Subject: [Drip] I-D Action: draft-ietf-drip-reqs-11.txt

From: [email-masked]
Date: Tue, 11 May 2021 20:38:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Drone Remote ID Protocol WG of the IETF.

        Title           : Drone Remote Identification Protocol (DRIP) Requirements
        Authors         : Stuart W. Card
                          Adam Wiethuechter
                          Robert Moskowitz
                          Andrei Gurtov
	Filename        : draft-ietf-drip-reqs-11.txt
	Pages           : 45
	Date            : 2021-05-11

Abstract:
   This document defines terminology and requirements for Drone Remote
   Identification Protocol (DRIP) Working Group solutions to support
   Unmanned Aircraft System Remote Identification and tracking (UAS RID)
   for security, safety, and other purposes (e.g., initiation of
   identity based network sessions supporting UAS applications).
   Complementing external technical standards as regulator-accepted
   means of compliance with UAS RID regulations, DRIP will facilitate
   use of existing Internet resources to support RID and to enable
   enhanced related services, and will enable online and offline
   verification that RID information is trustworthy.

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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-drip-reqs-11.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-reqs-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Stuart W. Card" <[email-masked]>
Date: Tue, 11 May 2021 23:54:32 -0400

The new draft addresses AD Eric's comments on the numbered requirements.

Please find below Eric's comments and my responses, the latter labeled 
[Stu].

Bob, there are two we particularly need you to proofread, your name is 
called out on each of them.

I earnestly solicit _everyone's_ review on this, as I was very hesitant 
to make changes, even in response to our AD's comments, on the numbered 
requirements that we had debated in the WG and on which I believe we had 
achieved the necessary consensus.

If we can avoid it, I don't want to have to go through another WGLC 
before we can go to an IETF Last Call and the IESG.

We have gotten everything we need from the ASTM working group that is 
revising F3411. It will go to ballot soon, so we need to be ready on the 
IETF side of this urgent multi-SDO effort.

Thanks all!

==

-- Section 4.1 --

GEN-4: 'readability' is rather vague... is it about clear text vs. 
cipher text ? is about structure/format ?

[Stu] clarified in rationale w/o change to numbered requirement.

GEN-6: should the communications also be authenticated ?

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

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.

GEN-8: what is meant by mobility ? Geographic move ? or change of IP 
connectivity ? (switching cellular providers)

[Stu] clarified in rationale w/o change to numbered requirement.

The last two § would gain of having either a bullet list format or one § 
per requirement (and also grouped in a sub-section 'rationale')

[Stu] requirements section restructured so each group has a "normative 
requirements" sub-section and a "rationale" sub-section, but latter 
language not _yet_ restructured (in the interests of getting this rev 
out for review ASAP)

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

Add references to HIP & DTLS ?

[Stu] done, I hope correctly, Bob please proofread.

-- Section 4.3 --

PRIV-2: is the crypto disabling total or only for partial data ?

[Stu] clarified in rationale w/o change to numbered requirement.

-- Section 4.4 --

REG-4: are those policies machine or human readable ?

[Stu] clarified in rationale w/o change to numbered requirement.

==

-- 
-----------------------------------------
Stuart W. Card, PhD, Principal Engineer
AX Enterprize, LLC  www.axenterprize.com
4947 Commercial Drive, Yorkville NY 13495

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 12 May 2021 05:42:26 +0000

Hello Stu,

Thank you for the reply. Just to be clear, it is perfectly correct not to act (= change text) on a comment of mine as a reply 'why not' is enough. Also, from reading your comments below, your action was more to clarify the requirements rather than changing them => this is perfect as it does not change the WG consensus. See more as EV>

BTW, I like your use of subsections (normative/rationale).

Bob, let me know when you are happy with proposed text. Of course, co-authors & WG opinions are welcome

Thank you again for your work on this topic,

Regards

-éric

-----Original Message-----
From: "Stuart W. Card" <[email-masked]>
Date: Wednesday, 12 May 2021 at 05:54
To: "[email-masked]" <[email-masked]>
Cc: Robert Moskowitz <[email-masked]>, Eric Vyncke <[email-masked]>
Subject: Re: [Drip] I-D Action: draft-ietf-drip-reqs-11.txt

    Thanks all!

    ==

    -- Section 4.1 --

EV> and adding a typo ;-)

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 ?

    -- Section 4.2 --

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.

    -- Section 4.3 --

    -- Section 4.4 --

    ==

---

From: <[email-masked]>
Date: Tue, 18 May 2021 11:09:15 +0000

Hi Eric, 

(as the doc shepherded)

Thank you for double checking the updated version.

It would be appreciated if the two points mentioned below are addressed SOON, but I don't think this prevents to initiate the IETF LC based on -11. 

The reasoning is that we have a public record for the clarifications related to the points you raised. We can point reviewers to this thread if needed. The authors will consider these two points as part of the IETF LC comments.

Eric, would this be OK with you? 

Cheers,
Med

> -----Message d'origine-----
> De : Tm-rid [mailto:[email-masked]] De la part de Eric
> Vyncke (evyncke)
> Envoyé : mercredi 12 mai 2021 07:42
> À : Stuart W. Card <[email-masked]>; [email-masked]
> Cc : Robert Moskowitz <[email-masked]>
> Objet : Re: [Drip] I-D Action: draft-ietf-drip-reqs-11.txt
> 
> Hello Stu,
...
> 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 ?
> 
...
> 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.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Card, Stu" <[email-masked]>
Date: Tue, 18 May 2021 08:10:02 -0400

And I will address those points, but cannot get back on this editing task
until this weekend.

On Tue, May 18, 2021, 7:09 AM <[email-masked]> wrote:

> It would be appreciated if the two points mentioned below are addressed
> SOON, but I don't think this prevents to initiate the IETF LC based on -11.
>
> The reasoning is that we have a public record for the clarifications
> related to the points you raised. We can point reviewers to this thread if
> needed. The authors will consider these two points as part of the IETF LC
> comments.
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Tue, 18 May 2021 12:17:55 +0000

Re-,

Thanks, Stu.

I don’t think the remaining two points disserve to change your week-end plans :-)

Cheers,
Med (doc shepherded)

De : Card, Stu [mailto:[email-masked]]
Envoyé : mardi 18 mai 2021 14:10
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
Cc : Eric Vyncke (evyncke) <evyncke=[email-masked]>; Robert Moskowitz <[email-masked]>; [email-masked]
Objet : Re: [Drip] I-D Action: draft-ietf-drip-reqs-11.txt

And I will address those points, but cannot get back on this editing task until this weekend.

On Tue, May 18, 2021, 7:09 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

(as the doc shepherded)

Cheers,
Med

> De : Tm-rid [mailto:[email-masked]<mailto:[email-masked]>] De la part de Eric
> Vyncke (evyncke)
> À : Stuart W. Card <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> Cc : Robert Moskowitz <[email-masked]<mailto:[email-masked]>>
...
...

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 19 May 2021 13:32:32 +0000

Stu,

Thank you for your reply => I am waiting until Monday 24 for either a revised I-D or for a reply of yours (again feel free to ignore my suggestions) or a simple time-out before starting the next step: IETF Last Call

Regards

-éric

From: "Card, Stu" <[email-masked]>
Date: Tuesday, 18 May 2021 at 14:10
To: "[email-masked]" <[email-masked]>
Cc: Eric Vyncke <[email-masked]>, Robert Moskowitz <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Drip] I-D Action: draft-ietf-drip-reqs-11.txt

(as the doc shepherded)

Cheers,
Med

...
...