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

Versions: 00 01 02

IPS Working Group                                               R. Weber
INTERNET-DRAFT
<draft-ietf-ips-fcip-wglc-02.txt>
(Expires November, 2002)


                         FCIP 1st WG Last Call

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as Reference
   material or to cite them other than as "work in progress".

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

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


Abstract

   This ips (IP Storage) working group draft contains all the working
   group last call comments received regarding:

            draft-ietf-ips-fcovertcpip-09.txt

   The proposed disposition of each comment also is recorded in this
   draft.


Summary of Comments

   Technical:  30 Comments, resulting in about  37 Changes
   Editorial: 112 Comments, resulting in about  84 Changes
   -------------------------------------------------------
     Totals:  142 Comments, resulting in about 121 Changes




Ralph Weber                                                     [Page 1]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Table Of Contents

   1. Comments from David Black  . . . . . . . . . . . . . . . . . . . 2
   2. Comments from Mallikarjun Chadalapaka . . . . . . . . . . . . . 47
   3. Comments from Don Fraser  . . . . . . . . . . . . . . . . . . . 70
   4. Comments from Murali Rajagopal  . . . . . . . . . . . . . . . . 71
   5. Comments from Bob Snively . . . . . . . . . . . . . . . . . . . 71
   6. Comments from Ralph Weber . . . . . . . . . . . . . . . . . . . 72


1. Comments from David Black
   =========================

Comment 1

   ----- Title Page -----

           E. Rodriguez, ips Liaison

   [E] What sort of title is that? This looks like an invitation
   to IESG approval trouble.

   Accepted with the following results

   Change "Liaison" to "Co-chair".

Comment 2

   -- Section 1 - Editors and Contributors

   [E] A bit wordy, but basically ok. Please take out the
   Internet-Draft references.

   Accepted with the following results

   1) Change "draft-ietf-ips-fcip-slp-___.txt" to "the FCIP SLP
      internet-draft"; and
   2) Change "draft-ietf-ips-fcip-mib-___.txt" to "the FCIP MIB
      internet-draft".











Ralph Weber                                                     [Page 2]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 3

   -- Section 1 - Editors and Contributors

      Several T11 leaders supported this effort and advised the editors
      of this specification regarding appropriate interfaces to T11
      documents.

   [E] Is "leaders" the right T11 title? Let's make sure the right word
   is used.
   Also I think "coordination with T11 documents and projects" might be
   better phrasing than "appropriate interfaces...".

   Accepted (Partially)

   I can think of no better word than "leaders". The only correct
   replacement I can think of is "chairs, vice-chairs, secretaries,
   facilitators, and document editors". I will make that change but
   only if mandated to do so.

   Change "...regarding appropriate interfaces to T11 documents." to
   "...regarding coordination with T11 documents and projects."

Comment 4

   -- Section 4 - Terminology
   (really Section 2 - Purpose, Motivation and Objectives)

   [E] Some of these [section 4] definitions implicitly exclude FC-AL,
   or at least the private (i.e., non-fabric) use of FC-AL across
   FC-IP. Section 2 would be a good place to make this exclusion
   explicit.

   Accepted with the following results

   Add the following new paragraph at the end of section 2: "The
   objectives of this document do not include using an IP Network as
   a replacement for the Fibre Channel Arbitrated Loop interconnect.
   No definition is provided for encapsulating loop primitive signals
   for transmission over an IP Network.










Ralph Weber                                                     [Page 3]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 5

   -- Section 3.2 - This Specification and Fibre Channel Standards

      No attempt is being made to define a specific API between an FCIP
      Entity and an FC Entity at this time because doing so risks
      compromising the performance and efficacy of the resulting
      products. Current experience in this area is simply insufficient
      to guide definition of the interface appropriately.

   [E] That's a bit negative. Please add some text indicating that the
   approach is to specify the functional interaction that is required,
   but allow implementers to choose how this will be realized.

   Accepted with the following results

   Replace the cited paragraph with: "   No attempt is being made to
   define a specific API between an FCIP Entity and an FC Entity. The
   approach is to specify required functional interactions between an
   FCIP Entity and an FC Entity (both of which are required to forward
   FC frames across an IP Network), but allow implementers to choose
   how this will be realized."

Comment 6

   -- Section 3.2 - This Specification and Fibre Channel Standards

      The objectives and motivations of this specification are not
      impacted by the decision not to standardize a specific API between
      FCIP Entities and FC Entities because fully functional and
      compliant products can be built provided they contain both an FCIP
      Entity and an FC Entity. The only products that cannot be built
      are those that contain only one or the other.

   [E] I don't like the product focus of this language. The basic point
   here is that in order to realize the full functionality of forwarding
   frames between FC and IP networks, both an FC Entity and an FCIP
   Entity are required. If someone wants to build something that only
   contains one of these, the fact that it won't have this functionality
   is their problem, not ours.

   Accepted with the following results

   This paragraph was intended to be the positive paragraph following
   on the negative paragraph cited in comment 5. Since the changes
   undertaken in response to comment 5 make that paragraph positive,
   the bulk of this paragraph is no longer needed.



Ralph Weber                                                     [Page 4]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


   A few of the critical thoughts from the comment have been added
   to the revised paragraph in the response to comment 5. With those
   changes in place, the cited paragraph will be deleted.

Comment 7

   -- Section 4 - Terminology

      Terms needed to clarify the concepts presented in FCIP are
      defined here.

   [E] I don't like the usage of "clarify". How about "Terms used to
   describe FCIP concepts are defined in this section."?

   Accepted, make change exactly as proposed.

Comment 8

   -- Section 4 - Terminology

      FC Entity - The Fibre Channel specific element that combines with
      an FCIP Entity to form an interface between an FC Fabric and an IP
      Network (see section 6.3).

   [E] I think "element" is problematic in this definition, because it
   implies "fabric element" and leads to the sort of confusion that
   Mallikarjun got into. How about "functional component"?

   Accepted, make change exactly as proposed.

Comment 9

   -- Section 4 - Terminology

      FC Receiver Portal - The access point through which an FC Frame
      and time stamp enters an FCIP Data Engine from the FC Entity.

      FC Transmitter Portal - The access point through which a
      reconstituted FC Frame and time stamp leaves an FCIP Data Engine
      to the FC Entity.

   [E] For clarity, shouldn't both of those terms be "FCIP" rather than
   "FC" to avoid any possible confusion with transmission and reception
   of FC frames on an FC fabric?

   Accepted but only in principle

   Change "FC" to "FC Frame" in these terms throughout the draft.


Ralph Weber                                                     [Page 5]


Internet-Draft              FCIP 1st WG Last Call              May, 2002



   Inspection of the Portal names shows that "FC" is shorthand for "FC
   Frame", not for "FCIP".

Comment 10

   -- Section 4 - Terminology

      FCIP Entity - The principal FCIP interface point to the IP Network
      (see section 6.4).

   [E] Definition needs to parallel FC Entity definition including
   "functional component" language (or whatever term/phrase is chosen).

   Accepted, make change exactly as proposed.

Comment 11

   -- Section 4 - Terminology

      FCIP Frame - An FC Frame plus the FC Frame Encapsulation [27]
      header and encoded EOF that contains the FC Frame (see section
      6.6.1).

   [E] What about SOF?

   Accepted

   Add "encoded SOF" in the right place.

Comment 12

   -- Section 4 - Terminology

      FCIP Link Endpoint (FCIP_LEP) - The component of an FCIP Entity
      that contains one or more FCIP_DEs (see section 6.5).

   [E] Needs to say something about its relationship to FCIP Links.

   Accepted with the following results

   Change "...that contains one..." to "...that handles a single FCIP
   Link and contains one..."







Ralph Weber                                                     [Page 6]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 13

   -- Section 4 - Terminology

      Special Frame (SF) - A specially formatted FCIP frame containing
      information used by the FCIP protocol (see section 8).

   [E] I suggest prefixing FCIP to this term for clarity.

   Accepted with the following results

   1) Change "Special Frame (SF)" to "FCIP Special Frame (FSF)"
   throughout the draft; and

   2) Limit usage of spelled out FCIP Special Frame to once per section
   and sections titles.

Comment 14

   -- Section 5 Protocol Summary

      2)  Viewed from the IP Network perspective, FCIP Entities are
          peers and communicate using TCP/IP. Each FCIP Entity is a
          TCP endpoint in the IP-based network.

   [E] TCP endpoint is not the right language, as this implies endpoint
   of a single TCP connection. Probably needs to be described in terms
   of TCP ports.

   Accepted with the following results

   Change "...is a TCP endpoint..." to "...contains one or more TCP
   endpoints..."

















Ralph Weber                                                     [Page 7]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 15

   -- Section 5 Protocol Summary

      3)  Viewed from the FC Fabric perspective, pairs of FCIP Entities,
          in combination with their associated FC Entities, serve as an
          FC Frame transmission component of the FC Fabric. The FC End
          Nodes are unaware of the existence of the FCIP Link.

   [E] "FC frame transmission component" is a bit abstract. Can we say
   that it forwards frames between two FC ports, e.g., E_Ports? Note
   the use of the e.g., to avoid limiting this to E_Ports.

   Accepted but only in principle

   Change "...serve as an FC Frame transmission component of the FC
   Fabric." to "...forward FC Frames between FC Fabric elements."

   Since comment 8 states that "element" has a well known meaning, use
   of that term here should not raise objections.

   Meticulous effort has gone into avoiding use of E_Port and B_Port
   in this draft and a very good reason will have to be offered to get
   either term in.

Comment 16

   -- Section 5 Protocol Summary

      7)  When multiple FCIP_LEPs with multiple FCIP_DEs are in use,
          selection of which FCIP_DE to use for encapsulating and
          transmitting a given FC Frame is outside the scope of this
          document. FCIP Entities do not actively participate in FC Frame
          routing.

   [E] Does anything need to be said about requirements for or
   desirability of preserving the order in which frames are forwarded.

   Response

   No. The fact that TCP keeps all the sent on one TCP Connection in
   order is covered elsewhere here. All other frame ordering concerns
   are covered in FC-BB-2.







Ralph Weber                                                     [Page 8]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 17

   -- Section 5 Protocol Summary

      8)  The FCIP Control & Services function MAY use TCP/IP quality of
          service features (see section 11.2) to support Fibre Channel
          capabilities.

   [E] This isn't quite right, as it seems to imply that FC has some
   features that map onto TCP/IP QoS features. Needs some editorial
   tweaking.

   Accepted with the following results

   Delete everything after the section reference.

Comment 18

   -- Section 5 Protocol Summary

      9)  Each FCIP Entity is statically or dynamically configured with
          a list of IP addresses and TCP port numbers corresponding
          to participating FCIP Entities. If dynamic discovery of
          participating FCIP Entities is supported, the function SHALL
          be performed using the Service Location Protocol (SLPv2) [25].
          It is outside the scope of this specification to describe any
          static configuration method for participating FCIP Entity
          discovery. Refer to section 9.1.2.2 for a detailed description
          of dynamic discovery of participating FCIP Entities using
          SLPv2.

   [E] There's a requirement lurking in here. One way to express it
   would be to change the first "is" to "MUST be".

   Accepted with the following results

   Replace the first sentence in the cited text with: "It is necessary
   to statically or dynamically configure each FCIP entity with the IP
   addresses and TCP port numbers corresponding to FCIP Entities with
   which it is expected to initiate communication."










Ralph Weber                                                     [Page 9]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 19

   -- Section 5 Protocol Summary

      10) Before creating a TCP Connection to a peer FCIP Entity, the
          FCIP Entity attempting to create the TCP connection SHALL
          statically or dynamically determine the IP address, TCP port,
          expected FC Fabric Entity World Wide Name, TCP Connection
          Parameters, and Quality of Service Information.

   [E] Need to get the "configuration" word in here, as this is
   describing a requirement on the configuration mechanisms in 9), and
   consider rephrasing this to make the connection clearer.

   Rejected

   Item 9) in the list describes configuration. This item describes
   what is required in order to make a TCP connection and send the
   Special Frame.

Comment 20

   -- Section 5 Protocol Summary

      13) On a given TCP Connection, this specification relies on TCP/IP
          to deliver a byte stream in the same order that it was sent.

   [E] "a given" --> "an individual" for clarity.

   Accepted




















