Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802-LMSC] P802.15.4ac SA Ballot Recirculation 3 Comments

Clint,

Thanks for providing this feedback. I’m a little confused about the procedure here, because I went to review the comment responses in the recirc and I see that there is no further recirc. I presume, then, that both of my MBS comments were ruled out of scope. However, your responses below do not indicate that they were out of scope. I personally think they were in scope. One of the comments objected to text that was freshly inserted into the latest draft, and another referred to a comment resolution freshly provided in the prior recirc.

To understand the procedural status, I looked back at the process and see that conditional approval to submit to RevCom was agreed at the November LMSC Plenary. As I understand, the Conditions include:

d) No new valid DISAPPROVE comments on new issues that are not resolved to the satisfaction of the submitter from existing DISAPPROVE voters.
I’d like to see how this condition was met with respect to my comments. Were they invalid? Were they not on new issues?

e) If the Working Group Chair determines that there is a new invalid DISAPPROVE comment or vote, the Working Group Chair shall promptly provide details to the IEEE 802 LMSC.
Was this notice provided? Or was it not provided because my comments were ruled as not “new invalid"?

f) The Working Group Chair shall immediately report the results of the ballot to the IEEE 802 LMSC including: the date the ballot closed, vote tally and comments associated with any remaining disapproves (valid and invalid), the Working Group responses and the rationale for ruling any vote invalid.
Was this report provided? Can you show me where I can find it?

Cheers,

Roger
On Feb 26, 2026 at 9:23 AM -0700, Clint Powell <clintonpowell@xxxxxxxxx>, wrote:

Roger,

Thank you for your comments on the 3rd SA Ballot Recirculation of the P802.15.4ac draft. After reviewing and carefully considering your comments the group arrived at the below Disposition Status and Detail. As there are no changes to the draft it has been submitted to RevCom.

As always your time and thoroughness in reviewing all drafts is greatly appreciated and valued, and we look forward to your review and feedback on all future projects/drafts.

Thanks & Best Regards,
Clint

Clint Powell

Managing Director – Wireless IoT Standardization, PWC LLC

IEEE 802.15 WG Chair & IEEE 802 LMSC

IEEE 802.15 TG4ab (NG-UWB) - Vice Chair

CSA IEEE 802.15.4 PHY/MAC Advisory Group - Chair

CSA Aliro CSG Certification Policy & Procedure - Tiger Team Lead

Mobile/WhatsApp: 480 586-8457

Email: cpowell@xxxxxxxx





--

Comment ID: 358623, Comment #: R3-2, MBS: Yes

Name: Marks, Roger

Category: Technical, Page: 20, Subclause: 10.9a.2.5, Line: 30

Comment:

The response to R2-2 says "there is no requirement that

requires extended privacy addresses to be globally unique,

they only need to be unique inside the same network." [It also

says "and next higher layers of the same network use same

method to allocate addresses, and for that method to work

properly it needs to maintain some level of uniqueness," which

I don't understand but also seems to support the notion that

some level of uniqueness is required.] However, as has been

indicated in several prior ballot comments, uniqueness is not

specified in the draft. There is no indication that the "next

higher layer" that assigns addresses is obligated to not

duplicate an assignment to multiple assignees, or under what

conditions it may do so (e.g. address reuse after delay). The

new sentence "The next higher layer can use different methods

to generate extended privacy addresses" provides no guidance

of any kind. Furthermore, its focus is on the generation of

addresses, whereas the focus should be on the _assignment_ of

the addresses, regardless of how they were generated. Another

issue that should be clarified regards the possibility that

multiple "next higher layer" entities could be assigning

addresses and whether the resulting possibility of duplicate

extended privacy addresses could ever lead to problems.

Proposed Change:

Restrict the assignment of extended privacy addresses to

provide an acceptably low level of harmful duplication.

Disposition status: REJECTED

Disposition detail:

This standard specifies that the extended privacy address is

provided by the higher layer. The standard specifies a format

for and a means to disseminate privacy addresses, but the

generation and correlation to a specific device is left to the

higher layer. Duplicate detection requires knowledge of

assignments and the algorithms used for generation not

available at the MAC layer (within the scope of this standard)

--

Comment ID: 358622, Comment #: R3-1, MBS: Yes

Name: Marks, Roger

Category: Technical, Page: 20, Subclause: 10.9a.2.5, Line: 30

Comment:

The draft update has added the sentence "The next higher layer

can use different methods to generate extended privacy

addresses." This meaning of this sentence is unclear. Per the

2021 IEEE SA Standards Style Manual, "The word _can_ is used

for statements of possibility and capability, whether

material, physical, or causal (can equals is able to)." So the

higher layer is physically able to use... methods. But are

some of those methods incompatible with the functionality of

the standard? And what methods qualify as "different"? What

are they different from? Is it possible for the higher layer

to use methods that are not different? It is worth considering

how one might wonder how one might write a statement of

conformance to that sentence? Would it be “My implementation

is physically capable to use different methods to generate

extended privacy addresses"?

Proposed Change:

Revise the sentence for improved clarity and specificity.

Ensure that it includes all necessary requirements regarding

the addresses assigned.

Disposition status: REJECTED

Disposition detail:

This standard states that generation of extended privacy

address is done at a higher layer and so out of scope of this

standard. The commenter is correct that this sentence is

stating a possible method that might be employed by a higher

layer entity. This is a correct use of “can”. The

implementation might be physically capable of using other

methods or it might not – thus “it is possible” is correct.




To unsubscribe from the STDS-802-LMSC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-LMSC&A=1