03 027v0

Company number Akara-001 Akara-002
tech/e Sec/table/fig dit locator Page E E 1.1, par 3 vii
Comment Spelling of Neil Wanamaker
Proposed resolution Correct
Response Accepted Accepted
Status Completed in Rev 5.8 Completed in Rev 5.8
1 "..emphasize on " in 2 places Remove on. The major part of FC-BB-2 is the addition of the FC-BB-2_IP This is the major addition, not specification which makes use major part. Replace "IETF 1 of the IETF specification [16]. specification" with FCIP [16].
Akara-003
1.1, par 3
Accepted
Completed in Rev 5.8
Akara-004
1.2, par 1
1 "..support for E_Ports" The B_port model shows the switch (or BSW) outside the box, with the B_port being the boundary of this specification. The E_port model shows these inside, with the boundary being the E_Port. These should be consistent.
Replace by "..support for virtual E_Ports" or "support for VEports".
Rejected: The commented suggestion is good one but will create an uneveness in the naming of Reference Model. VE_Port and B-Port creates a confusin as to what part of a model dictates its name. We cannot use B_Access as it only applies to IP. In future, we may be able to call the models VE_Port and B_Access when BBW models are changed to show this.
Akara-005
Global
Global
Make boundary of this model be VE_Port, with E_Ports, switch elements, BSWs, etc. outside this specification. See Andiamo-001
Akara-006 Akara-007
E E
2.1 2.2
T1.105 and T1.105.02 have been revised (2001; prepublished). FC-BB is INCITS 342-2001. FC-SW-2 is INCITS 355-2001. FG reaffirmed 2001 (?). FC-GS-3 is INCITS 3484 2001. Correct 5 xxxxD should be filled in.
Accepted. BB, SW-2, GS-3 corrected.T1.105 and T1.105.02 references from 1995 have been used to make the standard. 2001 updates were not used and may actually [resent problems if the later one is used. Completed in Rev 5.8 Accepted Completed in Rev 5.8
Company number
tech/e Sec/table/fig dit locator Page Table 17, Figure 11, Figure 12 50, 51,52
Comment Size of LLC/SNAP header is inconsistent.
Proposed resolution
Response
Status
Akara-008
Correct
Accepted
Akara-009
13.2.3.3.5, Figure 25
74, 75
It would appear that, with the exception of the LKA, ILSs are exchanged between (I.e., are initiated and terminated at) the attached E_Ports, not between the VE_Ports. These other ILSs are simply transported across the virtual ISL. Remove mention of other ILSs.
Rejected- ILSs are in fact exchanged between VE_Ports
Akara-010 Andiamo-001
T T
13.2.3.5.2.2 4.2, 4.4, 13.2.3.2.1
"If the network transit time is large enough to jeopardize meeting any Fibre Channel timeout requirements, the frame shall be discarded.". The FCIP entity cannot Timeout values should be agreed determine this by any means as part of routing setup during 76 specified in this standard. fabric initialization. 14-15 In these section there are a) complete the FSPF backbone and 72 several references to inter-AR definition in FC-SW-3; or b) connectivity, which requires include in FC-BB-2 the missing the usage of the FSPF pieces; or c) remove the inter-AR backbone protocol. But FSPF model from FC-BB-2. backbone is still not completely specified in FC-SW3. There are interoperability risks.
Accepted - Text indicating that timeout values will be adminstratively set. This should become a work item for FC-BB3 and FC-SW-4. See also McData-035. See also CNT-017 Completed in Rev 5.8
Accepted c). Removed all references to FSPF-Backbone, and AR Completed in Rev 5.8
Company number Andiamo-002
tech/e Sec/table/fig dit locator Page Comment Proposed resolution Response E several several The terminology used across Use a terminology consistent with the document is not consistent FC-FS. with FC-FS. It should be. Example: "FC Fabric Entity WWN" should be simply "Fabric_Name". WWPN should be N_Port_Name or B_Port_Name or what is required. Accepted E 13.2.3.4 75 The text says: "FCIP Wellknown Port 3225" It should be"FCIP Well-known TCP Port 3225".
Status
Andiamo-003
Accepted with correction: The correct term is actually FCIP Registered TCP Port Number 3225
Andiamo-004
13.2.3.3.5.1
75
The text says: "The Link Keep It should be"The Link Keep Alive Alive Switch Fabric ILS" SW_ILS". Accepted Completed in Rev 5.8 Completed in Rev 5.8 The text says: "A F Class frame" The text is ambiguous: "If the network transit time is large enough to jeopardize meeting any Fibre Channel timeout requirements" item a) says "FCsec frame authentication"; item b) says "IPsec TCP data authentication" The Requester Interconnect_Port_Name: definition says: "This field shall contain the name of the device that originated the EBP request." the term "name" is ambiguous The encoded value column is in binary It should be "A Class F frame" Accepted Give a more quantitative and measurable definition of "large enough", otherwise interoperability problems may occur. Accepted - See Akara -010 Change item a) in "FCsec frame authentication and confidentiality"; and item b) in "IPsec packet authentication and confidentiality". Accepted Clarify that this is a Port_Name. Completed in Rev 5.8
Andiamo-005 Andiamo-006
E T
13.2.3.5.2.2 13.2.3.5.2.2
76 76
Andiamo-007
13.2.3.5.4
77
Andiamo-008
13.3.3.2.5.1
81
Accepted: Changed to Port_Name. Please note Port_name refers to either an VE_Port or B_Access in this case. Completed in Rev 5.8 Express it in hex. Accepted Completed in Rev 5.8
Andiamo-009
table 23
82
Company number Andiamo-010
tech/e Sec/table/fig dit locator Page E 14.2.1 92
Comment Proposed resolution The Connection Usage Code Remove or resolve this text. paragraph contains the text "A TBD". What does it mean this paragraph? FC multicast/broadcast or IP multicast/broadcast ? What's wrong in supporting FC broadcast as defined in FCSW-3, being an FCIP link another kind of ISL link? The text says: "IPsec TCP data authentication" Clarify.
Response
Status
Accepted: See Brocade-127
Andiamo-011
16.6
101
Accepted. Add- This standard does not make use of IP broadcast/multicast. Completed in Rev 5.8 Change it in "IPsec packet authentication and confidentiality".
Andiamo-012
16.7
101
Accepted
Brocade-001 Brocade-002
E E
All Front Matter
All All
The frame type notation of FT0 and FT-1 are FC-PH notations. These have been redefined in FC-FS to be FT_0 and FT_1, respectively. NCITS needs to be changed to INCITS Change all instances of "National Committee for Information Technology" to "InterNational"
Change all references to FT-0 to FT_0 and FT-1 to FT_1. Accepted Change all instances of NCITS to INCITS Accepted Change all instances of "National Committee for Information Technology" to "InterNational" Accepted
Completed in Rev 5.8 Completed in Rev 5.8
Brocade-003
Front Matter
All
Brocade-004
Front Matter
Bob Snively's contact information incorrect
Update to: Robert Snively (T11 Chairman) Brocade Communications Systems, Inc. 1745 Technology Drive San Jose, CA 95110 Phone: (408) 487-8135 Fax: 408-392-6655 E-Mail: rsnively@brocade.com Accepted
Company number
tech/e Sec/table/fig dit locator Page
Comment
Proposed resolution Update to: Steve Wilson (Working Group Chairman) Brocade Communications Systems, Inc. 1745 Technology Drive San Jose, CA 95110 Phone: (408) 487-8128 Fax: 408-392-6655 E-Mail: swilson@brocade.com Change to INCITS XXX-XXXX Change approved date to mm.dd.yy
Response
Status
Brocade-005 Brocade-006 Brocade-007
E E E
Front Matter Front Matter Front Matter
i iv iv
Steve Wilson's contact information incorrect Document number format incorrect Document not yet approved
Accepted Accepted Accepted
Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8
Company number
Comment
Proposed resolution Boilerplate text: "CAUTION: The developers of this standard have requested that holders of patents that may be required for the implementation of the standard, disclose such patents to the publisher. However, neither the developers nor the publisher have undertaken a patent search in order to identify which, if any, patents may apply to this standard. As of the date of publication of this standard, following calls for the identification of patents that may be required for the implementation of the standard, notice of one or more claims has been received. By publication of this standard, no position is taken with respect to the validity of this claim or of any rights in connection therewith. The known patent holder has, however, filed a statement of willingness to grant a license under these rights on reasonable and nondiscriminatory terms and conditions to applicants desiring to obtain such a license. Details may be obtained from the publisher.
Response
Status
E E E
Patent Stmt Copyright Front Matter
v v v
Patent statement needs to be changed to the Have been announced/claimed format Copyright date listed as 199x Extraneous text "INSERT CODE HERE"
Accepted Change copyright date to 2002 Delete text Accepted Accepted
Company number
Comment
Proposed resolution
Response
Status
Brocade-011
Forward
vi
Change to "(This Forward is not Text "(This Forward is not part part of American National of dpANS NCITS xxx-2001) Standard NCITS xxx-xxxx)" Paragraph 2 & bulleted list of Forward do not belong in forward. (Text "Finally, NCITS has approved. faa.dot.gov")
Accepted
Brocade-012
Forward
vi
Delete text
Accepted
E E
Forward Forward
vi vi
Change text to "This standard was developed by Task Group T11.3 of the InterNational Committee for Information Technology Standards (INCITS) during 2000-2002. The standards approval process Dates in paragraph 3 incorrect started in 2002. Last paragraph covered by Patent Statement Delete text
Accepted Accepted
E E
Forward Forward
vi vi
Missing paragraph Signature (Steve Wilson/Murali Rajagopal)
Add paragraph "This standard was processed and approved for submittal to ANSI by the InterNational Committee for Information Technology Standards (INCITS). Committee approval of the Standard does not necessarily imply that all committee members voted for approval. At the time it approved this standard, NCITS had the following members: (to be filled in by INCITS) Accepted Delete text Accepted
Company number
Comment
Proposed resolution
Response
Status
Brocade-017
Forward
vi
Need to add T11 list of representatives
Add "Technical Committee T11 on Lower Level Interfaces, which Reviewed this standard, had the following members:", followed by current membership roster. Accepted Add introduction to document. This should contain an overview of what is contained in the document -- some versions contain clause by clause breakdown, as well as how the document fits into the T11 hierarchy.
Brocade-018
Introduction
vii
Introduction is missing
Accepted
Brocade-019
Page Hdr
1-
Header has improper format. Since Figure 1 is referenced by section 1.1, it should follow that section (or some where near the reference, but before the beginning of section 1.2, even if it means leaving some white space at the bottom of pg 1. Figures should appear near their reference in the text. Comma missing between 16 and Annex F in last line of table
Change to "INCITS T11, Project 1466-D Fibre Channel BB-2, Rev <rev>, <date>" Accepted
E E
1.1 1.2
1-2 1, 3
Move section 1.2 to start after figure 1. Move Figures 2 & 3 to closely follow their reference
Accepted Accepted
Brocade-022
Table 1
Add comma
Accepted
Brocade-023
2.1, 2.2
4, 5
FC-BB-2 references both FCPH documents ([4],[6],[7]) and the FC-FS specification [14]. Only one or the other should be referenced, since the two sets of documents contain Recommend that the FC-PH contradictory information. references be removed.
Accepted
Company number
Comment
Proposed resolution
Response
Status
Brocade-024
2.1, 2.2
4, 5
FC-BB-2 References FC-SW [8], FC-SW-2 [10] and FC-SW3[12]. Since the documents may contain conflicting information, and since each is a full replacement for its predecessor, only FC-SW-3 Delete references to FC-SW and should be referenced. FC-SW-2 Accepted FC-BB-2 References both FCGS-3 and FC-GS-4. Since the documents may contain conflicting information, only one of these documents should be referenced. Delete references to FC-GS-3. Accepted Update reference [17] to version 4, when submitted Accepted Update reference [19] to IETF draft-ietf-ips-security-16.txt, version 16 Sept 2002 Accepted Definition indicates SR applies only to FC-BBW_ATM. Other portions of document indicate that it applies to both SONET and ATM. Need to make document consistent on this point. Note: This is the same definition in FC-BB version of document See comment
E E E
2.1, 2.2 2.2 2.2
4, 5 5 5
Brocade-028
3.1.11
Accepted- made SR and SFC apply to both ATM and SONET Accepted- Changed to prefixed since prepend is not a defined word in most dictonaries Accepted
E E
3.4.4 4.7a
9 17
appended is incorrect term. Switche(s) -- incorrect ()
Change to prepended. Change to Switch(es)
Company number
Comment
Proposed resolution
Response
Status
Brocade-031
4.7a
17
This section indicates that class 2, 3, 4 and F Frames are to be exchanged between FCBBW/FC-BB-2_IP switches. This is a requirement of the FC-BB-2/FCIP protocols, but Class 4 support was not specified in the original FC-BB Update all references to Class 2, specification, though it was 3 & F support to include Class 4 also not prohibited. throughout the document. Accepted QoS Bandwidth guarantee considerations -- Listed as None. Shouldn't this be listed as no FC specific -- may choose to apply IP QoS standard functions for the IP backbone. See comment
Brocade-032
4.7c
17
Accepted - added a sentence from the FCIP draft in support of this.
Brocade-033
4.7e
18
This section indicates that SR is specific to FC-BBW_ATM and SFC is specific to FCBBW_SONET. This issue is Need to determine if SR is inconsistent thru-out the specific to ATM or not and make Accepted- made SR and SFC apply to document, and in BB as well. document consistent. both ATM and SONET A Simple flow control (SFC) Change to ...may optionally be can be optionally used. used. The first mention of class 1 not supported is in this section. Alluded to for first time in section 4.7a on pg 17. This should be made clearer. Recommend that in the introduction, explicitly mention that FC-BB-2 only supports classes 2, 3, 4 & F. Class 1 is not supported. (Resolve as part of Brocade-018)
Brocade-034
4.7e
18
Accepted
Brocade-035
4.8.1
18
Accepted - fixed the problem by adding a note in Clause 4 Completed in Rev 5.8
Company number
Comment Paragraph 2 indicates that SR protocol can be used with either ATM or SONET. Paragraph 3 indicates SFC can be used with either ATM or SONET. Yet 4.7e indicates that SR can only be used with ATM and SFC can only be used with SONET.
Proposed resolution
Response
Status
Brocade-036
4.9.1
18
The text needs to be fixed in one way or the other. (Brocade-028, Brocade-033 both indicate ATM specific but other sections of document indicate otherwise.) BB is not consistent on this point, so need to decide which is the appropriate way to go on this issue. Accepted: See Brocade-033
Brocade-037
4.9.1
18
Suggest new paragraph 2, inserted before current paragraph 2, stating "There are two flow control mechanisms defined for Paragraph 3, Sentence 1: the FC-BBW_ATM and FC"The Simple Flow Control BBW_SONET protocols. They (SFC) and mutually are the Selective Retransmission exclusive with the SR (SR) Protocol and the Simple protocol." Do not believe 'with' Flow Control (SFC) protocol. Accepted. The senetence has been is the proper term here. The two are mutually exclusive." deleted and the paragraph reworded. Paragraph 3, Sentence 2: Need to change word "can" to "may". [Note: If Brocade-037 is accepted, this sentence becomes sentence 1 of the paragraph (current sentence 1 deleted).] See comment Since Clause 6 is common to FC-BBW_ATM and FCBBW_SONET, and Clause 5 is specific to ATM, recommend reversing Clauses 5 & 6. See comment Paragraph 3. Indicates FCBBW_ATM encapsulates class 2, 3 & F frames.
Brocade-038
4.9.1
18
Accepted
Brocade-039
Clause 5,6,
20
Accepted - Made a separate clause for the common message formats, a separate clause for the SR Formats and palced the ATM caluse after the SR Procedures clause. Completed in Rev 5.8
Brocade-040
5.1
20
Need to add class 4 to the list.
Accepted
Company number
Comment Paragraph 5: P4 Indicates that SR is optional, and P5 indicates that SFC is also optional -- e.g. neither SFC or SR need to be used. But there is no way to indicate 'neither' in the BBW header. Paragraphs 8 & 9 -- Since LLC/SNAP comes before the BBW_Header, the order of these two paragraphs should be reversed.
Proposed resolution
Response
Status
Brocade-041
5.1
20
Update paragraph 5 to indicate that if neither SR or SFC is to be used, then still need to set BBW_Header to indicate SFC, but that value of PAUSE = 0 means no flow control. Accepted
Brocade-042
5.1
20
See comment
Accepted
Brocade-043
5.1
20
Assuming SFC is deemed applicable to ATM, the entire paragraph should be changed to read as follows: "When SR is Paragraph 8. "When SR is used, the 4 byte BBW_Header is used the message payload followed by the 4-byte consists of a 4 byte SR SR_Header, which are header. SFC Does not require prepended to the BBW Message a header." This statement is Payload. When SFC is used, the incorrect. When SR is used, SR header is not required, so the the 4 byte BBW_Header is 4-byte BBW_Header is followed by the 4-byte prepended directly to the BBW SR_Header, which are Message Payload." The first prepended to the BBW sentence of the paragraph should Message Payload. When SFC be eliminated completely ("A 4is used, the SR header is not byte BBW_Header is required, so the 4-byte appended..."). If SFC is deemed BBW_Header is prepended not applicable to ATM, then the directly to the BBW Message last sentence of the suggested Payload. text should also be eliminated. Accepted- paragraph rewritten Paragraph 9. The words 'appended at' needs to be changed to 'prepended to'.
Brocade-044
5.1
20
See comment
Accepted - replaced by 'prefixed'
Company number
Comment First paragraph indicates FCBBW_ATM encapsulates class 2, 3 & F frames Bullet 1, Sentence 1: 'When flow control is not used, the BBW appends the two headers to the payload of the FC_BBW message.'
Proposed resolution
Response
Status
Brocade-045
5.2.3
21
Accepted
Brocade-046
5.2.3
21
Change 'appends' to 'prepends'.
Accepted - paragraph rewritten
E E
5.2.3 5.2.3
21 21
Bullet 1: First sentence starts out as "When flow control is not used, the BBW appends", then second sentence indicates "BBW_Header specified the flow control type (SR or SFC). The BBW_Header PAUSE field carries a zero." This is contradictory. Bullet 2: When SFC is used, the BBW appends"
Change to "When flow control is not active, the BBW prepends""BBW_Header specified the flow control type of SFC, with a PAUSE field of zero. This means that no flow control is being requested. In addition, the SR_Header is not included as part of the BBW Accepted - paragraph rewritten message." Change 'appends' to 'prepends'. Change "PAUSE field." to "PAUSE field, and the SR_Header is not included as part of the BBW message." Accepted
Brocade-049
5.2.3
21
Bullet 2: No mention of the SR_Header is made. Bullet 3: "When SR Protocol is used, the BBW appends"
Accepted
Brocade-050
5.2.3
21
Accepted
Company number
Comment
Proposed resolution
Response
Status
Brocade-051
5.2.3
21
Bullet 3: "the two headers to the payload of the BBW message". Strictly speaking, according to table 9 (p. 27), these headers are prepended to the SR BBW Message. In fact, a third header, the SR_Header with format SR_I is inserted between the BBW Header and the BBW Message Payload. Clarify text. Sentences 'The SR Protocol makes the transport of FC Frames themselves are not flow controlled." This is description/selling of SR Protocol. It does not belong here. Delete text Change to The BBW Message consists of the SR_Header followed by the BBW Message Payload" or alternatively "The BBW Message consists of the SR_Header followed by the FC Frame"
Accepted
Brocade-052
5.2.3
21-22
Accepted
Brocade-053
5.2.3
22
Bullet 3, last sentence: "A 4byte SR_Header is appended at the beginning of each SRBBW message "
Brocade-054
5.2.4
22
Paragraph 3, last sentence: "Finally, a 5-byte ATM Cell Header is appended to each Change 'appended' to SAR PDU to form an ATM cell. 'prepended'. Paragraph 3, sentence 4 -Ambiguous sentence: "A minimum bandwidth allocation is recommended for each FCBBW_ATM VC that is used to avoid starvation
Accepted - used the word prefixed
Brocade-055
5.2.6
22
Change to: "A minimum bandwidth allocation is recommended for each FCBBW_ATM VC that is used, in order to avoid starvation
Accepted
Company number
Comment Paragraph 4: Split into two sentences. Indicates that ATM guarantees in order delivery. The requirement that the FC frames must be shipped in order received should be listed in a separate sentence. Need consistency between the two bullets on what is happening at each end. The second bullet mentions stripping SOF/EOF. This is misleading -- not really stripping them, but instead decoding them & converting them back to ordered set format
Proposed resolution
Response
Status
Brocade-056
5.2.6
22
Terminate sentence after "ATM Virtual Connection (VC). Remove the word 'and', and capitalize 'Frames' to begin new sentence.
Accepted
Brocade-057
5.2.7
23
Change Bullet 2 to read: "Processing includes tasks such as removal of the LLC/SNAP, BBW_Header, SR_Header (if present) and decoding of the FC-BBW message." Describe the encoding/decoding process elsewhere.
Accepted - simplified the sentence.
Brocade-058
5.2.8
23
Change this to a reference -- SR Indicates that SR Flow control flow control is currently described Accepted - actually there is no need to is "(described in following in clause 7, which is not the place a reference here and removed the clause)" following clause. reference. Completed in Rev 5.8
Brocade-059
5.2.8
23
Assuming SFC is deemed applicable to FC-BB_ATM, need to add more text to describe SFC. For example, if a message with SFC flow control specified and PAUSE set is receive, and then a subsequent message is received with the PAUSE field set to 0, this indicates that the originator may resume sending traffic at normal rates. On the other hand, if a subsequent message is received with the PAUSE field set to a value, the time is reset to the new value. See comment
Accepted
Company number
Comment
Proposed resolution
Response
Status
Brocade-060
25
Add sentence to 6 indicating that this section applies only to FC-BBW_ATM and FCBBW_SONET. To make it clear to the reader that this section does not apply to FCBB-2_IP. May also want to direct reader to next section that applies to IP (e.g. clause 13) See comment Paragraph 1: '...(SNAP) and a 4-byte BBW_Header field." change 'and' to 'followed by' Add diagram showing the format of a BBW message following paragraph 1.
Accepted - added an Applicapabiliy sub caluse at the begin of each clause Completed in Rev 5.8 Accepted - this whole clause has been reorganized
Brocade-061
6.1
25
Brocade-062
6.1
25
See comment
Accepted
Brocade-063
6.1
25
Paragraph 2: " The encoding for LLC indicates ". This is not the only possible encoding Change to " The encoding for for LLC, only the one that BB-2 LLC of 0xAAAA03 required by is requiring. FC-BB-2 indicates" Move tables 3 & 4 to between paragraphs 3 & 4, so that they follow immediately after where they are referenced. See comment Paragraph 4: Move words 'See Table 6' to end of paragraph, since next sentence describe the contents of table 6. See comment Move tables 5 & 6 to follow paragraph 4, so that they immediately follow the text that references them. See comment
Accepted- paragraph rewritten
Brocade-064
6.1
25
Brocade-065
6.1
25
Brocade-066
6.1
25-26
Company number
Comment
Proposed resolution
Response
Status
Brocade-067
6.1
25
Brocade-068
6.1
26
"If no flow control is desired, simply set the Flow Control Type to SFC and the PAUSE Add sentence after paragraph field to "0". Byte 3 of the BBW_Header should also be 4 or 5 to the effect that if no flow control is desired, simply set to "0", and the SR_Header must not be included in the use SFC with PAUSE value set to 0. BBW Message Payload." Table 5: PAUSE indicates that it is "Applicable to the SR Change to read "Applicable to the Protocol only" SFC Protocol only"
Accepted. Table 6 now clearly states the applicability. Added some of this text.
Accepted
Brocade-069
6.2
26
Section 6.2 indicates that it covers SFC Message formats. The numbers in the table support that. But the text prefacing table 7 does not indicate that this is specific to SFC, but uses a max size of 2148 for the BBW Message Payload. (consistent with SFC). Table 8 shows the structure of the BBW Message Payload with SFC, which is consistent with the section. But, the definition of the BBW Message Payload is never addressed for SR (clause 6.3, 7). Resolution for this issue is 1) Move table 7 to just after described in Brocade-069paragraph 1 of section 6.1 (see Brocade-072. Brocade-062).
Accepted
Brocade-070
6.2
26
See Brocade-069
2) Add new section before section 6.2 describing the BBW Message Payload, and show include table 8. May also want to add to this new section the Accepted - this whole clause has been optional SR_Header. reorganized
Company number
Comment
Proposed resolution
Response
Status
Brocade-071
6.2
26
See Brocade-069
3) Add new section for no flow control, indicating that a BBW message with no flow control consists of a message which follows the formats of table 7 & 8, with no optional SR_Header, Flow Control set to SFC, PAUSE set to 0, and byte 3 of the Accepted in spirit - I have accomplished BBW_Header (do we have a this goal by approriate text in the name for this?) set to 0. rewritten clause Completed in Rev 5.8
Brocade-072
6.2
26
See Brocade-069
4) Change section 6.2 to describe the SFC message formats, indicating that the BBW message consists of message which follows formats of table 7 & 8, with no optional SR_Header, Flow control set to SFC, and PAUSE set to a value, as described in SFC section (which needs to be added). Byte 3 of the BBW_Header needs to be Accepted - clause has be rewritten and set to 0. should no longer be an issue Completed in Rev 5.8
E E
6.3.1 6.3.1
27 27
SR-BBW Message Payload is never defined. The SR_I Message format is defined, which I believe is one form of the SR-BBW message. (not SR-BBW Message Payload) See Brocade-069-Brocade-070 Paragraph 2: The SR_Header define Change "define" to "defines" Table 10: Should "MM:" be "MMMMM:" (to match table header) or "MMM MM" To mimic format?
Accepted - clause has be rewritten and should no longer be an issue Completed in Rev 5.8 Accepted Completed in Rev 5.8
Brocade-075
6.3.1
27
See comment
Accepted
Company number
Comment Table 13: SR_I Description indicates that only class 2, 3 and F frames are supported. Table 13: A note should be added somewhere around Table 13, indicating that the Command/Response bit is indicated in Byte 3 of the BBW_Header. Paragraph 2 indicates that only class 2, 3 and F frames are supported
Proposed resolution
Response
Status
Brocade-076
6.3.1
28
Add Class 4.
Accepted
Brocade-077
6.3.1
28
See comment
Accepted
Brocade-078
6.3.2.1
30
Add Class 4.
Accepted
Brocade-079
6.3.2.1
30
Change Bullets 1 & 2 to something to the effect of replacing the SOF and EOF delimiters with the encoded forms; SOF at the head of the frame and EOF at the end of the frame, where they normally would be found. See comment Bullets 3, 4, 5: 'appending it'. Each of these headers are prepended to the SR-BBW Message Payload, in the order Change 'appending it' to stated. 'prepending it'.
Accepted
Brocade-080
6.3.2.1
30
Accepted - some of these bullets were delted because they were somewhat outside the scope of the SR_I Message Completed in Rev 5.8
Company number
Comment
Proposed resolution
Response
Status
Brocade-081
6.3.2.4
31-32
The description of Selective Reject does not seem to indicate the number of items in the payload. It furthermore does not indicate the maximum number of items that may be listed. While it is unlikely that 1074 N(R) items will be listed, causing the max payload size to be exceeded, a maximum number of items/max payload size should be indicated. See comment
Rejected- there is no maximum number for this specified in the SR protocol. Note that the max payload size of 2152 bytes is not applicable here and hence there is no restriction. (the author of this coment most likely mis took this for the SR_I payload limitations.
Brocade-082
6.3.5
33
Table 16: The first word indicates that it should include "Rejected BBW_Header Field Word 3". The BBW_Header is only 1 word long, unless you add the SR_Header, in which it is two words long. What is supposed to be inserted as the first word of the payload for SR_FRMR? See comment
Accepted- corrected to SR-Header and alsoa dded a Word Column to further make this a little clearer. Completed in Rev 5.8
Company number
Comment
Proposed resolution
Response
Status
Brocade-083
6.3.6.3
35
Clarification needed -- 1) "BBW_Header does not contain one of the defined encodings" What is meant by this? 2) "contains an address field other than the two Domain.Area.PortID of either FC-BBW" -- Where are these 'addresses' found in the message? This is the first mention in the document of a Domain.Area.PortID as related to a BBW Message. Unknown If SR is deemed to be common to both FCBBW_ATM and FCBBW_SONET (see Brocade033, Brocade-036), then this section should follow current section 6, before current section 5. (see Brocade 039)
Accepted
Brocade-084
Clause 7
37
See comment
Accepted
E E
7 7.1
37 37
Suggested text: "When SR flow control is the flow control of choice, but there are no SR messages to be sent, the Flow Control bit will be set to byte will Since SR is not for all be set to 0 for those messages. messages, some messages, Though this is depicted as will go out will a Flow Control meaning SFC flow control, when value set to SFC. Need to add used with a PAUSE value of 0, it description either to Clause 6 actually indicates 'no flow control Rejected - SR is sliding window protocol or clause 7 explaining this. required.' and will always be used once selected. Bullet 1: ...all class 2, 3 & F... Add Class 4. Accepted Completed in Rev 5.8
Company number
Comment
Proposed resolution
Response
Status
Brocade-087
7.2.1
38
Table 14 does not illustrate the different FC-BBW Message command and response field formats. It illustrates the SR_I message format. Think this is trying to reference some of the tables 9-13, and the SR_Header instead of the Change to "Section 6.3 describes Accepted : new correct sub clause will BBW_Header. the SR message formats." be referenced. Refers to an address field which includes whether a message is a command or a response. This is not true of BBW/SR. The indicator of command or response is noted in bit 0 of byte 3 of the BBW_Header. The note following this section also does not apply.
Brocade-088
7.2.2
38
Unknown
Accepted
Brocade-089
7.2.5.3
38
This section references a nonexistent section. Should reference section 6.3.6.3. Depending on resolution to comments against section 6.3.6.3 (See Brocade-083), this section may need to be updated/deleted. See comment The maximum CPSC-PDU size is specified in the first paragraph of text to be 2156. The table indicates that it may be a maximum of 2164. [Determined by summing 2152(max FC frame + SR Update text in paragraph 1 to Header)+4(BBW reference a max CPCS-PDU of Header)+8(LLC/SNAP)] 2164.
Accepted - added correct reference
Brocade-090
8.1
50
Accepted
Company number
Comment
Proposed resolution
Response
Status
Brocade-091
8.1
50
Why is note 2 important? If kept, should the note be expanded to indicate that the BBW Message Payload will always be a multiple of 4 bytes in size? See comment Note 3: "The maximum of 2148 bytes Change to "The maximum of 2148 bytes of BBW Message Payload
Accepted - made this part of the text under CPCS-PAD
Brocade-092
8.1
50
Accepted
Brocade-093
8.1
50-51
Last sentence describes figure11. If SFC is deemed to be SONET specific, this sentence and the figure need to be removed See comment Figure 12 is specific to the SR_I message. Does not show the mapping of the SR control messages. This is fine, but may want to make a clarification to this effect. Paragraph 3, sentence 3 -Ambiguous sentence: "A minimum bandwidth allocation is recommended for each VC that is used to avoid starvation Paragraph 2: "This service matches the requirements of FC Classes 2, 3 and F"
Rejected - SFC has been made common to both ATM/SONET
Brocade-094
8.1
52
See comment Change to: "A minimum bandwidth allocation is recommended for each that is used, in order to avoid starvation
Accepted -
Brocade-095
9.3
53
Accepted -
Brocade-096
9.4
54
Add Class 4.
Accepted
Company number
Comment
Proposed resolution
Response
Status
Brocade-097
9.6
55
SFC is not mentioned in this section. If supported for FCBBW_ATM, then should be added to this section, indicating that SFC is for flow control only, does not have any retry/recovery mechanisms. If not supported in ATM, then need to remove references to SFC from the ATM sections. See comment Paragraph 5: byte-encoded Class 2, 3 or F Fibre Channel Frames Add Class 4.
Accepted - added a Note to indicate that SFC does not have errory recovery support. Also, modified the last paragraph to indicate the usefulness of the SFC/SR protocol and deleted any other secondary information. Completed in Rev 5.8
Brocade-098
10.1
56
Accepted
Brocade-099
10.1
56
Paragraph 6 states: "The SR protocol makes the transport of FC frames between two FCBBW_SONETs reliable." But, SONET, by definition is reliable, assuming that the SONET network is well engineered. Therefore, SR is not needed to make FCBBW_SONET reliable. Make SR applicable to ATM only. Paragraph 6 indicates that SR is optional, and Paragraph 7 indicates that SFC is also optional -- e.g. neither SFC or SR need to be used. But there is no way to indicate 'neither' in the BBW header. Paragraphs 10 & 11 -- Since LLC/SNAP comes before the BBW_Header, the order of these two paragraphs should be reversed.
Rejected - in light of the earlier comments to make SR applicable to both. However, will add the word "more" reliable so as not to diminish the already reliable nature of SONET
Brocade-100
10.1
56
Update paragraph 7 to indicate that if neither SR or SFC is to be used, then still need to set BBW_Header to indicate SFC, but that value of PAUSE = 0 Accepted- made SR and SFC apply to means no flow control. both ATM and SONET
Brocade-101
10.1
56
See comment
Accepted
Company number
Comment
Proposed resolution
Response
Status
Brocade-102
10.1
56
Assuming SR is deemed applicable to SONET, the entire paragraph should be changed to read as follows: "When SR is used, the 4 byte BBW_Header is Paragraph 10. "When SR is followed by the 4-byte used the message payload SR_Header, which are consists of a 4 byte SR prepended to the BBW Message header. SFC Does not require Payload. When SFC is used, the a header." This statement is SR header is not required, so the incorrect. When SR is used, 4-byte BBW_Header is the 4 byte BBW_Header is prepended directly to the BBW followed by the 4-byte Message Payload." The first SR_Header, which are sentence of the paragraph should prepended to the BBW be eliminated completely ("A 4Message Payload. When SFC byte BBW_Header is is used, the SR header is not appended..."). If SR is deemed required, so the 4-byte not applicable to SONET, then BBW_Header is prepended the first sentence of the Accepted- this whole sub clause has directly to the BBW Message suggested text should also be been rewritten to accommodate this Payload. eliminated. and similar comments. Paragraph 11. The words 'appended at' needs to be changed to 'prepended to'. Move Figure 15 to follow reference in section 10.2.1 First paragraph indicates FCBBW_SONET encapsulates class 2, 3 & F frames Bullet 1, Sentence 1: 'When flow control is not used, the BBW appends the two headers to the payload of the FC_BBW message.'
E E
10.1 10.2.1
56 57
See comment See comment
Accepted - consistently using the word prefixed - since prepend is not a proper dictonary word Completed in Rev 5.8 Accepted Completed in Rev 5.8
Brocade-105
10.2.3
58
Accepted
Brocade-106
10.2.3
58
Accpeted
Company number
Comment
Proposed resolution
Response
Status
E E
10.2.3 10.2.3
58 58
Bullet 1: First sentence starts out as "When flow control is not used, the BBW appends", then second sentence indicates "BBW_Header specified the flow control type (SR or SFC). The BBW_Header PAUSE field carries a zero." This is contradictory. Bullet 2: When SFC is used, the BBW appends"
Change to "When flow control is not active, the BBW prepends""BBW_Header specified the flow control type of SFC, with a PAUSE field of zero. This means that no flow control is being requested. In addition, the SR_Header is not Accepted- this whole sub clause has included as part of the BBW been rewritten to accommodate this and similar comments. message." Accepted - this whole clause has been Change 'appends' to 'prepends'. reorganized Change "PAUSE field." to "PAUSE field, and the SR_Header is not included as part of the BBW message."
Brocade-109
10.2.3
58
Bullet 2: No mention of the SR_Header is made. Bullet 3: "When SR Protocol is used, the BBW appends" Bullet 3: "the two headers to the payload of the BBW message". Strictly speaking, according to table 9 (p. 27), these headers are prepended to the SR BBW Message. In fact, a third header, the SR_Header with format SR_I is inserted between the BBW Header and the BBW Message Payload.
Accepted - this whole clause has been reorganized Accepted - using the word prefixed throughout
Brocade-110
10.2.3
58
Brocade-111
10.2.3
58
Assuming SR is deemed applicable to FC-BBW_SONET, Clarify text, otherwise delete paragraph.
Accepted - this whole clause has been reorganized
Company number
Comment
Proposed resolution
Response
Status
E E
10.2.3 10.2.7
58 59
Sentences 'The SR Protocol makes the transport of FC Frames themselves are not flow controlled." This is selling/selling of SR Protocol. It does not belong here, even if SR is deemed applicable to FC-BBW_SONET. Delete text Bullet 2 begins "Processing Change to "Processing the FCthe SR_I message" BBW_SONET message ... Need consistency between the two bullets on what is happening at each end. The second bullet mentions stripping SOF/EOF. This is misleading -- not really stripping them, but instead decoding them & converting them back to ordered set format
Accepted Accepted
Brocade-114
10.2.7
59
Change Bullet 2 to read: "Processing includes tasks such as removal of the LLC/SNAP, BBW_Header, SR_Header (if present) and decoding of the FC-BBW message." Describe the encoding/decoding process elsewhere.
Accepted
Brocade-115
10.2.8
59
Need to add more text to describe SFC. For example, if a message with SFC flow control specified and PAUSE set is receive, and then a subsequent message is received with the PAUSE field set to 0, this indicates that the originator may resume sending traffic at normal rates. On the other hand, if a subsequent message is received with the PAUSE field set to a value, the time is reset to the new value. See comment If SR is deemed to be inapplicable to SONET, then need to delete this section
Accepted Rejected - SR is now made applicable to both ATM and SONET
Brocade-116
10.2.9
59
See comment
Company number
Comment If SR is deemed to be inapplicable to SONET, then delete this figure, otherwise reference somewhere (11.1?) in text. First paragraph on pg 70: "The FC-BB-2_IP Protocol creates Encapsulated FC frames by appending "
Proposed resolution
Response
Status
Brocade-117
11.1
65
See comment
Accepted
Brocade-118
13.1
70
Change "appending" to "prepending"
Accepted - using the word prefixed throughout
Brocade-119
13.2.3.3.5
75
LKA clause cross reference is Correct cross reference, likely to non-existent clause. 13.3.3.2.5.2 SW-3 allocates a range of values for SW_ILSs to be defined by BB-2, but leaves it to BB-2 to define the specific encoded values for SW_ILSs defined by BB-2. BB-2 should add table showing the encoded values of SW_ILSs defined by BB-2 and insure that each SW_ILS has a defined encoded value.
Accepted
Brocade-120
13,15
75-94
Accepted
Company number
Comment
T E
13.2.3.3.5.1 13.2.3.4
75 75
The first sentence in 13.2.3.3.5.1 indicates that LKA is an SW_ILS. By definition, an SW_ILS has a frame type 1 (FT-1), with FC-4 Device Data format. VE_Port LKA in BB-2 has been defined as a FT-0, which is a Link Control. This Link Control is running as Class F. LKA as a link_control frame does not address the issue in a multiconnection FCIP Link, since Class F frames are likely restricted to a single connection in the link, and since there is no payload or reply frame, there is no way to convey information about the status of the other links. Thus, the LKA will be able to determine if a single connection (that which is running the class F frames) is up, but not if the other TCP connections is still up. via the FCIP Well-known Port 3225
Proposed resolution Change the current FC-BB-2 text so that the VE_Port LKA is not a Link Control frame but instead an ILS frame. Assign an SW_ILS encoded value for VE_Port LKA and add appropriate request and response format tables to FC-BB2. Change text to indicate that "VE_Port LKA should be transmitted every K_A_TOV when no data or Link_Control frames have been received on a given FCIP_LINK. It may also be transmitted any time no data or Link_Control frames have not been recieved on any single TCP connection in the FCIP_Link. As part of the payload on the transmit, the connection nonce for each TCP connection that is open on the FCIP_Link should be transmitted. The recipient closes any TCP connections that it has open, and that are not listed (establishment of new TCP connections are permitted). In addition, in the Accept, it sends a list of nonces it does not recognize. The recipient, on Accept, closes any TCP connections that it has open and is listed in the Accept payload (establishment of new TCP connections are permitted). If an Accept is not received, then the originator begins FCIP_Link exception handling, which may include recovery attempts or FCIP_Link termination (e.g. shut Change to "via the FCIP Wellknown TCP Port 3225
Response
Status
Accepted-Elizabeth's (02-647v4) LKA proposal will resolve all comments related to LKA Accepted- See Andiamo-003
Company number
Comment
Proposed resolution
Response
Status
Brocade-123
13.2.3.5.4
77
Brocade-124
13.3.3.2.5.2
82
Delete reference to FCsec. This term is undefined and will not be used in FC-SP. See comment Accepted Change the current FC-BB-2 text so that the B_Access LKA is not a Link Control frame but instead an ILS frame. Assign an SW_ILS encoded value for B_Access LKA and add appropriate request and response format tables to FC-BB2. Change text to indicate that "B_Access LKA should be transmitted every K_A_TOV when no data or Link_Control frames have been received on a given FCIP_LINK. It may also be The first sentence in transmitted any time no data or 13.3.3.2.5.2 indicates that LKA Link_Control frames have not is an SW_ILS. By definition, been recieved on any single TCP an SW_ILS has a frame type 1 connection in the FCIP_Link. As (FT-1), with FC-4 Device Data part of the payload on the format. B_Access LKA in BB- transmit, the connection nonce 2 has been defined as a FT-0, for each TCP connection that is which is a Link Control. This open on the FCIP_Link should be Link Control is running as transmitted. Class F. LKA as a link_control The recipient closes any TCP frame does not address the connections that it has open, and issue in a multi-connection that are not listed (establishment FCIP Link, since Class F of new TCP connections are frames are likely restricted to a permitted). In addition, in the single connection in the link, Accept, it sends a list of nonces it and since there is no payload does not recognize. The or reply frame, there is no way recipient, on Accept, closes any to convey information about TCP connections that it has open the status of the other links. and is listed in the Accept Thus, the LKA will be able to payload (establishment of new determine if a single TCP connections are permitted). connection (that which is If an Accept is not received, then running the class F frames) is the originator begins FCIP_Link up, but not if the other TCP exception handling, which may connections is still up. include recovery attempts or Accepted - See Brocade-121
Company number Brocade-125
tech/e Sec/table/fig dit locator Page E 15.5.2 98
Comment Bullet 3: FC-FS is reference #14, not 6
Proposed resolution Correct cross reference to FCFS.
Response Accepted
Status Completed in Rev 5.8
Brocade-126
13.3.3.2.5.3
83-84
Transitions P4:P1, P4:P2 and P4:P3 are not defined, but are Add definitions for these state depicted in figure 28. transitions.
Accepted-
Brocade-127
14.2
92
Connection Usage Code: Indicates that the intended usage is still TBD. The description of the ASF SW_ILS is not clear that the ASF payload will be the echo of the FSF received on the previously authenticated connection, as required by FCIP 9.1.2.3. ASF Accept Payload -- why 8 bytes of reserved payload?
Change this paragraph to read "The Connection Usage Code field is to contain Fibre Channel defined information regarding the intended usage of the connection. The FCIP Entity uses the contents of the Connection Usage Flags and the Connection Usage Code fields to locate appropriate QoS settings in the in the shared database of TCP connection information and apply those settings to a newly formed connection. No values have been defined for this field at this time, so this field must be set to 0." Accepted - slight changes in wording. A diagram indicating the relationship between the FSF and the ASF should be added, and the text should be made more explicit to demonstrate this relationship. Accepted- see McDATA-041 Remove 8 bytes reserved payload.
Brocade-128
15.2.2.1
93-94
Brocade-129
15.2.2.1
94
Accepted
Draft Upadted
Brocade-130
A.2
103
The table of FC-BB-2 SOF OS codes needs to be updated to match the codes specified by the IPS FC Frame Encapsulation Document, section 5.3 See comment
Accepted
Company number
Comment
Proposed resolution
Response
Status
Brocade-131
A.2
103
The table of FC-BB-2 EOF OS codes needs to be updated to match the codes specified by the IPS FC Frame Encapsulation Document, section 5.3 See comment Since both references in F.2 are references for BB-2 in general, the document references should be used instead of having a separate reference section in the annex. Bookmarks make navigation much much easier, annexes in the TOC would be nice, as would figure numbers in the LOF and table numbers in the LOT. Use FC-BB-2_ATM and FCBB-2_SONET rather than FCBBW_ATM and FCBBW_SONET as used in the rest of the document. Do I have standard compliant FC-BB-2_IP device if the external FC ports of my box are F_Ports instead of E_Ports? If SW-3 supercedes SW-2 why mention SW-2 at all? my box are F_Ports instead of E_Ports? Somewhere an "FC Fabric Entity" needs to be defined. Even if it simply references FCFG.
Accepted
Brocade-132
118120
Delete section F.2 and replace references in section F.1 with corresponding document reference numbers.
Rejected - was told during BB standardization by INCITS that this way the correct way. BB prior to version 4.7 orginally had one one set of references.
CNT-001
TOC/LOF/LO T
Accepted- will include in the next Rev
CNT-002
Figures 4-6
Accepted- I believe the comment meant to say just the opposite: use FCBBW_ATM and FC-BBW_SONET rather than FC-BB-2_ATM and FC-BB2_SONET Completed in Rev 5.8
CNT-003
General
Accepted- Yes- Fig. 23 and 25 updated to reflect this Completed in Rev 5.8
CNT-004
General
Accepted: For second part of the comment see Response to CNT-003
CNT-005
General
Accepted - term no longer used. See also Andiamo- 002
Company number
Comment
Proposed resolution
Response
Status
CNT-006 CNT-007
E E
1.1 2.3 and Annex F
Reads "FC Over TCP/IP Network mapping emphasizes on the IP Network", should remove the "on", or change "on the" to "an" and reads "The major part of FC-BB-2 is the addition", could read "The major difference between FCBB-2 and FC-BB is the addition" The current rev of the security draft is 16 Would seem less confusing to define FC-BBW_SONET as used throughout the document rather than FCBBW_SONET/SDH SR can be applied with FCBBW_SONET as well Says interaces, should be interfaces. Might want to add EBP and LKA. Might want to add B_Access End of second sentance should read "both of these models." In each clause, the last paragraph, why the caveat? Should explain exactly what is "the BSW function." Note that Class 4 is not always mentioned when the document is talking about the supported classes.
Accepted Accepted
CNT-008 CNT-009 CNT-010 CNT-011 CNT-012
E T E E E
3.1.7 3.1.11 3.4.13 3.6.1.1 3.6.1.4
Accepted Accepted- corrected Accepted Accepted Accepted
Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8
CNT-013
4.1
Accepted
CNT-014 CNT-015
E E
4.2, 4.4 4.4
Accepted See Andiamo-001
CNT-016
4.7, bullet a
Accepted
Company number
Comment The FC-BB-2 entity has no way of ensuring a frame will traverse the internet within any specified TOV. Computing IP Network transmit time is nontrivial. SR (as well as SFC) may be used with either FCBBW_ATM or FCBBW_SONET interfaces. ISL Flow Control Mode of R_RDY needn't be mandated. Initialization should be described for legacy FC-BB devices as well. Something along the lines of initializing the WAN side before beginning port state initialization on the FC side. Similar to FC-BB-2 devices. Need a space between "functions." and "This" Need a space between "payload." and "The" Document states that "The procedures to be followed on receipt of Set Mode (SR_SM command are specified in 7.2.5.6, Receiving an SR_SREJ response message." Should read "SR_SREJ message" The document talks about total path delay never exceeding R_A_TOV. That should be E_D_TOV.
Proposed resolution
Response
Status
CNT-017
4.7 bullet b
Accepted-First item will state that BB-2 will not admit stale frames into the FC network. Second item will be deleted. Completed in Rev 5.8
CNT-018
4.7 bullet e
Accepted
CNT-019
4.8.1 bullet 2
Accepted
CNT-020 CNT-021 CNT-022
E E E
4.8.2 6.3.1.3 6.3.2.1
Draft Upadted Completed in Rev 5.8 Completed in Rev 5.8
CNT-023
6.3.2.4
Rejected- this is the sub clause title as written and also the protocl as defined by LAPB Accepted: Path Delay will never exceed 1/2 E_D_TOV.Also see McData035 Completed in Rev 5.8
CNT-024
9.2, 12.1
Company number
Comment There is no value in mandating a flow control mode between an FC switch and FC-BB-2_IP device. Need a space between "connection." and "The" Its not clear what is needed to fully identify a FCIP Link Originator, Acceptor or an FCIP Link; i.e. all the items or one of the items listed Redundant information as draftietf-ips-fcencapsulation-08.txt states the same in greater detail. Redundant information as draftietf-ips-fcencapsulation-08.txt states the same in greater detail. R_RDY flow control is not the only flow control a B_Port need use. Redundant information as draftietf-ips-fcencapsulation-08.txt states the same in greater detail. And what is intended by "A TBD." Reads "and it associated virtual ISL," should read "its"
Proposed resolution
Response
Status
CNT-025 CNT-026
T E
13.1 13.1
Accepted - verbage indicating that E, VE, and B_Ports operate as defined in FC-SW-3 added in Clause 4. Accepted
CNT-027
13.2.3.3.4
Accepted
CNT-028
13.2.3.5.2.1
Rejected: This brief explanation is beneficial
CNT-029
13.2.3.5.2.2
Rejected: This brief explanation is beneficial
CNT-030
13.3.2
Accepted
CNT-031 CNT-032
E E
14.1.1 14.2.1
Accepted Accepted- see Brocade 127
CNT-033
15.2.2.1
Accepted
Company number
Comment
Proposed resolution
Response
Status
CNT-034
15.2.2.3
Does FC-BB-2 care which order authentication is performed? It would make things a little more "backward compatible" if the B_Access authenticates with its peer then the individual switches and would agree with the steps outlined in Clause 15.3.1 Step 8 indicates that link cost determination is described in Clause 13.2.3.2.1 yet that clause doesn't indicate a recipe to determine link cost. 2 items appear to be striked out - is the intent to leave them in the document? This clause talks about switch requirements. How does a switch attached to a B_Port deside which Virtual ISL to use? ISL Flow Control Mode of R_RDY needn't be mandated. References the letter "a" in the text when describing the alpha symbol in Figure B.1 References the letter "b" in the text when describing the beta symbol in figure B.1
Rejected - Overtaken by events
CNT-035
15.3.1, step 8
Accepted: Editor to provide verbage. (e.g. link cost is implementation specific) Accepted: The struck items have been removed
CNT-036
15.3.4.1
CNT-037
15.3.4.2
Accepted - Clause removed. See ENDL177 Completed in Rev 5.8
CNT-038
15.4
Accepted
CNT-039
Annex B.2.1
Accepted- changed to alpha symbol
CNT-040
Annex B.2.2
Accepted- changed to beta symbol
Company number
Comment The phrase "but eliminates the effect of gaps." is inaccurate. 1point CDV is a measurement, a negative value correspond to gaps but cannot eliminate them. The last sentence reads poorly, "This service mostly closely..." rather than "This service most closely..."
Proposed resolution
Response
Status
CNT-041
Annex B.2.2
Accepted- new wording extracted verbatim from ATM Forum's Traffic Management Spec.
CNT-042
Annex B.7
Accepted
CNT-043 CNT-044 CNT-045
T E E
Annex D Annex F Annex F.2
First paragraph reads "parameters.Note", needs a space. The math in D.2 and D.3 are incorrect. They should read. D.2 W = ((155520000 * (10ms + 4ms))/ (8 * 2136 bytes)) = 127 D.3 T1 = ((((127 * (8 * 2136 bytes)) / 155520000) + 5ms) + 5ms) = 24ms + 1ms The table is labeled "D" should that not be "F". Why does an annex need special references?
Accepted Accepted Rejected- ISO Rules
ENDL-001
Global
The ISO style guide for cross references within a standard specifies a format containing just the subclause number (i.e., '15.2.2' not 'Clause 15.2.2'). The sole exception is for clauses that do not include a period in the clause number (i.e., 'clause 5' not '5').
Some cross references already use this format. Global adoption of this practice now, will greatly simplify the transition to ISO standard later.
Accepted
Company number
Comment The the extent possible, this standard would be easier to read if all references took the form 'FCIP [16]' instead of 'IETF standard [16]' or '[16]'. If possible, every table that continues on two or more pages should have a title and column headers on every continuation page. Better still, the titles should indicate somehow that the table is continued. Only one of 'Switch Fabric ILS', 'ILS', or 'SW_ILS' should be used consistently. The last usage appears to be the most common. NCITS [s/b] INCITS National Committee for Information Technology Standards [s/b] InterNational Committee for Information Technology Standards Use either 'Phone: (xxx) xxxxxxx' or '(xxx) xxx-xxxx' not both. Given the notation used for FAX numbers, it would appear that 'Phone: (xxx) xxxxxxx' should be preferred. [two instances] Remove revision history before Public Review.
Proposed resolution
Response
Status
ENDL-002
Global
Accepted
ENDL-003
Global
Accepted
ENDL-004 ENDL-005
E E
Global Global
Accepted Accepted
ENDL-006
Global
Accepted
ENDL-007 ENDL-008
E E
i ii
Accepted Accepted
Company number
Comment The dpANS sent to Public Review should not have change bars.
Proposed resolution
Response
Status
ENDL-009
viii
Accepted
ENDL-010
1.1, 1st p after dashed list, s 2 1
The FC over ATM and SONET Network mappings layer on the ATM and SONET backbone technologies, resulting in the FC-BBW_ATM and FC-BBW_SONET specifications that map directly to physical connections. The FC Over TCP/IP Network mapping layers on the IP Network, resulting in the FCBB _IP specification that maps to a logical connection.
Accepted
ENDL-011 ENDL-012 ENDL-013 ENDL-014 ENDL-015
E E E E E
1st p after dashed list, s 3&s4 1 Clause 2, p 1, s 1 4 3.1.4 3.1.12 3.2.1 6 6 6
[Delete] FC-BB-2 makes use of the previously defined FCBB standard [9] for the FCBBW_ATM and FC BBW_SONET specifications. which [s/b] that which [s/b] that which [s/b] that (two instances) can [s/b] may
The major part of FC-BB-2 is the addition of the FC-BB-2_IP specification which makes use of the IETF specification [16]. [Since FC-BB-2 contains all the text that was present in FC-BB, no discussion of the relationship between the two is necessary. Doubtless, the folks working on the GFP mapping would take umbrage at the description of FCBB-2_IP as the 'major' addition in FC-BB-2.] Accepted Accepted Accepted Accepted Accepted
Company number ENDL-016 ENDL-017 ENDL-018
tech/e Sec/table/fig dit locator Page E E E 3.2.2 3.2.10 3.2.15 6 7 7
Comment which [s/b] that which [s/b] that which [s/b] that [Delete] Can be used interchangeably. [Contains no useful information.] which [s/b] that can [s/b] may [two instances] 3.2 contains a definition of ATM, 3.3 contains a definition of SONET, so it seems natural that 3.4 should contain definitions of FCIP and TCP/IP. [Do not italicize] Encapsulated FC Frame: which [s/b] that The FCIP Data Engine glossary entry appears to be in the wrong place. Between the 3.4.13 and 3.4.14 would be more appropriate. which [s/b] that
Proposed resolution
Response Accepted Accepted Accepted
Status Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8
ENDL-019 ENDL-020 ENDL-021
E E E
3.2.18 3.3.9 3.3.10 s 2
7 9 9
E E E
3.4 3.4.4 3.4.7
9 9 10
ENDL-025 ENDL-026
E E
3.4.7 3.4.13 3.5, 2nd & 3rd dashed entries, s 2 && p 9 & p 10, s 1 3.6.1.1 3.6.1.4
10 10
Accepted Accepted
E E E
11 12 13
which [s/b] that [four instances] FCIP Add ', reference [16]' to end of acronym definition FCIP Add ', reference [16]' to end of acronym definition
Company number
Comment add acronym IETF Internet Engineering Task Force (www.ietf.org) CSM should be the first acronym listed in this sub clause. Add an acronym entry for RFC. can [s/b] may which [s/b] that
Proposed resolution
Response
Status
ENDL-030
3.6.1.4
13
Accepted
ENDL-031 ENDL-032 ENDL-033 ENDL-034
E E E E
3.6.1.4
13
Accepted Accepted Accepted Accepted
Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8
3.6.1.4 13 4.7, 1st p on pg 18 4.8.1 18
E E E
4.8.1, 2nd dashed entry, s1 18 4.9.1, p 2, s 4 18 4.9.1, p 3, s 2 18
which indicates [s/b] indicating which [s/b] that can [s/b] may
Accepted Accepted Accepted - this paragraph has been rewritten
ENDL-038
4.9.1, 3rd & 8th p after fig 8, s 2 20 4.9.1, 4th p after fig 8, s 1 20 5.2.3, 1st p on pg, s 5 22 5.2.4, p 1, s 2 22 5.2.7, dashed list entries 23 5.2.10, p 1, s 1 23 6.3.1, 1st p after table 9, s1 27
can [s/b] may [two instances]
Accepted - one instance because of paragraph restructing (Believe the intended Clause was 5.1 not 4.9.1) Rejected - second instance - use of the word 'may' is stylistically akward Completed in Rev 5.8 Accepted- But I believe Clause 5.1 was intended Completed in Rev 5.8 Accepted- this paragraph has been written. Completed in Rev 5.8 Accepted Completed in Rev 5.8
E E E
which [s/b] that which indicates [s/b] indicating can [s/b] may which [s/b] that [three instances] which [s/b] that
ENDL-042 ENDL-043
E E
Accepted Accepted
ENDL-044
which [s/b] that
Accepted
Company number
tech/e Sec/table/fig dit locator Page 6.3.1.1 & 6.3.1.2, p 1, s 2 29 6.3.1.5, p 1, s 2 29 6.3.1.7, p 1, s 2 30 6.3.3, p 1, s 1 32 6.3.5, p 1 & p 6, s 1 33 6.3.5, 1st p after dashed list, s 1 33 6.3.5, Table 16, bit 66 34 6.3.6, p 1, s 1 & s 2 && 6.3.6.2, p 2, s 1&s2 34 6.3.6.2 1st p on pg, s 1 && 6.3.6.2.2, p 2, s 1 && 6.3.6.3, p 1, s 1&s2 35 7.1, p 1, s 2 37 7.1, 1st p on pg, s 1 38 7.2.4.1, p 2, s 2 39 7.2.5, p 1, s 1 41 7.2.6.1, p 1, s 1 46 7.2.7.2, p 2, s 2 47
Comment
Proposed resolution
Response
Status
E E E E E
which [s/b] that [two instances] can [s/b] may can [s/b] may which [s/b] that which [s/b] that [two instances]
Accepted Accepted Accepted Accepted Accepted
ENDL-050 ENDL-051
E E
must [s/b] shall must [s/b] shall
Accepted Accepted
ENDL-052
which [s/b] that [four instances]
Accepted
ENDL-053 ENDL-054 ENDL-055 ENDL-056 ENDL-057 ENDL-058 ENDL-059
E E E E E E E
which [s/b] that [four instances] which [s/b] that which [s/b] that can [s/b] may which [s/b] that which [s/b] that can [s/b] is able to
Accepted Accepted Accepted Accepted Accepted Accepted Accepted
Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8
Company number ENDL-060
tech/e Sec/table/fig dit locator Page 7.2.7.3, 3rd p E on pg, s 3 48 7.2.8.2, p 2, s 1 && p 4 s 1 48
Comment must [s/b] shall
Proposed resolution
Response Accepted
ENDL-061
must [s/b] shall [two instances] According to the ISO style guide notes are not allowed to contain requirements. Either remove the 'shall' from this note, or change the note to part of the body text.
Accepted
ENDL-062
7.2.8.2, p 3 (note), s 1 8.1, p 3, s 2 && p 5, s 3 && note 3 after table 17, s 2 9.3, p 1, s 1 9.4, p 2, s 1 9.6, p 1, s 3
48
Accepted
E E E E
50 53 54 55
can [s/b] may [three instances] can [s/b] may which [s/b] that which [s/b] that
Accepted Accepted Accepted Accepted Accepted- this paragraph has been rewritten.
ENDL-067
10.1, 3rd p after fig 14, s 2 56 10.1, 4th p after fig 14, s 1 10.1, 1st p on pg, s 2 10.2.3, last p, s5 10.2.3, last p, s6
can [s/b] may
E E E E
56 57 58 58
which [s/b] that can [s/b] is able to be which [s/b] that which indicates [s/b] indicating
Accepted Accepted- substituted can with may Accepted - paragraph rewritten Accepted Accepted- substituted with may to be consistent with an earlier and similar comment from ENDL
ENDL-072
10.2.4, p 1, s 2 58
can [s/b] is able to be
Company number
tech/e Sec/table/fig dit locator Page 10.2.4, p 4, s 1 && last p on pg s 1 58 10.2.7, both dashed entries, s 1 59 10.2.10, p 1, s1 60 11.1, p 3, s 4 61 11.1, last p on pg, s 1 62 11.1, 1st p after dashed list, s 1 63 11.2, 1st p on pg, s 3 & s 4 67 11.2, 1st p on pg, s 3 67
Comment
Proposed resolution
Response
Status
ENDL-073
which [s/b] that [two instances]
Accepted
E E E E
which [s/b] that [two instances] which [s/b] that can [s/b] may must [s/b] shall [three instances]
ENDL-078
must [s/b] shall
Accepted
ENDL-079 ENDL-080
E E
must [s/b] shall [two instances] which [s/b] that All the other fonts used in this standard are san-serif. The font in this figure is a serif font. The smallest font size allowed in an ANSI standard is 9 pt. The following text is in a 7 pt font: '(Section, Line, Path)'. B-Port or E_Ports [s/b] B_Ports or E_Ports
Accepted Accepted
ENDL-081
11.2, Figure 20
67
Accepted
ENDL-082 ENDL-083
E E
11.2, Table 21
67
Accepted Accepted
13.1, p 2, s 1 69 13.1, 3rd p after fig 22, s 1 69 13.1, 3rd p after fig 22, s 2 69
ENDL-084
which is [s/b] that are
Accepted
ENDL-085
can [s/b] may
Accepted
Company number
tech/e Sec/table/fig dit locator Page 13.1, 4th p after fig 22 (note), s 1 13.1, 4th p after fig 22 (note), s 1
Comment a FC-BB-2_IP [s/b] an FC-BB2_IP one FC-BB-2_IP [s/b] one FCBB-2_IP device The usage of bold text for 'Encapsulated FC Frames' makes no sense and should be removed. retaining their SOF/EOF identities. [s/b] retaining their SOF/EOF identities in the Encapsulated FC Frame. a similar way [s/b] the same way Control.The TCP [s/b] Control. The TCP All other instances of 'Encapsulated FC Frames' are italicized. Why not this one? which [s/b] that clauses [s/b] sub clauses [see 13.2.3.1] which [s/b] that The font size of 'For more details on ... SW-3 [12].' appears to be smaller than the rest of the paragraph. VE_Port' and 'FCIP_LEP' should not be bold, like the second occurrence of 'FCIP_LEP'. FC/FCIP Identifier' should not be bold.
Proposed resolution
Response
Status
ENDL-086
69
Accepted
ENDL-087
69
Accepted
ENDL-088
13.1, 1st p on pg, s 1 70
Accepted
ENDL-089 ENDL-090
E E
13.1, 1st p on pg, s 2 70 13.1, 2nd p on pg, s 2 70 13.1, 4th p on pg, s 1 & s2
Accepted Accepted Accepted - added some clarity to this sentence and previous sentence.
ENDL-091
70
ENDL-092 ENDL-093
E E
13.1, 4th p on pg, s 3 70 13.2.1, p 1, s 1 70 13.2.1, 1st p after list, s 1 70 13.2.3.1, p 1, s1 70
Accepted- Italics removed in all cases Accepted
ENDL-094 ENDL-095
E E
Accepted Accepted
ENDL-096
13.2.3.1, 1st list entry, s 2 72
Accepted
ENDL-097 ENDL-098
E E
13.2.3.3.2, p 1, s 2 73 13.2.3.3.2, p 5, s 1 73
Accepted Accepted
Company number
Comment The following should be deleted: 'with the help of a Forwarding Table (see also Clause 13.2.3.2).' An FCIP Entity has no knowledge whatsoever about the Forwarding Table. main components [s/b] interface points If I understand the italics usage rules, in 'A FCIP Link Originator or FCIP Link Acceptor is fully identified by:' the following should be italicized 'FCIP Link Originator' and 'FCIP Link Acceptor' but 'fully identified' should not be italicized.
Proposed resolution
Response
Status
ENDL-099
13.2.3.3.3, p 1, s 1 73 13.2.3.3.3, 1st p on pg, s 1 74
Accepted
ENDL-100
Accepted
ENDL-101
13.2.3.3.4, 2nd p after dashed list, s 3 74 13.2.3.3.4, 1st p after 1st a,b,c list, s 1 74 13.2.3.3.4, 1st p after 1st a,b,c list, s 1 74
Accepted
ENDL-102
Do not italicize 'uniquely'. we only require [s/b] the following are required [at a minimum get rid of the 'we'] SW_ILS [s/b] SW_ILSs [three instances] [See 16.5 for the precedent for making acronyms plural in this way.] The smallest font point size allowed in an ANSI standard is 9 pt. The text 'Virtual ISL:Class...Class 2/3/4 Frame' is in an 8 pt font.
Accepted
ENDL-103
Accepted
ENDL-104
13.2.3.3.5, p 1, s 1 & s 2 74
Accepted
ENDL-105
13.2.3.3.5, Fig 25
75
Accepted
Company number ENDL-106 ENDL-107
tech/e Sec/table/fig dit locator Page 13.2.3.3.5.1, E p 2, s 2 75 13.2.3.4, p 1, E s2 75 13.2.3.5.2.1, p 1, s 3 76
Comment connection is down [s/b] connection is inoperative ISL/FCIP Link [s/b] Virtual ISL/FCIP Link the entering FC Frame [s/b] an entering Class F FC Frame [Add the following new sentence at the end of the paragraph] 'If no synchronized time stamp value is available to accompany an entering Class 2, 3, or 4 FC Frame, the frame should not be delivered to the FCIP_DE.
Proposed resolution
Status Completed in Rev 5.8 Completed in Rev 5.8
ENDL-108
Accepted
ENDL-109
13.2.3.5.2.1
76
Accepted
ENDL-110
13.2.3.5.4, 3rd p after a,b list 13.2.3.5.4, 3rd p after a,b list, s 3 13.3.1, p 1, s 1 13.3.1, p 2 (note), s 1 13.3.3.1, p 1, s 1
77
[Insert the following between the 1st and 2nd sentences] 'This mechanism works in concert with the FC-SP Virtual ISL authentication mechanism, transacting the Class F requests and responses over a previously authenticated TCP connection.' other FCIP security mechanisms [s/b] other FC-SP and FCIP security mechanisms which [s/b] that Delete the following: 'tends to be brief and' which [s/b] that 'B_Access' should not be bold. [see similar wording in 13.2.3.3.1.]
Accepted- See McData-041
T E E E
77 78 78 78
Accepted- See McData-041 Accepted Accepted Accepted
ENDL-115
13.3.3.2.1, p 1, s 1 78
Accepted
Company number
tech/e Sec/table/fig dit locator Page 13.3.3.2.2, p 1, s 2 & s 3 & s4&s5 13.3.3.2.3, p 1, s 2 13.3.3.2.4, p 3, s 1 13.3.3.2.5, p 1, s 1
Comment
Proposed resolution
Response
Status
E E E E
78 79 80 80
B_Access [s/b] B_Access portal [four instances] B_Access [s/b] B_Access portal 'fully identified' should not be italicized. B_Access' [s/b] B_Access portals SW_ILS [s/b] SW_ILSs [two instances] [See 16.5 for the precedent for making acronyms plural in this way.] The smallest font point size allowed in an ANSI standard is 9 pt. The text 'B_Access Virtual ISL:Class...Class 2/3/4 Frame' is in an 8 pt font. B_Access [s/b] B_Access portal [two instances] EBP exchange parameters must be completed [s/b] EBP SW_ILS shall be completed ['EBP exchange parameters' is redundant phrasing and 'must' is a dirty word in standards.]
Accepted- one more instance also corrected Accepted Accepted Accepted
ENDL-120
13.3.3.2.5, p 1, s 1 & s 2 80
Accepted
ENDL-121
13.3.3.2.5, Fig 27
80
Accepted
ENDL-122
13.3.3.2.5.1, p 1, s 1 80
Accepted
ENDL-123
13.3.3.2.5.1, p 1, s 2 80 13.3.3.2.5.1, 1st p after table 21, s 1 81 13.3.3.2.5.1, 5th p after table 21, s 1 81
Accepted
ENDL-124
name [s/b] world wide name
Accepted- but replaced it with Port_Name
ENDL-125
contains [s/b] shall contain
Accepted
Company number
Comment Add a definition for the Responder Interconnect_Port_Name field.
Proposed resolution
Response
Status
ENDL-126
13.3.3.2.5.1 82 13.3.3.2.5.2, p 1, s 1 82 13.3.3.2.5.2, p 2, s 2 82
Accepted
ENDL-127
'LKA' should not be bold. connection is down [s/b] connection is inoperative [Insert the following between the subclause heading and fig 28] 'The B_Access initialization state machine is shown in Fig. 28.' Is this blank page necessary? which consists [s/b] consisting
Accepted
ENDL-128
Accepted
E E E
13.3.3.2.5.3 83 13.4 86
Accepted Accepted - removed blank page Accepted
14.1, p 1, s 2 87
ENDL-132
14.1, Table 25
87
Table 25 should show that 4byte words are used in the FC frame encapsulation to contain the SOF and EOF representations. Essentially, 14.1.2 should be incorporated in table 25 with a note that the structure of the 4-byte SOF and EOF values can be found in [18]. [Move the note to the beginning of the subclause and change it to read] 'NOTE If there is any discrepancy between statements in this sub clause and FC Encapsulation [18] then FC Encapsulation prevails.'
Accepted
ENDL-133
14.1.1
87
Accepted- Note discarded but text retained. see also HP-045
Company number
Comment for FCIP Protocol assigned by IETF [18] is value 1.[s/b] for the FCIP Protocol is value 1.[The FCIP Protocol# value is assigned by IANA not by IETF [18], but attempting to describe that here is not useful.]
Proposed resolution
Response
Status
ENDL-134
14.1.1, 2nd p after table 26, s 1
88
Accepted
ENDL-135
14.1.1, Table 27 and the p's that describe it 88
Since this standard concerns itself with only the FCIP encapsulation, there are no 'protocol specific' fields in the FCIP header. The contents of table 27 should be embedded in table 26 and the field descriptions should remove all mention of 'protocol specific'. Table 28 should be removed because the description is so inadequate as to be confusing. [Change the description of the Flags bits to] 'For FC-BB-2_IP Protocol the Flags bits shall be zero.' [Remove table 29 and the CRCV description.] 14.1.2 should be incorporated in table 25.
Accepted
ENDL-136
14.1.1, Table 28
89
Accepted
ENDL-137 ENDL-138
E E
14.1.1, 1st p after table 28, table 29, & CRCV description 89 14.1.2 90
Accepted Accepted
Company number
Comment The note after table 30 is incorrect in that tables A.3 and A.4 define byte representations for SOF and EOF codes. No mention is made of how the 4-byte SOF/EOF codes used by FCIP are formed. Replace the note with a reference to [18]. 208 [s/b] 48 [Move the note to the beginning of the subclause and change it to read] 'NOTE If there is any discrepancy between statements in this sub clause and FCIP [16] then FCIP prevails.'
Proposed resolution
Response
Status
ENDL-139 ENDL-140
E E
14.1.2, Note 90 14.2, Table 31, row 2 90
Accepted. Accepted
ENDL-141
14.2.1
90
Accepted- Note discarded but text retained. See HP-046
ENDL-142
14.2.1, 1st & 2nd p after table 32 91 14.2.1, 2nd p after table 32
Do not italicize 'generates'. [two instances] FSF [s/b] FCIP Special Frame [like the preceding paragraph]
Accepted
ENDL-143
91
Accepted
ENDL-144
14.2.1, Connection Usage Flags description 91
The bit names in the connection usage flags and the description of those bits should be reworded in terms of Class 2, Class 3, Class 4, and Class F. FCIP cannot use those terms because they cannot be defined in the IETF context. However, this standard already uses the terms liberally. So, use them here.
Accepted
Company number
Comment [Change the description of the Connection Usage Code field to] 'The Connection Usage Code field shall contain zero.' Add a description of how the K_A_TOV field is used by VE_Port and by B_Access portals. The first row in Fig 30 gives the misimpression that FC Frames include a 4-byte encoded SOF and EOF. The fact that the SOF and EOF are 4-byte encoded should be moved to the second row of the table (i.e., to the FC Encapsulation row). it associated Virtual ISL [s/b] its associated Virtual ISL [replace] 'The FC Entity shall respond ... for the first TCP connection.'[with] If FC-SP authentication procedures are not being applied to the Virtual ISL, the FC Entity shall respond to the FCIP Entity indicating that the new TCP connection is authentic. added. [s/b] added using a TCP connection in the Virtual ISL that has already been authenticated.
Proposed resolution
Response
Status
ENDL-145
14.2.1, 2nd p on pg
92
Accepted: See Brocade-127
ENDL-146
14.2.1, 4th p on pg 92
Accepted - See Brocade -121
ENDL-147
14.3, Fig 30 92 15.2.2.1, p 1, s 1
Accepted
ENDL-148
93
Accepted
ENDL-149
15.2.2.1, starting at 1st p after 1st a,b,c list 93
Accepted
ENDL-150
15.2.2.1, 1st p on pg 94
Accepted
Company number
Comment
Proposed resolution
Response
Status
ENDL-151
15.2.2.2, p 1, s 3
94
These two VE_Ports and their parent entities are authenticated using the mechanisms described in FCSP [15]. [s/b] For the first TCP connection in a Virtual ISL, these two VE_Ports and their parent entities are authenticated using the mechanisms described in FCSP [15]. Subsequent TCP connections in the Virtual ISL are authenticated using the mechanism described in 15.2.2.1. B_Access authentication starts with ... [s/b] For the first TCP connection in a B_Access Virtual_ISL B_Access authentication starts with ... Virtual_ISL [s/b] Virtual ISL
Accepted- superseded by Ralph's latest comments Completed in Rev 5.8
ENDL-152 ENDL-153
T E
15.2.2.3, p 2, s 1 15.2.2.3, p 2, s 2
95 95
Accepted- superseded by Ralph's latest comments Completed in Rev 5.8 Accepted Completed in Rev 5.8
ENDL-154 ENDL-155
T E
15.2.2.3 15.3.1, p 2 (note), s 1
95 95
[Insert the following as a new paragraph at the end of the subclause] 'Subsequent TCP connections in the B_Access Virtual ISL are authenticated using the mechanism described in 15.2.2.1.' LEPs [s/b] FCIP_LEPs [LEP is not a defined acronym] that are involved are operational [s/b] that are involved become operational
Accepted- superseded by Ralph's latest comments Completed in Rev 5.8 Accepted Completed in Rev 5.8
ENDL-156
15.3.1, p 4, s 1 95
Accepted
Company number
Comment Use either 'Virtual ISL/FCIP Link' or '(Virtual ISL/FCIP) Link', preferably the former, but not both. can [s/b] may [or] can [s/b] is able to mechanisms [s/b] mechanisms and management controls
Proposed resolution
Response
Status
ENDL-157 ENDL-158
E E
15.3.1, p 4, s 1&s2 95 15.3.1, list entry 2, s 1 95 15.3.1, list entry 3, s 2
Accepted Accepted
ENDL-159
95
Accepted
T E E E E
15.3.1, list entry 3, s 3 15.3.1, list entry 7, s 1 15.3.1, list entry 7, s 2 15.3.1, list entry 8, s 1 15.3.1, list entry 9, s 2
95 95 95 96 96
Authentication of connections other than the first is accomplished by authenticating each new TCP connection against a previously authenticated TCP connection using the mechanisms described in 15.2.2.1.[s/b] If the first TCP connection has been authenticated using the FC-SP mechanisms, the authentication of subsequent connections is accomplished by authenticating each new TCP connection against a previously authenticated TCP connection using the mechanisms described in 15.2.2.1. E-port or B-Port [s/b] E_port or B_Port E-Port [s/b] E_Port ISL [s/b] Virtual ISL for each ISL or Link [s/b] for each Virtual ISL or FCIP Link
Accepted- See McData-041 Accepted Accepted Rejected- sentence changed per Denver meeting Accepted
Company number
tech/e Sec/table/fig dit locator Page 15.3.1, list entry 9, s 3 & s4 96 15.3.1, list entry 10, s 2 96
Comment for each connection [s/b] for each Virtual ISL or FCIP Link [two instances] See Annex F. [s/b] See FCIP [16].
Proposed resolution
Response
Status
ENDL-165
Accepted - small change made it Virtual ISL/FCIP Link Completed in Rev 5.8
ENDL-166
Accepted
ENDL-167 ENDL-168
E E
15.3.2, list entry 1 15.3.2, list entry 2, s 1
96 96
The sending FC Entity must deliver FC Frames to the correct FCIP Entity FCIP_LEP FCIP_DE (in the correct FC/FCIP Entity). [s/b] The sending FC Entity shall deliver FC Frames to the correct FCIP_LEP FCIP_DE in the correct FCIP Entity.[As written, the statement is redundant.] must [s/b] shall
Accepted Accepted
ENDL-169
15.3.2, list entry 2, s 2
96
[Delete] 'If a synchronized time value is not available, a value of zero shall accompany the FC Frame.' [The statement is not accurate and the reference to 13.2.3.4.2.1 in the previous sentence covers the issues.]
Accepted
ENDL-170
15.3.2, list entry 3, s 2
96
However, before forwarding ... for discarding the FC Frame. [s/b] However, before forwarding a FC Frame the FC Entity shall verify the end-toend transit time as described in 13.2.3.5.2.2. [The description of the transit checking rules should appear in only one place.]
Accepted
tech/e Sec/table/fig dit locator Page 15.3.4.1, p E 1, s 1 96
Comment a certain number [s/b] a number However, while assigning FC flows ... that FCIP_DE.[s/b] However, once a FC flow is assigned to a FCIP_DE within the Virtual ISL, all FC frames of that flow shall be sent on that same FCIP_DE. delete strikeout text These rules [s/b] This rule [Also, this sentence should not be in a new paragraph.] This paragraph should be a normal document paragraph not a numbered list entry paragraph. the FC Entity shall authenticate the source of the TCP connect request before use of the new TCP connection is allowed[s/b] the procedures described in 15.2.2.1 shall be followed Subclause 15.3.4.2 should be removed because it addresses a topic that belongs in the FCSW-n standard. [Add the following to the end of the note] 'If there is any discrepancy between statements in this sub clause and FCIP [16] then FCIP prevails.'
Proposed resolution
Response Accepted
ENDL-172 ENDL-173
E E
15.3.4.1, p 1, last s in p and list entry 1 96 15.3.4.1, 1,2,3 list 96 15.3.4.1, last p on pg 96
Accepted Accepted
ENDL-174
Accepted
ENDL-175
15.3.4.1, 1st p on pg 97
Accepted
ENDL-176
15.3.4.1, 1st p on pg 97
Accepted
ENDL-177
15.3.4.2
97
Accepted - Clause will be removed.
ENDL-178
15.5.1, p 3 (note)
97
Accepted
Company number
Comment The number list paragraphs in this clause should be made regular text paragraphs (i.e., not numbered or lettered). The last paragraph of 15.5.2 (describing the use of the HLO SW_ILS) should be deleted or replaced with a discussion of the LKA SW_ILS. Add a new clause between 15.6.1.1 and 15.6.1.2. Title 'FCBB-2_IP Timers' In the new clause place a discussion of K_A_TOV. The font size and line spacing in this clause should be made to match that used throughout other parts of the standard. can [s/b] may can [s/b] are able to MUST [s/b] shall DOES NOT [s/b] shall not will receive [s/b] receives must [s/b] shall [two instances] [Delete] 'In both cases,' [It is not at all clear what cases comprise the 'both cases'.] Use either 'See Section' or just 'Section' but not both.
Proposed resolution
Response
Status
ENDL-179
15.5.2
98
Accepted
ENDL-180
15.5.2, p 6
98
Accepted-
ENDL-181
15.6.1
98
Accepted- Added text in Clasue 15.7.1 and LKA (see Brocade 121)
ENDL-182 ENDL-183 ENDL-184 ENDL-185 ENDL-186 ENDL-187 ENDL-188
E E E E E E E
15.6.1.2 16.2.3, p 1, s 1 16.2.3, p 2, s 3 16.2.3, p 2, s 4 16.3.1, p 1, s 4 16.3.5, p 1, s 1 16.3.5, p 1, s 2&s3
98 99 99 99 100 100 100
Accepted Accepted Accepted Accepted Accepted Accepted Accepted
Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8
ENDL-189 ENDL-190
E E
16.3.5, p 2, s 1 100 16.3.5, dashed list 100
Accepted Accepted
Company number
tech/e Sec/table/fig dit locator Page 16.5, p 1, s 2 & s 3 && p 2, s1 101 16.5, p 1, s2 101
Comment DEs [s/b] FCIP_DEs [Three instances] [There is no defined acronym DE.] LEPs [s/b] FCIP_LEPs Virtual ISL[s/b] Virtual ISL as long as the first TCP connection is authenticated using the mechanisms described in 15.2.2 and FC-SP must [s/b] shall can [s/b] may [three instances] which [s/b] that
Proposed resolution
Response
Status
ENDL-191 ENDL-192
E E
Accepted Accepted
T E E E
16.7, p 2, s 1 101 A.1, p 5, s 2 102 B.1, p 5, s 1 &s5 104 B.1, p 5, s 7 104 B.2, 1st p after note, s 1
ENDL-197
105
must [s/b] needs to be
Accepted
E E E
B.2, 1st p after note, s 4 105 B.2.1, p 3, s 2 105 B.2.2, p 1, s 2 105 B.2.2, 1st note on , s 1 106 B.3.3, 1st & 2nd p after dashed list, s 1 && 4th p after list, s 2 && B.4, 2nd note, s 1 108 B.4, p 5, s 1 108
can [s/b] may can [s/b] may [two instances] which [s/b] that which [s/b] that [and] can [s/b] may
ENDL-201
Accepted
ENDL-202 ENDL-203
E E
can [s/b] may [four instances] must [s/b] are required to
Accepted Accepted
tech/e Sec/table/fig dit locator Page B.4.1, p 1, s E 1 108 B.4.2, p 1, s 4 && p 2, s 2 && p 3, last s && p 5 s 2 109 B.4.2, p 2, s 4 109 B.5, p 2, s 1 110 B.5, p 3, s 1 110 B.5, p 3, s 2 110 B.5, p 4, s 2 110 B.6, p 1, s 1 && p 2, s 3 && p 7, s 1 110 B.7, p 1, s 2 &s4 111 C.1, 2nd note, s 1 && C.1.1, p 3 (note), s 2 112 C.1.1, p 1, s 2 112 C.1.3.2, p 3, s2&s7 113 E.1, 1st p after Fig E.1, s3 116 E.1, last p on pg 116
Comment which [s/b] that
Proposed resolution
Response Accepted
ENDL-205 ENDL-206 ENDL-207 ENDL-208 ENDL-209 ENDL-210
E E E E E E
can [s/b] may [five instances] which [s/b] that can both support [s/b] both are capable of supporting can all support [s/b] all are capable of supporting can support [s/b] is capable of supporting must [s/b] are required to
Accepted Accepted Accepted Accepted Accepted Accepted
Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8
ENDL-211 ENDL-212
E E
can [s/b] may [three instances] can [s/b] may [and] which [s/b] that
Accepted Accepted
E E E
which [s/b] that [two instances] can [s/b] may can [s/b] may [two instances]
ENDL-216 ENDL-217
E E
must [s/b] shall can be processed [s/b] it is capable of processing
Accepted Accepted
Company number
Comment
Proposed resolution
Response
Status
ENDL-218
F.1
118
Section F.1 should be removed. The reason the section exists is to include a table that does nothing more than duplicate information provided in FCIP. There is no new or useful information in section F.1. If section F.1 is not removed, the title of the table should be changed from 'D.1' to 'F.1' and the section references in the left column of the table should be changed from FCIP section references to FC-BB-2 section references. The references in this clause already appear in 2.2 and 2.3 respectively, and should not be repeated here. remove the word that from the phrase " indicates that the reword the phrase to now read clearance " "...indicates the clearance..." replace the word "has" with "had" reword phrase "...BBW_Header consist of 9..." so that it now reads:" .. Link which had been previously" to "...(No Suggestions) and consists of 9..."
Accepted - Annex Removed
ENDL-219
F.2 6.3.2.5 para 2, line 2
120
Accepted -See ENDL-218
HP-001
32
Accepted
HP-002
6.3.3, para 1, line 1 32 6.3.5, para 3, line 1
Accepted
HP-003
33
Accepted - corrected
HP-004
7.1, para 2, line 5 37
insert the word "the" at the end to read " and it only sees the of the line FC-BBW.
Accepted
Company number
Comment
Proposed resolution
Response
Status
HP-005
7.1 cont, para 5, line 2 &4 38
those parts of the paragraph should now read: " The SR protocol specifies the maximum number (k) of outstanding reword the first sentence to messages at any given time. K remove the reference to is a system parameter (32767) and place it at the end available. Typically, the value of of the last sentence in the k is expected to be far below the paragraph maximum number of 32767. Accepted the reference to tables 8-14 seems out of date when one looks at the tables change the phrase "upon receipt of the SR-SM command correctly" remove the word "below" at the end of the sentence. like the comment, remove the word "below" at the end of the sentence. In both cases the word appears at the end of a long clause title. replace the word "filed" with "field" to now read ".. Information field of this message.." perhaps an exact reference would be more appropriate such Accepted - the reference has been as tables 7, 8, 9, 13, 14, 15, and made to a caluse which covers these 16 tables. change the phrase "upon correctly receiving the SR-SM command, ..."
HP-006
7.2.1, para 1, line 1
38
HP-007
7.2.4.5 (cont), para 3 lines 1&2 39 word just before 7.2.4.4
Accepted
HP-008
40
Accepted
HP-009
7.2.4.4.2, para 2, line 5 40 7.2.5.2, para 1, line 3 42
Accepted
HP-010
Accepted
HP-011
7.2.5.6.1
43
there is an extra blank line between para 5 and 6 (counting para a), b) and c) as para 2, 3, and 4 respectively remove the extra line
Accepted
Company number
Comment re-word the first part of the first sentence: "If the Timer T1 runs out waiting for the acknowledgement from the remote FC-BBW for an SR_I message transmitted, the FCBBW " there appears to be a typo in the phrase " link is reset an if no outstanding" there appears to be some missing words in the phrase "latency delay components due Queuing time at the FCBBW"
Proposed resolution suggested rewording: "If the Timer T1 runs out while waiting for the acknowledgement from the remote FC-BBW of an SR_I message, transmitted, the FCBBW " it should read "" link is reset and if no outstanding"
Response
Status
HP-012
7.2.5.9, para 1, line 1 & 2 45 7.2.7.2, para 4, last line 47
Accepted- but changed to "If the Timer T1 runs out while waiting for the acknowledgement of an SR_I message from the remote FC-BBW, the FC-BBW " Completed in Rev 5.8
HP-013
Accepted
HP-014
9.2, para 1, lines 3&4
53
should read: "..the latency delays due to the queuing time at the FCBBW.." Accepted
HP-015
9.6, para 1, line 1
55
remove the word "media" from the phrase: "ATM networks are to read: "ATM networks are lossy lossy media and " and " Accepted suggest rewording the phrase "..requests the remote BBW to: "..requests the remote BBW from transmitting traffic.." stop transmitting traffic.." is there a missing letter in the phrase "...control and an error should read "...control and any recovery functions." error recovery functions." two sentence fragments ".using HDLC according to RFC 1662.The fields are transmitted from left to right" at the end of the line there is the phrase: "Unnumbered Frames in this use are" should it read ".using HDLC according to RFC 1662, the contents of the fields are transmitted from left to right"
HP-016
10.2.8, para 1, line 1
59
Accepted
HP-017
10.2.9, para 2, line 2 59
Accepted- made function singular since the plural is implied. Completed in Rev 5.8
HP-018
11.1, para 2, line 1&2 11.1(cont), control:, line 2
61
Accepted
HP-019
HP-020
several
should it read ".. "Unnumbered Frames in this use are" please convert all references to on pages 66 & 67, the x^43+1 x43 on this page to x^43 or scrambler is shown with a convert all other references to 66 & 67 superscript as x43 +1 use the superscript. 62
Accepted
Accepted
Company number HP-021
tech/e Sec/table/fig dit locator Page 12.1, para E 1, lines 3&4 68 12.2, para 1, note line 3 68
Comment see comment HP 14
Proposed resolution see comment HP 14
Response Accepted
HP-022
in the last line of the note there reword to "remains and is appears to be a word missing addressed "
Accepted
HP-023
13.1, para 3, lines 1-3
69
I believe that the real concern is that either all of the FCIP devices used to build a multiple AR SAN as written the text: "If Inter-AR must either all support Inter-AR E_port FC Switch connectivity connectivity or none of those architecture (Fig 6) is same FCIP devices can support supported, then every FC-BB- Inter-AR connectivity. I would 2_IP device is required to suggest the following re-wording: support the BSW function" If Inter-AR E_port FC Switch appears to imply that if any connectivity architecture (Fig 6) is vendor provides inter-AR supported by any FCIP in the connectivity support, then all SAN, then every FC-BB-2_IP vendors MUST also provide device in that SAN is required to that support. support the BSW function". Accepted: See Andiamo-001
HP-024 HP-025
E E
13.1-cont, para 4 lines 3&4, or 4&3 lines before 13.2 13.2.1, line 7
70 70
The word ONLY is the sentence implies too much uniqueness, and should be placed in context the word describes should not be plural correct
suggest rewording as follows: "The only delivery order guarantee provided by TCP, with respect to the FCIP protocol, is the correctly ordered delivery of Encapsulated FC frames within a single TCP connection." Accepted Accepted
HP-026
13.2.1, line 7
70
the text within clause 13 that describe the interfaces are subclauses, not clauses as in 14, revised text (including HP 25) 15, and 16 which describe should read: " The following subother parts of the FC-BB-2_IP clauses describe each of the protocol above interfaces" Accepted
Company number
Comment Because Fig 23 includes the two network interfaces as well as the listed parts before this paragraph.
Proposed resolution
Response
Status
HP-027
13.2.3.1, para 1, line 2 70
reword the last sentence of the paragraph as follows: "In addition to the two network interfaces, it consists of the following major components" Accepted
HP-028
13.2.3.2, para 1, line 3 71
remove the word "and" and insert the word "the" in the phrase "the FC SE switches and route the data arriving" correct this is related to comment HP 23, and needs the same conditional requirement statement
Accepted
HP-029
13.2.3.2, para 1, last sentence
71
reword to "If the FCIP device is used in a multi-AR SAN, then the FC SE is required to support the BSW function of the Inter-AR architecture." Accepted: See Andiamo-001
HP-030
figure 23
71
the label "FCIP LINK" which identifies the links between the FCIP_LEP DE's and the TCP ports is misleading in that the FCIP LINK extends from the FCIP_LEP DE through the TCP ports, through the IP A better label is "One end of the stack and into the IP network. FCIP LINK" insert the word "is" into the phrase "...IP Routing and is between" at the end of the sentence there is the phrase "Clause 13.2.4"
Accepted Accepted - used the word "occur" instead of "is"
HP-031
13.2.3.2.1 para 1, line 1 72 13.2.3.2.2, last line
correct it should read "sub-Clause 13.2.4"
HP-032
72
Rejected: See ENDL- 001
HP-033
figure 24
73
The actual start point for the FCIP link is the bottom of the FCIP entity and not the bottom Accepted- actually removed this of the IP layer as shown (see correct by making the arrow pass because it did not add value to this also comment HP 30. through the TCP and IP layers. diagram.
HP-034
global
there are several references to search for and reword all 73 and clauses 13.2.3.x.x.x that references from clause 13.x.y.z.. others should be sub-clauses to sub-clause 13.x.y.z Rejected: See ENDL- 001
Company number
Comment
Proposed resolution
Response
Status
HP-035
13.2.3.3.4, bullet 2, FCIP Link 74
change to: "Conceptually, communication between two LEPs is similar to the at the end of the bullet, the last communication between two sentence should be reworded instances of a TCP application"
Accepted
HP-036
13.2.3.5.1
76
An additional sentence is needed to conform to the requirements of 16.3.5
append with the following: "The PMM is also the intended component for any miscellaneous housekeeping functions such as maintenance of event logs (see sub-clause 16.3.5)" Accepted
HP-037
13.2.3.5.4 (cont), para 2
77
near the end of the paragraph there is a reference to the FCIP RFC without the RFC and [16} tags. correct to read FCIP RFC [16] reword that sentence to: "An FC/FCIP entity pair has a potential security vulnerability where interactions may not be fully secured by either the FCSP or FCIP security features."
Accepted
HP-038
13.2.3.5.4 (cont), para 3
77
The first sentence now reads like the FC-SP or FCIP security features might attack the interaction of an FC/FCIP entity pair the last sentence states :"These ports interface with the CSM" but there is no mention of how that interface is performed.
Accepted - also had to slightly modified the following sentence to accommodate this change. Completed in Rev 5.8
HP-039
13.2.4 last sentence on page
77
add another phrase to the sentence so that it reads: "These ports interface with the CSM through an implementation defined interface." Accepted reword the last sentence of the paragraph as follows: "In addition to the two network interfaces, it consists of the following major components" Accepted correct it Accepted
HP-040 HP-041
E E
13.3.3.1, para 1, last sentence 13.3.3.2.1, line 1
78 78
see comment HP 27 unbold the term B_access
Company number
Comment
Proposed resolution
Response
Status
HP-042 HP-043
E E
13.2.3.3.1 and 13.3.3.2.1 figure 26
The same phrase is on both pages, that being: "The FC/FCIP Entity pair interface with the CSM and the PMM", but there is no indication of 72 & 78 how. 79 see comment HP 30
reword both to now say: "The FC/FCIP Entity pair communicate with the CSM and the PMM through an implementation defined interface." Accepted see comment HP 30 Accepted
HP-044
figure 29
85
In the figure the virtual ISL is shown as a heavy solid line and exists only between the VE_port and the FCIP LEP or the B_Access and the FCIP LEP. In truth the heavy line represents the last segment of the virtual ISL that exists between two VE_ports or two B_access. Similarly the FCIP link exists between two FCIP_LEP and not just between the TCP/IP stacks.
fix the legend as follows: rename the Virtual ISL to the First/Last segment of the Virtual ISL; rename the TCP can to the FCIP LINK; and rename the FCIP LINK to TCP Conn. An option would be to make the TCP portion of the FCIP link a dashed line, and so indicate in the legend Accepted
Company number
Comment
Proposed resolution
Response
Status
HP-045
14.1.1
87
Append the following text after the first sentence: "The information for this table and the field definitions has been extracted from the FC Encapsulation RFC [18]. Should there be a conflict between this table or the following field definitions and that of the RFC, then the RFC has precedence. The content of words one and if some text where inserted two in table 26 is defined by table after the heading describing 27 and the field definitions that the FC IP encapsulation RFC follow table 27. Similarly tables [18] then the first part of figure 28 and 29 provide specific details 26 would be pushed to the on the use of the FC next page making reading of encapsulation protocol flags" the figure on one page instead The note can then be deleted as Accepted- see ENDL- 133 forsome of of spanning two well. the text.
HP-046
14.2.1
90
see comment HP 45
Append the following text after the first sentence: "The information for this table and the field definitions has been extracted from the FCIP RFC [16]. Should there be a conflict between this table or the following field definitions and that of the RFC, then the RFC has precedence." The note can then Accepted- see ENDL- 141 for some of be deleted as well. the text.
HP-047
14.3
92
the title of the section should be renamed as there are multiple encapsulations within Rename to 14.3 TCP/IP this specification Encapsulation of an FC Frame
Accepted- with small change - TCP/IP Encapsulation [of an FC Frame is incorrect it should be Encapsulated FC Frame. Since this makes it rather repetious, I decided to keep it simple] Completed in Rev 5.8
Company number
Comment
Proposed resolution
Response
Status
HP-048
15.2
93
append the following after the only sentence: "There are no specific procedures defined for continuing comment HP 36, a housekeeping functions such as brief statement is needed here maintenance of error or event as well logs"
Accepted
HP-049
15.3.1 step 7 95
there is no process for when the FC-BB-2_IP device is running in B-port mode
append the following to the end of the step: "When operating in BPort mode, it is expected that the external E-ports will exchange FSPF messages over the virtual ISL which result in the link becoming operational" Accepted
HP-050
15.3.1-(cont), step 8 96
sub-clause 13.2.3.2.1 does not contain any text on determining link cost, only an indirect reference to the FSPF Change the reference to using algorithms the procedures in FSPF there is no mention if the FSPF link cost is the same or different across multiple Virtual ISLs or FCIP links. They should be the same, given that they share a common IP infrastructure and link cost is determined by speed not distance
Accepted- Text to say link costs are implementation defined.
HP-051
15.3.1-(cont) step 9 96
append the following to the end of the step: "The establishment of additional ISLs or Links does not require the re-running of the FSPF cost algorithms as in step 8."
Rejected+G503-The FSPF behavior should be the same regardless as to whether the Fabric has FC-BB-2 links.
HP-052
15.3.3
96
there is no mention of the need for notification back to the FC fabric
append the following sentence to the end of the paragraph: "When the FCIP link is disconnected, notification of the disconnection shall be accomplished according to the procedures in 16.3.5" Accepted
HP-053
15.3.4.1 last word of para 1 96
the word is "rules" as it should not be plural as there is only one rule left after the edits drop the "s" in rules.
Accepted
Company number
tech/e Sec/table/fig dit locator Page 15.3.4.1 first three words of para 2 96 15.3.4.1(cont), step 4 97
Comment
Proposed resolution
Response
Status
HP-054
the words "These rules are" should not be plural as there is only one rule left after the edits change to "This rule is" step/rule 4 at the top of the page appears to left over drop the step number and make it into a full paragraph
Accepted
HP-055
Accepted
HP-056
15.5.1, para 2
97
since the rules following the second paragraph are summarized from [16], a statement is needed that [16] overrides this specification (see comments HP 45 & 46) another case of clause x.y.z that should be a sub-clause
Rewrite the single sentence in the paragraph to: "Fibre Channel frame errors and the expected resolution of the errors are described in [16] and summarized below. Should there be a conflict between the summarization and [16], then the behavior in [16] shall take precedence" Accepted- see ENDL- 178
HP-057
16.1
99
correct it
Accepted
HP-058
16.2.2 16.3.1, para 1
99
rewrite the last sentence as follows:" then Encapsulated FC both the loss of TCP segments Frames will be discarded. Either and the discarding of FC case will cause the effective Accpeted- slight change - used shall frames will reduce throughput throughput to be reduced" instead of will. there is a reference to clause 15.6 item 4, that item does not exist correct pointer The second paragraph has the one sentence about the FC entity testing for failed TCP connections. There needs to be a corresponding action should a failed connection be identified
HP-059
100
Accepted
HP-060
16.3.1, para 2
100
d the following text after the one sentence: "Should such a test detect a failed TCP connection, the FC entity shall disconnect that connection following the procedures in sub-clause 15.3.3." Accepted
Company number
Comment corrupted frames if detected by the sender should be discarded and not sent over the IP network. Corrupted frames detected by the receiver have already been sent over the IP network the word "Any" is capitalized and it should not be the word "requirements" should be singular and not plural
Proposed resolution
Response
Status
HP-061
16.3.4 para 1, line 2 100 3rd bullet from top B.2.1, para 3, line 1 B.3 2 line 107
reword to state: "Corrupted frames detected prior to transmission into the IP network, are discarded and not sent over the IP network" Accepted
HP-062
101
correct
Accepted
HP-063
105
correct it
Accepted
HP-064
the word "is" is missing between the words connection and established. insert it
Accepted
HP-065 HP-066
E E
F.1 line 1 and Note 118 Table D.1 118
both refer to data in [1] which should be [16]. In addition the note duplicates whats in the first sentence and should be eliminate the note and chage the eliminated reference from [1] to [16] Accepted: See ENDL-218 it should be table F.1 not D.1 change reference Accepted: See ENDL-218
HP-067
section F.2
120
not needed If no ACK is received within the E_D_TOV the VE_Port may retry LKA. If a VE_Port satisfied itself that the connection is down, the VE_Port shall restart FCIP Link Initialization (see [16]) Concern: Insufficient definition of "satisfied itself that the connection is down."
remove it and any refeerences to it as in F.1 line 1 (Comment HP 65) Accepted: See ENDL-218
INRANGE-001
Section 13.2.3.3.5.1 paragraph 2
Accepted - See Brocade-121
Company number
Comment
Proposed resolution
Response
Status
INRANGE-002
Section 13.2.3.5.2.2 paragraph 2:
If the network transit time is large enough to jeopardize meeting any Fibre Channel timeout requirements, the frame shall be discarded. Concern: The above language could lead to interoperability problems with different interpretations of maximum transit times given a single set of Fiber Channel Timeouts.
Accepted-See Akara -010
Company number
Comment
Proposed resolution
Response
Status
INRANGE-003
Section 13.3.3.5.2 paragraph 2 Section 13.3.3.5.3 figure 28
If no ACK is received within RTT_TOV (see B_Access Initialization State Machine) the B_Access may retry LKA. If a B_Access has satisfied itself that the connection is down, the B_Access shall transition to Exchange B_Port Parameters state. Concern:The RTT_TOV is calculated based on a single round-trip acknowledgement to an EBP during B_Port link initialization. The RTT_TOV is used during B_Port ISL operation to time-protect receipt of an ACK to to an LKA Switch Fabric ILS. There is insufficient detail in the draft to understand when a B_Access should consider a connection down, and a concern that it is based on a round-trip time that is measured only once on a link that may reasonably have a highly variable round-trip delay characteristic. State P5 not shown in diagram, but referenced in diagram and text.
Accepted-See Brocade 121 Accepted-P5 is removed and references to RTT removed.
INRANGE-004
Company number
Comment
Proposed resolution
Response
Status
INRANGE-005 McDATA-001 E
Section 4.7 section b 1.1
Latency delay guarantees and timeout value considerations: 1) FC-BB-2 shall ensure that the inherent latency between two FC-BB-2 devices is bounded and included well within the Fabric?s R_A_TOV?s value. FC-BB2_IP shall compute the IP Network transit time to comply with the above. Concern: The draft does not allow implementors in a multi-vendor configuration to determine the appropriate maximum transit times between FC-BB-2 devices in order to allow switches to deterministically guarantee E_D_TOV and R_A_TOV within the fabric. "FC Over TCP/IP" should be 1 "over" for consistency Uncapitlaize "Over" If the dashed lines in the figure are supposed to show the boundaries of FC-BB-2_IP, then it should not enclose Move the dashed line above the 2 FCIP(IETF). FCIP Enitity. 10 GFC did not map native FC over SONET. See Appendix A Remove the reference to this 2 of 10 GFC. mapping. "to support the Fibre Channel over TCP/IP" should be "to support Fibre Channel over 3 TCP/IP." FC-SP and FC-SW-3 should 12 be added.
Accepted: Section b addressed see CNT 17.See Akara - 010 Accepted
McDATA-002
Figure 1
Accepted
McDATA-003
Note
Accepted
McDATA-004 McDATA-005
E E
third sentence top list
correct it. Add FC-SP and FC-SW-3.
Accepted Accepted
Company number
Comment
Proposed resolution
Response
Status
E E
4.7(a) 4.8.2
"Class 2, 3, 4, and Fshall be encapsulatedand transmitted..." implies that all classes must be supported. Class 4 is not widely 17 supported. Delete "Class 2, 3, 4 and F" Need a space or period after 18 "etc." add a space This sentence is incorrect "The procedures for Encapsulated FC Frame formatting, mapping and encapsulation are described in Clause 14 and the FC-BB-2_IP Protocol procedures are described in 69 Clause 15." "Functional Model" should not 70 be capitalized. FC-BB-2_IP Protocol 70 Interface" is wrong "E_Port FC Network Interface" is odd. Fibre Channel has a fabric, not a network. Does Network Interface have a special meaning that would require it to be captialized? This applies to the IP Network 70 Interface too. WWPN is not a defined term. WWPN should be Interconnect_Port_Name or 70 Port_Name. "Encapsulated FC Frames" 70 should not be bold. Should be "The procedures for formatting, mapping and encapsulating Encapsulated FC Frames are described in Clause 14. The FC-BB-2_IP Protocol procedures are described in Clause 15." The text should not be bold either. uncapitalize it Change to "FC-BB-2_IP Interface"
Accepted - text modifed per email Accepted
McDATA-008 McDATA-009 McDATA-010
E E E 13.2.1 13.2.1
13.1
Accepted - slightly modified next sentence to match the tense in the previous sentences. Accepted Accepted
McDATA-011
13.2.1 and 13.2.3.1
Change to "E_Port interface" and "IP interface". "FC Network" should be replaced with "FC Fabric" throughout the document. AcceptedChange to Interconnect_Port_Name or Port_Name throughout the document.
McDATA-012
13.2.2
Accepted- changed to E_Port_Name
McDATA-013
first sentence
Unbold it and all other bold text in the document not in titles. Accepted
Company number
Comment "All Encapsulated FC Frames are transparently transported (tunneled) over the IP network." is a misleading sentence because of the 70 implications of tunneled.
Proposed resolution
Response
Status
McDATA-014
last sentence of first pragraph
Remove "(tunneled)" from the sentence.
Accepted
McDATA-015
13.2.3.2
Remove the text regarding the function of the switching element. This clause states the function The switch is uniquely identified for the switching element, by the Switch_Name, not the FC 71 which is defined in FC-SW-3. SE. Accepted
McDATA-016
13.2.3.2
Change to "If the Inter-AR Last sentence of the first architecture is supported, the FC Accepted- References to FSPFparagraph is a false SE must support the BSW Backbone entities will be removed. See 71 requirement for BSW support. function." Andiamo-001 Completed in Rev 5.8
McDATA-017
13.2.3.2
"The FC-BB-2_IP Protocol forwards Encapsulated FC Frames across the IP Network. The forwarding function requires a knowledge of the FC routes and a Forwarding Table." is out of place. Isn't this section discussing the FC SE? What 71 is trying to be said?
Should it be"The IP Network Interface forwards Encapsulated FC Frames across the IP Network. The FC SE requires a knowledge of the FC routes and a Forwarding Table."? If this is not correct, FC-BB-2_IP Protocol needs to be defined. Accepted- this clause has been deleted. Completed in Rev 5.8
McDATA-018
Figure 23 and 25.
I thought we decided to change one of the E_Ports on the top to F_Port. We could Change one of the E_Ports on also remove the FC SW on the the top to F_Port and eliminate 71 right hand side of Fig 25. the middle FC SW from Fig 25. In the last sentence, it says "the selection of which FCIP_DE to use is decided by policies and not by FC Routing Change to "the selection of the or the VE_Port." Which FCIP_DE to use is decided by 72 policies? policies in the FCIP Entity".
Accepted
McDATA-019
13.2.3.2.1
Accepted
Company number
Comment
Proposed resolution Since it is "outside the scope" and it is implementation dependent, it might be better to remove description of "Forwarding Table" or change "IP addresses" to "TCP/IP Connections".
Response
Status
McDATA-020
13.2.3.2.3
Simple D_ID to IP addresses mapping is not sufficient. It needs to map to the TCP/IP 72 connection. The sentence "The term Virtual in VE_Port indicates the use of a non Fibre Channel link connecting the E_Ports" means connecting real E_Ports using non Fibre 73 Channel link.
Rejected- IP addresses are also used at the TCP layer which is passed as a psuedo header but snipped off at the IP layer
McDATA-021
13.2.3.3.2
Suggest changing "connecting the E_Ports" to "to provide E_Port capability between two FC-BB-2_IP devices." or change "E_Ports" to "VE_Ports". Accepted Accepted- added "The FC/FCIP Identifier uses the Name_Identifier format"
McDATA-022
13.2.3.3.2
FC/FCIP Identifier is an 8-byte Identifier, but there is no Suggest using WWN format for 73 description on its format. the 8-byte Identifier. Change: To uniquely identify a FCIP Link, we only require: "we" is used in the clause.The to: To uniquely identify a FCIP use of second person narrative Link, the following fields are 74 should be removed. required: " pair via one or more virtual constructs." The following text describes the virtual constructs. By this definition, always more than "one" virtual construct is involved (VISL Change " via one or more and FCIP Link) between two virtual constructs" to "via virtual 74 FC/FCIP Entity pairs. constructs". Should be VE_Port_Name and we should define the VE_Port_Name as the Port Name of the VE_Port.
McDATA-023
13.2.3.3.4
Accepted- except used the word items instead of fields as suggested to match the previous set. Completed in Rev 5.8
McDATA-024
13.2.3.3.4
Accepted
McDATA-025
b)
74 VE_Port WWPN is incorrect
Accepted
Company number
Comment
Proposed resolution
Response
Status
McDATA-026
c)
74 Fabric Entity is not defined
Change Fabric Entity throughout the document to Interconnect device or add a definition to the definitions section describing Accepted- Fabric Entity replaced by Fabric Entity. Switch_Name wherever applicable
T T
13.2.3.3.4 a)
The identity of the FCIP Link is identified by the Fabric Entity WWN of the Originator and the Acceptor and the FC/FCIP Entity Identifier of the FCIP Link Originator. Why do we have the asymmetry? We should add the FCIP Link Acceptor to the identity of the FCIP Link. What is the purpose of allowing more than one FCIP Link between FC/FCIP Entities? We could only recall that it addressed the ships passing in the night problem. If this is the case, then we should say that the TCP request with the lowest FC/FCIP Identifier should originate the link and the other 74 request should be rejected. Fabric Entity WWN is incorrect 74 or undefined.
Change "Although, more than one FCIP Link may be formed between a pair of FC-BB2_IP devices, a typical configuration may only consist of a single FCIP Link." to "Although, more than one FCIP Link may be formed between a pair of FC-BB2_IP devices, only a single FCIP Link can be betwen any two FCIP Entities." Add an item d) that says : "d) The 8-byte FC/FCIP Entity Identifier of the FCIP Link Acceptor." Correct Figure 29 to exclude the possibility. This is explained on the last slide of 02555v0. Should be "Switch Name" throughout the document
Rejected-First Comment and change in Fig. 29 request. Accepted - to add VE Port or B Access as an additional identifier for FCIP link. Completed in Rev 5.8 Accepted Completed in Rev 5.8
McDATA-029
13.2.3.3.5.1
K_A_TOV default value and resolution are not specified. This should be less than E_D_TOV and have a default 75 value of 1 second.
Accepted - Default value is 1/2 E_D_TOV; Table 21, Table 22 , will be changed to include resolution (in millseconds). Also define resolution for Suggest adding a default value of E_D_TOV and R_A_TOV were 1 second and say the rsolution of appropriate. Default value defined in K_A_TOV is in milliseconds. LKA. See Brocade 121
Company number
Comment The standard should specify when a VE_Port should declare the connection is 75 down. Why is K_A_TOV exchanged in EBP? FSF already 75 exchanges this value.
Proposed resolution We need to specify a dead interval for the VE_Ports. We suggest using the Dead_Interval specified in SW-2.
Response
Status
McDATA-030
13.2.3.3.5.1
McDATA-031
13.2.3.3.5.1
Remove K_A_TOV from EBP.
Reject - Possibly requred for other BB devices.
McDATA-032
13.2.3.5.2.2
Last two sentences have 76 grammar errors.
Change "Any frame other than a Class F" doesn't need "an" and "A Class F frame" instead of "an F Class frame". Accepted
McDATA-033
13.2.3.5.2
Add a note that says: "Note While it is strongly recommended that time services be synchronized throughout the While time synchronization fabric, some implementations between FC Entities is may choose not to use time recommended, there are services. Unsynchronized fabrics environments, like campuses, may receive frames that would that may not want to use time be discarded if time stamps were services since propagation used. Old frames could cause 76 delay is minimal. error recovery problems." Rejected
McDATA-034
13.2.3.5.2, last paragraph
"It is assumed" is an ambiguous sentence and the synchronization needs to be 76 clarified.
The text should say that "The administrator shall synchronize the time services on both sides of the FCIP link regardless of which time service is used. another time service can be used to synchronize each time service. The drift in time synchronization between the two FC Entities must Accepted - Entire paragraph will be be less than 1% of DLY_LIM." removed
Company number
Comment
Proposed resolution
Response
Status
McDATA-035
13.2.3.5.2.2
The delay limit timeout value (DLY_LIM) should be defined for the transit time. If the network transit time exceeds DLY_LIM, then the frame should be discarded. A default value of DLY_LIM should be less than ED_TOV 76 and we propose 1 second. "Any Frame other than an Class F frame whose time stamp is zero shall be discarded." is too stringent. Some implementations may not want to discard these 76 frames.
Change text to: "If the network transit time exceeds DLY_LIM, the frame shall be discarded." The description of DLY_LIM was discussed extensively in FCIP and text could be obtained from there. Set the default value of DLY_LIM to 1 second and it shall be less than E_D_TOV.
Accepted - FTT-FCIP Transit Time will be ued to compare with 1/2 E_D_TOV. Text for FCIP Transit Time (FTT) is defined as the total transit time of an Encapuslated Fibre Channel frame in the IP network. The FCIP Transit Time is calculated by subtracting the time stamp value in the arriving Encapsulated FC Frame from the synchronized time in the FCIP Entity. Completed in Rev 5.8
McDATA-036
13.2.3.5.2.2
Delete the sentence or add "unless time services are not used."
Accepted-Editor will add the following sentence to 4.7b and in this sub calsue. "FC-BB-2 shall allow class F encapsulated frames to be transmitted with a zero timestamp value". Completed in Rev 5.8
McDATA-037
third paragraph
"However, no such authentication is defined for the second, third, etc. TCP connections, since to Fibre Channel they all appear to be part of an already authenticated Virtual ISL. The mechanism for authenticating the second, third, etc. TCP connections is described in Clause 15.2.2." These statements contradict each 77 other. Delete the first sentence. An FCIP Link should be able to have multiple IP addresses. Since the FCIP Link may have multiple TCP Ports, it should be able to have multiple IP addresses. This is supported in FCIP in clause 10.2 and 77 10.3.2.
Accepted - see McData 041
McDATA-038
13.2.4
Add the following text: "d) Multiple IP Addresses per FCIP Link - A single IP address per TCP Port."
Accepted
Company number McDATA-039
tech/e Sec/table/fig dit locator Page E b)
Comment IKE isn't an authentication 77 technique
Proposed resolution change "IKE authentication" to"IKE for key exchange"
Response Rejected
Status
McDATA-040
first a)
This standard will have to wait How can we reference FC-SP until FC-SP specifies more when it does not even have a information about Fibre Channel draft and it doesn't mention FC- level security before FC-BB-2 77 BB-2? can be approved.
Rejected- Reference to SP is OK
McDATA-041
first b)
Specify the difference between FC-SP TCP connection authentication discussed in This says that Security for 15.2.2.2 and 15.2.2.3 and FCIP TCP connections is defined in security discussed in 13.2.3.5.4. FCIP and then goes on to This may require changing figure define TCP connection 1 to show where FC-SP fits in authentication. The with the overall architecture. We boundaries between FCIP, FC- can't figure out the relationships SP and FC-BB-2 need to be between each standard and how defined in more detail. to implement an interoperable Particularly, how does FCIP product from how it is specified 77 relate to FC-BB-2? now. Accepted What is FC Route-to-IP Route mapping? Is this the FC address to VE_Port or B_Access routing? Are IP addresses involved. Domain 78 ID or Destination ID? Please explain. The Switch_Name is not Include a Switch_Name in the 79 included in the Figure. diagram.
E T
second to last bullet Figure 26
Accepted- deleted text Accepted
McDATA-044
First bullet
"the selection of which State "policies in the FCIP Entity" FCIP_DE to use is decided by or some more information about 79 policies." What policies? what policy. Accepted- "described in 15.4.5" replace Fabric Entity WWN and B_Access WWPN to Switch_Name and Interconnect_Port_Name. Specify 1 second as the default time for K_A_TOV.
E T
a), b) 13.3.3.2.5.1
These use non-standard 80 names No time is specified for 81 K_A_TOV.
Accepted- changed to B_Access_Name and Fabric_Name Completed in Rev 5.8 Accepted - See Brocade -121 Completed in Rev 5.8
Company number
Comment
Proposed resolution
Response
Status
McDATA-047
13.3.3.2.5.2
RTT_TOV is not defined. In E_Port case, E_D_TOV is 82 used. What is the difference? Can E_D_TOV be used instead. "If a B_Access has satisfied itself that the connection is down, the B_Access shall transition to Exchange B_Port Parameters State". If the whole FCIP Link is dead, the switch should start from FCIP 82 Link Initialization. Should be FC/FCIP_Entity_3 85 instead of FC/FCIP_Entity_2. 86 Delete blank page
Accepted - See Brocade -121
McDATA-048 McDATA-049 McDATA-050
T E E
13.3.3.2.5.2 c) blank page
Change "Exchange B_Port Accepted- This comment is covered by Parameters State" to "FCIP Link a common LKA description. See Initialization". Brocade -121 Completed in Rev 5.8 Change 2 to 3. Delete blank page Accepted Accepted Completed in Rev 5.8 Completed in Rev 5.8
McDATA-051
hex values
The document needs to follow the ANSI convention for specifying hex numbers which is: Numbers or upper case letters in quotes immediately proceeded by the word hex (e.g. hex FA23) are 90 hexadecimal values. Change all Hex value notations. Why do we specify FSF if we never call for its use? This is defined in FCIP. Why 90 duplicate it? The note says FC Entity 91 incorrectly.
Accepted
T E
14.2.1 Note
Delete 14.2.1 or explain how/where it is used and why it's Rejected- we need this because of here. security related. Change it to "FC Fabric Entity". Change to "If the FC Fabric Entity is a FC Switch or B_Port device, " Determine it. Rejected Rejected- the names in the table have been changed to state Fabric_Name which already covers the B_Access case. Accepted: See Brocade 127 Completed in Rev 5.8
T T
Source FC Fabric Entity A TBD
The Switch_Name applies to 91 B_Ports as well. 92 What goes here?
Company number
Comment
Proposed resolution
Response
Status
McDATA-057
15.2.2.1
The "When the ASF SW_ILS" sentence/paragraph should be stated more clearly. We should not allow "another equivalent authentication method". If the authentication mechanism is not in FC-SP, then it should not be a valid authentication technique. The "for the first TCP connection" on the end of the sentence is 93 probably a mistake.
Change to "Additional TCP connections to exisiting FCIP Links shall be authenticated with either FC-SP mechanisms or the ASF SW_ILS." Accepted - see McData 058
McDATA-058
15.2.2.1
An overview section needs to specify that there are two (or even three with FCIP) levels of authentication in BB-2, Fibre channel and FCIP. FCIP refers to user-level security and this is not mentioned in BB-2. We mention TCP connection and Fibre Channel Level authentication. These terms need to be explained in 93 detail.
Explain how there is TCP connection authentication with IKE, TCP connection authentication between FC Entities before ELP and Fibre Channel level authentication between switches during Fabric initialization after ELP. Also state that there is no user-level authentication in FC-BB-2 - FCIP should probably change that terminology. Accepted - see McData 041
McDATA-059
15.2.2.1
Does the FC Entity respond with both the a) configuration information and b) success of failure of an ASF SW_ILS? If not, then it should be an "or" not an "and". What is the Change to "or" and describe the 93 configuration information? configuration information.
Accepted - superseded by ENDL-149
Company number
Comment
Proposed resolution
Response
Status
McDATA-060
15.2.2.1 last paragraph
The last paragraph should be the start of a new clause to define the ASF SW_ILS. The ASF SW_ILS should be defined similar to other SW_ILSs in SW-2. For example, the description of the fields in the ASF Request should be referenced below the payload table. References to "new" TCP Connections should be changed to "additional". How does the FC entity verify that the information in the ASF payload identify a TCP connection initiated by that FC/FCIP Entity pair. What address is the ASF 93 frame sent to?
Create new clause for ASF. Describe payloads below the table. Replace "new" with "additional" and explain how this is different from Security for the TCP connections described in FCIP on page 77. Specify how the FC Entity verifies the information in the ASF and that the S_ID and D_ID of the ASF is the Fabric Controller of each FC Entity. Accepted Text should read "ASF should use a previously authenticated TCP Connection in the existing FCIP Link to authenticate the Connection Nonce sent in the additional TCP Connection setup process. Accepted
McDATA-061
15.2.2.1
This section needs to state that the ASF is sent over a previously authenticated TCP connection as FCIP does on page 34 of draft 12. This is 94 not apparent in BB-2.
Company number
Comment
Proposed resolution
Response
Status
T E
15.2.2.2 and 15.2.2.3 6)
Require FC Entities to authenticate the first as well as additional TCP connections. Please refer to 02-555v0 for suggested text and a complete Authenticating B_Ports and explanation. BB-2 needs to state switches prohibits legacy what is being authenticated at devices from taking advantage each level - particularly the Name of FCIP. FCIP should be as used in authentications and that transparent as possible to the the authentication frames should switches that are using the be sent to the Fabric Controller. FCIP link. Requiring switches TCP authentication must be to authenticate each other is independent of Switch Accepted- superseded by Ralph's 94 not transparent. authentication. comments 95 Should we reference SW-3? This clause is for the link setup, but what is the procedure for establishing additional TCP connections? The dependence of the additional TCP connection authentications on the first authentication needs to be 95 specified. "modelled" should be "modeled" in American 96 English. "(in the correct FC/FCIP 96 Entity)" is redundant. Reference SW-3 if possible. Accepted
McDATA-064
15.3.1
Add a new clause or extend this clause to show the procedure for establishing additional TCP connections. Explain the dependence of additional TCP connections on the first authenticated TCP connection. Accepted - see changes in Item 3)
E E
10) 15.3.2 1)
change it. Delete it. Insert a comma after FC Frame in "However, before forwarding the FC Frame, the" Remove crossed out text
Accepted Accepted- see ENDL- 167
E E
3) Crossed out text
96 grammar problem Crossed out text should be 96 removed.
Accepted Accepted
Company number
Comment
Proposed resolution
Response
Status
McDATA-069
8)
8) references 13.2.3.2.1. 13.2.3.2.1 doesn't say anything about link cost. I don't see the need for 8). Isn't this standard SW-3 initialization? Are we proposing that link costs be 96 different? Delete 8). I don't see the reason to specify that each FC-BB-2_IP devices shall manage TCP operational parameters independently for each ISL. They should be able to manage them as a group. Management of the links does Change the "shall" to a "may" or 96 not need to be specified. delete the sentence. "FC-BB-2_IP shall use the standard FC RDY ISL flow control with Buffer-to-Buffer credit con-trol [14] across its FC Interfaces" is incorrect. R_RDY is a Primitive Signal and FC Interfaces is 97 undefined. 98 not [6] 98 grammar error 98 Text is in different font.
Accepted- sentence changed per Denver Interim meeting
McDATA-070
9)
Accepted - changed to May; 2 instances.
McDATA-071 McDATA-072 McDATA-073 McDATA-074
E E E E
15.4 1) 15.5.2 3) 15.6.1.1 15.6.1.2
It should be "FC-BB-2_IP shall use standard Buffer-to-Buffer flow control [14]." FC-FS is [14]. change "it's" to "its". correct font.
Company number
Comment
Proposed resolution
Response
Status
T E
15.5.2 16.3.1
"The F-BB-2_IP device may choose not to generate Fibre Channel's F_BSY or F_RJT frames or otherwise participate in FC frame recovery." is negligent. How can we let one device defile the sanctity of the fabric? If the FC-BB-2_IP device is going to participate in the fabric, then it needs to fully participate in the resolution of 98 problems and error recovery. (See 15.6 Item 4) doesn't 100 exist. "TCP Flow (and error) control has mechanisms to detect lost and corrupted data." is 100 incorrect. "The FC-BB-2_IP device FC 100 Interface" is incorrect. "VE_Port or B_Access shall immediately forward the RLIR to the FC Switch Entity" is incorrect. The RLIR should be forwarded to the Domain 100 Controller of the switch.
Delete the sentence or explain why these devices fall to the level of IP and don't have to report F_BSY and F_RJT. Accepted-sentence deleted Should be 15.5.2. Accepted- 15.6.2
E E
16.3.3 16.3.4
Should be "TCP Flow control and error control has mechanisms to detect lost or corrupted TCP segments." Accepted Should be "The FC Interface of the FC-BB-2_IP device". Accepted
McDATA-079
16.3.5
Change to "VE_Port or B_Access shall immediately forward the RLIR to the Domain Controller of the Switch." Accepted
Company number
Comment
Proposed resolution
Response
Status
McDATA-080
16.3.5
Change "Failure to setup TCP connection" to "Failure to setup additional TCP connections" Change "TCP connect request timeout or Duplicate connect RLIRs should only be request" to "Additional TCP generated when existing links connect request timeout" and have an incident. RLIRs "Duplicate additional TCP should not be generated when connect requests" Change to initializations fail. SA "Successful completion of FC parameter mismatch is an Entity request to close the last initialization event that should TCP connection" Remove "Any be removed. There should confidentiality violations" or move also not be multiple reasons it to the next line. Remove and 100 per bullet. "SA parameter mis-match". Accepted The second sentence says that an LKA shoul donly be sent when no data or Link_Control frames have been received. It would be easier to just send the LKA every K_A_TOV. This would free up processor resources to 75 do other jobs. Change" An LKA is transmitted" sentence to " An LKA is transmitted every K_A_TOV and may not be sent if Data or Link_Control frames have been received from the remote VE_Port during the prior K_A_TOV period." Accepted See Brocade 121
McDATA-081
13.2.3.3.5.1
McDATA-082
13.3.3.2.5.2
Second pragraph states: "If a B_Access has satisfied itself that the connection is down". Saying the is down implies the Change "connection" to "link" for Accepted in sub clause 13.3.3.2.5.2 . 82 TCP connection is down. this clause and 15.2.3.2.5.2. However, 15.2.3.2.5.2 is non-existent The payload for LKA is undefined. Why is everything but the payload defined twice Define the payload for LKA in for VE_Ports and B_Access? one place and apply it to the 82 What is the SW_ILS Code? VE_Ports and B_Access.
McDATA-083
13.3.3.2.5.2
Accepted Brocade 121
Company number
Comment
Proposed resolution
Response
Status
McDATA-084
13.3.3.2.5.2
There is a corner case where a frame might not be sent for almost 2 x K_A_TOV. This happens if the K_A_TOV timer is triggered at the start of one timer and the next data frame is not received till the end of 82 the next K_A_TOV timer. What is the usefulness of the LKA frame if it was transmitted over a functioning TCP connection while another 82 connection has failed? Cover Project Number is incorrecrt Cover X3 is now called INCITS
For SANmark purposes, add "In the worst case scenario, no data or LKA will be transmitted for almost 2 x K_A_TOV. Accepted See Brocade 121
McDATA-085 Qlogic-000 QLogic-001
T E E
13.3.3.2.5.2 Top line Top line
QLogic-002 QLogic-003
E E
Title Points of Contact
Cover Cover
Old spelling INCITS Information for Craig Carlson is incorrect
Add "For LKA to monitor the health of a Link, LKA should be sent on every TCP connection for a given link. Accepted See Brocade 121 Change to 1466-D Accepted Change "dPANS X3.xxx-200x" to "dPANS INCITS xxx-200x" Accepted Change all "NCITS" to "INCITS" in document. Accepted Change to: Craig W. Carlson (T11.3 Chaiman) QLogic Corporation 6321 Bury Drive Eden Prairie, MN 55346 (952) 932-4064 Fax: (952) 932-4037 E-Mail: craig.carlson@qlogic.com Accepted Remove blank page. Accepted Change "dPANS X3.xxx-200x" to "dPANS INCITS xxx-200x", make this change through-out document. Accepted
E E
Blank page Top line
iii iv
Blank pages are not allowed. X3 is now called INCITS
Company number QLogic-006 QLogic-007 QLogic-008 QLogic-009 QLogic-010 QLogic-011 QLogic-012
tech/e Sec/table/fig dit locator Page E Copyright v E E E E E E Top line 4th paragraph 4th paragraph After note vi vi vi vi
Comment Copyright is for wrong millenium. Approval date is wrong. Says the standard was developed during 1996-n. Says the approval process started 1997 Need line break Says Steve wilson is chair of FC-BB Membership list is incorrect.
Proposed resolution Change to 2002. Change "INCITS xxx-2001" to "INCITS xxx-200x". Shouldn't this be 2002? Shouldn't this be 2002?
Response Accepted Accepted Accepted Accepted
Status Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8
Add blank line. Accepted Change "FC-BB" to "FC-BB-2". Accepted See FC-GS-3 for format, see website for current membership list. Accepted Completed in Rev 5.8 Completed in Rev 5.8 Remove blank page. Accepted
2nd to last vi line Membership vii list Blank page Clause 1 xviii 1
E T
Blank pages are not allowed.
This chause should come after Mover after these sections to definitions and conventions "Clause 4". sections. Dashed lists are not to be used. Why are we say that things are defined in "FC-BB"? Used "alpha" list. See FC-MI-2 for example. Remove the text "FC-BB-2 makes use of the previously defined FC-BB" and state that it replaces it. Create annex for future work. Number all notes in document. See FC-MI or FC-GS-4 for example. Note should be fixed to reflect the real status of 10GFC.
Accepted Accepted
E T
clause 1.1 clause 1.1; 2nd paragraph Clause 1.2, note Clause 1.2, note Clause 1.2, note
1 1
T E
1 1
Future work should not be discussed in main text. Notes should be numbered
Accepted Accepted. However, no annex is necessary at this time
Accepted
QLogic-019
Note talks FC over SONET being defined in 10GFC, but I believe that SONET was removed from 10GFC. Hanging paragraph
Accepted Remove hanging paragraph. Accepted
T E
Clause 2 Clause 2.1
4 4
Has reference to both FC-SW Since FC-SW-2 replaces FCand FC-SW-2. SW, remove reference to FCSW.
Accepted
Company number QLogic-022 QLogic-023 QLogic-024 QLogic-025
tech/e Sec/table/fig dit locator Page T 3.2.1 6 T T T 3.2.18 3.3.10 3.5 6 9 11
Comment "Can" is not normative and leads to confusion. Cannot use "Can". Cannot use "Can".
Proposed resolution Replace with "may". Replace with "may".
Response Accepted
Status Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8
QLogic-026
3.5.1
11
Accepted Replace both cans in this definition with "may". Accepted Hanging paragraph Remove hanging paragraph, this should be done for all hanging paragraphs in document. Accepted Use ISO convention for Binary. ISO convention is 010101b. See FC-MI or FC-GS-4 for definitions. This needs to be fixed in remaineder of document. Accepted Use ISO convention for Hex. ISO convention is ABC123h. See FC-MI or FC-GS-4 for definitions. This needs to be fixed in remaineder of document. Accepted
QLogic-027
3.5.2
11
QLogic-028 QLogic-029 QLogic-030 QLogic-031
T T T T 4.7 (e) 4.9.1, 3rd paragraph 5.1, 3rd paragraph after figure
13 18 18 20
Should add list of defined keywords. Cannot use "Can". Cannot use "Can". Cannot use "Can".
Add list from FC-GS-4. Accepted Replace with "may". Replace with "may". Replace with "may". Accepted - this paragraph has been rewritten Completed in Rev 5.8 Accepted Accepted- this paragraph has been rewritten.
QLogic-032
5.1, last 20 paragraph on page 5.1, last 21 paragraph in clause 5.2.4, first paragraph 6.1, 6th paragraph 22 25
Cannot use "Can".
Replace with "may". Accepted - this paragraph has been rewritten Completed in Rev 5.8
QLogic-033
"Will" is not normative and can Replace with "shall". lead to confusion. Accepted Cannot use "Can". Will not use "will". Replace with "may". Accepted Replace both "will"s in paragraph with "shall". Accepted Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8
T T
Company number QLogic-036 QLogic-037 QLogic-038 QLogic-039 QLogic-040
tech/e Sec/table/fig dit locator Page T 6.3.1.5 29 T T T T 6.3.1.7 6.3.2.3 6.3.4.1 6.3.6.2.2 30 31 33 35
Comment Cannot use "Can". Cannot use "Can". Will not use "will". Many "will"s in this clause. Many "will"s in this clause.
Proposed resolution Replace with "may". Replace with "may".
Status Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8
Replace with "shall". Accepted Replace with "shall". Accepted Replace with "shall". Rest of document should be checked as well and wills replaced with shalls where found. Accepted. Replace with "may". Rest of document should be checked as well and cans replaced with mays where found. Accepted Removed crossed out text. Accepted
QLogic-041
8.1, 3rd paragraph
50
Cannot use "Can".
QLogic-042
15.3.4.1
96
Crossed out text below (1).
eted in Rev 5.8

