| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Colleagues: I’ve finally gotten around to reviewing the PARs from other WG for consideration during the November plenary session. In some cases, I can’t separate my opinions on some items as a member of the RAC from what would be concerns of the 802 WG. As usual, I’m open to the WG recommending some comments as coming from the RAC Chair (me) rather than from the WG (this role conflict is especially true for proposed P802f). Comments on the below are welcome. —Bob ___Possible WG comments follow____ 802f Amendment : YANG Data Model for EtherTypes 5.2.b (project scope) — The first sentence is awkward and could be parsed inaccurately parsed. Propose rewrite from: "This amendment specifies a procedure to generate YANG modules that contain the full EtherType information, including a compact human-readable name, found in the IEEE Registration Authority EtherType public listing.”, to: This amendment specifies a procedure to generate YANG modules that contain full EtherType identified protocol information (typically as found in the IEEE Registration Authority EtherType public listing), and adds a compact human-readable name (not found in the EtherType public listing)." 5.2.b (project scope) — The second sentence is ambiguous, are the errors and omissions in the EtherType public listing or in Std 802? Assuming this is a catch all for maintenance items on Std 802, it should clearly state that is the case. Possibly: "This amendment also addresses errors and omissions in IEEE Std 802 descriptions of existing functionality.” 5.2.b (project scope) — Assuming the second sentence allows maintenance tasks to be performed, the group may want to include in those maintenance changes making Std 802 consistent in its capitalization of EtherType. While EtherType is dominant in Std 802, the existing standard also uses Ethertype. Other 802.1 standards predominantly use Ethertype. Certainly only one capitalization should be used in any given standard, but it would also be nice if 802.1 picked one for gradual enforcement as its standards are revised. No change to the PAR is requested. 5.5 (need) — This description doesn’t clearly record rationale in discussion leading up to proposing this PAR. One important omission is that the IEEE RA listing may be misleading because assignees have not updated the information provided on their application for the EtherType. A standards project is the most efficient way to create an accurate listing of the common names within the industry for the protocols identified by a particular EtherType. 6.1.b (registration activity) — The project being dependent on enhancement of the EtherType public listing is not practical. It is unlikely that the public listing would be enhanced with common names unless such information can reference a standard for the common name (otherwise, update is dependent on the assignee providing the common name, something not likely to happen as desired. 1.1.1 (Managed objects) — The response is somewhat inaccurate. "This project is primarily a management project providing a YANG data model that contains compact human-readable names for the EtherType information found in the IEEE Registration Authority EtherType public listing.” Would better read "This project is primarily a management project providing a YANG data model that defines compact human-readable names for selected EtherType assignments found in the IEEE Registration Authority EtherType public listing.” __________ 802.1AEdk Amendment: MAC Privacy protection 5.2.b (project scope) — The last sentence is a bit obtuse (perhaps intentionally). Assuming this is a catch all for maintenance items on Std 802.1AE, it should clearly state that is the case. Possibly: "This amendment also addresses errors and omissions in IEEE Std 802.1AE descriptions of existing functionality.” 8.1 (additional explanation) — The last sentence references #7.3 which doesn’t appear in the PAR. Probably need a yes answer in 7.3 to get it to appear. Perhaps it would be better to reference a job responsibility title rather than a person. No comment. __________ 802.1CS Standard - Link-local Registration Protocol 4.2 (initial Sponsor Ballot) — Assuming the PAR is recent output of myProject, the PAR form hasn’t been updated to use new names (Standards Committee Ballot). Nothing you can do about that rather than complain via the 802 Task Force. The date though may not be realistic or will require special attention on the ballot. With the SASB meeting before 802 this year, it is unlikely that the PAR modification will be approved by January 2020. 5.2 (scope) — missing space after full stop at end of third from last sentence. 8.1 (additional explanation) — The note should reference a specific PAR item, in this case #5.2. General — There is no to be sure the right CSD is being looked at (until a long way down where LPR is finally mentioned). Please add project identification in the title area.. General — There is no way within the document to determine what in the CSD is being modified. __________ 802.15.7a - Amendment - Defining High Data Rate Optical Camera Communications (OCC) General — This PAR includes multiple unexpanded acronyms, e.g., V2X, ADAS, RF, MIMO, MIMO-OFDM, traditionally comment bait for NesCom members. May as well expand now rather than in response to NesCom comment. 5.2.b (project scope) — The use of “10000” without any thousands separator is inconsistent with IEEE style and with the existing project scope. Suggest using “10,000” for consistency with the base standard scope. 6.1.b (registration activity) — Just creating additional work for the RAC (triggering their review when there isn’t registration activity anticipated isn’t a good reason for answering Yes. This is supposed to be a filter and nothing in the scope, purpose, need or other fields (nor in the CSD) indicates any registration activity. General — The CSD also uses unexpanded acronyms (it is much better than the PAR). Though many may be familiar to most 802 participants please be kind to the others and expand first use of all acronyms (e.g., MIMO, OWC). 1.2.5 (economic feasibility) — The answers are rather terse and in some cases not really responsive. Item b, what does market size have to do with known cost factors, there is no real response to the question. Item c, adding optical transmitters and receivers to a system isn’t firmware, it isn’t obvious what firmware would need to be upgraded when new hardware (perhaps with its OCC relevant firmware included) is added to a system. Item d, if radio equipment isn’t replaced, operational cost are somewhat affected particularly in the infrastructure end of communication (the infrastructure has to support legacy radio communication and new OCC communication. __________ 802.16t - Amendment - Fixed and Mobile Wireless Access in Channel Bandwidth up to 100 kHz 2.1 (title) — Why is “Amendment:” missing at the beginning of the second line? 8.1 (additional explanation) — Is it correct to infer that providing expansions for acronyms in 5.2.a means that the acronyms weren’t properly expanded when the last revision of the scope was done? The 8.1 expansion of TDD in 5.2.b is unnecessary because it is properly expanded in t.2.b. 1.2.4.a (proven technology) — minor grammar problem in third line “have are”, delete “have”, or is more wordy language like the first line of 1.2.4.b what was intended? To unsubscribe from the STDS-802-3-DIALOG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DIALOG&A=1 |