Ralph Weber                                                    [Page 10]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 21

   -- Section 5 Protocol Summary

      14) This specification defines only limited error detection and
          recovery mechanisms and relies on both TCP and FC to handle
          data loss and corruption within the IP Network.

   [E] I'd rephrase this to talk about mechanisms that are complementary
   to the existing TCP/IP and FC mechanisms, and that this specification
   assumes the presence and requires the use of those existing
   mechanisms.

   Accepted with the following results

   Replace the cited paragraph with: "14) This specification assumes
   the presence of and requires the use of TCP and FC data loss and
   corruption mechanisms. The error detection and recovery features
   described in this specification complement and support these
   existing mechanisms."

Comment 22

   -- Section 6.1 - FCIP Protocol Model

   [E] Need to define every acronym in Figure 1 and make it clear that
   the FCIP Link is implemented via the IP Network Link. Consider using
   "Fibre Channel Fabric" instead of "Fibre Channel Environment" for
   consistency.

   Accepted (Partially)

   No changes will be made to "make it clear that the FCIP Link is
   implemented via the IP Network Link". This is a relatively standard
   network layering diagram. The notation is consistent already in
   place is 100% consistent with that concept.

   Actions to be taken:

   1) Add a key at the bottom of the figure; and
   2) Change "Environment" to "Fabric".









Ralph Weber                                                    [Page 11]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 23

   -- Section 6.3 - FC Entity

      A product that tunnels an FC Fabric through an IP Network MUST
      combine an FC Entity with an FCIP Entity (see section 6.4) to form
      a complete interface between the FC Fabric and IP Network as shown
      in figure 3.

   [E] Again, I don't like the use of "product". How about
   "implementation"?

   Accepted, make change exactly as proposed.

Comment 24

   -- Section 6.3 - FC Entity

      In general, the combination of an FCIP Link and FC and FCIP
      Entities is intended to replace a Fibre Channel defined connection
      between Fibre Channel components. For example, this combination
      can be used to replace a hard-wire connection between two Fibre
      Channel switches. There are limitations on the generally intended
      usage of the combination shown in figure 3. As another example,
      the combination cannot be used to replace cable connections in a
      Fibre Channel Arbitrated Loop because loop primitive signals
      cannot be encapsulated for transmission over TCP.

   [E] I think "replace" is the wrong verb. For example, if the
   distance is well over 10km, it's not possible to have an FC
   connection to replace. I would rewrite this in terms of "function
   as" rather than "replace". I don't understand the "There are
   limitations ..." sentence. As noted earlier the absence of support
   for FC-AL should be stated in Section 2.

   Accepted with the following results

   1) Replace the first cited sentence with: "In general, the
      combination of an FCIP Link and FC/FCIP Entities is intended
      to provide a non- Fibre Channel backbone transport between
      Fibre Channel components.";
   2) In the second cited sentence change "replace" to "function
      as"; and
   3) Delete all text from "There are limitations..." to the end of
      the paragraph. (Note this works because comment 4 puts the FC-AL
      limitation in section 2.)




Ralph Weber                                                    [Page 12]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 25

   -- Section 6.3 - FC Entity

      The interface between the FC and FCIP Entities is implementation
      specific. The minimum requirements placed on an FC Entity by this
      specification are listed in annex G.

   [E] Suggest changing "minimal" to "functional".

   Accepted

Comment 26

   -- Section 6.4 - FCIP Entity

   [E] In Figure 4, suggest changing "TCP connect request IP address and
   port" to "TCP port for incoming connections". The implicit need for
   an IP address should be obvious to the reader, or can be explained in
   the text.

   Accepted

Comment 27

   -- Section 6.4 - FCIP Entity

      The FCIP Entity is the connection interface point for the IP
      Network and is the owner of the IP Address and Well Known Port used
      to form TCP Connections.

   [E] That language isn't quite right. It owns the TCP port at that IP
   address, but does not need to exclusively own the IP address.

   Accepted with the following results

   Change "...is the owner of the IP Address and Well Known Port used
   to form..." to "...is the owner of the Well Known Port at an IP
   Address used to form...".











Ralph Weber                                                    [Page 13]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 28 Technical

   -- Section 6.4 - FCIP Entity

      The interfaces to the IP Network features is implementation
      specific, however, to maintain interoperability, the notable
      TCP/IP mechanisms used are specified in this document as follows:

   [E] I'd rephrase this to talk about "REQUIRED functional support" and
   remove the "to maintain interoperability" language.

   Accepted with the following results

   1) Change "is" to "are";
   2) Replace everything from "however" to the end of the cited text
      with: "however, REQUIRED TCP/IP functional support is specified
      in this document, including:"

Comment 29

   -- Section 6.5 - FCIP Link Endpoint (FCIP_LEP)

      An FCIP_LEP MAY communicate with its FC Entity counterpart to
      coordinate flow control.

   [E] Insert "local" before "FC Entity" to make it clear that this
   communication does not occur over the IP network.

   Accepted

Comment 30

   -- Section 6.6 - FCIP Data Engine (FCIP_DE)

      Data flows through the FCIP_DE in the following seven steps:

   [E] The text that follows this actually describes data flow through a
   pair of FCIP_DEs connected across an IP network - this sentence needs
   to be revised accordingly.

   Accepted with the following results

   Replace "...the FCIP_DE..." with "...a pair of IP Network connected
   FCIP_DEs..."






Ralph Weber                                                    [Page 14]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 31

   -- Section 6.6 - FCIP Data Engine (FCIP_DE)

      Table 2 shows the SOF and EOF code values that are legal in FCIP
      Frames. This list may be a subset of the SOF and EOF codes listed
      in the FC Frame Encapsulation [27].

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

   Accepted (Partially) with the following results

   Replace the cited text with: "In FCIP, the Class 2, Class 3, and
   Class 4 SOF and EOF codes listed in the FC Frame Encapsulation [27]
   are legal.

   Note: This change depends on adding the Class column in the FC Frame
   Encapsulation draft.

Comment 32

   -- Section 6.6.2.1 - TCP Assistance With Error Detection and
    Recovery

      TCP [8] requires in order delivery, generation of TCP checksums,
      and checking of TCP checksums. Thus, the byte stream passed from
      TCP to the FCIP_LEP will be in order and free of errors detectable
      by the TCP checksum. If TCP did not perform these functions, the
      FCIP_LEP would have to.

   [E] Strengthen the last sentence to indicate that the FCIP_LEP relies
   upon TCP performing these functions.

   Accepted with the following results

   Replace the cited last sentence with: "The FCIP_LEP relies on TCP
   performing these functions."








Ralph Weber                                                    [Page 15]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 33

   -- Section 6.6.2.2 - Errors in FCIP Headers and Discarding FCIP
    Frames

      1)  Length field validation -- 15 < Length < 545;

   [E] Explain where the 15 and 545 values come from.

   Accepted with the following results

   Add a note following the list that derives the values.

Comment 34 Technical

   -- Section 6.6.2.2 - Errors in FCIP Headers and Discarding FCIP
    Frames

      In addition to the tests above, the validity and positioning of
      the following FCIP Frame information SHOULD be used to detect
      encapsulation errors that may or may not affect synchronization:

      a)  Protocol # field and its ones complement (2 tests);
      b)  Version field and its ones complement (2 tests);
   [... list continues, snipped ...]

   [T] I think at least these two are MUSTs. At a minimum, the
   Protocol# and Version field must be checked against expected values -
   I might accept the checks against their ones complements being
   SHOULDs. Same comment applies to the Flags field and SOF. Someone
   MUST check the FC frame CRC before forwarding the frame, but that
   responsibility could be assigned to the FC Entity.

   Accepted (Partially) with the following results

   1) Add to 6.6.2.2 checking Protocol# and Version#. This addition
      will have to be in a separate paragraph before the current 1),
      2), 3) list because it is not a synchronization issue;
   2) Keep the one's complement tests in the SHOULD a), b), c) list,
      but reduce the number of tests in that list by 2 (1 in a and
      1 in b); and
   3) Change the count of optional tests required from "5 of 18" to
      "3 of 18".
   4) Add the following after the tests are described: "Note: The
      process of selecting an 8b/10b encoding for the SOF by
      necessity includes some validation of the SOF fields."




Ralph Weber                                                    [Page 16]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


   Responses to other issues raised by comment

   a) The Flags field is not a MUST test because it provides no
      certain identification of the protocol beyond that provided by
      the Protocol# field; and
   b) Not even the Fibre Channel standards require that the FC CRC
      be validated by FC Fabric elements. FC Endnode validation of
      the FC CRC is sufficient.


Comment 35 Technical

   -- Section 6.6.2.2 - Errors in FCIP Headers and Discarding FCIP
    Frames

      At least 5 of the 18 tests listed above SHALL be performed.
      Failure of any of the above tests actually performed SHALL
      indicate an encapsulation error and the frame SHALL NOT be
      forwarded on to the FC Entity. Further, such errors SHOULD be
      considered carefully, since some may be synchronization errors.

   [T] There aren't 18 tests, and I think some of the individual tests
   (or subsets) are MUSTs (see previous comment). This needs to be gone
   over carefully - in essence a MUST is only appropriate where failure
   to apply the test carries a non-negligible risk of forwarding a bad
   frame to FC.
   The authors are the experts on this and need to do this analysis. I
   don't understand the last "SHOULD" - what is the (testable)
   requirement on an implementation?

   No changes made

   There are 18 tests: 2 + 2 + 1 + 2 + 2 + 1 + 4 + 1 + 2 + 1 = 18

   What tests are MUSTs is covered by comment 34.

   The authors have gone over the tests carefully and have concluded
   that no individual test or specific group of tests associates
   specifically with a non-negligible risk of forwarding a bad frame
   to FC. The requirement is that a suitable number (at least 5, or
   12 when the 7 required tests are included) tests is necessary to
   reduce the risk of forwarding a bad frame to FC to a negligible
   level. The specific tests selected depends on the implementation,
   i.e., what test can be performed most efficiently in the
   implementation hardware.

   The "SHOULD" statement is intended to guide implementations.
   Repeated failures of, for example, the CRC equal to zero test may


Ralph Weber                                                    [Page 17]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


   mean that synchronization has been lost. There are no hard and fast
   rules here.

Comment 36 Technical

   -- Section 6.6.2.3 - Synchronization Failures

      If the FCIP_DE attempts to recover synchronization, the
      resynchronization algorithm used SHALL meet the following
      requirements:

   [T] One requirement is missing, which may be part of b):

      b)  return to sending valid FC Frames only after synchronization
          has been verified; and

   [T] Verification of synchronization MUST exclude any possibility of
   forwarding an FC frame that was not sent by the transmitting FCIP
   Entity. This includes the scenario in which a valid encapsulated FCIP
   frame occurs in the payload of an FC frame that is encapsulated and
   sent over FCIP; excluding this scenario is necessary but not
   sufficient to meet the requirement.

   Accepted with the following results

   Replace b) with: "return to forwarding FC Frames only after
   synchronization on the transmitted FCIP Frame stream has been
   verified; and"

Comment 37 Technical

   -- Section 6.6.2.3 - Synchronization Failures

      An example algorithm meeting these requirements can be found in
      annex C.

   [T] That doesn't meet the missing requirement that my above
   comment wants to add. The problem is at step 2 of the algorithm
   description.

      2)  Use multiple strong candidate headers to locate a verified
          candidate header:

          The Frame Length in one strong candidate header is used to skip
          incoming bytes until the expected location of the next strong
          candidate header is reached. Then the tests described in step
          1) are applied to see if another strong candidate header has
          successfully been located.


Ralph Weber                                                    [Page 18]


