Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[802.3_DIALOG] July PARs from other WGs

Colleagues:

I’ve taken a pass at review of proposed PARS from other WG that will be considered in July.  I have a lot more comments on the PARs wearing my RAC Chair hat than I do as a member of 802.3.  If an ad hoc is appropriate to generate 802.3 comments, I am certainly willing to segregate comments that are RAC concerns from others if the possible ad hoc feels that would be appropriate.

My comments follow below.

—Bob


General comment on 802.1 PARS from the Chair of the IEEE Registration Authority Committee:

Though 802.1 helps define the usage of many registry terms within standards that it maintains, it seems that has led to the 802.1 WG thinking it is exempt from RAC mandatory coordination.  This is surprising considering the number of RAC members that participate in the 802.1 Working Group.

Please consider the instructions for 6.1.b when preparing your PARs  (found in myProject the circle i next to the 6.1, B item, or by selecting view all instructions).  On 802.1 PARs, the question on registry activity is most often answered No, without explanation, even when there is registry content within the project, or such content is likely.  (The project not defining a NEW registry, only using established registries, is not a sufficient reason to answer No.)  Proper treatment of the question will reduce the probability of getting late-in-the-process mandatory coordination comments, perhaps even as late as at RevCom.  P802.1CB (a new proposed standard) is an example of the problems.  The latest draft posted on the 802.1 web site has inconsistencies and errors in use of RAC terms, and as a new standard, it certainly has new text specifying use of registries (though possibly much may be copied from other 802.1 standards).  

The PAR form instruction for PAR item 6.1.b copied from myProject reads:

The IEEE Registration Authority Committee (RAC) is a mandatory coordination body. A YES answer to this question provides early notification that RAC mandatory coordination will occur during Sponsor ballot. Working groups are welcome to engage the RAC if appropriate earlier in the project.

If the proposed standard requires (or is expected to require) the unique identification of objects or numbers for use in industry, the project has registration activity. This does not cover things like code points defined within the standard.

A YES answer with brief explanation is appropriate if:

1. The proposed standard creates a new registry.
2. The proposed standard includes new use of an existing registry (whether IEEE RA or other registry authority). An existing IEEE registry example would be use of an Organizationally Unique Identifier (OUI). An explanation of a new registration activity should be supplied on the PAR. Please visit the IEEE Registration Authority website (http://standards.ieee.org/regauth/index.html) for additional information regarding existing registries.
3. When RAC review of previously reviewed text is appropriate to assure terminology and descriptions of usage are current.

A NO answer is appropriate:

1. When the project has no registration activity.
2. When a project modifying an existing standard with registration activity will not be adding new text nor modifying existing registration activity text previously reviewed by the IEEE Registration Authority (e.g., corrigendum on non-registry content). Please briefly explain why RAC review is not required.

Please note that the RAC may request mandatory coordination on any project, independent of the answer to this question.

__________

P802.1AE-Rev  - Timing and Synchronization for Time-Sensitive Applications

6.1.b (registration activity) — A quick check shows the standard being revised does include registry content.  IEEE Std 802.1AE-2009  has text specifying use of EUI-64 and many references to EtherType.  Because both capitalizations EtherType and Ethertype are used, it would be likely the RAC would want consistent capitalization at a minimum.  The answer should be yes with an 8.1 explanation, possibly that: Registry content has previously been reviewed by the RAC, but the RAC may wish to review for current and consistent usage of terms including EUI and EtherType.
__________

P802.1AS-Rev  - Timing and Synchronization for Time-Sensitive Applications

6.1.b (registration activity) — This should have been answered yes on the original PAR.  (The base document includes use of registry terms (e.g., OUI, Ethertype, EUI-64, EUI-48 and also includes text suggesting using a mapping from EUI-48 to EUI-64 that is now deprecated because it potentially creates duplicate EUI-64 addresses.)  As long as you are doing a PAR modification, please correct this oversight with an answer of yes with an 8.1 explanation, possibly indicating:  Registry content has previously been reviewed by the RAC, but the RAC may wish to review for current and consistent usage of registry terms as well as review of expected text changes related to existing descriptions of deprecated EUI-48 to EUI-64 mapping.
__________

P802.1Qcc  - Stream Reservation Protocol (SRP) Enhancements and Performance Improvements
Base standard, Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks Amendment

General — No comments on the extension, other than an observation for staff (the WG may choose to drive followup through their staff liaison) that perhaps the myProject tools are not working as advertised.  The NesCom FAQ indicates a PAR modification is not required to update WG and Sponsor contact information.  This PAR extension (assuming it is pdf output from myProject) does not list the current 802.1 WG Chair, which per the NesCom FAQ, should have been updated when Mr. Parsons accepted his role as 802.1 Chair.
__________

P802.1ABcu YANG Data Model
Base standard, Station and Media Access Control Connectivity Discovery
 
5.2.a (Std scope)— The Scope begins with a sentence fragment.  Assuming the pdf is the output from myProject, staff liaison should be tasked with tracing down the problem and fixing it (the first line of published IEEE Std 802.1AB-2009 scope is not included).

5.2.b (project scope) — Because the base standard includes many uses of OUI that should be updated for alternate use of CID, it would be good for the new YANG specifications to properly allow either OUI or CID for identification of an organization/company.  If not already the subject for an 802.1 maintenance request, hopefully, one of the RAC members participating in 802.1 will initiate a maintenance request for updates allowing use of a CID in lieu of an OUI.  Otherwise, the scope should include update of the base standard for alternate use of CID.  Delaying this to the next revision could quickly obsolete implementations of YANG based on this amendment.

6.1.b (registration activity) — The content of the base standard makes it unlikely that the YANG additions will not include management of objects that include use of these terms.  (The base has extensive use of Ethertype and OUI.)  Please consider if the YANG specifications (or a the suggested maintenance item on CID) will include new text referencing or describing use of registry assignments or terms.  If so, please answer yes with appropriate explanation.  If the appropriate answer is no, then an explanation of the answer to 6.1.b is appropriate.


General — It would appear that 802.1 is not giving the CSD responses serious thought or review before submission to IEEE 802.  Answers are often perfunctory, terse to the point of being generic, and therefore not responsive for the specific project.  The identical and near identical text found in multiple CSD responses for proposed P802.1ABcu, P802.1Qcw, P802.3Qcw, and P802.1CBcv suggest minimal thought after cut and paste.

1.1.1 (management) — The answer (other YANG CSDs) is a bit strange.  The criterion asks nothing about SNMP.  Perhaps simply:  "This project is primarily a management project that adds enabling specifications for management of IEEE 802.1AB implementations through YANG data models.”

1.2.5 (economic feasibility) — The minimal editing of canned responses to this criterion have no justification.  For subcriteria a, it might be appropriate to explain that addition of YANG remote management requires both infrastructure and end-station capabilities similar to those required by SNMP management specifications, and YANG management is expected to have similar balance between infrastructure and end-stations.  The response to subcriterion b is similarly terse and unsupported. For subcriteria c and d, it isn’t clear why a response for VLAN bridges is relevant to Connectivity Discovery.  Why does remote management capability reduce installation cost, an unjustified assertion.  Is there an unsupported implication that YANG is less difficult to install and operate than SNMP?  

__________

P802.1CBcv  Information Model, YANG Data Model and Management Information Base Module
Base standard, Frame Replication and Elimination for Reliability

5.1 (participants) — Please answer the expected number of participants.

5.2.b (project scope) — It is difficult to determine from myProject the status of the base standard being amended (IEEE Std 802.1CB-2017).  There are errors in the latest draft (P802.1CB/D2.8) posted on the 802.1 web site.  If these errors (e.g., improper expansion of CID and inconsistency capitalization of EtherType) in usage of registry terms were/are not fixed in publication preparation, then a maintenance item should be opened to assure they are fixed under the scope of this project.

6.1.b (registration activity) — The inclusion of unspecified OUIs (Other OUI) in encodings make it probable that there will be management attributes associated with the other OUIs, and therefore, the specification of management would probably include specifications related to OUIs.  Please answer yes with 8.1 explanation describing expected usage of registry assignments and terms in the new specifications added by this amendment.



General — It would be helpful when reviewing multiple projects if project identification was included in the CSD document, not just in the file name.

1.2.1, b (broad market) — The last line indicates an expectation for 2014 switch ports.  Perhaps more current actual data is available, if not, rewrite to explain why a 2014 projection is used to justify a project requested in 2017.

1.2.5 (economic feasibility) — On item a, it might be better to indicate that YANG remote management utilizes a balance between end-station and infrastructure capabilities.  Item b seems disconnected from the reality of there being no defined remote management capability.  For items c and d, it isn’t clear why a vague response about VLAN bridges is relevant to management of Frame Replication and Elimination for Reliability.  Why does remote management capability reduce installation cost --an unjustified and  not credible assertion.  One could assume that it is not more difficult to install a box with a few more bits of firmware in its nonvolatile memory; but it isn’t easy to conjecture why YANG capabilities in the box will reduce installation costs, especially if some configuration of the management capabilities might be required, even if the additional capabilities are simply an addition to existing base YANG capabilities (not stated if YANG is already expected to be present in the end-stations and infrastructure).  It is a bit easier for the typical 802 person to conjecture why remote management might help with operational costs in response d, but the response to d is similarly terse.  Would it be more correct to describe that potentially higher installation costs would be offset by significant operational cost reductions?  Alternatively, perhaps the proper cost arguments would be that standardized management will provide benefits over proprietary management capabilities of 802.1CB devices by facilitating greater interoperability for configuring and operation of equipment.
__________

P802.1Qcw YANG Data Models for Scheduled Traffic, Frame Preemption, and Per-Stream Filtering and Policing
Base standard, Bridges and Bridged Networks

5.2.b (project scope) — With a P802.1Q revision projected (at least per its PAR) to be completed this year, this project scope seems a bit strange.  It would appear that this will be a revision to IEEE Std 802.1Q-201x rather than the 2014 revision (we recognize the myProject tool makes this impossible to address in the PAR header information), therefore, it seems likely that the listed amendments for which management items would be considered will all be superseded.  Perhaps the scope for maintenance items should not be restrictive to certain amendments, or indicate listed amendment items not included in the P802.1Q revision.  You may also not want to limit maintenance items to allow inclusion of maintenance items for 802.1Q-201x also.)

5.3 (contingencies) — No explanation given to the Yes.  One assumption is that it is dependent on completion of P802Q so that it can be considered by RevCom per the 3 year 3 amendment rule.  Will this project be dependent on P802.1Qcp providing a YANG base for the capabilities listed in the title?  Will it be dependent on any of the other four approved projects to amend 802.1Q?  Some of this might also deserve description in 5.3.b project scope.

6.1.b (registration activity) — Please reconsider if this question is answered correctly.  Will the new specifications reference registry assignments or terms (Std 802.1Q certainly does).  An 8.1 explanation of the yes or no should not be forgotten (for yes what registries/terns are being used (e.g., OUI/CID or EUI addresses); if no indicate that Per Stream Filtering, does not use registry terms in the operational specifications or the terms will not be used in the YANG specifications).


1.1.1 (management) — The answer (identical to the answer other YANG CSDs)  is a bit strange.  The question asks nothing about SNMP.  Perhaps simply:  "This project is primarily a management project that adds enabling specifications for management of specific IEEE 802.1Q capabilities through YANG data models.”

1.2.5 (economic feasibility) — On item a, it might be better to indicate that YANG remote management utilizes a balance between end-station and infrastructure capabilities.  For item b, if SNMP management is already defined for the subject 802.1Q capabilities, indicating the balance will be similar to that for SNMP management, if not, provide more substance in the response.  For items c and d, it isn’t clear why a vague response about VLAN bridges is relevant to management of Scheduled Traffic, Frame Preemption, and Per-Stream Filtering and Policing.  If this project simply adds to a YANG base capability for the listed 802.1Q functions, that should be stated in a more descriptive response.  What types of existing implementations will it improve installation and operation costs.  Is the cost benefit from eliminating multiple management platforms and this is one more module in a complete YANG solution, that should be stated somewhere and considered in responses to economic feasibility. 
__________

P802.1Qcx YANG Data Model for Connectivity Fault Management
Base standard, Bridges and Bridged Networks

5.3 (contingencies) — If this project is is dependent on completion of the 802.1Q revision so that it can be considered by RevCom per the 3 year 3 amendment rule P802.1Q should also be stated.  Per PAR form instructions, the document titles should also be included in an 8.1 explanatory note (802.1Q title is included in the PAR header).

6.1.b (registration activity) — Please reconsider if this question is answered correctly.  Will the new specifications reference registry assignments or terms (Std 802.1Q certainly does).  An 8.1 explanation of the yes or no should not be forgotten (for yes what registries/terns are being used (e.g., OUI/CID or EUI addresses); if no indicate that Connectivity Fault Management does not use registry terms in its operational specifications or the terms will not be used in the YANG specifications).  Based on a recent ProCom ad hoc, CFM op code assignments are made and will be coordinated in the 8.1 note.  If not answered yes, the ad hoc work should cause this project to be flagged for RAC review anyway because those assignments are by IEEE-SA definition, a registry.


1.1.1 (management) — The answer (identical to the answer for other YANG CSDs) is a bit strange.  The question asks nothing about SNMP.  Perhaps simply:  "This project is primarily a management project that adds enabling specifications for management of specific IEEE 802.1Q capabilities through YANG data models.”

1.2.5 (economic feasibility) — On item a, it might be better to indicate that YANG remote management utilizes a balance between end-station and infrastructure capabilities.  For item b, if SNMP management is already defined for the subject 802.1Q capabilities, indicating the balance will be similar to that for SNMP management, if not, provide more substance in the response.  For items c and d, it isn’t clear why a vague response about VLAN bridges is relevant to management of Connectivity Fault Management.  If this project simply adds to a YANG base capability for the listed 802.1Q functions, that should be stated in a more descriptive response.  What types of existing implementations will it improve installation and operation costs.  Is the cost benefit from eliminating multiple management platforms and this is one more module in a complete YANG solution, if so, that should be stated somewhere and considered in responses to economic feasibility. 
__________

P802.1ACct Support for IEEE Std 802.15.3
Base standard, Media Access Control (MAC) Service Definition

6.1.b (registration activity) — Please reconsider if this question is answered correctly.  Will the new specifications reference registry assignments or terms (Std 802.1AC has significant reference to EtherType).  An 8.1 explanation of the yes, or no should not be forgotten (for yes what registries/terns are being used (e.g., EtherType usage for EPD or LLC protocol encapsulation); if no indicate that addition of 802.15 specifications is not expected to add new text using registry terms.  

7.2 (joint development) — It might be appropriate to add a note in 8.1 that:  7.2, though not technically a joint development, 802.15 members that desire access will be invited to review drafts throughout the development process.  (Assuming that the customary offer from 802.1 to other 802 WGs is extended to 802.15 on this project.)


1.1.2 (coexistence) — Because 802.11 is already included in the base document, the statement that it is connecting to the wired world is not necessarily correct.  The specifications will indicate the connection of of 802.15.3 to a bridging architectural entity.  The answer could be improved for clarity and accuracy.  The project will add specifications for a wireless technology, but those specifications are well above the physical layer and therefore will not involve coexistence issues related to use of wireless spectrum.  

1.2.1, a, last sentence (broad market) — The ISS is far removed from the 802.14.3 media, and the sentence should be rewritten.  Perhaps:  Attaching IEEE 802.15.3 networks to . . .

1.2.5 (economic feasibility) — For item a, it might be more accurate to indicate that the specification is for bridges, and they are typically considered part of the infrastructure of networks.  It adds functionality to bridging but does not change the balance.  Item b, would be more accurate if stated: Similar to other wireless specifications currently included in IEEE Std 802.1AC.