P802.3ah Draft 2.0 Comments Cl 00 SC P L # 952 Cl 00 SC P L # 1248 Thompson, Geoff Nortel Lee Sendelbach IBM Comment Type TR Comment Status R Comment Type E Comment Status A What is being proposed in many places throughout this draft is not a peer network. To Fix all the references with *ref*. Like 60.9.4, 60.8.13.2.1, 60.8.13.1 60.8.11 60.1 I don't introduce such a foreign concept into a document where the implicit and explicit notion of understand what is going on with the *refs. Also fix #CrossRef# in 64.1 peer relationships is so thoroughly infused throughout the existing document is likely to SuggestedRemedy cause (a) significant confusion and (b) significant errors. Fix it. SuggestedRemedy Move non-peer proposals to a new and separate document that can thoroughly, explicitly Proposed Response Response Status C and unambigiously embrace the concept of Ethernet Services over asymetrical ACCEPT IN PRINCIPLE. infrastructure. These references are intended for the use of the editors to search for cross references. All Proposed Response Response Status U these will be romeved at time of publication as indicated in the editor's note boxes REJECT. Cl 00 SC P L # 951 The suggested remedy is ambiguous. What are "the non-peer proposals"? What is the Thompson, Geoff Nortel "new and separate document"? Comment Type TR Comment Status A reassigned The draft in its current form satisfies the PAR and 5 Criteria for the project, which call for an I have a problem with the use of the term "loopback" for the diagnostic return path being amendment to IEEE Std 802.3, formatted as a set of clauses. The suggested remedy proposed for the OAM sublayer. The potential for confusion of this new path with the would not satisfy the PAR and 5 Criteria. existing half-duplex DO to DI loopback path and its associated term of "loopback" is great. The term "loopback" has been an accepted label for this function at least since the drafting While there are asymetric physical layer specifications in the draft, the services provided to of FOIRL (ref: 9.9.2.1) in 1987. the MAC Client are provided in the same fashion as the base standard. The peer relationship between MAC Clients described in the base standard is preserved. SuggestedRemedy Pick another terminology. Previous projects introduced physical layers with asymetric behavior and characteristics. Proposed Response Response Status U For further information regarding document restructuring, see the file: ACCEPT. http://www.ieee802.org/3/efm/public/sep03/frazier_1_0903.pdf The term "loopback", as used within Clause 57, is used in reference to a remote loopback of frames. Occasionally, the word "loopback" is improperly used without being preceded by Cl 00 SC P L # 579 the word "remote". See for example Figure 57-3 at line 20 on page 138. This figure title Glen Kramer Teknovus should be changed to read "OAM remote loopback". If the term "OAM remote loopback" is used consistently, this should provide an adequate differentiation from the loopback Comment Type E Comment Status A olt defined in earlier clauses. In many places the abbreviation OLT is incorrectly expanded as Optical Line Termination. The correct term should be Terminal. Note that this problem was actually introduced in 802.3ae, SuggestedRemedy see for example Figure 45-2. Change "termination" to "terminal". The fix should be applied to C1.5 (page 13, line 12), Fig. 56-2 (page 169), C56.1.2.1 (page 169, line 52), Fig. 60-1 (page 289), and Fig. 66-4 (page 520). Proposed Response Response Status C ACCEPT. Refer 197 TYPE: TR/technical required T/technical E/editorial COMMENT STATUS: D/dispatched A/accepted R/rejected SORT ORDER: Clause, Page, Line, Subclause Page 1 of 269 RESPONSE STATUS: O/open W/written C/closed U/unsatisfied Z/withdrawn Cl 00 SC P802.3ah Draft 2.0 Comments Cl 00 SC P L # 829 Cl 00 SC P L # 837 Tzannes, Marcos Aware Brand, Richard Nortel Networks Comment Type T Comment Status A reassigned Comment Type TR Comment Status R In T1.424 9.3.5.5 it is not clearly specified how many EOC bytes per frame are mandatory Fundamental structural issue. even though the maximum number of EOC byte per frame is exchaged during startup in O- With the addition of a minimum of at least 562 pages of D 2.0 of EFM to the existing 802.3 MSG2 and R-MSG2. document, the IEEE 802.3 document will become overly large. At this point, I find it extremely time consuming to scan the existing 802.3 document for consistency with the SuggestedRemedy new draft sections. With so much bulk, we run an increased risk of approving a document State that support of 1 EOC byte per frame is mandatory. Also remove max EOC byte per that may not be up to our past level of quality. frame field from the initialization messages O-MSG2, R-MSG2 and O-CONTRACT. The material that is generated by future Task Forces will only exacerbate this situation. Proposed Response Response Status C SuggestedRemedy ACCEPT IN PRINCIPLE. Move EFM into a new separate 802.3 document that addresses an Ethernet for service providers and/or access networks. The existing text is sufficient. Refer to 828. Proposed Response Response Status U Cl 00 SC P L # 1181 REJECT. Parsons, Glenn Nortel Networks The draft in its current form satisfies the PAR and 5 Criteria for the project, which call for an Comment Type TR Comment Status A all amendment to IEEE Std 802.3, formatted as a set of clauses. The suggested remedy PICS mapping to clauses is incomplete as not all PICS entries are supported by would not satisfy the PAR and 5 Criteria. 'mandatory', 'shall', 'optional' or 'may' text within the clauses. The page count for this draft is not extraordinary in comparison to other recent projects in SuggestedRemedy 802.3. As an example, IEEE Draft P802.3ae/D5.0 had a page count of 540 pages when it Review all PICS entries to ensure that each entry references an appropriate 'mandatory', was approved by the sponsor ballot group and the IEEE-SA Standards Board. 'shall', 'optional' or 'may' text within the referenced clause. It is expected that the IEEE publications staff will elect to publish EFM as the fifth volume Review all clauses to ensure that all instances of 'mandatory', 'shall', 'optional' or 'may' of a future edition of IEEE Std 802.3, which will make it easy for the document reader to within the clause have a corresponding PICS entry. select the relevant specification. Proposed Response Response Status C For further information regarding document restructuring, see the file: ACCEPT IN PRINCIPLE. http://www.ieee802.org/3/efm/public/sep03/frazier_1_0903.pdf The convention used in 802.3 is that each "shall" statement correspondes to a PICS entry. Other words, such as "mandatory", "optional", and "may", do not receive corresponding PICS entries. Every effort has been made to follow this convention, and any specific instances that the commenter can identify that do not follow this convention will be corrected. If appropriate to document this convention then a maintenance request will be made by the commentor. TYPE: TR/technical required T/technical E/editorial COMMENT STATUS: D/dispatched A/accepted R/rejected SORT ORDER: Clause, Page, Line, Subclause Page 2 of 269 RESPONSE STATUS: O/open W/written C/closed U/unsatisfied Z/withdrawn Cl 00 SC P802.3ah Draft 2.0 Comments Cl 00 SC P L # 1167 Cl 00 SC P L # 1160 Parsons, Glenn Nortel Networks Parsons, Glenn Nortel Networks Comment Type TR Comment Status R Comment Type TR Comment Status A reassigned Amalgamation of these numerous seemingly unrelated clauses into the 802.3 standard is Clause 21 does not sufficiently define the PICS as used in this specification. For example, unrealistic. That is, using 'Ethernet' to bind all these clauses together stretches the the '*ITEM' notation to indicate an item is used as a predicate is not defined. It is defined in meaning of Ethernet beyond what was originally intended and also restricts how much can 802.1Q-1998 Clause A.3.4.2 be changed to add new functionality. SuggestedRemedy SuggestedRemedy Add reference to 802.1Q in Clause 21 or change references in each of the PICS clauses Rework this draft to be a stand-alone standard for 'access' or 'carrier' Ethernet. This would primarily affect the ammendments to clauses of 802.3. This draft would then, for example, Proposed Response Response Status C have its own clause 4 with 'obsolete' material removed and new functions added. The ACCEPT IN PRINCIPLE. existing 802.3 standard could then be termed as 'legacy' or 'enterprise' Ethernet. The commenter is asked to submit a comment in the next maintenance request on Cl. 21 Proposed Response Response Status U REJECT. Cl 00 SC P L 1 # 596 Grow, Robert Intel The draft in its current form satisfies the PAR and 5 Criteria for the project, which call for an amendment to IEEE Std 802.3, formatted as a set of clauses. The suggested remedy Comment Type TR Comment Status A would not satisfy the PAR and 5 Criteria. Per recent changes, we should begin including the front matter in the draft by Sponsor Ballot. Numerous prior projects performed amendments to the base standard. The scope of the changes described in the draft is consistent with past practice. With regard to the specific SuggestedRemedy example given in the suggested remedy, the combination of physical layers described in This is classified as a TR to assure it is implemented prior to Sponsor Ballot.