| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Colleagues: I’ve again taken a pass through the proposed PARs for the next meeting (March). Most of my comments are picking at nits (typographical errors, grammar, ambiguities in text, etc. Exceptions: 1. P802.1Qcz has me a little confused as written since it could be either one or two projects depending on what the content actually is. 2. P802.11bb almost seems like two different projects or target markets based on descriptions and justifications in the PAR and the CSD. Those two documents should be more in agreement on those fundamental points. 3. As RAC Chair, I have concerns about over-reaction on the RAC Mandatory Coordination question (6.1.b). In November, the ad hoc felt I should submit my 6.1.b concerns directly as Chair of the RAC, rather than from the WG. Proposed draft comments follow. —Bob P802.1CBcv - Amendment: Information Model, YANG Data Model and Management Information Base Module No comments. 1.2.1.b — Though numbers are significant, they are rather dated, isn’t more current data available to justify market sizes? In the second paragraph, a 2014 projection is especially awkward as that was a projection from 8 years ago for a year where actual data is more than 3 years old. 1.2.1.b — Though 802.3 folk will eventually understand FE:GE:10+GE, the acronyms without definition are likely to cause other folk problems (Fast Ethernet is especially archaic as it isn’t directly a speed of operation). __________ P802.1DC - Standard for Quality of Service Provision by Network Systems No comments. __________ P802.1CBdb - Amendment: Extended Stream Identification Functions Note to 802.3 colleagues: This project is dependent on P802.1CBcv (item 5.3), the dates in 4.2 have CBcv entering Sponsor ballot a bit earlier than this project, but submittal to RevCom at the same time. This is possible to manage and the contingency here in 5.3 should prevent CBdb getting approved ahead of CBcv. No comments. __________ 802.1Qcz - Amendment: Congestion Isolation Note to 802.3 colleagues: This project is dependent on P802.1ABcu (item 5.3), the dates in 4.2 trail ABcu by more than a year, nothing uncommon for amendment ordering (even though these are different standards. 5.3 — It certainly isn’t clear why an extension to 802.1ABcu specifications is in a P802.1Q amendment. The scope of 802.1AB and 802.1ABcu indicate that the appropriate location for such specifications would be in 802.1AB. Explain why the PAR should not be split into two amendments (or split the PAR into two projects), one for 802.1Q and another for 802.1AB. If on the other hand, “extension” is a misleading word, rephrase. (e.g., This project will reference and require use of capabilities being specified in P802.1ABcu.) If extend is a misleading word, then also correct the Explanation in 6.1.b. 8.1 — It looks like a cut and paste included too much. OID is not referenced in 6.1.b of this PAR. Either correct the Explanation in 6.1.b, the project scope, etc. to include SNMP management requiring OID, or remove the OID line from 8.1. General — It is helpful to identify what project the CSD justifies (other than in the file name). Other 802.1 projects do this following the title. __________ P60802 - Standard: Time-Sensitive Networking Profile for Industrial Automation, 1.2 — The project being a full standard seems to be at odds with language in Scope and Need, where the document is described as providing profiles and guidelines. These types of things are often provided in Recommended Practice standards. Note to 802.3 colleagues: This project is dependent on the P802.1AS revision project (item 5.3), the dates in 4.2 trail AS-Rev by a couple years. No comments. __________ P802.11bb - Amendment: Light Communications (LC) General — Because of observed inconsistencies, it appears that this PAR was not generated on the myProject system. The myProject system should be used. It provides easy access to instructions, assures use of current forms (simplifying review) and minimizes entry errors after 802 approval. 5.5 — This need statement mostly expresses a technology push based project, not a market demand justified project. The increase in availability of unlicensed spectrum provided by light covered in the Broad Market Potential is better at justifying from a market side than does this need statement. 5.6 — So a company that views itself as an established IoT company isn’t a stakeholder? A small or medium sized industrial manufacturer isn’t a stake holder? Delete “established”, “large”. 5.6 — The stakeholder list does not agree with the CSD Broad Market Potential answer. The Broad Market answer basically says light communications is applicable everywhere existing radio PHY wireless LANs are used. 6.1.b — Had the PAR been prepared on myProject, the person preparing the PAR would know that an explanation is required for a yes answer. Is a new registry being proposed? Is the amendment expected to produce new text with registry related content? (If so, what registry?) If the amendment will only be using existing capabilities (e.g., using and not modifying existing specifications for transmission of frames, and not changing or adding specifications for what addresses are used in those frames) then that is not a registry activity. The PAR form instruction 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. 7.1 — Had the PAR been prepared on myProject, the person preparing the PAR would know that an explanation is required. Why an additional standard is needed for a yes answer, not just a list of the similar scope standards. The PAR form instruction reads: Identify any standard(s) or project(s) of similar scope(s), both within or outside of the IEEE, and explain the need for an additional standard in this area. 1.2.4 — Note to 802.3 colleagues. Do those of you with optical expertise find the answers satisfactory (e.g., multipath via reflections). It seems to a novice that "communications occur primarily inside the cone of the light” (end of 1.2.1,a) alludes to directionality, but uses the weasel word “primarily”. Do any of our optics experts recommend comment on this area? The assertion that there are non-standard systems running implies that these problems have been solved — but for what types of environments? We have already approved 802.15 VLC projects, so perhaps the cow is already out of the barn for these questions. __________ 802.15.4w - Amendment: LPWA (Low Power Wide Area) 5.3 — Question is not answered, please do so. 6.1.b — Not sure who recommended review but if so, the RAC Chair is unaware of a recommendation from the RAC or from editorial staff (typically occurring because of content found in MEC review. RAC review can also be requested by the WG/TG later without a PAR modification if "not anticipated" registry related content appears in the draft.) Please refer to the PAR form instructions for when a Yes answer is appropriate and consider if the answer should be changed to No. (The RAC has reviewed IEEE Std 802.15.4.) 1.2.5,c — The answer about manufacturing costs is non-responsive to the question about installation costs. Please provide a responsive answer. 1.2.5,d — Change IEEE Std. 802.15.4 to IEEE Std 802.15.4 (remove the dot after Std). __________ P802.15.4x - Amendment: FANE (Field Area Network Enhancements) 6.1.b — The RAC Chair is not aware of a recommendation from the RAC to review this project (nor it being flagged for review by editorial staff, typically occurring because of content found in MEC review, nor in general PHY oriented projects. RAC review can also be requested by the WG/TG later without a PAR modification if "not anticipated" registry related content appears in the draft.) Please refer to the PAR form instructions for when a Yes answer is appropriate and consider if the answer should be changed to No. (The RAC has reviewed IEEE Std 802.15.4.) 1.2.1,b — Change IEEE Std. 802.15.4 to IEEE Std 802.15.4 (remove the dot after Std). 1.2.5,c — The answer about manufacturing costs is non-responsive to the question about installation costs. Please provide a responsive answer. __________ P802.15.4y - Amendment: SECN (Security Next Generation) 2.1 — As an amendment to 801.15.4, it is unnecessary to repeat what standard the extensions are for (especially when Std in incorrectly followed by a dot). Also the title doesn’t need to include a repeat of the project scope. How about Amendment Security extensions (preferred) or Amendment Security extensions including Advanced Encryption Standard (AES)-256 5.2.b — Change IEEE Std. 802.15.4 to IEEE Std 802.15.4 (remove the dot after Std). 5.2.b — The possible does not seem to be properly placed in: “It also defines possible methods to simplify the addition of future encryption modes and key lengths.” Is the project really planning to define a set (“methods") of ways to add new modes and keys; or is the possible supposed to mean the project may or may not define a method to simplify adding new keys and modes? Title — If PAR title is changed per comments, also change on the CSD. 1.2.1,a — Not all that responsive to the question about broad applicability. Isn’t the point that 802.15.4 has significant market presence and that addition of better security is demanded for that broad application base, and continued deployment to 802.15.4 will require better security? Adding something on that line might make the answer more responsive to the question. 1.2.3 — Change IEEE Std. 802.15.4 to IEEE Std 802.15.4 (remove the dot after Std). 1.2.3, last sentence — Should it read: "The SECN extensions will be unique from features in the existing standard which is currently limited to AES-128 encryption or no security." __________ P802.15.4z - Amendment: EIR (Enhanced IR-UWB Ranging) 5.5 — Change IEEE Std. 802.15.4 to IEEE Std 802.15.4 (remove the dot after Std). 6.1.b — The RAC Chair is not aware of a recommendation from the RAC to review this project (nor it being flagged for review by editorial staff, typically occurring because of content found in MEC review, nor in general PHY oriented projects. RAC review can also be requested by the WG/TG later without a PAR modification if "not anticipated" registry related content appears in the draft.) Please refer to the PAR form instructions for when a Yes answer is appropriate and consider if the answer should be changed to No. (The RAC has reviewed IEEE Std 802.15.4.) Broad Market, a — Typo and grammar: “is a widely” -> “is widely”, “Ihings” -> “Things" Broad Market, b — Doesn’t the phrase "into automotive remote control and associated Smart Phone Applications, to cite just one example” have two examples? Distinct Identity — Change IEEE Std. 802.15.4 to IEEE Std 802.15.4 (remove the dot after Std). Technical Feasibility, b — Change IEEE Std.802.15.4 to IEEE Std 802.15.4 (replace the dot after Std with a space). __________ P802.22.3 - Standard: Spectrum Characterization and Occupancy Sensing PAR Modification to a revision PAR No comment. Per Executive Committee email, will be deferred to a future meeting. 1.2.3,a — Typo: "Characteization" 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 |