Subject: Re: [Drip] [Internet]Re: 2nd WGLC of draft-ietf-drip-arch-19

From: Daniel Migault <[email-masked]>
Date: Wed, 26 Jan 2022 16:27:24 -0500

Hi,

Realizing the WG is not CCed and sharing with it. Co-authors please
confirm, no further changes are expected and confirm on the mailing list
the IPR so we can proceed. Please try to do this by January 28.

Yours,
Daniel

On Mon, Jan 17, 2022 at 9:35 AM Daniel Migault <[email-masked]> wrote:

>
>
> On Sat, Jan 15, 2022 at 10:39 PM shuaiizhao(Shuai Zhao) <
> [email-masked]> wrote:
>
>> Thanks, Bob, for clarification. -19 is uploaded, please see diff
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-arch-19
>>
>>
>>
>> Co-authors please verify if implementation is done based on comments.
>>
> and confirm IPR ;-)
>
>>
>>
>> Best,
>>
>> Shuai
>>
>> *From: *Robert Moskowitz <[email-masked]>
>> *Date: *Friday, January 14, 2022 at 11:30
>> *To: *"shuaiizhao(Shuai Zhao)" <[email-masked]>, "Stuart W.
>> Card" <[email-masked]>, Daniel Migault <[email-masked]>,
>> Robert Moskowitz <[email-masked]>, Adam Wiethuechter <
>> [email-masked]>, Andrei Gurtov <[email-masked]>,
>> Mohamed Boucadair <[email-masked]>
>> *Subject: *[Internet]Re: [Drip] 2nd WGLC of draft-ietf-drip-arch-19
>>
>>
>>
>>
>>
>> On 1/13/22 01:10, shuaiizhao(Shuai Zhao) wrote:
>>
>> Please see updated -19 with latest changes. The only thing I am not sure
>> is the following:
>>
>>
>>
>> “Self-asserting in this usage is given the Host Identity (HI), the HHIT
>> ORCHID construction and a signature of the HHIT by the HI can both be
>> validated. “
>>
>>
>>
>> My understanding is by given a HI, HHIT construction and signature can
>> both be validated. But I think this is not the same understanding as
>> others.  @Robert Moskowitz <[email-masked]> can you clarify?
>>
>>
>> This is correct.  Given the HI, and that means the full algorithm
>> information, not just the key, the ORCHID can be validated.  Afterall, you
>> need the prefix and HID to generate the hash, and these are not part in
>> parcel with the HI.  The sig is simpler.  No extra info as in the ORCHID.
>>
>>
>>
>>
>>
>>
>> Best,
>>
>> Shuai
>>
>>
>>
>>
>>
>>
>>
>> *From: *"shuaiizhao(Shuai Zhao)" <[email-masked]>
>> <[email-masked]>
>> *Date: *Wednesday, January 12, 2022 at 15:07
>> *To: *"Stuart W. Card" <[email-masked]>
>> <[email-masked]>, Daniel Migault <[email-masked]>
>> <[email-masked]>, Robert Moskowitz <[email-masked]>
>> <[email-masked]>, Robert Moskowitz <[email-masked]>
>> <[email-masked]>, Adam Wiethuechter
>> <[email-masked]> <[email-masked]>,
>> Andrei Gurtov <[email-masked]> <[email-masked]>, Mohamed
>> Boucadair <[email-masked]> <[email-masked]>
>> *Subject: *[Drip] 2nd WGLC of draft-ietf-drip-arch-19
>>
>>
>>
>>
>>
>> Dear All,
>>
>>
>>
>> Attached -19 with suggested changes/update based on Daniel and Stu’s
>> comments.  Please provide your feedback.
>>
>>
>>
>> Couple of items from Daniel need some attention:
>>
>> 1.
>>
>>     > """
>>
>>     > The
>>
>>     >     cryptographically-bound addition of the Hierarchy and an HHIT
>>
>>     >     registration process (e.g. based on Extensible Provisioning
>> Protocol,
>>
>>     >     [RFC5730]) provide complete, global HHIT uniqueness.
>>
>>     > """
>>
>>     >
>>
>>     > EPP is transparent to the registration process as far as I
>> understand. I
>>
>>     > do see this information more confusing and would recommend removing
>> it.
>>
>>     > The text does not explicitly mention why the registration results
>> in a
>>
>>     > unique HHIT. In my opinion the registration is for little as
>> opposed to
>>
>>     > the integration of that HIT into a centralized naming scheme that
>>
>>     > guarantees by construction the uniqueness.
>>
>>
>>
>>     I agree that EPP does not need to be mentioned here, as it distracts
>>
>>     from the main point addressed here; but it should be mentioned
>>
>>     somewhere, as we are trying very hard to leverage existing Internet
>>
>>     standards, protocols, infrastructure and business models to achieve
>>
>>     trustworthy UAS RID, and EPP is currently the way registration is
>> done
>>
>>     in the Internet.
>>
>>
>>
>> Shuai/ I recall Bob added this a while back. And I don’t think EPP is
>> totally transparent to registration process unless I am wrong. I suggest
>> keep it for now and will ask Bob for clarification.
>>
>>
>>
>> 2.       Section 3.3:  “A lookup of the HHIT into this registration data
>> provides the
>>
>>    registered HI for HHIT proof.  A first-come-first-serve registration
>>
>>    for a HHIT provides deterministic access to any other needed
>>
>>    actionable information based on inquiry access authority (more
>>
>>    details in Section 4.2).”
>>
>>
>>
>>   > HHIT proof should mention the proof of what. It is probably proof of
>>
>>     > ownership.
>>
>>
>>
>>     Again, someone other than Bob should propose specific language, then
>> Bob
>>
>>     should vet it.
>>
>>
>>
>> Shuai/ Can Adam help here?
>>
>>
>>
>>
>>
>> Best,
>>
>> Shuai
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --------- Fixed nit below ------------------
>>
>>
>>
>> /tmp/idnits26964/draft-ietf-drip-arch-18.txt:
>>
>> -(10): Line appears to be too long, but this could be caused by non-ascii
>> characters in UTF-8 encoding
>>
>>
>>
>>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>>
>>   https://trustee.ietf.org/license-info):
>>
>>
>> ----------------------------------------------------------------------------
>>
>>
>>
>>      No issues found here.
>>
>>
>>
>>   Checking nits according to
>> https://www.ietf.org/id-info/1id-guidelines.txt:
>>
>>
>> ----------------------------------------------------------------------------
>>
>>
>>
>>   == There are 3 instances of lines with non-ascii characters in the
>> document.
>>
>>
>>
>> Shuai/ We need UTF-8 to show author’s name.  If this is a Nit we don’t
>> wanna see, lets get some help from IESG editors
>>
>>
>>
>>   Checking nits according to https://www.ietf.org/id-info/checklist :
>>
>>
>> ----------------------------------------------------------------------------
>>
>>
>>
>>      No issues found here.
>>
>>
>>
>>   Miscellaneous warnings:
>>
>>
>> ----------------------------------------------------------------------------
>>
>>
>>
>>   == The copyright year in the IETF Trust and authors Copyright Line does
>> not
>>
>>      match the current year
>>
>>
>>
>> Shuai/ AFAIK, 200902 is the current value.
>>
>>
>>
>>   == Line 367 has weird spacing: '... Public   o---...'
>>
>>
>>
>> Shuai/ There is really nth I can do to remove this warning.
>>
>>
>>
>>   == The document seems to lack the recommended RFC 2119 boilerplate,
>> even if
>>
>>      it appears to use RFC 2119 keywords -- however, there's a paragraph
>> with
>>
>>      a matching beginning. Boilerplate error?
>>
>>
>>
>> Shuai/ I don’t understand that one and did not shown on my side.
>>
>>
>>
>>      (The document does seem to have the reference to RFC 2119 which the
>>
>>      ID-Checklist requires).
>>
>>   == Using lowercase 'not' together with uppercase 'MUST', 'SHALL',
>> 'SHOULD',
>>
>>      or 'RECOMMENDED' is not an accepted usage according to RFC 2119.
>> Please
>>
>>      use uppercase 'NOT' together with RFC 2119 keywords (if that is what
>> you
>>
>>      mean).
>>
>>
>>
>>      Found 'MUST not' in this paragraph:
>>
>>
>>
>>      Broadcast RID messages can contain Personally Identifiable
>>
>>      Information (PII).  A viable architecture for PII protection would be
>>
>>      symmetric encryption of the PII using a session key known to the UAS
>> and
>>
>>      its USS.  Authorized Observers could obtain plaintext in either of
>> two
>>
>>      ways.  An Observer can send the UAS ID and the cyphertext to a server
>>
>>      that offers decryption as a service.  An Observer can send the UAS ID
>>
>>      only to a server that returns the session key, so that Observer can
>>
>>      directly locally decrypt all cyphertext sent by that UA during that
>>
>>      session (UAS operation).  In either case, the server can be: a Public
>>
>>      Safety USS; the Observer's own USS; or the UA's USS if the latter
>> can be
>>
>>      determined (which under DRIP it can be, from the UAS ID itself).
>> PII can
>>
>>      be protected unless the UAS is informed otherwise.  This could come
>> as
>>
>>      part of UTM operation authorization. It can be special instructions
>> at
>>
>>      the start or during an operation. PII protection MUST not be used if
>> the
>>
>>      UAS loses connectivity to the USS.  The UAS always has the option to
>>
>>      abort the operation if PII protection is disallowed.
>>
>>
>>
>> Shuai/ Updated
>>
>>
>>
>>   -- The document date (14 December 2021) is 29 days in the past.  Is this
>>
>>      intentional?
>>
>>
>>
>>
>>
>>   Checking references for intended status: Informational
>>
>>
>> ----------------------------------------------------------------------------
>>
>>
>>
>>   -- Obsolete informational reference (is this intentional?): RFC 7482
>>
>>      (Obsoleted by RFC 9082)
>>
>>
>>
>>   -- Obsolete informational reference (is this intentional?): RFC 7483
>>
>>      (Obsoleted by RFC 9083)
>>
>>
>>
>>
>>
>>      Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments
>> (--).
>>
>>
>>
>>     Run idnits with the --verbose option for more detailed information
>> about
>>
>>      the items above.
>>
>> Shuai/ Updated
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> Daniel Migault
> Ericsson
>

