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

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.)

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).

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

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.