IPS Working Group                                               R. Weber
INTERNET-DRAFT
<draft-ietf-ips-fcencap-wglc-00.txt>
(Expires September, 2002)


                  FC Frame Encapsulation 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-fcencapsulation-06.txt

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


Summary of Comments

   Technical:  17 Comments, resulting in about  12 Changes
   Editorial:  60 Comments, resulting in about  41 Changes
   -------------------------------------------------------
     Totals:   77 Comments, resulting in about  53 Changes




Ralph Weber                                                     [Page 1]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Table Of Contents

   1. Comments from David Black  . . . . . . . . . . . . . . . . . . . 2
   2. Comments from Mallikarjun Chadalapaka . . . . . . . . . . . . . 19
   3. Comments from Rob Elliott . . . . . . . . . . . . . . . . . . . 23
   4. Additional Changes Discovered After WG Last Call  . . . . . . . 32


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

Comment 1

   -- Section 1 - Scope

      The organization responsible for the Fibre Channel standards (NCITS
      Technical Committee T11) has determined that some functions and
      modes of operation are not interoperable to the degree required by
      the IETF. This draft includes applicable T11 interoperability
      determinations in the form of restrictions on the use of this
      encapsulation mechanism.

   [E] Is there an official citation for this statement? It really needs
   one to be published in an archival unchangeable format such as an RFC.

   Accepted resulting in the following changes

   Add reference to FC-MI. Change "NCITS" to "INCITS".

Comment 2

   -- Section 2 - Encapsulation Concepts

           FC frames have several possible lengths.

   [E] Should read "variable length" or something like that - this
   implies several possible choices of fixed length, which is incorrect.

   Accepted as follows

   Replace the sentence with: "FC frames are variable length."









Ralph Weber                                                     [Page 2]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 3

   -- Section 2 - Encapsulation Concepts

      To facilitate transporting FC frames over TCP the native FC frame
      needs to be contained in (encapsulated in) a slightly larger
      structure as shown in figure 1.

   [E] The use of TCP in this context is overly restrictive. This
   encapsulation is in principle applicable to any means of transport
   over IP, including TCP, SCTP, UDP, and carrier pigeon :-), even though
   in practice all the initial uses will use TCP.

   Accepted as follows

   Change "over TCP" to "over an IP based transport such as TCP".

Comment 4

   -- Section 2 - Encapsulation Concepts
      The format and content of an FC frame is described in the FC

   [E] "is" --> "are"

   Accepted

Comment 5 Technical

   -- Section 3 - The FC Encapsulation Header
   -- Section 3.1 - FC Encapsulation Header Format

      The values in the Protocol# field are assigned by
      IANA [8]. The following values are known to be in use:

       - FCIP -- TO BE ASSIGNED by IANA
       - iFCP -- TO BE ASSIGNED by IANA

   [T] Delete the text starting with "The following values" and insert
   a forward reference to the IANA Consideration section.

   Accepted as written.









Ralph Weber                                                     [Page 3]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 6 Technical

   -- Section 3 - The FC Encapsulation Header
   -- Section 3.1 - FC Encapsulation Header Format

      FC Encapsulation receivers may compare the Protocol# and -Protocol#
      fields as an additional verification that an FC Encapsulation
      Header is being processed.

      FC Encapsulation receivers may compare the Version and -Version
      fields as an additional verification that an FC Encapsulation
      Header is being processed.

   [T] Those "may"s are misleading. I think "SHOULD" is appropriate, but
   I could accept "SHOULD"s that only applied when the CRC is not valid.

   Accepted as follows

   Replace the two cited sentences with:

      FC Encapsulation receivers SHOULD either validate the CRC or
      compare the Protocol# and -Protocol# fields to verify that an
      FC Encapsulation Header is being processed according to a
      policy defined by the encapsulating protocol.

      FC Encapsulation receivers SHOULD either validate the CRC or
      compare the Version and -Version fields to verify that an
      FC Encapsulation Header is being processed according to a
      policy defined by the encapsulating protocol.

   As per comment 8, sentences similar to those shown above will be
   added to the -Flags and -Frame Length descriptions.


















Ralph Weber                                                     [Page 4]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 7 Technical

   -- Section 3 - The FC Encapsulation Header
   -- Section 3.1 - FC Encapsulation Header Format

      Flags (bits 31-26 in word 3): The Flags bits provide information
      about the usage of the FC Encapsulation Header as shown in figure
      3.

      Note: Implementers are advised to consult the specifications of
      protocols that use this header to determine how each individual
      protocol uses the bits in the Flags field.

   [T] The "Note:" paragraph is part of the CRCV issue (see below), and
   probably needs to be deleted as part of resolving that issue. This
   paragraph also has the additional problem in that it implies that
   protocol specific uses of the reserved flags are allowed, which is not
   the case.

   Accepted

Comment 8 Technical

   -- Section 3 - The FC Encapsulation Header
   -- Section 3.1 - FC Encapsulation Header Format

      Reserved (Flags, bits 31-27 in word 3): These bits are reserved for
      use by future versions of the FC Encapsulation and SHALL be set to
      zero on send. Protocols employing this encapsulation MAY require
      checking for zero on receive, however doing so has the potential to
      create incompatibilities with future versions of this
      encapsulation.

   [E] Second sentence is poorly worded. Suggested rewrite: Protocols
   employing this encapsulation SHOULD ignore the Reserved bits on
   receive in order to avoid creating incompatibilities with possible
   future versions of this encapsulation. I believe this change is
   editorial, and it also applies to the -Flags and -Frame Length fields.

   Rejected

   This change is not editorial. It is technical and specifically
   recommends against some of the validity checking described in FCIP.
   The working group argued this issue several times and (I thought)
   agreed that checking the version number was sufficient to know that
   the reserved flags must be zero.