03 027v0

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

03 027v0

Transféré par

Droits d'auteur :

Formats disponibles

Company number Akara-001 Akara-002

tech/e Sec/table/fig dit locator Page E E 1.1, par 3 vii

Comment Spelling of Neil Wanamaker

Proposed resolution Correct

Response Accepted Accepted

Status Completed in Rev 5.8 Completed in Rev 5.8

Completed in Rev 5.8

Replace by "..support for virtual E_Ports" or "support for VEports".

Completed in Rev 5.8

Comment Size of LLC/SNAP header is inconsistent.

Completed in Rev 5.8

Rejected- ILSs are in fact exchanged between VE_Ports

13.2.3.5.2.2 4.2, 4.4, 13.2.3.2.1

Company number Andiamo-002

Completed in Rev 5.8

Completed in Rev 5.8

Completed in Rev 5.8

Company number Andiamo-010

tech/e Sec/table/fig dit locator Page E 14.2.1 92

Accepted: See Brocade-127

Completed in Rev 5.8

Completed in Rev 5.8

All Front Matter

Completed in Rev 5.8 Completed in Rev 5.8

Completed in Rev 5.8

Bob Snively's contact information incorrect

Completed in Rev 5.8

tech/e Sec/table/fig dit locator Page

Brocade-005 Brocade-006 Brocade-007

