Subject: [Madinas] Benjamin Kaduk's No Objection on charter-ietf-madinas-00-01: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 11 Aug 2021 21:57:25 -0700

Benjamin Kaduk has entered the following ballot position for
charter-ietf-madinas-00-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-madinas/

----------------------------------------------------------------------
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?