Internet-Draft              FCIP 1st WG Last Call              May, 2002



   The "skip incoming bytes" step makes it possible that a set of valid
   FC headers is interlaced in the payloads of FC frames in a fashion
   that causes all the real headers to be skipped. This is a rather
   unlikely, but not impossible scenario. This could be dealt with by
   searching for headers instead of skipping data and aborting if a
   header is found where data should have been or carrying on and
   aborting if an interlaced header chain scenario arises. The
   algorithm in Annex C does address the scenario of FCIP frames
   occurring in FC frame payloads, but it doesn't meet the "can't be
   fooled" requirement that I think should be added.

   Unfortunately, this issue appears to not be resolvable within the WG.
   I have had heated and lengthy offline discussion with the FCIP
   Authors in which they have made clear their strong opposition to the
   "missing requirement" and the need to scan rather than skip data, and
   have argued that the algorithm in Annex C produces a long enough
   chain of headers that the odds of having followed a chain that is
   interlaced through frame payloads is small enough to be ignored.
   I will have to consult the Area Directors.

   Accepted with the following comment

   Modifications to either step 2 or step 3 will achieve the requested
   results. Because step 3 already includes complex steps such as
   verifying the FC CRC value, changes in response to the comment will
   be made in step 3.

   Actions to be taken

   1) Change the first paragraph of Annex C step 3 from:

       "Incoming bytes are skipped and discarded until the next
       verified candidate header is reached. Each verified candidate
       header is tested against the full collection of tests listed in
       section 6.6.2.2 as would normally be the case."

   to:

       "Incoming bytes are inspected and discarded until the next
       verified candidate header is reached. Inspection of the incoming
       bytes includes testing for other candidate headers using the
       criteria described in step 1. Each verified candidate header is
       tested against the tests listed in section 6.6.2.2 as would
       normally be the case."





Ralph Weber                                                    [Page 19]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


   2) Change the second sentence in the third paragraph of Annex C
      step 3 from:

       "If any verified candidate headers are invalid and fail to meet
       the tests for a strong candidate header, increment the retry
       counter and return to step 1."

   to:

       "If any verified candidate headers are invalid and fail to
       meet the tests for a strong candidate header or inspection
       of the bytes between verified candidate headers discovers
       any candidate headers, increment the retry counter and
       return to step 1."

Comment 38 Technical

   Section 7 - Checking FC Frame Transit Times in the IP Network

      The FC Entity MUST implement the measurement of Fibre Channel
      frame IP Network transit time as described in the FC Frame
      Encapsulation [27] specification.

   [E] "MUST implement" --> "MUST implement and use" for clarity.

   Accepted but not as the comment intended

   The statement is misleading and needs to be revised.

   Action to be taken

   Replace the cited sentence with: "FC-BB-2 [4] defines how the
   measurement of IP Network transit time is performed, based on
   the requirements stated in the FC Frame Encapsulation [27]
   specification.

   Additional note

   See comment 40 for a discussion of why IP Network transit time
   checking is done by the FC Entity.










Ralph Weber                                                    [Page 20]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 39

   Section 7 - Checking FC Frame Transit Times in the IP Network

      If no synchronized time stamp value is available to accompany
      the entering FC Frame a value of zero SHALL be supplied.

   [E] "supplied" --> "used" for clarity.

   Accepted

Comment 40 Technical

   Section 7 - Checking FC Frame Transit Times in the IP Network

      The FC Entity SHALL use suitable internal clocks and either Fibre
      Channel services or an SNTP Version 4 server [13] to establish and
      maintain the required synchronized time value. The FC Entity SHALL
      verify that the FC Entity it is communicating with on an FCIP Link
      is using the same synchronized time source as it is, either Fibre
      Channel services or SNTP server.

   [T] I don't believe that this paragraph meets the requirements in the
   FC Frame Encapsulation specification for processing transit time
   information. Punting this up to the FC Entity is problematic -
   the minimum functional requirements on the FC Entity to meet the
   FC Frame Encapsulation requirements will need to be spelled out here
   in detail (i.e., a single sentence saying "must meet requirements in
   Section 4 of the FC Frame Encapsulation document" is probably not
   going to fly). Mallikarjun caught some issues in this area also.

   Rejected

   The decision to move time validation from FCIP to FC-BB-2 was made
   for sound technical reasons:

   1) Having the FC Entity verify transit time makes the test more
      end-to-end;
   2) Class F frames need not have their transit time verified. That
      decision is allowed by the FC Frame Encapsulation. Encoding that
      test in FCIP would necessitate a substantial increase in the
      FCIP reliance on FC specific knowledge, including but not limited
      to cracking FC Frames;
   3) Allowing Class F frames to transit without transit time
      verification is required to allow the FC Time Service to be
      used as a source of synchronized time, a critical feature for
      the success of FCIP; and



Ralph Weber                                                    [Page 21]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


   4) The description of the interactions between the FC Entity and
      FCIP Entity for the purpose of maintaining a synchronized time
      based on the FC Time Service were getting impossible to verify
      for correctness when the requirements were stated in FCIP.

   Having the FCIP Entity perform transit time tests was in the FCIP
   draft as recently as draft-ietf-ips-fcovertcpip-05.txt. The
   requested organization was tried and proved to be unworkable.

Comment 41

   -- Section 8 - The FCIP Special Frame

   [T] How is the FCIP Special Frame payload protected? I don't see the
   equivalent of an FC Frame CRC.

   Inquiry

   The Special Frame is protected by requiring that the connection be
   closed if the echoed SF differs from the transmitted SF. This is
   deemed to be a more rigorous test than any CRC.

Comment 42

   -- Section 8 - The FCIP Special Frame

      |------------------------------Bit------------------------------|
      |                                                               |
      |   31      30      29      28      27      26      25      24  |
      +-------+-------+-------+-------+-------------------------------+
      |  SOFf | SOF?2 | SOF?3 | SOF?4 |            Reserved           |
      +-------+-------+-------+-------+-------------------------------+

          Fig. 10  Connection Usage Flags Field Format

   [E] I don't think the "?"s were intended and suspect that MS Word or
   some other tool has been a little too helpful :-).

   Inquiry

   The question marks were intended to have the classic meaning of
   question mark in a file specification. SOF?2 == SOFi2 or SOFn2.








Ralph Weber                                                    [Page 22]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 43 Technical

   -- Section 8 - The FCIP Special Frame

      The Connection Usage Code field contains Fibre Channel defined
      information regarding the intended usage of the connection as
      specified in FC-BB-2 [4].

   [T] The authors need to talk to me about this, so that I can
   understand what's going on here, and whether we need another IANA
   registry, as is the case for the SOF and EOF values.

   No changes made

   The Connection Usage Code field allows pairs of FC Entities to
   communicate 16-bits of connection setup information in the Special
   Frame. It represents a request that the FC-BB-2 side of the house
   made on the FCIP side. Given that FC-BB-2 is defining a whole new
   SW_ILS to support a request made in the reverse direction, it is
   difficult to see why the presence of the Connection Usage Code
   field is an issue.

Comment 44 Technical

   -- Section 8 - The FCIP Special Frame

   [T] This section needs to describe the usage of the FCIP Special
   Frame, including the structure of the interaction between the two FCIP
   Entities, and how that establishes the security and connection usage
   properties that are desired. The descriptions in Section 9 contain a
   great deal of detail that mixes several mechanisms together - a high
   level guide to what's going on is necessary to understand them.

   Accepted with the following results

   It is considered desirable to leave the Special Frame open to
   additional uses in future versions of FCIP. This is why Section 8
   lacks the requested overview.

   Actions to be taken

   1) Put the current Section 8 text in 8.1 "Special Frame Format";
   2) Add 8.2 "Overview of Special Frame Usage in Connection
      Establishment"; and
   3) Be sure to discuss the issues raised in comment 52,
      comment 53, and comment 109 in the new section.

   The text for the new section is proposed to be the following:


Ralph Weber                                                    [Page 23]


Internet-Draft              FCIP 1st WG Last Call              May, 2002



   8.2 Overview of FSF Usage in Connection Establishment

   When a new TCP Connection is established, an FCIP Special Frame
   makes one round trip from the FCIP Entity initiating the TCP connect
   operation to the FCIP Entity receiving the TCP connect request and
   back. This FSF usage serves three functions:

     - Identification of the FCIP Link endpoints
     - Conveyance of a few critical parameters shared by the FC/FCIP
       Entity pairs involved in the FCIP Link
     - Configuration discovery (used in place of SLP only when
       allowed by site security policies)

   The specific requirements for this usage of the FSF are found in
   section 9.1. This section provides an overview of the FSF usage
   without stating requirements.

   Because FCIP is only a tunnel for a Fibre Channel Fabric and because
   the Fabric has its own complex link setup algorithm that can be
   employed for many FCIP link setup needs, it is desirable to minimize
   the complexity of the FSF usage during TCP Connection setup. With
   this in mind, this FSF usage is not a login or parameter negotiation
   mechanism. A single FSF transits each newly established TCP
   connection as the first bytes sent in each direction.

   Note: This usage of the FSF cannot be eliminated entirely because a
   newly created TCP Connection must be associated with the correct
   FCIP Link before FC Fabric initialization of the connection can
   commence.

   The first bytes sent from the TCP connect request initiator to the
   receiver are an FSF identifying both the sender and who the sender
   thinks is the receiver. If the contents of this FSF are correct and
   acceptable to the receiver, the unchanged FSF is echoed back to the
   sender. This send/echo process is the only set of actions that
   allows the TCP Connection to be used to carry FC Fabric traffic. If
   the send and unchanged echo process does not occur, the algorithm
   followed at one or both ends of the TCP Connection results in the
   closure of the TCP Connection (see section 9.1 for specific
   algorithm requirements).

   Note: Owing to the limited manner in which the FSF is used and the
   requirement that the FSF be echoed without changes before a TCP
   Connection is allowed to carry user data, no error checking beyond
   that provided by TCP is deemed necessary.

   As described above, the primary purpose of the FSF usage during TCP


Ralph Weber                                                    [Page 24]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


   Connection setup is identifying the FCIP Link to which the new TCP
   Connection belongs. From these beginnings, it is only a small
   stretch to envision using the FSF as a simplified configuration
   discovery tool, and the mechanics of such a usage are described in
   section 9.1.

   However, use of the FSF for configuration discovery lacks the broad
   range of capabilities provided by SLP v2 and most particularly lacks
   the security capabilities of SLP v2. For these reasons, using the
   FSF for configuration discovery is not appropriate for all
   environments. Thus the choice to use the FSF for discovery purposes
   is a policy choice to be included in the TCP Connection
   Establishment "shared" database described in section 9.1.1.

   When FSF-based configuration discovery is enabled, the normal TCP
   Connection setup rules outlined above are modified as follows.

   Normally, the algorithm executed by an FCIP Entity receiving an FSF
   includes verifying that its own identification information in the
   arriving FSF is correct and closing the TCP Connection if it is not.
   This can be viewed as requiring the initiator of a TCP connect
   request to know in advance the identity of the FCIP Entity that is
   the target of that request (using SLP, for example), and through the
   FSF effectively saying, "I think I'm talking to X." If the party at
   the other end of the TCP connect request is really Y, then it simply
   hangs up.

   FSF-based discovery allows the "I think I'm talking to X" to be
   replaced with "Please tell me who I am talking to?", which is
   accomplished by replacing an explicit value in the Destination FC
   Fabric Entity World Wide Name field with zero.

   If the policy at the receiving FCIP Entity allows FSF-based
   discovery, the zero is replaced with the correct Destination FC
   Fabric Entity World Wide Name value in the echoed FSF. This is still
   subject to the rules of sending with unchanged echo, and so closure
   of TCP Connection occurs after the echoed FSF is received by the TCP
   connect initiator.

   Despite the TCP Connection closure, however, the TCP connect
   initiator now knows the correct Destination FC Fabric Entity World
   Wide Name identity of the FCIP Entity at a given IP Address and a
   subsequent TCP Connection setup sequence probably will be successful.

   The Ch bit in the pFlags field (see section 6.6.1) allows for
   differentiation between changes in the FSF resulting from
   transmission errors and changes resulting from intentional acts by
   the FSF recipient.


Ralph Weber                                                    [Page 25]


Internet-Draft              FCIP 1st WG Last Call              May, 2002



Comment 45

   -- Section 9.1.1 - Connection Establishment Model

      What is important is the fact that the FCIP Entity MAY consult the
      database at anytime to determine its actions relative to TCP
      Connection establishment.

   [E] "anytime" --> "any time"

   Accepted

Comment 46 Technical

   -- Section 9.1.2.1 - Non-Dynamic Creation of New TCP Connections

      If the TCP connect request is rejected, the FCIP Entity SHALL act
      to limit unnecessary repetition of attempts to establish similar
      connections.

   [T] That's a little vague. How about specifying a minimum time
   period that MUST elapse before retry?

   Accepted with the following results

   Add new sentence following cited text: "For example, the FCIP
   Entity might wait 60 seconds before trying to re-establish the
   connection."





















