MAC Address Device Identification for Network and Application Services
charter-ietf-madinas-01

Note: This ballot was opened for revision 00-03 and is now closed.

Ballot question: "Do we approve of this charter?"

Alvaro Retana Yes

Comment (2021-09-03 for -00-03)
Just a small editorial nit: s/examine other IETF work and other standards (e.g., IEEE)/examine other work from the IETF and other SDOs (e.g., IEEE)

Benjamin Kaduk Yes

Comment (2021-09-08 for -00-03)
Thanks for the updates since the previous IESG evaluation; the changes
look good!

I still, as an editorial matter, am not sure how how the following two
sentences are to be connected to each other:

    The Working Group will work together with other IETF WGs (e.g., DHC,
    IntArea), and will liaise with other relevant organizations such as IEEE
    802 and the Wireless Broadband Alliance (WBA). The Working Group will
    coordinate on the different recommendations, as well as potential
    follow-up activities within or outside the IETF.

Erik Kline Yes

Éric Vyncke Yes

Comment (2021-09-01 for -00-03)
After 2 BoF and a first IESG internal evaluation the draft charter was updated. If the external evaluation goes well, then we should approve this charter: RCM has an impact on some deployments and the current charter prohibits protocol work.

Francesca Palombini No Objection

John Scudder No Objection

Comment (2021-09-09 for -00-03)
Nit: I’ve never seen MAC expanded as “medium access control“, I’ve always seen “media access control“. I can see why the singular makes more sense than the plural; nonetheless, wouldn’t it be better to follow established practice? (That said, I wasn’t able to find an authoritative expansion of the acronym, although I didn’t look very hard.)

Nit: BCP is “best current practice“, not “best common practice“. (Two places.)

Lars Eggert No Objection

Martin Duke No Objection

Martin Vigoureux No Objection

Comment (2021-09-08 for -00-03)
Hi

the first document will include requirements, but it is not entirely clear from the charter description when will requirement work be done and for what purpose?
Is it to identify the relevant identifiers, to prepare solution work in case there is a gap somewhere, ...?
It's not critical but a clarification would help.

-m

Murray Kucherawy No Objection

Robert Wilton No Objection

Comment (2021-09-08 for -00-03)
It might be helpful to flag the charter on the ieee-ietf-coord list to ensure that our IEEE friends are aware that a potential WG of interest to them is about to be chartered.

Roman Danyliw No Objection

Comment (2021-09-08 for -00-03)
More clarity on the what the BCP will specify is needed.  Per Paragraph 4:

	The group will generate a best common practices (BCP) document recommending	
	means to ensure that the privacy achieved with RCM is not compromised. For	
	scenarios where device identity stability is desirable, the BCP document will	
	recommend existing protocols that can be used to protect the request and	
	exchange of identifiers between the client and the service provider.

-- (nit) s/the privacy achieved with RCM/the privacy properties provided with RCM/

--  Context got lost with the edits in -03 in the first sentence.  If RCM is already achieving the needed privacy properties, what is the BCP suggesting?

-- The first and second sentence seem to be talking about different things (perhaps even conflicting).  I thought that the privacy service that RCM provided was that the client will emit a non-static (random) layer two identifier.  The first sentence seems to be saying that the BCP will ensure this property.  However, the second sentence, which suggest the work of the BCP, is noting different properties: supporting "device identifier stability" (the opposite of what RCM is trying realize) and "protect[ing] the request and exchange of identifiers between the client and the service provider" (RCM seems silent on this property).  It seems like this discrepancy could be clarified by discussing the device identity from the perspective of the network/application services surveyed in (i).

Zaheduzzaman Sarker No Objection