Colleagues,
The IEEE 802.3 WG provides the following comments on the PARs/CSDs under consideration at the July 2024 Plenary meeting:
With regards,
-Kent
Chair, IEEE 802.3 PAR review Ad Hoc
802.1DD -Standard - Resource Allocation Protocol
PAR Comments: none
CSD Comments:
1.2.1 avoid the use of “vendors … will participate” because of the individual process. Change to “Individuals affiliated with multiple vendors and users for….”
1.2.3 Clarification requested. The distinct identity response says in the first paragraph that no existing standard provides dynamic resource allocation. Then the second paragraph says that the project replaces an existing standard.
We interpret it to mean that the current standard does not provide dynamic resource allocation and the new one (that replaces an existing draft standard) will add this capability through replacement. Is this correct? What is the status of the IEEE P802.1Qdd
project that this PAR proposed to replace?
1.2.4 expand acronym of SRP. It is not defined in the CSD. Please define at its first use.
802.1ASed - Amendment - Fault-Tolerant Timing with Time Integrity
PAR Comments:
5.2.b: add “gPTP” as an acronym in section 8.1
CSD Comments:
1.2.1 avoid the use of “vendors … are participating” because of the individual process. Change to “Individuals affiliated with multiple vendors and numerous users ….”
1.2.4 expand acronym of gPTP. It is not defined in the CSD. Please define at its first use.
802.1DP - Standard - Time-Sensitive Networking for Aerospace Onboard Ethernet Communications
PAR comments: none
802.1AB-2016-rev - Standard - Station and MAC Connectivity Discovery
PAR comments: none
802.1AC-2016-rev - Standard - MAC Service Definition
PAR comments:
5.2: add “ISS” as an acronym in section 8.1
802.11-2024 - Standard - Wireless LANs
PAR comments: none
802.11bf - Amendment - Enhancements for Wireless Local Area Network (WLAN) Sensing
PAR comments:
2. change “SA” to “IEEE SA”
802.16t - Amendment - Fixed and Mobile Wireless Access in Narrowband Channels
PAR comments:
2. change “SA” to “IEEE SA” in two places
802.15.4ae - Amendment - Ascon cryptographic algorithms
PAR comments:
5.4 Does this amendment delete the purpose clause of the base standard, since the “change to purpose” section is stricken out?
CSD comments:
- improve clarity of the response. Change “Yes.” To “Yes, the definitions will be part of the project.”
- grammatical error. Change “No CA document needed...” to “No CA document is needed...”
1.2.1 There is a asterisk character after “AES-CCM” which may be spurious. If it references a note, the note is missing. Also, the second sentence in the first paragraph of the response is confusing to the reader and difficult
to parse. Consider changing it to “Adding the more efficient drop in replacement cipher Ascon-128 and/or Ascon-128a will make more lightweight implementations available.”
Also, readability in the last sentence of the first paragraph. Consider changing to “…as the NIST…” or “…as a NIST…” please clarify in this sentence if there is a group or only one algorithm, etc.
1.2.2 Is this the “no” response from the IEEE 802.1 WG?
1.2.3 Improve readability of the last sentence in the response, as it is difficult to parse. Change to “Adding Ascon-128 and/or Ascon-128a will allow using the more lightweight cryptographic algorithm and offers functionality not
available in AES (like hashing and key material extraction) that supports more use cases than AES.”
1.2.4 Typo. Change “competetion" to “competition”
1.2.5 Change “cheaper” to “lower cost”. Change “impementations” to “implementations”
802.15.9a - Amendment - Ephemeral Diffie-Hellman Over COSE (EDHOC) KMP
PAR comments:
5.4 Does this amendment delete the purpose clause of the base standard, since the “change to purpose” section is stricken out?
CSD comments:
- improve clarity of the response. Change “Yes.” To “Yes, the definitions will be part of the project.”
1.1.2 grammatical error. Change “No CA document needed...” to “No CA document is needed...”
1.2.1 grammatical error. Change “with existing KMPs” to “with the existing KMPs” also “in the typical”
1.2.2 Is this the “no” response from the IEEE 802.1 WG?