Ralph Weber                                                     [Page 5]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


   The last sentence of the comment is a misnomer with respect to the
   rest of the comment, however it makes sense when applied to comment 6.

Comment 9 Technical

   -- Section 3 - The FC Encapsulation Header
   -- Section 3.1 - FC Encapsulation Header Format

      CRCV (CRC Valid Flag, bit 26 in word 3): A CRCV bit value of one
      indicates that the contents of the CRC field are valid. A CRCV bit
      value of zero indicates that CRC are invalid. Some protocols may
      always check the CRC without regard for the state of this bit. The
      value of the CRCV bit SHALL be constant for all FC Encapsulation
      Headers sent on a given TCP connection.

   [T] The "Some protocols may always check the CRC ..." is the CRCV
   issue that Mallikarjun also found and that has been problematic in the
   past. I believe that what's going on here is that all protocols have
   to check the Protocol#, and once that's been checked, the
   implementation knows whether there's supposed to be a CRC there and
   hence doesn't need to look at CRCV. In practice this won't cause
   problems, as including the CRC when it's not supposed to be there is
   harmless, and failing to include it when it should be there will
   almost certainly cause a CRC check failure.

   I offer a proposal to resolve this by expanding the Protocol#
   registry that IANA will create so that each registered protocol
   must supply not only its name and an RFC reference, but also whether
   the protocol uses (Yes) or does not use (No) the CRC in this header.
   The above text could then be revised to make the CRCV check at the
   receiver OPTIONAL in all cases because its value can be inferred
   from the protocol#.

   Rejected in principle, with some changes required

   At the Nashua interim, someone wanted a client protocol to be free
   to use CRC or not according to operating environments (e.g., lab-
   local vs. network attachment). The proposed definition of usage by
   IANA based on protocol would eliminate this option.

   It must be noted that the content of Annex A also conflicts with
   this result from the Nashua interim. To correct that, the following
   text from Annex A must be replaced:

      "CRC

      "Protocols employing this encapsulation SHALL either:



Ralph Weber                                                     [Page 6]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


      "1) Require a valid CRC to be sent and the CRCV Flag bit to be
          sent as one, or
      "2) Require the CRC field to be sent as zero and the CRCV Flag
          bit to be sent as zero."

   The Annex A CRC discussion (shown above) will be replaced with:

      "Protocols employing this encapsulation SHALL define the
       procedures and policies necessary for verifying that an
       FC Encapsulation Header is being processed."

   Also, make the change described in the response to comment 35.

Comment 10

   -- Section 3 - The FC Encapsulation Header
   -- Section 3.1 - FC Encapsulation Header Format

   [E] Also need to generalize away from TCP connection to allow possible
   future use with other transports.

   Accepted, resulting in the following changes

   1) In the description of CRCV: change "TCP connection" to
      "connection";

   2) In Section 4:
    - change "TCP-connected elements" to IP-connected elements";
    - change "traverse the TCP connection" to "traverse the
      connection";
    - change "injected into a TCP connection" to "injected into
      a connection"; and

   3) In Section 5.3: change "transmission over TCP" to "transmission
      over an IP Network";















Ralph Weber                                                     [Page 7]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 11 Technical

   -- Section 3 - The FC Encapsulation Header
   -- Section 3.1 - FC Encapsulation Header Format

   [T] Here or in the description of the Protocol Specific fields, a
   warning to implementers is needed says some sort of error checking
   redundancy (e.g., the ones complements found elsewhere in the header)
   SHOULD (or MUST) be used when the CRC is not used. This warning
   should be duplicated in Section 3.2.1. This is a technical comment,
   but should not be controversial.

   Rejected

   Specific statements of action have been added to each applicable
   field as per comment 6.

Comment 12 Technical

   -- Section 3 - The FC Encapsulation Header
   -- Section 3.1 - FC Encapsulation Header Format

      Time Stamp [integer] and Time Stamp [fraction] (words 4 and 5): The
      two Time Stamp fields contain time at which the FC Encapsulated
      frame was sent as known to the sender. The format of integer and
      fraction Time Stamp word values is specified in Simple Network Time
      Protocol (SNTP) Version 4 [9]. The contents of the Time Stamp
      [integer] and Time Stamp [fraction] words SHALL be set as described
      in section 4.

   [E] For convenience, it might be good to summarize those formats here
   with an indication that [9] is the normative authority. I don't feel
   strongly about this, though.

   [T] We have a problem here - RFC 2030 is Informational, and hence
   can't be referenced in a normative fashion from a standards track
   document. I'll talk to Ralph offline about how to get around this.

   Accepted resulting in the following changes

   1) Copy the definitions of the two time stamp words from RFC 2030
      to this draft (estimated to be 2 paragraphs);
   2) Copy any necessary ancillary definition text from RFC 2030 to
      this draft (estimated to be no more than 5 paragraphs); and
   3) Make the reference to RFC 2030 information, both in the body
      text and in a Informative References section (which will have
      to be added).



