Colleagues,
The IEEE 802.3 PAR review ad hoc teleconference met today and collected the feedback below for consideration by IEEE 802.3 participants. The ad hoc
Please send feedback or suggested changes to me by 12 noon CEST, 28 July 2025. If none is received, I intend to submit the feedback below on behalf
of IEEE 802.3.
With regards,
-Kent
Chair, IEEE 802.3 PAR review Ad Hoc
IEC/IEEE P60802 - Standard - Time-Sensitive Networking Profile for Industrial Automation
PAR comments: none
P802.1Qdq - Amendment - Shaper Parameter Settings for Bursty Traffic requiring Bounded Latency
PAR Comments:
The reason for extension cites dependence on the revision project as one reason, yet there is no mention of this dependency in the original PAR. Is the delay in the project a RESULT of the dependence (it seems not, that something else happened since the
standard was supposed to be in SA ballot 3 years ago)? If the dependence is not a factor, then suggest delete the sentence beginning “Furthermore” to avoid confusion with the response to 5.3. (note that the PAR for 802.1Q states it IS dependent on the roll
up revision). If the delay has caused the standard to be dependent on the roll-up revision, than I suggest you say that directly in the reason for the extension (since I believe you cannot modify the original PAR response to 5.3).
P802.1Qee - Amendment - Traffic Engineering for Bridged Networks with Significant Delay Variance
PAR Comments:
5.2b Scope. Suggest “This amendment specifies procedures and YANG to…” should be “This amendment specifies procedures and YANG data models to…” (YANG is a data modelling language as described in 8.1, YANG data models are what may be specified…)
5.2b Scope. “to extend bridge attributes for traffic engineering for bridged networks with delay variance beyond that supported by the existing specification.” – suggest that SOME boundary on the delay variance targeted or some additional information
would be useful. Simply saying anything outside the existing specification, in conjunction with the ability to make technical corrections to the existing specification (next sentence) makes the scope the entire world.
5.2b Scope. It is noted that the “technical … corrections to existing IEEE … functionality”. Is this related to the difference in characteristics between wireless and wireline systems described in 5.5?
5.3. Is the term “roll up” revision a standardized term? Consider removing the term “roll up”.
6.1.2 Explanation – it is best not to promise future action. While it is FAIRLY SURE that URNs and OUIs will be used, it is better to say “is expected to use”. (the text for CID is fine).
CSD Comments:
1.2. The way the text of 1.2.1 and 1.2.3 is currently written. It does not explain what specifically the scope of the work is. For example, it isn’t clear to use as to whether this project addresses more than just wireless network technologies? Would
you please provide specific examples of wired network, if intended to be included?
1.2.1a The phrase “these markets” in the last sentence was confusing as to what it specifically refers to. Is it wireless and wired bridged network markets? Or is it a traffic engineering application markets? The suggested change is to combine these
into one sentence, such as “The need for supporting wireless and wireline systems in the same bridged network is increasing in markets and applications that use traffic engineering; including professional audio/video and industrial automation for applications
such as flexible factory automation”
1.2.4 Technical Feasibility: The responses to technical feasibility speak ONLY to the capabilities in the base standard, yet the amendment seeks to extend those capabilities to links “with more uncertain delays” than those in the base standard, something
it claims is not in there. Therefore, these responses are not relevant to the amendment being proposed. Please provide some support that the suggested delays can be supported. (note – this may also be useful in setting some boundary to the scope as suggested
above).
1.2.5 Economic Feasibility: (a) to say that it “will not add hardware cost” is to promise future action, and may not be true. For example, management extensions might require additional memory of monitoring functionality. Suggest “are not expected to
add”. Also, “beyond the minimal and firmly bounded resources consumed by additional management modules” doesn’t really have meaning. If I take this to an extreme, such resources are not obviously “firmly bounded” or even “minimal”. Suggest delete, or replace
by “beyond the resources consumed by management modules required for the existing specification”, or, if this phrasing is needed, additional explanation as to what “minimal” is relative to and what “firm bounds” are meant.
(b) (c) (d) replace “will” which promises an outcome or future action where possible, suggest “is not expected to” unless it is bounded by the scope. (potentially “c” is)
P802.11bt - Amendment - Post-Quantum Cryptography
PAR Comments: none
CSD Comments: none
P802.11bi - Amendment - Enhanced Service with Data Privacy Protection
PAR Comments: none