Subject: [Madinas] Roman Danyliw's No Objection on charter-ietf-madinas-00-03: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 08 Sep 2021 12:49:22 -0700

Roman Danyliw has entered the following ballot position for
charter-ietf-madinas-00-03: 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:
----------------------------------------------------------------------

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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 9 Sep 2021 12:01:38 +0000

Hello Roman

Thank for your review and your comments. I had no time to check with the MADINAS chairs, but what do you think of

OLD TEXT

NEW TEXT
            recommending means to reduce the impact of RCM on the documented use cases while ensuring that the privacy achieved with RCM is not

Regards

-éric

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 9 Sep 2021 12:58:34 +0000

Hi!

> From: Eric Vyncke (evyncke) <[email-masked]>
> Sent: Thursday, September 9, 2021 8:02 AM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: Roman Danyliw's No Objection on charter-ietf-madinas-00-03:
> (with COMMENT)
> 
> Hello Roman
> 
>             recommending means to reduce the impact of RCM on the documented
> use cases while ensuring that the privacy achieved with RCM is not

Looks good to me.  Thanks.

Regards,
Roman