Ralph Weber                                                     [Page 8]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 13

   -- Section 3 - The FC Encapsulation Header
   -- Section 3.1 - FC Encapsulation Header Format

      CRC (word 6): When the CRCV Flag bit is zero, the CRC field SHALL
      contain zero. When the CRCV Flag bit is one, the CRC field SHALL
      contain a CRC for words 0 to 5 of the FC Encapsulation Header
      computed using the polynomial, initial value, and bit order defined
      for Fibre Channel in FC-FS [3]. Using this algorithm, the bit order
      of the resulting CRC corresponds to that of FC-1 layer. The CRC
      transmitted over the IP network shall correspond to the equivalent
      value converted to FC-2 format as specified in FC-FS.

   [E] I realize that FC-FS is the latest and greatest version of the FC
   frame standard, BUT, referencing a project in progress for this sort
   of basic CRC mechanism is an invitation to procedural problems. Can
   this reference be changed to FC-PH accompanied by a note that FC-FS is
   supplanting FC-PH, but will make *no* changes in this area? Note that
   I'm comfortable with the earlier reference to FC-FS for frame
   contents.

   Accepted (Partially)

   T11 has clearly stated that FC-PI and FC-FS are the preferred
   documents over FC-PH. The statement takes the form of a refusal to
   process FC-PH for international standardization, with the preferred
   recourse being to process FC-PI and FC-FS when they are available.

   Furthermore, referencing FC-PH really requires references to FC-PH-2
   and FC-PH-3, since FC-PH is not a fully correct document in and of
   itself. In other words, there is a rats nest here.

   It is not a matter of FC-FS being the latest and greatest. T11 has
   unambiguously stated that FC-PI and FC-FS are the only true path
   with very clear reasons for that decision.

   Action to be taken:

   In the References section, the note will be added following the
   FC-FS reference: "Note: The Fibre Channel frame structure and CRC
   features referenced by this draft, while formally described in
   FC-FS, are substantially unchanged from similar features described
   in Fibre Channel Physical and Signaling Interface (FC-PH), ANSI
   X3.290-1994, June 1, 1994."





Ralph Weber                                                     [Page 9]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 14 Technical

   -- Section 3.2.1

   [T] The warning that the protocol-specific fields SHOULD (or MUST) be
   protected by redundancy needs to go here.

   Accepted.

Comment 15

   -- Section 3.2.1

      Redundancy based header validation can be built from simple logic
      (e.g., XORs and comparisons). Header validation based on redundancy
      also is a step wise process in that the first word is validated,
      then the second, then the third and so on. A decision that a
      candidate header is not valid may be reached before the complete
      header is available.

   [E] First sentence is superfluous and probably should be deleted as
   it's rather hardware-oriented.

   Accepted with the following results

   Replace the cited paragraph with: "Header validation based on
   redundancy is a step wise process in that the first word is
   validated, then the second, then the third and so on. A decision
   that a candidate header is not valid may be reached before the
   complete header is available."




















Ralph Weber                                                    [Page 10]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 16

   -- Section 3.2.2

      CRC based header validation employs a straight forward algorithm
      (e.g., compute the CRC for all bytes preceding the CRC word and
      compare the results to the CRC word's contents). The number of
      comparisons required to perform CRC validation is exactly one and
      the method for computing the CRC is well known with proven
      implementations.

   [E] Last sentence is superfluous and probably should be deleted as
   it's rather hardware-oriented.

   Accepted with the following results

   Replace the cited paragraph with: "Header validation based on the
   CRC defined in section 3.1 requires computing the CRC for all bytes
   preceding the CRC word, and comparing the results to the CRC word's
   contents."

Comment 17

   -- Section 4 - Measuring Fibre Channel frame transit time

      To comply with FC-FS [3], an FC Fabric must specify and limit the
      lifetime of a frame.

   [E] Same comment as before about referencing FC-FS. Can this be
   changed to reference FC-PH with a note that FC-FS won't change this
   ... or is FC-FS tinkering with things here?

   Rejected see response to comment 13.

















Ralph Weber                                                    [Page 11]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 18 Technical

   -- Section 4 - Measuring Fibre Channel frame transit time

      When originating an encapsulated frame, an entity that does not
      support transit time calculation SHALL always set the Time Stamp
      [integer] and Time Stamp [fraction] fields to zero. When receiving
      an encapsulated frame, an entity that does not support transit time
      calculation SHALL ignore the contents of the Time Stamp words. The
      protocol SHALL specify whether or not implementation support is
      required.

   [T] This is about "MUST/SHOULD/MAY implement". Need a similar
   requirement on the protocol to specify "MUST/SHOULD/MAY use" and under
   what conditions.

   Accepted with the following results

   Add the following sentence: "The protocol SHALL specify those
   conditions under which a received encapsulated frame MUST have
   its transit time checked before forwarding."

Comment 19 Technical

   -- Section 4 - Measuring Fibre Channel frame transit time

      The policy for processing frames while in the Unsynchronized state
      SHALL be defined by the protocol specification, including whether
      or not the entity may continue to send and receive frames from the
      IP network.

   [T] On the receive side, this condition appears to be specified in the
   wrong direction. Receiving frames from the IP network cannot possibly
   cause problems, the issues are in forwarding (stale) frames into FC.

   Accepted resulting in the following changes

   1) Change "processing" to "forwarding"; and
   2) Remove "including whether ..." to the end of the sentence.