-- 
Daniel Migault
Ericsson

---

From: Adam Wiethuechter <[email-masked]>
Date: Wed, 26 Jan 2022 21:28:43 +0000

I am not aware of any IPR pertaining to this document.

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC
________________________________
From: Daniel Migault <[email-masked]>
Sent: Wednesday, January 26, 2022 4:27 PM
To: shuaiizhao(Shuai Zhao) <[email-masked]>
Cc: Robert Moskowitz <[email-masked]>; Stuart W. Card <[email-masked]>; Robert Moskowitz <[email-masked]>; Adam Wiethuechter <[email-masked]>; Andrei Gurtov <[email-masked]>; Mohamed Boucadair <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Internet]Re: [Drip] 2nd WGLC of draft-ietf-drip-arch-19

Hi,

Realizing the WG is not CCed and sharing with it. Co-authors please confirm, no further changes are expected and confirm on the mailing list the IPR so we can proceed. Please try to do this by January 28.

Yours,
Daniel

On Mon, Jan 17, 2022 at 9:35 AM Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, Jan 15, 2022 at 10:39 PM shuaiizhao(Shuai Zhao) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks, Bob, for clarification. -19 is uploaded, please see diff https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-arch-19

and confirm IPR ;-)

Best,

Shuai

From: Robert Moskowitz <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 14, 2022 at 11:30
To: "shuaiizhao(Shuai Zhao)" <[email-masked]<mailto:[email-masked]>>, "Stuart W. Card" <[email-masked]<mailto:[email-masked]>>, Daniel Migault <[email-masked]<mailto:[email-masked]>>, Robert Moskowitz <[email-masked]<mailto:[email-masked]>>, Adam Wiethuechter <[email-masked]<mailto:[email-masked]>>, Andrei Gurtov <[email-masked]<mailto:[email-masked]>>, Mohamed Boucadair <[email-masked]<mailto:[email-masked]>>
Subject: [Internet]Re: [Drip] 2nd WGLC of draft-ietf-drip-arch-19

