| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Colleagues, I’ve run through the PARs submitted by other WGs for March IEEE 802 consideration. I’ve got a few comments that follow. There are a couple items that I think need significant improvement, so I always welcome comments whether in contradiction to my comments below, or for improvement or addition to possible 802.3 comments. (I do know one below that 802.3 would be unlikely to submit as written.) —Bob _______ P802.1Qdt - Bridges and Bridged Networks - Amendment: Priority-based Flow Control Enhancements No comments. The CSD should be readable on its own. It does not include the expansion of a number of acronyms, nor the helpful information in 8.1 of the PAR pointing at the standards specifying the protocols identified only by an acronym. 1.2.1,a — This is the first occurrence of PFC. The only place where Priority-based Flow Control occurs is in the title which does not include the acronym. Please change the last sentence to “Priority-based Flow Control (PFC) …”. 1.2.1,b — MACsec is not expanded/defined. At a minimum, replace “MACsec” with MACsec (802.1AE specified MAC security)”. 1.2.4,b — DCBX is not expanded/defined. Please do so. Similar for PTP, not expanded/defined. _______ P802.1DU - Cut-Through Forwarding Bridges and Bridged Networks General — I have had discussion with some 802.3 members that have general concerns about this project. I encourage them to highlight such concerns. 5.2 — "This standard also specifies requirements and recommendations…” So this project intends to include both mandatory requirements as well as informative recommendations? Said another way it intends to be both a Standard and a Recommended Practice contrary to what is specified in 1.2. Pick what the document is supposed to be or submit two PARs. General — The use of continuous lettered list across separate criteria is confusing. Note 1.2.2, i) where the sub criterion references “a)" yet what is “a)" in the LMSC Operations Manual here is lettered “h)”. So not only is this project proposed to be non-compliant with Std 802, the CSD for the project is non-compliant with the CSD requirements (sarcasm intended). 1.2.2, h — This is an area where work is needed to establish an 802.3 comment (based on my discussions with others). 1.2.2, i — On reading, it isn’t clear that this is an approved response from the 802.1 WG. It reads more like a response proposed by the proponents of the CSD to 802.1. Perhaps quotes for what was approved and and a recorded vote of the 802.1 WG would be helpful to understand what the 802.1 response really is. 1.2.5, m — This doesn’t seem to be an answer to the question. 1.2.5, p — CTF bridges violate the MAC Service interface where a transmission request is an atomic action. CTF starts a transmission before an entire frame is received and error checked. The CSD ignores the impact CTF bridges have on MAC capabilities and may not be compatible with existing MAC implementations. The CSD also ignores the impact on management. Will CTF require changes to the MAC Service interface (e.g., changing the atomic nature of the MA_DATA.request). CTF potentially produces truncated frames, the CSD ignores the possible impacts on management and potential increases to undetected error rates (changing the received data stream of an existing end-station). In other words, there are potential ecumenic impacts to existing networks because of potential errors. [This is another area where 802.3 consensus on a response is important.] _______ P802-REV - Overview and Architecture 5.3 Contingencies — The term “prior base standard” is ambiguous and technically inaccurate (it presumes approval of this revision which hasn’t occurred yet). The proposed P802 revision is unambiguously a revision of IEEE Std 802-2014 as noted at the top of the PAR (included amendments implied by IEEE SA rules). Perhaps change to read "IEEE P802f is progressing as an amendment to IEEE Std 802-2014. This revision is dependent on the approval of IEEE Std 802f-20xx.” 6.1.2, Explanation — There are a lot of unexpanded acronyms here. NesCom might ask for their expansion in 8.1. (Though the RAC will be familiar with them without expansion.) _______ P802.15.12 IEEE Standard for Low-Rate Wireless Networks withdraw: Enhanced Ultra Wide-Band (UWB) Physical Layers (PHYs) and Associated MAC Enhancements Background Information: https://mentor.ieee.org/802.15/dcn/22/15-22-0049-00-0000-p802-15-12-par-withdraw-overview.pptx 802.15 WG approved with the voting of 48/0/2 (Y/N/A) No comments. _______ P802.15.6a IEEE Standard for Local and metropolitan area networks - Part 15.6: Wireless Body Area Networks withdraw: Dependable Human and Vehicle Body Area Networks 802.15 WG approved with the voting of 50/0/5 (Y/N/A) No comments. _______ P802.15.6ma IEEE Standard for Local and metropolitan area networks - Part 15.6: Wireless Body Area Networks revision: Dependable Human and Vehicle Body Area Networks 5.2 — BAN is an unexpanded acronym. Recommend an 8.1 note explaining that BAN is body area network, which covers both VBAN and HBAN. 6.1.2 — IEEE Std 802.15.6-2012 does include registry content (OUI at a minimum). Answer should be Yes, with an explanation something like: "The Registration Authority Committee may wish to review to assure usage of registries and registry is terms are consistent with current usage.” Obviously if the new content will use or define any registry, then the explanation might need to change. 802.15 WG approved with the voting of 53/1/6 (Y/N/A) General — Thank you for your careful adherence to LMSC procedures and for supplying a CSD for the revision when the intent is to add significant new functionality (not just revision to roll up amendments and maintenance items). 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 |