Ralph Weber                                                    [Page 12]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 20

   -- Section 4 - Measuring Fibre Channel frame transit time

      When de-encapsulating a frame, an entity in the Synchronized state
      SHALL:

   [E] While the sub-bullets are correct, they leave a reader unfamiliar
   with FC somewhat high and dry. I would include a "for example" in
   both a) and b), along the lines of:

           a) For example, if a calculated transit time exceeds a value
              that could cause the frame to violate FC maximum time in
              transit limits (Time Out Values), the protocol may specify
              that the frame is to be discarded.
           b) For example, a protocol may specify that frames for which
              transit time cannot be determined are never to be forwarded
              over FC.

   Accepted with changes

   Everything except he phrase "(Time Out Values)" will be incorporated
   as written.

Comment 21

   -- Section 4 - Measuring Fibre Channel frame transit time

   [T] At the end of this section, it would be good to warn protocol
   designers that well-designed protocols are unlikely to accomplish
   useful communication when the communicating entities are in different
   states, and hence protocol designers need to consider how to
   coordinate state transitions, especially the Unsynchronized to
   Synchronized transition on startup and an unexpected Synchronized to
   Unsynchronized transition (e.g., caused by loss of contact with an
   external time service). This is related to some issues that
   Mallikarjun found.

   Accepted but only in principle

   The problem is not coordinating states between the two entities. The
   problem is keeping both entities in the Synchronized state as much
   of the time as possible.

   Little, if anything, is accomplished by adding protocol overhead to
   coordinate state transitions.

   This is not to say that the comment lacks merit.


Ralph Weber                                                    [Page 13]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002



   Action to be taken:

   Add the following note at the end of the section: "Note: For most
   purposes, communication between entities is possible only while in
   the Synchronized state."

Comment 22

   -- Section 5 - The FC frame
   -- Section 5.1 - FC frame content

      As shown in figure 4, the FC frame content is defined as the data
      between the EOF and SOF delimiters (including the FC CRC) after
      conversion from FC-1 to FC-2 format as specified by FC-FS [3].

   [E] This needs some more explanation. The important things that need
   to be said are:
           - FC uses the same 8b/10b encoding as Gigabit Ethernet in
             which each 8 bit byte is transmitted using 10 bits on the
             wire for reasons that include redundancy and low level
             timing synchronization between sender and receiver.
           - All discussion of FC frame content in this draft is at the
             8b level prior to 8b->10b expansion on send or after 10b->8b
             reduction on receive.

   The Gigabit Ethernet reference is particularly important in increasing
   accessibility of this document to a network-savvy, but new to FC
   audience.

   Accepted but only in principle

   The 8b/10b statement is no more accurate for Fibre Channel than
   it is for Ethernet. Ten Gigabit Fibre Channel will use 64b/66b
   encoding, the same as ten Gigabit Ethernet. Such a statement must
   be worded as an example.

   Action to be taken:

   Add the following paragraph at the end of the section: "In the
   conversion to the FC-0 physical transport, an encoding is applied to
   the FC frame content (e.g., 8b/10b encoding like that used in Gigbit
   Ethernet) for reasons that include redundancy and low level timing
   synchronization between sender and receiver. All discussion of FC
   frame content in this document is at the 8-bit byte level, prior to
   the application of any such encoding."




Ralph Weber                                                    [Page 14]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 23

   -- Section 5.3 - FC SOF and EOF

      The FC frame content is composed of 8-bit bytes that can be
      translated directly for transmission over TCP. The FC SOF and EOF
      [3] require 8b/10b special characters that cannot be translated
      directly to 8-bit bytes, encoded values are required.

   [E] I think this paragraph needs to be moved to Section 5.1, and
   replaced with a sentence here that refers back to it. One important
   editorial change is "8b/10b special characters that cannot be
   translated directly to 8-bit bytes" should be changed to "10b special
   characters that have no 8b equivalents" or something like that.

   Accepted

Comment 24 Technical

   -- Section 5.3 - FC SOF and EOF

      SOF (bits 31-24 and bits 23-16 in word 0): The SOF fields contain
      the encoded SOF value selected from table 1.

   [T] As we've learned from the Class 4 adventure, this table is subject
   to change/extension. IANA will need to manage it, and will need some
   sort of allocation guidelines to remain consistent with whatever
   mechanism produced this peculiar set of values. While we probably
   don't want to allow value recycling, we may want to write some text
   dealing with retiring values (making them no longer usable). This
   also applies to the EOF values in Table 2.

   Rejected

   The SOF/EOF codes are stable and have not changed for at least three
   years. They have been implemented in numerous products for tunneling
   FC over ATM and SONET. The only instability is the editor's lack of
   understanding about which SOF/EOF codes are required for FC Class 4
   operation.

   The codes are assigned by T11 and involving IANA in there assignment
   would constitute a conflict of jurisdictions.