Please see updated -19 with latest changes. The only thing I am not sure is the following:

“Self-asserting in this usage is given the Host Identity (HI), the HHIT ORCHID construction and a signature of the HHIT by the HI can both be validated. “

My understanding is by given a HI, HHIT construction and signature can both be validated. But I think this is not the same understanding as others.  @Robert Moskowitz<mailto:[email-masked]> can you clarify?

This is correct.  Given the HI, and that means the full algorithm information, not just the key, the ORCHID can be validated.  Afterall, you need the prefix and HID to generate the hash, and these are not part in parcel with the HI.  The sig is simpler.  No extra info as in the ORCHID.

Best,

Shuai

From: "shuaiizhao(Shuai Zhao)" <[email-masked]><mailto:[email-masked]>
Date: Wednesday, January 12, 2022 at 15:07
To: "Stuart W. Card" <[email-masked]><mailto:[email-masked]>, Daniel Migault <[email-masked]><mailto:[email-masked]>, Robert Moskowitz <[email-masked]><mailto:[email-masked]>, Robert Moskowitz <[email-masked]><mailto:[email-masked]>, Adam Wiethuechter <[email-masked]><mailto:[email-masked]>, Andrei Gurtov <[email-masked]><mailto:[email-masked]>, Mohamed Boucadair <[email-masked]><mailto:[email-masked]>
Subject: [Drip] 2nd WGLC of draft-ietf-drip-arch-19

Dear All,

Attached -19 with suggested changes/update based on Daniel and Stu’s comments.  Please provide your feedback.

1.

    >     registration process (e.g. based on Extensible Provisioning Protocol,

    > EPP is transparent to the registration process as far as I understand. I

    > do see this information more confusing and would recommend removing it.

    > The text does not explicitly mention why the registration results in a

    > unique HHIT. In my opinion the registration is for little as opposed to

    trustworthy UAS RID, and EPP is currently the way registration is done

    in the Internet.

Shuai/ I recall Bob added this a while back. And I don’t think EPP is totally transparent to registration process unless I am wrong. I suggest keep it for now and will ask Bob for clarification.

2.       Section 3.3:  “A lookup of the HHIT into this registration data provides the

    > ownership.

    Again, someone other than Bob should propose specific language, then Bob

    should vet it.

Best,

Shuai

--------- Fixed nit below ------------------

-(10): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:

  == There are 3 instances of lines with non-ascii characters in the document.

Shuai/ We need UTF-8 to show author’s name.  If this is a Nit we don’t wanna see, lets get some help from IESG editors

     No issues found here.

  Miscellaneous warnings:

  == The copyright year in the IETF Trust and authors Copyright Line does not

     match the current year

  == The document seems to lack the recommended RFC 2119 boilerplate, even if

     it appears to use RFC 2119 keywords -- however, there's a paragraph with

     ID-Checklist requires).

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',

     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please

     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you

     mean).

     symmetric encryption of the PII using a session key known to the UAS and

     its USS.  Authorized Observers could obtain plaintext in either of two

     Safety USS; the Observer's own USS; or the UA's USS if the latter can be

     determined (which under DRIP it can be, from the UAS ID itself).  PII can

     be protected unless the UAS is informed otherwise.  This could come as

     part of UTM operation authorization. It can be special instructions at

     the start or during an operation. PII protection MUST not be used if the