Ralph Weber                                                    [Page 26]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 47

   -- Section 9.1.2.1 - Non-Dynamic Creation of New TCP Connections

      It is recommended that an FCIP Entity not initiate TCP connect
      requests to another FCIP Entity if incoming TCP connect requests
      from that FCIP Entity have already been accepted.

   [T] Needs an upper case "SHOULD" or "RECOMMENDED". This also needs
   a MUST or SHOULD on the configuration mechanism to indicate in which
   direction connections are to be established between a pair of FCIP
   Entities in order to deal with a problem that turns up near the end
   of Section 9.1.3. This is related to Mallikarjun's issue about
   handling of simultaneous opens.

   Accepted (Partially)

   Change "recommended" to "RECOMMENDED". See comment 124 for a
   discussion of the other issues cited here.

Comment 48

   -- Section 9.1.2.2 - Dynamic Creation of New TCP Connections

   [E] The information on connection establishment is basically common to
   this and Section 9.1.2.1. Consider reducing this section to focus on
   use of SLP, and referring to Section 9.1.2.1 for what to do after the
   configuration info is discovered via SLP. Also consider whether the
   SLP description should come before the connection establishment
   description.

   Rejected

   The information on connection establishment is indeed common to
   section 9.1.2.1, but its relationship to SLP is not. Section 9.1.2.2
   already is less than one page long, that and a desire to have some
   amount of readable flow (as opposed to "do this, then do what it
   says to do over there, then do that, then do this other thing that
   is talked about in another section") seems like ample motivation
   for the current organization.










Ralph Weber                                                    [Page 27]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 49

   -- Section 9.1.2.3 - Connection Setup After a Successful TCP Connect
   Request

   [T] This dives into the details of FCIP Special Frame handling without
   explaining the overall structure and goals of the use, and is unclear
   as a result. For example, For example, on p. 29, after constructing
   the FCIP Special Frame, the text says:

      After the FCIP Special Frame bytes are sent on the newly formed
      connection, the FCIP Entity SHALL wait for the FCIP Special Frame
      to be echoed as the first bytes received on the newly formed
      connection.

   But one has to wade all the way down to p.33 towards the end of
   Section 9.1.3 to discover that the other FCIP Entity is expected to
   perform validation actions before echoing the frame. The structural
   outline of the usage of the FCIP Special Frame (without the blow by
   blow details) needs to be described in Section 8.

   Duplicate comment, see response to comment 44.

Comment 50

   -- Section 9.1.2.3 - Connection Setup After a Successful TCP Connect
    Request

      The remaining steps in this section SHALL be performed only if the
      echoed FCIP Special Frame bytes exactly match the FCIP Special
      Frame bytes sent (words 7 through 17 inclusive).

   [E] There is a great deal of common text in the two descriptions that
   follow the above text. They should be combined into a single
   description, with the creation of the FCIP_LEP at step 2 being done
   only if necessary.

   Accepted (Conditionally)

   An attempt will be made to do this. If the cure is worse than the
   disease, the original text will be used.









Ralph Weber                                                    [Page 28]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 51

   -- Section 9.1.3 - Processing Incoming TCP Connect Requests

      If the requested connection is allowed, the FC Entity SHALL ensure
      that required IP security features are enabled and accept the TCP
      connect request.

   [T] As written, this appears to require a dynamic interrogation of
   the IPsec Security Association Database, and possibly the IPsec
   Security Policy Database. I suspect that this is in excess of what
   was intended, and suspect a longer description is needed.

   Accepted with the following result

   Change "If the connection is allowed,..." to "If the connection is
   allowed by the "shared" database (see 9.1.1),..."

Comment 52 Technical

   -- Section 9.1.3 - Processing Incoming TCP Connect Requests

      If the Destination FC Fabric Entity World Wide Name contains 0,
      the FCIP Entity SHALL take one of the following three actions:

      1)  Leave the Destination FC Fabric Entity World Wide Name field
          and Ch bit both 0;
      2)  Change the Destination FC Fabric Entity World Wide Name field
          to match FC Fabric Entity World Wide Name associated with the
          FCIP Entity that received the TCP connect request and change
          the Ch bit to 1; or
      3)  Close the TCP Connection without sending any response.

      The choice between the above actions depends on the anticipated
      usage of the FCIP Entity and is outside the scope of this
      specification. The FCIP Entity may consult the "shared" database
      when choosing between the above actions.

   [T] I'm not buying the "outside the scope" disclaimer. Some more
   description of why the three choices are available is in order even
   if the normative criteria for choosing among them are specified in
   FC-BB-2. If my assumption about FC-BB-2 is correct, the last
   sentence is almost certainly too weak - it needs to refer to
   consulting the FC Entity to determine what to do.

   Accepted but not as the comment intended

   Delete "... and is outside the scope of this specification"


Ralph Weber                                                    [Page 29]


Internet-Draft              FCIP 1st WG Last Call              May, 2002



   Other actions to be taken

   Note: Some non SLP implementations wish to use the SF as a
   configuration determination mechanism. The choice exists to allow
   that option.

   Describe this in the new section added in response to comment 44.

Comment 53 Technical

   -- Section 9.1.3 - Processing Incoming TCP Connect Requests

      If:
      a)  The Destination FC Fabric Entity World Wide Name contains a
          non-zero value that does not match the FC Fabric Entity World
          Wide Name associated with the FCIP Entity that received the TCP
          connect request, or
      b)  The contents of the Connection Usage Flags, and Connection
          Usage Code fields is not acceptable to the FCIP Entity that
          received the TCP connect request,
      then the FCIP Entity SHALL take one of the following two actions:
      1)  Change the contents of the unacceptable fields to correct/
          acceptable values and set the Ch bit to 1; or
      2)  Close the TCP Connection without sending any response.

   [T] 1) looks like a security hole that discloses information an
   attacker may find useful in establishing an undesired connection to
   FCIP.
   What's the motivation/purpose for this?

   No changes made

   The motivation is to allow the SF to be used as a poor-man's SLP.

   Option 1) is a security policy that is not a security hole because
   either IPsec or option 2) or both are available as security policy
   choices.












Ralph Weber                                                    [Page 30]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 54 Technical

   -- Section 9.1.3 - Processing Incoming TCP Connect Requests

      If the Source FC Fabric Entity World Wide Name and Source FC/FCIP
      Entity Identifier field values in the FCIP Special Frame match the
      Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity
      Identifier associated with an existing FCIP_LEP, the FCIP Entity
      SHALL:

      1)  Request that the FC Entity authenticate the source of TCP
          connect request, providing the following information to the FC
          Entity for authentication purposes:

   [T] Need to say more about what the FC Entity MUST do to
   "authenticate the source". I realize that the details are specified
   in FC-BB-2, but the functional requirements on the FC Entity can be
   specified here.

   Accept but only to a limited degree

   Requiring the FC Entity to do a specific thing in response to
   the request to authenticate goes substantially beyond the security
   policies that the IETF applies to itself (i.e., this would be
   MANDATORY to implement and MANDATORY to use).

   Action to be taken

   Replace the "warning" paragraph cited in comment 56 with: "The
   definition of the FC Entity SHALL include a mechanism for use in
   response to a TCP connect request source that communicates with the
   partner FC Entity on the FCIP Link using a previously authenticated
   TCP Connection to verify that the Connection Nonce has been sent in
   a yet to be completed TCP Connection setup. Failure of the partner
   FC Entity to verify the Connection Nonce SHALL be treated as an
   authentication failure."














Ralph Weber                                                    [Page 31]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 55 Technical

   -- Section 9.1.3 - Processing Incoming TCP Connect Requests

          The FCIP Entity SHALL wait indefinitely for the FC Entity to
          authenticate source of the TCP connect request and SHALL not
          use the new TCP Connection for any purpose until the FC Entity
          completes the authentication.

   [T] "wait indefinitely" creates an obvious denial of service attack
   vulnerability. Try again.

   Accepted with the following results

   Change the cited text to: "The FCIP Entity SHALL not use the new TCP
   Connection for any purpose until the FC Entity authenticates the
   source of the TCP connect request."

Comment 56

   -- Section 9.1.3 - Processing Incoming TCP Connect Requests

          Warning: The authentication mechanism described here and in
          FC-BB-2 [4] is not designed to thwart sophisticated security
          threats. The IP security mechanisms described in section 10
          should be enabled in environments where security threats are
          suspected.

   [E] Unfortunately, that's almost content-free. I suggest replacing
   this with a forward pointer to a more specific discussion of the
   threats involved in the Security Considerations section.

   Accepted with the following results

   1) Embed said pointer in the first paragraph of the step 1)
      text describing the process; and
   2) Remove this paragraph entirely.













Ralph Weber                                                    [Page 32]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 57 Technical

    -- Section 9.1.3 - Processing Incoming TCP Connect Requests

      Note that the originator of TCP connect requests uses IP Address
      and TCP Port to identify which TCP Connections belong to which
      FCIP_LEPs while the recipient of TCP connect requests uses the
      Source FC Fabric Entity World Wide Name, Source FC/FCIP Entity
      Identifier fields from the FCIP Special Frame to identify which TCP
      Connection belong to which FCIP_LEPs. For this reason, an FCIP
      Entity that both originates and receives TCP connect requests is
      unable to match the FCIP_LEPs associated with originated TCP
      connect requests to the FCIP_LEPs associated with received TCP
      connect requests.

   [T] That's a problem. See comment against Section 9.1.2.1 for
   one suggestion for how to fix this, but some sort of fix appears
   necessary to me.

   Accepted with the following results

   Add a new section 9.1.4 titled "Simultaneous Connection
   Establishment" containing the following text.

   "If two FCIP Entities perform simultaneous open operations, then
   two TCP Connections are formed and the SF originates at one end
   on one connection and at the other end on the other. Connection
   setup proceeds as described above on both connections, and the
   steps described above properly result in the formation of two
   FCIP Links between the same FCIP Entities.

   "This is not an error. Fibre Channel is perfectly capable of
   handling to approximately equal connections between FC Fabric
   elements.

   "The decision to setup pairs of FCIP Links in this manner is
   considered to be a site policy decision that can be covered in
   the "shared" database described in section 9.1.1."












Ralph Weber                                                    [Page 33]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 58

   -- Section 9.3 - TCP Connection Parameters

      In order to provide efficient management of FCIP_LEP resources as
      well as FCIP Link resources, consideration of certain TCP
      Connection parameters is RECOMMENDED.

   [E] As written, "RECOMMENDED" should be lower case, as it does not
   convey a requirement related to interoperability or good use of the
   network.

   Accepted

Comment 59

   -- Sections 9.3.2, 9.3.3, and 9.3.4

   [E] Sections 9.3.2, 9.3.3, and 9.3.4 need references to the
   specifications of the TCP options being discussed.

   Accepted

   Good! We are being asked later to prune the normative references.
   This will allow them to be bulked up again.

Comment 60 Technical

   -- Section 9.3.4 TCP_NODELAY Option

      FCIP Entities SHALL set the TCP_NODELAY option to one. This will
      disable the Nagle Algorithm that is designed for usage in a telnet
      environment.

   [T] I believe that "SHALL" should be a lower case "should". This is
   a local performance optimization that has no other effects.

   Accepted












Ralph Weber                                                    [Page 34]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 61 Technical

   -- Section 9.5 - Flow Control Mapping between TCP and FC

      Coordination of these flow control mechanisms one of which is
      credit based and the other of which is window based depends on
      painstaking design that is outside the scope of this
      specification.

   [T] This is content-free. At least warn about some of the things
   that can go wrong, in particular BB-credit starvation and the
   potential to really screw up a Fibre Channel fabric if this is
   long-lived.

   Rejected

   This text was written in specific response to the decision of Orange
   County interim meeting that "The only statement that should appear
   in FCIP on the subject is, 'There be dragons here.'"