Ralph Weber                                                    [Page 15]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 25

   -- Section 5.3 - FC SOF and EOF

      Note: FC-BB-2 [6] lists SOF and EOF codes not shown in table 1 and
      table 2 (e.g., SOFi1 and SOFn1). However, FC-MI [7] identifies
      these codes as not interoperable, so they are not listed in this
      specification.

   [T] There are a couple of problems here. If FC-BB-2 has assigned
   values to SOF and EOF encodings that MUST NOT be used with FCIP, then
   we need to instruct IANA to reserve and not allocate those values. As
   part of allocating future values in this table, we need to (1)
   instruct the author(s) of the draft/RFC doing the allocation to ensure
   that T11.3 review of the proposed allocation is obtained (2) that the
   IPS WG chair(s) (if the IPS WG still exists) and the Transport ADs are
   informed of this review, and (3) that IANA allocates the values
   approved by T11.3 as opposed to choosing values. Since Murali's been
   appointed as T11's official liaison to IETF, I think it's his
   responsibility to suggest a coordination process.

   Accepted only because a platform is needed for an editorial change

   As per the response to comment 25, IANA must not be involved in
   assigning SOF/EOF codes.

   Actions to be taken

   The SOF and EOF tables will be modified to add a column for "Class"
   and each SOF or EOF value will have one of the following entered in
   the new column: "2", "3", "2 & 3", "2, 3 & 4", or "4".

   The new column will allow FCIP and iFCP to reference Class 2,
   Class 3, and Class 4 SOF/EOF values in their statements of what
   the protocol supports.















Ralph Weber                                                    [Page 16]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 26

   -- Section 7 - Normative References

   I would really like to remove the normative reference to FC-FS,
   substituting FC-PH with a note that FC-FS will replace FC-PH. I don't
   object to an FC-FS reference where it's really needed, but the
   portions of FC-FS that this draft relies on are sufficiently basic and
   stable that an FC-PH reference will make their stability clear. The
   FC-BB-2 and FC-MI references for SOF and EOF codes need to become non-
   normative as part of setting up the IANA registry and management
   process. The FC-SW-2 reference may not need to be normative here.

   Rejected see response to comment 13.

Comment 27

   -- Section 7 - Normative References

   RFC 1700 is almost certainly the wrong reference to instruct IANA on
   what procedures to follow. See RFC 2434 for guidance on this topic,
   although it may not be necessary to reference it.

   Accepted

Comment 28

   -- ANNEX A - Protocol Requirements

   [E] I think this should be an Appendix, rather than an Annex. Some
   changes may be in order here based on the above comments.

   Accepted resulting in the following changes

   1) Change "Annex A" to "Appendix A" and "Annex B" to "Appendix B",
      while remembering to correct the Table of Contents too;
   2) Add discussion of IANA assignment of CRC usage, per the
      resolution of comment 9; and
   3) In item d) change "processing" to "forwarding".











Ralph Weber                                                    [Page 17]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 29

   -- ANNEX B - IANA Considerations

   [T] This needs to be made somewhat more explicit and direct. IANA is
   looking for simple straightforward instructions roughly of the form
   "IANA is instructed to do <X>". in particular, the following sentence
   is a problem:

      Standards action on this RFC should be accompanied by IANA
      assignment of the following two Protocol# values:

   It should read something like:

      In addition to creating the FC Encapsulation Protocol Number
      Registry, the standards action of this RFC allocates the following
      two values from this registry:

   While one normally asks IANA to allocate values, the exception is that
   when creating a registry, one can instruct IANA as to what the initial
   contents are (i.e., a new registry does not have to be created empty).

   Accepted

Comment 30

   -- ANNEX B - IANA Considerations

   [T] Also, earlier comments suggest that the Protocol# registry needs
   to be expanded with a CRC field (Yes/No) and that registries need to
   be created for the SOF and EOF values.

   Rejected See comment 9 and comment 24.

















