home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / iscsiprj.zip / draft-ietf-ips-fcencap-wglc-01.txt < prev    next >
Text File  |  2002-06-02  |  54KB  |  1,816 lines
  1.  
  2.  
  3.  
  4.  
  5. IPS Working Group                                               R. Weber
  6. INTERNET-DRAFT
  7. <draft-ietf-ips-fcencap-wglc-01.txt>
  8. (Expires October, 2002)
  9.  
  10.  
  11.                   FC Frame Encapsulation WG Last Call
  12.  
  13. Status of this Memo
  14.  
  15.    This document is an Internet-Draft and is in full conformance with
  16.    all provisions of Section 10 of RFC 2026.
  17.  
  18.    Internet-Drafts are working documents of the Internet Engineering
  19.    Task Force (IETF), its areas, and its working groups. Note that
  20.    other groups may also distribute working documents as Internet-Drafts.
  21.  
  22.    Internet-Drafts are draft documents valid for a maximum of six
  23.    months and may be updated, replaced, or obsoleted by other documents
  24.    at any time. It is inappropriate to use Internet-Drafts as Reference
  25.    material or to cite them other than as "work in progress".
  26.  
  27.    The list of current Internet-Drafts can be accessed at 
  28.    http://www.ietf.org/ietf/lid-abstracts.txt
  29.  
  30.    The list of Internet-Draft Shadow Directories can be accessed at 
  31.    http://www.ietf.org/shadow.html
  32.  
  33.  
  34. Abstract
  35.  
  36.    This ips (IP Storage) working group draft contains all the working
  37.    group last call comments received regarding:
  38.  
  39.             draft-ietf-ips-fcencapsulation-06.txt
  40.  
  41.    The proposed disposition of each comment also is recorded in this
  42.    draft.
  43.  
  44.  
  45. Summary of Comments
  46.  
  47.    Technical:  17 Comments, resulting in about  11 Changes
  48.    Editorial:  60 Comments, resulting in about  42 Changes
  49.    -------------------------------------------------------
  50.      Totals:   77 Comments, resulting in about  53 Changes
  51.  
  52.  
  53.  
  54.  
  55. Ralph Weber                                                     [Page 1]
  56.  
  57. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  58.  
  59.  
  60. Table Of Contents
  61.  
  62.    1. Comments from David Black  . . . . . . . . . . . . . . . . . . . 2
  63.    2. Comments from Mallikarjun Chadalapaka . . . . . . . . . . . . . 19
  64.    3. Comments from Rob Elliott . . . . . . . . . . . . . . . . . . . 23
  65.    4. Additional Changes Discovered After WG Last Call  . . . . . . . 32
  66.  
  67.  
  68. 1. Comments from David Black
  69.    =========================
  70.  
  71. Comment 1 
  72.  
  73.    -- Section 1 - Scope
  74.  
  75.       The organization responsible for the Fibre Channel standards (NCITS
  76.       Technical Committee T11) has determined that some functions and
  77.       modes of operation are not interoperable to the degree required by
  78.       the IETF. This draft includes applicable T11 interoperability
  79.       determinations in the form of restrictions on the use of this
  80.       encapsulation mechanism.
  81.  
  82.    [E] Is there an official citation for this statement? It really needs
  83.    one to be published in an archival unchangeable format such as an RFC.
  84.  
  85.    Accepted resulting in the following changes
  86.  
  87.    Add reference to FC-MI. Change "NCITS" to "INCITS".
  88.  
  89. Comment 2 
  90.  
  91.    -- Section 2 - Encapsulation Concepts
  92.  
  93.            FC frames have several possible lengths.
  94.  
  95.    [E] Should read "variable length" or something like that - this
  96.    implies several possible choices of fixed length, which is incorrect.
  97.  
  98.    Accepted as follows
  99.  
  100.    Replace the sentence with: "FC frames are variable length."
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110. Ralph Weber                                                     [Page 2]
  111.  
  112. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  113.  
  114.  
  115. Comment 3 
  116.  
  117.    -- Section 2 - Encapsulation Concepts
  118.  
  119.       To facilitate transporting FC frames over TCP the native FC frame
  120.       needs to be contained in (encapsulated in) a slightly larger
  121.       structure as shown in figure 1.
  122.  
  123.    [E] The use of TCP in this context is overly restrictive. This
  124.    encapsulation is in principle applicable to any means of transport
  125.    over IP, including TCP, SCTP, UDP, and carrier pigeon :-), even though
  126.    in practice all the initial uses will use TCP.
  127.  
  128.    Accepted as follows
  129.  
  130.    Change "over TCP" to "over an IP based transport such as TCP".
  131.  
  132. Comment 4 
  133.  
  134.    -- Section 2 - Encapsulation Concepts
  135.       The format and content of an FC frame is described in the FC
  136.  
  137.    [E] "is" --> "are"
  138.  
  139.    Accepted
  140.  
  141. Comment 5 Technical
  142.  
  143.    -- Section 3 - The FC Encapsulation Header
  144.    -- Section 3.1 - FC Encapsulation Header Format
  145.  
  146.       The values in the Protocol# field are assigned by
  147.       IANA [8]. The following values are known to be in use:
  148.  
  149.        - FCIP -- TO BE ASSIGNED by IANA
  150.        - iFCP -- TO BE ASSIGNED by IANA
  151.  
  152.    [T] Delete the text starting with "The following values" and insert
  153.    a forward reference to the IANA Consideration section.
  154.  
  155.    Accepted as written.
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165. Ralph Weber                                                     [Page 3]
  166.  
  167. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  168.  
  169.  
  170. Comment 6 Technical
  171.  
  172.    -- Section 3 - The FC Encapsulation Header
  173.    -- Section 3.1 - FC Encapsulation Header Format
  174.  
  175.       FC Encapsulation receivers may compare the Protocol# and -Protocol#
  176.       fields as an additional verification that an FC Encapsulation
  177.       Header is being processed.
  178.  
  179.       FC Encapsulation receivers may compare the Version and -Version
  180.       fields as an additional verification that an FC Encapsulation
  181.       Header is being processed.
  182.  
  183.    [T] Those "may"s are misleading. I think "SHOULD" is appropriate, but
  184.    I could accept "SHOULD"s that only applied when the CRC is not valid.
  185.  
  186.    Accepted as follows
  187.  
  188.    Replace the two cited sentences with:
  189.  
  190.       FC Encapsulation receivers SHOULD either validate the CRC or
  191.       compare the Protocol# and -Protocol# fields to verify that an
  192.       FC Encapsulation Header is being processed according to a
  193.       policy defined by the encapsulating protocol.
  194.  
  195.       FC Encapsulation receivers SHOULD either validate the CRC or
  196.       compare the Version and -Version fields to verify that an
  197.       FC Encapsulation Header is being processed according to a
  198.       policy defined by the encapsulating protocol.
  199.  
  200.    As per comment 8, sentences similar to those shown above will be
  201.    added to the -Flags and -Frame Length descriptions.
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220. Ralph Weber                                                     [Page 4]
  221.  
  222. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  223.  
  224.  
  225. Comment 7 Technical
  226.  
  227.    -- Section 3 - The FC Encapsulation Header
  228.    -- Section 3.1 - FC Encapsulation Header Format
  229.  
  230.       Flags (bits 31-26 in word 3): The Flags bits provide information
  231.       about the usage of the FC Encapsulation Header as shown in figure
  232.       3.
  233.  
  234.       Note: Implementers are advised to consult the specifications of
  235.       protocols that use this header to determine how each individual
  236.       protocol uses the bits in the Flags field.
  237.  
  238.    [T] The "Note:" paragraph is part of the CRCV issue (see below), and
  239.    probably needs to be deleted as part of resolving that issue. This
  240.    paragraph also has the additional problem in that it implies that
  241.    protocol specific uses of the reserved flags are allowed, which is not
  242.    the case.
  243.  
  244.    Accepted
  245.  
  246. Comment 8 Technical
  247.  
  248.    -- Section 3 - The FC Encapsulation Header
  249.    -- Section 3.1 - FC Encapsulation Header Format
  250.  
  251.       Reserved (Flags, bits 31-27 in word 3): These bits are reserved for
  252.       use by future versions of the FC Encapsulation and SHALL be set to
  253.       zero on send. Protocols employing this encapsulation MAY require
  254.       checking for zero on receive, however doing so has the potential to
  255.       create incompatibilities with future versions of this
  256.       encapsulation.
  257.  
  258.    [E] Second sentence is poorly worded. Suggested rewrite: Protocols
  259.    employing this encapsulation SHOULD ignore the Reserved bits on
  260.    receive in order to avoid creating incompatibilities with possible
  261.    future versions of this encapsulation. I believe this change is
  262.    editorial, and it also applies to the -Flags and -Frame Length fields.
  263.  
  264.    Rejected
  265.  
  266.    This change is not editorial. It is technical and specifically
  267.    recommends against some of the validity checking described in FCIP.
  268.    The working group argued this issue several times and (I thought)
  269.    agreed that checking the version number was sufficient to know that
  270.    the reserved flags must be zero.
  271.  
  272.  
  273.  
  274.  
  275. Ralph Weber                                                     [Page 5]
  276.  
  277. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  278.  
  279.  
  280.    The last sentence of the comment is a misnomer with respect to the
  281.    rest of the comment, however it makes sense when applied to comment 6.
  282.  
  283. Comment 9 Technical
  284.  
  285.    -- Section 3 - The FC Encapsulation Header
  286.    -- Section 3.1 - FC Encapsulation Header Format
  287.  
  288.       CRCV (CRC Valid Flag, bit 26 in word 3): A CRCV bit value of one
  289.       indicates that the contents of the CRC field are valid. A CRCV bit
  290.       value of zero indicates that CRC are invalid. Some protocols may
  291.       always check the CRC without regard for the state of this bit. The
  292.       value of the CRCV bit SHALL be constant for all FC Encapsulation
  293.       Headers sent on a given TCP connection.
  294.  
  295.    [T] The "Some protocols may always check the CRC ..." is the CRCV
  296.    issue that Mallikarjun also found and that has been problematic in the
  297.    past. I believe that what's going on here is that all protocols have
  298.    to check the Protocol#, and once that's been checked, the
  299.    implementation knows whether there's supposed to be a CRC there and
  300.    hence doesn't need to look at CRCV. In practice this won't cause
  301.    problems, as including the CRC when it's not supposed to be there is
  302.    harmless, and failing to include it when it should be there will
  303.    almost certainly cause a CRC check failure.
  304.  
  305.    I offer a proposal to resolve this by expanding the Protocol#
  306.    registry that IANA will create so that each registered protocol
  307.    must supply not only its name and an RFC reference, but also whether
  308.    the protocol uses (Yes) or does not use (No) the CRC in this header.
  309.    The above text could then be revised to make the CRCV check at the
  310.    receiver OPTIONAL in all cases because its value can be inferred
  311.    from the protocol#.
  312.  
  313.    Rejected in principle, with some changes required
  314.  
  315.    At the Nashua interim, someone wanted a client protocol to be free
  316.    to use CRC or not according to operating environments (e.g., lab-
  317.    local vs. network attachment). The proposed definition of usage by
  318.    IANA based on protocol would eliminate this option.
  319.  
  320.    Actions to be taken
  321.  
  322.    It must be noted that the content of Annex A also conflicts with
  323.    this result from the Nashua interim. To correct that, the following
  324.    text from Annex A must be replaced:
  325.  
  326.       "CRC
  327.  
  328.  
  329.  
  330. Ralph Weber                                                     [Page 6]
  331.  
  332. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  333.  
  334.  
  335.       "Protocols employing this encapsulation SHALL either:
  336.  
  337.       "1) Require a valid CRC to be sent and the CRCV Flag bit to be
  338.           sent as one, or
  339.       "2) Require the CRC field to be sent as zero and the CRCV Flag
  340.           bit to be sent as zero."
  341.  
  342.    The Annex A CRC discussion (shown above) will be replaced with:
  343.  
  344.       "Protocols employing this encapsulation SHALL define the
  345.        procedures and policies necessary for verifying that an
  346.        FC Encapsulation Header is being processed."
  347.  
  348.    Also, make the change described in the response to comment 35.
  349.  
  350. Comment 10 
  351.  
  352.    -- Section 3 - The FC Encapsulation Header
  353.    -- Section 3.1 - FC Encapsulation Header Format
  354.  
  355.    [E] Also need to generalize away from TCP connection to allow possible
  356.    future use with other transports.
  357.  
  358.    Accepted, resulting in the following changes
  359.  
  360.    1) In the description of CRCV: change "TCP connection" to
  361.       "connection";
  362.  
  363.    2) In Section 4:
  364.     - change "TCP-connected elements" to IP-connected elements";
  365.     - change "traverse the TCP connection" to "traverse the
  366.       connection";
  367.     - change "injected into a TCP connection" to "injected into
  368.       a connection"; and
  369.  
  370.    3) In Section 5.3: change "transmission over TCP" to "transmission
  371.       over an IP Network";
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385. Ralph Weber                                                     [Page 7]
  386.  
  387. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  388.  
  389.  
  390. Comment 11 Technical
  391.  
  392.    -- Section 3 - The FC Encapsulation Header
  393.    -- Section 3.1 - FC Encapsulation Header Format
  394.  
  395.    [T] Here or in the description of the Protocol Specific fields, a
  396.    warning to implementers is needed says some sort of error checking
  397.    redundancy (e.g., the ones complements found elsewhere in the header)
  398.    SHOULD (or MUST) be used when the CRC is not used. This warning
  399.    should be duplicated in Section 3.2.1. This is a technical comment,
  400.    but should not be controversial.
  401.  
  402.    Rejected
  403.  
  404.    Specific statements of action have been added to each applicable
  405.    field as per comment 6.
  406.  
  407. Comment 12 Technical
  408.  
  409.    -- Section 3 - The FC Encapsulation Header
  410.    -- Section 3.1 - FC Encapsulation Header Format
  411.  
  412.       Time Stamp [integer] and Time Stamp [fraction] (words 4 and 5): The
  413.       two Time Stamp fields contain time at which the FC Encapsulated
  414.       frame was sent as known to the sender. The format of integer and
  415.       fraction Time Stamp word values is specified in Simple Network Time
  416.       Protocol (SNTP) Version 4 [9]. The contents of the Time Stamp
  417.       [integer] and Time Stamp [fraction] words SHALL be set as described
  418.       in section 4.
  419.  
  420.    [E] For convenience, it might be good to summarize those formats here
  421.    with an indication that [9] is the normative authority. I don't feel
  422.    strongly about this, though.
  423.  
  424.    [T] We have a problem here - RFC 2030 is Informational, and hence
  425.    can't be referenced in a normative fashion from a standards track
  426.    document. I'll talk to Ralph offline about how to get around this.
  427.  
  428.    Accepted resulting in the following changes
  429.  
  430.    1) Copy the definitions of the two time stamp words from RFC 2030
  431.       to this draft (estimated to be 2 paragraphs);
  432.    2) Copy any necessary ancillary definition text from RFC 2030 to
  433.       this draft (estimated to be no more than 5 paragraphs); and
  434.    3) Make the reference to RFC 2030 information, both in the body 
  435.       text and in a Informative References section (which will have
  436.       to be added).
  437.  
  438.  
  439.  
  440. Ralph Weber                                                     [Page 8]
  441.  
  442. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  443.  
  444.  
  445. Comment 13 
  446.  
  447.    -- Section 3 - The FC Encapsulation Header
  448.    -- Section 3.1 - FC Encapsulation Header Format
  449.  
  450.       CRC (word 6): When the CRCV Flag bit is zero, the CRC field SHALL
  451.       contain zero. When the CRCV Flag bit is one, the CRC field SHALL
  452.       contain a CRC for words 0 to 5 of the FC Encapsulation Header
  453.       computed using the polynomial, initial value, and bit order defined
  454.       for Fibre Channel in FC-FS [3]. Using this algorithm, the bit order
  455.       of the resulting CRC corresponds to that of FC-1 layer. The CRC
  456.       transmitted over the IP network shall correspond to the equivalent
  457.       value converted to FC-2 format as specified in FC-FS.
  458.  
  459.    [E] I realize that FC-FS is the latest and greatest version of the FC
  460.    frame standard, BUT, referencing a project in progress for this sort
  461.    of basic CRC mechanism is an invitation to procedural problems. Can
  462.    this reference be changed to FC-PH accompanied by a note that FC-FS is
  463.    supplanting FC-PH, but will make *no* changes in this area? Note that
  464.    I'm comfortable with the earlier reference to FC-FS for frame
  465.    contents.
  466.  
  467.    Accepted (Partially)
  468.  
  469.    T11 has clearly stated that FC-PI and FC-FS are the preferred
  470.    documents over FC-PH. The statement takes the form of a refusal to
  471.    process FC-PH for international standardization, with the preferred
  472.    recourse being to process FC-PI and FC-FS when they are available.
  473.  
  474.    Furthermore, referencing FC-PH really requires references to FC-PH-2
  475.    and FC-PH-3, since FC-PH is not a fully correct document in and of
  476.    itself. In other words, there is a rats nest here.
  477.  
  478.    It is not a matter of FC-FS being the latest and greatest. T11 has
  479.    unambiguously stated that FC-PI and FC-FS are the only true path
  480.    with very clear reasons for that decision.
  481.  
  482.    Action to be taken:
  483.  
  484.    In the References section, the note will be added following the
  485.    FC-FS reference: "Note: The Fibre Channel frame structure and CRC
  486.    features referenced by this draft, while formally described in
  487.    FC-FS, are substantially unchanged from similar features described
  488.    in Fibre Channel Physical and Signaling Interface (FC-PH), ANSI
  489.    X3.290-1994, June 1, 1994."
  490.  
  491.  
  492.  
  493.  
  494.  
  495. Ralph Weber                                                     [Page 9]
  496.  
  497. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  498.  
  499.  
  500. Comment 14 Technical
  501.  
  502.    -- Section 3.2.1
  503.  
  504.    [T] The warning that the protocol-specific fields SHOULD (or MUST) be
  505.    protected by redundancy needs to go here.
  506.  
  507.    Accepted.
  508.  
  509. Comment 15 
  510.  
  511.    -- Section 3.2.1
  512.  
  513.       Redundancy based header validation can be built from simple logic
  514.       (e.g., XORs and comparisons). Header validation based on redundancy
  515.       also is a step wise process in that the first word is validated,
  516.       then the second, then the third and so on. A decision that a
  517.       candidate header is not valid may be reached before the complete
  518.       header is available.
  519.  
  520.    [E] First sentence is superfluous and probably should be deleted as
  521.    it's rather hardware-oriented.
  522.  
  523.    Accepted with the following results
  524.  
  525.    Replace the cited paragraph with: "Header validation based on
  526.    redundancy is a step wise process in that the first word is
  527.    validated, then the second, then the third and so on. A decision
  528.    that a candidate header is not valid may be reached before the
  529.    complete header is available."
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550. Ralph Weber                                                    [Page 10]
  551.  
  552. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  553.  
  554.  
  555. Comment 16 
  556.  
  557.    -- Section 3.2.2
  558.  
  559.       CRC based header validation employs a straight forward algorithm
  560.       (e.g., compute the CRC for all bytes preceding the CRC word and
  561.       compare the results to the CRC word's contents). The number of
  562.       comparisons required to perform CRC validation is exactly one and
  563.       the method for computing the CRC is well known with proven
  564.       implementations.
  565.  
  566.    [E] Last sentence is superfluous and probably should be deleted as
  567.    it's rather hardware-oriented.
  568.  
  569.    Accepted with the following results
  570.  
  571.    Replace the cited paragraph with: "Header validation based on the
  572.    CRC defined in section 3.1 requires computing the CRC for all bytes
  573.    preceding the CRC word, and comparing the results to the CRC word's
  574.    contents."
  575.  
  576. Comment 17 
  577.  
  578.    -- Section 4 - Measuring Fibre Channel frame transit time
  579.  
  580.       To comply with FC-FS [3], an FC Fabric must specify and limit the
  581.       lifetime of a frame.
  582.  
  583.    [E] Same comment as before about referencing FC-FS. Can this be
  584.    changed to reference FC-PH with a note that FC-FS won't change this
  585.    ... or is FC-FS tinkering with things here?
  586.  
  587.    Rejected see response to comment 13.
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605. Ralph Weber                                                    [Page 11]
  606.  
  607. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  608.  
  609.  
  610. Comment 18 Technical
  611.  
  612.    -- Section 4 - Measuring Fibre Channel frame transit time
  613.  
  614.       When originating an encapsulated frame, an entity that does not
  615.       support transit time calculation SHALL always set the Time Stamp
  616.       [integer] and Time Stamp [fraction] fields to zero. When receiving
  617.       an encapsulated frame, an entity that does not support transit time
  618.       calculation SHALL ignore the contents of the Time Stamp words. The
  619.       protocol SHALL specify whether or not implementation support is
  620.       required.
  621.  
  622.    [T] This is about "MUST/SHOULD/MAY implement". Need a similar
  623.    requirement on the protocol to specify "MUST/SHOULD/MAY use" and under
  624.    what conditions.
  625.  
  626.    Accepted with the following results
  627.  
  628.    Add the following sentence: "The protocol SHALL specify those
  629.    conditions under which a received encapsulated frame MUST have
  630.    its transit time checked before forwarding."
  631.  
  632. Comment 19 Technical
  633.  
  634.    -- Section 4 - Measuring Fibre Channel frame transit time
  635.  
  636.       The policy for processing frames while in the Unsynchronized state
  637.       SHALL be defined by the protocol specification, including whether
  638.       or not the entity may continue to send and receive frames from the
  639.       IP network.
  640.  
  641.    [T] On the receive side, this condition appears to be specified in the
  642.    wrong direction. Receiving frames from the IP network cannot possibly
  643.    cause problems, the issues are in forwarding (stale) frames into FC.
  644.  
  645.    Accepted resulting in the following changes
  646.  
  647.    1) Change "processing" to "forwarding"; and
  648.    2) Remove "including whether ..." to the end of the sentence.
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660. Ralph Weber                                                    [Page 12]
  661.  
  662. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  663.  
  664.  
  665. Comment 20 
  666.  
  667.    -- Section 4 - Measuring Fibre Channel frame transit time
  668.  
  669.       When de-encapsulating a frame, an entity in the Synchronized state
  670.       SHALL:
  671.  
  672.    [E] While the sub-bullets are correct, they leave a reader unfamiliar
  673.    with FC somewhat high and dry. I would include a "for example" in
  674.    both a) and b), along the lines of:
  675.  
  676.            a) For example, if a calculated transit time exceeds a value
  677.               that could cause the frame to violate FC maximum time in
  678.               transit limits (Time Out Values), the protocol may specify
  679.               that the frame is to be discarded.
  680.            b) For example, a protocol may specify that frames for which
  681.               transit time cannot be determined are never to be forwarded
  682.               over FC.
  683.  
  684.    Accepted with changes
  685.  
  686.    Everything except he phrase "(Time Out Values)" will be incorporated
  687.    as written.
  688.  
  689. Comment 21 
  690.  
  691.    -- Section 4 - Measuring Fibre Channel frame transit time
  692.  
  693.    [T] At the end of this section, it would be good to warn protocol
  694.    designers that well-designed protocols are unlikely to accomplish
  695.    useful communication when the communicating entities are in different
  696.    states, and hence protocol designers need to consider how to
  697.    coordinate state transitions, especially the Unsynchronized to
  698.    Synchronized transition on startup and an unexpected Synchronized to
  699.    Unsynchronized transition (e.g., caused by loss of contact with an
  700.    external time service). This is related to some issues that
  701.    Mallikarjun found.
  702.  
  703.    Accepted but only in principle
  704.  
  705.    The problem is not coordinating states between the two entities. The
  706.    problem is keeping both entities in the Synchronized state as much
  707.    of the time as possible.
  708.  
  709.    Little, if anything, is accomplished by adding protocol overhead to
  710.    coordinate state transitions.
  711.  
  712.    This is not to say that the comment lacks merit.
  713.  
  714.  
  715. Ralph Weber                                                    [Page 13]
  716.  
  717. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  718.  
  719.  
  720.  
  721.    Action to be taken:
  722.  
  723.    Add the following note at the end of the section: "Note: For most
  724.    purposes, communication between entities is possible only while in
  725.    the Synchronized state."
  726.  
  727. Comment 22 
  728.  
  729.    -- Section 5 - The FC frame
  730.    -- Section 5.1 - FC frame content
  731.  
  732.       As shown in figure 4, the FC frame content is defined as the data
  733.       between the EOF and SOF delimiters (including the FC CRC) after
  734.       conversion from FC-1 to FC-2 format as specified by FC-FS [3].
  735.  
  736.    [E] This needs some more explanation. The important things that need
  737.    to be said are:
  738.            - FC uses the same 8b/10b encoding as Gigabit Ethernet in
  739.              which each 8 bit byte is transmitted using 10 bits on the
  740.              wire for reasons that include redundancy and low level
  741.              timing synchronization between sender and receiver.
  742.            - All discussion of FC frame content in this draft is at the
  743.              8b level prior to 8b->10b expansion on send or after 10b->8b
  744.              reduction on receive.
  745.  
  746.    The Gigabit Ethernet reference is particularly important in increasing
  747.    accessibility of this document to a network-savvy, but new to FC
  748.    audience.
  749.  
  750.    Accepted but only in principle
  751.  
  752.    The 8b/10b statement is no more accurate for Fibre Channel than
  753.    it is for Ethernet. Ten Gigabit Fibre Channel will use 64b/66b
  754.    encoding, the same as ten Gigabit Ethernet. Such a statement must
  755.    be worded as an example.
  756.  
  757.    Action to be taken:
  758.  
  759.    Add the following paragraph at the end of the section: "In the
  760.    conversion to the FC-0 physical transport, an encoding is applied to
  761.    the FC frame content (e.g., 8b/10b encoding like that used in Gigbit
  762.    Ethernet) for reasons that include redundancy and low level timing
  763.    synchronization between sender and receiver. All discussion of FC
  764.    frame content in this document is at the 8-bit byte level, prior to
  765.    the application of any such encoding."
  766.  
  767.  
  768.  
  769.  
  770. Ralph Weber                                                    [Page 14]
  771.  
  772. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  773.  
  774.  
  775. Comment 23 
  776.  
  777.    -- Section 5.3 - FC SOF and EOF
  778.  
  779.       The FC frame content is composed of 8-bit bytes that can be
  780.       translated directly for transmission over TCP. The FC SOF and EOF
  781.       [3] require 8b/10b special characters that cannot be translated
  782.       directly to 8-bit bytes, encoded values are required.
  783.  
  784.    [E] I think this paragraph needs to be moved to Section 5.1, and
  785.    replaced with a sentence here that refers back to it. One important
  786.    editorial change is "8b/10b special characters that cannot be
  787.    translated directly to 8-bit bytes" should be changed to "10b special
  788.    characters that have no 8b equivalents" or something like that.
  789.  
  790.    Accepted
  791.  
  792. Comment 24 Technical
  793.  
  794.    -- Section 5.3 - FC SOF and EOF
  795.  
  796.       SOF (bits 31-24 and bits 23-16 in word 0): The SOF fields contain
  797.       the encoded SOF value selected from table 1.
  798.  
  799.    [T] As we've learned from the Class 4 adventure, this table is subject
  800.    to change/extension. IANA will need to manage it, and will need some
  801.    sort of allocation guidelines to remain consistent with whatever
  802.    mechanism produced this peculiar set of values. While we probably
  803.    don't want to allow value recycling, we may want to write some text
  804.    dealing with retiring values (making them no longer usable). This
  805.    also applies to the EOF values in Table 2.
  806.  
  807.    Rejected
  808.  
  809.    The SOF/EOF codes are stable and have not changed for at least three
  810.    years. They have been implemented in numerous products for tunneling
  811.    FC over ATM and SONET. The only instability is the editor's lack of
  812.    understanding about which SOF/EOF codes are required for FC Class 4
  813.    operation.
  814.  
  815.    The codes are assigned by T11 and involving IANA in there assignment
  816.    would constitute a conflict of jurisdictions.
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825. Ralph Weber                                                    [Page 15]
  826.  
  827. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  828.  
  829.  
  830. Comment 25 
  831.  
  832.    -- Section 5.3 - FC SOF and EOF
  833.  
  834.       Note: FC-BB-2 [6] lists SOF and EOF codes not shown in table 1 and
  835.       table 2 (e.g., SOFi1 and SOFn1). However, FC-MI [7] identifies
  836.       these codes as not interoperable, so they are not listed in this
  837.       specification.
  838.  
  839.    [T] There are a couple of problems here. If FC-BB-2 has assigned
  840.    values to SOF and EOF encodings that MUST NOT be used with FCIP, then
  841.    we need to instruct IANA to reserve and not allocate those values. As
  842.    part of allocating future values in this table, we need to (1)
  843.    instruct the author(s) of the draft/RFC doing the allocation to ensure
  844.    that T11.3 review of the proposed allocation is obtained (2) that the
  845.    IPS WG chair(s) (if the IPS WG still exists) and the Transport ADs are
  846.    informed of this review, and (3) that IANA allocates the values
  847.    approved by T11.3 as opposed to choosing values. Since Murali's been
  848.    appointed as T11's official liaison to IETF, I think it's his
  849.    responsibility to suggest a coordination process.
  850.  
  851.    Accepted only because a platform is needed for an editorial change
  852.  
  853.    As per the response to comment 25, IANA must not be involved in
  854.    assigning SOF/EOF codes.
  855.  
  856.    Actions to be taken
  857.  
  858.    The SOF and EOF tables will be modified to add a column for "Class"
  859.    and each SOF or EOF value will have one of the following entered in
  860.    the new column: "2", "3", "2 & 3", "2, 3 & 4", or "4".
  861.  
  862.    The new column will allow FCIP and iFCP to reference Class 2,
  863.    Class 3, and Class 4 SOF/EOF values in their statements of what
  864.    the protocol supports.
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880. Ralph Weber                                                    [Page 16]
  881.  
  882. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  883.  
  884.  
  885. Comment 26 
  886.  
  887.    -- Section 7 - Normative References
  888.  
  889.    I would really like to remove the normative reference to FC-FS,
  890.    substituting FC-PH with a note that FC-FS will replace FC-PH. I don't
  891.    object to an FC-FS reference where it's really needed, but the
  892.    portions of FC-FS that this draft relies on are sufficiently basic and
  893.    stable that an FC-PH reference will make their stability clear. The
  894.    FC-BB-2 and FC-MI references for SOF and EOF codes need to become non-
  895.    normative as part of setting up the IANA registry and management
  896.    process. The FC-SW-2 reference may not need to be normative here.
  897.  
  898.    Rejected see response to comment 13.
  899.  
  900. Comment 27 
  901.  
  902.    -- Section 7 - Normative References
  903.  
  904.    RFC 1700 is almost certainly the wrong reference to instruct IANA on
  905.    what procedures to follow. See RFC 2434 for guidance on this topic,
  906.    although it may not be necessary to reference it.
  907.  
  908.    Accepted
  909.  
  910. Comment 28 
  911.  
  912.    -- ANNEX A - Protocol Requirements
  913.  
  914.    [E] I think this should be an Appendix, rather than an Annex. Some
  915.    changes may be in order here based on the above comments.
  916.  
  917.    Accepted resulting in the following changes
  918.  
  919.    1) Change "Annex A" to "Appendix A" and "Annex B" to "Appendix B",
  920.       while remembering to correct the Table of Contents too;
  921.    2) Add discussion of IANA assignment of CRC usage, per the
  922.       resolution of comment 9; and
  923.    3) In item d) change "processing" to "forwarding".
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935. Ralph Weber                                                    [Page 17]
  936.  
  937. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  938.  
  939.  
  940. Comment 29 
  941.  
  942.    -- ANNEX B - IANA Considerations
  943.  
  944.    [T] This needs to be made somewhat more explicit and direct. IANA is
  945.    looking for simple straightforward instructions roughly of the form
  946.    "IANA is instructed to do <X>". in particular, the following sentence
  947.    is a problem:
  948.  
  949.       Standards action on this RFC should be accompanied by IANA
  950.       assignment of the following two Protocol# values:
  951.  
  952.    It should read something like:
  953.  
  954.       In addition to creating the FC Encapsulation Protocol Number
  955.       Registry, the standards action of this RFC allocates the following
  956.       two values from this registry:
  957.  
  958.    While one normally asks IANA to allocate values, the exception is that
  959.    when creating a registry, one can instruct IANA as to what the initial
  960.    contents are (i.e., a new registry does not have to be created empty).
  961.  
  962.    Accepted
  963.  
  964. Comment 30 
  965.  
  966.    -- ANNEX B - IANA Considerations
  967.  
  968.    [T] Also, earlier comments suggest that the Protocol# registry needs
  969.    to be expanded with a CRC field (Yes/No) and that registries need to
  970.    be created for the SOF and EOF values.
  971.  
  972.    Rejected See comment 9 and comment 24.
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990. Ralph Weber                                                    [Page 18]
  991.  
  992. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  993.  
  994.  
  995. Comment 31 
  996.  
  997.    -- ANNEX B - IANA Considerations
  998.  
  999.       It is requested that the ips working group chairs or the Transport
  1000.       Services area directors be notified when any new Protocol# value
  1001.       assignment is requested.
  1002.  
  1003.    [T] Given that an approved RFC is required, this sentence seems
  1004.    redundant. If the intent was notification of the IPS WG chairs and/or
  1005.    ADs when a an I-D draft is submitted that will cause a Protocol#
  1006.    assignment if/when approved as an RFC, the language needs to say that
  1007.    and should be rephrased to require notification of the IP Storage WG
  1008.    chairs (don't use WG acronyms here) and notification of the Transport
  1009.    ADs instead in the case that the IPS WG does not exist or is not
  1010.    active.
  1011.  
  1012.    Accepted, delete the sentence
  1013.  
  1014. Comment 32 
  1015.  
  1016.    -- ANNEX B - IANA Considerations
  1017.  
  1018.    [T] Also see previous comments about needing to set up an IANA
  1019.    registry for SOF and EOF values. I'll work with Ralph on crafting the
  1020.    right IANA instructions.
  1021.  
  1022.    Rejected see comment 24.
  1023.  
  1024.  
  1025. 2. Comments from Mallikarjun Chadalapaka
  1026.    =====================================
  1027.  
  1028. Comment 33 Technical
  1029.  
  1030.    - Section 3.1, page 4. For the Protocol# values for FCIP and iFCP,
  1031.      the Annex B should instead be referred.
  1032.  
  1033.    Accepted see comment 5.
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045. Ralph Weber                                                    [Page 19]
  1046.  
  1047. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  1048.  
  1049.  
  1050. Comment 34 Technical
  1051.  
  1052.    - Section 3.1, pages 4 & 5. I notice that all the ones complement
  1053.      fields (-Protocol#, -Version etc.) are described as "contains the
  1054.      ones complement" as opposed to "SHALL contain ones complement",
  1055.      whereas the corresponding non-1's complement fields have the SHALL
  1056.      wording. Any reasons for this distinction?
  1057.  
  1058.    Accepted
  1059.  
  1060.    Change -xxx descriptions to use SHALL.
  1061.  
  1062. Comment 35 Technical
  1063.  
  1064.    - Section 3.1, page 5, CRCV bit description.
  1065.            "Some protocols may always check the CRC without regard for
  1066.            the state of this bit."
  1067.       I am troubled by the literal implication of this sentence. Why
  1068.       would that be so?
  1069.       Would the encapsulating protocol not mandate CRCV to be set to
  1070.       valid always instead? It seems like the purpose of defining a
  1071.       common encapsulation format and associated semantics is watered
  1072.       down for no stated reason...
  1073.  
  1074.    Accepted
  1075.  
  1076.    Delete the cited sentence.
  1077.  
  1078.    The following response is provided in response to the question asked
  1079.    in the last paragraph of the comment. FCIP mandates that CRCV be
  1080.    zero. iFCP mandates that CRCV be one.
  1081.  
  1082. Comment 36 
  1083.  
  1084.    - Section 3.2.1, page 7. S/b "step wise" w/ "stepwise".
  1085.  
  1086.    Accepted
  1087.  
  1088.  
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100. Ralph Weber                                                    [Page 20]
  1101.  
  1102. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  1103.  
  1104.  
  1105. Comment 37 
  1106.  
  1107.    - Section 4, page 7.
  1108.           "The protocol SHALL specify whether or not implementation
  1109.           support is required."
  1110.       A general comment on usage of the term "protocol" here and in other
  1111.       areas - I would recommend using "encapsulating protocol" instead to
  1112.       make it easier (or perhaps use "Protocol" may be...) for the reader
  1113.       to follow the usage.
  1114.  
  1115.    Accepted, use "encapsulating protocol"
  1116.  
  1117. Comment 38 
  1118.  
  1119.    - Section 4, page 8. Since there is no mention of a notification
  1120.      frame to announce an entity's transition into/out of the
  1121.      Synchronized state, I assume it's possible and even anticipated that
  1122.      there may be times when one of the two entities may be in
  1123.      Unsynchronized state even while the operational encapsulating
  1124.      protocol requires Synchronized operation. The expectation is that
  1125.      the state rules (and encapsulating protocol-specified rules) should
  1126.      cause this type of start-up/transient scenario to be correctly
  1127.      sorted out. Is that right?
  1128.  
  1129.    Inquiry
  1130.  
  1131.    Yes it is anticipated that one entity may be in the Unsynchronized
  1132.    state and thus discarding some FC frames. Presumably, the entity
  1133.    will return to the Synchronized state quickly or close the connection.
  1134.  
  1135.    It is not clear that any requirements need to be state for
  1136.    interoperability. It is definitely undesirable to add protocol
  1137.    overhead to coordinate the synch/unsynch state without there being
  1138.    a well demonstrated need.
  1139.  
  1140. Comment 39 Technical
  1141.  
  1142.    - I think it might be useful to add a statement in this section along
  1143.      the lines of - If the encapsulating protocol mandates Synchronized
  1144.      operation, the entity MUST NOT accept TCP connections on the well-
  1145.      known port(s) unless the entity is in the Synchronized state.
  1146.  
  1147.    Rejected
  1148.  
  1149.    Since encapsulating protocols are allowed to specify operation in
  1150.    the Unsynchronized state, specifying this level of detail about how
  1151.    Synchronized operation is handled over reaches the bounds of this
  1152.    specification.
  1153.  
  1154.  
  1155. Ralph Weber                                                    [Page 21]
  1156.  
  1157. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  1158.  
  1159.  
  1160.  
  1161. Comment 40 Technical
  1162.  
  1163.    - Section 4, page 9, Synchronized state rules. I think this should
  1164.      also address what is to be done in case there's a case of "bad
  1165.      synchronization" when Time Stamp words are valid. For ex., when the
  1166.      received value is smaller than the received entity's timebase, I
  1167.      assume it would result in arriving at a huge transit time. While
  1168.      the huge transit time may cause the frame to be discarded, it isn't
  1169.      clear to me what may cause the TCP connection drop and a re-synch.
  1170.  
  1171.    Rejected
  1172.  
  1173.    RFC 2030 leads to the belief that "bad synchronization" should be
  1174.    very low probability event. Therefore, the FC Frame Encapsulation
  1175.    draft has chosen to ignore it.
  1176.  
  1177. Comment 41 
  1178.  
  1179.    - Section 4, page9, Synchronized state rules.
  1180.       "If both Time Stamp words have a value of zero, the receiving
  1181.       entity SHALL process the de-encapsulated frame without computing
  1182.       the transit time. The disposition of the frame and any other
  1183.       actions by the recipient SHALL be defined by the protocol
  1184.       specification."
  1185.  
  1186.      I am rather perplexed by the usage of the words here. While saying
  1187.      that the frame shall be "processed", this also seems to leave it up
  1188.      to the encapsulating protocol to define if it needs to be processed
  1189.      (as reaffirmed by rule (e) in Annex A). One change that makes it
  1190.      clear to me is:
  1191.        S/b "SHALL process the de-encapsulated frame"
  1192.          w/ "SHALL de-encapsulate the frame".
  1193.  
  1194.    Accepted
  1195.  
  1196. Comment 42 
  1197.  
  1198.    - Section 7
  1199.    It may be useful to add informative references to FCIP and iFCP.
  1200.  
  1201.    Accepted with the following results
  1202.  
  1203.    Informative references will be added for FCIP and iFCP. The
  1204.    references will be to the Internet-Drafts and will include the
  1205.    words, "Work in Progress".
  1206.  
  1207.  
  1208.  
  1209.  
  1210. Ralph Weber                                                    [Page 22]
  1211.  
  1212. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  1213.  
  1214.  
  1215. Comment 43 
  1216.  
  1217.    - Section 9, page 13. S/b "no long working" w/ "no longer working".
  1218.  
  1219.    Accepted
  1220.  
  1221. Comment 44 
  1222.  
  1223.    - Annex B, page 15. It isn't clear to me from this sentence if the
  1224.       Protocol# values (1 & 2) are temporarily assigned by this draft for
  1225.       now.
  1226.  
  1227.        "Standards action on this RFC should be accompanied by IANA
  1228.         assignment of the following two Protocol# values:"
  1229.  
  1230.    Inquiry
  1231.  
  1232.    It is said that IANA will not assign the Protocol# values until
  1233.    presented with an RFC (not an internet draft) that instructs them to
  1234.    do so. Therefore, the current Protocol# values are requests to IANA
  1235.    (or perhaps instructions to IANA).
  1236.  
  1237.  
  1238. 3. Comments from Rob Elliott
  1239.    =========================
  1240.  
  1241. Comment 45 
  1242.  
  1243.    Title page
  1244.    I assume change bars will be gone from the final version.
  1245.  
  1246.    Inquiry
  1247.  
  1248.    The change bars appear only in the PDF file. The normative document
  1249.    in IETF terms is the TXT file, where there are no change bars.
  1250.  
  1251. Comment 46 
  1252.  
  1253.    Abstract
  1254.    "common encapsulation" s/b "common Fibre Channel encapsulation"
  1255.  
  1256.    Accepted
  1257.  
  1258.  
  1259.  
  1260.  
  1261.  
  1262.  
  1263.  
  1264.  
  1265. Ralph Weber                                                    [Page 23]
  1266.  
  1267. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  1268.  
  1269.  
  1270. Comment 47 
  1271.  
  1272.    1 Scope
  1273.    "NCITS" s/b "INCITS"
  1274.  
  1275.    Accepted
  1276.  
  1277. Comment 48 
  1278.  
  1279.    All section headers
  1280.    Should each word in a section header be capitalized or not? This
  1281.    document has a mix.
  1282.  
  1283.    (3.2.2 doesn't capitalize validation, 4 doesn't capitalized frame
  1284.    transmit time, etc.)
  1285.  
  1286.    Accepted as follows
  1287.  
  1288.    All section headers will be modified to follow the capitalization in
  1289.    the header for section 3.1.
  1290.  
  1291. Comment 49 
  1292.  
  1293.    2. Encapsulation Concepts
  1294.    "The Fibre Channel frame has a CRC that provides error detection..."
  1295.    s/b "The Fibre Channel frame includes a Cyclic Redundancy Check (CRC)
  1296.    code that provides error detection..."
  1297.  
  1298.    Accepted
  1299.  
  1300. Comment 50 
  1301.  
  1302.    Figure 1 Title
  1303.    "FC frame Encapsulation" s/b "Encapsulated FC Frame"
  1304.  
  1305.    Response
  1306.  
  1307.    This figure and the text describing it are concerned with how a FC
  1308.    frame is encapsulated. Thus the figure title. The fact that the
  1309.    result is an Encapsulated FC Frame should not be introduced in a
  1310.    figure title.
  1311.  
  1312.  
  1313.  
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320. Ralph Weber                                                    [Page 24]
  1321.  
  1322. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  1323.  
  1324.  
  1325. Comment 51 
  1326.  
  1327.    3.1 Figure 2
  1328.    Where is word defined as 32 bits?
  1329.  
  1330.    Response
  1331.  
  1332.    This figure seems to define that concept clearly. It would be a
  1333.    shame to add a glossary to the draft simply to contain this one
  1334.    definition.
  1335.  
  1336. Comment 52 
  1337.  
  1338.    3.1 FC Encapsulation Header Format
  1339.    "Protocol (bits 31-24 in word 0):" s/b "Protocol# (bits 31-24 in word
  1340.    0):"
  1341.  
  1342.    Accepted
  1343.  
  1344. Comment 53 
  1345.  
  1346.    3.1 FC Encapsulation Header Format
  1347.    RE: "TO BE ASSIGNED by IANA"
  1348.  
  1349.    When are these protocol values filled in?
  1350.  
  1351.    Inquiry
  1352.  
  1353.    See the response to comment 44.
  1354.  
  1355. Comment 54 
  1356.  
  1357.    3.1 FC Encapsulation Header Format
  1358.    "The Version field SHALL contain 0x1 ..." s/b "The Version field SHALL
  1359.    contain 0x01 ..." since Version is an 8-bit field.
  1360.  
  1361.    Accepted
  1362.  
  1363. Comment 55 
  1364.  
  1365.    All instances of "ones complement"
  1366.    "ones complement" s/b "one's complement"
  1367.  
  1368.    Google reports 10,000 "one's complement" vs 3700 "ones complement"
  1369.  
  1370.    Accepted
  1371.  
  1372.  
  1373.  
  1374.  
  1375. Ralph Weber                                                    [Page 25]
  1376.  
  1377. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  1378.  
  1379.  
  1380.  
  1381. Comment 56 
  1382.  
  1383.    3.1 FC Encapsulation Header Format
  1384.    "...i.e., the usage of this word is defined..." s/b "...i.e., the
  1385.    usage of these words is defined..." because there are two protocol
  1386.    specific words.
  1387.  
  1388.    Accepted
  1389.  
  1390. Comment 57 
  1391.  
  1392.    3.1 FC Encapsulation Header Format
  1393.    Regarding: "Protocols employing this encapsulation MUST NOT make use
  1394.    of the Reserved Flags bits in any fashion other than that described
  1395.    here." "here" s/b "by this encapsulation". "Here" implies that future
  1396.    versions are excluded.
  1397.  
  1398.    Accepted
  1399.  
  1400. Comment 58 
  1401.  
  1402.    3.1 FC Encapsulation Header Format
  1403.    "A CRCV bit value of zero indicates that CRC are invalid." s/b "A CRCV
  1404.    bit value of zero indicates that the contents of the CRC field are
  1405.    invalid."
  1406.  
  1407.    Accepted
  1408.  
  1409. Comment 59 
  1410.  
  1411.    3.1 FC Encapsulation Header Format
  1412.    Frame Length is a greater than 1 byte quantity. Which bit is the MSB?
  1413.  
  1414.    There's discussion later on page 9 inside the FC frame section, but
  1415.    endianness should be covered before the encapsulation header is
  1416.    described.
  1417.  
  1418.    Rejected
  1419.  
  1420.    Per http://www.ietf.org/ID-nits.html:
  1421.  
  1422.    "Historically, RFCs have specified byte and bit order according
  1423.    to a US DoD rule which made byte zero be the first byte in an
  1424.    address range, and bit zero be the most significant bit in a
  1425.    word or field. For example, you will find drawings like this
  1426.    one (from RFC 791) in many RFCs: when you make drawings like
  1427.    it, you should follow the same rule. Label your bit positions,
  1428.  
  1429.  
  1430. Ralph Weber                                                    [Page 26]
  1431.  
  1432. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  1433.  
  1434.  
  1435.    bit zero is the most significant bit, and place the first
  1436.    addressable byte at the upper left-hand corner."
  1437.  
  1438.    Observance of these rules is enforced for all RFCs. Therefore,
  1439.    additional specifics are unnecessary.
  1440.  
  1441.    See also comment 77.
  1442.  
  1443. Comment 60 
  1444.  
  1445.    3.1 FC Encapsulation Header Format
  1446.    Regarding: "...the FC Encapsulation Header SHALL always be word-
  1447.    aligned;..."
  1448.  
  1449.    Replace "SHALL" with "is".SHALL doesn't seem right here. There's no
  1450.    option to not make it aligned, since the format is fixed length. We
  1451.    don't say the CRC field shall be one word long - it just is one word
  1452.    long.
  1453.  
  1454.    Accepted
  1455.  
  1456. Comment 61 
  1457.  
  1458.    3.1 FC Encapsulation Header Format
  1459.    "...contain time..." s/b "...contain the time..."
  1460.  
  1461.    Accepted
  1462.  
  1463. Comment 62 
  1464.  
  1465.    3.1 FC Encapsulation Header Format
  1466.    Should the field names in SNTP ("Seconds" and "Seconds fraction") be
  1467.    referenced? It's not immediately obvious which words correspond.
  1468.  
  1469.    Accepted as follows
  1470.  
  1471.    Change all occurrences of "[integer]" to "[Seconds]" and all
  1472.    occurrences of "[fraction]" to "[Seconds Fraction]".
  1473.  
  1474.  
  1475.  
  1476.  
  1477.  
  1478.  
  1479.  
  1480.  
  1481.  
  1482.  
  1483.  
  1484.  
  1485. Ralph Weber                                                    [Page 27]
  1486.  
  1487. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  1488.  
  1489.  
  1490. Comment 63 
  1491.  
  1492.    3.1 FC Encapsulation Header Format
  1493.    SNTP describes its Seconds field formats with bit 0 on the left as the
  1494.    MSB.
  1495.  
  1496.    I assume FCencap wants to use bit 31 on the left as the MSB. How can
  1497.    this be made clearer?
  1498.  
  1499.    Rejected
  1500.  
  1501.    MSB is always on the left and the bit numbering will be changed to
  1502.    match SNTP as per comment 77.
  1503.  
  1504. Comment 64 
  1505.  
  1506.    3.1 FC Encapsulation Header Format
  1507.    "...CRC for words 0 to 5 of the FC Encapsulation Header computed using
  1508.    the polynomial, initial value, and bit order defined for Fibre Channel
  1509.    in FC- FS..." s/b "...CRC for words 0 to 5 of the FC Encapsulation
  1510.    Header computed using the equations, polynomial, initial value, and
  1511.    bit order defined for Fibre Channel in FC-FS..."
  1512.  
  1513.    As indicated by iSCSI CRC discussion, the FC "initial value" assumes a
  1514.    certain implementation. I think if you add the word "equations" it
  1515.    implies that the FC annex be followed more completely.
  1516.  
  1517.    Accepted
  1518.  
  1519. Comment 65 
  1520.  
  1521.    3.2 FC Encapsulation Header Validation
  1522.    I would include a hyphen in both Redundancy-based and CRC-based (since
  1523.    they act as modifiers to "mechanism")
  1524.  
  1525.    Rejected
  1526.  
  1527.    Editor's prerogative.
  1528.  
  1529. Comment 66 
  1530.  
  1531.    3.2.2 CRC based FC Encapsulation Header validation
  1532.    Straightforward is one word
  1533.  
  1534.    Accepted
  1535.  
  1536.  
  1537.  
  1538.  
  1539.  
  1540. Ralph Weber                                                    [Page 28]
  1541.  
  1542. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  1543.  
  1544.  
  1545. Comment 67 
  1546.  
  1547.    4. Measuring Fibre Channel frame transit time
  1548.    Is it worthy of a note that this field runs out of bits in 2036? SNTP
  1549.    mentions the problems of zero. Using zeros to indicate invalid at the
  1550.    FCencap level means any solution future SNTP's define will not work.
  1551.  
  1552.    Rejected
  1553.  
  1554.    The way to handle this problem is to change the Version field when
  1555.    the SNTP rollover issue is resolved.
  1556.  
  1557. Comment 68 
  1558.  
  1559.    4. Measuring Fibre Channel frame transit time
  1560.    "...accordance with the applicable protocol specification;..." s/b
  1561.    "...accordance with the protocol specification;..."
  1562.  
  1563.    Rejected
  1564.  
  1565.    I see nothing gained by the removal of the work "applicable".
  1566.  
  1567. Comment 69 
  1568.  
  1569.    5.2 Bit and Byte Ordering
  1570.    As mentioned before, description of ordering for the Encapsulation
  1571.    Header needs to be before the Encapsulation Header section, not buried
  1572.    in the FC frame chapter.
  1573.  
  1574.    Rejected
  1575.  
  1576.    As mentioned in comment 77 there is an enforced IETF depiction of
  1577.    byte ordering that clarifies this issue by having all IETF documents
  1578.    follow the same rules.
  1579.  
  1580. Comment 70 
  1581.  
  1582.    5.3 FC SOF and EOF
  1583.    Somewhere it should be noted that FC frame content is always 32-bit
  1584.    aligned. Otherwise, FC encap would need insert pad bytes to keep EOFs
  1585.    as shown in figure 5.
  1586.  
  1587.    Accepted as follows:
  1588.  
  1589.    Add a the following sentence after this one: "The number of 8-bit
  1590.    bytes in the FC frame content is always a multiple of four."
  1591.  
  1592.  
  1593.  
  1594.  
  1595. Ralph Weber                                                    [Page 29]
  1596.  
  1597. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  1598.  
  1599.  
  1600. Comment 71 
  1601.  
  1602.    5.3 FC SOF and EOF
  1603.    "...bytes," s/b "bytes;"
  1604.  
  1605.    Accepted
  1606.  
  1607. Comment 72 
  1608.  
  1609.    5.3 FC SOF and EOF
  1610.    How were the SOF and EOF codes chosen?
  1611.  
  1612.    It seems like the SOF codes should be chosen to increase the Hamming
  1613.    distance between each other.   0x28 is only one bit different from
  1614.    0x29, so four bit errors could change SOFf into SOFi4 undetected.
  1615.    With only 8 values to encode in 32 bits, it seems like better Hamming
  1616.    distance could be provided.
  1617.  
  1618.    Rejected
  1619.  
  1620.    The SOF and EOF code values are defined in FC-BB. They are already
  1621.    implemented in products based on FC-BB and are not open to changes.
  1622.  
  1623. Comment 73 
  1624.  
  1625.    5.3 FC SOF and EOF
  1626.    what is the rule about checking the redundant SOF, -SOF, EOF, and -EOF
  1627.    fields? Same as the FCencap rules or different?
  1628.  
  1629.    Rejected
  1630.  
  1631.    There is no rule.
  1632.  
  1633.  
  1634.  
  1635.  
  1636.  
  1637.  
  1638.  
  1639.  
  1640.  
  1641.  
  1642.  
  1643.  
  1644.  
  1645.  
  1646.  
  1647.  
  1648.  
  1649.  
  1650. Ralph Weber                                                    [Page 30]
  1651.  
  1652. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  1653.  
  1654.  
  1655. Comment 74 
  1656.  
  1657.    7. Normative References
  1658.    Is it ok to reference a draft standard in this "normative references"
  1659.    section?
  1660.  
  1661.    A link to a page that points to how to buy a copy of the official
  1662.    standard would be appropriate for [5] and any other completed T11
  1663.    standards.
  1664.  
  1665.    Accepted (Partially)
  1666.  
  1667.    Yes, it is okay to reference draft standards in normative
  1668.    references. This assurance was provided by a Transport Area
  1669.    Director during the Minneapolis IETF meeting.
  1670.  
  1671.    A clone of the ANSI web URL from a T10 or T11 standard will be add.
  1672.  
  1673. Comment 75 
  1674.  
  1675.    9. Acknowledgements
  1676.    "...no long..." s/b "...no longer..."
  1677.  
  1678.    Accepted
  1679.  
  1680. Comment 76 
  1681.  
  1682.    10. Full Copyright Statement
  1683.    "2001" s/b "2002"
  1684.  
  1685.    Accepted
  1686.  
  1687.  
  1688.  
  1689.  
  1690.  
  1691.  
  1692.  
  1693.  
  1694.  
  1695.  
  1696.  
  1697.  
  1698.  
  1699.  
  1700.  
  1701.  
  1702.  
  1703.  
  1704.  
  1705. Ralph Weber                                                    [Page 31]
  1706.  
  1707. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  1708.  
  1709.  
  1710. 4. Additional Changes Discovered After WG Last Call
  1711.    ================================================
  1712.  
  1713. Comment 77 Technical
  1714.  
  1715.    The draft fails to conform to the following requirement stated in
  1716.    http://www.ietf.org/ID-nits.html.
  1717.  
  1718.    Historically, RFCs have specified byte and bit order according
  1719.    to a US DoD rule which made byte zero be the first byte in an
  1720.    address range, and bit zero be the most significant bit in a
  1721.    word or field. For example, you will find drawings like this
  1722.    one (from RFC 791) in many RFCs: when you make drawings like
  1723.    it, you should follow the same rule. Label your bit positions,
  1724.    bit zero is the most significant bit, and place the first
  1725.    addressable byte at the upper left-hand corner.
  1726.  
  1727.    3.1.  Internet Header Format
  1728.  
  1729.      A summary of the contents of the Internet header follows:
  1730.  
  1731.        0                   1                   2                   3
  1732.        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
  1733.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1734.       |Version|  IHL  |Type of Service|          Total Length         |
  1735.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1736.       |         Identification        |Flags|      Fragment Offset    |
  1737.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1738.       |  Time to Live |    Protocol   |         Header Checksum       |
  1739.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1740.       |                       Source Address                          |
  1741.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1742.       |                    Destination Address                        |
  1743.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1744.       |                    Options                    |    Padding    |
  1745.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1746.  
  1747.    Accepted with the following results
  1748.  
  1749.    1) Add the following paragraph immediately following the Table Of
  1750.       Contents: "Warning to Readers Familiar With Fibre Channel: Both
  1751.       Fibre Channel and IETF standards use the same byte transmission
  1752.       order. However, the bit and byte numbering is different. See
  1753.       Appendix A for guidance."
  1754.    2) Change figures 2, 3, and 5 to conform to the IETF bit and byte
  1755.       numbering;
  1756.    3) Remove bit and byte numbers wherever they appear in the text; and
  1757.    4) Insert Appendix A with the following text:
  1758.  
  1759.  
  1760. Ralph Weber                                                    [Page 32]
  1761.  
  1762. Internet-Draft      FC Frame Encapsulation WG Last Call      April, 2002
  1763.  
  1764.  
  1765.  
  1766.    "Appendix A - Fibre Channel Bit and Byte Numbering Guidance
  1767.  
  1768.       "Both Fibre Channel and IETF standards use the same byte
  1769.       transmission order. However, the bit and byte numbering is
  1770.       different.
  1771.  
  1772.       "Fibre Channel bit and byte numbering can be observed if the
  1773.       data structure heading shown in figure 6, is cut and pasted
  1774.       at the top of figure 2 and figure 5.
  1775.  
  1776.      W|------------------------------Bit------------------------------|
  1777.      o|                                                               |
  1778.      r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1                    |
  1779.      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|
  1780.  
  1781.         Fig. 6 - Fibre Channel Data Structure Bit and Byte Numbering
  1782.  
  1783.       "Fibre Channel bit numbering for the Flags field can be observed
  1784.       if the data structure heading shown in figure 7, is cut and
  1785.       pasted at the top of figure 3.
  1786.  
  1787.         |------------------------Bit--------------------------|
  1788.         |                                                     |
  1789.         |   31       30       29       28       27       26   |
  1790.  
  1791.         Fig. 7 - Fibre Channel Flags Bit Numbering"
  1792.  
  1793.  
  1794.  
  1795.  
  1796.  
  1797.  
  1798.  
  1799.  
  1800.  
  1801.  
  1802.  
  1803.  
  1804.  
  1805.  
  1806.  
  1807.  
  1808.  
  1809.  
  1810.  
  1811.  
  1812.  
  1813.  
  1814.  
  1815. Ralph Weber                                                    [Page 33]
  1816.