home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / iscsiprj.zip / draft-ietf-ips-ifcp-wglcc-00.txt < prev    next >
Text File  |  2002-06-02  |  103KB  |  2,655 lines
  1.  
  2.  
  3.      IPS                                                            C. Monia
  4.                                                                F. Travostino
  5.                                                                     J. Tseng
  6.      Internet Draft                                           Nishan Systems
  7.      Document: draft-ietf-ips-ifcp-wglcc-00.txt                     May 2002
  8.      Category: Informational
  9.  
  10.  
  11.                   Responses to iFCP Rev. 10  Last Call Comments
  12.  
  13.      Status of this Memo
  14.  
  15.         This document is an Internet-Draft and is in full conformance with
  16.         all provisions of Section 10 of [RFC2026].
  17.  
  18.         Internet-Drafts are working documents of the Internet Engineering
  19.         Task Force (IETF), its areas, and its working groups. Note that
  20.         other groups may also distribute working documents as Internet-
  21.         Drafts. Internet-Drafts are draft documents valid for a maximum of
  22.         six months and may be updated, replaced, or obsoleted by other
  23.         documents at any time. It is inappropriate to use Internet- Drafts
  24.         as reference material or to cite them other than as "work in
  25.         progress."
  26.  
  27.         The list of current Internet-Drafts can be accessed at
  28.         http://www.ietf.org/ietf/1id-abstracts.txt
  29.  
  30.         The list of Internet-Draft Shadow Directories can be accessed at
  31.         http://www.ietf.org/shadow.html.
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.      Monia, et-al            Category - Expiration                [Page 1]
  59.  
  60.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  61.  
  62.  
  63.      Status of this Memo...................................................1
  64.      Abstract..............................................................3
  65.      Change Log............................................................3
  66.      1.   Conventions used in this document...............................3
  67.      2.   Comments from David Black.......................................3
  68.      3.   Comments From Elizabeth Rodriguez..............................21
  69.      4.   Comments from Brian Forbes.....................................25
  70.      5.   Comments from Mallikarjun Chadalapaka..........................30
  71.      6.   Security Considerations........................................43
  72.      7.   References.....................................................43
  73.      8.   Author's Addresses.............................................44
  74.      Full Copyright Statement.............................................44
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.      Monia, et-al            Category - Expiration                [Page 2]
  118.  
  119.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  120.  
  121.  
  122.  
  123.      Abstract
  124.  
  125.         This document is a compilation of responses to review comments
  126.         received for revision 10 if the iFCP specification [IFCP] during the
  127.         preliminary last call period from 3/4/2002 to 3/18/2002.
  128.  
  129.      Change Log
  130.  
  131.         Revision 0 of draft-monia-ips-ifcplcc-00 to draft-ietf-ips-ifcp-
  132.         wglcc-00.txt, revision 0.
  133.  
  134.         Comment 49 -- Modified to comply with IESG policy on number of co-
  135.         authors.
  136.  
  137.         Modified the following responses per feedback from David Black and
  138.         Mallikarjun Chadalapaka.
  139.  
  140.         Comment 5,
  141.         Comment 12,
  142.         Comment 94,
  143.         Comment 104,
  144.         Comment 110.
  145.         Comment 120
  146.  
  147.      1. Conventions used in this document
  148.  
  149.         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  150.         "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
  151.         this document are to be interpreted as described in [RFC2119].
  152.  
  153.         In the following, [E] designates an editorial comment, [T] a
  154.         technical comment.
  155.  
  156.         The keywords 'Rejected' or 'Accepted' indicate fundamental agreement
  157.         or disagreement with the position stated in the comment.
  158.  
  159.         The keyword 'Response' is used when a comment is predicated on a
  160.         query. The explanatory text should be consulted for details.
  161.  
  162.      2. Comments from David Black
  163.  
  164.           Comment 1. [E} Page 5, Change Log
  165.  
  166.              Remove Change Log in the version after a successful WG Last
  167.              Call.
  168.  
  169.           Accepted
  170.  
  171.           Comment 2. [E] Section 2.1, page 7, paragraph 1
  172.  
  173.              "Terms needed to clarify the concepts presented in this
  174.              document are presented here."
  175.  
  176.      Monia, et-al            Category - Expiration                [Page 3]
  177.  
  178.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  179.  
  180.  
  181.              I don't like the usage of "clarify".  How about "Terms used to
  182.              describe the concepts presented in this document are defined
  183.              here." ?
  184.  
  185.           Accepted
  186.  
  187.              The text will be revised as suggested.
  188.  
  189.           Comment 3. [E] Section 2.1, Address Translation Mode Definition
  190.  
  191.              Some tool has helpfully inserted non-ASCII characters.  MS Word
  192.              AutoCorrect is a likely suspect.  Hunt all of these down and
  193.              fix them, then discipline the tool severely ;-).
  194.  
  195.           Accepted.
  196.  
  197.           Comment 4. [T] Section 2.1, Definition of FC-4 Layer
  198.  
  199.              "FC-4 - The fibre channel application layer. This layer is
  200.              functionally equivalent to the TCP/IP application layer."
  201.  
  202.              I don't understand this.  Are you equating FC-4 with OSI layer
  203.              7?  If so, I'm not sure that is correct, and it might be better
  204.              to leave out this attempted analogy.
  205.  
  206.           Accepted
  207.  
  208.              The definition will be changed to:
  209.  
  210.              "FC-4 - The fibre channel mapping of an upper level protocol,
  211.              such as [FCP-2], the fibre channel SCSI mapping."
  212.  
  213.           Comment 5. [T] Section 3.2, page 10
  214.  
  215.              a) "Arbitrated Loop -- A series of N_PORTs connected together
  216.                in daisy-chain fashion.  Data transmission between N_PORTs
  217.                requires arbitration for control of the loop in a manner
  218.                similar to a token ring network."
  219.  
  220.              That's not a fabric topology, unless the loop is fabric
  221.              attached, in which case you're in case c), Mixed Fabric. iFCP
  222.              can't support an FC-AL loop that isn't fabric-attached.
  223.  
  224.           Accepted in part
  225.  
  226.              The terminology will be changed to "fibre channel network
  227.              topologies".
  228.  
  229.              In addition, the following definition will be added:
  230.  
  231.              "Fabric -- From [FC-FS]: "The entity which interconnects
  232.              N_PORTs attached to it and is capable of routing frames by
  233.              using only the address information in the fibre channel frame."
  234.  
  235.      Monia, et-al            Category - Expiration                [Page 4]
  236.  
  237.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  238.  
  239.  
  240.              With regard to FC-AL support, an iFCP gateway implementation
  241.              can emulate either a public (fabric attached) or private loop
  242.              environment. The gateway may support a private loop by
  243.              representing remotely attached devices as if they were resident
  244.              on a local loop and by emulating the semantics required to
  245.              support the loop control frames and primitives. Since these
  246.              functions are implemented internally by the gateway, iFCP
  247.              protocol support is not required.  However, the specification
  248.              should explicitly prohibit the forwarding of fibre channel loop
  249.              control frames via iFCP.
  250.  
  251.              A related issue is support for the set of extended link
  252.              services for remote loop control, such as LINIT (Loop
  253.              Initialize).  These are standard link service messages
  254.              addressed to the loop fabric address (LFA) of the FL port
  255.              controlling the loop. A gateway that chooses to expose remote,
  256.              loop-connected devices as NL_Ports must also expose the LFA.
  257.              To do so, it should assign the local alias such that the
  258.              corresponding LFA or the remote loop can be derived by setting
  259.              the port_id component of the alias to zero in accordance with
  260.              [FC-FS].
  261.  
  262.              The specification will be modified to discuss these loop
  263.              topology support issues.
  264.  
  265.           Comment 6. [T] Section 3.2, page 11, para 5
  266.  
  267.              "Depending on the topology, the N_PORT and fabric port variants
  268.              through which a fibre channel device is attached to the network
  269.              may be one of the following:
  270.  
  271.              "Fabric Topology  Fabric Port Type    N_PORT Variant
  272.              ---------------  ----------------    --------------
  273.  
  274.              Loop             L_PORT              NL_PORT
  275.              Switched         F_PORT              N_PORT
  276.              Mixed            FL_PORT             NL_PORT
  277.                               F_PORT              N_PORT"
  278.  
  279.              I believe the Loop line in this table does not match the other
  280.              lines and if so, this is one more reason to leave non-fabric-
  281.              attached FC-AL out of this description.
  282.  
  283.           Accepted in part
  284.  
  285.              Since the loop topology can be supported, it should remain in
  286.              the table. However, the terminology should be changed per
  287.              Comment 5 and the table modified as shown below:
  288.  
  289.              "FC Network Topology   N_PORT Variant     FC Network Interface
  290.              --------------------   --------------     --------------------
  291.  
  292.  
  293.  
  294.      Monia, et-al            Category - Expiration                [Page 5]
  295.  
  296.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  297.  
  298.  
  299.              Loop                   NL_PORT           L_PORT
  300.              Switched               N_PORT            F_PORT
  301.              Mixed                  NL_PORT           FL_PORT via L_PORT"
  302.  
  303.              In the case of a mixed fabric, additional supporting text will
  304.              be provided.
  305.  
  306.           Comment 7. [E] Section 3.3.1, page 14, para 2
  307.  
  308.              "All switched fabrics must provide the following services:
  309.  
  310.              "Fabric F_PORT server ô Services an N_PORT request to access
  311.              the fabric for communications.
  312.  
  313.              Change "request" to "requests"
  314.  
  315.           Accepted
  316.  
  317.              Replace special character and reword as follows:
  318.  
  319.              "Fabric F_PORT server -- Services N_PORT requests to access the
  320.              fabric for communications."
  321.  
  322.           Comment 8. [E] Section 4.4, page 21, para 2
  323.  
  324.              "As discussed below, an unbounded iFCP fabric may have any
  325.              number of switch elements and gateways."
  326.  
  327.              It's not "any", but the limit is a very large number by
  328.              comparison to 239.
  329.  
  330.           Accepted
  331.  
  332.              The sentence will be changed to:
  333.  
  334.              "As discussed below, an unbounded iFCP fabric is not limited to
  335.              239 switches and gateways."
  336.  
  337.           Comment 9. [T] Section 4.4 - iFCP Fabric Properties
  338.  
  339.              At some point the need to reuse 24-bit addresses for outbound
  340.              traffic from a single FC link behind an iFCP gateway will be a
  341.              problem.  This comment also applies to the second paragraph in
  342.              Section 4.4.2.
  343.  
  344.           Accepted
  345.  
  346.              A discussion of address re-use issues will be added to the
  347.              spec.
  348.  
  349.           Comment 10.        [E] Section 4.5, page 23, para 2
  350.  
  351.  
  352.  
  353.      Monia, et-al            Category - Expiration                [Page 6]
  354.  
  355.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  356.  
  357.  
  358.              "In the iFCP protocol, an N_PORT is represented by the
  359.              following addresses:"
  360.  
  361.              Change "addresses" to "types of addresses" to avoid implying
  362.              that there's only one alias.  Different gateways will assign
  363.              different aliases to the same N_PORT.
  364.  
  365.           Rejected
  366.  
  367.              The description of an alias will be revised as follows:
  368.  
  369.              b) "A 24-bit N_PORT alias. The fibre channel N_PORT address
  370.                 assigned by each gateway operating in address translation
  371.                 mode to identify a remotely attached N_PORT.
  372.  
  373.                 Frame traffic is intercepted by an iFCP gateway and
  374.                 directed to a remotely attached N_PORT by means of the
  375.                 N_PORT alias.  The address assigned by each gateway is
  376.                 unique within the scope of the gateway region."
  377.  
  378.           Comment 11.        [T] Section 4.5, pp 24, para 14
  379.  
  380.              "The mode of gateway operation is settable in an
  381.              implementation-specific manner.  The implementation MUST NOT
  382.              allow the mode to be changed after the gateway begins
  383.              processing fibre channel frame traffic."
  384.  
  385.              Might want to add a MUST that a gateway cannot operate in more
  386.              than one mode at the same time, and a repeat of the (implied)
  387.              requirement that all gateways in an iFCP fabric MUST operate in
  388.              the same mode.
  389.  
  390.           Accepted
  391.  
  392.           Comment 12.        [T] Section 4.6. pp 24, para 2
  393.  
  394.              b) "When interoperating with locally attached fibre channel
  395.                 switch elements, each iFCP gateway MUST assume control of
  396.                 DOMAIN_ID assignments in accordance with the appropriate
  397.                 fibre channel standard or vendor-specific protocol
  398.                 specification."
  399.  
  400.              This is ok, but turns up another requirement that needs to be
  401.              explicitly stated earlier.  Any given FC N_PORT MUST NOT be
  402.              behind more than one iFCP gateway.  Address Transparent mode
  403.              satisfies this because only one gateway can become the
  404.              principal switch, so the others presumably shut down, but
  405.              Address Translation mode appears to have the potential for
  406.              seriously nasty misbehavior unless the "iFCP gateway MUST
  407.              become the principal switch" requirement is imposed on it also.
  408.              Need to add a sentence or two on how an iFCP gateway can be
  409.              assured of becoming the principal switch.  Beyond this, the
  410.              fact that any Fabric Attached FC-AL loop can have only one FL
  411.  
  412.      Monia, et-al            Category - Expiration                [Page 7]
  413.  
  414.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  415.  
  416.  
  417.              port completes the picture, ensuring that a loop can't stitch
  418.              two gateway domains together.  Requiring the iFCP gateway to be
  419.              the principal switch also avoids problems with the gateway
  420.              being unable to obtain sufficient Domain IDs from the principal
  421.              switch.
  422.  
  423.           Accepted in Part
  424.  
  425.              An N_PORT can be behind more than one gateway if the following
  426.              rules are observed:
  427.  
  428.              a)  The gateways MUST cooperate in the assignment of N_PORT IDs
  429.                  for locally attached devices and aliases for remotely
  430.                  attached devices such that each local or remotely attached
  431.                  N_PORT has one and only one N_PORT address within the scope
  432.                  of the gateway region.
  433.  
  434.              b)  All iFCP frame traffic between any two N_PORTs MUST flow
  435.                  through a single iFCP session.  However, each session may
  436.                  traverse a different gateway attached to the region.
  437.  
  438.              In order to meet these constraints, a multi-gateway
  439.              implementation may require an out of band mechanism for
  440.              redirecting frame traffic from one physical gateway to another.
  441.  
  442.              The above will be added to the specification.
  443.  
  444.           Comment 13.        [T] Section 5.2.2.2, pp 32, para 4
  445.  
  446.              "The gateway SHALL initiate the creation of an iFCP session in
  447.              response to a PLOGI ELS directed to a remote N_PORT from a
  448.              locally attached N_PORT as described in the following steps.
  449.  
  450.              a) "Using the D_ID field in the PLOGI frame header, locate the
  451.                 remote N_PORT descriptor.  If no descriptor exists, the iFCP
  452.                 gateway SHALL return a response of LS_RJT, with a Reason
  453.                 Code of 'Unable to Perform Command Request' (0x09) and a
  454.                 Reason Code Explanation of 'Invalid N_PORT_ID' (0x1F). An
  455.                 iFCP session SHALL NOT be created."
  456.  
  457.              Need to explain why this is ok.
  458.  
  459.              The answer is that a properly operating FC N_PORT will have
  460.              previously issued an FC nameserver query that the gateway
  461.              translated to an iSNS query, and hence when it issues PLOGI to
  462.              the result of the nameserver query, the iSNS query response
  463.              created the required descriptor in the gateway before being
  464.              translated to the FC nameserver result.  There's an implication
  465.              here that remote N_PORT descriptors that result from iSNS
  466.              queries translated from FC nameserver queries MUST NOT be
  467.              discarded as long as any N_PORT that has issued a query for
  468.              that remote N_PORT is logged into the fabric.
  469.  
  470.  
  471.      Monia, et-al            Category - Expiration                [Page 8]
  472.  
  473.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  474.  
  475.  
  476.           Accepted in part
  477.  
  478.              Although a name server query is almost always done in practice
  479.              prior to a PLOGI, an N_PORT compliant with [FC-FS] is not
  480.              required to do so. For that reason, the specification should
  481.              cover the case where a fibre channel device attempts to send
  482.              frames to an address without having executed a previous name
  483.              server query.
  484.  
  485.              Also, while the policies for remote N_PORT descriptor retention
  486.              are implementation-specific, the specification should at least
  487.              contain recommendations. In that regard, the following added
  488.              text is proposed:
  489.  
  490.              "Remote N_PORT Descriptors should be reclaimed based on a last
  491.              in, first out policy.
  492.  
  493.              "An iFCP implementation should have sufficient resources to
  494.              insure that a newly created descriptor is not reclaimed before
  495.              the referencing iFCP session is created."
  496.  
  497.           Comment 14.         [E] Section 5.2.2.2 - Creating an iFCP Session
  498.  
  499.              e) "If a CBIND response is returned with one of the following
  500.                statuses, the PLOGI SHALL be terminated with an LS_RJT
  501.                message. Depending on the CBIND failure status, the Reason
  502.                Code and Reason Explanation SHALL be set to the following
  503.                values specified in [FC-FS]."
  504.  
  505.              Add a statement that this plus case f) is a comprehensive list
  506.              of possible CBIND failure statuses, as specified in Section
  507.              6.1.
  508.  
  509.           Accepted
  510.  
  511.           Comment 15.        [E] Section 5.2.2.2 - Creating an iFCP Session
  512.  
  513.              f) "A CBIND response with a CBIND STATUS of "N_PORT session
  514.                already exists" indicates that the remote gateway has
  515.                concurrently initiated a CBIND request to create an iFCP
  516.                session between the same pair of N_PORTs. The receiving
  517.                gateway SHALL terminate this attempt, return the connection
  518.                to the Unbound state and prepare to respond to an incoming
  519.                CBIND request as described below."
  520.  
  521.              Add a sentence indicating that the "simultaneous open" race is
  522.              dealt with by allowing the sender with the numerically larger
  523.              N_PORT name to succeed in establishing the session.
  524.  
  525.           Accepted
  526.  
  527.           Comment 16.        [E] Section 5.2.2.2, pp 34, para 2
  528.  
  529.  
  530.      Monia, et-al            Category - Expiration                [Page 9]
  531.  
  532.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  533.  
  534.  
  535.              "The gateway receiving a CBIND request SHALL respond as
  536.              follows:
  537.  
  538.              a) "If the receiver has a duplicate iFCP session in the OPEN
  539.                 PENDING state, then the receiving gateway SHALL compare the
  540.                 Source N_PORT Name in the incoming CBIND payload with the
  541.                 Destination N_PORT Name."
  542.  
  543.              b) "If the Source N_PORT Name is greater, the receiver SHALL
  544.                 issue a CBIND response of "Success" and SHALL place the
  545.                 session in the OPEN state."
  546.  
  547.              Add a sentence indicating that in case b), case c) will occur
  548.              at the other gateway because N_PORT names are globally unique
  549.              WWNs, and hence this gateway's duplicate session will receive a
  550.              CBIND STATUS of "N_PORT session already exists" and will be
  551.              terminated in due course.
  552.  
  553.           Accepted
  554.  
  555.           Comment 17.        [T] Section 5.2.2.2 - Creating an iFCP Session
  556.  
  557.              There's no discussion of what to do if a TCP connection closes
  558.              unexpectedly during this process (e.g., if closing of unbound
  559.              connections is allowed at arbitrary times for reasons such as
  560.              reducing the resources consumed by unbound connections).  This
  561.              needs to be added even if the reason in parentheses is not
  562.              allowed.
  563.  
  564.           Accepted
  565.  
  566.           Comment 18.        [T] Section 5.2.2.2, pp 35, para 4
  567.  
  568.              "Upon receiving such a request, the gateway providing the
  569.              connectivity probe SHALL transmit LTEST messages at the
  570.              specified interval."
  571.  
  572.              This requires liveness test (LTEST) messages even when the
  573.              connection is in active use.  Was that intended?
  574.  
  575.           Response
  576.  
  577.              The intent is to require LTEST messages at the specified
  578.              interval regardless of whether or not there is other traffic.
  579.  
  580.           Comment 19.        [E] Section 5.2.2.4 - Use of TCP Features and
  581.              Settings
  582.  
  583.              For Wrapped sequence detection, "Should use" in the table
  584.              should be "SHOULD use".
  585.  
  586.           Accepted
  587.  
  588.  
  589.      Monia, et-al            Category - Expiration               [Page 10]
  590.  
  591.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  592.  
  593.  
  594.           Comment 20.        [T] Section 5.2.3.1, pp 38, para 1
  595.  
  596.              "In response to the Unbind message, either gateway may choose
  597.              to close the TCP connection or return it to a pool of unbound
  598.              connections."
  599.  
  600.              This assumes that Unbind is always successful.  It can fail, as
  601.              documented in Section 6.2.  Need to specify how to deal with
  602.              this (e.g., close the TCP connection).
  603.  
  604.           Accepted
  605.  
  606.              The sentence will be modified as follows:
  607.  
  608.              "Upon successful completion of an Unbind operation, either
  609.              gateway may choose to close the TCP connection or return it to
  610.              a pool of unbound connections."
  611.  
  612.              The processing for the failure cases will also be specified.
  613.  
  614.           Comment 21.        [T] Section 5.2.3.1 - iFCP Session Completion
  615.  
  616.              Can an iFCP gateway reduce the pool of unbound connections
  617.              (e.g., due to demands for resources for other connections),
  618.              possibly by closing them?  If yes, need to say so.
  619.  
  620.           Accepted
  621.  
  622.              A gateway may close an unbound connection due to resource
  623.              demands.  The spec will be modified appropriately.
  624.  
  625.           Comment 22.        [E] Section 5.3 - IANA Considerations
  626.  
  627.              Put this near the end of the document where IANA can more
  628.              easily find it.
  629.  
  630.           Accepted
  631.  
  632.           Comment 23.        [T] Section 5.4.1, pp 40, para 1
  633.  
  634.              "Protocol#            IANA-assigned protocol number identifying
  635.              the protocol using the encapsulation.  For iFCP the value is
  636.              (/TBD/)."
  637.  
  638.              It's 2 - cite the FC Encapsulation draft's IANA Considerations
  639.              section as the authority for this.
  640.  
  641.           Accepted
  642.  
  643.           Comment 24.        [E] Section 5.4.2 - SOF and EOF Delimiter
  644.              Fields
  645.  
  646.  
  647.  
  648.      Monia, et-al            Category - Expiration               [Page 11]
  649.  
  650.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  651.  
  652.  
  653.              Need to say that the format is specified in the FC Common
  654.              Encapsulation document and reproduced here for convenience.
  655.  
  656.           Accepted
  657.  
  658.           Comment 25.        [T] Section 5.4.2 - SOF and EOF Delimiter
  659.              Fields
  660.  
  661.              "SOF (bits 31-24 and bits 23-16 in word 0):  iFCP uses the
  662.              following subset of the SOF fields described in [ENCAP].
  663.  
  664.              This is a problem because these codes are being specified in
  665.              more than one place.  I think the FC Frame Encapsulation
  666.              document is the right place for the normative specification of
  667.              these codes (and see my comments against it on the need to get
  668.              IANA involved).  This would be ok as a list of codes that are
  669.              currently valid, but the specification authority needs to be in
  670.              one place.  Same comment applies to EOF.
  671.  
  672.           Accepted in Part
  673.  
  674.              The specification will be revised in accordance with Comment
  675.              24.
  676.  
  677.           Comment 26.        [E] Section 6, pp 46
  678.  
  679.              "LS_COMMAND     For a special link service ACC response to be
  680.              processed by iFCP, the LS_COMMAND field SHALL contain bits 31
  681.              through 24 of the LS_COMMAND to which the ACC applies.
  682.              Otherwise the LS_COMMAND field shall be set to zero."
  683.  
  684.              There's an LS_COMMAND field in figure 16 and a second one in
  685.              the iFCP portion of the FC Common Encapsulation header (from
  686.              Section 5.4.1).
  687.  
  688.              When a single section discusses both fields, as Section 6 does,
  689.              this gets confusing fast.  Please rename the LS_COMMAND field
  690.              in the iFCP portion of the FC Common Encapsulation header to
  691.              something like ACC_LS_COMMAND or LS_COMMAND_ACC.
  692.  
  693.           Accepted
  694.  
  695.              The mnemonic will be changed to LS_COMMAND_ACC.
  696.  
  697.           Comment 27.        [T/E] Section 6 - TCP Session Control Messages
  698.  
  699.              Request              LS_COMMAND Short Name  iFCP Support
  700.              -------              ---------- ----------  -----------
  701.  
  702.              Connection Bind          0xE0       CBIND      REQUIRED
  703.              Unbind Connection        0xE4      UNBIND      REQUIRED
  704.              Test Connection Liveness 0xE5       LTEST      REQUIRED
  705.  
  706.  
  707.      Monia, et-al            Category - Expiration               [Page 12]
  708.  
  709.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  710.  
  711.  
  712.              [T/E] How do we know that those three values (E0, E4, and E5)
  713.              will not conflict with some future usage by Fibre Channel?  I
  714.              think the answer is that SES=1 in the iFCP flags in the header,
  715.              and would be 0 in any future use of these values in an ELS, but
  716.              the use of those three values looks like an attempt to avoid
  717.              conflict and should be explained.
  718.  
  719.           Accepted
  720.  
  721.              That is correct. These values were chosen as patterns readily
  722.              distinguishable by a protocol analyzer.
  723.  
  724.           Comment 28.        [T] 6.2 - Unbind Connection (UNBIND)
  725.  
  726.              "Unbind Status Description
  727.              ------------- -----------
  728.  
  729.                 0        Successful ô No other status
  730.               1 - 15     Reserved
  731.                 16       Failed - Unspecified Reason
  732.                 18       Failed - Connection ID Invalid
  733.              Others      Reserved
  734.  
  735.              "Unbind can fail, but earlier specification of the use of
  736.              Unbind (e.g., in Section 5.2.3.1) assumes that it cannot fail."
  737.  
  738.              Description of how to deal with Failed status needs to be added
  739.              there (e.g., close the TCP connection).
  740.  
  741.           Accepted
  742.  
  743.           Comment 29.        [E] Section 7.2, pp 56, para 7
  744.  
  745.              "For translation type 3, the receiving gateway SHALL obtain the
  746.              information needed to fill in the field in the link service
  747.              frame payload by converting the specified N_PORT worldwide
  748.              identifier to a gateway IP address and N_PORT ID.  This
  749.              information MUST be obtained through an iSNS name server
  750.              query."
  751.  
  752.              This requires an iSNS query for every type 3 translation
  753.              received even if it exists locally in a Remote N_PORT
  754.              descriptor.  It looks like this was intended due to the
  755.              possibility of the descriptor being stale, but I wanted to
  756.              check if that was in fact the intention.
  757.  
  758.           Accepted
  759.  
  760.              The intention was to update a potentially stale entry or force
  761.              the creation of a new descriptor.
  762.  
  763.           Comment 30.        [E] Section 7.2, pp 57, para 3
  764.  
  765.  
  766.      Monia, et-al            Category - Expiration               [Page 13]
  767.  
  768.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  769.  
  770.  
  771.              "When the ACC response requires iFCP intervention, the
  772.              receiving gateway MUST act as a proxy for the originator,
  773.              retaining the state needed to process the response from the
  774.              N_PORT to which the request was directed."
  775.  
  776.              That doesn't parse for me.  I think the intended meaning was
  777.              that when an ELS request is sent whose ACC will require iFCP
  778.              intervention, the ELS also requires intervention to capture the
  779.              state necessary to process the ACC.
  780.  
  781.           Accepted
  782.  
  783.              The text will be modified as follows:
  784.  
  785.              "When the ACC response requires iFCP intervention, the
  786.              receiving gateway MUST intervene to process the response from
  787.              the N_PORT to which the request was directed."
  788.  
  789.           Comment 31.        [T] 7.3 - Fibre Channel Link Services Processed
  790.              by iFCP
  791.  
  792.              "The following Extended and FC-4 Link Service Messages must
  793.              receive special processing."
  794.  
  795.              Process question - how does this list get coordinated with T11
  796.              so that it gets updated when T11 defines a new ELS or FC-4 LS
  797.              that requires iFCP intervention?
  798.  
  799.           Response
  800.  
  801.              The specification must be revised to track the evolving fibre
  802.              channel specifications, including, among other things, the
  803.              addition of new link services that require special processing.
  804.  
  805.           Comment 32.        [T] 7.3.1.1 - Abort Exchange (ABTX)
  806.  
  807.              "Fields Requiring       Translation   Supplemental Data
  808.              Address Translation     Type (see      (type 3 only)
  809.              -------------------    section 7.2)     ------------
  810.                                     -----------
  811.              Exchange Originator        1, 2              N/A
  812.              S_ID"
  813.  
  814.              Need to specify how to choose the translation type.  This
  815.              comment also applies to RES, RES ACC, RLS, RSS, RRQ, RSI, REC
  816.              and REC ACC.  It may be best resolved by adding additional text
  817.              in Section 7.2.
  818.  
  819.           Accepted
  820.  
  821.           Comment 33.        [E] 7.3.1.3 - Discover Address Accept (ADISC
  822.              ACC)
  823.  
  824.  
  825.      Monia, et-al            Category - Expiration               [Page 14]
  826.  
  827.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  828.  
  829.  
  830.              Should the Command field be 0x20 or 0x02?
  831.  
  832.           Response
  833.  
  834.              The command field for all ACC response frames is 0x02.  No
  835.              change to the specification is required.
  836.  
  837.           Comment 34.        [T] 7.3.1.3 - Discover Address Accept (ADISC
  838.              ACC)
  839.  
  840.              "Other Special Processing:
  841.  
  842.              The Hard Address of the ELS originator SHALL be set to 0."
  843.  
  844.              Doesn't this also require setting the LS_COMMAND iFCP-specific
  845.              field (to be renamed) in the FC Common Encapsulation header?
  846.              This comment also applies to all other ACC's in Section 7.
  847.  
  848.           Accepted
  849.  
  850.              The specification will be modified accordingly.
  851.  
  852.           Comment 35.        Section 8.2.1 - Enforcing R_A_TOV Limits
  853.  
  854.              The rules in this section appear to allow forwarding of all
  855.              frames received while in Unsynchronized mode or with a
  856.              timestamp of 0,0.  This looks like  formula for violating
  857.              R_A_TOV - was this intended?
  858.  
  859.           Response
  860.  
  861.              The intention was to abort all iFCP sessions and not allow the
  862.              creation of new ones.  The specification will be revised
  863.              accordingly.
  864.  
  865.           Comment 36.        [T] Section 9.4.1 - Establishing the Broadcast
  866.              Configuration
  867.  
  868.              "The broadcast configuration is managed using facilities
  869.              provided by the iSNS server. Specifically:
  870.  
  871.              a) "An iSNS discovery domain is created and seeded with the
  872.                 network address of the global broadcast server N_PORT.  The
  873.                 global server is identified as such by setting the
  874.                 appropriate N_PORT entity attribute."
  875.  
  876.              There are no means for recovery from failure, so loss of the
  877.              gateway performing the broadcast service results in loss of the
  878.              broadcast service. This needs to be explained at a minimum, and
  879.              probably corrected.
  880.  
  881.           Accepted
  882.  
  883.  
  884.      Monia, et-al            Category - Expiration               [Page 15]
  885.  
  886.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  887.  
  888.  
  889.              An implementation may designate a local server as a standby
  890.              global broadcast server.  The local server uses the LTEST
  891.              message to determine if the global server is functioning and
  892.              may assume control if not.
  893.  
  894.              The specification will be revised accordingly.
  895.  
  896.           Comment 37.        [T] Section 10.2.2, page 82, para 1
  897.  
  898.              "Conformant implementations of the iFCP protocol MAY use such
  899.              security definitions."
  900.  
  901.              I don't understand this sentence.  What was intended?
  902.  
  903.           Accepted
  904.  
  905.              The paragraph will be changed to:
  906.  
  907.              ⌠It is imperative to thwart these attacks, given that an iFCP
  908.              gateway is the last line of defense for a whole fibre channel
  909.              island, which may include several hosts and fibre channel
  910.              switches. To do so, the iFCP gateway must implement and may use
  911.              confidentiality, data origin authentication, integrity, and
  912.              replay protection on a per-datagram basis. The iFCP gateway
  913.              must implement and may use bi-directional authentication of the
  914.              communication endpoints. Finally, it must implement and may use
  915.              a scalable approach to key management.÷
  916.  
  917.           Comment 38.        [T] Section 10.2.3, pp 82, para 1
  918.  
  919.              "Enterprise data center networks are considered mission-
  920.              critical facilities that must be isolated and protected from
  921.              all possible security threats.  Such networks are usually
  922.              protected by security gateways, which at a minimum provide a
  923.              shield against denial of service attacks.  The iFCP security
  924.              architecture is capable of leveraging the protective services
  925.              of the existing security infrastructure, including firewall
  926.              protection, NAT and NAPT services, and IPSec VPN services
  927.              available on existing security gateways."
  928.  
  929.              While this is true of iFCP, iSNS has some serious issues with
  930.              NAT and NAPT and iFCP cannot be operated without iSNS.
  931.  
  932.           Rejected
  933.  
  934.              iSNS issues with NA(P)Ts are thought to be resolved (see
  935.              Section 3.6 in the iSNS specification). iSNS has at least two
  936.              non-exclusive options to cope with NA(P)Ts, a) the use of FQDNs
  937.              instead of IP addresses, and b) the option to establish a
  938.              confederation of iSNS servers and have them doctor IP numbers
  939.              in transit as part of their mutual confederation contract.
  940.  
  941.           Comment 39.        [T] Section 10.2.4, pp 82, para 1
  942.  
  943.      Monia, et-al            Category - Expiration               [Page 16]
  944.  
  945.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  946.  
  947.  
  948.              "iFCP gateways MUST use Discovery Domain information obtained
  949.              from the iSNS server [ISNS] to determine whether the initiating
  950.              fibre channel N_PORT should be allowed access to the target
  951.              N_PORT. N_PORT identities used in the Port Login (PLOGI)
  952.              process shall be considered authenticated provided the PLOGI
  953.              request is received from the remote gateway over a secure,
  954.              IPSec-protected connection."
  955.  
  956.              Need to say something about the IKE identities (ID payloads)
  957.              used for the authentication, and how they correspond to
  958.              information obtained from iSNS - NATs/NAPTs will cause issues
  959.              here.  Just requiring an IPsec-protected connection isn't good
  960.              enough as it may allow a node not registered with iSNS to get
  961.              in.
  962.  
  963.           Accepted in part
  964.  
  965.              It would be premature to enumerate ID payloads in section
  966.              10.2.4, which describes the scope of the overall security
  967.              design prior to any IKE/IPsec requirement (to follow in
  968.              sections 10.3). The requested information will be supplied
  969.              after the last paragraph in section 10.3.1.
  970.  
  971.              Regarding intervening NA(P)Ts between iSNS clients and servers,
  972.              it is possible to put a proxy iSNS server at the boundary
  973.              between addressing domains. Such proxy will terminate the
  974.              IKE/IPSec so that the ID_IPV4_ADDR identity can be used
  975.              natively by IKE.  It is also possible to use the second method
  976.              described in the response to comment 38 -- a confederation of
  977.              iSNS servers where the NAT(P)T mediation now occurs between
  978.              iSNS servers.
  979.  
  980.              Admission control is performed by the iSNS server, based upon
  981.              the Discovery Domain (DD) configuration information stored in
  982.              that iSNS server. Once the authenticity of a gateway is
  983.              verified (e.g., via a pre-shared key) and IPsec SAs are
  984.              established, then the gateway is trusted to behave according to
  985.              the specification, which mandates a handshake with iSNS for
  986.              admission.
  987.  
  988.           Comment 40.        [E] Section 10.2.6  Rekeying
  989.  
  990.              I believe the security draft has changed in this area (small
  991.              rekeying interval example), please check it.
  992.  
  993.           Response
  994.  
  995.              We appear to be consistent with [SECIPS] version 11 still, end
  996.              of section 5.4, when Bellare╞s results are taken into
  997.              consideration.  Therefore, no change to iFCP is required.
  998.  
  999.           Comment 41.        [T] Section 10.2.7  Authorization
  1000.  
  1001.  
  1002.      Monia, et-al            Category - Expiration               [Page 17]
  1003.  
  1004.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  1005.  
  1006.  
  1007.              "Authorization is outside of the scope of this specification,
  1008.              and is seen as fully orthogonal to the iFCP security design.
  1009.              Such design, however, includes key authorization-enabling
  1010.              features in the form of Identity Payload (e.g., ID_FQDN),
  1011.              certificate-based authentication (e.g., with X509v3
  1012.              certificates), and discovery domains [ISNS]."
  1013.  
  1014.              What??  If iSNS doesn't know about an iFCP gateway, that
  1015.              gateway shouldn't be able to talk to any other iFCP gateway.
  1016.              That's access control, which counts as authorization in my
  1017.              book.
  1018.  
  1019.           Accept
  1020.  
  1021.              The paragraph will be re-written as follows.
  1022.  
  1023.              ⌠Basic access control properties stem from the requirement that
  1024.              the communicating iFCP gateways be known to one or more iSNS
  1025.              servers before they can engage in iFCP exchanges. The optional
  1026.              use of Identity Payloads (e.g., ID_FQDNs), certificate-based
  1027.              authentication (e.g., with X509v3 certificates), and discovery
  1028.              domains [ISNS] enables authorization schemas of increasing
  1029.              complexity. The definition of such schemas (e.g., role-based
  1030.              access control) is outside of the scope of this specification."
  1031.  
  1032.           Comment 42.        [E] Section 10.3.2, pp 86, para 8
  1033.  
  1034.              If an iFCP implementation makes use of unbound TCP connections,
  1035.              and such connections belong to an iFCP Portal with security
  1036.              requirements, then the unbound connections MUST be protected by
  1037.              an SA at all times just like bounded connections.
  1038.  
  1039.              Change "bounded" to "bound".
  1040.  
  1041.           Accepted
  1042.  
  1043.           Comment 43.        [T] Section 10.3.2, pp 86, para 9
  1044.  
  1045.              "Upon receiving an IKE Phase-2 delete message, there is no
  1046.              requirement to terminate the protected TCP connections or
  1047.              delete the associated IKE Phase-1 SA. Since an IKE Phase-2 SA
  1048.              may be associated with multiple TCP connections, terminating
  1049.              such connections might in fact be inappropriate and untimely.
  1050.              An iFCP Portal must instead attempt to create a new Phase-2 SA
  1051.              while there are outstanding iFCP sessions."
  1052.  
  1053.              That's a problem.  If the other side is behaving in accordance
  1054.              with the next paragraph ...:
  1055.  
  1056.              "To minimize the number of active Phase-2 SAs, IKE Phase-2
  1057.              delete messages may be sent for Phase-2 SAs whose TCP
  1058.              connections have not handled data traffic for a while. To
  1059.              minimize the use of SA resources while the associated TCP
  1060.  
  1061.      Monia, et-al            Category - Expiration               [Page 18]
  1062.  
  1063.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  1064.  
  1065.  
  1066.              connections are idle, creation of a new SA may be deferred
  1067.              until new data is to be sent over the connections."
  1068.  
  1069.              ... and is deleting the Phase-2 SAs because it lacks the
  1070.              resources to support them, immediately creating a new Phase-2
  1071.              SA in response to delete messages risks livelock (massive churn
  1072.              in Phase-2 SA creation/destruction).  Creating a new Phase-2 SA
  1073.              in response to a Phase-2 delete message SHOULD be deferred
  1074.              until there is traffic to send over that SA.
  1075.  
  1076.           Accepted
  1077.  
  1078.              We shall be removing the misleading sentence ⌠An iFCP Portal
  1079.              must instead attempt to create a new Phase-2 SA while there are
  1080.              outstanding iFCP sessions." and promote from may to SHOULD
  1081.              prior to the word µdeferred╞.
  1082.  
  1083.              The resulting modified text is shown below:
  1084.  
  1085.              "Upon receiving an IKE Phase-2 delete message, there is no
  1086.              requirement to terminate the protected TCP connections or
  1087.              delete the associated IKE Phase-1 SA. Since an IKE Phase-2 SA
  1088.              may be associated with multiple TCP connections, terminating
  1089.              such connections might in fact be inappropriate and untimely.
  1090.  
  1091.              "To minimize the number of active Phase-2 SAs, IKE Phase-2
  1092.              delete messages may be sent for Phase-2 SAs whose TCP
  1093.              connections have not handled data traffic for a while. To
  1094.              minimize the use of SA resources while the associated TCP
  1095.              connections are idle, creation of a new SA SHOULD be deferred
  1096.              until new data is to be sent over the connections."
  1097.  
  1098.           Comment 44.        [E] Section 13. - Normative References
  1099.  
  1100.              RFC 2451 reference shows up twice.
  1101.  
  1102.           Accepted
  1103.  
  1104.           Comment 45.        [T] Section A.2 - Link Services Processed
  1105.              Transparently
  1106.  
  1107.              "ACC       Accept"
  1108.  
  1109.              Is that right?  I thought this was intercepted in some cases,
  1110.              as indicated in Table 6.
  1111.  
  1112.           Response
  1113.  
  1114.              The ACC description will be modified to discriminate between
  1115.              the transparent and non-transparent cases.
  1116.  
  1117.           Comment 46.        [T] Section A.2 - Link Services Processed
  1118.              Transparently
  1119.  
  1120.      Monia, et-al            Category - Expiration               [Page 19]
  1121.  
  1122.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  1123.  
  1124.  
  1125.              FDISC     Discover F_Port Service Parameters
  1126.              FLOGI     F_Port Login
  1127.              RTV       Read Timeout Value
  1128.  
  1129.              Definitely wrong - the iFCP gateway has to implement these
  1130.              itself as specified in Section 9.1.
  1131.  
  1132.           Accepted in Part
  1133.  
  1134.              Special link service messages are those which require
  1135.              intervention by an iFCP protocol implementation before they are
  1136.              passed to the destination N_PORT.  Transparent link service
  1137.              messages are passed to the destination N_PORT without such
  1138.              intervention. In that regard, the above link services are
  1139.              processed transparently.
  1140.  
  1141.              The specification will be modified to make the above
  1142.              distinction clearer and the section will be re-titled as: "Link
  1143.              Services Processed Transparently by the iFCP layer".
  1144.  
  1145.           Comment 47.         [T] Section A.2 - Link Services Processed
  1146.              Transparently
  1147.  
  1148.              LINIT     Loop Initialize
  1149.              LPC       Loop Port Control
  1150.              LSTS      Loop Status
  1151.              SCL       Scan Remote Loop
  1152.  
  1153.              I don't have time to check these, but I'm suspicious about
  1154.              whether anything that has "Loop" as part of its name can/should
  1155.              be forwarded transparently into an FC fabric, although SCL
  1156.              seems plausible.  Please verify whether these are transparent.
  1157.  
  1158.           Response
  1159.  
  1160.              SCL must be processed as a special link service message. iFCP
  1161.              will be modified accordingly.  The remaining link services
  1162.              listed above are transparent.
  1163.  
  1164.           Comment 48.        [T] Section A.2 - Link Services Processed
  1165.              Transparently
  1166.  
  1167.              RSCN      Registered State Change Notification
  1168.              SCN       State Change Notification
  1169.              SCR       State Change Registration
  1170.  
  1171.              Those can't be transparent, as Section 9.2 requires the iFCP
  1172.              gateway to implement them.
  1173.  
  1174.           Response
  1175.  
  1176.              See response to Comment 46.
  1177.  
  1178.  
  1179.      Monia, et-al            Category - Expiration               [Page 20]
  1180.  
  1181.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  1182.  
  1183.  
  1184.      3. Comments From Elizabeth Rodriguez
  1185.  
  1186.           Comment 49.        [E] Title Page, Number of Authors
  1187.  
  1188.              Looks like you have 8 authors listed. Rule of thumb I think is
  1189.              6. I am having difficulty locating the guidelines, but may want
  1190.              to consider how you can move a couple of the listed authors
  1191.              into an acknowledgements section of some sort.   With 8, it may
  1192.              or may not get flagged by the IESG...
  1193.  
  1194.           Accepted
  1195.  
  1196.              We will reduce the roster of co-authors in accordance with IETF
  1197.              policy.
  1198.  
  1199.           Comment 50.        [E] Capitalize Fibre Channel
  1200.  
  1201.              I believe "Fibre Channel" should be capitalized throughout
  1202.              document.
  1203.  
  1204.           Rejected
  1205.  
  1206.              The specification is consistent with T11 lower case usage.
  1207.  
  1208.           Comment 51.        [E] Acknowledgements
  1209.  
  1210.              Braces around SECIPS do not match.
  1211.  
  1212.           Accepted
  1213.  
  1214.           Comment 52.        [E] Section 1.2
  1215.  
  1216.              "NCITS" should be "INCITS".
  1217.  
  1218.           Accepted
  1219.  
  1220.           Comment 53.        [E] "About This Document"
  1221.  
  1222.              There should be a page break before this section.
  1223.  
  1224.           Accepted
  1225.  
  1226.           Comment 54.        [E] Definitions, iFCP Frame
  1227.  
  1228.              Technically, the title is of the comment encapsulation
  1229.              specification is "FC Frame Encapsulation".
  1230.  
  1231.           Accepted
  1232.  
  1233.           Comment 55.        [E] Definitions
  1234.  
  1235.  
  1236.  
  1237.  
  1238.      Monia, et-al            Category - Expiration               [Page 21]
  1239.  
  1240.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  1241.  
  1242.  
  1243.              In the definitions of "N_PORT Alias" and "N_PORT I/D", two
  1244.              dashes should be used to separate the term from the body of the
  1245.              definition.
  1246.  
  1247.           Accepted
  1248.  
  1249.           Comment 56.        [E] Section 3, pp 9, para 1
  1250.  
  1251.              "Fibre channel is a frame-based, serial technology designed for
  1252.              peer-to-peer communication between devices at gigabit speeds
  1253.              and with low overhead and latency."
  1254.  
  1255.              May want to change to gigabit or greater speeds.  Technically,
  1256.              2, 4, 10 gigabit speeds are still gigabit, but many today
  1257.              interpret gigabit strictly as 1 gigabit.
  1258.  
  1259.           Rejected
  1260.  
  1261.              The term 'speeds' implies rates of 1Gb/sec and above.
  1262.  
  1263.           Comment 57.        [E] Section 3.1
  1264.  
  1265.              a) "N_PORTs -- The end points for fibre channel traffic. In
  1266.                 the FC standards, N_PORT interfaces have several variants,
  1267.                 depending on the topology of the fabric to which they are
  1268.                 attached. As used in this specification, the term applies
  1269.                 to any one of the variants."
  1270.  
  1271.              Suggestion -- sometimes referred to in literature as Nx_PORTs?
  1272.  
  1273.           Rejected
  1274.  
  1275.              A parenthetical Nx_PORT digression does not add any value to
  1276.              the iFCP specification, given that the following statement
  1277.              claims that N_PORT is used for any such variants.
  1278.  
  1279.           Comment 58.        [E] Section 3.2, Fabric Topologies
  1280.  
  1281.              a) "Arbitrated Loop -- A series of N_PORTs connected together
  1282.                 in daisy-chain fashion. Data transmission between N_PORTs
  1283.                 requires arbitration for control of the loop in a manner
  1284.                 similar to a token ring network."
  1285.  
  1286.           Accepted in part
  1287.  
  1288.              Rewrite as:
  1289.  
  1290.              a) ⌠Arbitrated Loop -- A series of N_PORTs connected together
  1291.                 in daisy-chain fashion. Loop-connected N_PORTS are referred
  1292.                 to as NL_PORTS. Data transmission between NL_PORTS
  1293.                 requires...÷
  1294.  
  1295.           Comment 59.        [E] Section 3.3, pp 13, para 6
  1296.  
  1297.      Monia, et-al            Category - Expiration               [Page 22]
  1298.  
  1299.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  1300.  
  1301.  
  1302.              "FC-4 √- Application protocols, such as FCP, the fibre channel
  1303.              SCSI protocol."
  1304.  
  1305.              Reword to read: "...such as FCP, commonly used abbreviation for
  1306.              "Fibre Channel Protocol for SCSI"
  1307.  
  1308.           Accepted in part
  1309.  
  1310.              The sentence will be revised to read: "...such as the fibre
  1311.              channel protocol for SCSI (FCP)."
  1312.  
  1313.           Comment 60.        [E] Section 3.7, pp 16, par 2
  1314.  
  1315.              "The source and destination N_PORT fabric addresses embedded in
  1316.              the S_ID and D_ID fields represent the physical MAC addresses
  1317.              of originating and receiving N_PORTs."
  1318.  
  1319.              "I think the term MAC is inappropriate here -- MAC is really an
  1320.              ethernet term.  Something like physical world wide unique
  1321.              address, similar to an ethernet MAC address... Or ... represent
  1322.              the physical MAC like address...
  1323.  
  1324.           Accepted
  1325.  
  1326.              The text will be changed to:
  1327.  
  1328.              "The source and destination N_PORT fabric addresses embedded in
  1329.              the S_ID and D_ID fields represent the physical addresses of
  1330.              the originating and receiving N_PORTs."
  1331.  
  1332.           Comment 61.        [E] Section 3.8, Fibre Channel Transport
  1333.              Services
  1334.  
  1335.              Does class 6 still exist, or has it been made obsolete?
  1336.  
  1337.           Response
  1338.  
  1339.              Class 6 is still specified in [FC-FS].
  1340.  
  1341.           Comment 62.        [E] Section 4.5, pp 24, para 5
  1342.  
  1343.              "The mode of gateway operation is settable in an
  1344.              implementation-specific manner. The implementation MUST NOT
  1345.              allow the mode to be changed after the gateway begins
  1346.              processing fibre channel frame traffic."
  1347.  
  1348.              Does this need to be qualified -- e.g. MUST NOT allow the mode
  1349.              to be changed after the gateway begins processing Fibre Channel
  1350.              traffic without first terminating all connections to that
  1351.              gateway, or some such -- in other words, really someone can
  1352.              change the mode of operation, but just cannot do so while the
  1353.              gateway is in use.
  1354.  
  1355.  
  1356.      Monia, et-al            Category - Expiration               [Page 23]
  1357.  
  1358.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  1359.  
  1360.  
  1361.           Rejected
  1362.  
  1363.              The specification will not be changed. The intent is to latch
  1364.              the operational mode after gateway power is turned on and the
  1365.              gateway begins handling FC frame traffic.  A change in
  1366.              operational mode is not intended to be easy or graceful.
  1367.  
  1368.           Comment 63.        [E] Section 5.2.2.1, pp 31, para 9
  1369.  
  1370.              "When creating a descriptor in response to an incoming CBIND
  1371.              request, the iFCP gateway SHALL perform an iSNS name server
  1372.              query using the worldwide port name of the remote N_PORT in the
  1373.              SOURCE N_PORT NAME field within the CBIND payload. The
  1374.              descriptor SHALL be filled in using the query results."
  1375.  
  1376.              Need to make sure that iSNS gets through WG last call soon as
  1377.              well, since this is a normative dependency.
  1378.  
  1379.           Accepted
  1380.  
  1381.           Comment 64.        [E] Section 5.4, pp 39, para 1
  1382.  
  1383.              "This section describes the iFCP encapsulation of fibre channel
  1384.              frames. The encapsulation is based on the common encapsulation
  1385.              format defined in [ENCAP]."
  1386.  
  1387.              The reference to "common encapsulation" should be "FC Frame
  1388.              Encapsulation".
  1389.  
  1390.           Rejected
  1391.  
  1392.              The reference is appropriate.
  1393.  
  1394.           Comment 65.        [E] Section 6.2, Unbind Connection (UNBIND)
  1395.  
  1396.           It should be noted that the Unbind status codes listed in this
  1397.           section are decimal values.
  1398.  
  1399.           Accepted
  1400.  
  1401.              The rules for numeric representation will be added to the
  1402.              "Conventions" section.
  1403.  
  1404.           Comment 66.        [E] Section 7, pp 53
  1405.  
  1406.              a) "Transparent √ The link service message and reply MUST be
  1407.                transported to the receiving N_PORT by the iFCP gateway
  1408.                without altering the message payload. The link service
  1409.                message and reply are not processed by the iFCP
  1410.                implementation."
  1411.  
  1412.              Since iFCP has Transparent and Translation modes, use of the
  1413.              term transparent here might get confusing -- Transparent is
  1414.  
  1415.      Monia, et-al            Category - Expiration               [Page 24]
  1416.  
  1417.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  1418.  
  1419.  
  1420.              referring to the fact that the link service must be propogated
  1421.              across the IP network, correct?  As opposed to a link service
  1422.              that is applicable only to transparent mode...
  1423.  
  1424.           Accepted
  1425.  
  1426.              The term "transparent" in this context will be changed to
  1427.              "pass-though".
  1428.  
  1429.      4. Comments from Brian Forbes
  1430.  
  1431.           Comment 67.        [E] Section 2.1, Special Characters
  1432.  
  1433.              For some reason the file contains a number of occurrences of
  1434.              the character <funny character> instead of a hyphen or dash.
  1435.              Occurs throughout the text.
  1436.  
  1437.           Accepted
  1438.  
  1439.           Comment 68.        [E] Section 2.1, Definitions
  1440.  
  1441.              "iFCP Session - An association created when an N_PORT sends a
  1442.              PLOGI request to a remotely attached N_PORT. It is comprised of
  1443.              the N_PORTs and TCP connection that carries traffic between
  1444.              them."
  1445.  
  1446.              Grammar: ⌠it is comprised of÷ should be ⌠it comprises÷.
  1447.  
  1448.           Accepted
  1449.  
  1450.           Comment 69.        [E] Section 2.1, Definitions
  1451.  
  1452.              "N_PORT Alias -- The N_PORT address assigned by a gateway to
  1453.              represent a remote N_PORT accessed via the iFCP protocol. When
  1454.              routing frame traffic in address translation mode, the gateway
  1455.              automatically converts N_PORT aliases to N_PORT network
  1456.              addresses and vice versa."
  1457.  
  1458.              Consistency: in the list of 2.1 definitions, some entries use a
  1459.              double hyphen and others only a single one (which at least one
  1460.              reader interpreted as a change in level)
  1461.  
  1462.           Accepted
  1463.  
  1464.           Comment 70.        [E] Section 3.1, The Fibre Channel Network
  1465.  
  1466.              "Unlike a layered network architecture,  a fibre channel
  1467.              network is largely..."
  1468.  
  1469.              Remove the extra space after the comma.
  1470.  
  1471.           Accepted
  1472.  
  1473.  
  1474.      Monia, et-al            Category - Expiration               [Page 25]
  1475.  
  1476.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  1477.  
  1478.  
  1479.           Comment 71.        [E] Section 3.3.1, Fabric Supplied Link
  1480.              Services
  1481.  
  1482.              "Time Server √- Intended for the management of fabric-wide
  1483.              expiration timers or elapsed time values and is not intended
  1484.              for precise time synchronization"
  1485.  
  1486.              Parallel structure: ⌠and is not intended÷ seems to read better
  1487.              as ⌠and not intended÷
  1488.  
  1489.           Accepted
  1490.  
  1491.              Text will be changed to read:
  1492.  
  1493.              "Time Server √- Intended for the management of fabric-wide
  1494.              expiration timers or elapsed time values and not intended for
  1495.              precise time synchronization"
  1496.  
  1497.           Comment 72.        [E] Section 3.7.1, page 6, para 3
  1498.  
  1499.              "...The value of the Domain I/D ranges from 1 to 239 (0xEF)."
  1500.  
  1501.              Both ⌠ID÷ and ⌠I/D÷ are used to mean ⌠identifier÷ within the
  1502.              same paragraph. Common usage suggests ⌠ID÷ throughout. Also
  1503.              occurs elsewhere, e.g. page 21
  1504.  
  1505.           Accepted
  1506.  
  1507.           Comment 73.        [E] Section 3.7.1, page 17, para 3
  1508.  
  1509.              For some reason the file contains a number of occurrences of a
  1510.              non-ascii character instead of an apostrophe. Also occurs on
  1511.              pages 64 for example.
  1512.  
  1513.           Accepted
  1514.  
  1515.           Comment 74.        [E] Section 3.7.1, page 17, para 4
  1516.  
  1517.              ⌠FLOGI÷: this is the first occurrence of this FC term; it
  1518.              should be spelled out here or a forward reference could be
  1519.              provided
  1520.  
  1521.           Accepted
  1522.  
  1523.           Comment 75.        [E] Section 3.9, page 18. item a)
  1524.  
  1525.              a) "Fabric Login (FLOGI) -- An operation whereby the N_PORT
  1526.                 registers its presence on the fabric, obtains fabric
  1527.                 parameters, such as classes of service supported, and
  1528.                 receives its N_PORT address,"
  1529.  
  1530.              Reads better without the comma after ⌠fabric parameters÷.
  1531.  
  1532.  
  1533.      Monia, et-al            Category - Expiration               [Page 26]
  1534.  
  1535.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  1536.  
  1537.  
  1538.           Accepted
  1539.  
  1540.           Comment 76.        [E] Section 4, page 18, para 3
  1541.  
  1542.              "Within the fibre channel device domain, fabric-addressable
  1543.              entities consist of other N_PORTs and devices internal to the
  1544.              fabric that perform the fabric services defined in [FC-GS3]."
  1545.  
  1546.              ⌠devices÷ is possibly ambiguous here, could say ⌠FC devices÷ or
  1547.              iFCP devices÷ depending on the intent.
  1548.  
  1549.           Accepted
  1550.  
  1551.              Text will be changed to:
  1552.  
  1553.              "Within the fibre channel device domain, fabric-addressable
  1554.              entities consist of other N_PORTs and fibre channel devices
  1555.              internal to the fabric that perform the fabric services defined
  1556.              in [FC-GS3]."
  1557.  
  1558.           Comment 77.        [E] Section 4.6.1, Page 25, Para 1
  1559.  
  1560.              "As described in section 4.6, each gateway and fibre channel
  1561.              switch in a bounded iFCP fabric MUST have a unique domain I/D.
  1562.              In a gateway region containing fibre channel switch elements,
  1563.              each element obtains a domain I/D by querying the principal
  1564.              switch as described in [FC-SW2] -- in this case the iFCP
  1565.              gateway itself.  The gateway in turn MUST obtain domain I/Ds on
  1566.              demand from the iSNS name server acting as the central address
  1567.              allocation authority. In effect, the iSNS server assumes the
  1568.              role of principal switch for the bounded fabric. In that case,
  1569.              the iSNS database contains:"
  1570.  
  1571.              The fact that a gateway can act as the FC principal switch is
  1572.              mentioned in this section and others, but there seems to be no
  1573.              normative text determining when it must do so. This will be
  1574.              obvious to a knowledgeable reader, or perhaps is covered in an
  1575.              ancillary document, but given the care taken elsewhere to
  1576.              provide normative language for µobvious╞ functionality it seems
  1577.              to be an oversight
  1578.  
  1579.           Rejected
  1580.  
  1581.              Since the paragraph is intended to describe behavior that is
  1582.              normatively specified elsewhere, the use of "MUST" is
  1583.              incorrect.  The text will be changed to the following:
  1584.  
  1585.              "As described in section 4.6, each gateway and fibre channel
  1586.              switch in a bounded iFCP fabric has a unique domain I/D.  In a
  1587.              gateway region containing fibre channel switch elements, each
  1588.              element obtains a domain I/D by querying the principal switch
  1589.              as described in [FC-SW2] -- in this case the iFCP gateway
  1590.              itself.  The gateway in turn obtains domain I/Ds on demand from
  1591.  
  1592.      Monia, et-al            Category - Expiration               [Page 27]
  1593.  
  1594.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  1595.  
  1596.  
  1597.              the iSNS name server acting as the central address allocation
  1598.              authority. In effect, the iSNS server assumes the role of
  1599.              principal switch for the bounded fabric. In that case, the iSNS
  1600.              database contains..."
  1601.  
  1602.           Comment 78.        [E] Section 5.2.2.3, page 35, paras 3 and 4
  1603.  
  1604.              These two paragraphs use the terms µheartbeat╞ and
  1605.              µconnectivity probe╞ as informal synonyms for LTESTs. Use of
  1606.              the same synonym in both places would keep the reader from
  1607.              wondering whether the two synonyms represent the same concept.
  1608.  
  1609.           Accepted
  1610.  
  1611.           Comment 79.        [E] Section 5.2.2.4.3, page 37, para 1
  1612.  
  1613.              "Window scaling, as specified in [RFC1323], allows full
  1614.              utilization of links with large bandwidth - delay products and
  1615.              should be supported by an iFCP implementation."
  1616.  
  1617.              Is ⌠should÷ intended to be normative (capitalized)?
  1618.  
  1619.           Response
  1620.  
  1621.              The lower case usage is intentional.  The goal is to reflect a
  1622.              desirable bias rather than the sort of mandate defined in
  1623.              [RFC2119].
  1624.  
  1625.           Comment 80.        [E] Section 5.2,3, page 32, items c) and d)
  1626.  
  1627.              a) "For an FC frame received from the IP network, a gateway
  1628.                 detects a CRC error in the encapsulation header. The gateway
  1629.                 shall abort the session as described in section....
  1630.  
  1631.              b) "The TCP connection associated with the login session fails
  1632.                 for any reason.  The gateway detecting the failed connection
  1633.                 shall abort the session as described in section...."
  1634.  
  1635.              ⌠shall÷ should be capitalized.
  1636.  
  1637.           Accepted
  1638.  
  1639.           Comment 81.        [E] Section 5.4, page 39, last paragraph
  1640.  
  1641.              "When operating in Address Translation mode, (see section ...)
  1642.              the iFCP gateway must recalculate the fibre channel CRC."
  1643.  
  1644.              ⌠must÷ should be in caps.
  1645.  
  1646.           Accepted
  1647.  
  1648.           Comment 82.        [E] Section 5.4, page 41, "TRN" mnemonic
  1649.  
  1650.  
  1651.      Monia, et-al            Category - Expiration               [Page 28]
  1652.  
  1653.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  1654.  
  1655.  
  1656.              It╞s unfortunate that ⌠TRN÷ can be read as either ⌠transparent÷
  1657.              or ⌠translation÷ and therefore has less mnemonic value.
  1658.  
  1659.           Accepted
  1660.  
  1661.              "TRN", the mnemonic for "transparent mode", will be changed to
  1662.              "TRP".
  1663.  
  1664.           Comment 83.        [E] Section 6.2, page 49, para 1
  1665.  
  1666.              "UNBIND is used to release a bound TCP connection and.
  1667.              optionally, return it to the pool of unbound TCP connections."
  1668.  
  1669.              Punctuation: ⌠and. optionally, ÷ should be ⌠and optionally÷.
  1670.  
  1671.           Accepted
  1672.  
  1673.           Comment 84.        [E] Section 7.3, page 58, para 2
  1674.  
  1675.              "The formats of each special link service message, including
  1676.              supplemental data where applicable, are shown in the following
  1677.              sections."
  1678.  
  1679.              ⌠The formats of eachα message are÷ is awkward, suggest ⌠The
  1680.              format of eachα message is÷.
  1681.  
  1682.           Accepted
  1683.  
  1684.           Comment 85.        [E] Section 7.3.1.6, page 63, para 2
  1685.  
  1686.              "This ELS shall always be sent as an augmented ELS regardless
  1687.              of the translation mode in effect."
  1688.  
  1689.              "Shall" should be capitalized.
  1690.  
  1691.              Accepted
  1692.  
  1693.              The text must also be modified to replace "augmented" with
  1694.              "special", as given below.
  1695.  
  1696.              "This ELS SHALL always be sent as a special ELS regardless of
  1697.              the translation mode in effect."
  1698.  
  1699.              [E] Section 7.3.1.14, page 71, last paragraph
  1700.  
  1701.              "The size of each frame to be sent to the destination N_PORT
  1702.              MUST NOT exceed the maximum frame size that the destination
  1703.              N_PORT can accept.  The sequence identifier in each frame
  1704.              header SHALL be copied from the augmented ELS and the sequence
  1705.              count shall be monotonically increasing."
  1706.  
  1707.              "Shall" should be capitalized.
  1708.  
  1709.  
  1710.      Monia, et-al            Category - Expiration               [Page 29]
  1711.  
  1712.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  1713.  
  1714.  
  1715.           Accepted
  1716.  
  1717.           Comment 86.        [E] Section 10.2.4, page 82, paras 1 and 2
  1718.  
  1719.              "iFCP is a peer-to-peer protocol.  iFCP sessions may be
  1720.              initiated by either or both peer gateways.  Consequently, bi-
  1721.              directional authentication of peer gateways MUST be provided.
  1722.  
  1723.              "iFCP gateways MUST use Discovery Domain information obtained
  1724.              from the iSNS server [ISNS] to determine whether the initiating
  1725.              fibre channel N_PORT should be allowed access to the target
  1726.              N_PORT.  N_PORT identities used in the Port Login (PLOGI)
  1727.              process shall be considered authenticated provided the PLOGI
  1728.              request is received from the remote gateway over a secure,
  1729.              IPSec-protected connection."
  1730.  
  1731.              These paragraphs seem to be statements of required
  1732.              functionality but are too general to use normative language
  1733.              (⌠MUST÷). Later sections contain the normative text necessary
  1734.              to cover these topics.
  1735.  
  1736.           Accepted
  1737.  
  1738.           Comment 87.        [E] Section 10.2.5, page 82, para 1
  1739.  
  1740.              See Comment 86.
  1741.  
  1742.           Accepted
  1743.  
  1744.           Comment 88.        [E] Section 10.2.6, pages 82 and 82, all
  1745.              paragraphs
  1746.  
  1747.              See Comment 86.
  1748.  
  1749.           Accepted
  1750.  
  1751.  
  1752.  
  1753.      5. Comments from Mallikarjun Chadalapaka
  1754.  
  1755.           Comment 89.        [E] Section 1.2
  1756.  
  1757.              "...standards controlled by NCITS T10 and T11."
  1758.  
  1759.              "NCITS" should be "INCITS".
  1760.  
  1761.           Accepted
  1762.  
  1763.           Comment 90.        [E] 2.1 Definitions
  1764.  
  1765.              "Gateway Region -- The portion of an iFCP fabric accessed
  1766.              through an iFCP gateway. Fibre channel devices in the region
  1767.  
  1768.  
  1769.      Monia, et-al            Category - Expiration               [Page 30]
  1770.  
  1771.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  1772.  
  1773.  
  1774.              consist of all fibre channel devices locally attached to the
  1775.              gateway."
  1776.  
  1777.              The first sentence here when interpreted wrt a Nx_port sitting
  1778.              within a given gateway region, implies something that isn't
  1779.              right - viz. the rest of the iFCP fabric.  The second sentence
  1780.              makes the intention clear, if "locally attached" includes the
  1781.              entire local fabric.  My suggestion would be: "The portion of
  1782.              an iFCP fabric that accesses the rest of the fabric through one
  1783.              iFCP gateway."
  1784.  
  1785.           Accepted
  1786.  
  1787.              The definition will be changed to the following:
  1788.  
  1789.              "Gateway Region -- The portion of an iFCP fabric accessed
  1790.              through an iFCP gateway by a remotely attached N_PORT. Fibre
  1791.              channel devices in the region consist of all those locally
  1792.              attached to the gateway."
  1793.  
  1794.           Comment 91.        [T] Section 3.3.1, pp 14, para 7
  1795.  
  1796.              "Time Server -- Intended for the management of fabric-wide
  1797.              expiration timers or elapsed time values and is not intended
  1798.              for precise time synchronization."
  1799.  
  1800.              I am curious about this - is it the conclusion the iFCP authors
  1801.              reached? The reason I ask is that IIRC, FCIP allows using this
  1802.              for time sync.
  1803.  
  1804.           Response
  1805.  
  1806.              See Comment 71 for the proposed change to this section.
  1807.  
  1808.              The characterization is found in the literature and based on
  1809.              the following from the [FC-GS3] specification, section 7, page
  1810.              161.
  1811.  
  1812.              "The Time Service is provided to serve time information that is
  1813.              sufficient for managing expiration time."
  1814.  
  1815.           Comment 92.        [T] Section 3.7, pp 14, para 2
  1816.  
  1817.              "The source and destination N_PORT fabric addresses embedded in
  1818.              the S_ID and D_ID fields represent the physical MAC addresses
  1819.              of originating and receiving N_PORTs."
  1820.  
  1821.              I am not sure that it is a correct analogy....S_ID and D_ID are
  1822.              actually (potentially transient) addresses assigned by the
  1823.              fabric, Port Names are more akin to the MAC addresses.
  1824.  
  1825.           Accepted
  1826.  
  1827.  
  1828.      Monia, et-al            Category - Expiration               [Page 31]
  1829.  
  1830.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  1831.  
  1832.  
  1833.              See Comment 60.
  1834.  
  1835.           Comment 93.        [E] 4. The iFCP Network Model
  1836.  
  1837.              "The iFCP protocol enables the implementation of fibre channel
  1838.              mixed or switched fabric functionality on an IP network."
  1839.  
  1840.              I am not sure what is intended by "fibre channel mixed or
  1841.              switched" here, perhaps this could use rewording.
  1842.  
  1843.           Accepted
  1844.  
  1845.              The text will be changed to:
  1846.  
  1847.              "The iFCP protocol enables the implementation of fibre channel
  1848.              fabric functionality on an IP network."
  1849.  
  1850.           Comment 94.        [E] Section 4, pp 20, para 1
  1851.  
  1852.              "Each iFCP gateway contains two standards-compliant fibre
  1853.              channel ports and an iFCP Portal for attachment to the IP
  1854.              network."
  1855.  
  1856.              Why are two FC ports required?  As far as I can tell, even one
  1857.              E_Port works just as well - is it to be technically called as a
  1858.              "switch"?
  1859.  
  1860.              Also, is there a reason for limiting to only one IP address
  1861.              (implied by one iFCP Portal)?  I see that supporting multiple
  1862.              iFCP Portals would require enahancements to the data structures
  1863.              presented - but can you please comment on any architectural
  1864.              issues here?
  1865.  
  1866.           Response
  1867.  
  1868.              The specification will be revised to emphasize that the figure
  1869.              is but one example of a supported implementation.  It was
  1870.              intended to parallel the earlier fibre channel fabric example
  1871.              as a way of showing the transition to an equivalent iFCP
  1872.              fabric.
  1873.  
  1874.              The selected example was chosen because it was easier to depict
  1875.              within the constraints of ASCII text.  An E_PORT example could
  1876.              have also been used.  In either case, the device incorporating
  1877.              iFCP portal functionality would be called an "iFCP gateway".
  1878.  
  1879.              The considerations to be addressed when connecting multiple
  1880.              iFCP portals to a gateway region are discussed in Comment 12.
  1881.  
  1882.           Comment 95.        [E] section 4, pp 20, para 2
  1883.  
  1884.              "... channel switch element. At this interface, remote N_PORTs
  1885.              are presented as fabric-attached devices. Conversely, on the IP
  1886.  
  1887.      Monia, et-al            Category - Expiration               [Page 32]
  1888.  
  1889.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  1890.  
  1891.  
  1892.              network side, the gateway presents each locally connected
  1893.              N_PORT as a logical fibre channel device."
  1894.  
  1895.              I am not sure the last sentence is correct - I think "logical
  1896.              fibre channel device" should probably be replaced by "a TCP
  1897.              connection".
  1898.  
  1899.           Rejected
  1900.  
  1901.              The logical fibre channel device represents the layer 4
  1902.              abstraction visible on the IP network.
  1903.  
  1904.           Comment 96.        [E] Section 4.1, pp 20, para 1
  1905.  
  1906.              "...cases, the gateway may support any standards-compliant
  1907.              fibre channel fabric type by incorporating the functionality
  1908.              required to..."
  1909.  
  1910.              Can you please comment if really "fabric type" is meant here?
  1911.              Or, is it the "fabric port type"?
  1912.  
  1913.           Response
  1914.  
  1915.              More accurately, "fabric type" should be changed to "fibre
  1916.              channel network topology."  The specification will be changed
  1917.              accordingly. See Comment 5.
  1918.  
  1919.           Comment 97.        [E] Section 4.1, pp 20, para 1
  1920.  
  1921.              "...present locally attached N_PORTs as logical iFCP devices."
  1922.  
  1923.              It may be useful to define "iFCP device" in section 2.1.
  1924.  
  1925.           Rejected
  1926.  
  1927.              From section 2.1:
  1928.  
  1929.              "Logical iFCP Device - The abstraction representing a single
  1930.              fibre channel device as it appears on an iFCP network."
  1931.  
  1932.              The specification will not be changed.
  1933.  
  1934.           Comment 98.        [T]  Section 4.4.1, pp 22, para 2
  1935.  
  1936.              "...messages, a gateway cannot convert such addresses in the
  1937.              payload of vendor- or user-specific fibre channel frame
  1938.              traffic."
  1939.  
  1940.              Not being very familiar with today's FC, can you please comment
  1941.              if these proprietary versions of frame formats (with even the
  1942.              D_ID out of place) are legal on regular fabrics?  Seems like
  1943.              the entire fabric should be capable of special handling
  1944.              these...
  1945.  
  1946.      Monia, et-al            Category - Expiration               [Page 33]
  1947.  
  1948.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  1949.  
  1950.  
  1951.           Response
  1952.  
  1953.              There is one and only one acceptable format for FC frames. That
  1954.              said, the issue is not the frame format but the payload
  1955.              contents.
  1956.  
  1957.              Besides the addresses in the FC frame header, an iFCP
  1958.              implementation is only cognizant of N_PORT addresses that may
  1959.              be embedded in the payload of standards-compliant link service
  1960.              messages.  It cannot remap such addresses if present in the
  1961.              payloads of user-specified or vendor-specific frames.
  1962.  
  1963.              No change to the specification will be made.
  1964.  
  1965.           Comment 99.        [T] Section 4.4.3, pp 22, para 1
  1966.  
  1967.              "In an unbounded iFCP fabric, limiting the scope of an N_PORT
  1968.              address to a gateway region reduces the likelihood that
  1969.              reassignment of domain I/Ds caused by a disruption in one
  1970.              gateway region will cascade to others."
  1971.  
  1972.              "In an unbounded iFCP fabric, limiting the scope of an N_PORT
  1973.              address to a gateway region reduces the likelihood that "
  1974.  
  1975.              Does it not prevent the likelihood?
  1976.  
  1977.           Accepted
  1978.  
  1979.              The text will be changed to:
  1980.  
  1981.              "In an unbounded iFCP fabric, limiting the scope of an N_PORT
  1982.              address to a gateway region prevents reassignment of domain
  1983.              I/Ds caused when a disruption in one gateway region cascades to
  1984.              others."
  1985.  
  1986.           Comment 100.       [T] Section 4.4.3, pp 22, para 2
  1987.  
  1988.              "In addition, a bounded iFCP fabric has an increased dependency
  1989.              on..."
  1990.  
  1991.              Suggest changing "In addition" to "On the other hand".
  1992.  
  1993.           Accepted
  1994.  
  1995.           Comment 101.       [E] Section 4.4.3, pp 22, para 3
  1996.  
  1997.              "Finally, adding a gateway to a bounded fabric is more likely
  1998.              to disrupt the operation of all devices in the gateway region
  1999.              along with those already in the fabric as new, fabric-wide
  2000.              N_PORT addresses are assigned."
  2001.  
  2002.  
  2003.  
  2004.  
  2005.      Monia, et-al            Category - Expiration               [Page 34]
  2006.  
  2007.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  2008.  
  2009.  
  2010.              Isn't the issue in this para the same as that in the first
  2011.              para, albeit from the bounded fabric's perspective?  If so,
  2012.              suggest merging them.
  2013.  
  2014.           Rejected
  2015.  
  2016.              Adding a new gateway region is distinct from disrupting an
  2017.              existing region and therefore merits its own mention.
  2018.  
  2019.           Comment 102.       [E] Section 4.4.3, pp 23, para 4
  2020.  
  2021.              ...be done non-disruptively and requires only that new
  2022.              gateway's iSNS..."
  2023.  
  2024.              Change "that" to "that the".
  2025.  
  2026.           Accepted
  2027.  
  2028.           Comment 103.       [T] Section 4.5, The iFCP N_PORT Address Model
  2029.  
  2030.              b) "A 24-bit N_PORT alias. A fibre channel N_PORT address
  2031.                 assigned by a gateway operating in address translation mode
  2032.                 to identify a remotely attached N_PORT. Frame traffic is
  2033.                 directed to a remotely attached N_PORT by means of the
  2034.                 N_PORT alias."
  2035.  
  2036.              At any point in time, there can only be 2^24 N_PORTs
  2037.              communicating even in the address translation mode, even though
  2038.              this mode allows the same N_PORT to be mapped to different
  2039.              nports in different gateway regions at different times.  If
  2040.              this is a correct interpretation, I suggest that this be made
  2041.              clear in section 4.4.2, which currently simply states that
  2042.              there are no architectural limitations on the number of fibre
  2043.              channel devices in this mode.
  2044.  
  2045.           Accepted in Part
  2046.  
  2047.              While the addressability in a given gateway region is
  2048.              constrained by the fibre channel address model, the aggregate
  2049.              addressability of all gateway regions comprising an unbounded
  2050.              iFCP fabric can exceed that limit.
  2051.  
  2052.              To make this clearer, the text will be changed as follows:
  2053.  
  2054.              b) "Since N_PORT fibre channel addresses in an unbounded iFCP
  2055.                 fabric are not fabric-wide, the number of iFCP gateways,
  2056.                 fibre channel devices and switch elements that may be
  2057.                 internetworked may exceed the fibre channel fabric limits."
  2058.  
  2059.           Comment 104.       [E] Section 4.6.1, pp 25, para 4
  2060.  
  2061.              "In its role as principal switch within the gateway region, an
  2062.              iFCP..."
  2063.  
  2064.      Monia, et-al            Category - Expiration               [Page 35]
  2065.  
  2066.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  2067.  
  2068.  
  2069.              General comment - Change to "...as the Principal Switch...".
  2070.  
  2071.           Accepted
  2072.  
  2073.           Comment 105.       [T] Section 5.2.1, pp 30, para 4
  2074.  
  2075.              "...A gateway implementation MAY establish a pool of unbound
  2076.              connections to reduce the session setup time.  Such pre-
  2077.              existing TCP connections between iFCP Portals remain unbound
  2078.              and uncommitted until allocated to an iFCP session through a
  2079.              CBIND message"
  2080.  
  2081.              I wonder if there is a scope for DoS attack here with the
  2082.              possibility of one gateway potentially holding onto several
  2083.              unused TCP connections infinitely...."
  2084.  
  2085.           Response
  2086.  
  2087.              No. However, the specification will be modified to point out
  2088.              that a gateway may recover resources at any time by simply
  2089.              closing unbound connections. See Comment 21.
  2090.  
  2091.           Comment 106.       [E] Section 5.2.2.1, pp31, para 6
  2092.  
  2093.              "If a descriptor does not exist, one SHALL be created in
  2094.              response to an iSNS name server query."
  2095.  
  2096.              Did you mean "SHALL be created after the response to an iSNS
  2097.              name server query is received"?
  2098.  
  2099.           Response
  2100.  
  2101.              The test will be changed to:
  2102.  
  2103.              "If a descriptor does not exist, one SHALL be created using the
  2104.              information returned by an iSNS name server query."
  2105.  
  2106.           Comment 107.       [E] Section 5.2.2.1.1,  pp 31, para 1
  2107.  
  2108.              "A Remote N_PORT descriptor SHALL only be updated as the result
  2109.              of an iSNS query that returns information for the specified
  2110.              worldwide port name. Following such an update, a new N_PORT
  2111.              alias SHALL NOT be assigned."
  2112.  
  2113.              I assume you meant "iSNS response" instead of "iSNS query"?
  2114.  
  2115.              I am a little confused by the SHALL NOT.  Here's what I was
  2116.              assuming as the sequence of events
  2117.  
  2118.              1. Local FC Name Server query.
  2119.  
  2120.              2. iFCP gateway picks it up.
  2121.  
  2122.  
  2123.      Monia, et-al            Category - Expiration               [Page 36]
  2124.  
  2125.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  2126.  
  2127.  
  2128.              3. Consults with iSNS server
  2129.  
  2130.              4. iSNS provides the remote N_PORT for the WWN
  2131.  
  2132.              5. iFCP gateway assigns a local alias if in translation mode
  2133.                 and if the remote N_PORT ID  clashes with a pre-existing
  2134.                 local NPORT_ID.
  2135.  
  2136.              I do not see why this sequence should be prohibited. Comments
  2137.              will certainly help.
  2138.  
  2139.           Accepted in Part
  2140.  
  2141.              The text will be modified as described in Comment 108.
  2142.  
  2143.              The 24-bit N_PORT component of the remote N_PORTs address and
  2144.              its local alias can never clash.  The gateway transparently
  2145.              converts the alias to a network address, consisting of the TCP
  2146.              connection I/D, TCP Port number and the N_PORT ID assigned by
  2147.              the remote gateway.
  2148.  
  2149.           Comment 108.       [T] Section 5.2.2.1.1, pp 31, para 1
  2150.  
  2151.              "A Remote N_PORT descriptor SHALL only be updated as the result
  2152.              of an iSNS query that returns information for the specified
  2153.              worldwide port name. Following such an update, a new N_PORT
  2154.              alias SHALL NOT be assigned.
  2155.  
  2156.              "Until such an update occurs, the contents of a descriptor may
  2157.              become stale as the result of any event that invalidates or
  2158.              triggers a change in the N_PORT network address of the remote
  2159.              device, such as a fabric reconfiguration or the device's
  2160.              removal or replacement."
  2161.  
  2162.              I assume that generally what is meant by "Until such an update
  2163.              occurs" is "In the absence of an operational iFCP session based
  2164.              on a descriptor". If so, it perhaps requires rewording.
  2165.  
  2166.           Accepted in Part
  2167.  
  2168.              Descriptors are only built and updated as a consequence of name
  2169.              server requests or state change notifications.  An iFCP session
  2170.              may not necessarily be associated with these activities.
  2171.  
  2172.              The text will be reworded as shown below to add the state
  2173.              change case and clarify the order of events leading to a stale
  2174.              descriptor.
  2175.  
  2176.              "A Remote N_PORT descriptor SHALL only be updated as the result
  2177.              of an iSNS query to obtain information for the specified
  2178.              worldwide port name or from information returned by an iSNS
  2179.              state change notification. Following such an update, a new
  2180.              N_PORT alias SHALL NOT be assigned.
  2181.  
  2182.      Monia, et-al            Category - Expiration               [Page 37]
  2183.  
  2184.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  2185.  
  2186.  
  2187.              "Before such an update, the contents of a descriptor may have
  2188.              become stale as the result of any event that invalidates or
  2189.              triggers a change in the N_PORT network address of the remote
  2190.              device, such as a fabric reconfiguration or the device's
  2191.              removal or replacement."
  2192.  
  2193.           Comment 109.       [E] Section 5.2.2.1.1, pp 31, para 4
  2194.  
  2195.              "Once the originating N_PORT learns of the reconfiguration,
  2196.              usually through the name server state change notification
  2197.              mechanism, the name server lookup needed to reestablish the
  2198.              iFCP session will automatically purge such stale data from the
  2199.              gateway."
  2200.  
  2201.              Just a clarification here - it seems to me that the SCN for a
  2202.              remote N_PORT ID needs to delivered via the iFCP gateway
  2203.              anyway, so why not purge the stale mapping then (instead of
  2204.              waiting for the new SNS query from the local N_PORT?
  2205.  
  2206.           Accepted
  2207.  
  2208.              The text will be changed to:
  2209.  
  2210.              "Once the originating N_PORT learns of the reconfiguration,
  2211.              usually through the name server state change notification
  2212.              mechanism, information returned in the notification or the
  2213.              subsequent name server lookup needed to reestablish the iFCP
  2214.              session will automatically purge such stale data from the
  2215.              gateway."
  2216.  
  2217.           Comment 110.       [T] Section 5.2.2.2, pp 33
  2218.  
  2219.              f) "A CBIND response with a CBIND STATUS of "N_PORT session
  2220.                 already exists" indicates that the remote gateway has
  2221.                 concurrently..."
  2222.  
  2223.              I think the document should specify that this status be mapped
  2224.              to the LS_RJT reason code of "Login/command already in
  2225.              progress" - 0x0E. Also, there may be N_PORTs that go down
  2226.              without issuing a LOGO, and attempt a PLOGI once they come back
  2227.              - unbeknownst to the iFCP gateway still with the old session
  2228.              descriptor.  It isn't clear to me how this is proposed to be
  2229.              dealt with.
  2230.  
  2231.           Rejected
  2232.  
  2233.              As described in Comment 15, the specified behavior is meant to
  2234.              serve as a tie-breaking mechanism for the establishment of the
  2235.              iFCP session. Once the session is established, the PLOGIs from
  2236.              each side are sent and processed by the N_PORTs in accordance
  2237.              with the PLOGI semantics specified in [FC-FS].
  2238.  
  2239.  
  2240.  
  2241.      Monia, et-al            Category - Expiration               [Page 38]
  2242.  
  2243.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  2244.  
  2245.  
  2246.              A PLOGI after an iFCP session exists is handled in accordance
  2247.              with section 7.3.1.7, paragraph 5, which states:
  2248.  
  2249.              "As specified in section 5.2.2.2, a PLOGI request addressed to
  2250.              a remotely attached N_PORT MUST cause the creation of an iFCP
  2251.              session if one does not exist. Otherwise, the PLOGI and PLOGI
  2252.              ACC payloads MUST be passed transparently to the destination
  2253.              N_PORT using the existing iFCP session."
  2254.  
  2255.              Section 5.2.2.2 will be modified to describe the simultaneous
  2256.              PLOGI scenario above and the case of a PLOGI issued when an
  2257.              iFCP session exists.
  2258.  
  2259.           Comment 111.       [T] Section 5.2.2.3, pp 35
  2260.  
  2261.              b) "An LTEST message is not received within twice the
  2262.                 specified interval or the iFCP session has been quiescent
  2263.                 for longer than twice the specified interval."
  2264.  
  2265.              I think "or" above should be "and" - else it implies that the
  2266.              LTEST message must be received periodically even in the
  2267.              presence of other traffic.
  2268.  
  2269.           Rejected
  2270.  
  2271.              See Comment 18.
  2272.  
  2273.              If liveness testing was requested for an iFCP session, an LTEST
  2274.              message must be received within twice the specified interval
  2275.              regardless of whether or not other traffic is present.
  2276.  
  2277.           Comment 112.       [T] Section 5.2.3, pp 37
  2278.  
  2279.              a) "An LS_RJT response is returned to the gateway that issued
  2280.                 the PLOGI ELS. The gateway SHALL forward the LS_RJT to the
  2281.                 local N_PORT and complete the session as described in..."
  2282.  
  2283.              My reading is that the gateway does not "issue" the PLOGI ELS,
  2284.              it merely facilitates the transport of an issued PLOGI ELS.
  2285.              The wording here is a little confusing - I also believe that
  2286.              the forwarding should be to the remote N_PORT, not local.
  2287.  
  2288.              [Also,] I recommend "terminate"/"close" in all the places
  2289.              "complete" is used.
  2290.  
  2291.           Accepted
  2292.  
  2293.              The text will be modified as follows:
  2294.  
  2295.              a) "An LS_RJT response is returned to the gateway from which
  2296.                 the PLOGI ELS originated. That gateway SHALL forward the
  2297.                 LS_RJT to the locally attached N_PORT and terminate the
  2298.                 session as described in..."
  2299.  
  2300.      Monia, et-al            Category - Expiration               [Page 39]
  2301.  
  2302.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  2303.  
  2304.  
  2305.           Comment 113.       [E] Section 5.2.3.1, pp 37, para 2
  2306.  
  2307.              "Unbind session control ELS as described in section 6.2."
  2308.  
  2309.              I am a little confused about the status of Unbind here - is it
  2310.              a FC-FS approved ELS or an iFCP session control message?
  2311.  
  2312.           Response
  2313.  
  2314.              Since Unbind is an iFCP session control message, the text will
  2315.              be changed to:
  2316.  
  2317.              "Unbind session control message as described in section 6.2."
  2318.  
  2319.           Comment 114.       [T] Section 5.2.3.2, pp 38, para 4
  2320.  
  2321.              "In any event, the TCP connection SHOULD be terminated with a
  2322.              connection reset (RST). If the local N_PORT has logged in to
  2323.              the remote N_PORT, the gateway SHALL send a LOGO to the local
  2324.              N_PORT."
  2325.  
  2326.              I think the draft should specify both OPEN and OPEN PENDING
  2327.              cases here.  For OPEN state, a local LOGO is required as
  2328.              stated, whereas for OPEN PENDING, a local LS_RJT may be
  2329.              appropriate.
  2330.  
  2331.              Also, it is useful to state that the proxied ELS (in either
  2332.              case) be indistinguishable from the end-to-end ELS in its
  2333.              payload (so any sanity checking done by endnode software would
  2334.              continue to work).
  2335.  
  2336.           Accepted
  2337.  
  2338.           Comment 115.       [T] Section 5.4.1, pp 40
  2339.  
  2340.              "Protocol# IANA-assigned protocol number identifying the
  2341.              protocol using the encapsulation. For iFCP the value is
  2342.              (/TBD/)."
  2343.  
  2344.              Should FCEncap document be referred here instead?
  2345.  
  2346.           Accepted
  2347.  
  2348.              See Comment 23.
  2349.  
  2350.           Comment 116.       [E] Section 5.4.3, pp 43, para 2
  2351.  
  2352.              "Following frame validation, the S_ID and D_ID fields in the
  2353.              frame header SHALL be referenced to lookup the iFCP session
  2354.              descriptor (see section 5.2.2.2). If no iFCP session descriptor
  2355.              exists, the frame SHALL be discarded."
  2356.  
  2357.              With the exception of PLOGI?
  2358.  
  2359.      Monia, et-al            Category - Expiration               [Page 40]
  2360.  
  2361.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  2362.  
  2363.  
  2364.           Accepted
  2365.  
  2366.              The specification will be modified to address the case where a
  2367.              frame triggers the creation of an iFCP session.
  2368.  
  2369.           Comment 117.       [E] Section 5.4.3, pp 43, para 3
  2370.  
  2371.              "Frames types submitted for encapsulation and forwarding on the
  2372.              IP..."
  2373.  
  2374.              "Frames" should be "Frame".
  2375.  
  2376.           Accepted
  2377.  
  2378.           Comment 118.       [E] Section 6, pp 44, para 1
  2379.  
  2380.              "TCP session control messages are used to create and manage an
  2381.              iFCP session as described in section 5.2.2. They are passed
  2382.              between peer iFCP Portals and are only processed within the
  2383.              iFCP layer.
  2384.  
  2385.              "The message format is based on the fibre channel extended link
  2386.              service message template shown below...."
  2387.  
  2388.              It may be useful to state that this message forms the "FC
  2389.              Frame" payload. of the iFCP frame. It may also be useful to
  2390.              state the value of LS_COMMAND in the encap header (0?).
  2391.  
  2392.              Instead of having two LS_COMMAND fields - one in the header and
  2393.              one in the payload - for these messages, a simpler approach
  2394.              could be to state that LS_COMMAND in the header contains an
  2395.              iFCP-defined value when SES=1 (and remove the one in the
  2396.              payload).
  2397.  
  2398.           Accepted in Part
  2399.  
  2400.              In accordance with Comment 26, the mnemonic for the LS_COMMAND
  2401.              field in the encapsulation header will be changed to eliminate
  2402.              confusion as follows:
  2403.  
  2404.              From section 5.4, Encapsulation of Fibre Channel Frames:
  2405.  
  2406.               "LS_COMMAND_ACC   For a special link service ACC
  2407.                                 response to be processed by iFCP, the
  2408.                                 LS_COMMAND_ACC field SHALL contain
  2409.                                 bits 31 through 24 of the LS_COMMAND
  2410.                                 to which the ACC applies. Otherwise
  2411.                                 this field shall be set to zero."
  2412.  
  2413.  
  2414.  
  2415.              From section 6, TCP Session Control Messages:
  2416.  
  2417.  
  2418.      Monia, et-al            Category - Expiration               [Page 41]
  2419.  
  2420.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  2421.  
  2422.  
  2423.               LS_COMMAND_ACC    0
  2424.  
  2425.  
  2426.  
  2427.              With the addition of the new mnemonic, the above text clearly
  2428.              specifies how the field is to be set.
  2429.  
  2430.           Comment 119.       [E] Section 6.1, pp 46, para 2
  2431.  
  2432.              "The following shows the format of the CBIND request."
  2433.  
  2434.              I take it that this CBIND structure goes into the Session
  2435.              Control Message starting from word 6?  Same question on CBIND
  2436.              response.
  2437.  
  2438.           Rejected
  2439.  
  2440.              That is correct.  The existing text seems to explain this
  2441.              adequately.
  2442.  
  2443.           Comment 120.       [T] Section 6.2, pp 49, para 1
  2444.  
  2445.              "UNBIND is used to release a bound TCP connection and.
  2446.              optionally, return it to the pool of unbound TCP connections."
  2447.  
  2448.              I assume "release" here implies - "remove the binding"?
  2449.  
  2450.              Is there a way to convey the preference to not terminate the
  2451.              connection on the part of the sender?  IOW, where is the
  2452.              optionality selected?
  2453.  
  2454.           Response
  2455.  
  2456.              See Comment 21 regarding the disposition of "unbound" TCP
  2457.              connections.  The above paragraph will be expanded to clarify
  2458.              the rationale for the unbound connection pool as follows:
  2459.  
  2460.              "UNBIND is used to terminate an iFCP session and disassociate
  2461.              the TCP connection. To expedite the creation of a new iFCP
  2462.              session, the TCP connection MAY remain open at the discretion
  2463.              of either gateway and kept in a pool of unbound connections.
  2464.  
  2465.              In order to recover resources, either gateway may spontaneously
  2466.              close the unbound TCP connection at any time."
  2467.  
  2468.           Comment 121.       [E] Section 6.2, pp 50, para 1
  2469.  
  2470.              "transmitted in the connection that is to be unbound. The
  2471.              time..."
  2472.  
  2473.              Change "in" to "on".
  2474.  
  2475.           Accepted
  2476.  
  2477.      Monia, et-al            Category - Expiration               [Page 42]
  2478.  
  2479.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  2480.  
  2481.  
  2482.           Comment 122.       [T] Section 8.2.1, pp 76, para 1
  2483.  
  2484.              "The R_A_TOV limit on frame lifetimes SHALL be enforced by
  2485.              means of the time stamp in the encapsulation header (see
  2486.              section 5.4.1 ) as described in this section."
  2487.  
  2488.              A couple of general questions on this section -
  2489.  
  2490.              a) Is Unsynchronized operation allowed?  If so, how is the
  2491.                 R_A_TOV expectation met?
  2492.  
  2493.              b) If an incorrect configuration causes the timestamp of the
  2494.                 incoming frame to be higher than the gateway's time base, it
  2495.                 is better if there is a way to detect and perhaps resync
  2496.                 both ends with the same SNTP server (as opposed to one out
  2497.                 of a list returned by iSNS).  As far as I can tell, the
  2498.                 current text specifies that it would simply cause the frames
  2499.                 to be discarded, but doesn't break the binding nor terminate
  2500.                 the TCP connection - perhaps relying on the end nodes to
  2501.                 LOGOUT?
  2502.  
  2503.           Accepted in Part
  2504.  
  2505.              For item a), see the response to Comment 35.
  2506.  
  2507.              For item b), iFCP specifies the following behavior:
  2508.  
  2509.              d) "If the incoming frame has a non-zero time stamp, the
  2510.                 receiving gateway SHALL compute the absolute value of the
  2511.                 time in flight and SHALL compare it against the value of
  2512.                 IP_TOV specified for the IP fabric.
  2513.  
  2514.              e) "If the result in step (d) exceeds IP_TOV, the encapsulated
  2515.                 frame shall be discarded.  Otherwise, the frame shall be
  2516.                 de-encapsulated as described in section ...."
  2517.  
  2518.              Since it is impossible to guarantee that one time reference
  2519.              won't be skewed negatively with respect to the other. the
  2520.              propagation delay test is against the absolute value of the
  2521.              time difference.
  2522.  
  2523.              The iFCP spec will be modified to state that an iFCP gateway
  2524.              implementation MAY terminate an iFCP session if the rate at
  2525.              which stale frames are detected exceeds some administratively-
  2526.              specified threshold.
  2527.  
  2528.      6. Security Considerations
  2529.  
  2530.         The applicable security provisions are defined in [IFCP].
  2531.  
  2532.      7. References
  2533.  
  2534.          [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
  2535.  
  2536.      Monia, et-al            Category - Expiration               [Page 43]
  2537.  
  2538.                  Responses to iFCP Rev. 10  Last Call Comments    May 2002
  2539.  
  2540.  
  2541.                  3", BCP 9, RFC 2026, October 1996.
  2542.  
  2543.          [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
  2544.                  Requirement Levels", BCP 14, RFC 2119, March 1997
  2545.  
  2546.          [IFCP] Monia, C., et al, ÷ iFCP - A Protocol for Internet Fibre
  2547.                  Channel Storage Networking", draft-ietf-ips-ifcp-10.txt,
  2548.                  February 2002
  2549.  
  2550.          [FC-FS] dpANS INCITS.XXX-200X, "Fibre Channel Framing and Signaling
  2551.                  Interface", Revision 1.7, NCITS Project 1331-D, February
  2552.                  2002
  2553.  
  2554.          [SECIPS] Aboba, B., et-al., "Securing Block Storage Protocols Over
  2555.                  IP", revision 11, February 2002
  2556.  
  2557.          [FC-GS3] dpANS X3.XXX-200X, "Fibre Channel Generic Services -3 (FC-
  2558.                  GS3)", revision 7.01, NCITS Project 1356-D, November 2000
  2559.  
  2560.  
  2561.  
  2562. 8. Author's Addresses
  2563.  
  2564.         Charles Monia                Franco Travostino
  2565.         Josh Tseng                   Director, Content
  2566.                                       Internetworking Lab,
  2567.         Nishan Systems               Nortel Networks
  2568.         3850 North First Street      3 Federal Street
  2569.         San Jose, CA  95134          Billerica, MA  01821
  2570.         Phone: 408-519-3986          Phone:  978-288-7708
  2571.         Email:                       Email:
  2572.         cmonia@nishansystems.com     travos@nortelnetworks.com
  2573.  
  2574.  
  2575.  
  2576. Full Copyright Statement
  2577.  
  2578.    "Copyright (C) The Internet Society May 2002. All Rights Reserved.
  2579.    This document and translations of it may be copied and furnished to
  2580.    others, and derivative works that comment on or otherwise explain it
  2581.    or assist in its implmentation may be prepared, copied, published
  2582.    and distributed, in whole or in part, without restriction of any
  2583.    kind, provided that the above copyright notice and this paragraph
  2584.    are included on all such copies and derivative works. However, this
  2585.    document itself may not be modified in any way, such as by removing
  2586.    the copyright notice or references to the Internet Society or other
  2587.    Internet organizations, except as needed for the purpose of
  2588.    developing Internet standards in which case the procedures for
  2589.    copyrights defined in the Internet Standards process must be
  2590.    followed, or as required to translate it into languages other than
  2591.    English.
  2592.  
  2593.  
  2594.  
  2595.      Monia, et-al            Category - Expiration               [Page 44]
  2596.  
  2597.             Responses to iFCP Rev. 10  Last Call Comments    May 2002
  2598.  
  2599.  
  2600.    The limited permissions granted above are perpetual and will not be
  2601.    revoked by the Internet Society or its successors or assigns.
  2602.  
  2603.    This document and the information contained herein is provided on an
  2604.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  2605.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  2606.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  2607.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  2608.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
  2609.  
  2610.  
  2611.  
  2612.  
  2613.  
  2614.  
  2615.  
  2616.  
  2617.  
  2618.  
  2619.  
  2620.  
  2621.  
  2622.  
  2623.  
  2624.  
  2625.  
  2626.  
  2627.  
  2628.  
  2629.  
  2630.  
  2631.  
  2632.  
  2633.  
  2634.  
  2635.  
  2636.  
  2637.  
  2638.  
  2639.  
  2640.  
  2641.  
  2642.  
  2643.  
  2644.  
  2645.  
  2646.  
  2647.  
  2648.  
  2649.  
  2650.  
  2651.  
  2652.  
  2653.  
  2654. Monia, et-al            Category - Expiration               [Page 45]
  2655.