Ralph Weber                                                    [Page 18]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 31

   -- ANNEX B - IANA Considerations

      It is requested that the ips working group chairs or the Transport
      Services area directors be notified when any new Protocol# value
      assignment is requested.

   [T] Given that an approved RFC is required, this sentence seems
   redundant. If the intent was notification of the IPS WG chairs and/or
   ADs when a an I-D draft is submitted that will cause a Protocol#
   assignment if/when approved as an RFC, the language needs to say that
   and should be rephrased to require notification of the IP Storage WG
   chairs (don't use WG acronyms here) and notification of the Transport
   ADs instead in the case that the IPS WG does not exist or is not
   active.

   Accepted, delete the sentence

Comment 32

   -- ANNEX B - IANA Considerations

   [T] Also see previous comments about needing to set up an IANA
   registry for SOF and EOF values. I'll work with Ralph on crafting the
   right IANA instructions.

   Rejected see comment 24.


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

Comment 33 Technical

   - Section 3.1, page 4. For the Protocol# values for FCIP and iFCP,
     the Annex B should instead be referred.

   Accepted see comment 5.











Ralph Weber                                                    [Page 19]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 34 Technical

   - Section 3.1, pages 4 & 5. I notice that all the ones complement
     fields (-Protocol#, -Version etc.) are described as "contains the
     ones complement" as opposed to "SHALL contain ones complement",
     whereas the corresponding non-1's complement fields have the SHALL
     wording. Any reasons for this distinction?

   Accepted

   Change -xxx descriptions to use SHALL.

Comment 35 Technical

   - Section 3.1, page 5, CRCV bit description.
           "Some protocols may always check the CRC without regard for
           the state of this bit."
      I am troubled by the literal implication of this sentence. Why
      would that be so?
      Would the encapsulating protocol not mandate CRCV to be set to
      valid always instead? It seems like the purpose of defining a
      common encapsulation format and associated semantics is watered
      down for no stated reason...

   Accepted

   Delete the cited sentence.

   The following response is provided in response to the question asked
   in the last paragraph of the comment. FCIP mandates that CRCV be
   zero. iFCP mandates that CRCV be one.

Comment 36

   - Section 3.2.1, page 7. S/b "step wise" w/ "stepwise".

   Accepted













Ralph Weber                                                    [Page 20]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 37

   - Section 4, page 7.
          "The protocol SHALL specify whether or not implementation
          support is required."
      A general comment on usage of the term "protocol" here and in other
      areas - I would recommend using "encapsulating protocol" instead to
      make it easier (or perhaps use "Protocol" may be...) for the reader
      to follow the usage.

   Accepted, use "encapsulating protocol"

Comment 38

   - Section 4, page 8. Since there is no mention of a notification
     frame to announce an entity's transition into/out of the
     Synchronized state, I assume it's possible and even anticipated that
     there may be times when one of the two entities may be in
     Unsynchronized state even while the operational encapsulating
     protocol requires Synchronized operation. The expectation is that
     the state rules (and encapsulating protocol-specified rules) should
     cause this type of start-up/transient scenario to be correctly
     sorted out. Is that right?

   Inquiry

   Yes it is anticipated that one entity may be in the Unsynchronized
   state and thus discarding some FC frames. Presumably, the entity
   will return to the Synchronized state quickly or close the connection.

   It is not clear that any requirements need to be state for
   interoperability. It is definitely undesirable to add protocol
   overhead to coordinate the synch/unsynch state without there being
   a well demonstrated need.

Comment 39 Technical

   - I think it might be useful to add a statement in this section along
     the lines of - If the encapsulating protocol mandates Synchronized
     operation, the entity MUST NOT accept TCP connections on the well-
     known port(s) unless the entity is in the Synchronized state.

   Rejected

   Since encapsulating protocols are allowed to specify operation in
   the Unsynchronized state, specifying this level of detail about how
   Synchronized operation is handled over reaches the bounds of this
   specification.


Ralph Weber                                                    [Page 21]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002



Comment 40 Technical

   - Section 4, page 9, Synchronized state rules. I think this should
     also address what is to be done in case there's a case of "bad
     synchronization" when Time Stamp words are valid. For ex., when the
     received value is smaller than the received entity's timebase, I
     assume it would result in arriving at a huge transit time. While
     the huge transit time may cause the frame to be discarded, it isn't
     clear to me what may cause the TCP connection drop and a re-synch.

   Accepted with the following results

   Change the recommended transit time evaluation to use the absolute
   value of the time difference.

Comment 41

   - Section 4, page9, Synchronized state rules.
      "If both Time Stamp words have a value of zero, the receiving
      entity SHALL process the de-encapsulated frame without computing
      the transit time. The disposition of the frame and any other
      actions by the recipient SHALL be defined by the protocol
      specification."

     I am rather perplexed by the usage of the words here. While saying
     that the frame shall be "processed", this also seems to leave it up
     to the encapsulating protocol to define if it needs to be processed
     (as reaffirmed by rule (e) in Annex A). One change that makes it
     clear to me is:
       S/b "SHALL process the de-encapsulated frame"
         w/ "SHALL de-encapsulate the frame".

   Accepted

Comment 42

   - Section 7
   It may be useful to add informative references to FCIP and iFCP.

   Rejected

   Adding such references seems ill advised for the following reasons:

   1) Their presence will delay publication of this draft until both
      FCIP and iFCP have cleared the last call process; and
   2) Such references will be less than informative in the specific
      event that this document was commissioned to serve, the case


Ralph Weber                                                    [Page 22]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


      where a third FC encapsulation protocol is defined, after which
      this document would mislead readers into believing that only two
      "encapsulating protocols" exist.

Comment 43

   - Section 9, page 13. S/b "no long working" w/ "no longer working".

   Accepted

Comment 44

   - Annex B, page 15. It isn't clear to me from this sentence if the
      Protocol# values (1 & 2) are temporarily assigned by this draft for
      now.

       "Standards action on this RFC should be accompanied by IANA
        assignment of the following two Protocol# values:"

   Inquiry

   It is said that IANA will not assign the Protocol# values until
   presented with an RFC (not an internet draft) that instructs them to
   do so. Therefore, the current Protocol# values are requests to IANA
   (or perhaps instructions to IANA).


3. Comments from Rob Elliott
   =========================

Comment 45

   Title page
   I assume change bars will be gone from the final version.

   Inquiry

   The change bars appear only in the PDF file. The normative document
   in IETF terms is the TXT file, where there are no change bars.

Comment 46

   Abstract
   "common encapsulation" s/b "common Fibre Channel encapsulation"

   Accepted




Ralph Weber                                                    [Page 23]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 47

   1 Scope
   "NCITS" s/b "INCITS"

   Accepted

Comment 48

   All section headers
   Should each word in a section header be capitalized or not? This
   document has a mix.

   (3.2.2 doesn't capitalize validation, 4 doesn't capitalized frame
   transmit time, etc.)

   Accepted as follows

   All section headers will be modified to follow the capitalization in
   the header for section 3.1.