Comment 62 Technical

   -- Section 10 Security

   [T] Need to get this whole section aligned with the latest (currently
   -11) version of the IPS Security draft.

   Accepted with the following results

   Section 10 will be aligned with IPS Security Draft version 12.
   This will require a substantial number of changes, as detailed
   below. It would be desirable to avoid a "hairball" between FCIP
   and the IPS Security Draft. With this in mind, it is believed that
   changes in the IPS Security Draft will concern areas that do not
   directly impact FCIP. Of course, there are no guarantees.

   In Section 10.1, add the following to the Threat Models: "8) An
   adversary may launch a variety of attacks against the discovery
   process [SLPv2, RFC2608]."

   Note: This addition is placed in the list in such a way as to keep
   the FCIP-specific attack (the attack related to the Special Frame)
   last in the list.

   Section 10.3.1, add the following to the end of the first paragraph:
   "When ESP is utilized, per-packet data origin authentication,
   integrity and replay protection must be used."



Ralph Weber                                                    [Page 35]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


   In addition to the changes in Section 10.3.2 (Key Management)
   described in comment 69, comment 70, comment 71, comment 72, and
   comment 73, make the following changes:

   1) Add the following to the end of Paragraph 1:

      "Conformant FCIP implementations MUST support peer authentication
      using pre-shared key and MAY support peer authentication using
      digital certificates. Peer authentication using public key
      encryption methods outlined in IKE [2409] Section 5.2 and 5.3
      SHOULD NOT be used."

   2) Change the last sentence of Paragraph 2 from:

      "FCIP Entities MUST support "Main Mode" operation in Phase 1 and
      MAY support "Aggressive Mode" if identity protection is not
      required."

      to:

      "FCIP implementations MUST support IKE Main Mode and SHOULD
      support Aggressive Mode."

   3) Add the following at the end of paragraph 3: "The Phase 2 Quick
      Mode exchanges MUST explicitly carry the Identity Payload fields
      (IDci and IDcr). Each Phase 2 payload SHOULD carry a single IP
      Address and a single non-zero port number and SHOULD NOT use the
      IP Subnet or IP Address Range formats. Other ID payload formats
      MUST NOT be used."

   4) Add the following new paragraph after paragraph 3: "Since the
      number of Phase 2 SAs may be limited, Phase 2 delete messages may
      be sent for idle SAs. The receipt of a Phase 2 delete message
      SHOULD NOT be interpreted as a reason for tearing down an FCIP
      Link or any of its TCP connections. When there is new activity on
      that idle link, a new Phase 2 SA MUST be re-established."

   5) In the paragraph that starts with "For the purposes of...",
      change the last sentence from:

      "For the purposes of establishing IKE Phase 1 SA, static IP
      Addresses are typically used for identification."

      to:

      "Within IKE Phase 1, FCIP implementations must support the
      ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6)
      and ID_FQDN Identity Payloads. If FCIP Endpoint addresses are


Ralph Weber                                                    [Page 36]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


      dynamically assigned, it may be beneficial to use ID_FQDN, and
      for this reason, IP_FQDN Identity Payload MUST be supported.
      Other identity payloads (ID_USER_FQDN, ID_DER_ASN1_GN, ID_KEY_ID)
      SHOULD NOT be used.

Comment 63

   -- Section 10.1 Threat Models

      Using a general purpose, wide-area network such as an IP Network as
      a substitute for physical cabling introduces some security problems
      not normally encountered in Fibre Channel Fabrics. FC interconnect
      cabling typically is protected physically from outside access.
      Public IP Networks allow hostile parties to impact the security of
      the transport infrastructure.

   [E] The intent is fine, but the "substitute" word has the same
   problems as the use of "replace" in Section 6.3. This is about
   "implementation of functionality that was originally specified only
   to use dedicated physical cabling" or something like that, as
   indicated in the latter two sentences.

   Accepted with the following result

   Replace "substitute" with "functional replacement".

Comment 64

   -- Section 10.1 Threat Models

      The general effect is that the security of the entire FC Fabric
      is only as good as the security of the entire IP Network through
      which it tunnels.

   [E] "the entire" --> "any". This may be the first occurrence of
   "tunnel" in the document - that might be better rephrased to talk
   about "any IP Network" carrying FCIP links that are part of the
   fabric".

   Accepted with the following result

   Replace the cited text with: "The general effect is that the
   security of an FC Fabric is only as good as the security of the
   entire IP Network that carries the FCIP Links used by that FC Fabric.






Ralph Weber                                                    [Page 37]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 65

   -- Section 10.1 Threat Models

      2)  Unauthorized agents can monitor and manipulate Fibre Channel
          traffic flowing over physical media used by the IP Network and
          under control of the agent.

   [E] "under control of" is too strong. "accessible to" would be
   better, especially for monitoring.

   Accepted

Comment 66

   -- Section 10.1 Threat Models

      5)  The payload of an FCIP Encapsulated frame may be altered or
          transformed in such a way that it preserves the TCP Checksum
          transform while altering content.

   [E] Put a period after "transformed" and rephrase the rest to say
   that the TCP checksum, FCIP ones complement checks and FC frame CRC
   do not protect against this, as all of them can be modified or
   regenerated by a malicious and determined adversary.

   Accepted

Comment 67

   -- Section 10.3 - FCIP Security Components

      FCIP Security compliant implementations MUST implement IPSec
      Protocol Suite based cryptographic authentication and data
      integrity [14], as well as confidentiality using algorithms and
      transforms as described in this section.

   [E] Please insert the ESP acronym into this sentence.
   [E] The official capitalization is "IPsec", not "IPSec".

   Accepted with the following results

   1) Replace "IPSec" with "ESP and IPsec"; and
   2) Verify correct IPsec usage throughout.






Ralph Weber                                                    [Page 38]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 68 Technical

   -- Section 10.3.1 - IPSec ESP Authentication and Confidentiality

      FCIP Entities MUST implement IPSec ESP [16] in Tunnel Mode for
      providing Data Integrity and Confidentiality. FCIP Entities MAY
      implement IPSec ESP in Transport Mode, if deployment considerations
      require use of Transport Mode.

   [T] Those deployment considerations include RFC 2401 requirement for
   Transport mode because the IPsec implementation is a host
   implementation rather than a security gateway. I thought this was
   understood by the FCIP authors, and it needs to be explicit here
   including an appropriate reference to RFC 2401. I expect to be able
   to double-check this requirement with the IETF Security Area in the
   next few days.

   Rejected

   As per the consensus taken at the March 2002 IETF meeting, Transport
   Mode implementation is a MAY.

Comment 69

   -- Section 10.3.2 - Key Management

      FCIP Entities MUST support IKE [18] for peer authentication,
      negotiation of Security Associations (SA) and Key Management using
      the IPSec DOI [17]. Manual keying for establishing SA is not
      permitted since it does not provide the necessary elements for
      rekeying (see section 10.3.3).

   [E] Reword last sentence to include "MUST NOT use", "SHALL NOT use"
   or equivalent.

   Accepted














Ralph Weber                                                    [Page 39]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 70

   -- Section 10.3.2 - Key Management

      Repeated rekeying using "Quick Mode" on the same shared secret will
      over time, reduce the cryptographic properties of that secret. To
      overcome this, Phase 1 MAY be invoked periodically to create a new
      set of IKE shared secrets and related security parameters.

   [E] "MAY" --> "SHOULD" (I believe this captures the intention).

   Accepted

Comment 71 Technical

   -- Section 10.3.2 - Key Management

      When pre-shared keys are used, IKE Aggressive Mode SHOULD be used
      and Main Mode SHOULD NOT be used.

   [T] I think this is too strong and will cause problems. Pre-Shared
   keys are a "MUST", Aggressive Mode is a "MAY", so this "SHOULD" is
   inconsistent. The issue with Main Mode arises when dynamically
   assigned IP addresses are used (and hence Main Mode can't figure out
   which pre-shared key to use). The escape from this box appears to be
   that Aggressive Mode is a MUST (SHOULD?) when dynamic assignment of
   IP addresses to FCIP implementations is used, but support for dynamic
   assignment of IP addresses is NOT REQUIRED.

   The problem with this approach is that one gets into trouble on one
   end of an FCIP Link when the *other* end has its IP address
   dynamically assigned. The obvious solutions to this issue are to
   forbid (MUST NOT) dynamic IP address assignment (which has no chance
   of making it through the IESG) or to REQUIRE Aggressive Mode (as iFCP
   does). In addition, the IPS Security draft appears to need some
   editing to allow Aggressive Mode to be a "MAY" for FCIP (and iFCP).
   Darn - I thought we had this issue closed in Huntington Beach - did I
   miss something?

   Accepted with the following results

   Replace the cited text with:

   "When pre-shared keys are used, IKE Main Mode is usable only when
   both peers of an FCIP Link use statically assigned IP addresses.
   When support for dynamically assigned IP Addresses is attempted in
   conjunction with Main Mode, use of group pre-shared keys would be
   forced, and the use of group pre-shared keys in combination with


Ralph Weber                                                    [Page 40]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


   Main Mode is not recommended as it exposes the deployed environment
   for man-in-the-middle attacks. Therefore, if either peer of an FCIP
   Link uses dynamically assigned address, Aggressive Mode SHOULD be
   used and Main Mode SHOULD NOT be used."

Comment 72

   -- Section 10.3.2 - Key Management

           Support for IKE Oakley Groups is not required.

   [T] What does this refer to? At a minimum, it needs a reference.

   Accepted

   The reference for IKE Oakley Groups is RFC 2412. A suitable
   informational reference will be added.

Comment 73

   -- Section 10.3.2 - Key Management

      For the purposes of establishing a secure FCIP Link, the two
      participating FCIP Entities consult a Security Policy Database
      (SPD).

   [E] For this and the SAD, please add RFC 2401 references.

   Accepted with the following results

   1) Add a new normative reference for SPD to section 4.4.1 of
      RFC 2401; and
   2) Add a new normative reference for SAD to section 4.4.3 of
      RFC 2401.
















Ralph Weber                                                    [Page 41]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 74 Technical

   -- Section 10.4.2 - TCP Connection Security Associations (SAs)

      For a TCP Connection establishment, IKE Phase 2 is employed,
      resulting in an SA, identified by an SPI. All IP datagrams of the
      TCP Connection MUST carry an ESP header with a valid SPI and
      Sequence Number to be accepted as valid by the receiving peer.

   [T] The requirement for a phase 2 SA per TCP connection has been
   removed. This text (and possibly the rest of this section) need some
   editing to reflect that.

   Accepted with the following results

   1) Replace the cited text with: "Each TCP connection MUST be
      protected by an IKE Phase 2 SA. Traffic from one or more than
      one TCP connection may flow within each IPsec Phase 2 SA. While
      it is possible for a IKE Phase 2 SA to protect multiple TCP
      connections, all packets of a TCP connection is protected using
      only one IKE Phase 2 SA. FCIP implementations need not verify
      that the IP addresses and port numbers in the packet match any
      locally stored per-connection values, leaving this check to be
      performed by the IPsec layer."

   2) Delete the last paragraph of the section, which currently reads:
      "When a TCP Connection is terminated or closed, all SAs
      associated with it MUST be removed from the local SAD."

Comment 75

   -- Section 10.4.3 - Handling data integrity and confidentiality
    violations

      An implementation MAY audit such events as a diagnostic aid.

   [E] Almost but not quite. Auditing is about a lot more than
   "diagnostic aid". See Section 7 of RFC 2401, make sure the text is
   consistent with it, and refer to it.

   Accepted with the following results

   Replace the cited text with: "An implementation SHOULD follow
   guidelines for auditing all auditable ESP events per Section 7
   of RFC2401."





Ralph Weber                                                    [Page 42]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 76 Technical

   -- Section 10.4.3 - Handling data integrity and confidentiality
    violations

      Confidentiality checks MUST be performed if Confidentiality is
      enabled.

   [T] And what would those be, please? Replace this with a prohibition
   on use of Confidentiality without Integrity.

   Accepted with the following results

   Replace the first "Confidentiality" with "Integrity".

Comment 77 Technical

   -- Section 10.4.4 - Handling SA parameter mismatches

      When SA parameters do not match, the TCP Connection may reach a
      point where no traffic moves, or there are excessive TCP
      retransmissions. In such a case, either side MAY take one of the
      following actions:
      a)  Reestablish another set of SA parameters; or
      b)  Close the TCP Connection and notify the FC Entity with the
          reason for the closure.

   [T/E] Needs some more explanation, including an example of the
   sort of mismatch that could cause this problem. Recall that IKE
   negotiates SA parameters, and this fact needs to be included in the
   explanation and example.

   Accepted but perhaps not as intended

   The handling of SA parameter mismatches belongs in a security draft,
   not in FCIP. Therefore, section 10.4.4 will be removed.