Front Matter Front Matter Front Matter

Accepted Accepted Accepted

Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8

tech/e Sec/table/fig dit locator Page

Brocade-008 Brocade-009 Brocade-010

Patent Stmt Copyright Front Matter

Accepted Change copyright date to 2002 Delete text Accepted Accepted

Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8

tech/e Sec/table/fig dit locator Page

Completed in Rev 5.8

Completed in Rev 5.8

Completed in Rev 5.8 Completed in Rev 5.8

Missing paragraph Signature (Steve Wilson/Murali Rajagopal)

Completed in Rev 5.8 Completed in Rev 5.8

tech/e Sec/table/fig dit locator Page

Need to add T11 list of representatives

Completed in Rev 5.8

Completed in Rev 5.8

Completed in Rev 5.8

Completed in Rev 5.8 Completed in Rev 5.8

Completed in Rev 5.8

Completed in Rev 5.8

tech/e Sec/table/fig dit locator Page

Completed in Rev 5.8

Brocade-025 Brocade-026 Brocade-027

2.1, 2.2 2.2 2.2

Completed in Rev 5.8 Completed in Rev 5.8 Completed in Rev 5.8

Completed in Rev 5.8

appended is incorrect term. Switche(s) -- incorrect ()

Change to prepended. Change to Switch(es)

Completed in Rev 5.8 Completed in Rev 5.8

tech/e Sec/table/fig dit locator Page

Completed in Rev 5.8

Accepted - added a sentence from the FCIP draft in support of this.