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

It might be helpful to remind them early and/or often that normative reference to any IEEE documents behind a paywall will need to be resolved preferably before the documents reach the IESG.

I think the two documents shown as outputs in milestone #1 could be a single document.

(1) Can the scope of the work be refined?

“Currently, many use cases and applications make an implicit assumption about the unique association between the device identity and its MAC address. ... This requires updating applications to function across MAC address changes.”

This text suggests explicit changes are needed.  However, it isn’t clear what exact IETF protocols are now broken due to RCM that might bound this exploration.  Is this an instance of “we know we have a problem but we don’t sufficiently understand the scope” yet?

(2) The phrase “personal device identity” is used twice.  Is that a term of art?  Is it the same as “Layer 2 device identifier”? or “device identifier”?

(3) Per “The group will also evaluate various identifiers (i.e., beyond the MAC address) that can be used by the network to provide services, as well as scenarios where personal device identity is not required”:

-- is this “evaluat[ion] [of] various identifiers” strictly bound to previously published specifications for identifiers?  If not, this suggests “new solutions” work subject to recharter later in the text.

-- It would seem that an evaluation would have to be done in context of specific protocols.  Are these protocols known at this time?

(4) Per “An Informational Use Cases and Requirements document (e.g. draft-henry-madinas-framework)”, this deliverable doesn’t naturally fall out of the previous charter text for me.  Specifically:

-- I stumbled over the term “MADINAS use cases” as the WG isn’t intended to create solutions.  Is it an enumeration of existing protocols, applications and operational practices where MAC addresses are used for identity?

-- A requirements document for what audience and for what purpose?  (e.g., is it for end device vendors implementing RCM? application owners relying on static MAC addresses? Other SDOs?)

(1) I am glad that this work is being done, but there's a disconnect, at least for me, between the main text of the charter and the deliverables.  IOW, it is unclear what this WG will produce and how the actions in the charter map to the documents.  To be explicit:

(a)
   The MADINAS Working Group will examine the effect of RCM schemes on 
   network and application services in several scenarios identified as 
   relevant.

What should "examine the effect" result in?  For which scenarios?  I can see how this item can result in both use cases (scenarios) and a current state-of-affairs document on MAC randomization (examine the effect).  Is that the intent?


(b)
   The group will also evaluate various identifiers (i.e., beyond the MAC 
   address) that can be used by the network to provide services...

This part sounds like a solution: the identifiers can be used by the network. But, where will these identifiers come from?  Other IETF WGs?  What will be the result of the evaluation?


(c)
   The group will also evaluate...as well as scenarios where personal device identity is not required.

This is the second part of the sentence in (2).  There doesn't seem to be a clear relationship between identifiers and scenarios (feels like comparing apples and oranges).  What will be the result of this evaluation?


(d) 
   For scenarios where personal device identity stability is desirable, the
   Working Group will recommend protocols that can be used to protect the
   request and exchange of identifiers between the client and the service
   provider. ... The MADINAS Working Group will examine other IETF work that 
   may be applicable.

It is not clear whether the recommended protocols will come only from a set of existing IETF work or if the WG can develop new ones. Also, where will the recommendations be documented?     


(e) 
   For scenarios where privacy is paramount, the group will recommend best 
   practices to ensure that the privacy achieved with RCM is not compromised 
   by the communication of other identifiers.

It sounds like this might match the BCP document...but only for some scenarios?


(2) Personally, I believe it is not a good idea to mention specific documents (even as examples) as the eventual WG may decide to go in a different direction.

  Currently, many use cases and applications make an implicit
  assumption about the unique association between the device identity and its MAC
  address. [...]

"Unique association" implies a bidirectional invertible map, i.e., both that
knowing device identity implies knowing MAC address, and that knowing MAC
address implies knowing device identity.  Are these two relationships
seperable -- that is, do some use cases only involve one mapping or the other?

Relatedly, I wonder if the existence of such a map implies the ability to
detect invalid MAC addresses and invalid identities (or rather, I wonder what
"identity information" would be associated with an invalid MAC and vice versa,
if it does); does this ability actually exist and is it used?  (I mostly assume
it does not exist, but am open to being surprised.)

  The MADINAS Working Group will examine the effect of RCM schemes on network and
  application services in several scenarios identified as relevant. The group

(editorial?) Identified where/by whom?  Perhaps the sentence should be
reordered to "will identify relevant scenarios and examine the effect of RCM
schemes on them"?

  will also evaluate various identifiers (i.e., beyond the MAC address) that can
  be used by the network to provide services, as well as scenarios where personal
  device identity is not required.

Evaluate on what axes/metrics?
(It's also not entirely clear what it means to "evaluate [...] scenarios where
personal device identity is not required".)

  For scenarios where personal device identity stability is desirable, the
  Working Group will recommend protocols that can be used to protect the request
  and exchange of identifiers between the client and the service provider. For
  scenarios where privacy is paramount, the group will recommend best practices
  to ensure that the privacy achieved with RCM is not compromised by the
  communication of other identifiers. The MADINAS Working Group will examine
  other IETF work that may be applicable.

Applicable for which purpose(s)?

  The Working Group will work together with other IETF WGs (e.g., DHC, IntArea),
  and will liaise with other relevant SDOs 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.

(editorial) I think I'm missing a connection between the two sentences.  Am I
to assume that the "work[ing together and liaising are for the purpose of
coordinating on recommendations and potential follow-up activities?

  1. Document Current State of Affairs:
    An Informational Use Cases and Requirements document (e.g.
    draft-henry-madinas-framework) An Informational MAC Address Randomization
    current state-of-affairs document (e.g.
    draft-zuniga-mac-address-randomization)

Is it intended to publish these documents as RFCs, or just produce a draft
that has obtained WG consensus but is not published as an RFC?  (It's not
entirely clear to me whether the "state of affairs" being documented would be
stable or expected to change on a fast enough timescale to reduce the archival
value of an RFC.)

  2. Document Best Practices handling RCM
    A Best Common Practices document

Best practices for which operations/entities and subject to which goals?  I
see at least "applications" and "network services" mentioned elsewhere in the
charter; are both in scope?