Ralph Weber                                                    [Page 43]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 78

   -- Section 11.1 - Performance Considerations

      Traditionally, the links between FC Fabric components have been
      characterized by low latency and high throughput. The purpose of
      FCIP is to replace some of these links with an IP Network,

   [E] There's the "replace" work again. See comment against Section
   6.3.

   Accepted with the following result

   Replace "...to replace some of these links with..." with "...to
   provide functionality equivalent to these links using..."

Comment 79

   -- Section 11.2 - IP Quality of Service (QoS) Support

      It is RECOMMENDED that some form of preferential QoS be used
      for FCIP traffic to minimize latency and drop precedence. No
      particular form of QoS is recommended.

   [E] "drop precedence" --> "packet drops"

   Accepted

Comment 80

   -- Section 11.2 - IP Quality of Service (QoS) Support

      If diffserv/PHB QoS is NOT implemented, the DSCP field for all IP
      packets SHALL be set to '000000'.

   [T] Sorry, wrong answer. That's not consistent with RFC 2474.
   Best bet is to drop this sentence, but if the authors want to say
   something here, they should contact me directly to discuss/vet
   appropriate text.

   Accepted with the following results

   Replace the cited text with: "If no form of preferential QoS is
   implemented, the DSCP field SHOULD be set to '000000' to avoid
   negative impacts on other network components and services that
   may be caused by uncontrolled usage of non-zero values of the
   DSCP field."



Ralph Weber                                                    [Page 44]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 81

   -- Section 12 - Normative References

   [E] This needs to be carefully checked to minimize normative
   references. [7] is definitely non-normative. Most of the QoS
   references are or can be non-normative, specifically [11], [22],
   [23], [24]). [22] is an Informational RFC and hence has to be
   referenced in a non-normative fashion, and I really want to see [23]
   and [24] be non-normative (else any FCIP implementation will have to
   implement both EF and AF, which is surely not what was intended).
   Need to add a non-normative MPLS reference.

   Accepted with the following results

   1) Remove reference 7 entirely;
   2) Make the SNTP reference [13] informative;
   3) Make all references from section 11 (Performance/QoS)
      informative (note: this covers all the other cited
      references); and
   4) Add an informative reference to RFC 3031 for MPLS.

   All other references appear to be necessary.

Comment 82

   -- Section 14 - Acknowledgments

   [E] This is a good place to thank everyone who's reviewed the
   document, commented on ideas in it, or helped in other ways.

   Accepted

   Acknowledge Mallikarjun Chadalapaka and David Black.

Comment 83

   -- Section 15 - Contributors' Addresses

   We'll try this structure of not separating the folks listed on p.1
   from the other contributors and see if there are any procedural
   objections. It's unusual to say the least.

   Unusual demands beget unusual responses.






Ralph Weber                                                    [Page 45]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 84 Technical

   -- Annex A - IANA Considerations

   [T] Instruct IANA to change the authority for those port allocations
   to reference this RFC when it is approved. Add a sentence forbidding
   the use of UDP with FCIP even though IANA has allocated a port.

   Accepted

Comment 85

   -- Annex A - IANA Considerations

   [T] Will need to reference the SOF/EOF registry that the FC Frame
   Encapsulation Draft will need to set up. Point to the Protocol#
   allocation done by that draft also. If a connection usage registry
   is needed (see comment against Section 8, details of that will have
   to go here).

   Accepted (Partially)

   Add discussion of Protocol# allocation.

   The SOF/EOF registry will not happen.

Comment 86

   -- Annex A - IANA Considerations

   [E] Should the ANNEXes be APPENDIXes instead?

   Accepted, make exactly the proposed change

Comment 87

   -- Annex C - Example of synchronization recovery algorithm

   [T] See comment on this Annex under Section 6.6.2.3 above.

   See response to comment 37.









Ralph Weber                                                    [Page 46]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


2. Comments from Mallikarjun Chadalapaka
   =====================================

Comment 88

   > 2. Purpose, Motivation and Objectives
   ......
   >    Network. Since Fibre Channel and IP Networking technologies are
   >    compatible,

   I am not sure what's implied by this sentence....

   Generally, I would think that the motivation to extend an FC SAN
   using IP networks is based on the ubiquity of the IP networks.

   No changes made

   The cited phrase says that it is technologically possible to use
   IP Networks to extend FC SANs. That is, IP Networks are NOT tin
   cans and strings, but are in fact electromechanical signaling
   systems that are similar enough to FC to be useful in FC SANs.

Comment 89

   > 2. Purpose, Motivation and Objectives
   ......
   >    The fundamental assumption made in this specification is that the
   >    Fibre Channel traffic is carried over the IP Network in such a
   >    manner that the Fibre Channel Fabric and all Fibre Channel
   >    devices on the Fabric are unaware of the presence of the IP
   >    Network.

   Can someone please comment on the protocol interactions that result
   in the failure to set up an FCIP Link if this latency expectation is
   not met?

   Inquiry

   All data frames will fail their transit time test and will be
   discarded. No data will move from application to application and
   the end users will riot.









Ralph Weber                                                    [Page 47]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 90

   > 2. Purpose, Motivation and Objectives
   ......
   >    2)  apply the mechanism described in 1) to an FC Fabric using an
   >        IP network as an interconnect for two or more islands in an
   >        FC Fabric.

   S/b "an" w/ "the"; S/b "for" w/ "between"

   Accepted (Partially)

   Change "for ... islands" to "between ... islands".
   Do not change "an IP Network" to "the IP Network" because
   this specification assumes that there can be more than one
   IP Network.

Comment 91

   > 3. Relationship to Fibre Channel Standards
   ......
   >    FC is standardized under American National Standard for
   >    Information Systems of the National Committee for Information
   >    Technology Standards (ANSI-NCITS) in its T11 technical committee.

   I believe ANSI stands for American National Standards Institute.
   Also, NCITS had been changed to INCITS last year.

   Accepted with the following result

   Replace the cited text with: "FC is standardized as a family of
   American National Standards developed by the T11 technical committee
   of INCITS (InterNational Committee for Information Technology
   Standards).
















Ralph Weber                                                    [Page 48]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 92

   > 3. Relationship to Fibre Channel Standards
   ......
   >   FC-BB and FC-BB-2 describe the relationship between an FC Fabrics
   >   and interconnect technologies not defined in by Fibre Channel
   >   standards (e.g., ATM and SONET). FC-BB-2 is the natural Fibre
   >   Channel home for describing relationships to TCP/IP and FCIP.

   This is the first instance of FCIP's usage as a *protocol*. It would
   be best preceded by a definition of what FCIP means as a protocol.
   The previous text only describes the objectives of the document, but
   not the protocol.

   Accepted but not as intended

   The section in which the cited text appears is attempting to
   describe the relationship between standards documents. The second
   sentence in the cited text fails to maintain the purpose of the
   section.

    Actions to be taken

   Replace the second cited sentence with: "FC-BB-2 is the Fibre
   Channel document describing the relationships between FC and
   TCP/IP, including the FC use of FCIP.

Comment 93

   > 3.2 This Specification and Fibre Channel Standards
   ......
   >    No attempt is being made to define a specific API between an FCIP
   >    Entity and an FC Entity at this time because doing so risks
   >    compromising the performance and efficacy of the resulting
   >    products.

   I am somewhat concerned that the names are implying an incorrect
   distribution of functionality between "FC Entity" and "FCIP
   Entity"....

   From the name, I had assumed that FC Entity is simply a standard FC
   fabric element with no FCIP-isms. But further reading of the document
   made me realize that it in fact knows about the TCP connections and
   even actively participates in QoS and authentication decisions.

   As a first time reader, it appears to me that retaining only the FC
   E_Port functionality perhaps additionally providing timestamp and flow
   control services to the FCIP Entity (and dropping everything else into


Ralph Weber                                                    [Page 49]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


   the FCIP Entity) may be a lot cleaner distribution of functionality.
   At any rate, I would like to understand the current distribution
   rationale.

   BTW, can someone please clarify if the expected "role" of the FC
   Entity on the FC side is indeed an E_Port? It appears so from the
   requirement that FCIP be totally transparent to the FC fabric, but I
   don't see it called out in Annex G.

   Inquiry

   The process of developing FCIP has shown repeatedly that FCIP
   should contain only the Fibre Channel knowledge required to
   interact with TCP/IP. Attempting to include FC concepts such
   as R_A_TOV only leads to confusion in the IP Network community
   that in turn leads to proposals for changes in FCIP that are,
   in fact, proposals to change the definition of R_A_TOV in ways
   that are unacceptable to T11.

   The dividing line between an FC Entity and an FCIP Entity
   is drawn along political not technological lines.

   To understand the function of an FC Entity, you must read
   FC-BB-2, http://www.t11.org/t11/docreg.nsf/ldl/fc-bb-2.

Comment 94

   > 3.2 This Specification and Fibre Channel Standards
   ......
   >....fully functional and compliant
   >    products can be built provided they contain both an FCIP Entity
   >    and an FC Entity. The only products that cannot be built are
   >    those that contain only one or the other.

   The last sentence seems to stress the obvious at first glance, but I
   would think that products with just the FC Entity should be able to be
   built (not that one would...) to act as regular fabric elements with
   no FCIP features?

   Also, I take it that products with two FC Entities and one FCIP Entity
   for ex. are disallowed - but the last sentence seems to imply
   otherwise.

   No changes made

   This section and the cited paragraph are about the compliance
   relationship between FCIP and FC-BB-2. The Model section is
   where the numbers of FC Entities and FCIP Entities are discussed.


Ralph Weber                                                    [Page 50]


Internet-Draft              FCIP 1st WG Last Call              May, 2002



Comment 95

   > 4. Terminology
   ....
   >    FCIP Entity - The principal FCIP interface point to the IP
   >    Network (see section 6.4).

   This doesn't sound right to me....this definition is more appropriate
   for FCIP_LEP. This can perhaps be described as "the entity responsible
   for the FCIP protocol exchanges on the IP Network and which
   encompasses FCIP_LEP(s) and FCIP Control & Services module".

   Accepted

Comment 96

   > 5. Protocol Summary
   ...
   >    2)  Viewed from the IP Network perspective, FCIP Entities are
   >        peers and communicate using TCP/IP. Each FCIP Entity is a TCP
   >        endpoint in the IP-based network.

   The second sentence seems a little context-sensitive, since each FCIP
   Entity can be the TCP endpoint for several TCP connections.

   Changed as described in the response to comment 14.

Comment 97

   > 5. Protocol Summary
   ...
   >    3)  Viewed from the FC Fabric perspective, pairs of FCIP
   >        Entities, in combination with their associated FC Entities,
   >        serve as an FC Frame transmission component of the FC Fabric.
   >        The FC End Nodes are unaware of the existence of the FCIP
   >        Link.

   Can a "FC Frame transmission component" be something other than an
   E_Port?

   Inquiry

   An FC Frame transmission component can also be a B_Port.






Ralph Weber                                                    [Page 51]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 98

   > 5. Protocol Summary
   ...
   >    6)  An FCIP Entity MAY contain multiple FCIP Link Endpoints,
   >        but...

   I would add "each of which MAY service multiple TCP connections, "
   here...

   Rejected

   Such a change would detract from the focus on the point to be made.

Comment 99

   > 5. Protocol Summary
   ...
   >    7)  When multiple FCIP_LEPs with multiple FCIP_DEs are in use,
   >        selection of which FCIP_DE to use for encapsulating and
   >        transmitting a given FC Frame is outside the scope of this
   >        document. FCIP Entities do not actively participate in FC
   >        Frame routing.

   Couple of comments on this bullet (7) -

   Let's consider the case of multiple FCIP_DEs in one FCIP_LEP. This
   draft does not specify how each inbound FC frame from the FC fabric
   is distributed onto one of these FCIP_DEs (TCP connections). Where is
   it specified in wrt routing on TCP connections? I take it that the
   regular FC fabric routing rules aren't quite applicable in this case.

   To stress the obvious, I think we should have some standard covering
   this case - else we will end up with frames destined to the same D_ID
   being striped on multiple TCP connections, and thus ending up OOO.

   Accepted in principle

   The standard covering the questions raised by this comment is
   FC-BB-2.

   Action to be taken

   Replace "...is outside the scope of this document." with "...is
   covered in FC-BB-2 [4]."





