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

Changed charter milestone "Best Practices handling RCM document submitted to the IESG for publication", set description to "Best Current Practices handling RCM document submitted to the IESG for publication"

Changed charter milestone "Use Cases and Requirements (informational) document submitted to the IESG for publication", set description to "Use Cases and Identity Requirements (informational) document submitted to the IESG for publication"

[Ballot comment]
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.)

[Ballot comment]
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).

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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

[Ballot comment]
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)

[Ballot comment]
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.

[Ballot comment]
After 2 BoF and a first IESG internal evaluation, and if the external evaluation goes well, then we should approve this charter: RCM has a impact on some deployments and the current charter prohibits protocol work.

[Ballot comment]
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.

[Ballot comment]
  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?

[Ballot comment]
(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?)

[Ballot comment]
(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.