Shuai/ Updated

     intentional?

     (Obsoleted by RFC 9082)

     (Obsoleted by RFC 9083)

     Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--).

    Run idnits with the --verbose option for more detailed information about

     the items above.

Shuai/ Updated

--
Daniel Migault
Ericsson

--
Daniel Migault
Ericsson

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Wed, 26 Jan 2022 21:33:40 +0000

I Confirm all the comments have been addressed in revision 19 and am not aware of any IPR related to arch draft.

Best,
Shuai

From: Daniel Migault <[email-masked]>
Date: Wednesday, January 26, 2022 at 13:27
To: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Cc: Robert Moskowitz <[email-masked]>, "Stuart W. Card" <[email-masked]>, Robert Moskowitz <[email-masked]>, Adam Wiethuechter <[email-masked]>, Andrei Gurtov <[email-masked]>, Mohamed Boucadair <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Internet]Re: Re: [Drip] 2nd WGLC of draft-ietf-drip-arch-19

Hi,

Yours,
Daniel

Best,
Shuai

Best,
Shuai

Dear All,

1.

Best,
Shuai

--------- Fixed nit below ------------------

     No issues found here.

     No issues found here.

  Miscellaneous warnings:

Shuai/ Updated

--
Daniel Migault
Ericsson

--
Daniel Migault
Ericsson

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 26 Jan 2022 17:50:13 -0500

There is some confusing grammar in the CS-RID Finder & SDSP section that
needs fixing but is purely editorial not substantive. I will scan for any
substantive issues.

On Wed, Jan 26, 2022, 16:27 Daniel Migault <[email-masked]> wrote:

>>> <[email-masked]>
>>> <[email-masked]>, Andrei Gurtov
>>> <[email-masked]> <[email-masked]>, Mohamed Boucadair
>>> <[email-masked]> <[email-masked]>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 26 Jan 2022 19:37:31 -0500

Thanks! I am expecting the other co-authors to confirm in the coming days
and so be abe to ship the document this week.
Yours,
Daniel

On Wed, Jan 26, 2022 at 5:50 PM Card, Stu <[email-masked]> wrote:

>>>> [email-masked]>, Andrei Gurtov <
>>>> [email-masked]>, Mohamed Boucadair <[email-masked]>

-- 
Daniel Migault
Ericsson

---

From: "Stuart W. Card" <[email-masked]>
Date: Wed, 26 Jan 2022 20:56:45 -0500

My WGLC review of the DRIP Architecture v19 follows.

==

page 5 section 1.2.1 "visual Light-Of-Sight" -> "visual Line-Of-Sight"

==

p. 5 s. 1.2.2 1st bullet mismatched parentheses

==

p. 7 Figure 3 ASCII art is off by one and figure caption wraps to p. 8

==

p. 8 Fig. 4 ASCII art is slightly scrambled & "NetRID" -> "Net-RID"

==

p. 10 s. 3.2 Assertions "its signing over" -> "over which it is signing"

==

p. 10f s. 4 last paragraph on p. 10 / 1st on p. 11 is still confusing

==

p. 11 s. 4.1 paragraph 2 "Session IDs" -> "Specific Session ID"

==

p. 13 s. 5 last line "PRG-2" -> "REG-2"

==

p. 15 s. 5.2.2 second sentence mismatched parentheses & brackets

==

p. 15 s. 6 3rd sentence garbled grammar

==

p. 15 s. 6 last paragraph is "optimization" really the right word?

==

p. 16 s. 7.2 "using including using" garbled grammar (previously noted)

==

I found _no_ substantive problems and congratulate editor Shuai as well 
as our co-authors on a fine job!

I am not aware of any ownership claims by my employer or any other party 
on any IP that would be needed to implement this architecture.