Ralph Weber                                                    [Page 52]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 100

   > 5. Protocol Summary
   ...
   >    13) On a given TCP Connection, this specification relies on
   >        TCP/IP to deliver a byte stream in the same order that it was
   >        sent.

   Perhaps we should add - ", but allows confirmation of the same for
   each frame by checking the FCIP and FC CRCs."....

   Rejected

   1) FCIP has no CRC to check. 2) It is difficult to see how checking
   the FC CRC would confirm in order delivery.

Comment 101

   > 6.3 FC Entity
   ....
   >    the combination shown in figure 3. As another example, the
   >    combination cannot be used to replace cable connections in a
   >    Fibre Channel Arbitrated Loop because loop primitive signals
   >    cannot be encapsulated for transmission over TCP.

   I am not sure the last sentence is needed since figure 3 is explicit
   about the usage of fabrics.

   Changed as described in the response to comment 24.

Comment 102

   > 6.4 FCIP Entity
   ......
   >    The FCIP Entity is the connection interface point for the IP
   >    Network

   As commented earlier, the "connection interface point" doesn't sound
   totally correct - I would suggest "interfacing element" instead.

   Accepted









Ralph Weber                                                    [Page 53]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 103

   > 6.4 FCIP Entity
   ......
   >    and is the owner of the IP Address and Well Known Port used to
   >    form TCP Connections. An FC Fabric to IP Network interface
   >    product SHALL provide each FC Entity FCIP Entity pair contained
   >    in the product

   May I suggest a new term "FC-FCIP Pair" in place of "FC Entity FCIP
   Entity pair ".
   I think it improves the general readability.

   Accepted with the following results

   Change all occurrences of "FC Entity FCIP Entity pair" to
   "FC/FCIP Entity pair" to match the terminology used in FC-BB-2.

   Also add the following to section 4:

   FC/FCIP Entity pair - The combination of one FC Entity and one FCIP
   entity.

Comment 104

   > 6.4 FCIP Entity
   ......
   >    FC Entity with an interface to key IP Network features. The
   >    interfaces to the IP Network features is implementation specific,
   >    however, to maintain interoperability, the notable TCP/IP
   >    mechanisms used are specified in this document as follows:

   I think the last sentence is incorrectly implying interoperability
   issues around the (private) FC Entity-FCIP Entity interface.

   I would suggest a rewrite for the last sentence as something like -

   "The interfaces to the IP Network features are implementation-
   specific. To aid interoperability, this document specifies the
   notable TCP/IP Network features that are typically used."

   Changed as described in the response to comment 28.








Ralph Weber                                                    [Page 54]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 105

   > 6.5 FCIP Link Endpoint (FCIP_LEP)
   ....
   >    An FCIP_LEP
   >    MAY communicate with its FC Entity counterpart to coordinate
   >    flow control.

   Suggest adding the phrase "across the domains".

   Rejected

   Without a definition of "domains" such a change adds confusion,
   not reduced it.

Comment 106

   > 6.6 FCIP Data Engine (FCIP_DE)
   ......
   >    7)  In the absence of errors, the de-encapsulated FC Frame and
   >        time stamp SHALL be passed to the FC Transmitter Portal for
   >        delivery to the FC Entity.

   It is nice to add a sentence about the handling in the presence of
   errors. At a minimum, this should provide a cross-reference to the
   error detection section.

   Accepted with the following results

   Add the following at the end of the paragraph: "Error handling is
   discussed in section 6.6.2.2."



















Ralph Weber                                                    [Page 55]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 107

   > 6.6.1 FCIP Encapsulation of FC Frames
   ....
   >    The FCIP Special Frame SHALL only be sent as the first bytes
   >    transmitted in each direction on a newly formed TCP Connection
   >    and only one FCIP Special Frame SHALL be transmitted in each
   >    direction at that time (see section 9.1). After that all FCIP
   >    Frames SHALL have the SF bit set to 0.

   This para seems slightly out of context here, and perhaps should be
   moved to section 9.1. This usage semantics should ideally be preceded
   by what *is* a Special Frame and its purpose - though I could gather
   that from the usage and format descriptions in the entire document, I
   don't really find a place where its purpose is defined...

   Accepted, see response to comment 44

Comment 108

   > 6.6.1 FCIP Encapsulation of FC Frames
   ....
   >    Table 1 summarizes the usage of the pFlags SF and Ch bits.

   - It may be useful to add a protocol-specific bit to distinguish
   originated vs echoed SF, so the parsing and validation can be self-
   contained.

   - Also, I think a sentence should be added which says that the -
   pFlags field SHALL contain the ones-complement of the pFlags field.

   Accepted


















Ralph Weber                                                    [Page 56]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 109 Technical

   > 6.6.1 FCIP Encapsulation of FC Frames
   ....
   >    The CRCV (CRC Valid) Flag SHALL be set to 0.
   >
   >    The CRC field SHALL be set to 0.

   I am surprised that the FCIP encapsulated header is never protected
   by a CRC. The error detection section clearly acknowledges the
   possibility that TCP checksum could be inadequate for certain
   deployments - and even suggests checking the FC frame CRC (sort
   of like a data digest) on reception at the Encapsulated Frame
   Receiver Portal.

   My recommendation is to require an FCIP Entity to employ the header
   CRC if the SF that it receives asks for CRC - IOW, similar to iSCSI's
   approach. So, I guess I am also advocating a new bit in the pFlags
   field to announce this. When this CRC expectation is announced, the
   FC CRC checking test in 6.6.2.2 should also be a mandatory test -
   from the "semi-optional" list it is currently in.

   Accepted with the following result

   Add the following to the new section created in response to comment
   44: "Note: Owing to the limited manner in which the FSF is used and
   the requirement that the FSF be echoed without changes before a TCP
   connection is allowed to carry user data, no error checking beyond
   that provided by TCP is deemed necessary."

Comment 110

   > 6.6.2 FCIP Data Engine Error Detection and Recover

   The last word in the above should be "Recovery".

   Accepted













Ralph Weber                                                    [Page 57]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 111

   > 6.6.2.1 TCP Assistance With Error Detection and Recovery
   ......
   >    Thus, the byte stream passed from TCP to
   >    the FCIP_LEP will be in order and free of errors detectable by
   >    the TCP checksum. If TCP did not perform these functions, the
   >    FCIP_LEP would have to.

   Suggest rewording the last sentence (TCP always performs these
   functions to *its* satisfaction, the question is if FCIP feels the
   same; secondly, FCIP_LEP's error mgmt behavior is not dynamically
   contingent upon TCP's behavior as this sentence implies) -

   "To address the possibility that TCP did not perform these functions
   adequately in a given FCIP deployment context, the FCIP_LEP verifies
   if these expectations are met."

   Changed as described in the response to comment 32.

Comment 112

   > 6.6.2.2 Errors in FCIP Headers and Discarding FCIP Frames
   ......
   >    Further, some errors in the encapsulation will result in the
   >   FCIP_DE losing synchronization with the FCIP frames in the byte
   >    stream

   I don't see "frames" here with the uppercase "F" used everywhere
   else.

   Also, one observation is that FCEncap document uses "frames"
   consistently throughout, whereas this document chooses to use
   uppercase "F" (mostly).

   Accepted with notes

   "FCIP frame" s/b "FCIP Frame". That is a specific named
   construct that is defined and used in FCIP.

   FC Frame Encapsulation uses "frame" (lowercase) when referring
   to a Fibre Channel frame because lowercase frame is the Fibre
   Channel term.







Ralph Weber                                                    [Page 58]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 113

   > 6.6.2.2 Errors in FCIP Headers and Discarding FCIP Frames
   ......
   >    1)  Length field validation -- 15 < Length < 545;

   I assume "Frame Length" is meant by "Length" above.

   Accepted with the following results

   Change "Length" to "Frame Length".

Comment 114

   > 6.6.2.3 Synchronization Failures
   ......
   >    If an FCIP_DE determines that it cannot find the next FCIP Frame
   >    header in the byte stream entering through the Encapsulated
   >    Frame Receiver Portal, the FCIP_DE SHALL either:

   S/b "either" w/ "do one of the following".

   Accepted

Comment 115

   > 6.6.2.3 Synchronization Failures
   ......
   >    b)  recover synchronization by searching the bytes delivered by
   >        the Encapsulated Frame Receiver Portal for a valid FCIP Frame
   >        header having the correct properties

   Useful to refer to 6.6.2.2 here for "correct properties".

   Accepted

Comment 116

   > 7. Checking FC Frame Transit Times in the IP Network
   ....
   >    requirement in the FC Entity is based on a desire to include
   >    the Frame.

   S/b "in" w/ "on"

   Accepted




Ralph Weber                                                    [Page 59]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 117 Technical

   > 7. Checking FC Frame Transit Times in the IP Network
   ....
   >    ... If no synchronized time stamp value is available to
   >    accompany the entering FC Frame a value of zero SHALL be
   >    supplied.

   From this, it isn't clear to me if FCIP *requires* only Synchronized
   operation. If so, the draft should also specify how implementations
   are expected to deal with "benign" transitions into and out of the
   Unsynchronized state (i.e. transitions happening when no Encapsulated
   Frames are being received).

   Rejected

   Class F frames can be transmitted and forwarded in the
   Unsynchronized state.

   The requirements for transit time determinations are in FC-BB-2
   for all the reasons described in the response to comment 40.

Comment 118

   > 7. Checking FC Frame Transit Times in the IP Network
   ....
   >    The FC Entity SHALL
   >    verify that the FC Entity it is communicating with on an FCIP
   >    Link is using the same synchronized time source as it is, either
   >    Fibre Channel services or SNTP server.

   I see a chicken-and-egg problem for some implementations: Since Fibre
   Channel time services are not available until the FCIP Link is
   successfully set up and since timestamp is to be carried on every FC
   Frame (including those Fibre Channel time service exchanges) once the
   Link is set up, the only decent option for an implementation (assuming
   it supports only Synchronized operation) is to rely on SNTP server.
   Is this correct?

   If Unsynchronized operation is intended to be disallowed (my earlier
   question), then it seems to me that SNTP is the only option.

   Inquiry

   Yes but Unsynchronized operation is allowed precisely so that
   Class F frames can be processed to setup the FC Time Services Time
   for use by the FC Entity in computing transit times.



Ralph Weber                                                    [Page 60]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 119

   > 8. The FCIP Special Frame
   ......
   >    The FCIP Special Frame SHALL only be sent as the first bytes
   >    transmitted in each direction on a newly formed TCP Connection
   >    and only one FCIP Special Frame SHALL be transmitted in each
   >    direction.

   A general comment on this wording (and others similar to this).   I
   would suggest rewording (to be much stronger) to:

   The FCIP Special Frame SHALL be the first application data exchanged
   on each newly formed TCP connection, and only one FCIP Special Frame
   SHALL be transmitted in each direction.

   Rejected

   The use of "application data" could cause confusion with
   application data generated by FC Endnodes.

   See also comment 44 for more information on the SF and how it will
   be described in the next FCIP revision.



























Ralph Weber                                                    [Page 61]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 120

   > 8. The FCIP Special Frame
   ......
   >    Note: The combination of the Source FC Entity World Wide Name and
   >    Source FCIP Entity Identifier fields uniquely identifies every FC
   >    Entity FCIP Entity pair in the IP Network.

   - S/b "Source FCIP Entity Identifier" w/ "Source FC/FCIP Entity
     Identifier"

   - Also I take it that the "FC/FCIP Entity Identifier" is unique only
     within the scope of the given FC Entity's WWN. So, does the model
     allow multiple FCIP Entities to be associated with the FC Fabric
     Entity WWN?

   - From this statement, it implies to me that the Destination FC/FCIP
     Entity Identifier must be present in the special frame to ensure
     that the TCP connection is indeed established to the right "FC/FCIP
     Entity" under the scope of the given Destination FC Fabric Entity
     WWN. What am I missing?

   Accepted (Partially) as follows

   Make the change described in the first bullet.

   Response to the second bullet: Yes, the "FC/FCIP Entity Identifier"
   is unique only within the scope of the given FC Entity's WWN. Yes,
   the model allows multiple FCIP Entities to be associated with the FC
   Fabric Entity WWN.

   The following changes will be made to clarify this and other issues
   raised during the discussion of this comment on the ips list.

   Add the following to section 4:

       FC Fabric Entity - A Fibre Channel specific element containing
       one or more Interconnect_Ports (see [FC-SW-2 ref 5]) and one or
       more FC/FCIP Entity pairs. See FC-BB-2 [4] for a details about
       FC Fabric Entities.

   Change the title of figure 3:

   from: FC Entity and FCIP Entity Model
     to: Model for Two Connected FC/FCIP Entity Pairs





