idnits 2.17.1 draft-ietf-ips-ifcp-wglcc-00.txt: -(208): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(736): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(839): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(888): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1079): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1085): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1183): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1217): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1246): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1250): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1257): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1265): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1266): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1280): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1293): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1303): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1333): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1356): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1400): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1413): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1423): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1471): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2192): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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? == There are 36 instances of lines with non-ascii characters in the document. == It seems as if not all pages are separated by form feeds - found 45 form feeds but 47 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 483 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([IFCP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 555 has weird spacing: '...rt Name iFCP ...' == Line 692 has weird spacing: '...ks like formu...' -- 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.) -- The document date (May 2002) is 8009 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'E' is mentioned on line 2126, but not defined == Missing Reference: 'T' is mentioned on line 2134, but not defined == Missing Reference: 'FCP-2' is mentioned on line 125, but not defined == Missing Reference: 'ENCAP' is mentioned on line 1162, but not defined == Missing Reference: 'ISNS' is mentioned on line 1462, but not defined == Missing Reference: 'FC-SW2' is mentioned on line 1346, but not defined == Missing Reference: 'RFC1323' is mentioned on line 1364, but not defined ** Obsolete undefined reference: RFC 1323 (Obsoleted by RFC 7323) == Outdated reference: A later version (-14) exists of draft-ietf-ips-ifcp-10 Summary: 9 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPS C. Monia 3 F. Travostino 4 J. Tseng 5 Internet Draft Nishan Systems 6 Document: draft-ietf-ips-ifcp-wglcc-00.txt May 2002 7 Category: Informational 9 Responses to iFCP Rev. 10 Last Call Comments 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of [RFC2026]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Status of this Memo...................................................1 32 Abstract..............................................................3 33 Change Log............................................................3 34 1. Conventions used in this document...............................3 35 2. Comments from David Black.......................................3 36 3. Comments From Elizabeth Rodriguez..............................21 37 4. Comments from Brian Forbes.....................................25 38 5. Comments from Mallikarjun Chadalapaka..........................30 39 6. Security Considerations........................................43 40 7. References.....................................................43 41 8. Author's Addresses.............................................44 42 Full Copyright Statement.............................................44 43 Abstract 45 This document is a compilation of responses to review comments 46 received for revision 10 if the iFCP specification [IFCP] during the 47 preliminary last call period from 3/4/2002 to 3/18/2002. 49 Change Log 51 Revision 0 of draft-monia-ips-ifcplcc-00 to draft-ietf-ips-ifcp- 52 wglcc-00.txt, revision 0. 54 Comment 49 -- Modified to comply with IESG policy on number of co- 55 authors. 57 Modified the following responses per feedback from David Black and 58 Mallikarjun Chadalapaka. 60 Comment 5, 61 Comment 12, 62 Comment 94, 63 Comment 104, 64 Comment 110. 65 Comment 120 67 1. Conventions used in this document 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 71 this document are to be interpreted as described in [RFC2119]. 73 In the following, [E] designates an editorial comment, [T] a 74 technical comment. 76 The keywords 'Rejected' or 'Accepted' indicate fundamental agreement 77 or disagreement with the position stated in the comment. 79 The keyword 'Response' is used when a comment is predicated on a 80 query. The explanatory text should be consulted for details. 82 2. Comments from David Black 84 Comment 1. [E} Page 5, Change Log 86 Remove Change Log in the version after a successful WG Last 87 Call. 89 Accepted 91 Comment 2. [E] Section 2.1, page 7, paragraph 1 93 "Terms needed to clarify the concepts presented in this 94 document are presented here." 95 I don't like the usage of "clarify". How about "Terms used to 96 describe the concepts presented in this document are defined 97 here." ? 99 Accepted 101 The text will be revised as suggested. 103 Comment 3. [E] Section 2.1, Address Translation Mode Definition 105 Some tool has helpfully inserted non-ASCII characters. MS Word 106 AutoCorrect is a likely suspect. Hunt all of these down and 107 fix them, then discipline the tool severely ;-). 109 Accepted. 111 Comment 4. [T] Section 2.1, Definition of FC-4 Layer 113 "FC-4 - The fibre channel application layer. This layer is 114 functionally equivalent to the TCP/IP application layer." 116 I don't understand this. Are you equating FC-4 with OSI layer 117 7? If so, I'm not sure that is correct, and it might be better 118 to leave out this attempted analogy. 120 Accepted 122 The definition will be changed to: 124 "FC-4 - The fibre channel mapping of an upper level protocol, 125 such as [FCP-2], the fibre channel SCSI mapping." 127 a) "Arbitrated Loop -- A series of N_PORTs connected together 128 in daisy-chain fashion. Data transmission between N_PORTs 129 requires arbitration for control of the loop in a manner 130 similar to a token ring network." 132 That's not a fabric topology, unless the loop is fabric 133 attached, in which case you're in case c), Mixed Fabric. iFCP 134 can't support an FC-AL loop that isn't fabric-attached. 136 Accepted in part 138 The terminology will be changed to "fibre channel network 139 topologies". 141 In addition, the following definition will be added: 143 "Fabric -- From [FC-FS]: "The entity which interconnects 144 N_PORTs attached to it and is capable of routing frames by 145 using only the address information in the fibre channel frame." 146 With regard to FC-AL support, an iFCP gateway implementation 147 can emulate either a public (fabric attached) or private loop 148 environment. The gateway may support a private loop by 149 representing remotely attached devices as if they were resident 150 on a local loop and by emulating the semantics required to 151 support the loop control frames and primitives. Since these 152 functions are implemented internally by the gateway, iFCP 153 protocol support is not required. However, the specification 154 should explicitly prohibit the forwarding of fibre channel loop 155 control frames via iFCP. 157 A related issue is support for the set of extended link 158 services for remote loop control, such as LINIT (Loop 159 Initialize). These are standard link service messages 160 addressed to the loop fabric address (LFA) of the FL port 161 controlling the loop. A gateway that chooses to expose remote, 162 loop-connected devices as NL_Ports must also expose the LFA. 163 To do so, it should assign the local alias such that the 164 corresponding LFA or the remote loop can be derived by setting 165 the port_id component of the alias to zero in accordance with 166 [FC-FS]. 168 The specification will be modified to discuss these loop 169 topology support issues. 171 Comment 6. [T] Section 3.2, page 11, para 5 173 "Depending on the topology, the N_PORT and fabric port variants 174 through which a fibre channel device is attached to the network 175 may be one of the following: 177 "Fabric Topology Fabric Port Type N_PORT Variant 178 --------------- ---------------- -------------- 180 Loop L_PORT NL_PORT 181 Switched F_PORT N_PORT 182 Mixed FL_PORT NL_PORT 183 F_PORT N_PORT" 185 I believe the Loop line in this table does not match the other 186 lines and if so, this is one more reason to leave non-fabric- 187 attached FC-AL out of this description. 189 Accepted in part 191 Since the loop topology can be supported, it should remain in 192 the table. However, the terminology should be changed per 193 Comment 5 and the table modified as shown below: 195 "FC Network Topology N_PORT Variant FC Network Interface 196 -------------------- -------------- -------------------- 197 Loop NL_PORT L_PORT 198 Switched N_PORT F_PORT 199 Mixed NL_PORT FL_PORT via L_PORT" 201 In the case of a mixed fabric, additional supporting text will 202 be provided. 204 Comment 7. [E] Section 3.3.1, page 14, para 2 206 "All switched fabrics must provide the following services: 208 "Fabric F_PORT server � Services an N_PORT request to access 209 the fabric for communications. 211 Change "request" to "requests" 213 Accepted 215 Replace special character and reword as follows: 217 "Fabric F_PORT server -- Services N_PORT requests to access the 218 fabric for communications." 220 Comment 8. [E] Section 4.4, page 21, para 2 222 "As discussed below, an unbounded iFCP fabric may have any 223 number of switch elements and gateways." 225 It's not "any", but the limit is a very large number by 226 comparison to 239. 228 Accepted 230 The sentence will be changed to: 232 "As discussed below, an unbounded iFCP fabric is not limited to 233 239 switches and gateways." 235 Comment 9. [T] Section 4.4 - iFCP Fabric Properties 237 At some point the need to reuse 24-bit addresses for outbound 238 traffic from a single FC link behind an iFCP gateway will be a 239 problem. This comment also applies to the second paragraph in 240 Section 4.4.2. 242 Accepted 244 A discussion of address re-use issues will be added to the 245 spec. 247 Comment 10. [E] Section 4.5, page 23, para 2 248 "In the iFCP protocol, an N_PORT is represented by the 249 following addresses:" 251 Change "addresses" to "types of addresses" to avoid implying 252 that there's only one alias. Different gateways will assign 253 different aliases to the same N_PORT. 255 Rejected 257 The description of an alias will be revised as follows: 259 b) "A 24-bit N_PORT alias. The fibre channel N_PORT address 260 assigned by each gateway operating in address translation 261 mode to identify a remotely attached N_PORT. 263 Frame traffic is intercepted by an iFCP gateway and 264 directed to a remotely attached N_PORT by means of the 265 N_PORT alias. The address assigned by each gateway is 266 unique within the scope of the gateway region." 268 Comment 11. [T] Section 4.5, pp 24, para 14 270 "The mode of gateway operation is settable in an 271 implementation-specific manner. The implementation MUST NOT 272 allow the mode to be changed after the gateway begins 273 processing fibre channel frame traffic." 275 Might want to add a MUST that a gateway cannot operate in more 276 than one mode at the same time, and a repeat of the (implied) 277 requirement that all gateways in an iFCP fabric MUST operate in 278 the same mode. 280 Accepted 282 Comment 12. [T] Section 4.6. pp 24, para 2 284 b) "When interoperating with locally attached fibre channel 285 switch elements, each iFCP gateway MUST assume control of 286 DOMAIN_ID assignments in accordance with the appropriate 287 fibre channel standard or vendor-specific protocol 288 specification." 290 This is ok, but turns up another requirement that needs to be 291 explicitly stated earlier. Any given FC N_PORT MUST NOT be 292 behind more than one iFCP gateway. Address Transparent mode 293 satisfies this because only one gateway can become the 294 principal switch, so the others presumably shut down, but 295 Address Translation mode appears to have the potential for 296 seriously nasty misbehavior unless the "iFCP gateway MUST 297 become the principal switch" requirement is imposed on it also. 298 Need to add a sentence or two on how an iFCP gateway can be 299 assured of becoming the principal switch. Beyond this, the 300 fact that any Fabric Attached FC-AL loop can have only one FL 301 port completes the picture, ensuring that a loop can't stitch 302 two gateway domains together. Requiring the iFCP gateway to be 303 the principal switch also avoids problems with the gateway 304 being unable to obtain sufficient Domain IDs from the principal 305 switch. 307 Accepted in Part 309 An N_PORT can be behind more than one gateway if the following 310 rules are observed: 312 a) The gateways MUST cooperate in the assignment of N_PORT IDs 313 for locally attached devices and aliases for remotely 314 attached devices such that each local or remotely attached 315 N_PORT has one and only one N_PORT address within the scope 316 of the gateway region. 318 b) All iFCP frame traffic between any two N_PORTs MUST flow 319 through a single iFCP session. However, each session may 320 traverse a different gateway attached to the region. 322 In order to meet these constraints, a multi-gateway 323 implementation may require an out of band mechanism for 324 redirecting frame traffic from one physical gateway to another. 326 The above will be added to the specification. 328 Comment 13. [T] Section 5.2.2.2, pp 32, para 4 330 "The gateway SHALL initiate the creation of an iFCP session in 331 response to a PLOGI ELS directed to a remote N_PORT from a 332 locally attached N_PORT as described in the following steps. 334 a) "Using the D_ID field in the PLOGI frame header, locate the 335 remote N_PORT descriptor. If no descriptor exists, the iFCP 336 gateway SHALL return a response of LS_RJT, with a Reason 337 Code of 'Unable to Perform Command Request' (0x09) and a 338 Reason Code Explanation of 'Invalid N_PORT_ID' (0x1F). An 339 iFCP session SHALL NOT be created." 341 Need to explain why this is ok. 343 The answer is that a properly operating FC N_PORT will have 344 previously issued an FC nameserver query that the gateway 345 translated to an iSNS query, and hence when it issues PLOGI to 346 the result of the nameserver query, the iSNS query response 347 created the required descriptor in the gateway before being 348 translated to the FC nameserver result. There's an implication 349 here that remote N_PORT descriptors that result from iSNS 350 queries translated from FC nameserver queries MUST NOT be 351 discarded as long as any N_PORT that has issued a query for 352 that remote N_PORT is logged into the fabric. 354 Accepted in part 356 Although a name server query is almost always done in practice 357 prior to a PLOGI, an N_PORT compliant with [FC-FS] is not 358 required to do so. For that reason, the specification should 359 cover the case where a fibre channel device attempts to send 360 frames to an address without having executed a previous name 361 server query. 363 Also, while the policies for remote N_PORT descriptor retention 364 are implementation-specific, the specification should at least 365 contain recommendations. In that regard, the following added 366 text is proposed: 368 "Remote N_PORT Descriptors should be reclaimed based on a last 369 in, first out policy. 371 "An iFCP implementation should have sufficient resources to 372 insure that a newly created descriptor is not reclaimed before 373 the referencing iFCP session is created." 375 Comment 14. [E] Section 5.2.2.2 - Creating an iFCP Session 377 e) "If a CBIND response is returned with one of the following 378 statuses, the PLOGI SHALL be terminated with an LS_RJT 379 message. Depending on the CBIND failure status, the Reason 380 Code and Reason Explanation SHALL be set to the following 381 values specified in [FC-FS]." 383 Add a statement that this plus case f) is a comprehensive list 384 of possible CBIND failure statuses, as specified in Section 385 6.1. 387 Accepted 389 Comment 15. [E] Section 5.2.2.2 - Creating an iFCP Session 391 f) "A CBIND response with a CBIND STATUS of "N_PORT session 392 already exists" indicates that the remote gateway has 393 concurrently initiated a CBIND request to create an iFCP 394 session between the same pair of N_PORTs. The receiving 395 gateway SHALL terminate this attempt, return the connection 396 to the Unbound state and prepare to respond to an incoming 397 CBIND request as described below." 399 Add a sentence indicating that the "simultaneous open" race is 400 dealt with by allowing the sender with the numerically larger 401 N_PORT name to succeed in establishing the session. 403 Accepted 405 Comment 16. [E] Section 5.2.2.2, pp 34, para 2 406 "The gateway receiving a CBIND request SHALL respond as 407 follows: 409 a) "If the receiver has a duplicate iFCP session in the OPEN 410 PENDING state, then the receiving gateway SHALL compare the 411 Source N_PORT Name in the incoming CBIND payload with the 412 Destination N_PORT Name." 414 b) "If the Source N_PORT Name is greater, the receiver SHALL 415 issue a CBIND response of "Success" and SHALL place the 416 session in the OPEN state." 418 Add a sentence indicating that in case b), case c) will occur 419 at the other gateway because N_PORT names are globally unique 420 WWNs, and hence this gateway's duplicate session will receive a 421 CBIND STATUS of "N_PORT session already exists" and will be 422 terminated in due course. 424 Accepted 426 Comment 17. [T] Section 5.2.2.2 - Creating an iFCP Session 428 There's no discussion of what to do if a TCP connection closes 429 unexpectedly during this process (e.g., if closing of unbound 430 connections is allowed at arbitrary times for reasons such as 431 reducing the resources consumed by unbound connections). This 432 needs to be added even if the reason in parentheses is not 433 allowed. 435 Accepted 437 Comment 18. [T] Section 5.2.2.2, pp 35, para 4 439 "Upon receiving such a request, the gateway providing the 440 connectivity probe SHALL transmit LTEST messages at the 441 specified interval." 443 This requires liveness test (LTEST) messages even when the 444 connection is in active use. Was that intended? 446 Response 448 The intent is to require LTEST messages at the specified 449 interval regardless of whether or not there is other traffic. 451 Comment 19. [E] Section 5.2.2.4 - Use of TCP Features and 452 Settings 454 For Wrapped sequence detection, "Should use" in the table 455 should be "SHOULD use". 457 Accepted 458 Comment 20. [T] Section 5.2.3.1, pp 38, para 1 460 "In response to the Unbind message, either gateway may choose 461 to close the TCP connection or return it to a pool of unbound 462 connections." 464 This assumes that Unbind is always successful. It can fail, as 465 documented in Section 6.2. Need to specify how to deal with 466 this (e.g., close the TCP connection). 468 Accepted 470 The sentence will be modified as follows: 472 "Upon successful completion of an Unbind operation, either 473 gateway may choose to close the TCP connection or return it to 474 a pool of unbound connections." 476 The processing for the failure cases will also be specified. 478 Comment 21. [T] Section 5.2.3.1 - iFCP Session Completion 480 Can an iFCP gateway reduce the pool of unbound connections 481 (e.g., due to demands for resources for other connections), 482 possibly by closing them? If yes, need to say so. 484 Accepted 486 A gateway may close an unbound connection due to resource 487 demands. The spec will be modified appropriately. 489 Comment 22. [E] Section 5.3 - IANA Considerations 491 Put this near the end of the document where IANA can more 492 easily find it. 494 Accepted 496 Comment 23. [T] Section 5.4.1, pp 40, para 1 498 "Protocol# IANA-assigned protocol number identifying 499 the protocol using the encapsulation. For iFCP the value is 500 (/TBD/)." 502 It's 2 - cite the FC Encapsulation draft's IANA Considerations 503 section as the authority for this. 505 Accepted 507 Comment 24. [E] Section 5.4.2 - SOF and EOF Delimiter 508 Fields 509 Need to say that the format is specified in the FC Common 510 Encapsulation document and reproduced here for convenience. 512 Accepted 514 Comment 25. [T] Section 5.4.2 - SOF and EOF Delimiter 515 Fields 517 "SOF (bits 31-24 and bits 23-16 in word 0): iFCP uses the 518 following subset of the SOF fields described in [ENCAP]. 520 This is a problem because these codes are being specified in 521 more than one place. I think the FC Frame Encapsulation 522 document is the right place for the normative specification of 523 these codes (and see my comments against it on the need to get 524 IANA involved). This would be ok as a list of codes that are 525 currently valid, but the specification authority needs to be in 526 one place. Same comment applies to EOF. 528 Accepted in Part 530 The specification will be revised in accordance with Comment 531 24. 533 Comment 26. [E] Section 6, pp 46 535 "LS_COMMAND For a special link service ACC response to be 536 processed by iFCP, the LS_COMMAND field SHALL contain bits 31 537 through 24 of the LS_COMMAND to which the ACC applies. 538 Otherwise the LS_COMMAND field shall be set to zero." 540 There's an LS_COMMAND field in figure 16 and a second one in 541 the iFCP portion of the FC Common Encapsulation header (from 542 Section 5.4.1). 544 When a single section discusses both fields, as Section 6 does, 545 this gets confusing fast. Please rename the LS_COMMAND field 546 in the iFCP portion of the FC Common Encapsulation header to 547 something like ACC_LS_COMMAND or LS_COMMAND_ACC. 549 Accepted 551 The mnemonic will be changed to LS_COMMAND_ACC. 553 Comment 27. [T/E] Section 6 - TCP Session Control Messages 555 Request LS_COMMAND Short Name iFCP Support 556 ------- ---------- ---------- ----------- 558 Connection Bind 0xE0 CBIND REQUIRED 559 Unbind Connection 0xE4 UNBIND REQUIRED 560 Test Connection Liveness 0xE5 LTEST REQUIRED 562 [T/E] How do we know that those three values (E0, E4, and E5) 563 will not conflict with some future usage by Fibre Channel? I 564 think the answer is that SES=1 in the iFCP flags in the header, 565 and would be 0 in any future use of these values in an ELS, but 566 the use of those three values looks like an attempt to avoid 567 conflict and should be explained. 569 Accepted 571 That is correct. These values were chosen as patterns readily 572 distinguishable by a protocol analyzer. 574 Comment 28. [T] 6.2 - Unbind Connection (UNBIND) 576 "Unbind Status Description 577 ------------- ----------- 579 0 Successful � No other status 580 1 - 15 Reserved 581 16 Failed - Unspecified Reason 582 18 Failed - Connection ID Invalid 583 Others Reserved 585 "Unbind can fail, but earlier specification of the use of 586 Unbind (e.g., in Section 5.2.3.1) assumes that it cannot fail." 588 Description of how to deal with Failed status needs to be added 589 there (e.g., close the TCP connection). 591 Accepted 593 Comment 29. [E] Section 7.2, pp 56, para 7 595 "For translation type 3, the receiving gateway SHALL obtain the 596 information needed to fill in the field in the link service 597 frame payload by converting the specified N_PORT worldwide 598 identifier to a gateway IP address and N_PORT ID. This 599 information MUST be obtained through an iSNS name server 600 query." 602 This requires an iSNS query for every type 3 translation 603 received even if it exists locally in a Remote N_PORT 604 descriptor. It looks like this was intended due to the 605 possibility of the descriptor being stale, but I wanted to 606 check if that was in fact the intention. 608 Accepted 610 The intention was to update a potentially stale entry or force 611 the creation of a new descriptor. 613 Comment 30. [E] Section 7.2, pp 57, para 3 614 "When the ACC response requires iFCP intervention, the 615 receiving gateway MUST act as a proxy for the originator, 616 retaining the state needed to process the response from the 617 N_PORT to which the request was directed." 619 That doesn't parse for me. I think the intended meaning was 620 that when an ELS request is sent whose ACC will require iFCP 621 intervention, the ELS also requires intervention to capture the 622 state necessary to process the ACC. 624 Accepted 626 The text will be modified as follows: 628 "When the ACC response requires iFCP intervention, the 629 receiving gateway MUST intervene to process the response from 630 the N_PORT to which the request was directed." 632 Comment 31. [T] 7.3 - Fibre Channel Link Services Processed 633 by iFCP 635 "The following Extended and FC-4 Link Service Messages must 636 receive special processing." 638 Process question - how does this list get coordinated with T11 639 so that it gets updated when T11 defines a new ELS or FC-4 LS 640 that requires iFCP intervention? 642 Response 644 The specification must be revised to track the evolving fibre 645 channel specifications, including, among other things, the 646 addition of new link services that require special processing. 648 Comment 32. [T] 7.3.1.1 - Abort Exchange (ABTX) 650 "Fields Requiring Translation Supplemental Data 651 Address Translation Type (see (type 3 only) 652 ------------------- section 7.2) ------------ 653 ----------- 654 Exchange Originator 1, 2 N/A 655 S_ID" 657 Need to specify how to choose the translation type. This 658 comment also applies to RES, RES ACC, RLS, RSS, RRQ, RSI, REC 659 and REC ACC. It may be best resolved by adding additional text 660 in Section 7.2. 662 Accepted 664 Comment 33. [E] 7.3.1.3 - Discover Address Accept (ADISC 665 ACC) 666 Should the Command field be 0x20 or 0x02? 668 Response 670 The command field for all ACC response frames is 0x02. No 671 change to the specification is required. 673 Comment 34. [T] 7.3.1.3 - Discover Address Accept (ADISC 674 ACC) 676 "Other Special Processing: 678 The Hard Address of the ELS originator SHALL be set to 0." 680 Doesn't this also require setting the LS_COMMAND iFCP-specific 681 field (to be renamed) in the FC Common Encapsulation header? 682 This comment also applies to all other ACC's in Section 7. 684 Accepted 686 The specification will be modified accordingly. 688 Comment 35. Section 8.2.1 - Enforcing R_A_TOV Limits 690 The rules in this section appear to allow forwarding of all 691 frames received while in Unsynchronized mode or with a 692 timestamp of 0,0. This looks like formula for violating 693 R_A_TOV - was this intended? 695 Response 697 The intention was to abort all iFCP sessions and not allow the 698 creation of new ones. The specification will be revised 699 accordingly. 701 Comment 36. [T] Section 9.4.1 - Establishing the Broadcast 702 Configuration 704 "The broadcast configuration is managed using facilities 705 provided by the iSNS server. Specifically: 707 a) "An iSNS discovery domain is created and seeded with the 708 network address of the global broadcast server N_PORT. The 709 global server is identified as such by setting the 710 appropriate N_PORT entity attribute." 712 There are no means for recovery from failure, so loss of the 713 gateway performing the broadcast service results in loss of the 714 broadcast service. This needs to be explained at a minimum, and 715 probably corrected. 717 Accepted 718 An implementation may designate a local server as a standby 719 global broadcast server. The local server uses the LTEST 720 message to determine if the global server is functioning and 721 may assume control if not. 723 The specification will be revised accordingly. 725 Comment 37. [T] Section 10.2.2, page 82, para 1 727 "Conformant implementations of the iFCP protocol MAY use such 728 security definitions." 730 I don't understand this sentence. What was intended? 732 Accepted 734 The paragraph will be changed to: 736 �It is imperative to thwart these attacks, given that an iFCP 737 gateway is the last line of defense for a whole fibre channel 738 island, which may include several hosts and fibre channel 739 switches. To do so, the iFCP gateway must implement and may use 740 confidentiality, data origin authentication, integrity, and 741 replay protection on a per-datagram basis. The iFCP gateway 742 must implement and may use bi-directional authentication of the 743 communication endpoints. Finally, it must implement and may use 744 a scalable approach to key management.� 746 Comment 38. [T] Section 10.2.3, pp 82, para 1 748 "Enterprise data center networks are considered mission- 749 critical facilities that must be isolated and protected from 750 all possible security threats. Such networks are usually 751 protected by security gateways, which at a minimum provide a 752 shield against denial of service attacks. The iFCP security 753 architecture is capable of leveraging the protective services 754 of the existing security infrastructure, including firewall 755 protection, NAT and NAPT services, and IPSec VPN services 756 available on existing security gateways." 758 While this is true of iFCP, iSNS has some serious issues with 759 NAT and NAPT and iFCP cannot be operated without iSNS. 761 Rejected 763 iSNS issues with NA(P)Ts are thought to be resolved (see 764 Section 3.6 in the iSNS specification). iSNS has at least two 765 non-exclusive options to cope with NA(P)Ts, a) the use of FQDNs 766 instead of IP addresses, and b) the option to establish a 767 confederation of iSNS servers and have them doctor IP numbers 768 in transit as part of their mutual confederation contract. 770 Comment 39. [T] Section 10.2.4, pp 82, para 1 771 "iFCP gateways MUST use Discovery Domain information obtained 772 from the iSNS server [ISNS] to determine whether the initiating 773 fibre channel N_PORT should be allowed access to the target 774 N_PORT. N_PORT identities used in the Port Login (PLOGI) 775 process shall be considered authenticated provided the PLOGI 776 request is received from the remote gateway over a secure, 777 IPSec-protected connection." 779 Need to say something about the IKE identities (ID payloads) 780 used for the authentication, and how they correspond to 781 information obtained from iSNS - NATs/NAPTs will cause issues 782 here. Just requiring an IPsec-protected connection isn't good 783 enough as it may allow a node not registered with iSNS to get 784 in. 786 Accepted in part 788 It would be premature to enumerate ID payloads in section 789 10.2.4, which describes the scope of the overall security 790 design prior to any IKE/IPsec requirement (to follow in 791 sections 10.3). The requested information will be supplied 792 after the last paragraph in section 10.3.1. 794 Regarding intervening NA(P)Ts between iSNS clients and servers, 795 it is possible to put a proxy iSNS server at the boundary 796 between addressing domains. Such proxy will terminate the 797 IKE/IPSec so that the ID_IPV4_ADDR identity can be used 798 natively by IKE. It is also possible to use the second method 799 described in the response to comment 38 -- a confederation of 800 iSNS servers where the NAT(P)T mediation now occurs between 801 iSNS servers. 803 Admission control is performed by the iSNS server, based upon 804 the Discovery Domain (DD) configuration information stored in 805 that iSNS server. Once the authenticity of a gateway is 806 verified (e.g., via a pre-shared key) and IPsec SAs are 807 established, then the gateway is trusted to behave according to 808 the specification, which mandates a handshake with iSNS for 809 admission. 811 Comment 40. [E] Section 10.2.6 Rekeying 813 I believe the security draft has changed in this area (small 814 rekeying interval example), please check it. 816 Response 818 We appear to be consistent with [SECIPS] version 11 still, end 819 of section 5.4, when Bellare�s results are taken into 820 consideration. Therefore, no change to iFCP is required. 822 Comment 41. [T] Section 10.2.7 Authorization 823 "Authorization is outside of the scope of this specification, 824 and is seen as fully orthogonal to the iFCP security design. 825 Such design, however, includes key authorization-enabling 826 features in the form of Identity Payload (e.g., ID_FQDN), 827 certificate-based authentication (e.g., with X509v3 828 certificates), and discovery domains [ISNS]." 830 What?? If iSNS doesn't know about an iFCP gateway, that 831 gateway shouldn't be able to talk to any other iFCP gateway. 832 That's access control, which counts as authorization in my 833 book. 835 Accept 837 The paragraph will be re-written as follows. 839 �Basic access control properties stem from the requirement that 840 the communicating iFCP gateways be known to one or more iSNS 841 servers before they can engage in iFCP exchanges. The optional 842 use of Identity Payloads (e.g., ID_FQDNs), certificate-based 843 authentication (e.g., with X509v3 certificates), and discovery 844 domains [ISNS] enables authorization schemas of increasing 845 complexity. The definition of such schemas (e.g., role-based 846 access control) is outside of the scope of this specification." 848 Comment 42. [E] Section 10.3.2, pp 86, para 8 850 If an iFCP implementation makes use of unbound TCP connections, 851 and such connections belong to an iFCP Portal with security 852 requirements, then the unbound connections MUST be protected by 853 an SA at all times just like bounded connections. 855 Change "bounded" to "bound". 857 Accepted 859 Comment 43. [T] Section 10.3.2, pp 86, para 9 861 "Upon receiving an IKE Phase-2 delete message, there is no 862 requirement to terminate the protected TCP connections or 863 delete the associated IKE Phase-1 SA. Since an IKE Phase-2 SA 864 may be associated with multiple TCP connections, terminating 865 such connections might in fact be inappropriate and untimely. 866 An iFCP Portal must instead attempt to create a new Phase-2 SA 867 while there are outstanding iFCP sessions." 869 That's a problem. If the other side is behaving in accordance 870 with the next paragraph ...: 872 "To minimize the number of active Phase-2 SAs, IKE Phase-2 873 delete messages may be sent for Phase-2 SAs whose TCP 874 connections have not handled data traffic for a while. To 875 minimize the use of SA resources while the associated TCP 876 connections are idle, creation of a new SA may be deferred 877 until new data is to be sent over the connections." 879 ... and is deleting the Phase-2 SAs because it lacks the 880 resources to support them, immediately creating a new Phase-2 881 SA in response to delete messages risks livelock (massive churn 882 in Phase-2 SA creation/destruction). Creating a new Phase-2 SA 883 in response to a Phase-2 delete message SHOULD be deferred 884 until there is traffic to send over that SA. 886 Accepted 888 We shall be removing the misleading sentence �An iFCP Portal 889 must instead attempt to create a new Phase-2 SA while there are 890 outstanding iFCP sessions." and promote from may to SHOULD 891 prior to the word �deferred�. 893 The resulting modified text is shown below: 895 "Upon receiving an IKE Phase-2 delete message, there is no 896 requirement to terminate the protected TCP connections or 897 delete the associated IKE Phase-1 SA. Since an IKE Phase-2 SA 898 may be associated with multiple TCP connections, terminating 899 such connections might in fact be inappropriate and untimely. 901 "To minimize the number of active Phase-2 SAs, IKE Phase-2 902 delete messages may be sent for Phase-2 SAs whose TCP 903 connections have not handled data traffic for a while. To 904 minimize the use of SA resources while the associated TCP 905 connections are idle, creation of a new SA SHOULD be deferred 906 until new data is to be sent over the connections." 908 Comment 44. [E] Section 13. - Normative References 910 RFC 2451 reference shows up twice. 912 Accepted 914 Comment 45. [T] Section A.2 - Link Services Processed 915 Transparently 917 "ACC Accept" 919 Is that right? I thought this was intercepted in some cases, 920 as indicated in Table 6. 922 Response 924 The ACC description will be modified to discriminate between 925 the transparent and non-transparent cases. 927 Comment 46. [T] Section A.2 - Link Services Processed 928 Transparently 929 FDISC Discover F_Port Service Parameters 930 FLOGI F_Port Login 931 RTV Read Timeout Value 933 Definitely wrong - the iFCP gateway has to implement these 934 itself as specified in Section 9.1. 936 Accepted in Part 938 Special link service messages are those which require 939 intervention by an iFCP protocol implementation before they are 940 passed to the destination N_PORT. Transparent link service 941 messages are passed to the destination N_PORT without such 942 intervention. In that regard, the above link services are 943 processed transparently. 945 The specification will be modified to make the above 946 distinction clearer and the section will be re-titled as: "Link 947 Services Processed Transparently by the iFCP layer". 949 Comment 47. [T] Section A.2 - Link Services Processed 950 Transparently 952 LINIT Loop Initialize 953 LPC Loop Port Control 954 LSTS Loop Status 955 SCL Scan Remote Loop 957 I don't have time to check these, but I'm suspicious about 958 whether anything that has "Loop" as part of its name can/should 959 be forwarded transparently into an FC fabric, although SCL 960 seems plausible. Please verify whether these are transparent. 962 Response 964 SCL must be processed as a special link service message. iFCP 965 will be modified accordingly. The remaining link services 966 listed above are transparent. 968 Comment 48. [T] Section A.2 - Link Services Processed 969 Transparently 971 RSCN Registered State Change Notification 972 SCN State Change Notification 973 SCR State Change Registration 975 Those can't be transparent, as Section 9.2 requires the iFCP 976 gateway to implement them. 978 Response 980 See response to Comment 46. 982 3. Comments From Elizabeth Rodriguez 984 Comment 49. [E] Title Page, Number of Authors 986 Looks like you have 8 authors listed. Rule of thumb I think is 987 6. I am having difficulty locating the guidelines, but may want 988 to consider how you can move a couple of the listed authors 989 into an acknowledgements section of some sort. With 8, it may 990 or may not get flagged by the IESG... 992 Accepted 994 We will reduce the roster of co-authors in accordance with IETF 995 policy. 997 Comment 50. [E] Capitalize Fibre Channel 999 I believe "Fibre Channel" should be capitalized throughout 1000 document. 1002 Rejected 1004 The specification is consistent with T11 lower case usage. 1006 Comment 51. [E] Acknowledgements 1008 Braces around SECIPS do not match. 1010 Accepted 1012 Comment 52. [E] Section 1.2 1014 "NCITS" should be "INCITS". 1016 Accepted 1018 Comment 53. [E] "About This Document" 1020 There should be a page break before this section. 1022 Accepted 1024 Comment 54. [E] Definitions, iFCP Frame 1026 Technically, the title is of the comment encapsulation 1027 specification is "FC Frame Encapsulation". 1029 Accepted 1031 Comment 55. [E] Definitions 1032 In the definitions of "N_PORT Alias" and "N_PORT I/D", two 1033 dashes should be used to separate the term from the body of the 1034 definition. 1036 Accepted 1038 Comment 56. [E] Section 3, pp 9, para 1 1040 "Fibre channel is a frame-based, serial technology designed for 1041 peer-to-peer communication between devices at gigabit speeds 1042 and with low overhead and latency." 1044 May want to change to gigabit or greater speeds. Technically, 1045 2, 4, 10 gigabit speeds are still gigabit, but many today 1046 interpret gigabit strictly as 1 gigabit. 1048 Rejected 1050 The term 'speeds' implies rates of 1Gb/sec and above. 1052 Comment 57. [E] Section 3.1 1054 a) "N_PORTs -- The end points for fibre channel traffic. In 1055 the FC standards, N_PORT interfaces have several variants, 1056 depending on the topology of the fabric to which they are 1057 attached. As used in this specification, the term applies 1058 to any one of the variants." 1060 Suggestion -- sometimes referred to in literature as Nx_PORTs? 1062 Rejected 1064 A parenthetical Nx_PORT digression does not add any value to 1065 the iFCP specification, given that the following statement 1066 claims that N_PORT is used for any such variants. 1068 Comment 58. [E] Section 3.2, Fabric Topologies 1070 a) "Arbitrated Loop -- A series of N_PORTs connected together 1071 in daisy-chain fashion. Data transmission between N_PORTs 1072 requires arbitration for control of the loop in a manner 1073 similar to a token ring network." 1075 Accepted in part 1077 Rewrite as: 1079 a) �Arbitrated Loop -- A series of N_PORTs connected together 1080 in daisy-chain fashion. Loop-connected N_PORTS are referred 1081 to as NL_PORTS. Data transmission between NL_PORTS 1082 requires...� 1084 Comment 59. [E] Section 3.3, pp 13, para 6 1085 "FC-4 �- Application protocols, such as FCP, the fibre channel 1086 SCSI protocol." 1088 Reword to read: "...such as FCP, commonly used abbreviation for 1089 "Fibre Channel Protocol for SCSI" 1091 Accepted in part 1093 The sentence will be revised to read: "...such as the fibre 1094 channel protocol for SCSI (FCP)." 1096 Comment 60. [E] Section 3.7, pp 16, par 2 1098 "The source and destination N_PORT fabric addresses embedded in 1099 the S_ID and D_ID fields represent the physical MAC addresses 1100 of originating and receiving N_PORTs." 1102 "I think the term MAC is inappropriate here -- MAC is really an 1103 ethernet term. Something like physical world wide unique 1104 address, similar to an ethernet MAC address... Or ... represent 1105 the physical MAC like address... 1107 Accepted 1109 The text will be changed to: 1111 "The source and destination N_PORT fabric addresses embedded in 1112 the S_ID and D_ID fields represent the physical addresses of 1113 the originating and receiving N_PORTs." 1115 Comment 61. [E] Section 3.8, Fibre Channel Transport 1116 Services 1118 Does class 6 still exist, or has it been made obsolete? 1120 Response 1122 Class 6 is still specified in [FC-FS]. 1124 Comment 62. [E] Section 4.5, pp 24, para 5 1126 "The mode of gateway operation is settable in an 1127 implementation-specific manner. The implementation MUST NOT 1128 allow the mode to be changed after the gateway begins 1129 processing fibre channel frame traffic." 1131 Does this need to be qualified -- e.g. MUST NOT allow the mode 1132 to be changed after the gateway begins processing Fibre Channel 1133 traffic without first terminating all connections to that 1134 gateway, or some such -- in other words, really someone can 1135 change the mode of operation, but just cannot do so while the 1136 gateway is in use. 1138 Rejected 1140 The specification will not be changed. The intent is to latch 1141 the operational mode after gateway power is turned on and the 1142 gateway begins handling FC frame traffic. A change in 1143 operational mode is not intended to be easy or graceful. 1145 Comment 63. [E] Section 5.2.2.1, pp 31, para 9 1147 "When creating a descriptor in response to an incoming CBIND 1148 request, the iFCP gateway SHALL perform an iSNS name server 1149 query using the worldwide port name of the remote N_PORT in the 1150 SOURCE N_PORT NAME field within the CBIND payload. The 1151 descriptor SHALL be filled in using the query results." 1153 Need to make sure that iSNS gets through WG last call soon as 1154 well, since this is a normative dependency. 1156 Accepted 1158 Comment 64. [E] Section 5.4, pp 39, para 1 1160 "This section describes the iFCP encapsulation of fibre channel 1161 frames. The encapsulation is based on the common encapsulation 1162 format defined in [ENCAP]." 1164 The reference to "common encapsulation" should be "FC Frame 1165 Encapsulation". 1167 Rejected 1169 The reference is appropriate. 1171 Comment 65. [E] Section 6.2, Unbind Connection (UNBIND) 1173 It should be noted that the Unbind status codes listed in this 1174 section are decimal values. 1176 Accepted 1178 The rules for numeric representation will be added to the 1179 "Conventions" section. 1181 Comment 66. [E] Section 7, pp 53 1183 a) "Transparent � The link service message and reply MUST be 1184 transported to the receiving N_PORT by the iFCP gateway 1185 without altering the message payload. The link service 1186 message and reply are not processed by the iFCP 1187 implementation." 1189 Since iFCP has Transparent and Translation modes, use of the 1190 term transparent here might get confusing -- Transparent is 1191 referring to the fact that the link service must be propogated 1192 across the IP network, correct? As opposed to a link service 1193 that is applicable only to transparent mode... 1195 Accepted 1197 The term "transparent" in this context will be changed to 1198 "pass-though". 1200 4. Comments from Brian Forbes 1202 Comment 67. [E] Section 2.1, Special Characters 1204 For some reason the file contains a number of occurrences of 1205 the character instead of a hyphen or dash. 1206 Occurs throughout the text. 1208 Accepted 1210 Comment 68. [E] Section 2.1, Definitions 1212 "iFCP Session - An association created when an N_PORT sends a 1213 PLOGI request to a remotely attached N_PORT. It is comprised of 1214 the N_PORTs and TCP connection that carries traffic between 1215 them." 1217 Grammar: �it is comprised of� should be �it comprises�. 1219 Accepted 1221 Comment 69. [E] Section 2.1, Definitions 1223 "N_PORT Alias -- The N_PORT address assigned by a gateway to 1224 represent a remote N_PORT accessed via the iFCP protocol. When 1225 routing frame traffic in address translation mode, the gateway 1226 automatically converts N_PORT aliases to N_PORT network 1227 addresses and vice versa." 1229 Consistency: in the list of 2.1 definitions, some entries use a 1230 double hyphen and others only a single one (which at least one 1231 reader interpreted as a change in level) 1233 Accepted 1235 Comment 70. [E] Section 3.1, The Fibre Channel Network 1237 "Unlike a layered network architecture, a fibre channel 1238 network is largely..." 1240 Remove the extra space after the comma. 1242 Accepted 1243 Comment 71. [E] Section 3.3.1, Fabric Supplied Link 1244 Services 1246 "Time Server �- Intended for the management of fabric-wide 1247 expiration timers or elapsed time values and is not intended 1248 for precise time synchronization" 1250 Parallel structure: �and is not intended� seems to read better 1251 as �and not intended� 1253 Accepted 1255 Text will be changed to read: 1257 "Time Server �- Intended for the management of fabric-wide 1258 expiration timers or elapsed time values and not intended for 1259 precise time synchronization" 1261 Comment 72. [E] Section 3.7.1, page 6, para 3 1263 "...The value of the Domain I/D ranges from 1 to 239 (0xEF)." 1265 Both �ID� and �I/D� are used to mean �identifier� within the 1266 same paragraph. Common usage suggests �ID� throughout. Also 1268 Accepted 1270 Comment 73. [E] Section 3.7.1, page 17, para 3 1272 For some reason the file contains a number of occurrences of a 1273 non-ascii character instead of an apostrophe. Also occurs on 1274 pages 64 for example. 1276 Accepted 1278 Comment 74. [E] Section 3.7.1, page 17, para 4 1280 �FLOGI�: this is the first occurrence of this FC term; it 1281 should be spelled out here or a forward reference could be 1282 provided 1284 Accepted 1286 Comment 75. [E] Section 3.9, page 18. item a) 1288 a) "Fabric Login (FLOGI) -- An operation whereby the N_PORT 1289 registers its presence on the fabric, obtains fabric 1290 parameters, such as classes of service supported, and 1291 receives its N_PORT address," 1293 Reads better without the comma after �fabric parameters�. 1295 Accepted 1297 Comment 76. [E] Section 4, page 18, para 3 1299 "Within the fibre channel device domain, fabric-addressable 1300 entities consist of other N_PORTs and devices internal to the 1301 fabric that perform the fabric services defined in [FC-GS3]." 1303 �devices� is possibly ambiguous here, could say �FC devices� or 1304 iFCP devices� depending on the intent. 1306 Accepted 1308 Text will be changed to: 1310 "Within the fibre channel device domain, fabric-addressable 1311 entities consist of other N_PORTs and fibre channel devices 1312 internal to the fabric that perform the fabric services defined 1313 in [FC-GS3]." 1315 Comment 77. [E] Section 4.6.1, Page 25, Para 1 1317 "As described in section 4.6, each gateway and fibre channel 1318 switch in a bounded iFCP fabric MUST have a unique domain I/D. 1319 In a gateway region containing fibre channel switch elements, 1320 each element obtains a domain I/D by querying the principal 1321 switch as described in [FC-SW2] -- in this case the iFCP 1322 gateway itself. The gateway in turn MUST obtain domain I/Ds on 1323 demand from the iSNS name server acting as the central address 1324 allocation authority. In effect, the iSNS server assumes the 1325 role of principal switch for the bounded fabric. In that case, 1326 the iSNS database contains:" 1328 The fact that a gateway can act as the FC principal switch is 1329 mentioned in this section and others, but there seems to be no 1330 normative text determining when it must do so. This will be 1331 obvious to a knowledgeable reader, or perhaps is covered in an 1332 ancillary document, but given the care taken elsewhere to 1333 provide normative language for �obvious� functionality it seems 1334 to be an oversight 1336 Rejected 1338 Since the paragraph is intended to describe behavior that is 1339 normatively specified elsewhere, the use of "MUST" is 1340 incorrect. The text will be changed to the following: 1342 "As described in section 4.6, each gateway and fibre channel 1343 switch in a bounded iFCP fabric has a unique domain I/D. In a 1344 gateway region containing fibre channel switch elements, each 1345 element obtains a domain I/D by querying the principal switch 1346 as described in [FC-SW2] -- in this case the iFCP gateway 1347 itself. The gateway in turn obtains domain I/Ds on demand from 1348 the iSNS name server acting as the central address allocation 1349 authority. In effect, the iSNS server assumes the role of 1350 principal switch for the bounded fabric. In that case, the iSNS 1351 database contains..." 1353 Comment 78. [E] Section 5.2.2.3, page 35, paras 3 and 4 1355 These two paragraphs use the terms �heartbeat� and 1356 �connectivity probe� as informal synonyms for LTESTs. Use of 1357 the same synonym in both places would keep the reader from 1358 wondering whether the two synonyms represent the same concept. 1360 Accepted 1362 Comment 79. [E] Section 5.2.2.4.3, page 37, para 1 1364 "Window scaling, as specified in [RFC1323], allows full 1365 utilization of links with large bandwidth - delay products and 1366 should be supported by an iFCP implementation." 1368 Is �should� intended to be normative (capitalized)? 1370 Response 1372 The lower case usage is intentional. The goal is to reflect a 1373 desirable bias rather than the sort of mandate defined in 1374 [RFC2119]. 1376 Comment 80. [E] Section 5.2,3, page 32, items c) and d) 1378 a) "For an FC frame received from the IP network, a gateway 1379 detects a CRC error in the encapsulation header. The gateway 1380 shall abort the session as described in section.... 1382 b) "The TCP connection associated with the login session fails 1383 for any reason. The gateway detecting the failed connection 1384 shall abort the session as described in section...." 1386 �shall� should be capitalized. 1388 Accepted 1390 Comment 81. [E] Section 5.4, page 39, last paragraph 1392 "When operating in Address Translation mode, (see section ...) 1393 the iFCP gateway must recalculate the fibre channel CRC." 1395 �must� should be in caps. 1397 Accepted 1399 Comment 82. [E] Section 5.4, page 41, "TRN" mnemonic 1400 It�s unfortunate that �TRN� can be read as either �transparent� 1401 or �translation� and therefore has less mnemonic value. 1403 Accepted 1405 "TRN", the mnemonic for "transparent mode", will be changed to 1406 "TRP". 1408 Comment 83. [E] Section 6.2, page 49, para 1 1410 "UNBIND is used to release a bound TCP connection and. 1411 optionally, return it to the pool of unbound TCP connections." 1413 Punctuation: �and. optionally, � should be �and optionally�. 1415 Accepted 1417 Comment 84. [E] Section 7.3, page 58, para 2 1419 "The formats of each special link service message, including 1420 supplemental data where applicable, are shown in the following 1421 sections." 1423 �The formats of each� message are� is awkward, suggest �The 1424 format of each� message is�. 1426 Accepted 1428 Comment 85. [E] Section 7.3.1.6, page 63, para 2 1430 "This ELS shall always be sent as an augmented ELS regardless 1431 of the translation mode in effect." 1433 "Shall" should be capitalized. 1435 Accepted 1437 The text must also be modified to replace "augmented" with 1438 "special", as given below. 1440 "This ELS SHALL always be sent as a special ELS regardless of 1441 the translation mode in effect." 1443 [E] Section 7.3.1.14, page 71, last paragraph 1445 "The size of each frame to be sent to the destination N_PORT 1446 MUST NOT exceed the maximum frame size that the destination 1447 N_PORT can accept. The sequence identifier in each frame 1448 header SHALL be copied from the augmented ELS and the sequence 1449 count shall be monotonically increasing." 1451 "Shall" should be capitalized. 1453 Accepted 1455 Comment 86. [E] Section 10.2.4, page 82, paras 1 and 2 1457 "iFCP is a peer-to-peer protocol. iFCP sessions may be 1458 initiated by either or both peer gateways. Consequently, bi- 1459 directional authentication of peer gateways MUST be provided. 1461 "iFCP gateways MUST use Discovery Domain information obtained 1462 from the iSNS server [ISNS] to determine whether the initiating 1463 fibre channel N_PORT should be allowed access to the target 1464 N_PORT. N_PORT identities used in the Port Login (PLOGI) 1465 process shall be considered authenticated provided the PLOGI 1466 request is received from the remote gateway over a secure, 1467 IPSec-protected connection." 1469 These paragraphs seem to be statements of required 1470 functionality but are too general to use normative language 1471 (�MUST�). Later sections contain the normative text necessary 1472 to cover these topics. 1474 Accepted 1476 Comment 87. [E] Section 10.2.5, page 82, para 1 1478 See Comment 86. 1480 Accepted 1482 Comment 88. [E] Section 10.2.6, pages 82 and 82, all 1483 paragraphs 1485 See Comment 86. 1487 Accepted 1489 5. Comments from Mallikarjun Chadalapaka 1491 Comment 89. [E] Section 1.2 1493 "...standards controlled by NCITS T10 and T11." 1495 "NCITS" should be "INCITS". 1497 Accepted 1499 Comment 90. [E] 2.1 Definitions 1501 "Gateway Region -- The portion of an iFCP fabric accessed 1502 through an iFCP gateway. Fibre channel devices in the region 1503 consist of all fibre channel devices locally attached to the 1504 gateway." 1506 The first sentence here when interpreted wrt a Nx_port sitting 1507 within a given gateway region, implies something that isn't 1508 right - viz. the rest of the iFCP fabric. The second sentence 1509 makes the intention clear, if "locally attached" includes the 1510 entire local fabric. My suggestion would be: "The portion of 1511 an iFCP fabric that accesses the rest of the fabric through one 1512 iFCP gateway." 1514 Accepted 1516 The definition will be changed to the following: 1518 "Gateway Region -- The portion of an iFCP fabric accessed 1519 through an iFCP gateway by a remotely attached N_PORT. Fibre 1520 channel devices in the region consist of all those locally 1521 attached to the gateway." 1523 Comment 91. [T] Section 3.3.1, pp 14, para 7 1525 "Time Server -- Intended for the management of fabric-wide 1526 expiration timers or elapsed time values and is not intended 1527 for precise time synchronization." 1529 I am curious about this - is it the conclusion the iFCP authors 1530 reached? The reason I ask is that IIRC, FCIP allows using this 1531 for time sync. 1533 Response 1535 See Comment 71 for the proposed change to this section. 1537 The characterization is found in the literature and based on 1538 the following from the [FC-GS3] specification, section 7, page 1539 161. 1541 "The Time Service is provided to serve time information that is 1542 sufficient for managing expiration time." 1544 Comment 92. [T] Section 3.7, pp 14, para 2 1546 "The source and destination N_PORT fabric addresses embedded in 1547 the S_ID and D_ID fields represent the physical MAC addresses 1548 of originating and receiving N_PORTs." 1550 I am not sure that it is a correct analogy....S_ID and D_ID are 1551 actually (potentially transient) addresses assigned by the 1552 fabric, Port Names are more akin to the MAC addresses. 1554 Accepted 1555 See Comment 60. 1557 Comment 93. [E] 4. The iFCP Network Model 1559 "The iFCP protocol enables the implementation of fibre channel 1560 mixed or switched fabric functionality on an IP network." 1562 I am not sure what is intended by "fibre channel mixed or 1563 switched" here, perhaps this could use rewording. 1565 Accepted 1567 The text will be changed to: 1569 "The iFCP protocol enables the implementation of fibre channel 1570 fabric functionality on an IP network." 1572 Comment 94. [E] Section 4, pp 20, para 1 1574 "Each iFCP gateway contains two standards-compliant fibre 1575 channel ports and an iFCP Portal for attachment to the IP 1576 network." 1578 Why are two FC ports required? As far as I can tell, even one 1579 E_Port works just as well - is it to be technically called as a 1580 "switch"? 1582 Also, is there a reason for limiting to only one IP address 1583 (implied by one iFCP Portal)? I see that supporting multiple 1584 iFCP Portals would require enahancements to the data structures 1585 presented - but can you please comment on any architectural 1586 issues here? 1588 Response 1590 The specification will be revised to emphasize that the figure 1591 is but one example of a supported implementation. It was 1592 intended to parallel the earlier fibre channel fabric example 1593 as a way of showing the transition to an equivalent iFCP 1594 fabric. 1596 The selected example was chosen because it was easier to depict 1597 within the constraints of ASCII text. An E_PORT example could 1598 have also been used. In either case, the device incorporating 1599 iFCP portal functionality would be called an "iFCP gateway". 1601 The considerations to be addressed when connecting multiple 1602 iFCP portals to a gateway region are discussed in Comment 12. 1604 Comment 95. [E] section 4, pp 20, para 2 1606 "... channel switch element. At this interface, remote N_PORTs 1607 are presented as fabric-attached devices. Conversely, on the IP 1608 network side, the gateway presents each locally connected 1609 N_PORT as a logical fibre channel device." 1611 I am not sure the last sentence is correct - I think "logical 1612 fibre channel device" should probably be replaced by "a TCP 1613 connection". 1615 Rejected 1617 The logical fibre channel device represents the layer 4 1618 abstraction visible on the IP network. 1620 Comment 96. [E] Section 4.1, pp 20, para 1 1622 "...cases, the gateway may support any standards-compliant 1623 fibre channel fabric type by incorporating the functionality 1624 required to..." 1626 Can you please comment if really "fabric type" is meant here? 1627 Or, is it the "fabric port type"? 1629 Response 1631 More accurately, "fabric type" should be changed to "fibre 1632 channel network topology." The specification will be changed 1633 accordingly. See Comment 5. 1635 Comment 97. [E] Section 4.1, pp 20, para 1 1637 "...present locally attached N_PORTs as logical iFCP devices." 1639 It may be useful to define "iFCP device" in section 2.1. 1641 Rejected 1643 From section 2.1: 1645 "Logical iFCP Device - The abstraction representing a single 1646 fibre channel device as it appears on an iFCP network." 1648 The specification will not be changed. 1650 Comment 98. [T] Section 4.4.1, pp 22, para 2 1652 "...messages, a gateway cannot convert such addresses in the 1653 payload of vendor- or user-specific fibre channel frame 1654 traffic." 1656 Not being very familiar with today's FC, can you please comment 1657 if these proprietary versions of frame formats (with even the 1658 D_ID out of place) are legal on regular fabrics? Seems like 1659 the entire fabric should be capable of special handling 1660 these... 1662 Response 1664 There is one and only one acceptable format for FC frames. That 1665 said, the issue is not the frame format but the payload 1666 contents. 1668 Besides the addresses in the FC frame header, an iFCP 1669 implementation is only cognizant of N_PORT addresses that may 1670 be embedded in the payload of standards-compliant link service 1671 messages. It cannot remap such addresses if present in the 1672 payloads of user-specified or vendor-specific frames. 1674 No change to the specification will be made. 1676 Comment 99. [T] Section 4.4.3, pp 22, para 1 1678 "In an unbounded iFCP fabric, limiting the scope of an N_PORT 1679 address to a gateway region reduces the likelihood that 1680 reassignment of domain I/Ds caused by a disruption in one 1681 gateway region will cascade to others." 1683 "In an unbounded iFCP fabric, limiting the scope of an N_PORT 1684 address to a gateway region reduces the likelihood that " 1686 Does it not prevent the likelihood? 1688 Accepted 1690 The text will be changed to: 1692 "In an unbounded iFCP fabric, limiting the scope of an N_PORT 1693 address to a gateway region prevents reassignment of domain 1694 I/Ds caused when a disruption in one gateway region cascades to 1695 others." 1697 Comment 100. [T] Section 4.4.3, pp 22, para 2 1699 "In addition, a bounded iFCP fabric has an increased dependency 1700 on..." 1702 Suggest changing "In addition" to "On the other hand". 1704 Accepted 1706 Comment 101. [E] Section 4.4.3, pp 22, para 3 1708 "Finally, adding a gateway to a bounded fabric is more likely 1709 to disrupt the operation of all devices in the gateway region 1710 along with those already in the fabric as new, fabric-wide 1711 N_PORT addresses are assigned." 1712 Isn't the issue in this para the same as that in the first 1713 para, albeit from the bounded fabric's perspective? If so, 1714 suggest merging them. 1716 Rejected 1718 Adding a new gateway region is distinct from disrupting an 1719 existing region and therefore merits its own mention. 1721 Comment 102. [E] Section 4.4.3, pp 23, para 4 1723 ...be done non-disruptively and requires only that new 1724 gateway's iSNS..." 1726 Change "that" to "that the". 1728 Accepted 1730 Comment 103. [T] Section 4.5, The iFCP N_PORT Address Model 1732 b) "A 24-bit N_PORT alias. A fibre channel N_PORT address 1733 assigned by a gateway operating in address translation mode 1734 to identify a remotely attached N_PORT. Frame traffic is 1735 directed to a remotely attached N_PORT by means of the 1736 N_PORT alias." 1738 At any point in time, there can only be 2^24 N_PORTs 1739 communicating even in the address translation mode, even though 1740 this mode allows the same N_PORT to be mapped to different 1741 nports in different gateway regions at different times. If 1742 this is a correct interpretation, I suggest that this be made 1743 clear in section 4.4.2, which currently simply states that 1744 there are no architectural limitations on the number of fibre 1745 channel devices in this mode. 1747 Accepted in Part 1749 While the addressability in a given gateway region is 1750 constrained by the fibre channel address model, the aggregate 1751 addressability of all gateway regions comprising an unbounded 1752 iFCP fabric can exceed that limit. 1754 To make this clearer, the text will be changed as follows: 1756 b) "Since N_PORT fibre channel addresses in an unbounded iFCP 1757 fabric are not fabric-wide, the number of iFCP gateways, 1758 fibre channel devices and switch elements that may be 1759 internetworked may exceed the fibre channel fabric limits." 1761 Comment 104. [E] Section 4.6.1, pp 25, para 4 1763 "In its role as principal switch within the gateway region, an 1764 iFCP..." 1765 General comment - Change to "...as the Principal Switch...". 1767 Accepted 1769 Comment 105. [T] Section 5.2.1, pp 30, para 4 1771 "...A gateway implementation MAY establish a pool of unbound 1772 connections to reduce the session setup time. Such pre- 1773 existing TCP connections between iFCP Portals remain unbound 1774 and uncommitted until allocated to an iFCP session through a 1775 CBIND message" 1777 I wonder if there is a scope for DoS attack here with the 1778 possibility of one gateway potentially holding onto several 1779 unused TCP connections infinitely...." 1781 Response 1783 No. However, the specification will be modified to point out 1784 that a gateway may recover resources at any time by simply 1785 closing unbound connections. See Comment 21. 1787 Comment 106. [E] Section 5.2.2.1, pp31, para 6 1789 "If a descriptor does not exist, one SHALL be created in 1790 response to an iSNS name server query." 1792 Did you mean "SHALL be created after the response to an iSNS 1793 name server query is received"? 1795 Response 1797 The test will be changed to: 1799 "If a descriptor does not exist, one SHALL be created using the 1800 information returned by an iSNS name server query." 1802 Comment 107. [E] Section 5.2.2.1.1, pp 31, para 1 1804 "A Remote N_PORT descriptor SHALL only be updated as the result 1805 of an iSNS query that returns information for the specified 1806 worldwide port name. Following such an update, a new N_PORT 1807 alias SHALL NOT be assigned." 1809 I assume you meant "iSNS response" instead of "iSNS query"? 1811 I am a little confused by the SHALL NOT. Here's what I was 1812 assuming as the sequence of events 1814 1. Local FC Name Server query. 1816 2. iFCP gateway picks it up. 1818 3. Consults with iSNS server 1820 4. iSNS provides the remote N_PORT for the WWN 1822 5. iFCP gateway assigns a local alias if in translation mode 1823 and if the remote N_PORT ID clashes with a pre-existing 1824 local NPORT_ID. 1826 I do not see why this sequence should be prohibited. Comments 1827 will certainly help. 1829 Accepted in Part 1831 The text will be modified as described in Comment 108. 1833 The 24-bit N_PORT component of the remote N_PORTs address and 1834 its local alias can never clash. The gateway transparently 1835 converts the alias to a network address, consisting of the TCP 1836 connection I/D, TCP Port number and the N_PORT ID assigned by 1837 the remote gateway. 1839 Comment 108. [T] Section 5.2.2.1.1, pp 31, para 1 1841 "A Remote N_PORT descriptor SHALL only be updated as the result 1842 of an iSNS query that returns information for the specified 1843 worldwide port name. Following such an update, a new N_PORT 1844 alias SHALL NOT be assigned. 1846 "Until such an update occurs, the contents of a descriptor may 1847 become stale as the result of any event that invalidates or 1848 triggers a change in the N_PORT network address of the remote 1849 device, such as a fabric reconfiguration or the device's 1850 removal or replacement." 1852 I assume that generally what is meant by "Until such an update 1853 occurs" is "In the absence of an operational iFCP session based 1854 on a descriptor". If so, it perhaps requires rewording. 1856 Accepted in Part 1858 Descriptors are only built and updated as a consequence of name 1859 server requests or state change notifications. An iFCP session 1860 may not necessarily be associated with these activities. 1862 The text will be reworded as shown below to add the state 1863 change case and clarify the order of events leading to a stale 1864 descriptor. 1866 "A Remote N_PORT descriptor SHALL only be updated as the result 1867 of an iSNS query to obtain information for the specified 1868 worldwide port name or from information returned by an iSNS 1869 state change notification. Following such an update, a new 1870 N_PORT alias SHALL NOT be assigned. 1872 "Before such an update, the contents of a descriptor may have 1873 become stale as the result of any event that invalidates or 1874 triggers a change in the N_PORT network address of the remote 1875 device, such as a fabric reconfiguration or the device's 1876 removal or replacement." 1878 Comment 109. [E] Section 5.2.2.1.1, pp 31, para 4 1880 "Once the originating N_PORT learns of the reconfiguration, 1881 usually through the name server state change notification 1882 mechanism, the name server lookup needed to reestablish the 1883 iFCP session will automatically purge such stale data from the 1884 gateway." 1886 Just a clarification here - it seems to me that the SCN for a 1887 remote N_PORT ID needs to delivered via the iFCP gateway 1888 anyway, so why not purge the stale mapping then (instead of 1889 waiting for the new SNS query from the local N_PORT? 1891 Accepted 1893 The text will be changed to: 1895 "Once the originating N_PORT learns of the reconfiguration, 1896 usually through the name server state change notification 1897 mechanism, information returned in the notification or the 1898 subsequent name server lookup needed to reestablish the iFCP 1899 session will automatically purge such stale data from the 1900 gateway." 1902 Comment 110. [T] Section 5.2.2.2, pp 33 1904 f) "A CBIND response with a CBIND STATUS of "N_PORT session 1905 already exists" indicates that the remote gateway has 1906 concurrently..." 1908 I think the document should specify that this status be mapped 1909 to the LS_RJT reason code of "Login/command already in 1910 progress" - 0x0E. Also, there may be N_PORTs that go down 1911 without issuing a LOGO, and attempt a PLOGI once they come back 1912 - unbeknownst to the iFCP gateway still with the old session 1913 descriptor. It isn't clear to me how this is proposed to be 1914 dealt with. 1916 Rejected 1918 As described in Comment 15, the specified behavior is meant to 1919 serve as a tie-breaking mechanism for the establishment of the 1920 iFCP session. Once the session is established, the PLOGIs from 1921 each side are sent and processed by the N_PORTs in accordance 1922 with the PLOGI semantics specified in [FC-FS]. 1924 A PLOGI after an iFCP session exists is handled in accordance 1925 with section 7.3.1.7, paragraph 5, which states: 1927 "As specified in section 5.2.2.2, a PLOGI request addressed to 1928 a remotely attached N_PORT MUST cause the creation of an iFCP 1929 session if one does not exist. Otherwise, the PLOGI and PLOGI 1930 ACC payloads MUST be passed transparently to the destination 1931 N_PORT using the existing iFCP session." 1933 Section 5.2.2.2 will be modified to describe the simultaneous 1934 PLOGI scenario above and the case of a PLOGI issued when an 1935 iFCP session exists. 1937 Comment 111. [T] Section 5.2.2.3, pp 35 1939 b) "An LTEST message is not received within twice the 1940 specified interval or the iFCP session has been quiescent 1941 for longer than twice the specified interval." 1943 I think "or" above should be "and" - else it implies that the 1944 LTEST message must be received periodically even in the 1945 presence of other traffic. 1947 Rejected 1949 See Comment 18. 1951 If liveness testing was requested for an iFCP session, an LTEST 1952 message must be received within twice the specified interval 1953 regardless of whether or not other traffic is present. 1955 Comment 112. [T] Section 5.2.3, pp 37 1957 a) "An LS_RJT response is returned to the gateway that issued 1958 the PLOGI ELS. The gateway SHALL forward the LS_RJT to the 1959 local N_PORT and complete the session as described in..." 1961 My reading is that the gateway does not "issue" the PLOGI ELS, 1962 it merely facilitates the transport of an issued PLOGI ELS. 1963 The wording here is a little confusing - I also believe that 1964 the forwarding should be to the remote N_PORT, not local. 1966 [Also,] I recommend "terminate"/"close" in all the places 1967 "complete" is used. 1969 Accepted 1971 The text will be modified as follows: 1973 a) "An LS_RJT response is returned to the gateway from which 1974 the PLOGI ELS originated. That gateway SHALL forward the 1975 LS_RJT to the locally attached N_PORT and terminate the 1976 session as described in..." 1978 Comment 113. [E] Section 5.2.3.1, pp 37, para 2 1980 "Unbind session control ELS as described in section 6.2." 1982 I am a little confused about the status of Unbind here - is it 1983 a FC-FS approved ELS or an iFCP session control message? 1985 Response 1987 Since Unbind is an iFCP session control message, the text will 1988 be changed to: 1990 "Unbind session control message as described in section 6.2." 1992 Comment 114. [T] Section 5.2.3.2, pp 38, para 4 1994 "In any event, the TCP connection SHOULD be terminated with a 1995 connection reset (RST). If the local N_PORT has logged in to 1996 the remote N_PORT, the gateway SHALL send a LOGO to the local 1997 N_PORT." 1999 I think the draft should specify both OPEN and OPEN PENDING 2000 cases here. For OPEN state, a local LOGO is required as 2001 stated, whereas for OPEN PENDING, a local LS_RJT may be 2002 appropriate. 2004 Also, it is useful to state that the proxied ELS (in either 2005 case) be indistinguishable from the end-to-end ELS in its 2006 payload (so any sanity checking done by endnode software would 2007 continue to work). 2009 Accepted 2011 Comment 115. [T] Section 5.4.1, pp 40 2013 "Protocol# IANA-assigned protocol number identifying the 2014 protocol using the encapsulation. For iFCP the value is 2015 (/TBD/)." 2017 Should FCEncap document be referred here instead? 2019 Accepted 2021 See Comment 23. 2023 Comment 116. [E] Section 5.4.3, pp 43, para 2 2025 "Following frame validation, the S_ID and D_ID fields in the 2026 frame header SHALL be referenced to lookup the iFCP session 2027 descriptor (see section 5.2.2.2). If no iFCP session descriptor 2028 exists, the frame SHALL be discarded." 2030 With the exception of PLOGI? 2032 Accepted 2034 The specification will be modified to address the case where a 2035 frame triggers the creation of an iFCP session. 2037 Comment 117. [E] Section 5.4.3, pp 43, para 3 2039 "Frames types submitted for encapsulation and forwarding on the 2040 IP..." 2042 "Frames" should be "Frame". 2044 Accepted 2046 Comment 118. [E] Section 6, pp 44, para 1 2048 "TCP session control messages are used to create and manage an 2049 iFCP session as described in section 5.2.2. They are passed 2050 between peer iFCP Portals and are only processed within the 2051 iFCP layer. 2053 "The message format is based on the fibre channel extended link 2054 service message template shown below...." 2056 It may be useful to state that this message forms the "FC 2057 Frame" payload. of the iFCP frame. It may also be useful to 2058 state the value of LS_COMMAND in the encap header (0?). 2060 Instead of having two LS_COMMAND fields - one in the header and 2061 one in the payload - for these messages, a simpler approach 2062 could be to state that LS_COMMAND in the header contains an 2063 iFCP-defined value when SES=1 (and remove the one in the 2064 payload). 2066 Accepted in Part 2068 In accordance with Comment 26, the mnemonic for the LS_COMMAND 2069 field in the encapsulation header will be changed to eliminate 2070 confusion as follows: 2072 From section 5.4, Encapsulation of Fibre Channel Frames: 2074 "LS_COMMAND_ACC For a special link service ACC 2075 response to be processed by iFCP, the 2076 LS_COMMAND_ACC field SHALL contain 2077 bits 31 through 24 of the LS_COMMAND 2078 to which the ACC applies. Otherwise 2079 this field shall be set to zero." 2081 From section 6, TCP Session Control Messages: 2083 LS_COMMAND_ACC 0 2085 With the addition of the new mnemonic, the above text clearly 2086 specifies how the field is to be set. 2088 Comment 119. [E] Section 6.1, pp 46, para 2 2090 "The following shows the format of the CBIND request." 2092 I take it that this CBIND structure goes into the Session 2093 Control Message starting from word 6? Same question on CBIND 2094 response. 2096 Rejected 2098 That is correct. The existing text seems to explain this 2099 adequately. 2101 Comment 120. [T] Section 6.2, pp 49, para 1 2103 "UNBIND is used to release a bound TCP connection and. 2104 optionally, return it to the pool of unbound TCP connections." 2106 I assume "release" here implies - "remove the binding"? 2108 Is there a way to convey the preference to not terminate the 2109 connection on the part of the sender? IOW, where is the 2110 optionality selected? 2112 Response 2114 See Comment 21 regarding the disposition of "unbound" TCP 2115 connections. The above paragraph will be expanded to clarify 2116 the rationale for the unbound connection pool as follows: 2118 "UNBIND is used to terminate an iFCP session and disassociate 2119 the TCP connection. To expedite the creation of a new iFCP 2120 session, the TCP connection MAY remain open at the discretion 2121 of either gateway and kept in a pool of unbound connections. 2123 In order to recover resources, either gateway may spontaneously 2124 close the unbound TCP connection at any time." 2126 Comment 121. [E] Section 6.2, pp 50, para 1 2128 "transmitted in the connection that is to be unbound. The 2129 time..." 2131 Change "in" to "on". 2133 Accepted 2134 Comment 122. [T] Section 8.2.1, pp 76, para 1 2136 "The R_A_TOV limit on frame lifetimes SHALL be enforced by 2137 means of the time stamp in the encapsulation header (see 2138 section 5.4.1 ) as described in this section." 2140 A couple of general questions on this section - 2142 a) Is Unsynchronized operation allowed? If so, how is the 2143 R_A_TOV expectation met? 2145 b) If an incorrect configuration causes the timestamp of the 2146 incoming frame to be higher than the gateway's time base, it 2147 is better if there is a way to detect and perhaps resync 2148 both ends with the same SNTP server (as opposed to one out 2149 of a list returned by iSNS). As far as I can tell, the 2150 current text specifies that it would simply cause the frames 2151 to be discarded, but doesn't break the binding nor terminate 2152 the TCP connection - perhaps relying on the end nodes to 2153 LOGOUT? 2155 Accepted in Part 2157 For item a), see the response to Comment 35. 2159 For item b), iFCP specifies the following behavior: 2161 d) "If the incoming frame has a non-zero time stamp, the 2162 receiving gateway SHALL compute the absolute value of the 2163 time in flight and SHALL compare it against the value of 2164 IP_TOV specified for the IP fabric. 2166 e) "If the result in step (d) exceeds IP_TOV, the encapsulated 2167 frame shall be discarded. Otherwise, the frame shall be 2168 de-encapsulated as described in section ...." 2170 Since it is impossible to guarantee that one time reference 2171 won't be skewed negatively with respect to the other. the 2172 propagation delay test is against the absolute value of the 2173 time difference. 2175 The iFCP spec will be modified to state that an iFCP gateway 2176 implementation MAY terminate an iFCP session if the rate at 2177 which stale frames are detected exceeds some administratively- 2178 specified threshold. 2180 6. Security Considerations 2182 The applicable security provisions are defined in [IFCP]. 2184 7. References 2186 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 2187 3", BCP 9, RFC 2026, October 1996. 2189 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2190 Requirement Levels", BCP 14, RFC 2119, March 1997 2192 [IFCP] Monia, C., et al, � iFCP - A Protocol for Internet Fibre 2193 Channel Storage Networking", draft-ietf-ips-ifcp-10.txt, 2194 February 2002 2196 [FC-FS] dpANS INCITS.XXX-200X, "Fibre Channel Framing and Signaling 2197 Interface", Revision 1.7, NCITS Project 1331-D, February 2198 2002 2200 [SECIPS] Aboba, B., et-al., "Securing Block Storage Protocols Over 2201 IP", revision 11, February 2002 2203 [FC-GS3] dpANS X3.XXX-200X, "Fibre Channel Generic Services -3 (FC- 2204 GS3)", revision 7.01, NCITS Project 1356-D, November 2000 2206 8. Author's Addresses 2208 Charles Monia Franco Travostino 2209 Josh Tseng Director, Content 2210 Internetworking Lab, 2211 Nishan Systems Nortel Networks 2212 3850 North First Street 3 Federal Street 2213 San Jose, CA 95134 Billerica, MA 01821 2214 Phone: 408-519-3986 Phone: 978-288-7708 2215 Email: Email: 2216 cmonia@nishansystems.com travos@nortelnetworks.com 2218 Full Copyright Statement 2220 "Copyright (C) The Internet Society May 2002. All Rights Reserved. 2221 This document and translations of it may be copied and furnished to 2222 others, and derivative works that comment on or otherwise explain it 2223 or assist in its implmentation may be prepared, copied, published 2224 and distributed, in whole or in part, without restriction of any 2225 kind, provided that the above copyright notice and this paragraph 2226 are included on all such copies and derivative works. However, this 2227 document itself may not be modified in any way, such as by removing 2228 the copyright notice or references to the Internet Society or other 2229 Internet organizations, except as needed for the purpose of 2230 developing Internet standards in which case the procedures for 2231 copyrights defined in the Internet Standards process must be 2232 followed, or as required to translate it into languages other than 2233 English. 2235 The limited permissions granted above are perpetual and will not be 2236 revoked by the Internet Society or its successors or assigns. 2238 This document and the information contained herein is provided on an 2239 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2240 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2241 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2242 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2243 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."