On 1/26/2022 5:50 PM, Card, Stu wrote:
> needs fixing but is purely editorial not substantive. I will scan for 
> any substantive issues.
> 
> On Wed, Jan 26, 2022, 16:27 Daniel Migault <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>     confirm, no further changes are expected and confirm on the mailing
>     list the IPR so we can proceed. Please try to do this by January 28.
> 
>     Yours,
>     Daniel
> 
> 
> 
>         On Sat, Jan 15, 2022 at 10:39 PM shuaiizhao(Shuai Zhao)
>         <[email-masked] <mailto:[email-masked]>> wrote:
> 
>             <https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-arch-19>____
> 
>             __ __
> 
>             ____
>             __ __
>             Best,____
>             Shuai____
>             *From: *Robert Moskowitz <[email-masked]
>             <mailto:[email-masked]>>
>             *To: *"shuaiizhao(Shuai Zhao)" <[email-masked]
>             <mailto:[email-masked]>>, "Stuart W. Card"
>             <[email-masked]
>             <mailto:[email-masked]>>, Daniel Migault
>             <[email-masked] <mailto:[email-masked]>>, Robert
>             Moskowitz <[email-masked]
>             <mailto:[email-masked]>>, Adam Wiethuechter
>             <[email-masked]
>             <mailto:[email-masked]>>, Andrei Gurtov
>             <[email-masked] <mailto:[email-masked]>>,
>             Mohamed Boucadair <[email-masked]
>             <mailto:[email-masked]>>
>             *Subject: *[Internet]Re: [Drip] 2nd WGLC of
>             draft-ietf-drip-arch-19____
> 
>             __ __
> 
>             __ __
> 
>             On 1/13/22 01:10, shuaiizhao(Shuai Zhao) wrote:____
> 
>                 Please see updated -19 with latest changes. The only
>                 thing I am not sure is the following:____
> 
>                 ____
> 
>                 “Self-asserting in this usage is given the Host Identity
>                 (HI), the HHIT ORCHID construction and a signature of
>                 the HHIT by the HI can both be validated. “____
> 
>                 ____
> 
>                 My understanding is by given a HI, HHIT construction and
>                 signature can both be validated. But I think this is not
>                 the same understanding as others. @Robert Moskowitz
>                 <mailto:[email-masked]> can you clarify? ____
> 
> 
>             This is correct.  Given the HI, and that means the full
>             algorithm information, not just the key, the ORCHID can be
>             validated.  Afterall, you need the prefix and HID to
>             generate the hash, and these are not part in parcel with the
>             HI.  The sig is simpler.  No extra info as in the ORCHID.
> 
> 
>             ____
> 
>                 ____
> 
>                 ____
> 
>                 Best,____
> 
>                 Shuai____
> 
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 *From: *"shuaiizhao(Shuai Zhao)"
>                 <[email-masked]> <mailto:[email-masked]>
>                 <mailto:[email-masked]>, Daniel Migault
>                 <[email-masked]> <mailto:[email-masked]>,
>                 Robert Moskowitz <[email-masked]>
>                 <mailto:[email-masked]>, Robert Moskowitz
>                 <[email-masked]> <mailto:[email-masked]>, Adam
>                 Wiethuechter <[email-masked]>
>                 <mailto:[email-masked]>, Andrei
>                 Gurtov <[email-masked]>
>                 <mailto:[email-masked]>, Mohamed Boucadair
>                 <[email-masked]>
>                 <mailto:[email-masked]>
>                 *Subject: *[Drip] 2nd WGLC of draft-ietf-drip-arch-19____
> 
>                 ____
> 
>                 ____
> 
>                 Dear All,____
> 
>                 ____
> 
>                 Attached -19 with suggested changes/update based on
>                 Daniel and Stu’s comments.  Please provide your
>                 feedback.____
> 
>                 ____
> 
>                 Couple of items from Daniel need some attention: ____
> 
>                 __1.__ ____
> 
>                      > """____
> 
>                      > The____
> 
>                      >     cryptographically-bound addition of the
>                 Hierarchy and an HHIT____
> 
>                      >     registration process (e.g. based on
>                 Extensible Provisioning Protocol,____
> 
>                      >     [RFC5730]) provide complete, global HHIT
>                 uniqueness.____
> 
>                      > """____
> 
>                      > ____
> 
>                      > EPP is transparent to the registration process as
>                 far as I understand. I ____
> 
>                      > do see this information more confusing and would
>                 recommend removing it.____
> 
>                      > The text does not explicitly mention why the
>                 registration results in a ____
> 
>                      > unique HHIT. In my opinion the registration is
>                 for little as opposed to ____
> 
>                      > the integration of that HIT into a centralized
>                 naming scheme that ____
> 
>                      > guarantees by construction the uniqueness.____
> 
>                 ____
> 
>                      I agree that EPP does not need to be mentioned
>                 here, as it distracts ____
> 
>                      from the main point addressed here; but it should
>                 be mentioned ____
> 
>                      somewhere, as we are trying very hard to leverage
>                 existing Internet ____
> 
>                      standards, protocols, infrastructure and business
>                 models to achieve ____
> 
>                      trustworthy UAS RID, and EPP is currently the way
>                 registration is done ____
> 
>                      in the Internet.____
> 
>                 ____
> 
>                 Shuai/ I recall Bob added this a while back. And I don’t
>                 think EPP is totally transparent to registration process
>                 unless I am wrong. I suggest keep it for now and will
>                 ask Bob for clarification.____
> 
>                 ____
> 
>                 __2.__Section 3.3:  “A lookup of the HHIT into this
>                 registration data provides the____
> 
>                     registered HI for HHIT proof.  A
>                 first-come-first-serve registration____
> 
>                     for a HHIT provides deterministic access to any
>                 other needed____
> 
>                     actionable information based on inquiry access
>                 authority (more____
> 
>                     details in Section 4.2).”____
> 
>                 ____
> 
>                    > HHIT proof should mention the proof of what. It is
>                 probably proof of ____
> 
>                      > ownership.____
> 
>                 ____
> 
>                      Again, someone other than Bob should propose
>                 specific language, then Bob ____
> 
>                      should vet it.____
> 
>                 ____
> 
>                 Shuai/ Can Adam help here?____
> 
>                 ____
> 
>                 ____
> 
>                 Best,____
> 
>                 Shuai____
> 
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 --------- Fixed nit below ------------------____
> 
>                 ____
> 
>                 /tmp/idnits26964/draft-ietf-drip-arch-18.txt:____
> 
>                 -(10): Line appears to be too long, but this could be
>                 caused by non-ascii characters in UTF-8 encoding____
> 
>                 ____
> 
>                    Checking boilerplate required by RFC 5378 and the
>                 IETF Trust (see____
> 
>                 https://trustee.ietf.org/license-info
>                 <https://trustee.ietf.org/license-info>):____
> 
>                   
>                 ----------------------------------------------------------------------------____
> 
>                 ____
> 
>                       No issues found here.____
> 
>                 ____
> 
>                 https://www.ietf.org/id-info/1id-guidelines.txt
>                 <https://www.ietf.org/id-info/1id-guidelines.txt>:____
> 
>                   
>                 ----------------------------------------------------------------------------____
> 
>                 ____
> 
>                    == There are 3 instances of lines with non-ascii
>                 characters in the document.____
> 
>                 ____
> 
>                 Shuai/ We need UTF-8 to show author’s name.  If this is
>                 a Nit we don’t wanna see, lets get some help from IESG
>                 editors____
> 
>                 ____
> 
>                 https://www.ietf.org/id-info/checklist
>                 <https://www.ietf.org/id-info/checklist> :____
> 
>                   
>                 ----------------------------------------------------------------------------____
> 
>                 ____
> 
>                       No issues found here.____
> 
>                 ____
> 
>                    Miscellaneous warnings:____
> 
>                   
>                 ----------------------------------------------------------------------------____
> 
>                 ____
> 
>                    == The copyright year in the IETF Trust and authors
>                 Copyright Line does not____
> 
>                       match the current year____
> 
>                 ____
> 
>                 Shuai/ AFAIK, 200902 is the current value. ____
> 
>                 ____
> 
>                    == Line 367 has weird spacing: '... Public   o---...'____
> 
>                 ____
> 
>                 Shuai/ There is really nth I can do to remove this
>                 warning. ____
> 
>                 ____
> 
>                    == The document seems to lack the recommended RFC
>                 2119 boilerplate, even if____
> 
>                       it appears to use RFC 2119 keywords -- however,
>                 there's a paragraph with____
> 
>                       a matching beginning. Boilerplate error?____
> 
>                 ____
> 
>                 Shuai/ I don’t understand that one and did not shown on
>                 my side. ____
> 
>                 ____
> 
>                       (The document does seem to have the reference to
>                 RFC 2119 which the____
> 
>                       ID-Checklist requires).____
> 
>                    == Using lowercase 'not' together with uppercase
>                 'MUST', 'SHALL', 'SHOULD',____
> 
>                       or 'RECOMMENDED' is not an accepted usage
>                 according to RFC 2119.  Please____
> 
>                       use uppercase 'NOT' together with RFC 2119
>                 keywords (if that is what you____
> 
>                       mean).____
> 
>                 ____
> 
>                       Found 'MUST not' in this paragraph:____
> 
>                 ____
> 
>                       Broadcast RID messages can contain Personally
>                 Identifiable____
> 
>                       Information (PII).  A viable architecture for PII
>                 protection would be____
> 
>                       symmetric encryption of the PII using a session
>                 key known to the UAS and____
> 
>                       its USS.  Authorized Observers could obtain
>                 plaintext in either of two____
> 
>                       ways.  An Observer can send the UAS ID and the
>                 cyphertext to a server____
> 
>                       that offers decryption as a service.  An Observer
>                 can send the UAS ID____
> 
>                       only to a server that returns the session key, so
>                 that Observer can____
> 
>                       directly locally decrypt all cyphertext sent by
>                 that UA during that____
> 
>                       session (UAS operation).  In either case, the
>                 server can be: a Public____
> 
>                       Safety USS; the Observer's own USS; or the UA's
>                 USS if the latter can be____
> 
>                       determined (which under DRIP it can be, from the
>                 UAS ID itself).  PII can____
> 
>                       be protected unless the UAS is informed
>                 otherwise.  This could come as____
> 
>                       part of UTM operation authorization. It can be
>                 special instructions at____
> 
>                       the start or during an operation. PII protection
>                 MUST not be used if the____
> 
>                       UAS loses connectivity to the USS.  The UAS always
>                 has the option to____
> 
>                       abort the operation if PII protection is
>                 disallowed.____
> 
>                 ____
> 
>                 Shuai/ Updated____
> 
>                 ____
> 
>                    -- The document date (14 December 2021) is 29 days in
>                 the past.  Is this____
> 
>                       intentional?____
> 
>                 ____
> 
>                 ____
> 
>                    Checking references for intended status:
>                 Informational____
> 
>                   
>                 ----------------------------------------------------------------------------____
> 
>                 ____
> 
>                    -- Obsolete informational reference (is this
>                 intentional?): RFC 7482____
> 
>                       (Obsoleted by RFC 9082)____
> 
>                 ____
> 
>                    -- Obsolete informational reference (is this
>                 intentional?): RFC 7483____
> 
>                       (Obsoleted by RFC 9083)____
> 
>                 ____
> 
>                 ____
> 
>                       Summary: 0 errors (**), 0 flaws (~~), 5 warnings
>                 (==), 3 comments (--).____
> 
>                 ____
> 
>                      Run idnits with the --verbose option for more
>                 detailed information about____
> 
>                       the items above.____
> 
>                 Shuai/ Updated____
> 
>                 ____
> 
>                 ____
> 
> 
> 
>             ____
> 
> 
> 
>         -- 
>         Daniel Migault
>         Ericsson
> 
> 
> 
>     -- 
>     Daniel Migault
>     Ericsson
> 

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

---

From: Jim Reid <[email-masked]>
Date: Thu, 27 Jan 2022 14:40:40 +0000

> On 26 Jan 2022, at 21:27, Daniel Migault <[email-masked]> wrote:
> 

I'm not aware of any IPR issues. However I won’t be able to do a substantive review of the doc by tomorrow: dayjob end of month deadlines. That’ll get done some time next week.

---

From: Andrei Gurtov <[email-masked]>
Date: Thu, 27 Jan 2022 15:51:49 +0100

Hi,

I am fine with this version and not aware of IPRs related to the draft.

Just please add same ack as for Req. Maybe it will be done by the RFC 
editor together with authors' addresses.

" This work was partly supported by the EU project AiRMOUR (enabling
    sustainable air mobility in urban contexts via emergency and medical
    services) under grant agreement no. 101006601."