Comment 49

   2. Encapsulation Concepts
   "The Fibre Channel frame has a CRC that provides error detection..."
   s/b "The Fibre Channel frame includes a Cyclic Redundancy Check (CRC)
   code that provides error detection..."

   Accepted

Comment 50

   Figure 1 Title
   "FC frame Encapsulation" s/b "Encapsulated FC Frame"

   Response

   This figure and the text describing it are concerned with how a FC
   frame is encapsulated. Thus the figure title. The fact that the
   result is an Encapsulated FC Frame should not be introduced in a
   figure title.









Ralph Weber                                                    [Page 24]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 51

   3.1 Figure 2
   Where is word defined as 32 bits?

   Response

   This figure seems to define that concept clearly. It would be a
   shame to add a glossary to the draft simply to contain this one
   definition.

Comment 52

   3.1 FC Encapsulation Header Format
   "Protocol (bits 31-24 in word 0):" s/b "Protocol# (bits 31-24 in word
   0):"

   Accepted

Comment 53

   3.1 FC Encapsulation Header Format
   RE: "TO BE ASSIGNED by IANA"

   When are these protocol values filled in?

   Inquiry

   See the response to comment 44.

Comment 54

   3.1 FC Encapsulation Header Format
   "The Version field SHALL contain 0x1 ..." s/b "The Version field SHALL
   contain 0x01 ..." since Version is an 8-bit field.

   Accepted

Comment 55

   All instances of "ones complement"
   "ones complement" s/b "one's complement"

   Google reports 10,000 "one's complement" vs 3700 "ones complement"

   Accepted




Ralph Weber                                                    [Page 25]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002



Comment 56

   3.1 FC Encapsulation Header Format
   "...i.e., the usage of this word is defined..." s/b "...i.e., the
   usage of these words is defined..." because there are two protocol
   specific words.

   Accepted

Comment 57

   3.1 FC Encapsulation Header Format
   Regarding: "Protocols employing this encapsulation MUST NOT make use
   of the Reserved Flags bits in any fashion other than that described
   here." "here" s/b "by this encapsulation". "Here" implies that future
   versions are excluded.

   Accepted

Comment 58

   3.1 FC Encapsulation Header Format
   "A CRCV bit value of zero indicates that CRC are invalid." s/b "A CRCV
   bit value of zero indicates that the contents of the CRC field are
   invalid."

   Accepted

Comment 59

   3.1 FC Encapsulation Header Format
   Frame Length is a greater than 1 byte quantity. Which bit is the MSB?

   There's discussion later on page 9 inside the FC frame section, but
   endianness should be covered before the encapsulation header is
   described.

   Rejected

   Per http://www.ietf.org/ID-nits.html:

   "Historically, RFCs have specified byte and bit order according
   to a US DoD rule which made byte zero be the first byte in an
   address range, and bit zero be the most significant bit in a
   word or field. For example, you will find drawings like this
   one (from RFC 791) in many RFCs: when you make drawings like
   it, you should follow the same rule. Label your bit positions,


Ralph Weber                                                    [Page 26]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


   bit zero is the most significant bit, and place the first
   addressable byte at the upper left-hand corner."

   Observance of these rules is enforced for all RFCs. Therefore,
   additional specifics are unnecessary.

   See also comment 77.

Comment 60

   3.1 FC Encapsulation Header Format
   Regarding: "...the FC Encapsulation Header SHALL always be word-
   aligned;..."

   Replace "SHALL" with "is".SHALL doesn't seem right here. There's no
   option to not make it aligned, since the format is fixed length. We
   don't say the CRC field shall be one word long - it just is one word
   long.

   Accepted

Comment 61

   3.1 FC Encapsulation Header Format
   "...contain time..." s/b "...contain the time..."

   Accepted

Comment 62

   3.1 FC Encapsulation Header Format
   Should the field names in SNTP ("Seconds" and "Seconds fraction") be
   referenced? It's not immediately obvious which words correspond.

   Accepted as follows

   Change all occurrences of "[integer]" to "[Seconds]" and all
   occurrences of "[fraction]" to "[Seconds Fraction]".












Ralph Weber                                                    [Page 27]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 63

   3.1 FC Encapsulation Header Format
   SNTP describes its Seconds field formats with bit 0 on the left as the
   MSB.

   I assume FCencap wants to use bit 31 on the left as the MSB. How can
   this be made clearer?

   Rejected

   MSB is always on the left and the bit numbering will be changed to
   match SNTP as per comment 77.

Comment 64

   3.1 FC Encapsulation Header Format
   "...CRC for words 0 to 5 of the FC Encapsulation Header computed using
   the polynomial, initial value, and bit order defined for Fibre Channel
   in FC- FS..." s/b "...CRC for words 0 to 5 of the FC Encapsulation
   Header computed using the equations, polynomial, initial value, and
   bit order defined for Fibre Channel in FC-FS..."

   As indicated by iSCSI CRC discussion, the FC "initial value" assumes a
   certain implementation. I think if you add the word "equations" it
   implies that the FC annex be followed more completely.

   Accepted

Comment 65

   3.2 FC Encapsulation Header Validation
   I would include a hyphen in both Redundancy-based and CRC-based (since
   they act as modifiers to "mechanism")

   Rejected

   Editor's prerogative.

Comment 66

   3.2.2 CRC based FC Encapsulation Header validation
   Straightforward is one word

   Accepted