Ralph Weber                                                    [Page 62]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


   Add the following sentence at the end of the paragraph preceding
   figure 3:

       An FC Fabric Entity may contain multiple instances of the FC/
       FCIP Entity pair shown on either the right-hand or left-hand
       side of figure 3.

   Change the first sentence following figure 4:

   from:

       The FCIP Entity is the connection interface point for the IP
       Network and is the owner of the IP Address and Well Known Port
       used to form TCP Connections.

   to:

       The FCIP Entity receives TCP connect requests on behalf of the
       FCIP_LEPs that it manages. In support of this, the FCIP Entity
       is the sole owner of at least one TCP port/IP Address
       combination used to form TCP Connections. The TCP port may be
       the FCIP well known port at a given IP Address.

   Response to the third bullet: The motivation for permitting the
   "Destination FC Fabric Entity WWN" to be zero is to allow the
   SF to be used as a poor-man's SLP (a configuration discovery
   mechanism). This usage is described in the new section added in
   response to comment 44.

Comment 121

   > 8. The FCIP Special Frame
   ......
   >    The Destination FC Fabric Entity World Wide Name field MAY
   >    contain

   Why isn't the above requirement a SHALL?

   Inquiry - see the response to comment 120.











Ralph Weber                                                    [Page 63]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 122

   > 9.1.2.2 Dynamic Creation of New TCP Connections
   ...

   >     - The expected Destination FC Fabric Entity World Wide Name of
   >       the FC Entity FCIP Entity pair to which the TCP Connection is
   >       being made
   >     - TCP Connection Parameters (see section 9.3)
   >     - Quality of Service Information (see section 11)
   >
   >    Based on this information, the FCIP Entity SHALL generate a TCP
   >    connect request [8] to the FCIP Well-Known Port of 3225 (or other
   >    configuration specific port number) at the IP Address specified
   >    by the service advertisement. If the TCP connect request is
   >    rejected, act to limit unnecessary repetition of attempts to
   >    establish similar connections. If the TCP connect request is
   >    accepted, the FCIP Entity SHALL follow the steps described in
   >    section 9.1.2.3 to complete the establishment of a new FCIP_DE.
   >
   >    It is recommended that an FCIP Entity not initiate TCP connect
   >    requests to another FCIP Entity if incoming TCP connect requests
   >    from that FCIP Entity have already been accepted.

   This entire text is duplicated from previous section 9.1.2.1. Seems
   like we could do with one instance (possibly in a new subsection).

   Rejected

   The information on connection establishment is indeed common to
   section 9.1.2.1, but its relationship to SLP is not. Section 9.1.2.2
   already is less than one page long, that and a desire to have some
   amount of readable flow (as opposed to "do this, then do what it
   says to do over there, then do that, then do this other thing that
   is talked about in another section") seems like ample motivation for
   the current organization.














Ralph Weber                                                    [Page 64]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 123

   > 9.1.2.3 Connection Setup After a Successful TCP Connect Request
   ......
   >    All fields in the FCIP Special
   >    Frame SHALL be filled in as described in section 8, particularly:

   While the sentence above is unequivocally clear, I don't understand
   the need for all the text that follows "particularly".... It is
   confusingly repetitive since as far as I can tell, all these are
   covered in more or less the same language in section 8.

   No changes made

   The draft is structured so that the Special Frame can be used
   for more features than just initial connection setup. As of yet,
   additional uses have not been defined, but it seems prudent to
   simplify such enhancements to ensure that future versions remain
   correct with minimal editorial effort.

   In keeping with this, section 8 describes the overall SF format
   and section 9.1... defines SF usage during connection setup.

Comment 124

   > 9.1.2.3 Connection Setup After a Successful TCP Connect Request
   ......
   >    After the FCIP Special Frame bytes are sent on the newly formed
   >    connection, the FCIP Entity SHALL wait for the FCIP Special Frame
   >    to be echoed as the first bytes received on the newly formed
   >    connection.

   - S/b "bytes are" w/ "is"
   - S/b "first bytes" w/ "first TCP segment data"
   - I take it that the onus is on the FCIP Entity that did the TCP
     active open to send the SF. That leads me to: What if there's a TCP
     simultaneous open?
     Would not each end up sending the SF and waiting for the echo?
     Also, would not the earlier rule on only one frame being transferred
     in each direction be violated then?

   Accepted (Partially) as follows

   Make the change described in the first bullet.

   Do not make the change described in the second bullet because it
   requires more knowledge of TCP than FCIP should have.



Ralph Weber                                                    [Page 65]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


   The last issue is resolved as per the response to comment 57.

Comment 125

   > 9.1.2.3 Connection Setup After a Successful TCP Connect Request
   ......
   >    If the echoed FCIP Special Frame bytes do not exactly match the
   >    FCIP Special Frame bytes sent (words 7 through 17 inclusive), the
   >    FCIP Entity SHALL close the TCP Connection and notify the FC
   >    Entity with the reason for the closure.

   Seems like all the 11 words are required to be compared. If so, what
   is the Ch bit being used for? IOW, why SHALL it be set by the
   responder?

   Inquiry

   The Ch bit serves to identify the difference between changes
   made intentionally by the echoing FCIP Entity and changes that
   result from transmission errors.

Comment 126

   > 9.1.2.3 Connection Setup After a Successful TCP Connect Request
   ......
   >    The FCIP Entity SHALL listen for new TCP Connection requests [8]
   >    on the FCIP Well-Known Port (3225). An FCIP Entity MAY also
   >    accept and establish TCP Connections to a TCP port number other
   >    than the FCIP Well-Known Port, as configured by the network
   >    administrator.

   It may be useful to add that this usage is outside the scope of this
   document.

   Accepted with the following results

   Add "... in a manner outside the scope of this specification." at
   the end of the last cited sentence.












Ralph Weber                                                    [Page 66]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 127

   > 9.1.2.3 Connection Setup After a Successful TCP Connect Request
   ......
   >    The FCIP Entity SHALL determine the following information about
   >    the requested connection:
   >
   >     - Whether the requested connection is allowed

   I take it that by means not specified in this spec? If so, it's
   useful to call it out.

   Accepted with the following results

   1) Change "Whether the requested connection is allowed" to "Whether
   the "shared" database (see section 9.1.1) allows the requested
   connection"; and
   2) Ensure that this change is applied wherever it is needed.

Comment 128 Technical

   > 9.1.3 Processing Incoming TCP Connect Requests......
   >    abort the TCP connect request [8]. If the requested connection is

   I was told that "abort" isn't available on all implementations -
   perhaps "abort/close" would be better....

   Accepted with the following results

   Change "abort the TCP connect request [8]" to "reject the connect
   request using appropriate TCP means"



















Ralph Weber                                                    [Page 67]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 129

   > 9.1.2.3 Connection Setup After a Successful TCP Connect Request
   ......
   >    The FCIP Entity MAY apply a timeout of not less than 90 seconds
   >    to the waiting for the FCIP Special Frame bytes and if the
   >    timeout expires the FCIP Entity SHALL close the TCP Connection
   >    and notify the FC Entity with the reason for the closure.

   I am not clear why this notification is required, since the local FC
   Entity did not motivate the TCP connection establishment. If it is
   intended for logging, perhaps notifying the Control & Services module
   would be more appropriate.

   > 9.1.2.3 Connection Setup After a Successful TCP Connect Request
   ......
   >    If the Connection Nonce field contains a value identical to the
   >    most recently received Connection Nonce from the same IP Address,
   >    the FCIP Entity SHALL close the TCP Connection and notify the FC
   >    Entity with the reason for the closure.

   Same comment.

   Rejected

   Current plans call for the MIB interface to be in the FC Entity.
   Therefore, this notification is necessary for MIB logging. Also,
   requirements are being added to FC-BB-2 that depend on the
   requirement as stated in FCIP.

Comment 130

   > 9.1.2.3 Connection Setup After a Successful TCP Connect Request
   ......
   >    1)  Leave the Destination FC Fabric Entity World Wide Name field
   >        and Ch bit both 0;

   So allow the FCIP Link to be established? It is unclear to me how
   implementations adopting this option would be able to prevent
   unintended FCIP Link formation.

   Accepted

   A requirement needs to be added somewhere that the TCP Connection
   MUST be closed if the echoed Destination FC Fabric Entity World Wide
   Name field contains zero.




Ralph Weber                                                    [Page 68]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


Comment 131 Technical

   > 9.1.2.3 Connection Setup After a Successful TCP Connect Request
   ......
   >    2)  Change the Destination FC Fabric Entity World Wide Name field
   >        to match FC Fabric Entity World Wide Name associated with the
   >        FCIP Entity that received the TCP connect request and change
   >        the Ch bit to 1; or

   In effect, this is being indirectly allowed as a legal discovery
   process. Is there a DoS concern here? Also, would revealing the FC
   WWN be acceptable in confidentiality terms?

   Duplicate of comment 53.

Comment 132

   > 9.1.2.3 Connection Setup After a Successful TCP Connect Request
   ......
   >    3)  Close the TCP Connection without sending any response.

   I like this option best, :-)

   Inquiry

   See comment 53.

Comment 133

   > 10.2 FC Fabric and IP Network Deployment Models
   ......
   >        Entities in an equal manner. This varies from a true Client-

   S/b "varies" w/ "differs".

   Accepted














Ralph Weber                                                    [Page 69]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


3. Comments from Don Fraser
   ========================

Comment 134

   9.1.3 (page 31)

   "If an FCIP Entity receives a duplicate FCIP Short Frame during the
   FCIP Link formation process,..."

   "Short Frame" s/b "Special Frame"

   Accepted

Comment 135

   Annex G (page 63)

   The reference to section 9.5, should refer to 9.4.

   Accepted

Comment 136

   Annex G

   The table should have a number and title like the rest of the
   tables in the document. Also, do not put just the table header
   on a page by itself.

   Accepted



















Ralph Weber                                                    [Page 70]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


4. Comments from Murali Rajagopal
   ==============================


Comment 137

   -- Section 5 Protocol Summary

      8)  The FCIP Control & Services function MAY use TCP/IP quality of
          service features (see section 11.2) to support Fibre Channel
          capabilities.

   [E] "function" s/b "Module".

   Accepted


5. Comments from Bob Snively
   =========================

Comment 138

   -- 6.6.2.3 Synchronization Failures

   I would suggest the following minor editorial correction:

           b) return to sending valid FC Frames only after
           synchronization has been verified; and

   should be changed to:

           b) return to emitting frames through the FC Transmitter
           Portal only after synchronization has been verified; and

   Accepted with changes

   Make the change as written, except replace "emitting" with
   "forwarding".












Ralph Weber                                                    [Page 71]


Internet-Draft              FCIP 1st WG Last Call              May, 2002


6. Comments from Ralph Weber
   =========================

Comment 139

   Annex C (first step in algorithm)

   "f) Reserved field and its ones complement."

   The "reserved" field is now pFlags.

   Accepted

Comment 140 Technical

   The bit/byte numbering resolution approved for the FC Frame
   Encapsulation draft must be replicated in this draft.

   Accepted

Comment 141 Technical

   In order to support the FC-BB-2 Link Keep Alive (LKA) switch
   internal link service, it is necessary for FC/FCIP Entities to
   communicate a time interval for transmission of the LKA. The
   T11 FC-BB-2 working group has asked that this 32-bit quantity
   be added to the Special Frame.

   Accepted

Comment 142

   Update contributors and acknowledgements.
   Update contact information for Murali Rajagopal.
   Move Jim Nelson from contributors to acknowledgements since Jim no
   longer is FC-FS editor and has provided no updated contact
   information.

   Accepted











Ralph Weber                                                    [Page 72]


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