[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

     IPS                                                            C. Monia
                                                               F. Travostino
                                                                    J. Tseng
     Internet Draft                                           Nishan Systems
     Document: draft-ietf-ips-ifcp-wglcc-00.txt                     May 2002
     Category: Informational


                  Responses to iFCP Rev. 10  Last Call Comments

     Status of this Memo

        This document is an Internet-Draft and is in full conformance with
        all provisions of Section 10 of [RFC2026].

        Internet-Drafts are working documents of the Internet Engineering
        Task Force (IETF), its areas, and its working groups. Note that
        other groups may also distribute working documents as Internet-
        Drafts. Internet-Drafts are draft documents valid for a maximum of
        six months and may be updated, replaced, or obsoleted by other
        documents at any time. It is inappropriate to use Internet- Drafts
        as reference material or to cite them other than as "work in
        progress."

        The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

        The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.


























     Monia, et-al            Category - Expiration                [Page 1]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


     Status of this Memo...................................................1
     Abstract..............................................................3
     Change Log............................................................3
     1.   Conventions used in this document...............................3
     2.   Comments from David Black.......................................3
     3.   Comments From Elizabeth Rodriguez..............................21
     4.   Comments from Brian Forbes.....................................25
     5.   Comments from Mallikarjun Chadalapaka..........................30
     6.   Security Considerations........................................43
     7.   References.....................................................43
     8.   Author's Addresses.............................................44
     Full Copyright Statement.............................................44










































     Monia, et-al            Category - Expiration                [Page 2]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002



     Abstract

        This document is a compilation of responses to review comments
        received for revision 10 if the iFCP specification [IFCP] during the
        preliminary last call period from 3/4/2002 to 3/18/2002.

     Change Log

        Revision 0 of draft-monia-ips-ifcplcc-00 to draft-ietf-ips-ifcp-
        wglcc-00.txt, revision 0.

        Comment 49 -- Modified to comply with IESG policy on number of co-
        authors.

        Modified the following responses per feedback from David Black and
        Mallikarjun Chadalapaka.

        Comment 5,
        Comment 12,
        Comment 94,
        Comment 104,
        Comment 110.
        Comment 120

     1. Conventions used in this document

        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
        this document are to be interpreted as described in [RFC2119].

        In the following, [E] designates an editorial comment, [T] a
        technical comment.

        The keywords 'Rejected' or 'Accepted' indicate fundamental agreement
        or disagreement with the position stated in the comment.

        The keyword 'Response' is used when a comment is predicated on a
        query. The explanatory text should be consulted for details.

     2. Comments from David Black

          Comment 1. [E} Page 5, Change Log

             Remove Change Log in the version after a successful WG Last
             Call.

          Accepted

          Comment 2. [E] Section 2.1, page 7, paragraph 1

             "Terms needed to clarify the concepts presented in this
             document are presented here."

     Monia, et-al            Category - Expiration                [Page 3]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             I don't like the usage of "clarify".  How about "Terms used to
             describe the concepts presented in this document are defined
             here." ?

          Accepted

             The text will be revised as suggested.

          Comment 3. [E] Section 2.1, Address Translation Mode Definition

             Some tool has helpfully inserted non-ASCII characters.  MS Word
             AutoCorrect is a likely suspect.  Hunt all of these down and
             fix them, then discipline the tool severely ;-).

          Accepted.

          Comment 4. [T] Section 2.1, Definition of FC-4 Layer

             "FC-4 - The fibre channel application layer. This layer is
             functionally equivalent to the TCP/IP application layer."

             I don't understand this.  Are you equating FC-4 with OSI layer
             7?  If so, I'm not sure that is correct, and it might be better
             to leave out this attempted analogy.

          Accepted

             The definition will be changed to:

             "FC-4 - The fibre channel mapping of an upper level protocol,
             such as [FCP-2], the fibre channel SCSI mapping."

          Comment 5. [T] Section 3.2, page 10

             a) "Arbitrated Loop -- A series of N_PORTs connected together
               in daisy-chain fashion.  Data transmission between N_PORTs
               requires arbitration for control of the loop in a manner
               similar to a token ring network."

             That's not a fabric topology, unless the loop is fabric
             attached, in which case you're in case c), Mixed Fabric. iFCP
             can't support an FC-AL loop that isn't fabric-attached.

          Accepted in part

             The terminology will be changed to "fibre channel network
             topologies".

             In addition, the following definition will be added:

             "Fabric -- From [FC-FS]: "The entity which interconnects
             N_PORTs attached to it and is capable of routing frames by
             using only the address information in the fibre channel frame."

     Monia, et-al            Category - Expiration                [Page 4]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             With regard to FC-AL support, an iFCP gateway implementation
             can emulate either a public (fabric attached) or private loop
             environment. The gateway may support a private loop by
             representing remotely attached devices as if they were resident
             on a local loop and by emulating the semantics required to
             support the loop control frames and primitives. Since these
             functions are implemented internally by the gateway, iFCP
             protocol support is not required.  However, the specification
             should explicitly prohibit the forwarding of fibre channel loop
             control frames via iFCP.

             A related issue is support for the set of extended link
             services for remote loop control, such as LINIT (Loop
             Initialize).  These are standard link service messages
             addressed to the loop fabric address (LFA) of the FL port
             controlling the loop. A gateway that chooses to expose remote,
             loop-connected devices as NL_Ports must also expose the LFA.
             To do so, it should assign the local alias such that the
             corresponding LFA or the remote loop can be derived by setting
             the port_id component of the alias to zero in accordance with
             [FC-FS].

             The specification will be modified to discuss these loop
             topology support issues.

          Comment 6. [T] Section 3.2, page 11, para 5

             "Depending on the topology, the N_PORT and fabric port variants
             through which a fibre channel device is attached to the network
             may be one of the following:

             "Fabric Topology  Fabric Port Type    N_PORT Variant
             ---------------  ----------------    --------------

             Loop             L_PORT              NL_PORT
             Switched         F_PORT              N_PORT
             Mixed            FL_PORT             NL_PORT
                              F_PORT              N_PORT"

             I believe the Loop line in this table does not match the other
             lines and if so, this is one more reason to leave non-fabric-
             attached FC-AL out of this description.

          Accepted in part

             Since the loop topology can be supported, it should remain in
             the table. However, the terminology should be changed per
             Comment 5 and the table modified as shown below:

             "FC Network Topology   N_PORT Variant     FC Network Interface
             --------------------   --------------     --------------------



     Monia, et-al            Category - Expiration                [Page 5]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             Loop                   NL_PORT           L_PORT
             Switched               N_PORT            F_PORT
             Mixed                  NL_PORT           FL_PORT via L_PORT"

             In the case of a mixed fabric, additional supporting text will
             be provided.

          Comment 7. [E] Section 3.3.1, page 14, para 2

             "All switched fabrics must provide the following services:

             "Fabric F_PORT server “ Services an N_PORT request to access
             the fabric for communications.

             Change "request" to "requests"

          Accepted

             Replace special character and reword as follows:

             "Fabric F_PORT server -- Services N_PORT requests to access the
             fabric for communications."

          Comment 8. [E] Section 4.4, page 21, para 2

             "As discussed below, an unbounded iFCP fabric may have any
             number of switch elements and gateways."

             It's not "any", but the limit is a very large number by
             comparison to 239.

          Accepted

             The sentence will be changed to:

             "As discussed below, an unbounded iFCP fabric is not limited to
             239 switches and gateways."

          Comment 9. [T] Section 4.4 - iFCP Fabric Properties

             At some point the need to reuse 24-bit addresses for outbound
             traffic from a single FC link behind an iFCP gateway will be a
             problem.  This comment also applies to the second paragraph in
             Section 4.4.2.

          Accepted

             A discussion of address re-use issues will be added to the
             spec.

          Comment 10.        [E] Section 4.5, page 23, para 2



     Monia, et-al            Category - Expiration                [Page 6]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             "In the iFCP protocol, an N_PORT is represented by the
             following addresses:"

             Change "addresses" to "types of addresses" to avoid implying
             that there's only one alias.  Different gateways will assign
             different aliases to the same N_PORT.

          Rejected

             The description of an alias will be revised as follows:

             b) "A 24-bit N_PORT alias. The fibre channel N_PORT address
                assigned by each gateway operating in address translation
                mode to identify a remotely attached N_PORT.

                Frame traffic is intercepted by an iFCP gateway and
                directed to a remotely attached N_PORT by means of the
                N_PORT alias.  The address assigned by each gateway is
                unique within the scope of the gateway region."

          Comment 11.        [T] Section 4.5, pp 24, para 14

             "The mode of gateway operation is settable in an
             implementation-specific manner.  The implementation MUST NOT
             allow the mode to be changed after the gateway begins
             processing fibre channel frame traffic."

             Might want to add a MUST that a gateway cannot operate in more
             than one mode at the same time, and a repeat of the (implied)
             requirement that all gateways in an iFCP fabric MUST operate in
             the same mode.

          Accepted

          Comment 12.        [T] Section 4.6. pp 24, para 2

             b) "When interoperating with locally attached fibre channel
                switch elements, each iFCP gateway MUST assume control of
                DOMAIN_ID assignments in accordance with the appropriate
                fibre channel standard or vendor-specific protocol
                specification."

             This is ok, but turns up another requirement that needs to be
             explicitly stated earlier.  Any given FC N_PORT MUST NOT be
             behind more than one iFCP gateway.  Address Transparent mode
             satisfies this because only one gateway can become the
             principal switch, so the others presumably shut down, but
             Address Translation mode appears to have the potential for
             seriously nasty misbehavior unless the "iFCP gateway MUST
             become the principal switch" requirement is imposed on it also.
             Need to add a sentence or two on how an iFCP gateway can be
             assured of becoming the principal switch.  Beyond this, the
             fact that any Fabric Attached FC-AL loop can have only one FL

     Monia, et-al            Category - Expiration                [Page 7]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             port completes the picture, ensuring that a loop can't stitch
             two gateway domains together.  Requiring the iFCP gateway to be
             the principal switch also avoids problems with the gateway
             being unable to obtain sufficient Domain IDs from the principal
             switch.

          Accepted in Part

             An N_PORT can be behind more than one gateway if the following
             rules are observed:

             a)  The gateways MUST cooperate in the assignment of N_PORT IDs
                 for locally attached devices and aliases for remotely
                 attached devices such that each local or remotely attached
                 N_PORT has one and only one N_PORT address within the scope
                 of the gateway region.

             b)  All iFCP frame traffic between any two N_PORTs MUST flow
                 through a single iFCP session.  However, each session may
                 traverse a different gateway attached to the region.

             In order to meet these constraints, a multi-gateway
             implementation may require an out of band mechanism for
             redirecting frame traffic from one physical gateway to another.

             The above will be added to the specification.

          Comment 13.        [T] Section 5.2.2.2, pp 32, para 4

             "The gateway SHALL initiate the creation of an iFCP session in
             response to a PLOGI ELS directed to a remote N_PORT from a
             locally attached N_PORT as described in the following steps.

             a) "Using the D_ID field in the PLOGI frame header, locate the
                remote N_PORT descriptor.  If no descriptor exists, the iFCP
                gateway SHALL return a response of LS_RJT, with a Reason
                Code of 'Unable to Perform Command Request' (0x09) and a
                Reason Code Explanation of 'Invalid N_PORT_ID' (0x1F). An
                iFCP session SHALL NOT be created."

             Need to explain why this is ok.

             The answer is that a properly operating FC N_PORT will have
             previously issued an FC nameserver query that the gateway
             translated to an iSNS query, and hence when it issues PLOGI to
             the result of the nameserver query, the iSNS query response
             created the required descriptor in the gateway before being
             translated to the FC nameserver result.  There's an implication
             here that remote N_PORT descriptors that result from iSNS
             queries translated from FC nameserver queries MUST NOT be
             discarded as long as any N_PORT that has issued a query for
             that remote N_PORT is logged into the fabric.


     Monia, et-al            Category - Expiration                [Page 8]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


          Accepted in part

             Although a name server query is almost always done in practice
             prior to a PLOGI, an N_PORT compliant with [FC-FS] is not
             required to do so. For that reason, the specification should
             cover the case where a fibre channel device attempts to send
             frames to an address without having executed a previous name
             server query.

             Also, while the policies for remote N_PORT descriptor retention
             are implementation-specific, the specification should at least
             contain recommendations. In that regard, the following added
             text is proposed:

             "Remote N_PORT Descriptors should be reclaimed based on a last
             in, first out policy.

             "An iFCP implementation should have sufficient resources to
             insure that a newly created descriptor is not reclaimed before
             the referencing iFCP session is created."

          Comment 14.         [E] Section 5.2.2.2 - Creating an iFCP Session

             e) "If a CBIND response is returned with one of the following
               statuses, the PLOGI SHALL be terminated with an LS_RJT
               message. Depending on the CBIND failure status, the Reason
               Code and Reason Explanation SHALL be set to the following
               values specified in [FC-FS]."

             Add a statement that this plus case f) is a comprehensive list
             of possible CBIND failure statuses, as specified in Section
             6.1.

          Accepted

          Comment 15.        [E] Section 5.2.2.2 - Creating an iFCP Session

             f) "A CBIND response with a CBIND STATUS of "N_PORT session
               already exists" indicates that the remote gateway has
               concurrently initiated a CBIND request to create an iFCP
               session between the same pair of N_PORTs. The receiving
               gateway SHALL terminate this attempt, return the connection
               to the Unbound state and prepare to respond to an incoming
               CBIND request as described below."

             Add a sentence indicating that the "simultaneous open" race is
             dealt with by allowing the sender with the numerically larger
             N_PORT name to succeed in establishing the session.

          Accepted

          Comment 16.        [E] Section 5.2.2.2, pp 34, para 2


     Monia, et-al            Category - Expiration                [Page 9]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             "The gateway receiving a CBIND request SHALL respond as
             follows:

             a) "If the receiver has a duplicate iFCP session in the OPEN
                PENDING state, then the receiving gateway SHALL compare the
                Source N_PORT Name in the incoming CBIND payload with the
                Destination N_PORT Name."

             b) "If the Source N_PORT Name is greater, the receiver SHALL
                issue a CBIND response of "Success" and SHALL place the
                session in the OPEN state."

             Add a sentence indicating that in case b), case c) will occur
             at the other gateway because N_PORT names are globally unique
             WWNs, and hence this gateway's duplicate session will receive a
             CBIND STATUS of "N_PORT session already exists" and will be
             terminated in due course.

          Accepted

          Comment 17.        [T] Section 5.2.2.2 - Creating an iFCP Session

             There's no discussion of what to do if a TCP connection closes
             unexpectedly during this process (e.g., if closing of unbound
             connections is allowed at arbitrary times for reasons such as
             reducing the resources consumed by unbound connections).  This
             needs to be added even if the reason in parentheses is not
             allowed.

          Accepted

          Comment 18.        [T] Section 5.2.2.2, pp 35, para 4

             "Upon receiving such a request, the gateway providing the
             connectivity probe SHALL transmit LTEST messages at the
             specified interval."

             This requires liveness test (LTEST) messages even when the
             connection is in active use.  Was that intended?

          Response

             The intent is to require LTEST messages at the specified
             interval regardless of whether or not there is other traffic.

          Comment 19.        [E] Section 5.2.2.4 - Use of TCP Features and
             Settings

             For Wrapped sequence detection, "Should use" in the table
             should be "SHOULD use".

          Accepted


     Monia, et-al            Category - Expiration               [Page 10]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


          Comment 20.        [T] Section 5.2.3.1, pp 38, para 1

             "In response to the Unbind message, either gateway may choose
             to close the TCP connection or return it to a pool of unbound
             connections."

             This assumes that Unbind is always successful.  It can fail, as
             documented in Section 6.2.  Need to specify how to deal with
             this (e.g., close the TCP connection).

          Accepted

             The sentence will be modified as follows:

             "Upon successful completion of an Unbind operation, either
             gateway may choose to close the TCP connection or return it to
             a pool of unbound connections."

             The processing for the failure cases will also be specified.

          Comment 21.        [T] Section 5.2.3.1 - iFCP Session Completion

             Can an iFCP gateway reduce the pool of unbound connections
             (e.g., due to demands for resources for other connections),
             possibly by closing them?  If yes, need to say so.

          Accepted

             A gateway may close an unbound connection due to resource
             demands.  The spec will be modified appropriately.

          Comment 22.        [E] Section 5.3 - IANA Considerations

             Put this near the end of the document where IANA can more
             easily find it.

          Accepted

          Comment 23.        [T] Section 5.4.1, pp 40, para 1

             "Protocol#            IANA-assigned protocol number identifying
             the protocol using the encapsulation.  For iFCP the value is
             (/TBD/)."

             It's 2 - cite the FC Encapsulation draft's IANA Considerations
             section as the authority for this.

          Accepted

          Comment 24.        [E] Section 5.4.2 - SOF and EOF Delimiter
             Fields



     Monia, et-al            Category - Expiration               [Page 11]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             Need to say that the format is specified in the FC Common
             Encapsulation document and reproduced here for convenience.

          Accepted

          Comment 25.        [T] Section 5.4.2 - SOF and EOF Delimiter
             Fields

             "SOF (bits 31-24 and bits 23-16 in word 0):  iFCP uses the
             following subset of the SOF fields described in [ENCAP].

             This is a problem because these codes are being specified in
             more than one place.  I think the FC Frame Encapsulation
             document is the right place for the normative specification of
             these codes (and see my comments against it on the need to get
             IANA involved).  This would be ok as a list of codes that are
             currently valid, but the specification authority needs to be in
             one place.  Same comment applies to EOF.

          Accepted in Part

             The specification will be revised in accordance with Comment
             24.

          Comment 26.        [E] Section 6, pp 46

             "LS_COMMAND     For a special link service ACC response to be
             processed by iFCP, the LS_COMMAND field SHALL contain bits 31
             through 24 of the LS_COMMAND to which the ACC applies.
             Otherwise the LS_COMMAND field shall be set to zero."

             There's an LS_COMMAND field in figure 16 and a second one in
             the iFCP portion of the FC Common Encapsulation header (from
             Section 5.4.1).

             When a single section discusses both fields, as Section 6 does,
             this gets confusing fast.  Please rename the LS_COMMAND field
             in the iFCP portion of the FC Common Encapsulation header to
             something like ACC_LS_COMMAND or LS_COMMAND_ACC.

          Accepted

             The mnemonic will be changed to LS_COMMAND_ACC.

          Comment 27.        [T/E] Section 6 - TCP Session Control Messages

             Request              LS_COMMAND Short Name  iFCP Support
             -------              ---------- ----------  -----------

             Connection Bind          0xE0       CBIND      REQUIRED
             Unbind Connection        0xE4      UNBIND      REQUIRED
             Test Connection Liveness 0xE5       LTEST      REQUIRED


     Monia, et-al            Category - Expiration               [Page 12]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             [T/E] How do we know that those three values (E0, E4, and E5)
             will not conflict with some future usage by Fibre Channel?  I
             think the answer is that SES=1 in the iFCP flags in the header,
             and would be 0 in any future use of these values in an ELS, but
             the use of those three values looks like an attempt to avoid
             conflict and should be explained.

          Accepted

             That is correct. These values were chosen as patterns readily
             distinguishable by a protocol analyzer.

          Comment 28.        [T] 6.2 - Unbind Connection (UNBIND)

             "Unbind Status Description
             ------------- -----------

                0        Successful “ No other status
              1 - 15     Reserved
                16       Failed - Unspecified Reason
                18       Failed - Connection ID Invalid
             Others      Reserved

             "Unbind can fail, but earlier specification of the use of
             Unbind (e.g., in Section 5.2.3.1) assumes that it cannot fail."

             Description of how to deal with Failed status needs to be added
             there (e.g., close the TCP connection).

          Accepted

          Comment 29.        [E] Section 7.2, pp 56, para 7

             "For translation type 3, the receiving gateway SHALL obtain the
             information needed to fill in the field in the link service
             frame payload by converting the specified N_PORT worldwide
             identifier to a gateway IP address and N_PORT ID.  This
             information MUST be obtained through an iSNS name server
             query."

             This requires an iSNS query for every type 3 translation
             received even if it exists locally in a Remote N_PORT
             descriptor.  It looks like this was intended due to the
             possibility of the descriptor being stale, but I wanted to
             check if that was in fact the intention.

          Accepted

             The intention was to update a potentially stale entry or force
             the creation of a new descriptor.

          Comment 30.        [E] Section 7.2, pp 57, para 3


     Monia, et-al            Category - Expiration               [Page 13]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             "When the ACC response requires iFCP intervention, the
             receiving gateway MUST act as a proxy for the originator,
             retaining the state needed to process the response from the
             N_PORT to which the request was directed."

             That doesn't parse for me.  I think the intended meaning was
             that when an ELS request is sent whose ACC will require iFCP
             intervention, the ELS also requires intervention to capture the
             state necessary to process the ACC.

          Accepted

             The text will be modified as follows:

             "When the ACC response requires iFCP intervention, the
             receiving gateway MUST intervene to process the response from
             the N_PORT to which the request was directed."

          Comment 31.        [T] 7.3 - Fibre Channel Link Services Processed
             by iFCP

             "The following Extended and FC-4 Link Service Messages must
             receive special processing."

             Process question - how does this list get coordinated with T11
             so that it gets updated when T11 defines a new ELS or FC-4 LS
             that requires iFCP intervention?

          Response

             The specification must be revised to track the evolving fibre
             channel specifications, including, among other things, the
             addition of new link services that require special processing.

          Comment 32.        [T] 7.3.1.1 - Abort Exchange (ABTX)

             "Fields Requiring       Translation   Supplemental Data
             Address Translation     Type (see      (type 3 only)
             -------------------    section 7.2)     ------------
                                    -----------
             Exchange Originator        1, 2              N/A
             S_ID"

             Need to specify how to choose the translation type.  This
             comment also applies to RES, RES ACC, RLS, RSS, RRQ, RSI, REC
             and REC ACC.  It may be best resolved by adding additional text
             in Section 7.2.

          Accepted

          Comment 33.        [E] 7.3.1.3 - Discover Address Accept (ADISC
             ACC)


     Monia, et-al            Category - Expiration               [Page 14]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             Should the Command field be 0x20 or 0x02?

          Response

             The command field for all ACC response frames is 0x02.  No
             change to the specification is required.

          Comment 34.        [T] 7.3.1.3 - Discover Address Accept (ADISC
             ACC)

             "Other Special Processing:

             The Hard Address of the ELS originator SHALL be set to 0."

             Doesn't this also require setting the LS_COMMAND iFCP-specific
             field (to be renamed) in the FC Common Encapsulation header?
             This comment also applies to all other ACC's in Section 7.

          Accepted

             The specification will be modified accordingly.

          Comment 35.        Section 8.2.1 - Enforcing R_A_TOV Limits

             The rules in this section appear to allow forwarding of all
             frames received while in Unsynchronized mode or with a
             timestamp of 0,0.  This looks like  formula for violating
             R_A_TOV - was this intended?

          Response

             The intention was to abort all iFCP sessions and not allow the
             creation of new ones.  The specification will be revised
             accordingly.

          Comment 36.        [T] Section 9.4.1 - Establishing the Broadcast
             Configuration

             "The broadcast configuration is managed using facilities
             provided by the iSNS server. Specifically:

             a) "An iSNS discovery domain is created and seeded with the
                network address of the global broadcast server N_PORT.  The
                global server is identified as such by setting the
                appropriate N_PORT entity attribute."

             There are no means for recovery from failure, so loss of the
             gateway performing the broadcast service results in loss of the
             broadcast service. This needs to be explained at a minimum, and
             probably corrected.

          Accepted


     Monia, et-al            Category - Expiration               [Page 15]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             An implementation may designate a local server as a standby
             global broadcast server.  The local server uses the LTEST
             message to determine if the global server is functioning and
             may assume control if not.

             The specification will be revised accordingly.

          Comment 37.        [T] Section 10.2.2, page 82, para 1

             "Conformant implementations of the iFCP protocol MAY use such
             security definitions."

             I don't understand this sentence.  What was intended?

          Accepted

             The paragraph will be changed to:

             ôIt is imperative to thwart these attacks, given that an iFCP
             gateway is the last line of defense for a whole fibre channel
             island, which may include several hosts and fibre channel
             switches. To do so, the iFCP gateway must implement and may use
             confidentiality, data origin authentication, integrity, and
             replay protection on a per-datagram basis. The iFCP gateway
             must implement and may use bi-directional authentication of the
             communication endpoints. Finally, it must implement and may use
             a scalable approach to key management.ö

          Comment 38.        [T] Section 10.2.3, pp 82, para 1

             "Enterprise data center networks are considered mission-
             critical facilities that must be isolated and protected from
             all possible security threats.  Such networks are usually
             protected by security gateways, which at a minimum provide a
             shield against denial of service attacks.  The iFCP security
             architecture is capable of leveraging the protective services
             of the existing security infrastructure, including firewall
             protection, NAT and NAPT services, and IPSec VPN services
             available on existing security gateways."

             While this is true of iFCP, iSNS has some serious issues with
             NAT and NAPT and iFCP cannot be operated without iSNS.

          Rejected

             iSNS issues with NA(P)Ts are thought to be resolved (see
             Section 3.6 in the iSNS specification). iSNS has at least two
             non-exclusive options to cope with NA(P)Ts, a) the use of FQDNs
             instead of IP addresses, and b) the option to establish a
             confederation of iSNS servers and have them doctor IP numbers
             in transit as part of their mutual confederation contract.

          Comment 39.        [T] Section 10.2.4, pp 82, para 1

     Monia, et-al            Category - Expiration               [Page 16]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             "iFCP gateways MUST use Discovery Domain information obtained
             from the iSNS server [ISNS] to determine whether the initiating
             fibre channel N_PORT should be allowed access to the target
             N_PORT. N_PORT identities used in the Port Login (PLOGI)
             process shall be considered authenticated provided the PLOGI
             request is received from the remote gateway over a secure,
             IPSec-protected connection."

             Need to say something about the IKE identities (ID payloads)
             used for the authentication, and how they correspond to
             information obtained from iSNS - NATs/NAPTs will cause issues
             here.  Just requiring an IPsec-protected connection isn't good
             enough as it may allow a node not registered with iSNS to get
             in.

          Accepted in part

             It would be premature to enumerate ID payloads in section
             10.2.4, which describes the scope of the overall security
             design prior to any IKE/IPsec requirement (to follow in
             sections 10.3). The requested information will be supplied
             after the last paragraph in section 10.3.1.

             Regarding intervening NA(P)Ts between iSNS clients and servers,
             it is possible to put a proxy iSNS server at the boundary
             between addressing domains. Such proxy will terminate the
             IKE/IPSec so that the ID_IPV4_ADDR identity can be used
             natively by IKE.  It is also possible to use the second method
             described in the response to comment 38 -- a confederation of
             iSNS servers where the NAT(P)T mediation now occurs between
             iSNS servers.

             Admission control is performed by the iSNS server, based upon
             the Discovery Domain (DD) configuration information stored in
             that iSNS server. Once the authenticity of a gateway is
             verified (e.g., via a pre-shared key) and IPsec SAs are
             established, then the gateway is trusted to behave according to
             the specification, which mandates a handshake with iSNS for
             admission.

          Comment 40.        [E] Section 10.2.6  Rekeying

             I believe the security draft has changed in this area (small
             rekeying interval example), please check it.

          Response

             We appear to be consistent with [SECIPS] version 11 still, end
             of section 5.4, when BellareÆs results are taken into
             consideration.  Therefore, no change to iFCP is required.

          Comment 41.        [T] Section 10.2.7  Authorization


     Monia, et-al            Category - Expiration               [Page 17]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             "Authorization is outside of the scope of this specification,
             and is seen as fully orthogonal to the iFCP security design.
             Such design, however, includes key authorization-enabling
             features in the form of Identity Payload (e.g., ID_FQDN),
             certificate-based authentication (e.g., with X509v3
             certificates), and discovery domains [ISNS]."

             What??  If iSNS doesn't know about an iFCP gateway, that
             gateway shouldn't be able to talk to any other iFCP gateway.
             That's access control, which counts as authorization in my
             book.

          Accept

             The paragraph will be re-written as follows.

             ôBasic access control properties stem from the requirement that
             the communicating iFCP gateways be known to one or more iSNS
             servers before they can engage in iFCP exchanges. The optional
             use of Identity Payloads (e.g., ID_FQDNs), certificate-based
             authentication (e.g., with X509v3 certificates), and discovery
             domains [ISNS] enables authorization schemas of increasing
             complexity. The definition of such schemas (e.g., role-based
             access control) is outside of the scope of this specification."

          Comment 42.        [E] Section 10.3.2, pp 86, para 8

             If an iFCP implementation makes use of unbound TCP connections,
             and such connections belong to an iFCP Portal with security
             requirements, then the unbound connections MUST be protected by
             an SA at all times just like bounded connections.

             Change "bounded" to "bound".

          Accepted

          Comment 43.        [T] Section 10.3.2, pp 86, para 9

             "Upon receiving an IKE Phase-2 delete message, there is no
             requirement to terminate the protected TCP connections or
             delete the associated IKE Phase-1 SA. Since an IKE Phase-2 SA
             may be associated with multiple TCP connections, terminating
             such connections might in fact be inappropriate and untimely.
             An iFCP Portal must instead attempt to create a new Phase-2 SA
             while there are outstanding iFCP sessions."

             That's a problem.  If the other side is behaving in accordance
             with the next paragraph ...:

             "To minimize the number of active Phase-2 SAs, IKE Phase-2
             delete messages may be sent for Phase-2 SAs whose TCP
             connections have not handled data traffic for a while. To
             minimize the use of SA resources while the associated TCP

     Monia, et-al            Category - Expiration               [Page 18]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             connections are idle, creation of a new SA may be deferred
             until new data is to be sent over the connections."

             ... and is deleting the Phase-2 SAs because it lacks the
             resources to support them, immediately creating a new Phase-2
             SA in response to delete messages risks livelock (massive churn
             in Phase-2 SA creation/destruction).  Creating a new Phase-2 SA
             in response to a Phase-2 delete message SHOULD be deferred
             until there is traffic to send over that SA.

          Accepted

             We shall be removing the misleading sentence ôAn iFCP Portal
             must instead attempt to create a new Phase-2 SA while there are
             outstanding iFCP sessions." and promote from may to SHOULD
             prior to the word ædeferredÆ.

             The resulting modified text is shown below:

             "Upon receiving an IKE Phase-2 delete message, there is no
             requirement to terminate the protected TCP connections or
             delete the associated IKE Phase-1 SA. Since an IKE Phase-2 SA
             may be associated with multiple TCP connections, terminating
             such connections might in fact be inappropriate and untimely.

             "To minimize the number of active Phase-2 SAs, IKE Phase-2
             delete messages may be sent for Phase-2 SAs whose TCP
             connections have not handled data traffic for a while. To
             minimize the use of SA resources while the associated TCP
             connections are idle, creation of a new SA SHOULD be deferred
             until new data is to be sent over the connections."

          Comment 44.        [E] Section 13. - Normative References

             RFC 2451 reference shows up twice.

          Accepted

          Comment 45.        [T] Section A.2 - Link Services Processed
             Transparently

             "ACC       Accept"

             Is that right?  I thought this was intercepted in some cases,
             as indicated in Table 6.

          Response

             The ACC description will be modified to discriminate between
             the transparent and non-transparent cases.

          Comment 46.        [T] Section A.2 - Link Services Processed
             Transparently

     Monia, et-al            Category - Expiration               [Page 19]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             FDISC     Discover F_Port Service Parameters
             FLOGI     F_Port Login
             RTV       Read Timeout Value

             Definitely wrong - the iFCP gateway has to implement these
             itself as specified in Section 9.1.

          Accepted in Part

             Special link service messages are those which require
             intervention by an iFCP protocol implementation before they are
             passed to the destination N_PORT.  Transparent link service
             messages are passed to the destination N_PORT without such
             intervention. In that regard, the above link services are
             processed transparently.

             The specification will be modified to make the above
             distinction clearer and the section will be re-titled as: "Link
             Services Processed Transparently by the iFCP layer".

          Comment 47.         [T] Section A.2 - Link Services Processed
             Transparently

             LINIT     Loop Initialize
             LPC       Loop Port Control
             LSTS      Loop Status
             SCL       Scan Remote Loop

             I don't have time to check these, but I'm suspicious about
             whether anything that has "Loop" as part of its name can/should
             be forwarded transparently into an FC fabric, although SCL
             seems plausible.  Please verify whether these are transparent.

          Response

             SCL must be processed as a special link service message. iFCP
             will be modified accordingly.  The remaining link services
             listed above are transparent.

          Comment 48.        [T] Section A.2 - Link Services Processed
             Transparently

             RSCN      Registered State Change Notification
             SCN       State Change Notification
             SCR       State Change Registration

             Those can't be transparent, as Section 9.2 requires the iFCP
             gateway to implement them.

          Response

             See response to Comment 46.


     Monia, et-al            Category - Expiration               [Page 20]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


     3. Comments From Elizabeth Rodriguez

          Comment 49.        [E] Title Page, Number of Authors

             Looks like you have 8 authors listed. Rule of thumb I think is
             6. I am having difficulty locating the guidelines, but may want
             to consider how you can move a couple of the listed authors
             into an acknowledgements section of some sort.   With 8, it may
             or may not get flagged by the IESG...

          Accepted

             We will reduce the roster of co-authors in accordance with IETF
             policy.

          Comment 50.        [E] Capitalize Fibre Channel

             I believe "Fibre Channel" should be capitalized throughout
             document.

          Rejected

             The specification is consistent with T11 lower case usage.

          Comment 51.        [E] Acknowledgements

             Braces around SECIPS do not match.

          Accepted

          Comment 52.        [E] Section 1.2

             "NCITS" should be "INCITS".

          Accepted

          Comment 53.        [E] "About This Document"

             There should be a page break before this section.

          Accepted

          Comment 54.        [E] Definitions, iFCP Frame

             Technically, the title is of the comment encapsulation
             specification is "FC Frame Encapsulation".

          Accepted

          Comment 55.        [E] Definitions




     Monia, et-al            Category - Expiration               [Page 21]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             In the definitions of "N_PORT Alias" and "N_PORT I/D", two
             dashes should be used to separate the term from the body of the
             definition.

          Accepted

          Comment 56.        [E] Section 3, pp 9, para 1

             "Fibre channel is a frame-based, serial technology designed for
             peer-to-peer communication between devices at gigabit speeds
             and with low overhead and latency."

             May want to change to gigabit or greater speeds.  Technically,
             2, 4, 10 gigabit speeds are still gigabit, but many today
             interpret gigabit strictly as 1 gigabit.

          Rejected

             The term 'speeds' implies rates of 1Gb/sec and above.

          Comment 57.        [E] Section 3.1

             a) "N_PORTs -- The end points for fibre channel traffic. In
                the FC standards, N_PORT interfaces have several variants,
                depending on the topology of the fabric to which they are
                attached. As used in this specification, the term applies
                to any one of the variants."

             Suggestion -- sometimes referred to in literature as Nx_PORTs?

          Rejected

             A parenthetical Nx_PORT digression does not add any value to
             the iFCP specification, given that the following statement
             claims that N_PORT is used for any such variants.

          Comment 58.        [E] Section 3.2, Fabric Topologies

             a) "Arbitrated Loop -- A series of N_PORTs connected together
                in daisy-chain fashion. Data transmission between N_PORTs
                requires arbitration for control of the loop in a manner
                similar to a token ring network."

          Accepted in part

             Rewrite as:

             a) ôArbitrated Loop -- A series of N_PORTs connected together
                in daisy-chain fashion. Loop-connected N_PORTS are referred
                to as NL_PORTS. Data transmission between NL_PORTS
                requires...ö

          Comment 59.        [E] Section 3.3, pp 13, para 6

     Monia, et-al            Category - Expiration               [Page 22]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             "FC-4 û- Application protocols, such as FCP, the fibre channel
             SCSI protocol."

             Reword to read: "...such as FCP, commonly used abbreviation for
             "Fibre Channel Protocol for SCSI"

          Accepted in part

             The sentence will be revised to read: "...such as the fibre
             channel protocol for SCSI (FCP)."

          Comment 60.        [E] Section 3.7, pp 16, par 2

             "The source and destination N_PORT fabric addresses embedded in
             the S_ID and D_ID fields represent the physical MAC addresses
             of originating and receiving N_PORTs."

             "I think the term MAC is inappropriate here -- MAC is really an
             ethernet term.  Something like physical world wide unique
             address, similar to an ethernet MAC address... Or ... represent
             the physical MAC like address...

          Accepted

             The text will be changed to:

             "The source and destination N_PORT fabric addresses embedded in
             the S_ID and D_ID fields represent the physical addresses of
             the originating and receiving N_PORTs."

          Comment 61.        [E] Section 3.8, Fibre Channel Transport
             Services

             Does class 6 still exist, or has it been made obsolete?

          Response

             Class 6 is still specified in [FC-FS].

          Comment 62.        [E] Section 4.5, pp 24, para 5

             "The mode of gateway operation is settable in an
             implementation-specific manner. The implementation MUST NOT
             allow the mode to be changed after the gateway begins
             processing fibre channel frame traffic."

             Does this need to be qualified -- e.g. MUST NOT allow the mode
             to be changed after the gateway begins processing Fibre Channel
             traffic without first terminating all connections to that
             gateway, or some such -- in other words, really someone can
             change the mode of operation, but just cannot do so while the
             gateway is in use.


     Monia, et-al            Category - Expiration               [Page 23]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


          Rejected

             The specification will not be changed. The intent is to latch
             the operational mode after gateway power is turned on and the
             gateway begins handling FC frame traffic.  A change in
             operational mode is not intended to be easy or graceful.

          Comment 63.        [E] Section 5.2.2.1, pp 31, para 9

             "When creating a descriptor in response to an incoming CBIND
             request, the iFCP gateway SHALL perform an iSNS name server
             query using the worldwide port name of the remote N_PORT in the
             SOURCE N_PORT NAME field within the CBIND payload. The
             descriptor SHALL be filled in using the query results."

             Need to make sure that iSNS gets through WG last call soon as
             well, since this is a normative dependency.

          Accepted

          Comment 64.        [E] Section 5.4, pp 39, para 1

             "This section describes the iFCP encapsulation of fibre channel
             frames. The encapsulation is based on the common encapsulation
             format defined in [ENCAP]."

             The reference to "common encapsulation" should be "FC Frame
             Encapsulation".

          Rejected

             The reference is appropriate.

          Comment 65.        [E] Section 6.2, Unbind Connection (UNBIND)

          It should be noted that the Unbind status codes listed in this
          section are decimal values.

          Accepted

             The rules for numeric representation will be added to the
             "Conventions" section.

          Comment 66.        [E] Section 7, pp 53

             a) "Transparent û The link service message and reply MUST be
               transported to the receiving N_PORT by the iFCP gateway
               without altering the message payload. The link service
               message and reply are not processed by the iFCP
               implementation."

             Since iFCP has Transparent and Translation modes, use of the
             term transparent here might get confusing -- Transparent is

     Monia, et-al            Category - Expiration               [Page 24]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             referring to the fact that the link service must be propogated
             across the IP network, correct?  As opposed to a link service
             that is applicable only to transparent mode...

          Accepted

             The term "transparent" in this context will be changed to
             "pass-though".

     4. Comments from Brian Forbes

          Comment 67.        [E] Section 2.1, Special Characters

             For some reason the file contains a number of occurrences of
             the character <funny character> instead of a hyphen or dash.
             Occurs throughout the text.

          Accepted

          Comment 68.        [E] Section 2.1, Definitions

             "iFCP Session - An association created when an N_PORT sends a
             PLOGI request to a remotely attached N_PORT. It is comprised of
             the N_PORTs and TCP connection that carries traffic between
             them."

             Grammar: ôit is comprised ofö should be ôit comprisesö.

          Accepted

          Comment 69.        [E] Section 2.1, Definitions

             "N_PORT Alias -- The N_PORT address assigned by a gateway to
             represent a remote N_PORT accessed via the iFCP protocol. When
             routing frame traffic in address translation mode, the gateway
             automatically converts N_PORT aliases to N_PORT network
             addresses and vice versa."

             Consistency: in the list of 2.1 definitions, some entries use a
             double hyphen and others only a single one (which at least one
             reader interpreted as a change in level)

          Accepted

          Comment 70.        [E] Section 3.1, The Fibre Channel Network

             "Unlike a layered network architecture,  a fibre channel
             network is largely..."

             Remove the extra space after the comma.

          Accepted


     Monia, et-al            Category - Expiration               [Page 25]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


          Comment 71.        [E] Section 3.3.1, Fabric Supplied Link
             Services

             "Time Server û- Intended for the management of fabric-wide
             expiration timers or elapsed time values and is not intended
             for precise time synchronization"

             Parallel structure: ôand is not intendedö seems to read better
             as ôand not intendedö

          Accepted

             Text will be changed to read:

             "Time Server û- Intended for the management of fabric-wide
             expiration timers or elapsed time values and not intended for
             precise time synchronization"

          Comment 72.        [E] Section 3.7.1, page 6, para 3

             "...The value of the Domain I/D ranges from 1 to 239 (0xEF)."

             Both ôIDö and ôI/Dö are used to mean ôidentifierö within the
             same paragraph. Common usage suggests ôIDö throughout. Also
             occurs elsewhere, e.g. page 21

          Accepted

          Comment 73.        [E] Section 3.7.1, page 17, para 3

             For some reason the file contains a number of occurrences of a
             non-ascii character instead of an apostrophe. Also occurs on
             pages 64 for example.

          Accepted

          Comment 74.        [E] Section 3.7.1, page 17, para 4

             ôFLOGIö: this is the first occurrence of this FC term; it
             should be spelled out here or a forward reference could be
             provided

          Accepted

          Comment 75.        [E] Section 3.9, page 18. item a)

             a) "Fabric Login (FLOGI) -- An operation whereby the N_PORT
                registers its presence on the fabric, obtains fabric
                parameters, such as classes of service supported, and
                receives its N_PORT address,"

             Reads better without the comma after ôfabric parametersö.


     Monia, et-al            Category - Expiration               [Page 26]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


          Accepted

          Comment 76.        [E] Section 4, page 18, para 3

             "Within the fibre channel device domain, fabric-addressable
             entities consist of other N_PORTs and devices internal to the
             fabric that perform the fabric services defined in [FC-GS3]."

             ôdevicesö is possibly ambiguous here, could say ôFC devicesö or
             iFCP devicesö depending on the intent.

          Accepted

             Text will be changed to:

             "Within the fibre channel device domain, fabric-addressable
             entities consist of other N_PORTs and fibre channel devices
             internal to the fabric that perform the fabric services defined
             in [FC-GS3]."

          Comment 77.        [E] Section 4.6.1, Page 25, Para 1

             "As described in section 4.6, each gateway and fibre channel
             switch in a bounded iFCP fabric MUST have a unique domain I/D.
             In a gateway region containing fibre channel switch elements,
             each element obtains a domain I/D by querying the principal
             switch as described in [FC-SW2] -- in this case the iFCP
             gateway itself.  The gateway in turn MUST obtain domain I/Ds on
             demand from the iSNS name server acting as the central address
             allocation authority. In effect, the iSNS server assumes the
             role of principal switch for the bounded fabric. In that case,
             the iSNS database contains:"

             The fact that a gateway can act as the FC principal switch is
             mentioned in this section and others, but there seems to be no
             normative text determining when it must do so. This will be
             obvious to a knowledgeable reader, or perhaps is covered in an
             ancillary document, but given the care taken elsewhere to
             provide normative language for æobviousÆ functionality it seems
             to be an oversight

          Rejected

             Since the paragraph is intended to describe behavior that is
             normatively specified elsewhere, the use of "MUST" is
             incorrect.  The text will be changed to the following:

             "As described in section 4.6, each gateway and fibre channel
             switch in a bounded iFCP fabric has a unique domain I/D.  In a
             gateway region containing fibre channel switch elements, each
             element obtains a domain I/D by querying the principal switch
             as described in [FC-SW2] -- in this case the iFCP gateway
             itself.  The gateway in turn obtains domain I/Ds on demand from

     Monia, et-al            Category - Expiration               [Page 27]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             the iSNS name server acting as the central address allocation
             authority. In effect, the iSNS server assumes the role of
             principal switch for the bounded fabric. In that case, the iSNS
             database contains..."

          Comment 78.        [E] Section 5.2.2.3, page 35, paras 3 and 4

             These two paragraphs use the terms æheartbeatÆ and
             æconnectivity probeÆ as informal synonyms for LTESTs. Use of
             the same synonym in both places would keep the reader from
             wondering whether the two synonyms represent the same concept.

          Accepted

          Comment 79.        [E] Section 5.2.2.4.3, page 37, para 1

             "Window scaling, as specified in [RFC1323], allows full
             utilization of links with large bandwidth - delay products and
             should be supported by an iFCP implementation."

             Is ôshouldö intended to be normative (capitalized)?

          Response

             The lower case usage is intentional.  The goal is to reflect a
             desirable bias rather than the sort of mandate defined in
             [RFC2119].

          Comment 80.        [E] Section 5.2,3, page 32, items c) and d)

             a) "For an FC frame received from the IP network, a gateway
                detects a CRC error in the encapsulation header. The gateway
                shall abort the session as described in section....

             b) "The TCP connection associated with the login session fails
                for any reason.  The gateway detecting the failed connection
                shall abort the session as described in section...."

             ôshallö should be capitalized.

          Accepted

          Comment 81.        [E] Section 5.4, page 39, last paragraph

             "When operating in Address Translation mode, (see section ...)
             the iFCP gateway must recalculate the fibre channel CRC."

             ômustö should be in caps.

          Accepted

          Comment 82.        [E] Section 5.4, page 41, "TRN" mnemonic


     Monia, et-al            Category - Expiration               [Page 28]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             ItÆs unfortunate that ôTRNö can be read as either ôtransparentö
             or ôtranslationö and therefore has less mnemonic value.

          Accepted

             "TRN", the mnemonic for "transparent mode", will be changed to
             "TRP".

          Comment 83.        [E] Section 6.2, page 49, para 1

             "UNBIND is used to release a bound TCP connection and.
             optionally, return it to the pool of unbound TCP connections."

             Punctuation: ôand. optionally, ö should be ôand optionallyö.

          Accepted

          Comment 84.        [E] Section 7.3, page 58, para 2

             "The formats of each special link service message, including
             supplemental data where applicable, are shown in the following
             sections."

             ôThe formats of eachà message areö is awkward, suggest ôThe
             format of eachà message isö.

          Accepted

          Comment 85.        [E] Section 7.3.1.6, page 63, para 2

             "This ELS shall always be sent as an augmented ELS regardless
             of the translation mode in effect."

             "Shall" should be capitalized.

             Accepted

             The text must also be modified to replace "augmented" with
             "special", as given below.

             "This ELS SHALL always be sent as a special ELS regardless of
             the translation mode in effect."

             [E] Section 7.3.1.14, page 71, last paragraph

             "The size of each frame to be sent to the destination N_PORT
             MUST NOT exceed the maximum frame size that the destination
             N_PORT can accept.  The sequence identifier in each frame
             header SHALL be copied from the augmented ELS and the sequence
             count shall be monotonically increasing."

             "Shall" should be capitalized.


     Monia, et-al            Category - Expiration               [Page 29]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


          Accepted

          Comment 86.        [E] Section 10.2.4, page 82, paras 1 and 2

             "iFCP is a peer-to-peer protocol.  iFCP sessions may be
             initiated by either or both peer gateways.  Consequently, bi-
             directional authentication of peer gateways MUST be provided.

             "iFCP gateways MUST use Discovery Domain information obtained
             from the iSNS server [ISNS] to determine whether the initiating
             fibre channel N_PORT should be allowed access to the target
             N_PORT.  N_PORT identities used in the Port Login (PLOGI)
             process shall be considered authenticated provided the PLOGI
             request is received from the remote gateway over a secure,
             IPSec-protected connection."

             These paragraphs seem to be statements of required
             functionality but are too general to use normative language
             (ôMUSTö). Later sections contain the normative text necessary
             to cover these topics.

          Accepted

          Comment 87.        [E] Section 10.2.5, page 82, para 1

             See Comment 86.

          Accepted

          Comment 88.        [E] Section 10.2.6, pages 82 and 82, all
             paragraphs

             See Comment 86.

          Accepted



     5. Comments from Mallikarjun Chadalapaka

          Comment 89.        [E] Section 1.2

             "...standards controlled by NCITS T10 and T11."

             "NCITS" should be "INCITS".

          Accepted

          Comment 90.        [E] 2.1 Definitions

             "Gateway Region -- The portion of an iFCP fabric accessed
             through an iFCP gateway. Fibre channel devices in the region


     Monia, et-al            Category - Expiration               [Page 30]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             consist of all fibre channel devices locally attached to the
             gateway."

             The first sentence here when interpreted wrt a Nx_port sitting
             within a given gateway region, implies something that isn't
             right - viz. the rest of the iFCP fabric.  The second sentence
             makes the intention clear, if "locally attached" includes the
             entire local fabric.  My suggestion would be: "The portion of
             an iFCP fabric that accesses the rest of the fabric through one
             iFCP gateway."

          Accepted

             The definition will be changed to the following:

             "Gateway Region -- The portion of an iFCP fabric accessed
             through an iFCP gateway by a remotely attached N_PORT. Fibre
             channel devices in the region consist of all those locally
             attached to the gateway."

          Comment 91.        [T] Section 3.3.1, pp 14, para 7

             "Time Server -- Intended for the management of fabric-wide
             expiration timers or elapsed time values and is not intended
             for precise time synchronization."

             I am curious about this - is it the conclusion the iFCP authors
             reached? The reason I ask is that IIRC, FCIP allows using this
             for time sync.

          Response

             See Comment 71 for the proposed change to this section.

             The characterization is found in the literature and based on
             the following from the [FC-GS3] specification, section 7, page
             161.

             "The Time Service is provided to serve time information that is
             sufficient for managing expiration time."

          Comment 92.        [T] Section 3.7, pp 14, para 2

             "The source and destination N_PORT fabric addresses embedded in
             the S_ID and D_ID fields represent the physical MAC addresses
             of originating and receiving N_PORTs."

             I am not sure that it is a correct analogy....S_ID and D_ID are
             actually (potentially transient) addresses assigned by the
             fabric, Port Names are more akin to the MAC addresses.

          Accepted


     Monia, et-al            Category - Expiration               [Page 31]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             See Comment 60.

          Comment 93.        [E] 4. The iFCP Network Model

             "The iFCP protocol enables the implementation of fibre channel
             mixed or switched fabric functionality on an IP network."

             I am not sure what is intended by "fibre channel mixed or
             switched" here, perhaps this could use rewording.

          Accepted

             The text will be changed to:

             "The iFCP protocol enables the implementation of fibre channel
             fabric functionality on an IP network."

          Comment 94.        [E] Section 4, pp 20, para 1

             "Each iFCP gateway contains two standards-compliant fibre
             channel ports and an iFCP Portal for attachment to the IP
             network."

             Why are two FC ports required?  As far as I can tell, even one
             E_Port works just as well - is it to be technically called as a
             "switch"?

             Also, is there a reason for limiting to only one IP address
             (implied by one iFCP Portal)?  I see that supporting multiple
             iFCP Portals would require enahancements to the data structures
             presented - but can you please comment on any architectural
             issues here?

          Response

             The specification will be revised to emphasize that the figure
             is but one example of a supported implementation.  It was
             intended to parallel the earlier fibre channel fabric example
             as a way of showing the transition to an equivalent iFCP
             fabric.

             The selected example was chosen because it was easier to depict
             within the constraints of ASCII text.  An E_PORT example could
             have also been used.  In either case, the device incorporating
             iFCP portal functionality would be called an "iFCP gateway".

             The considerations to be addressed when connecting multiple
             iFCP portals to a gateway region are discussed in Comment 12.

          Comment 95.        [E] section 4, pp 20, para 2

             "... channel switch element. At this interface, remote N_PORTs
             are presented as fabric-attached devices. Conversely, on the IP

     Monia, et-al            Category - Expiration               [Page 32]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             network side, the gateway presents each locally connected
             N_PORT as a logical fibre channel device."

             I am not sure the last sentence is correct - I think "logical
             fibre channel device" should probably be replaced by "a TCP
             connection".

          Rejected

             The logical fibre channel device represents the layer 4
             abstraction visible on the IP network.

          Comment 96.        [E] Section 4.1, pp 20, para 1

             "...cases, the gateway may support any standards-compliant
             fibre channel fabric type by incorporating the functionality
             required to..."

             Can you please comment if really "fabric type" is meant here?
             Or, is it the "fabric port type"?

          Response

             More accurately, "fabric type" should be changed to "fibre
             channel network topology."  The specification will be changed
             accordingly. See Comment 5.

          Comment 97.        [E] Section 4.1, pp 20, para 1

             "...present locally attached N_PORTs as logical iFCP devices."

             It may be useful to define "iFCP device" in section 2.1.

          Rejected

             From section 2.1:

             "Logical iFCP Device - The abstraction representing a single
             fibre channel device as it appears on an iFCP network."

             The specification will not be changed.

          Comment 98.        [T]  Section 4.4.1, pp 22, para 2

             "...messages, a gateway cannot convert such addresses in the
             payload of vendor- or user-specific fibre channel frame
             traffic."

             Not being very familiar with today's FC, can you please comment
             if these proprietary versions of frame formats (with even the
             D_ID out of place) are legal on regular fabrics?  Seems like
             the entire fabric should be capable of special handling
             these...

     Monia, et-al            Category - Expiration               [Page 33]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


          Response

             There is one and only one acceptable format for FC frames. That
             said, the issue is not the frame format but the payload
             contents.

             Besides the addresses in the FC frame header, an iFCP
             implementation is only cognizant of N_PORT addresses that may
             be embedded in the payload of standards-compliant link service
             messages.  It cannot remap such addresses if present in the
             payloads of user-specified or vendor-specific frames.

             No change to the specification will be made.

          Comment 99.        [T] Section 4.4.3, pp 22, para 1

             "In an unbounded iFCP fabric, limiting the scope of an N_PORT
             address to a gateway region reduces the likelihood that
             reassignment of domain I/Ds caused by a disruption in one
             gateway region will cascade to others."

             "In an unbounded iFCP fabric, limiting the scope of an N_PORT
             address to a gateway region reduces the likelihood that "

             Does it not prevent the likelihood?

          Accepted

             The text will be changed to:

             "In an unbounded iFCP fabric, limiting the scope of an N_PORT
             address to a gateway region prevents reassignment of domain
             I/Ds caused when a disruption in one gateway region cascades to
             others."

          Comment 100.       [T] Section 4.4.3, pp 22, para 2

             "In addition, a bounded iFCP fabric has an increased dependency
             on..."

             Suggest changing "In addition" to "On the other hand".

          Accepted

          Comment 101.       [E] Section 4.4.3, pp 22, para 3

             "Finally, adding a gateway to a bounded fabric is more likely
             to disrupt the operation of all devices in the gateway region
             along with those already in the fabric as new, fabric-wide
             N_PORT addresses are assigned."




     Monia, et-al            Category - Expiration               [Page 34]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             Isn't the issue in this para the same as that in the first
             para, albeit from the bounded fabric's perspective?  If so,
             suggest merging them.

          Rejected

             Adding a new gateway region is distinct from disrupting an
             existing region and therefore merits its own mention.

          Comment 102.       [E] Section 4.4.3, pp 23, para 4

             ...be done non-disruptively and requires only that new
             gateway's iSNS..."

             Change "that" to "that the".

          Accepted

          Comment 103.       [T] Section 4.5, The iFCP N_PORT Address Model

             b) "A 24-bit N_PORT alias. A fibre channel N_PORT address
                assigned by a gateway operating in address translation mode
                to identify a remotely attached N_PORT. Frame traffic is
                directed to a remotely attached N_PORT by means of the
                N_PORT alias."

             At any point in time, there can only be 2^24 N_PORTs
             communicating even in the address translation mode, even though
             this mode allows the same N_PORT to be mapped to different
             nports in different gateway regions at different times.  If
             this is a correct interpretation, I suggest that this be made
             clear in section 4.4.2, which currently simply states that
             there are no architectural limitations on the number of fibre
             channel devices in this mode.

          Accepted in Part

             While the addressability in a given gateway region is
             constrained by the fibre channel address model, the aggregate
             addressability of all gateway regions comprising an unbounded
             iFCP fabric can exceed that limit.

             To make this clearer, the text will be changed as follows:

             b) "Since N_PORT fibre channel addresses in an unbounded iFCP
                fabric are not fabric-wide, the number of iFCP gateways,
                fibre channel devices and switch elements that may be
                internetworked may exceed the fibre channel fabric limits."

          Comment 104.       [E] Section 4.6.1, pp 25, para 4

             "In its role as principal switch within the gateway region, an
             iFCP..."

     Monia, et-al            Category - Expiration               [Page 35]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             General comment - Change to "...as the Principal Switch...".

          Accepted

          Comment 105.       [T] Section 5.2.1, pp 30, para 4

             "...A gateway implementation MAY establish a pool of unbound
             connections to reduce the session setup time.  Such pre-
             existing TCP connections between iFCP Portals remain unbound
             and uncommitted until allocated to an iFCP session through a
             CBIND message"

             I wonder if there is a scope for DoS attack here with the
             possibility of one gateway potentially holding onto several
             unused TCP connections infinitely...."

          Response

             No. However, the specification will be modified to point out
             that a gateway may recover resources at any time by simply
             closing unbound connections. See Comment 21.

          Comment 106.       [E] Section 5.2.2.1, pp31, para 6

             "If a descriptor does not exist, one SHALL be created in
             response to an iSNS name server query."

             Did you mean "SHALL be created after the response to an iSNS
             name server query is received"?

          Response

             The test will be changed to:

             "If a descriptor does not exist, one SHALL be created using the
             information returned by an iSNS name server query."

          Comment 107.       [E] Section 5.2.2.1.1,  pp 31, para 1

             "A Remote N_PORT descriptor SHALL only be updated as the result
             of an iSNS query that returns information for the specified
             worldwide port name. Following such an update, a new N_PORT
             alias SHALL NOT be assigned."

             I assume you meant "iSNS response" instead of "iSNS query"?

             I am a little confused by the SHALL NOT.  Here's what I was
             assuming as the sequence of events

             1. Local FC Name Server query.

             2. iFCP gateway picks it up.


     Monia, et-al            Category - Expiration               [Page 36]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             3. Consults with iSNS server

             4. iSNS provides the remote N_PORT for the WWN

             5. iFCP gateway assigns a local alias if in translation mode
                and if the remote N_PORT ID  clashes with a pre-existing
                local NPORT_ID.

             I do not see why this sequence should be prohibited. Comments
             will certainly help.

          Accepted in Part

             The text will be modified as described in Comment 108.

             The 24-bit N_PORT component of the remote N_PORTs address and
             its local alias can never clash.  The gateway transparently
             converts the alias to a network address, consisting of the TCP
             connection I/D, TCP Port number and the N_PORT ID assigned by
             the remote gateway.

          Comment 108.       [T] Section 5.2.2.1.1, pp 31, para 1

             "A Remote N_PORT descriptor SHALL only be updated as the result
             of an iSNS query that returns information for the specified
             worldwide port name. Following such an update, a new N_PORT
             alias SHALL NOT be assigned.

             "Until such an update occurs, the contents of a descriptor may
             become stale as the result of any event that invalidates or
             triggers a change in the N_PORT network address of the remote
             device, such as a fabric reconfiguration or the device's
             removal or replacement."

             I assume that generally what is meant by "Until such an update
             occurs" is "In the absence of an operational iFCP session based
             on a descriptor". If so, it perhaps requires rewording.

          Accepted in Part

             Descriptors are only built and updated as a consequence of name
             server requests or state change notifications.  An iFCP session
             may not necessarily be associated with these activities.

             The text will be reworded as shown below to add the state
             change case and clarify the order of events leading to a stale
             descriptor.

             "A Remote N_PORT descriptor SHALL only be updated as the result
             of an iSNS query to obtain information for the specified
             worldwide port name or from information returned by an iSNS
             state change notification. Following such an update, a new
             N_PORT alias SHALL NOT be assigned.

     Monia, et-al            Category - Expiration               [Page 37]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             "Before such an update, the contents of a descriptor may have
             become stale as the result of any event that invalidates or
             triggers a change in the N_PORT network address of the remote
             device, such as a fabric reconfiguration or the device's
             removal or replacement."

          Comment 109.       [E] Section 5.2.2.1.1, pp 31, para 4

             "Once the originating N_PORT learns of the reconfiguration,
             usually through the name server state change notification
             mechanism, the name server lookup needed to reestablish the
             iFCP session will automatically purge such stale data from the
             gateway."

             Just a clarification here - it seems to me that the SCN for a
             remote N_PORT ID needs to delivered via the iFCP gateway
             anyway, so why not purge the stale mapping then (instead of
             waiting for the new SNS query from the local N_PORT?

          Accepted

             The text will be changed to:

             "Once the originating N_PORT learns of the reconfiguration,
             usually through the name server state change notification
             mechanism, information returned in the notification or the
             subsequent name server lookup needed to reestablish the iFCP
             session will automatically purge such stale data from the
             gateway."

          Comment 110.       [T] Section 5.2.2.2, pp 33

             f) "A CBIND response with a CBIND STATUS of "N_PORT session
                already exists" indicates that the remote gateway has
                concurrently..."

             I think the document should specify that this status be mapped
             to the LS_RJT reason code of "Login/command already in
             progress" - 0x0E. Also, there may be N_PORTs that go down
             without issuing a LOGO, and attempt a PLOGI once they come back
             - unbeknownst to the iFCP gateway still with the old session
             descriptor.  It isn't clear to me how this is proposed to be
             dealt with.

          Rejected

             As described in Comment 15, the specified behavior is meant to
             serve as a tie-breaking mechanism for the establishment of the
             iFCP session. Once the session is established, the PLOGIs from
             each side are sent and processed by the N_PORTs in accordance
             with the PLOGI semantics specified in [FC-FS].



     Monia, et-al            Category - Expiration               [Page 38]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


             A PLOGI after an iFCP session exists is handled in accordance
             with section 7.3.1.7, paragraph 5, which states:

             "As specified in section 5.2.2.2, a PLOGI request addressed to
             a remotely attached N_PORT MUST cause the creation of an iFCP
             session if one does not exist. Otherwise, the PLOGI and PLOGI
             ACC payloads MUST be passed transparently to the destination
             N_PORT using the existing iFCP session."

             Section 5.2.2.2 will be modified to describe the simultaneous
             PLOGI scenario above and the case of a PLOGI issued when an
             iFCP session exists.

          Comment 111.       [T] Section 5.2.2.3, pp 35

             b) "An LTEST message is not received within twice the
                specified interval or the iFCP session has been quiescent
                for longer than twice the specified interval."

             I think "or" above should be "and" - else it implies that the
             LTEST message must be received periodically even in the
             presence of other traffic.

          Rejected

             See Comment 18.

             If liveness testing was requested for an iFCP session, an LTEST
             message must be received within twice the specified interval
             regardless of whether or not other traffic is present.

          Comment 112.       [T] Section 5.2.3, pp 37

             a) "An LS_RJT response is returned to the gateway that issued
                the PLOGI ELS. The gateway SHALL forward the LS_RJT to the
                local N_PORT and complete the session as described in..."

             My reading is that the gateway does not "issue" the PLOGI ELS,
             it merely facilitates the transport of an issued PLOGI ELS.
             The wording here is a little confusing - I also believe that
             the forwarding should be to the remote N_PORT, not local.

             [Also,] I recommend "terminate"/"close" in all the places
             "complete" is used.

          Accepted

             The text will be modified as follows:

             a) "An LS_RJT response is returned to the gateway from which
                the PLOGI ELS originated. That gateway SHALL forward the
                LS_RJT to the locally attached N_PORT and terminate the
                session as described in..."

     Monia, et-al            Category - Expiration               [Page 39]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


          Comment 113.       [E] Section 5.2.3.1, pp 37, para 2

             "Unbind session control ELS as described in section 6.2."

             I am a little confused about the status of Unbind here - is it
             a FC-FS approved ELS or an iFCP session control message?

          Response

             Since Unbind is an iFCP session control message, the text will
             be changed to:

             "Unbind session control message as described in section 6.2."

          Comment 114.       [T] Section 5.2.3.2, pp 38, para 4

             "In any event, the TCP connection SHOULD be terminated with a
             connection reset (RST). If the local N_PORT has logged in to
             the remote N_PORT, the gateway SHALL send a LOGO to the local
             N_PORT."

             I think the draft should specify both OPEN and OPEN PENDING
             cases here.  For OPEN state, a local LOGO is required as
             stated, whereas for OPEN PENDING, a local LS_RJT may be
             appropriate.

             Also, it is useful to state that the proxied ELS (in either
             case) be indistinguishable from the end-to-end ELS in its
             payload (so any sanity checking done by endnode software would
             continue to work).

          Accepted

          Comment 115.       [T] Section 5.4.1, pp 40

             "Protocol# IANA-assigned protocol number identifying the
             protocol using the encapsulation. For iFCP the value is
             (/TBD/)."

             Should FCEncap document be referred here instead?

          Accepted

             See Comment 23.

          Comment 116.       [E] Section 5.4.3, pp 43, para 2

             "Following frame validation, the S_ID and D_ID fields in the
             frame header SHALL be referenced to lookup the iFCP session
             descriptor (see section 5.2.2.2). If no iFCP session descriptor
             exists, the frame SHALL be discarded."

             With the exception of PLOGI?

     Monia, et-al            Category - Expiration               [Page 40]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


          Accepted

             The specification will be modified to address the case where a
             frame triggers the creation of an iFCP session.

          Comment 117.       [E] Section 5.4.3, pp 43, para 3

             "Frames types submitted for encapsulation and forwarding on the
             IP..."

             "Frames" should be "Frame".

          Accepted

          Comment 118.       [E] Section 6, pp 44, para 1

             "TCP session control messages are used to create and manage an
             iFCP session as described in section 5.2.2. They are passed
             between peer iFCP Portals and are only processed within the
             iFCP layer.

             "The message format is based on the fibre channel extended link
             service message template shown below...."

             It may be useful to state that this message forms the "FC
             Frame" payload. of the iFCP frame. It may also be useful to
             state the value of LS_COMMAND in the encap header (0?).

             Instead of having two LS_COMMAND fields - one in the header and
             one in the payload - for these messages, a simpler approach
             could be to state that LS_COMMAND in the header contains an
             iFCP-defined value when SES=1 (and remove the one in the
             payload).

          Accepted in Part

             In accordance with Comment 26, the mnemonic for the LS_COMMAND
             field in the encapsulation header will be changed to eliminate
             confusion as follows:

             From section 5.4, Encapsulation of Fibre Channel Frames:

              "LS_COMMAND_ACC   For a special link service ACC
                                response to be processed by iFCP, the
                                LS_COMMAND_ACC field SHALL contain
                                bits 31 through 24 of the LS_COMMAND
                                to which the ACC applies. Otherwise
                                this field shall be set to zero."



             From section 6, TCP Session Control Messages:


     Monia, et-al            Category - Expiration               [Page 41]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


              LS_COMMAND_ACC    0



             With the addition of the new mnemonic, the above text clearly
             specifies how the field is to be set.

          Comment 119.       [E] Section 6.1, pp 46, para 2

             "The following shows the format of the CBIND request."

             I take it that this CBIND structure goes into the Session
             Control Message starting from word 6?  Same question on CBIND
             response.

          Rejected

             That is correct.  The existing text seems to explain this
             adequately.

          Comment 120.       [T] Section 6.2, pp 49, para 1

             "UNBIND is used to release a bound TCP connection and.
             optionally, return it to the pool of unbound TCP connections."

             I assume "release" here implies - "remove the binding"?

             Is there a way to convey the preference to not terminate the
             connection on the part of the sender?  IOW, where is the
             optionality selected?

          Response

             See Comment 21 regarding the disposition of "unbound" TCP
             connections.  The above paragraph will be expanded to clarify
             the rationale for the unbound connection pool as follows:

             "UNBIND is used to terminate an iFCP session and disassociate
             the TCP connection. To expedite the creation of a new iFCP
             session, the TCP connection MAY remain open at the discretion
             of either gateway and kept in a pool of unbound connections.

             In order to recover resources, either gateway may spontaneously
             close the unbound TCP connection at any time."

          Comment 121.       [E] Section 6.2, pp 50, para 1

             "transmitted in the connection that is to be unbound. The
             time..."

             Change "in" to "on".

          Accepted

     Monia, et-al            Category - Expiration               [Page 42]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


          Comment 122.       [T] Section 8.2.1, pp 76, para 1

             "The R_A_TOV limit on frame lifetimes SHALL be enforced by
             means of the time stamp in the encapsulation header (see
             section 5.4.1 ) as described in this section."

             A couple of general questions on this section -

             a) Is Unsynchronized operation allowed?  If so, how is the
                R_A_TOV expectation met?

             b) If an incorrect configuration causes the timestamp of the
                incoming frame to be higher than the gateway's time base, it
                is better if there is a way to detect and perhaps resync
                both ends with the same SNTP server (as opposed to one out
                of a list returned by iSNS).  As far as I can tell, the
                current text specifies that it would simply cause the frames
                to be discarded, but doesn't break the binding nor terminate
                the TCP connection - perhaps relying on the end nodes to
                LOGOUT?

          Accepted in Part

             For item a), see the response to Comment 35.

             For item b), iFCP specifies the following behavior:

             d) "If the incoming frame has a non-zero time stamp, the
                receiving gateway SHALL compute the absolute value of the
                time in flight and SHALL compare it against the value of
                IP_TOV specified for the IP fabric.

             e) "If the result in step (d) exceeds IP_TOV, the encapsulated
                frame shall be discarded.  Otherwise, the frame shall be
                de-encapsulated as described in section ...."

             Since it is impossible to guarantee that one time reference
             won't be skewed negatively with respect to the other. the
             propagation delay test is against the absolute value of the
             time difference.

             The iFCP spec will be modified to state that an iFCP gateway
             implementation MAY terminate an iFCP session if the rate at
             which stale frames are detected exceeds some administratively-
             specified threshold.

     6. Security Considerations

        The applicable security provisions are defined in [IFCP].

     7. References

         [RFC2026] Bradner, S., "The Internet Standards Process -- Revision

     Monia, et-al            Category - Expiration               [Page 43]


                 Responses to iFCP Rev. 10  Last Call Comments    May 2002


                 3", BCP 9, RFC 2026, October 1996.

         [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997

         [IFCP] Monia, C., et al, ö iFCP - A Protocol for Internet Fibre
                 Channel Storage Networking", draft-ietf-ips-ifcp-10.txt,
                 February 2002

         [FC-FS] dpANS INCITS.XXX-200X, "Fibre Channel Framing and Signaling
                 Interface", Revision 1.7, NCITS Project 1331-D, February
                 2002

         [SECIPS] Aboba, B., et-al., "Securing Block Storage Protocols Over
                 IP", revision 11, February 2002

         [FC-GS3] dpANS X3.XXX-200X, "Fibre Channel Generic Services -3 (FC-
                 GS3)", revision 7.01, NCITS Project 1356-D, November 2000



8. Author's Addresses

        Charles Monia                Franco Travostino
        Josh Tseng                   Director, Content
                                      Internetworking Lab,
        Nishan Systems               Nortel Networks
        3850 North First Street      3 Federal Street
        San Jose, CA  95134          Billerica, MA  01821
        Phone: 408-519-3986          Phone:  978-288-7708
        Email:                       Email:
        cmonia@nishansystems.com     travos@nortelnetworks.com



Full Copyright Statement

   "Copyright (C) The Internet Society May 2002. All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.



     Monia, et-al            Category - Expiration               [Page 44]


            Responses to iFCP Rev. 10  Last Call Comments    May 2002


   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."













































Monia, et-al            Category - Expiration               [Page 45]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/