Ralph Weber                                                    [Page 28]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 67

   4. Measuring Fibre Channel frame transit time
   Is it worthy of a note that this field runs out of bits in 2036? SNTP
   mentions the problems of zero. Using zeros to indicate invalid at the
   FCencap level means any solution future SNTP's define will not work.

   Rejected

   The way to handle this problem is to change the Version field when
   the SNTP rollover issue is resolved.

Comment 68

   4. Measuring Fibre Channel frame transit time
   "...accordance with the applicable protocol specification;..." s/b
   "...accordance with the protocol specification;..."

   Rejected

   I see nothing gained by the removal of the work "applicable".

Comment 69

   5.2 Bit and Byte Ordering
   As mentioned before, description of ordering for the Encapsulation
   Header needs to be before the Encapsulation Header section, not buried
   in the FC frame chapter.

   Rejected

   As mentioned in comment 77 there is an enforced IETF depiction of
   byte ordering that clarifies this issue by having all IETF documents
   follow the same rules.

Comment 70

   5.3 FC SOF and EOF
   Somewhere it should be noted that FC frame content is always 32-bit
   aligned. Otherwise, FC encap would need insert pad bytes to keep EOFs
   as shown in figure 5.

   Accepted as follows:

   Add a the following sentence after this one: "The number of 8-bit
   bytes in the FC frame content is always a multiple of four."




Ralph Weber                                                    [Page 29]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 71

   5.3 FC SOF and EOF
   "...bytes," s/b "bytes;"

   Accepted

Comment 72

   5.3 FC SOF and EOF
   How were the SOF and EOF codes chosen?

   It seems like the SOF codes should be chosen to increase the Hamming
   distance between each other.   0x28 is only one bit different from
   0x29, so four bit errors could change SOFf into SOFi4 undetected.
   With only 8 values to encode in 32 bits, it seems like better Hamming
   distance could be provided.

   Rejected

   The SOF and EOF code values are defined in FC-BB. They are already
   implemented in products based on FC-BB and are not open to changes.

Comment 73

   5.3 FC SOF and EOF
   what is the rule about checking the redundant SOF, -SOF, EOF, and -EOF
   fields? Same as the FCencap rules or different?

   Rejected

   There is no rule.


















Ralph Weber                                                    [Page 30]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


Comment 74

   7. Normative References
   Is it ok to reference a draft standard in this "normative references"
   section?

   A link to a page that points to how to buy a copy of the official
   standard would be appropriate for [5] and any other completed T11
   standards.

   Accepted (Partially)

   Yes, it is okay to reference draft standards in normative
   references. This assurance was provided by a Transport Area
   Director during the Minneapolis IETF meeting.

   A clone of the ANSI web URL from a T10 or T11 standard will be add.

Comment 75

   9. Acknowledgements
   "...no long..." s/b "...no longer..."

   Accepted

Comment 76

   10. Full Copyright Statement
   "2001" s/b "2002"

   Accepted



















Ralph Weber                                                    [Page 31]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002


4. Additional Changes Discovered After WG Last Call
   ================================================

Comment 77 Technical

   The draft fails to conform to the following requirement stated in
   http://www.ietf.org/ID-nits.html.

   Historically, RFCs have specified byte and bit order according
   to a US DoD rule which made byte zero be the first byte in an
   address range, and bit zero be the most significant bit in a
   word or field. For example, you will find drawings like this
   one (from RFC 791) in many RFCs: when you make drawings like
   it, you should follow the same rule. Label your bit positions,
   bit zero is the most significant bit, and place the first
   addressable byte at the upper left-hand corner.

   3.1.  Internet Header Format

     A summary of the contents of the Internet header follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version|  IHL  |Type of Service|          Total Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Identification        |Flags|      Fragment Offset    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Time to Live |    Protocol   |         Header Checksum       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Destination Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Options                    |    Padding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Accepted with the following results

   1) Add the following paragraph immediately following the Table Of
      Contents: "Warning to Readers Familiar With Fibre Channel: Both
      Fibre Channel and IETF standards use the same byte transmission
      order. However, the bit and byte numbering is different. See
      Appendix A for guidance."
   2) Change figures 2, 3, and 5 to conform to the IETF bit and byte
      numbering;
   3) Remove bit and byte numbers wherever they appear in the text; and
   4) Insert Appendix A with the following text:


Ralph Weber                                                    [Page 32]


Internet-Draft      FC Frame Encapsulation WG Last Call      March, 2002



   "Appendix A - Fibre Channel Bit and Byte Numbering Guidance

      "Both Fibre Channel and IETF standards use the same byte
      transmission order. However, the bit and byte numbering is
      different.

      "Fibre Channel bit and byte numbering can be observed if the
      data structure heading shown in figure 6, is cut and pasted
      at the top of figure 2 and figure 5.

     W|------------------------------Bit------------------------------|
     o|                                                               |
     r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1                    |
     d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0|

        Fig. 6 - Fibre Channel Data Structure Bit and Byte Numbering

      "Fibre Channel bit numbering for the Flags field can be observed
      if the data structure heading shown in figure 7, is cut and
      pasted at the top of figure 3.

        |------------------------Bit--------------------------|
        |                                                     |
        |   31       30       29       28       27       26   |

        Fig. 7 - Fibre Channel Flags Bit Numbering"























Ralph Weber                                                    [Page 33]