br Andrei

On 26-Jan-22 22:27, Daniel Migault wrote:
>     <[email-masked]> wrote:
>
>         Thanks, Bob, for clarification. -19 is uploaded, please see
>         diff https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-arch-19
>         <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-drip-arch-19&data=04%7C01%7Candrei.gurtov%40liu.se%7C25a3b67144ea4c2a6fc508d9e112ac3c%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637788293363931409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=a5mKyROkI92tjh4s2cSaGvXUfvOkMyu6MVxvksm7RMk%3D&reserved=0>
>
>         *To: *"shuaiizhao(Shuai Zhao)" <[email-masked]>,
>         "Stuart W. Card" <[email-masked]>, Daniel Migault
>         <[email-masked]>, Robert Moskowitz
>         <[email-masked]>, Adam Wiethuechter
>         <[email-masked]>, Mohamed Boucadair
>         draft-ietf-drip-arch-19
>             (HI), the HHIT ORCHID construction and a signature of the
>             HHIT by the HI can both be validated. “
>
>             <mailto:[email-masked]> can you clarify?
>
>
>         validated.  Afterall, you need the prefix and HID to generate
>         the hash, and these are not part in parcel with the HI.  The
>         sig is simpler.  No extra info as in the ORCHID.
>
>
>             Best,
>
>             Shuai
>
>             <mailto:[email-masked]>
>             <[email-masked]> <mailto:[email-masked]>, Robert
>             Moskowitz <[email-masked]>
>             <mailto:[email-masked]>, Andrei Gurtov
>             <[email-masked]> <mailto:[email-masked]>,
>             Attached -19 with suggested changes/update based on Daniel
>             and Stu’s comments.  Please provide your feedback.
>
>                 > """
>                 > The
>                 > cryptographically-bound addition of the Hierarchy
>             and an HHIT
>
>                 > registration process (e.g. based on Extensible
>             Provisioning Protocol,
>
>                 >     [RFC5730]) provide complete, global HHIT uniqueness.
>
>                 > """
>
>                 >
>
>             far as I understand. I
>             recommend removing it.
>             registration results in a
>
>                 > unique HHIT. In my opinion the registration is for
>             little as opposed to
>
>             naming scheme that
>                 > guarantees by construction the uniqueness.
>
>             existing Internet
>             models to achieve
>             registration is done
>             unless I am wrong. I suggest keep it for now and will ask
>             Bob for clarification.
>
>             2.Section 3.3:  “A lookup of the HHIT into this
>             registration data provides the
>
>             authority (more
>             probably proof of
>                 > ownership.
>             caused by non-ascii characters in UTF-8 encoding
>
>             <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-info&data=04%7C01%7Candrei.gurtov%40liu.se%7C25a3b67144ea4c2a6fc508d9e112ac3c%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637788293363931409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=D%2FvzEqEanof%2FXg%2BvWV3N%2F6E0%2FX4eSHdi0BrxAggTf7A%3D&reserved=0>):
>
>             <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid-info%2F1id-guidelines.txt&data=04%7C01%7Candrei.gurtov%40liu.se%7C25a3b67144ea4c2a6fc508d9e112ac3c%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637788293363931409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=wKTPtURsKfrJIo0NjTafTj8a2K8Wr6COz%2FN8VU%2Fs7V8%3D&reserved=0>:
>
>             characters in the document.
>
>             Shuai/ We need UTF-8 to show author’s name.  If this is a
>             Nit we don’t wanna see, lets get some help from IESG editors
>
>             <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid-info%2Fchecklist&data=04%7C01%7Candrei.gurtov%40liu.se%7C25a3b67144ea4c2a6fc508d9e112ac3c%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637788293363931409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=7xU26d0%2BttMODgk2cHbSQ%2FNubcSEbNZDWBhBRgtUULE%3D&reserved=0>
>             :
>
>             Copyright Line does not
>             there's a paragraph with
>             Identifiable
>             protection would be
>             cyphertext to a server
>             that Observer can
>             special instructions at
>             has the option to
>             the past.  Is this
>             intentional?): RFC 7482
>             intentional?): RFC 7483
>             (==), 3 comments (--).

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Fri, 28 Jan 2022 21:52:27 +0000

