Subject: [Drip] New Version Notification - draft-ietf-drip-reqs-12.txt

From: [email-masked]
Date: Sun, 23 May 2021 19:16:03 -0700

A new version (-12) has been submitted for draft-ietf-drip-reqs:
https://www.ietf.org/archive/id/draft-ietf-drip-reqs-12.txt
https://www.ietf.org/archive/id/draft-ietf-drip-reqs-12.html

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-drip-reqs/

Diff from previous version:
https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-reqs-12

IETF Secretariat.

---

From: "Card, Stu" <[email-masked]>
Date: Sun, 23 May 2021 22:23:11 -0400

all, esp. Eric --

I hope this version adequately addresses all outstanding issues. All please
review to be sure, as I understand it is going to IETF Last Call
immediately!

Below are Eric's comments on the previous rev -11, my responses, his
rebuttals and my dispositions in this new rev -12.

    -- Section 4.1 --
    ...
    GEN-6: should the communications also be authenticated ?

    [Stu] inserted "mutually authenticated" before "end-to-end strongly
    encrypted" in numbered requirement.

EV> and adding a typo ;-)

[Stu] Arghh! Thanks for catching it; fixed.

GEN-7: unsure whether the message frequency is really about QoS
(suggest to find an alternative to QoS)

[Stu] if there is some other term that broadly encompasses the
ability of administrators to write policies specifying acceptable
bounds on rate, latency, reliability, etc., please suggest it so I
can replace "QoS" with it.

EV> I would be happier without the part ", such as ...latencies." or at
least removing the "maximum message transmission intervals", which is
not really clear. As the requirement mentions reliability, if you want
to keep examples, then why not mentioning message loss rate ?

[Stu] Cut ", such as... latencies" from normative requirement, pasted
it into rationale and clarified it with examples including loss rate.

    -- Section 4.2 --

    ID-4: isn't uniqueness implicit for an ID ?

[Stu] usually yes; the point of this requirement is not just that
it should be unique, but also where and when it should be unique
(global scope within a specified space, from registration to
deregistration).

ID-5: I wonder whether 'non-spoofable' is an ID property or an
authentication property... So, moving ID-5 to another requirements
section

[Stu] it is an authentication property, but not just of the
protocol, also of the identifier itself. I think Bob (who wrote the
original version of this requirement) was alluding to a HHIT
embedding a hash of the registry ID and a public key, thus being in
a sense self-authenticating any time the corresponding private key
is used to sign a message. Bob, care to elaborate to address Eric's
comment?

    ID-6: isn't it more about 'privacy' than 'identifier' ?

[Stu] yes, the objective is privacy, but again we desire this not
just of the protocol, also of the identifier itself, as distinct
from the UA serial number.

EV> for all the above ID-* comments of mine, your clarification is
perfect in this email but did not make its way to the document in the
clarification sub-section. I suggest adding them to the clarifications
section to avoid having more comments/questions during the IETF Last
Call. Just a hint, up to the authors.

[Stu] The authors aren't always obstreperous. ;-) Done.

On Sun, May 23, 2021 at 10:17 PM <[email-masked]> wrote:

> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>