idnits 2.17.1 draft-ietf-ips-fcencap-wglc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1 Scope' ) ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 48 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([5], [Seconds]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 149: '...lation receivers SHOULD either validat...' RFC 2119 keyword, line 154: '...lation receivers SHOULD either validat...' RFC 2119 keyword, line 189: '...e FC Encapsulation and SHALL be set to...' RFC 2119 keyword, line 190: '...ploying this encapsulation MAY require...' RFC 2119 keyword, line 196: '...is encapsulation SHOULD ignore the Res...' (25 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'E' on line 695 looks like a reference -- Missing reference section? '8' on line 119 looks like a reference -- Missing reference section? 'T' on line 763 looks like a reference -- Missing reference section? '9' on line 324 looks like a reference -- Missing reference section? '3' on line 593 looks like a reference -- Missing reference section? '6' on line 634 looks like a reference -- Missing reference section? '7' on line 635 looks like a reference -- Missing reference section? '5' on line 1267 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPS Working Group R. Weber 3 INTERNET-DRAFT 4 5 (Expires September, 2002) 7 FC Frame Encapsulation WG Last Call 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as Reference 21 material or to cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/lid-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Abstract 31 This ips (IP Storage) working group draft contains all the working 32 group last call comments received regarding: 34 draft-ietf-ips-fcencapsulation-06.txt 36 The proposed disposition of each comment also is recorded in this 37 draft. 39 Summary of Comments 41 Technical: 17 Comments, resulting in about 12 Changes 42 Editorial: 60 Comments, resulting in about 41 Changes 43 ------------------------------------------------------- 44 Totals: 77 Comments, resulting in about 53 Changes 46 Table Of Contents 48 1. Comments from David Black . . . . . . . . . . . . . . . . . . . 2 49 2. Comments from Mallikarjun Chadalapaka . . . . . . . . . . . . . 19 50 3. Comments from Rob Elliott . . . . . . . . . . . . . . . . . . . 23 51 4. Additional Changes Discovered After WG Last Call . . . . . . . 32 53 1. Comments from David Black 54 ========================= 56 Comment 1 58 -- Section 1 - Scope 60 The organization responsible for the Fibre Channel standards (NCITS 61 Technical Committee T11) has determined that some functions and 62 modes of operation are not interoperable to the degree required by 63 the IETF. This draft includes applicable T11 interoperability 64 determinations in the form of restrictions on the use of this 65 encapsulation mechanism. 67 [E] Is there an official citation for this statement? It really needs 68 one to be published in an archival unchangeable format such as an RFC. 70 Accepted resulting in the following changes 72 Add reference to FC-MI. Change "NCITS" to "INCITS". 74 Comment 2 76 -- Section 2 - Encapsulation Concepts 78 FC frames have several possible lengths. 80 [E] Should read "variable length" or something like that - this 81 implies several possible choices of fixed length, which is incorrect. 83 Accepted as follows 85 Replace the sentence with: "FC frames are variable length." 87 Comment 3 89 -- Section 2 - Encapsulation Concepts 91 To facilitate transporting FC frames over TCP the native FC frame 92 needs to be contained in (encapsulated in) a slightly larger 93 structure as shown in figure 1. 95 [E] The use of TCP in this context is overly restrictive. This 96 encapsulation is in principle applicable to any means of transport 97 over IP, including TCP, SCTP, UDP, and carrier pigeon :-), even though 98 in practice all the initial uses will use TCP. 100 Accepted as follows 102 Change "over TCP" to "over an IP based transport such as TCP". 104 Comment 4 106 -- Section 2 - Encapsulation Concepts 107 The format and content of an FC frame is described in the FC 109 [E] "is" --> "are" 111 Accepted 113 Comment 5 Technical 115 -- Section 3 - The FC Encapsulation Header 116 -- Section 3.1 - FC Encapsulation Header Format 118 The values in the Protocol# field are assigned by 119 IANA [8]. The following values are known to be in use: 121 - FCIP -- TO BE ASSIGNED by IANA 122 - iFCP -- TO BE ASSIGNED by IANA 124 [T] Delete the text starting with "The following values" and insert 125 a forward reference to the IANA Consideration section. 127 Accepted as written. 129 Comment 6 Technical 131 -- Section 3 - The FC Encapsulation Header 132 -- Section 3.1 - FC Encapsulation Header Format 134 FC Encapsulation receivers may compare the Protocol# and -Protocol# 135 fields as an additional verification that an FC Encapsulation 136 Header is being processed. 138 FC Encapsulation receivers may compare the Version and -Version 139 fields as an additional verification that an FC Encapsulation 140 Header is being processed. 142 [T] Those "may"s are misleading. I think "SHOULD" is appropriate, but 143 I could accept "SHOULD"s that only applied when the CRC is not valid. 145 Accepted as follows 147 Replace the two cited sentences with: 149 FC Encapsulation receivers SHOULD either validate the CRC or 150 compare the Protocol# and -Protocol# fields to verify that an 151 FC Encapsulation Header is being processed according to a 152 policy defined by the encapsulating protocol. 154 FC Encapsulation receivers SHOULD either validate the CRC or 155 compare the Version and -Version fields to verify that an 156 FC Encapsulation Header is being processed according to a 157 policy defined by the encapsulating protocol. 159 As per comment 8, sentences similar to those shown above will be 160 added to the -Flags and -Frame Length descriptions. 162 Comment 7 Technical 164 -- Section 3 - The FC Encapsulation Header 165 -- Section 3.1 - FC Encapsulation Header Format 167 Flags (bits 31-26 in word 3): The Flags bits provide information 168 about the usage of the FC Encapsulation Header as shown in figure 169 3. 171 Note: Implementers are advised to consult the specifications of 172 protocols that use this header to determine how each individual 173 protocol uses the bits in the Flags field. 175 [T] The "Note:" paragraph is part of the CRCV issue (see below), and 176 probably needs to be deleted as part of resolving that issue. This 177 paragraph also has the additional problem in that it implies that 178 protocol specific uses of the reserved flags are allowed, which is not 179 the case. 181 Accepted 183 Comment 8 Technical 185 -- Section 3 - The FC Encapsulation Header 186 -- Section 3.1 - FC Encapsulation Header Format 188 Reserved (Flags, bits 31-27 in word 3): These bits are reserved for 189 use by future versions of the FC Encapsulation and SHALL be set to 190 zero on send. Protocols employing this encapsulation MAY require 191 checking for zero on receive, however doing so has the potential to 192 create incompatibilities with future versions of this 193 encapsulation. 195 [E] Second sentence is poorly worded. Suggested rewrite: Protocols 196 employing this encapsulation SHOULD ignore the Reserved bits on 197 receive in order to avoid creating incompatibilities with possible 198 future versions of this encapsulation. I believe this change is 199 editorial, and it also applies to the -Flags and -Frame Length fields. 201 Rejected 203 This change is not editorial. It is technical and specifically 204 recommends against some of the validity checking described in FCIP. 205 The working group argued this issue several times and (I thought) 206 agreed that checking the version number was sufficient to know that 207 the reserved flags must be zero. 209 The last sentence of the comment is a misnomer with respect to the 210 rest of the comment, however it makes sense when applied to comment 6. 212 Comment 9 Technical 214 -- Section 3 - The FC Encapsulation Header 215 -- Section 3.1 - FC Encapsulation Header Format 217 CRCV (CRC Valid Flag, bit 26 in word 3): A CRCV bit value of one 218 indicates that the contents of the CRC field are valid. A CRCV bit 219 value of zero indicates that CRC are invalid. Some protocols may 220 always check the CRC without regard for the state of this bit. The 221 value of the CRCV bit SHALL be constant for all FC Encapsulation 222 Headers sent on a given TCP connection. 224 [T] The "Some protocols may always check the CRC ..." is the CRCV 225 issue that Mallikarjun also found and that has been problematic in the 226 past. I believe that what's going on here is that all protocols have 227 to check the Protocol#, and once that's been checked, the 228 implementation knows whether there's supposed to be a CRC there and 229 hence doesn't need to look at CRCV. In practice this won't cause 230 problems, as including the CRC when it's not supposed to be there is 231 harmless, and failing to include it when it should be there will 232 almost certainly cause a CRC check failure. 234 I offer a proposal to resolve this by expanding the Protocol# 235 registry that IANA will create so that each registered protocol 236 must supply not only its name and an RFC reference, but also whether 237 the protocol uses (Yes) or does not use (No) the CRC in this header. 238 The above text could then be revised to make the CRCV check at the 239 receiver OPTIONAL in all cases because its value can be inferred 240 from the protocol#. 242 Rejected in principle, with some changes required 244 At the Nashua interim, someone wanted a client protocol to be free 245 to use CRC or not according to operating environments (e.g., lab- 246 local vs. network attachment). The proposed definition of usage by 247 IANA based on protocol would eliminate this option. 249 It must be noted that the content of Annex A also conflicts with 250 this result from the Nashua interim. To correct that, the following 251 text from Annex A must be replaced: 253 "CRC 255 "Protocols employing this encapsulation SHALL either: 257 "1) Require a valid CRC to be sent and the CRCV Flag bit to be 258 sent as one, or 259 "2) Require the CRC field to be sent as zero and the CRCV Flag 260 bit to be sent as zero." 262 The Annex A CRC discussion (shown above) will be replaced with: 264 "Protocols employing this encapsulation SHALL define the 265 procedures and policies necessary for verifying that an 266 FC Encapsulation Header is being processed." 268 Also, make the change described in the response to comment 35. 270 Comment 10 272 -- Section 3 - The FC Encapsulation Header 273 -- Section 3.1 - FC Encapsulation Header Format 275 [E] Also need to generalize away from TCP connection to allow possible 276 future use with other transports. 278 Accepted, resulting in the following changes 280 1) In the description of CRCV: change "TCP connection" to 281 "connection"; 283 2) In Section 4: 284 - change "TCP-connected elements" to IP-connected elements"; 285 - change "traverse the TCP connection" to "traverse the 286 connection"; 287 - change "injected into a TCP connection" to "injected into 288 a connection"; and 290 3) In Section 5.3: change "transmission over TCP" to "transmission 291 over an IP Network"; 293 Comment 11 Technical 295 -- Section 3 - The FC Encapsulation Header 296 -- Section 3.1 - FC Encapsulation Header Format 298 [T] Here or in the description of the Protocol Specific fields, a 299 warning to implementers is needed says some sort of error checking 300 redundancy (e.g., the ones complements found elsewhere in the header) 301 SHOULD (or MUST) be used when the CRC is not used. This warning 302 should be duplicated in Section 3.2.1. This is a technical comment, 303 but should not be controversial. 305 Rejected 307 Specific statements of action have been added to each applicable 308 field as per comment 6. 310 Comment 12 Technical 312 -- Section 3 - The FC Encapsulation Header 313 -- Section 3.1 - FC Encapsulation Header Format 315 Time Stamp [integer] and Time Stamp [fraction] (words 4 and 5): The 316 two Time Stamp fields contain time at which the FC Encapsulated 317 frame was sent as known to the sender. The format of integer and 318 fraction Time Stamp word values is specified in Simple Network Time 319 Protocol (SNTP) Version 4 [9]. The contents of the Time Stamp 320 [integer] and Time Stamp [fraction] words SHALL be set as described 321 in section 4. 323 [E] For convenience, it might be good to summarize those formats here 324 with an indication that [9] is the normative authority. I don't feel 325 strongly about this, though. 327 [T] We have a problem here - RFC 2030 is Informational, and hence 328 can't be referenced in a normative fashion from a standards track 329 document. I'll talk to Ralph offline about how to get around this. 331 Accepted resulting in the following changes 333 1) Copy the definitions of the two time stamp words from RFC 2030 334 to this draft (estimated to be 2 paragraphs); 335 2) Copy any necessary ancillary definition text from RFC 2030 to 336 this draft (estimated to be no more than 5 paragraphs); and 337 3) Make the reference to RFC 2030 information, both in the body 338 text and in a Informative References section (which will have 339 to be added). 341 Comment 13 343 -- Section 3 - The FC Encapsulation Header 344 -- Section 3.1 - FC Encapsulation Header Format 346 CRC (word 6): When the CRCV Flag bit is zero, the CRC field SHALL 347 contain zero. When the CRCV Flag bit is one, the CRC field SHALL 348 contain a CRC for words 0 to 5 of the FC Encapsulation Header 349 computed using the polynomial, initial value, and bit order defined 350 for Fibre Channel in FC-FS [3]. Using this algorithm, the bit order 351 of the resulting CRC corresponds to that of FC-1 layer. The CRC 352 transmitted over the IP network shall correspond to the equivalent 353 value converted to FC-2 format as specified in FC-FS. 355 [E] I realize that FC-FS is the latest and greatest version of the FC 356 frame standard, BUT, referencing a project in progress for this sort 357 of basic CRC mechanism is an invitation to procedural problems. Can 358 this reference be changed to FC-PH accompanied by a note that FC-FS is 359 supplanting FC-PH, but will make *no* changes in this area? Note that 360 I'm comfortable with the earlier reference to FC-FS for frame 361 contents. 363 Accepted (Partially) 365 T11 has clearly stated that FC-PI and FC-FS are the preferred 366 documents over FC-PH. The statement takes the form of a refusal to 367 process FC-PH for international standardization, with the preferred 368 recourse being to process FC-PI and FC-FS when they are available. 370 Furthermore, referencing FC-PH really requires references to FC-PH-2 371 and FC-PH-3, since FC-PH is not a fully correct document in and of 372 itself. In other words, there is a rats nest here. 374 It is not a matter of FC-FS being the latest and greatest. T11 has 375 unambiguously stated that FC-PI and FC-FS are the only true path 376 with very clear reasons for that decision. 378 Action to be taken: 380 In the References section, the note will be added following the 381 FC-FS reference: "Note: The Fibre Channel frame structure and CRC 382 features referenced by this draft, while formally described in 383 FC-FS, are substantially unchanged from similar features described 384 in Fibre Channel Physical and Signaling Interface (FC-PH), ANSI 385 X3.290-1994, June 1, 1994." 387 Comment 14 Technical 389 -- Section 3.2.1 391 [T] The warning that the protocol-specific fields SHOULD (or MUST) be 392 protected by redundancy needs to go here. 394 Accepted. 396 Comment 15 398 -- Section 3.2.1 400 Redundancy based header validation can be built from simple logic 401 (e.g., XORs and comparisons). Header validation based on redundancy 402 also is a step wise process in that the first word is validated, 403 then the second, then the third and so on. A decision that a 404 candidate header is not valid may be reached before the complete 405 header is available. 407 [E] First sentence is superfluous and probably should be deleted as 408 it's rather hardware-oriented. 410 Accepted with the following results 412 Replace the cited paragraph with: "Header validation based on 413 redundancy is a step wise process in that the first word is 414 validated, then the second, then the third and so on. A decision 415 that a candidate header is not valid may be reached before the 416 complete header is available." 418 Comment 16 420 -- Section 3.2.2 422 CRC based header validation employs a straight forward algorithm 423 (e.g., compute the CRC for all bytes preceding the CRC word and 424 compare the results to the CRC word's contents). The number of 425 comparisons required to perform CRC validation is exactly one and 426 the method for computing the CRC is well known with proven 427 implementations. 429 [E] Last sentence is superfluous and probably should be deleted as 430 it's rather hardware-oriented. 432 Accepted with the following results 434 Replace the cited paragraph with: "Header validation based on the 435 CRC defined in section 3.1 requires computing the CRC for all bytes 436 preceding the CRC word, and comparing the results to the CRC word's 437 contents." 439 Comment 17 441 -- Section 4 - Measuring Fibre Channel frame transit time 443 To comply with FC-FS [3], an FC Fabric must specify and limit the 444 lifetime of a frame. 446 [E] Same comment as before about referencing FC-FS. Can this be 447 changed to reference FC-PH with a note that FC-FS won't change this 448 ... or is FC-FS tinkering with things here? 450 Rejected see response to comment 13. 452 Comment 18 Technical 454 -- Section 4 - Measuring Fibre Channel frame transit time 456 When originating an encapsulated frame, an entity that does not 457 support transit time calculation SHALL always set the Time Stamp 458 [integer] and Time Stamp [fraction] fields to zero. When receiving 459 an encapsulated frame, an entity that does not support transit time 460 calculation SHALL ignore the contents of the Time Stamp words. The 461 protocol SHALL specify whether or not implementation support is 462 required. 464 [T] This is about "MUST/SHOULD/MAY implement". Need a similar 465 requirement on the protocol to specify "MUST/SHOULD/MAY use" and under 466 what conditions. 468 Accepted with the following results 470 Add the following sentence: "The protocol SHALL specify those 471 conditions under which a received encapsulated frame MUST have 472 its transit time checked before forwarding." 474 Comment 19 Technical 476 -- Section 4 - Measuring Fibre Channel frame transit time 478 The policy for processing frames while in the Unsynchronized state 479 SHALL be defined by the protocol specification, including whether 480 or not the entity may continue to send and receive frames from the 481 IP network. 483 [T] On the receive side, this condition appears to be specified in the 484 wrong direction. Receiving frames from the IP network cannot possibly 485 cause problems, the issues are in forwarding (stale) frames into FC. 487 Accepted resulting in the following changes 489 1) Change "processing" to "forwarding"; and 490 2) Remove "including whether ..." to the end of the sentence. 492 Comment 20 494 -- Section 4 - Measuring Fibre Channel frame transit time 496 When de-encapsulating a frame, an entity in the Synchronized state 497 SHALL: 499 [E] While the sub-bullets are correct, they leave a reader unfamiliar 500 with FC somewhat high and dry. I would include a "for example" in 501 both a) and b), along the lines of: 503 a) For example, if a calculated transit time exceeds a value 504 that could cause the frame to violate FC maximum time in 505 transit limits (Time Out Values), the protocol may specify 506 that the frame is to be discarded. 507 b) For example, a protocol may specify that frames for which 508 transit time cannot be determined are never to be forwarded 509 over FC. 511 Accepted with changes 513 Everything except he phrase "(Time Out Values)" will be incorporated 514 as written. 516 Comment 21 518 -- Section 4 - Measuring Fibre Channel frame transit time 520 [T] At the end of this section, it would be good to warn protocol 521 designers that well-designed protocols are unlikely to accomplish 522 useful communication when the communicating entities are in different 523 states, and hence protocol designers need to consider how to 524 coordinate state transitions, especially the Unsynchronized to 525 Synchronized transition on startup and an unexpected Synchronized to 526 Unsynchronized transition (e.g., caused by loss of contact with an 527 external time service). This is related to some issues that 528 Mallikarjun found. 530 Accepted but only in principle 532 The problem is not coordinating states between the two entities. The 533 problem is keeping both entities in the Synchronized state as much 534 of the time as possible. 536 Little, if anything, is accomplished by adding protocol overhead to 537 coordinate state transitions. 539 This is not to say that the comment lacks merit. 541 Action to be taken: 543 Add the following note at the end of the section: "Note: For most 544 purposes, communication between entities is possible only while in 545 the Synchronized state." 547 Comment 22 549 -- Section 5 - The FC frame 550 -- Section 5.1 - FC frame content 552 As shown in figure 4, the FC frame content is defined as the data 553 between the EOF and SOF delimiters (including the FC CRC) after 554 conversion from FC-1 to FC-2 format as specified by FC-FS [3]. 556 [E] This needs some more explanation. The important things that need 557 to be said are: 558 - FC uses the same 8b/10b encoding as Gigabit Ethernet in 559 which each 8 bit byte is transmitted using 10 bits on the 560 wire for reasons that include redundancy and low level 561 timing synchronization between sender and receiver. 562 - All discussion of FC frame content in this draft is at the 563 8b level prior to 8b->10b expansion on send or after 10b->8b 564 reduction on receive. 566 The Gigabit Ethernet reference is particularly important in increasing 567 accessibility of this document to a network-savvy, but new to FC 568 audience. 570 Accepted but only in principle 572 The 8b/10b statement is no more accurate for Fibre Channel than 573 it is for Ethernet. Ten Gigabit Fibre Channel will use 64b/66b 574 encoding, the same as ten Gigabit Ethernet. Such a statement must 575 be worded as an example. 577 Action to be taken: 579 Add the following paragraph at the end of the section: "In the 580 conversion to the FC-0 physical transport, an encoding is applied to 581 the FC frame content (e.g., 8b/10b encoding like that used in Gigbit 582 Ethernet) for reasons that include redundancy and low level timing 583 synchronization between sender and receiver. All discussion of FC 584 frame content in this document is at the 8-bit byte level, prior to 585 the application of any such encoding." 587 Comment 23 589 -- Section 5.3 - FC SOF and EOF 591 The FC frame content is composed of 8-bit bytes that can be 592 translated directly for transmission over TCP. The FC SOF and EOF 593 [3] require 8b/10b special characters that cannot be translated 594 directly to 8-bit bytes, encoded values are required. 596 [E] I think this paragraph needs to be moved to Section 5.1, and 597 replaced with a sentence here that refers back to it. One important 598 editorial change is "8b/10b special characters that cannot be 599 translated directly to 8-bit bytes" should be changed to "10b special 600 characters that have no 8b equivalents" or something like that. 602 Accepted 604 Comment 24 Technical 606 -- Section 5.3 - FC SOF and EOF 608 SOF (bits 31-24 and bits 23-16 in word 0): The SOF fields contain 609 the encoded SOF value selected from table 1. 611 [T] As we've learned from the Class 4 adventure, this table is subject 612 to change/extension. IANA will need to manage it, and will need some 613 sort of allocation guidelines to remain consistent with whatever 614 mechanism produced this peculiar set of values. While we probably 615 don't want to allow value recycling, we may want to write some text 616 dealing with retiring values (making them no longer usable). This 617 also applies to the EOF values in Table 2. 619 Rejected 621 The SOF/EOF codes are stable and have not changed for at least three 622 years. They have been implemented in numerous products for tunneling 623 FC over ATM and SONET. The only instability is the editor's lack of 624 understanding about which SOF/EOF codes are required for FC Class 4 625 operation. 627 The codes are assigned by T11 and involving IANA in there assignment 628 would constitute a conflict of jurisdictions. 630 Comment 25 632 -- Section 5.3 - FC SOF and EOF 634 Note: FC-BB-2 [6] lists SOF and EOF codes not shown in table 1 and 635 table 2 (e.g., SOFi1 and SOFn1). However, FC-MI [7] identifies 636 these codes as not interoperable, so they are not listed in this 637 specification. 639 [T] There are a couple of problems here. If FC-BB-2 has assigned 640 values to SOF and EOF encodings that MUST NOT be used with FCIP, then 641 we need to instruct IANA to reserve and not allocate those values. As 642 part of allocating future values in this table, we need to (1) 643 instruct the author(s) of the draft/RFC doing the allocation to ensure 644 that T11.3 review of the proposed allocation is obtained (2) that the 645 IPS WG chair(s) (if the IPS WG still exists) and the Transport ADs are 646 informed of this review, and (3) that IANA allocates the values 647 approved by T11.3 as opposed to choosing values. Since Murali's been 648 appointed as T11's official liaison to IETF, I think it's his 649 responsibility to suggest a coordination process. 651 Accepted only because a platform is needed for an editorial change 653 As per the response to comment 25, IANA must not be involved in 654 assigning SOF/EOF codes. 656 Actions to be taken 658 The SOF and EOF tables will be modified to add a column for "Class" 659 and each SOF or EOF value will have one of the following entered in 660 the new column: "2", "3", "2 & 3", "2, 3 & 4", or "4". 662 The new column will allow FCIP and iFCP to reference Class 2, 663 Class 3, and Class 4 SOF/EOF values in their statements of what 664 the protocol supports. 666 Comment 26 668 -- Section 7 - Normative References 670 I would really like to remove the normative reference to FC-FS, 671 substituting FC-PH with a note that FC-FS will replace FC-PH. I don't 672 object to an FC-FS reference where it's really needed, but the 673 portions of FC-FS that this draft relies on are sufficiently basic and 674 stable that an FC-PH reference will make their stability clear. The 675 FC-BB-2 and FC-MI references for SOF and EOF codes need to become non- 676 normative as part of setting up the IANA registry and management 677 process. The FC-SW-2 reference may not need to be normative here. 679 Rejected see response to comment 13. 681 Comment 27 683 -- Section 7 - Normative References 685 RFC 1700 is almost certainly the wrong reference to instruct IANA on 686 what procedures to follow. See RFC 2434 for guidance on this topic, 687 although it may not be necessary to reference it. 689 Accepted 691 Comment 28 693 -- ANNEX A - Protocol Requirements 695 [E] I think this should be an Appendix, rather than an Annex. Some 696 changes may be in order here based on the above comments. 698 Accepted resulting in the following changes 700 1) Change "Annex A" to "Appendix A" and "Annex B" to "Appendix B", 701 while remembering to correct the Table of Contents too; 702 2) Add discussion of IANA assignment of CRC usage, per the 703 resolution of comment 9; and 704 3) In item d) change "processing" to "forwarding". 706 Comment 29 708 -- ANNEX B - IANA Considerations 710 [T] This needs to be made somewhat more explicit and direct. IANA is 711 looking for simple straightforward instructions roughly of the form 712 "IANA is instructed to do ". in particular, the following sentence 713 is a problem: 715 Standards action on this RFC should be accompanied by IANA 716 assignment of the following two Protocol# values: 718 It should read something like: 720 In addition to creating the FC Encapsulation Protocol Number 721 Registry, the standards action of this RFC allocates the following 722 two values from this registry: 724 While one normally asks IANA to allocate values, the exception is that 725 when creating a registry, one can instruct IANA as to what the initial 726 contents are (i.e., a new registry does not have to be created empty). 728 Accepted 730 Comment 30 732 -- ANNEX B - IANA Considerations 734 [T] Also, earlier comments suggest that the Protocol# registry needs 735 to be expanded with a CRC field (Yes/No) and that registries need to 736 be created for the SOF and EOF values. 738 Rejected See comment 9 and comment 24. 740 Comment 31 742 -- ANNEX B - IANA Considerations 744 It is requested that the ips working group chairs or the Transport 745 Services area directors be notified when any new Protocol# value 746 assignment is requested. 748 [T] Given that an approved RFC is required, this sentence seems 749 redundant. If the intent was notification of the IPS WG chairs and/or 750 ADs when a an I-D draft is submitted that will cause a Protocol# 751 assignment if/when approved as an RFC, the language needs to say that 752 and should be rephrased to require notification of the IP Storage WG 753 chairs (don't use WG acronyms here) and notification of the Transport 754 ADs instead in the case that the IPS WG does not exist or is not 755 active. 757 Accepted, delete the sentence 759 Comment 32 761 -- ANNEX B - IANA Considerations 763 [T] Also see previous comments about needing to set up an IANA 764 registry for SOF and EOF values. I'll work with Ralph on crafting the 765 right IANA instructions. 767 Rejected see comment 24. 769 2. Comments from Mallikarjun Chadalapaka 770 ===================================== 772 Comment 33 Technical 774 - Section 3.1, page 4. For the Protocol# values for FCIP and iFCP, 775 the Annex B should instead be referred. 777 Accepted see comment 5. 779 Comment 34 Technical 781 - Section 3.1, pages 4 & 5. I notice that all the ones complement 782 fields (-Protocol#, -Version etc.) are described as "contains the 783 ones complement" as opposed to "SHALL contain ones complement", 784 whereas the corresponding non-1's complement fields have the SHALL 785 wording. Any reasons for this distinction? 787 Accepted 789 Change -xxx descriptions to use SHALL. 791 Comment 35 Technical 793 - Section 3.1, page 5, CRCV bit description. 794 "Some protocols may always check the CRC without regard for 795 the state of this bit." 796 I am troubled by the literal implication of this sentence. Why 797 would that be so? 798 Would the encapsulating protocol not mandate CRCV to be set to 799 valid always instead? It seems like the purpose of defining a 800 common encapsulation format and associated semantics is watered 801 down for no stated reason... 803 Accepted 805 Delete the cited sentence. 807 The following response is provided in response to the question asked 808 in the last paragraph of the comment. FCIP mandates that CRCV be 809 zero. iFCP mandates that CRCV be one. 811 Comment 36 813 - Section 3.2.1, page 7. S/b "step wise" w/ "stepwise". 815 Accepted 817 Comment 37 819 - Section 4, page 7. 820 "The protocol SHALL specify whether or not implementation 821 support is required." 822 A general comment on usage of the term "protocol" here and in other 823 areas - I would recommend using "encapsulating protocol" instead to 824 make it easier (or perhaps use "Protocol" may be...) for the reader 825 to follow the usage. 827 Accepted, use "encapsulating protocol" 829 Comment 38 831 - Section 4, page 8. Since there is no mention of a notification 832 frame to announce an entity's transition into/out of the 833 Synchronized state, I assume it's possible and even anticipated that 834 there may be times when one of the two entities may be in 835 Unsynchronized state even while the operational encapsulating 836 protocol requires Synchronized operation. The expectation is that 837 the state rules (and encapsulating protocol-specified rules) should 838 cause this type of start-up/transient scenario to be correctly 839 sorted out. Is that right? 841 Inquiry 843 Yes it is anticipated that one entity may be in the Unsynchronized 844 state and thus discarding some FC frames. Presumably, the entity 845 will return to the Synchronized state quickly or close the connection. 847 It is not clear that any requirements need to be state for 848 interoperability. It is definitely undesirable to add protocol 849 overhead to coordinate the synch/unsynch state without there being 850 a well demonstrated need. 852 Comment 39 Technical 854 - I think it might be useful to add a statement in this section along 855 the lines of - If the encapsulating protocol mandates Synchronized 856 operation, the entity MUST NOT accept TCP connections on the well- 857 known port(s) unless the entity is in the Synchronized state. 859 Rejected 861 Since encapsulating protocols are allowed to specify operation in 862 the Unsynchronized state, specifying this level of detail about how 863 Synchronized operation is handled over reaches the bounds of this 864 specification. 866 Comment 40 Technical 868 - Section 4, page 9, Synchronized state rules. I think this should 869 also address what is to be done in case there's a case of "bad 870 synchronization" when Time Stamp words are valid. For ex., when the 871 received value is smaller than the received entity's timebase, I 872 assume it would result in arriving at a huge transit time. While 873 the huge transit time may cause the frame to be discarded, it isn't 874 clear to me what may cause the TCP connection drop and a re-synch. 876 Accepted with the following results 878 Change the recommended transit time evaluation to use the absolute 879 value of the time difference. 881 Comment 41 883 - Section 4, page9, Synchronized state rules. 884 "If both Time Stamp words have a value of zero, the receiving 885 entity SHALL process the de-encapsulated frame without computing 886 the transit time. The disposition of the frame and any other 887 actions by the recipient SHALL be defined by the protocol 888 specification." 890 I am rather perplexed by the usage of the words here. While saying 891 that the frame shall be "processed", this also seems to leave it up 892 to the encapsulating protocol to define if it needs to be processed 893 (as reaffirmed by rule (e) in Annex A). One change that makes it 894 clear to me is: 895 S/b "SHALL process the de-encapsulated frame" 896 w/ "SHALL de-encapsulate the frame". 898 Accepted 900 Comment 42 902 - Section 7 903 It may be useful to add informative references to FCIP and iFCP. 905 Rejected 907 Adding such references seems ill advised for the following reasons: 909 1) Their presence will delay publication of this draft until both 910 FCIP and iFCP have cleared the last call process; and 911 2) Such references will be less than informative in the specific 912 event that this document was commissioned to serve, the case 913 where a third FC encapsulation protocol is defined, after which 914 this document would mislead readers into believing that only two 915 "encapsulating protocols" exist. 917 Comment 43 919 - Section 9, page 13. S/b "no long working" w/ "no longer working". 921 Accepted 923 Comment 44 925 - Annex B, page 15. It isn't clear to me from this sentence if the 926 Protocol# values (1 & 2) are temporarily assigned by this draft for 927 now. 929 "Standards action on this RFC should be accompanied by IANA 930 assignment of the following two Protocol# values:" 932 Inquiry 934 It is said that IANA will not assign the Protocol# values until 935 presented with an RFC (not an internet draft) that instructs them to 936 do so. Therefore, the current Protocol# values are requests to IANA 937 (or perhaps instructions to IANA). 939 3. Comments from Rob Elliott 940 ========================= 942 Comment 45 944 Title page 945 I assume change bars will be gone from the final version. 947 Inquiry 949 The change bars appear only in the PDF file. The normative document 950 in IETF terms is the TXT file, where there are no change bars. 952 Comment 46 954 Abstract 955 "common encapsulation" s/b "common Fibre Channel encapsulation" 957 Accepted 959 Comment 47 961 1 Scope 962 "NCITS" s/b "INCITS" 964 Accepted 966 Comment 48 968 All section headers 969 Should each word in a section header be capitalized or not? This 970 document has a mix. 972 (3.2.2 doesn't capitalize validation, 4 doesn't capitalized frame 973 transmit time, etc.) 975 Accepted as follows 977 All section headers will be modified to follow the capitalization in 978 the header for section 3.1. 980 Comment 49 982 2. Encapsulation Concepts 983 "The Fibre Channel frame has a CRC that provides error detection..." 984 s/b "The Fibre Channel frame includes a Cyclic Redundancy Check (CRC) 985 code that provides error detection..." 987 Accepted 989 Comment 50 991 Figure 1 Title 992 "FC frame Encapsulation" s/b "Encapsulated FC Frame" 994 Response 996 This figure and the text describing it are concerned with how a FC 997 frame is encapsulated. Thus the figure title. The fact that the 998 result is an Encapsulated FC Frame should not be introduced in a 999 figure title. 1001 Comment 51 1003 3.1 Figure 2 1004 Where is word defined as 32 bits? 1006 Response 1008 This figure seems to define that concept clearly. It would be a 1009 shame to add a glossary to the draft simply to contain this one 1010 definition. 1012 Comment 52 1014 3.1 FC Encapsulation Header Format 1015 "Protocol (bits 31-24 in word 0):" s/b "Protocol# (bits 31-24 in word 1016 0):" 1018 Accepted 1020 Comment 53 1022 3.1 FC Encapsulation Header Format 1023 RE: "TO BE ASSIGNED by IANA" 1025 When are these protocol values filled in? 1027 Inquiry 1029 See the response to comment 44. 1031 Comment 54 1033 3.1 FC Encapsulation Header Format 1034 "The Version field SHALL contain 0x1 ..." s/b "The Version field SHALL 1035 contain 0x01 ..." since Version is an 8-bit field. 1037 Accepted 1039 Comment 55 1041 All instances of "ones complement" 1042 "ones complement" s/b "one's complement" 1044 Google reports 10,000 "one's complement" vs 3700 "ones complement" 1046 Accepted 1048 Comment 56 1050 3.1 FC Encapsulation Header Format 1051 "...i.e., the usage of this word is defined..." s/b "...i.e., the 1052 usage of these words is defined..." because there are two protocol 1053 specific words. 1055 Accepted 1057 Comment 57 1059 3.1 FC Encapsulation Header Format 1060 Regarding: "Protocols employing this encapsulation MUST NOT make use 1061 of the Reserved Flags bits in any fashion other than that described 1062 here." "here" s/b "by this encapsulation". "Here" implies that future 1063 versions are excluded. 1065 Accepted 1067 Comment 58 1069 3.1 FC Encapsulation Header Format 1070 "A CRCV bit value of zero indicates that CRC are invalid." s/b "A CRCV 1071 bit value of zero indicates that the contents of the CRC field are 1072 invalid." 1074 Accepted 1076 Comment 59 1078 3.1 FC Encapsulation Header Format 1079 Frame Length is a greater than 1 byte quantity. Which bit is the MSB? 1081 There's discussion later on page 9 inside the FC frame section, but 1082 endianness should be covered before the encapsulation header is 1083 described. 1085 Rejected 1087 Per http://www.ietf.org/ID-nits.html: 1089 "Historically, RFCs have specified byte and bit order according 1090 to a US DoD rule which made byte zero be the first byte in an 1091 address range, and bit zero be the most significant bit in a 1092 word or field. For example, you will find drawings like this 1093 one (from RFC 791) in many RFCs: when you make drawings like 1094 it, you should follow the same rule. Label your bit positions, 1095 bit zero is the most significant bit, and place the first 1096 addressable byte at the upper left-hand corner." 1098 Observance of these rules is enforced for all RFCs. Therefore, 1099 additional specifics are unnecessary. 1101 See also comment 77. 1103 Comment 60 1105 3.1 FC Encapsulation Header Format 1106 Regarding: "...the FC Encapsulation Header SHALL always be word- 1107 aligned;..." 1109 Replace "SHALL" with "is".SHALL doesn't seem right here. There's no 1110 option to not make it aligned, since the format is fixed length. We 1111 don't say the CRC field shall be one word long - it just is one word 1112 long. 1114 Accepted 1116 Comment 61 1118 3.1 FC Encapsulation Header Format 1119 "...contain time..." s/b "...contain the time..." 1121 Accepted 1123 Comment 62 1125 3.1 FC Encapsulation Header Format 1126 Should the field names in SNTP ("Seconds" and "Seconds fraction") be 1127 referenced? It's not immediately obvious which words correspond. 1129 Accepted as follows 1131 Change all occurrences of "[integer]" to "[Seconds]" and all 1132 occurrences of "[fraction]" to "[Seconds Fraction]". 1134 Comment 63 1136 3.1 FC Encapsulation Header Format 1137 SNTP describes its Seconds field formats with bit 0 on the left as the 1138 MSB. 1140 I assume FCencap wants to use bit 31 on the left as the MSB. How can 1141 this be made clearer? 1143 Rejected 1145 MSB is always on the left and the bit numbering will be changed to 1146 match SNTP as per comment 77. 1148 Comment 64 1150 3.1 FC Encapsulation Header Format 1151 "...CRC for words 0 to 5 of the FC Encapsulation Header computed using 1152 the polynomial, initial value, and bit order defined for Fibre Channel 1153 in FC- FS..." s/b "...CRC for words 0 to 5 of the FC Encapsulation 1154 Header computed using the equations, polynomial, initial value, and 1155 bit order defined for Fibre Channel in FC-FS..." 1157 As indicated by iSCSI CRC discussion, the FC "initial value" assumes a 1158 certain implementation. I think if you add the word "equations" it 1159 implies that the FC annex be followed more completely. 1161 Accepted 1163 Comment 65 1165 3.2 FC Encapsulation Header Validation 1166 I would include a hyphen in both Redundancy-based and CRC-based (since 1167 they act as modifiers to "mechanism") 1169 Rejected 1171 Editor's prerogative. 1173 Comment 66 1175 3.2.2 CRC based FC Encapsulation Header validation 1176 Straightforward is one word 1178 Accepted 1180 Comment 67 1182 4. Measuring Fibre Channel frame transit time 1183 Is it worthy of a note that this field runs out of bits in 2036? SNTP 1184 mentions the problems of zero. Using zeros to indicate invalid at the 1185 FCencap level means any solution future SNTP's define will not work. 1187 Rejected 1189 The way to handle this problem is to change the Version field when 1190 the SNTP rollover issue is resolved. 1192 Comment 68 1194 4. Measuring Fibre Channel frame transit time 1195 "...accordance with the applicable protocol specification;..." s/b 1196 "...accordance with the protocol specification;..." 1198 Rejected 1200 I see nothing gained by the removal of the work "applicable". 1202 Comment 69 1204 5.2 Bit and Byte Ordering 1205 As mentioned before, description of ordering for the Encapsulation 1206 Header needs to be before the Encapsulation Header section, not buried 1207 in the FC frame chapter. 1209 Rejected 1211 As mentioned in comment 77 there is an enforced IETF depiction of 1212 byte ordering that clarifies this issue by having all IETF documents 1213 follow the same rules. 1215 Comment 70 1217 5.3 FC SOF and EOF 1218 Somewhere it should be noted that FC frame content is always 32-bit 1219 aligned. Otherwise, FC encap would need insert pad bytes to keep EOFs 1220 as shown in figure 5. 1222 Accepted as follows: 1224 Add a the following sentence after this one: "The number of 8-bit 1225 bytes in the FC frame content is always a multiple of four." 1227 Comment 71 1229 5.3 FC SOF and EOF 1230 "...bytes," s/b "bytes;" 1232 Accepted 1234 Comment 72 1236 5.3 FC SOF and EOF 1237 How were the SOF and EOF codes chosen? 1239 It seems like the SOF codes should be chosen to increase the Hamming 1240 distance between each other. 0x28 is only one bit different from 1241 0x29, so four bit errors could change SOFf into SOFi4 undetected. 1242 With only 8 values to encode in 32 bits, it seems like better Hamming 1243 distance could be provided. 1245 Rejected 1247 The SOF and EOF code values are defined in FC-BB. They are already 1248 implemented in products based on FC-BB and are not open to changes. 1250 Comment 73 1252 5.3 FC SOF and EOF 1253 what is the rule about checking the redundant SOF, -SOF, EOF, and -EOF 1254 fields? Same as the FCencap rules or different? 1256 Rejected 1258 There is no rule. 1260 Comment 74 1262 7. Normative References 1263 Is it ok to reference a draft standard in this "normative references" 1264 section? 1266 A link to a page that points to how to buy a copy of the official 1267 standard would be appropriate for [5] and any other completed T11 1268 standards. 1270 Accepted (Partially) 1272 Yes, it is okay to reference draft standards in normative 1273 references. This assurance was provided by a Transport Area 1274 Director during the Minneapolis IETF meeting. 1276 A clone of the ANSI web URL from a T10 or T11 standard will be add. 1278 Comment 75 1280 9. Acknowledgements 1281 "...no long..." s/b "...no longer..." 1283 Accepted 1285 Comment 76 1287 10. Full Copyright Statement 1288 "2001" s/b "2002" 1290 Accepted 1292 4. Additional Changes Discovered After WG Last Call 1293 ================================================ 1295 Comment 77 Technical 1297 The draft fails to conform to the following requirement stated in 1298 http://www.ietf.org/ID-nits.html. 1300 Historically, RFCs have specified byte and bit order according 1301 to a US DoD rule which made byte zero be the first byte in an 1302 address range, and bit zero be the most significant bit in a 1303 word or field. For example, you will find drawings like this 1304 one (from RFC 791) in many RFCs: when you make drawings like 1305 it, you should follow the same rule. Label your bit positions, 1306 bit zero is the most significant bit, and place the first 1307 addressable byte at the upper left-hand corner. 1309 3.1. Internet Header Format 1311 A summary of the contents of the Internet header follows: 1313 0 1 2 3 1314 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 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 |Version| IHL |Type of Service| Total Length | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 | Identification |Flags| Fragment Offset | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | Time to Live | Protocol | Header Checksum | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | Source Address | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | Destination Address | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | Options | Padding | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 Accepted with the following results 1331 1) Add the following paragraph immediately following the Table Of 1332 Contents: "Warning to Readers Familiar With Fibre Channel: Both 1333 Fibre Channel and IETF standards use the same byte transmission 1334 order. However, the bit and byte numbering is different. See 1335 Appendix A for guidance." 1336 2) Change figures 2, 3, and 5 to conform to the IETF bit and byte 1337 numbering; 1338 3) Remove bit and byte numbers wherever they appear in the text; and 1339 4) Insert Appendix A with the following text: 1341 "Appendix A - Fibre Channel Bit and Byte Numbering Guidance 1343 "Both Fibre Channel and IETF standards use the same byte 1344 transmission order. However, the bit and byte numbering is 1345 different. 1347 "Fibre Channel bit and byte numbering can be observed if the 1348 data structure heading shown in figure 6, is cut and pasted 1349 at the top of figure 2 and figure 5. 1351 W|------------------------------Bit------------------------------| 1352 o| | 1353 r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | 1354 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| 1356 Fig. 6 - Fibre Channel Data Structure Bit and Byte Numbering 1358 "Fibre Channel bit numbering for the Flags field can be observed 1359 if the data structure heading shown in figure 7, is cut and 1360 pasted at the top of figure 3. 1362 |------------------------Bit--------------------------| 1363 | | 1364 | 31 30 29 28 27 26 | 1366 Fig. 7 - Fibre Channel Flags Bit Numbering"