Thanks, Stu, for your review. -20 is uploaded. Please also see inline response. 

URL:            https://www.ietf.org/archive/id/draft-ietf-drip-arch-20.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-drip-arch/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-drip-arch
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-arch-20

Best,
Shuai

-----Original Message-----
From: "Stuart W. Card" <[email-masked]>
Date: Wednesday, January 26, 2022 at 17:56
To: Daniel Migault <[email-masked]>
Cc: "shuaiizhao(Shuai Zhao)" <[email-masked]>, Robert Moskowitz <[email-masked]>, Adam Wiethuechter <[email-masked]>, Andrei Gurtov <[email-masked]>, Mohamed Boucadair <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Internet]Re: Re: [Drip] 2nd WGLC of draft-ietf-drip-arch-19

    ==

    ==
Shuai/ Updated

    p. 5 s. 1.2.2 1st bullet mismatched parentheses
Shuai/ checked and its fine. 
    ==

    p. 7 Figure 3 ASCII art is off by one and figure caption wraps to p. 8
Shuai/ Adjusted in both places
    ==

Shuai/ Adjusted
    ==

    p. 10f s. 4 last paragraph on p. 10 / 1st on p. 11 is still confusing
Shuai/ Bob has clarified his opinion. But will send out a email among authors.
    ==

Shuai/ updated
    ==

    p. 15 s. 6 3rd sentence garbled grammar
shuai/ Agree, updated to the following :
"
A sender's identity can not be approved by only possessing a DET (DRIP Entity Tag which is an HHIT-based UA ID) and broadcasting a claim that it belongs to that sender.
"
    ==

    p. 15 s. 6 last paragraph is "optimization" really the right word?
Shuai/ I really don’t know. @Adam Wiethuechtermaybe you can help here
    ==

    p. 16 s. 7.2 "using including using" garbled grammar (previously noted)
Shuai/ updated to " estimates UA location using multilateration when possible"
    ==

    On 1/26/2022 5:50 PM, Card, Stu wrote:
    >             diff
    >                      > """____
    >                      > The____
    >                      >     cryptographically-bound addition of the
    >                      >     registration process (e.g. based on
    >                      >     [RFC5730]) provide complete, global HHIT
    >                 uniqueness.____
    > 
    >                      > """____
    > 
    >                      > ____
    > 
    >                      > EPP is transparent to the registration process as
    >                      > do see this information more confusing and would
    >                      > The text does not explicitly mention why the
    >                      > unique HHIT. In my opinion the registration is
    >                      > the integration of that HIT into a centralized
    >                 naming scheme that ____
    > 
    >                      > guarantees by construction the uniqueness.____
    > 
    >                 ____
    > 
    >                    > HHIT proof should mention the proof of what. It is
    >                 probably proof of ____
    > 
    >                      > ownership.____
    > 
    >                 ____
    >

---

From: Daniel Migault <[email-masked]>
Date: Sat, 29 Jan 2022 14:18:12 -0500

Unless I am missing anything, I think we are missing Stu and Bob's IPR
confirmation for version 19 / or 20. Please correct me if I am wrong, and
either send me the link of the confirmation or reconfirm - whichever is
faster for you.

There are two ongoing implementations I am aware of, please let me know if
there are any links - documentation regarding these two implementations.

I hope I can ship it to Eric's monday morning!

Yours,
Daniel

On Fri, Jan 28, 2022 at 4:52 PM shuaiizhao(Shuai Zhao) <
[email-masked]> wrote:

> URL:
> https://www.ietf.org/archive/id/draft-ietf-drip-arch-20.txt
> Cc: "shuaiizhao(Shuai Zhao)" <[email-masked]>, Robert Moskowitz <
> [email-masked]>, Adam Wiethuechter <
> Mohamed Boucadair <[email-masked]>, "[email-masked]" <
> [email-masked]>
> A sender's identity can not be approved by only possessing a DET (DRIP
> Entity Tag which is an HHIT-based UA ID) and broadcasting a claim that it
> belongs to that sender.
> "
>     ==
>
>     >     On Mon, Jan 17, 2022 at 9:35 AM Daniel Migault <
> [email-masked]
>     >             <
> https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-arch-19>____
>     >
>     >             __ __
>     >
>     >             Co-authors please verify if implementation is done based
> on
>     >             comments.
>     >
>     >         and confirm IPR ;-)
>     >
>     >             ____
>     >
>     >             __ __
>     >
>     >             Best,____
>     >
>     >             Shuai____
>     >
>     >                 <https://www.ietf.org/id-info/1id-guidelines.txt
> >:____
>     >
>     >
>     >

-- 
Daniel Migault
Ericsson

---

From: "Card, Stu" <[email-masked]>
Date: Sat, 29 Jan 2022 22:32:24 -0500

Thanks Shuai!

Sorry about my mistakenly flagging correct parentheses as mismatched.

Any further grammatical, stylistic, etc. stuff will be addressed thoroughly
when we get to the RFC Editor, as I have recently learned from my first
experience with -reqs. ;-)

I am satisfied with -20.

On Fri, Jan 28, 2022 at 4:52 PM shuaiizhao(Shuai Zhao) <
[email-masked]> wrote:

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