DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)
draft-ietf-drip-rid-37

After several updates to address the non-blocking COMMENT + some late remarks by the AD (notably about the IPsec I-D being normative + representations of RID in domain names).

[Ballot comment]
(Updated ballot)

Thank you to Magnus Nystrom for the SECDIR Review and to Nicholas Gajcowski during the CFRG discussions.

Thank for the revised text from -29 to -32.  It addressed all of my DISCUSS and some of my COMMENT points.  Further details with history below.

These were DISCUSSes.  From https://mailarchive.ietf.org/arch/msg/tm-rid/Of4ZUih3oiHvwZDrYG9cjBf27-Q/

>>> I’m having trouble following along on where the guidance for offline
>>> verification is described – who exactly signs what with what key and
>>> in what
>>> format is this stored.  Is this considered in-scope for this
>>> document?  Given
>>> the asserted security properties,
>>
>> This guidance that lines up with 9.2 that the DET alone is not
>> enough, go read drip-auth.  But this is the core that makes drip-auth
>> even possible.
>>
>>> -- I’ll note that draft-ietf-drip-auth is an informative reference.
>>
>> Yes.  drip-rid does not, itself, need drip-auth.  A trustworthy
>> implementation would use drip-auth to provide full message trust,
>> including of the messages providing the DET.
>
> Please see the recent addition to drip-auth, sec 1.1
>>
>>> -- What exactly needs to be in the offline Observer’s cache?  I
>>> couldn’t find
>>> that in draft-ietf-drip-auth.
>>
>> Well, then I need more updates to drip-auth!  The cache, minimally is
>> the HDA's DET and HI.  48 bytes worth per entry. As it says above:
>>
>>    Only a small cache that contains the
>>    HDA's HI/HHIT and HDA meta-data is needed by the Observer.
>>
>> So the offline attestation in defined in drip-auth has the HDA's HHIT
>> (DET).  Use this to retrieve the HDA's HI.  Use this HI to validate
>> the signing of the registration attestation within the larger
>> attestation.  This does need to be clearly defined in drip-auth.  I
>> am making a note to check this out.
>
> This has recently been updated in drip-auth, sec 1.1

Adding the appropriate sub-section drip-auth reference would be helpful.  It’s in a few places further into the document (not Section 1.1)


These were DISCUSSes and https://mailarchive.ietf.org/arch/msg/tm-rid/aq-wsciitaB4h-CghTpPwDn1KuM/

>> ** Section 9.
>>    Therefore, the HHIT registration and HHIT/HI registration validation
>>    is strongly recommended.
>>
>> If validation isn’t done, who are the promised security guarantees of
>> global
>> non-collision possible?  Practically, why isn’t this a MUST?
>
> I am open to it being a MUST, but I think I was advised to back off to
> a strongly recommended.
>
> If not registered, no offline attestation available, only the
> self-attestation.

Understood.  Thanks for explaining.  I recommend added this explanation into the text to justify why the MUST isn’t needed.

>> ** Section 9.5.
>>
>>    The UAS/USS registration
>>    process should include registering the DET and MUST reject a
>>    collision, forcing the UAS to generate a new HI and thus HHIT and
>>    reapplying to the DET registration process.
>>
>> How does a UAS “generate a new HI” in the case of a CTA2063A or
>> manufacturer
>> hard-coding the HHIT per Section 3.2 of draft-ietf-drip-arch-24?
>
> See drip-registries.  That is covered there, and it parallels ANIMA in
> many ways.  The CTA encoded HHIT is a permanent DET to bootstrap
> registration of one or lots of operational (Session) DETs.

Strongly recommend putting into reference to relevant section in drip-registries.

From https://mailarchive.ietf.org/arch/msg/tm-rid/DGQ5pQ-TNkzG-WDoHoOnTVoA-so/:


> > ** Section 4.
> >    The original UAS ID Types 1 - 3 allow for an UAS ID with a maximum
> >    length of 20 bytes, this new SSI (Type 4) uses the first byte of the
> >    ID for the SSI Type, thus restricting the UAS ID of this type to a
> >    maximum of 19 bytes.  The SSI Types initially assigned are :
> >
> >    ID 1  IETF - DRIP Drone Remote ID Protocol (DRIP) entity ID.
> >
> >    ID 2  3GPP - IEEE 1609.2-2016 HashedID8
> >
> > -- Is this text saying that the HHITs format defined in this text can be used
> with a UAS ID Type = 1, 2, 3?

>No, at one time I had the full UAS ID Type table here and I was asked to
> cut it:
>
>    ASTM Standard Specification for Remote ID and Tracking [F3411-19]
>    specifies three UAS ID types:
>
>    TYPE-1  A static, manufacturer assigned, hardware serial number per
>            ANSI/CTA-2063-A "Small Unmanned Aerial System Serial Numbers"
>            [CTA2063A].
>
>    TYPE-2  A CAA assigned (presumably static) ID.
>
>    TYPE-3  A UTM system assigned UUID [RFC4122].  These can be dynamic,
>          but do not need to be.
>
> Only the new Type-4, Session ID can support HHITs.  Well your type-1 CTA
> SN COULD be an encoded HHIT.

> Do you feel that this information should be added or text saying that
> HHIT is only used in type-4?

I would probably err on the side of saying less and make clear that only type-4 is relevant to HHIT.


> ** Section 4.2.  Please provide a normative reference for Base32.  RFC4648?
> We have had this discussion.  The CTA alphabet selection precludes
> referencing ANYthing I have found out there.  We MUST work with the
> letters and numbers they allow and it DOES NOT map to 4648.  We had this
> discussion during early reviews.

I leave this to WG and the AD.  We should technically have a citation on how to compute this Base32 variant if it isn’t the expected on RFC4648.

[Ballot comment]
OLD DISCUSSES:

#1

  Note that if the zone hhit.arpa is ultimately used, some registrar
  will need to manage this for all HHIT applications.

Regardless of what zone is used, someone needs to keep it operational.
It might be an attractive target to attack, eg to try and avoid drones
being shut down. I would feel much better if this zone was optional,
not mandatory. (but if optional, one could also argue maybe not have it
at all?)

  If the HHITs cannot be
  looked up with services provided by the registrar identified via the
  embedded hierarchical information or its registration validated by
  registration attestations messages [drip-authentication], then the
  HHIT is either fraudulent or revoked/expired.

That's quite catastrophic if there is a Registrar/Registry outage. Would
all the drones get shot down or would they all be ignored (so they can
fly to their terrorism target)

#2

As DISCUSS'ED by others, https://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hi-algorithm does not seem to have a third field for "status" to
denotate RECOMMENDED, REQUIRED, etc, even though RFC 7401 creates the registry,
uses the terms too but doesn't populate a status field. Perhaps this or another
short RFC could do so.

Also, 3.4.1 calls this "Algorithm profiles" and "Values" but the IANA registry
calls it "Algorithm Profile" (singular) and "Value" (singular)

#3

Section 3.4.1.1. has a NULL field of variable length ? Or perhaps the
slash and pipe symbols on those first and second lines got swapped by
accident?

#4

  The new EdDSA HI uses [RFC8080] for the IPSECKEY RR encoding:

      Value  Description

      TBD2 (suggested value 4)
            An EdDSA key is present, in the format defined in [RFC8080]

I have asked the Expert of this Registry whether they are okay with this
entry to the ipseckey-rr-parameters registry. It might be confusing for IKE.

COMMENTS:


#1

  100.hhit.arpa  IN PTR      raa.example.com.

Please add a trailing dot, eg "100.hhit.arpa."

Similarly for:

    100.50.det.uas.icao.int  IN PTR      foo.uss.icao.int.

#2

      HIP DNS RR (Resource Record)

Add reference to RFC5205 on its first mention.

#3

    However, this document does not intend to provide a recommendation.

weasel wording. It should probaby just state "this document does not provide
a recommendation."


#4

  The individual DETs may be potentially too numerous (e.g., 60 - 600M)
  and dynamic (e.g., new DETs every minute for some HDAs) to store in a
  signed, DNS zone.

This can be achieved with online signing. I would remove this speculative
sentence unless it is backed by some real numbers.

[Ballot comment]
I'm clearing my DISCUSS because my points were addressed, but I am still concerned by the issue in Comment 2 -- just because you *can* put stuff in the DNS, doesn't mean that you *should*. The DNS is a loosely coherent, scalable, distributed database with good performance and deployment -- but that doesn't mean that it should be overloaded to store $whatever - there is a complexity, scalability and monetary cost to running the system; it isn't a free, infinitely scalable resource, and we quickly get into a "tragedy of the commons" problem.


I have a few comments and questions related to this document:
1: "Address Block: IANA is requested to allocate a new 28-bit prefix out of the IANA IPv6 Special Purpose Address Block, namely 2001::/23, as per [RFC6890] (TBD6, suggested: 2001:30::/28)."
This seems like a *really* large block of addresses to be taking and using for this purpose - I understand that there is already some concern about the number of address bits being used for the crypto parts, but it does seem incredibly wasteful to be deciding to use this much of the IPv6 Special Purpose block for this -- there are only 32 /28s in the /23. Yes, IPv6 is large, but "no-one will need more that 640k of RAM", IPv4 was originally viewed as massive, etc --- this is 1,267,650,600,228,229,401,496,703,205,376 host addresses.

2: I have some reservations about how much this punts a large amount of work to the DNS -- "Note that if the zone hhit.arpa is ultimately used, some registrar will need to manage this for all HHIT applications.", etc.  Has there been discussion with the DNSOP WG about the potential load profile? And with the IAB about having an entry under .arpa for this? This does feel somewhat like the well known "just put it in the DNS"-type solution (see slide 13 here). Yes, the DNS is an incredibly good, well scaling solution, but there are costs, and I think that more investigation into how this gets used without just shifting costs to someone else is needed. This is repeated in things like "A DET reverse lookup could be to: a69e.ad0.1952.a3ad.1405.280.30.2001.20.10.det.arpa. or: a3ad1952ad0a69e.5.20.10.30.2001.det.remoteid.icao.int." - yes, it *could* be, but this feels like it is assuming that .arpa or .icao.int is happy to serve this function, have the registry, etc.

[Ballot comment]
Thanks for resolving my IANA Considerations concerns.

Rather than repeating them, I support Paul's and John's DISCUSS positions.

I like that we're recycling existing IETF technologies to map to a new purpose like this.  However, like Warren (who did not DISCUSS it or I would support that too), I'd like to hear about what consultation was done with DNSOP, if any.  I have the same question about REGEXT for the EPP references.

Section 3.3.1 says:

  [...]  An RAA MUST
  provide a set of services to allocate HDAs to organizations. 

Are we talking about online services of some kind?  If so, which ones?  If not, is this an appropriate use of BCP 14?

Sections 8.3 and 8.5 should be explicit that the Reference for the new entry is this document.  Even though that's obvious, the instructions should be complete.  (Note, for example, that they're correctly different in Section 8.4.)

[Ballot comment]
Thanks for addressing my discuss point and comments. I've pasted the previous discuss point below, for posterity.

Previous discuss:

1. In §3.2,

  The following HHIT Suite IDs are defined:

        HHIT Suite          Value
        RESERVED            0
        RSA,DSA/SHA-256    1    [RFC7401]
        ECDSA/SHA-384      2    [RFC7401]
        ECDSA_LOW/SHA-1    3    [RFC7401]
        EdDSA/cSHAKE128    TBD3 (suggested value 5)  (RECOMMENDED)

What, exactly, does the notation "RECOMMENDED" on the last quoted line mean? AFAICT there's no unambiguous way to parse this. My guess is that it's meant to mean "this is the suite we think you should use". Whatever the intended meaning, please elaborate to make the meaning clear. I suggest removing the notation from the table, and providing prose in some appropriate section instead, with "RECOMMENDED" if you think the RFC 2119 keyword is needed. If desired, you could xref that section from the table, although I don't think that's really necessary.

This comment also applies to the similar lines in §3.4.1, §3.4.1.1, and §3.4.2. The use in §3.4.1.1 is especially confounding, since the prose right before the table tells us that (all of) "the following EdDSA curves are required" (but evidently not REQUIRED)... but only some of the required curves are RECOMMENDED? I definitely have no clue, then, what "RECOMMENDED" means in this section. RFC 2119 basically defines RECOMMENDED as a weaker form of REQUIRED, but that doesn't seem to be how you're using it.

Similarly, I have no clue what "RECOMMENDED" is meant to mean in its several uses in §8.2 and §8.4. I suggest simply removing it from those sections entirely.

(Taken together, this comment covers every use of RECCOMMENDED in the document.)

Comments:

2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section.

3. I assume the "middle L-bit-long bitstring" thing you mention in various places is some well-known phrasing, but it's not something I'm familiar with, so please humor me by explaining what it would mean in the case where the argument bitstring is of even length and L is an odd number, or vice-versa? For example, consider the argument 0101 and L = 1. What's the "middle" value? Should this be clarified in this document, either by defining in-line or by reference to a document that does define it?

4. The document uses the term "unmanned" in various places, including its title. As you're probably aware, "The IESG [...] encourages IETF participants to use the guidance in [NISTIR8366] when making contributions to the IETF." (https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/)

It looks as though the aviation community is aware that "unmanned" isn't as inclusive as would be desirable (e.g., https://www.washingtonpost.com/transportation/2021/06/23/faa-gender-neutral-language/, https://www.federalregister.gov/documents/2021/10/26/2021-23280/notice-of-public-meeting) but just as in other industries, is still in the process of revising its document set.

I'm guessing the uses of "unmanned" in this document have been considered already and are necessary because they flow from definitions elsewhere, which have not been revised? If there is any space to move to more inclusive terminology, that would seem to be desirable. (E.g. "uncrewed" wouldn't even require an acronym change.)

5. Not a big deal considering you're describing another organization's format, not defining your own, but in §4.2,

  Encoding an HHIT within the CTA 2063-A format is not simple.  The CTA
  2063-A format is defined as follows:

  Serial Number  :=  MFR Code | Length Code | MFR SN

The flow and clarity would be better (IMO) if you stated in the "Encoding..." sentence what alphabet the format is defined over. From context I infer the alphabet is US-ASCII?

6. I am curious, in §4.6, you've capitalized "Observers" (and "Observer") as a proper noun, but there's no definition of it elsewhere. Is the capitalization in error, or should the term be defined? (A cursory look at [drip-authentication] suggests maybe that's where the term comes from, maybe an xref from your definitions section?)

7. Similarly, for capitalized "Pilot" in §6.

8. You create several registries with Expert Review policy. RFC 8126 §4.5 asks that:

  The required documentation and review criteria, giving clear guidance
  to the designated expert, should be provided when defining the
  registry. 
 
Please review RFC 8216 §4.5 (it's short) and ensure you've taken care of what's asked for there.

NITS:

9. In §3.4, is it "Edward-Curve", or "Edwards-Curve"? Please fix as appropriate.

10. In §3.5.1,

                                                    Care
  must be considering the size of the hash portion
 
Something's missing here. Perhaps "Care must be taken in considering..."?

11. In §4.2,

                                                  Definition of this
  mapping service is currently out of scope of this document.
 
I think you can drop "currently" considering you're going to press as an RFC.

[Ballot discuss]
John raised this in a comment, and I agree with it: Please provide proper guidance for your new registry's designated experts, or let's discuss why you think what's there is sufficient.

[Ballot comment]
Rather than repeating them, I support Paul's and John's DISCUSS positions.

I like that we're recycling existing IETF technologies to map to a new purpose like this.  However, like Warren (who did not DISCUSS it or I would support that too), I'd like to hear about what consultation was done with DNSOP, if any.  I have the same question about REGEXT for the EPP references.

Section 3.3.1 says:

  [...]  An RAA MUST
  provide a set of services to allocate HDAs to organizations. 

Are we talking about online services of some kind?  If so, which ones?  If not, is this an appropriate use of BCP 14?

Sections 8.3 and 8.5 should be explicit that the Reference for the new entry is this document.  Even though that's obvious, the instructions should be complete.  (Note, for example, that they're correctly different in Section 8.4.)

[Ballot comment]
Thanks for the document,

After reading the document I went through the other discuss points and they covered pretty much everything I had come up with and hence I support the other discusses, but with specific emphasis on Paul's discuss, as regards to making that zone mandatory and the failure situation that results.

[Ballot comment]
[NOTE: This ballot is not yet complete.  I'm traveling and will submit an update ASAP.]

John raised this in a comment, and I agree with it: You need to provide proper guidance for your new registry's designated experts.

[Ballot discuss]
#1

  Note that if the zone hhit.arpa is ultimately used, some registrar
  will need to manage this for all HHIT applications.

Regardless of what zone is used, someone needs to keep it operational.
It might be an attractive target to attack, eg to try and avoid drones
being shut down. I would feel much better if this zone was optional,
not mandatory. (but if optional, one could also argue maybe not have it
at all?)

  If the HHITs cannot be
  looked up with services provided by the registrar identified via the
  embedded hierarchical information or its registration validated by
  registration attestations messages [drip-authentication], then the
  HHIT is either fraudulent or revoked/expired.

That's quite catastrophic if there is a Registrar/Registry outage. Would
all the drones get shot down or would they all be ignored (so they can
fly to their terrorism target)

#2

As DISCUSS'ED by others, https://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hi-algorithm does not seem to have a third field for "status" to
denotate RECOMMENDED, REQUIRED, etc, even though RFC 7401 creates the registry,
uses the terms too but doesn't populate a status field. Perhaps this or another
short RFC could do so.

Also, 3.4.1 calls this "Algorithm profiles" and "Values" but the IANA registry
calls it "Algorithm Profile" (singular) and "Value" (singular)

#3

Section 3.4.1.1. has a NULL field of variable length ? Or perhaps the
slash and pipe symbols on those first and second lines got swapped by
accident?

#4

  The new EdDSA HI uses [RFC8080] for the IPSECKEY RR encoding:

      Value  Description

      TBD2 (suggested value 4)
            An EdDSA key is present, in the format defined in [RFC8080]

I have asked the Expert of this Registry whether they are okay with this
entry to the ipseckey-rr-parameters registry. It might be confusing for IKE.

[Ballot comment]
#1

  100.hhit.arpa  IN PTR      raa.example.com.

Please add a trailing dot, eg "100.hhit.arpa."

Similarly for:

    100.50.det.uas.icao.int  IN PTR      foo.uss.icao.int.

#2

      HIP DNS RR (Resource Record)

Add reference to RFC5205 on its first mention.

#3

    However, this document does not intend to provide a recommendation.

weasel wording. It should probaby just state "this document does not provide
a recommendation."


#4

  The individual DETs may be potentially too numerous (e.g., 60 - 600M)
  and dynamic (e.g., new DETs every minute for some HDAs) to store in a
  signed, DNS zone.

This can be achieved with online signing. I would remove this speculative
sentence unless it is backed by some real numbers.

[Ballot comment]
2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section.

3. I assume the "middle L-bit-long bitstring" thing you mention in various places is some well-known phrasing, but it's not something I'm familiar with, so please humor me by explaining what it would mean in the case where the argument bitstring is of even length and L is an odd number, or vice-versa? For example, consider the argument 0101 and L = 1. What's the "middle" value? Should this be clarified in this document, either by defining in-line or by reference to a document that does define it?

4. The document uses the term "unmanned" in various places, including its title. As you're probably aware, "The IESG [...] encourages IETF participants to use the guidance in [NISTIR8366] when making contributions to the IETF." (https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/)

It looks as though the aviation community is aware that "unmanned" isn't as inclusive as would be desirable (e.g., https://www.washingtonpost.com/transportation/2021/06/23/faa-gender-neutral-language/, https://www.federalregister.gov/documents/2021/10/26/2021-23280/notice-of-public-meeting) but just as in other industries, is still in the process of revising its document set.

I'm guessing the uses of "unmanned" in this document have been considered already and are necessary because they flow from definitions elsewhere, which have not been revised? If there is any space to move to more inclusive terminology, that would seem to be desirable. (E.g. "uncrewed" wouldn't even require an acronym change.)

5. Not a big deal considering you're describing another organization's format, not defining your own, but in §4.2,

  Encoding an HHIT within the CTA 2063-A format is not simple.  The CTA
  2063-A format is defined as follows:

  Serial Number  :=  MFR Code | Length Code | MFR SN

The flow and clarity would be better (IMO) if you stated in the "Encoding..." sentence what alphabet the format is defined over. From context I infer the alphabet is US-ASCII?

6. I am curious, in §4.6, you've capitalized "Observers" (and "Observer") as a proper noun, but there's no definition of it elsewhere. Is the capitalization in error, or should the term be defined? (A cursory look at [drip-authentication] suggests maybe that's where the term comes from, maybe an xref from your definitions section?)

7. Similarly, for capitalized "Pilot" in §6.

8. You create several registries with Expert Review policy. RFC 8126 §4.5 asks that:

  The required documentation and review criteria, giving clear guidance
  to the designated expert, should be provided when defining the
  registry. 
 
Please review RFC 8216 §4.5 (it's short) and ensure you've taken care of what's asked for there.

NITS:

9. In §3.4, is it "Edward-Curve", or "Edwards-Curve"? Please fix as appropriate.

10. In §3.5.1,

                                                    Care
  must be considering the size of the hash portion
 
Something's missing here. Perhaps "Care must be taken in considering..."?

11. In §4.2,

                                                  Definition of this
  mapping service is currently out of scope of this document.
 
I think you can drop "currently" considering you're going to press as an RFC.

[Ballot comment]
2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section.

3. I assume the "middle L-bit-long bitstring" thing you mention in various places is some well-known phrasing, but it's not something I'm familiar with, so please humor me by explaining what it would mean in the case where the argument bitstring is of even length and L is an odd number, or vice-versa? For example, consider the argument 0101 and L = 1. What's the "middle" value? Should this be clarified in this document, either by defining in-line or by reference to a document that does define it?

4. The document uses the term "unmanned" in various places, including its title. As you're probably aware, "The IESG [...] encourages IETF participants to use the guidance in [NISTIR8366] when making contributions to the IETF." (https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/)

It looks as though the aviation community is aware that "unmanned" isn't as inclusive as would be desirable (e.g., https://www.washingtonpost.com/transportation/2021/06/23/faa-gender-neutral-language/, https://www.federalregister.gov/documents/2021/10/26/2021-23280/notice-of-public-meeting) but just as in other industries, is still in the process of revising its document set.

I'm guessing the uses of "unmanned" in this document have been considered already and are necessary because they flow from definitions elsewhere, which have not been revised? If there is any space to move to more inclusive terminology, that would seem to be desirable. (E.g. "uncrewed" wouldn't even require an acronym change.)

5. Not a big deal considering you're describing another organization's format, not defining your own, but in §4.2,

  Encoding an HHIT within the CTA 2063-A format is not simple.  The CTA
  2063-A format is defined as follows:

  Serial Number  :=  MFR Code | Length Code | MFR SN

The flow and clarity would be better (IMO) if you stated in the "Encoding..." sentence what alphabet the format is defined over. From context I infer the alphabet is US-ASCII?

6. I am curious, in §4.6, you've capitalized "Observers" (and "Observer") as a proper noun, but there's no definition of it elsewhere. Is the capitalization in error, or should the term be defined? (A cursory look at [drip-authentication] suggests maybe that's where the term comes from, maybe an xref from your definitions section?)

7. Similarly, for capitalized "Pilot" in §6.

8. You create several registries with Expert Review policy. RFC 8126 §4.5 asks that:

  The required documentation and review criteria, giving clear guidance
  to the designated expert, should be provided when defining the
  registry. 
 
Please review RFC 8216 §4.5 (it's short) and ensure you've taken care of what's asked for there.

NITS:

9. In §3.4, is it "Edward-Curve", or "Edwards-Curve"? Please fix as appropriate.

10. In §3.5.1,

                                                    Care
  must be considering the size of the hash portion
 
Something's missing here. Perhaps "Care must be taken considering..."?

11. In §4.2,

                                                  Definition of this
  mapping service is currently out of scope of this document.
 
I think you can drop "currently" considering you're going to press as an RFC.

[Ballot comment]
2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section.

3. I assume the "middle L-bit-long bitstring" thing you mention in various places is some well-known phrasing, but it's not something I'm familiar with, so please humor me by explaining what it would mean in the case where the argument bitstring is of even length and L is an odd number, or vice-versa? For example, consider the argument 0101 and L = 1. What's the "middle" value? Should this be clarified in this document, either by defining in-line or by reference to a document that does define it?

4. The document uses the term "unmanned" in various places, including its title. As you're probably aware, "The IESG [...] encourages IETF participants to use the guidance in [NISTIR8366] when making contributions to the IETF." (https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/)

It looks as though the aviation community is aware that "unmanned" isn't as inclusive as would be desirable (e.g., https://www.washingtonpost.com/transportation/2021/06/23/faa-gender-neutral-language/, https://www.federalregister.gov/documents/2021/10/26/2021-23280/notice-of-public-meeting) but just as in other industries, is still in the process of revising its document set.

I'm guessing the uses of "unmanned" in this document have been considered already and are necessary because they flow from definitions elsewhere, which have not been revised? If there is any space to move to more inclusive terminology, that would seem to be desirable. (E.g. "uncrewed" wouldn't even require an acronym change.)

5. Not a big deal considering you're describing another organization's format, not defining your own, but in §4.2,

  Encoding an HHIT within the CTA 2063-A format is not simple.  The CTA
  2063-A format is defined as follows:

  Serial Number  :=  MFR Code | Length Code | MFR SN

The flow and clarity would be better (IMO) if you stated in the "Encoding..." sentence what alphabet the format is defined over. From context I infer the alphabet is US-ASCII?

6. I am curious, in §4.6, you've capitalized "Observers" (and "Observer") as a proper noun, but there's no definition of it elsewhere. Is the capitalization in error, or should the term be defined? (A cursory look at [drip-authentication] suggests maybe that's where the term comes from, maybe an xref from your definitions section?)

7. Similarly, for capitalized "Pilot" in §6.

8. You have several registries with Expert Review policy. RFC 8126 §4.5 asks that:

  The required documentation and review criteria, giving clear guidance
  to the designated expert, should be provided when defining the
  registry. 
 
Please review RFC 8216 §4.5 (it's short) and ensure you've taken care of what's asked for there.

NITS:

9. In §3.4, is it "Edward-Curve", or "Edwards-Curve"? Please fix as appropriate.

10. In §3.5.1,

                                                    Care
  must be considering the size of the hash portion
 
Something's missing here. Perhaps "Care must be taken considering..."?

11. In §4.2,

                                                  Definition of this
  mapping service is currently out of scope of this document.
 
I think you can drop "currently" considering you're going to press as an RFC.

[Ballot comment]
2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section.

3. I assume the "middle L-bit-long bitstring" thing you mention in various places is some well-known phrasing, but it's not something I'm familiar with, so please humor me by explaining what it would mean in the case where the argument bitstring is of even length and L is an odd number, or vice-versa? For example, consider the argument 0101 and L = 1. What's the "middle" value? Should this be clarified in this document, either by defining in-line or by reference to a document that does define it?

4. The document uses the term "unmanned" in various places, including its title. As you're probably aware, "The IESG [...] encourages IETF participants to use the guidance in [NISTIR8366] when making contributions to the IETF." (https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/)

It looks as though the aviation community is aware that "unmanned" isn't as inclusive as would be desirable (e.g., https://www.washingtonpost.com/transportation/2021/06/23/faa-gender-neutral-language/, https://www.federalregister.gov/documents/2021/10/26/2021-23280/notice-of-public-meeting) but just as in other industries, is still in the process of revising its document set.

I'm guessing the uses of "unmanned" in this document have been considered already and are necessary because they flow from definitions elsewhere, which have not been revised? If there is any space to move to more inclusive terminology, that would seem to be desirable. (E.g. "uncrewed" wouldn't even require an acronym change.)

5. Not a big deal considering you're describing another organization's format, not defining your own, but in §4.2,

  Encoding an HHIT within the CTA 2063-A format is not simple.  The CTA
  2063-A format is defined as follows:

  Serial Number  :=  MFR Code | Length Code | MFR SN

The flow would be better (IMO) if you stated in the "Encoding..." sentence what alphabet the format is defined over. From context I infer the alphabet is US-ASCII?

6. I am curious, in §4.6, you've capitalized "Observers" (and "Observer") as a proper noun, but there's no definition of it elsewhere. Is the capitalization in error, or should the term be defined? (A cursory look at [drip-authentication] suggests maybe that's where the term comes from, maybe an xref from your definitions section?)

7. Similarly, for capitalized "Pilot" in §6.

8. You have several registries with Expert Review policy. RFC 8126 §4.5 asks that:

  The required documentation and review criteria, giving clear guidance
  to the designated expert, should be provided when defining the
  registry. 
 
Please review RFC 8216 §4.5 (it's short) and ensure you've taken care of what's asked for there.

NITS:

9. In §3.4, is it "Edward-Curve", or "Edwards-Curve"? Please fix as appropriate.

10. In §3.5.1,

                                                    Care
  must be considering the size of the hash portion
 
Something's missing here. Perhaps "Care must be taken considering..."?

11. In §4.2,

                                                  Definition of this
  mapping service is currently out of scope of this document.
 
I think you can drop "currently" considering you're going to press as an RFC.

[Ballot discuss]
1. In §3.2,

  The following HHIT Suite IDs are defined:

        HHIT Suite          Value
        RESERVED            0
        RSA,DSA/SHA-256    1    [RFC7401]
        ECDSA/SHA-384      2    [RFC7401]
        ECDSA_LOW/SHA-1    3    [RFC7401]
        EdDSA/cSHAKE128    TBD3 (suggested value 5)  (RECOMMENDED)

What, exactly, does the notation "RECOMMENDED" on the last quoted line mean? AFAICT there's no unambiguous way to parse this. My guess is that it's meant to mean "this is the suite we think you should use". Whatever the intended meaning, please elaborate to make the meaning clear. I suggest removing the notation from the table, and providing prose in some appropriate section instead, with "RECOMMENDED" if you think the RFC 2119 keyword is needed. If desired, you could xref that section from the table, although I don't think that's really necessary.

This comment also applies to the similar lines in §3.4.1, §3.4.1.1, and §3.4.2. The use in §3.4.1.1 is especially confounding, since the prose right before the table tells us that (all of) "the following EdDSA curves are required" (but evidently not REQUIRED)... but only some of the required curves are RECOMMENDED? I definitely have no clue, then, what "RECOMMENDED" means in this section. RFC 2119 basically defines RECOMMENDED as a weaker form of REQUIRED, but that doesn't seem to be how you're using it.

Similarly, I have no clue what "RECOMMENDED" is meant to mean in its several uses in §8.2 and §8.4. I suggest simply removing it from those sections entirely.

(Taken together, this comment covers every use of RECCOMMENDED in the document.)

[Ballot comment]
2. Please define "CAA", either by expanding on first use (in §3.3) or in your Definitions section.

3. I assume the "middle L-bit-long bitstring" thing you mention in various places is some well-known phrasing, but it's not something I'm familiar with, so please humor me by explaining what it would mean in the case where the argument bitstring is of even length and L is an odd number, or vice-versa? For example, consider the argument 0101 and L = 1. What's the "middle" value? Should this be clarified in this document?

4. The document uses the term "unmanned" in various places, including its title. As you're probably aware, "The IESG [...] encourages IETF participants to use the guidance in [NISTIR8366] when making contributions to the IETF." (https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/)

It looks as though the aviation community is aware that "unmanned" isn't as inclusive as would be desirable (e.g., https://www.washingtonpost.com/transportation/2021/06/23/faa-gender-neutral-language/, https://www.federalregister.gov/documents/2021/10/26/2021-23280/notice-of-public-meeting) but just as in other industries, is still in the process of revising its document set.

I'm guessing the uses of "unmanned" in this document have been considered already and are necessary because they flow from definitions elsewhere, which have not been revised? If there is any space to move to more inclusive terminology, that would seem to be desirable. (E.g. "uncrewed" wouldn't even require an acronym change.)

5. Not a big deal considering you're describing another organization's format, not defining your own, but in §4.2,

  Encoding an HHIT within the CTA 2063-A format is not simple.  The CTA
  2063-A format is defined as follows:

  Serial Number  :=  MFR Code | Length Code | MFR SN

The flow would be better (IMO) if you stated in the "Encoding..." sentence what alphabet the format is defined over. From context I infer the alphabet is US-ASCII?

6. I am curious, in §4.6, you've capitalized "Observers" (and "Observer") as a proper noun, but there's no definition of it elsewhere. Is the capitalization in error, or should the term be defined? (A cursory look at [drip-authentication] suggests maybe that's where the term comes from, maybe an xref from your definitions section?)

7. Similarly, for capitalized "Pilot" in §6.

8. You have several registries with Expert Review policy. RFC 8126 §4.5 asks that:

  The required documentation and review criteria, giving clear guidance
  to the designated expert, should be provided when defining the
  registry. 
 
Please review RFC 8216 §4.5 (it's short) and ensure you've taken care of what's asked for there.

NITS:

9. In §3.4, is it "Edward-Curve", or "Edwards-Curve"? Please fix as appropriate.

10. In §3.5.1,

                                                    Care
  must be considering the size of the hash portion
 
Something's missing here. Perhaps "Care must be taken considering..."?

11. In §4.2,

                                                  Definition of this
  mapping service is currently out of scope of this document.
 
I think you can drop "currently" considering you're going to press as an RFC.

[Ballot discuss]
Apologies for the terse / rushed tone of this ballot - I'm currently traveling and really short on time.

1: "A mapping service (e.g., DNS) MUST provide a trusted (e.g., via DNSSEC [RFC4034]) conversion of the 4-character Manufacturer Code to high-order 58 bits (Prefix | HID) of the HHIT.  Definition of this mapping service is currently out of scope of this document." -- this feels really underspecified, especially because it is a MUST. DNSSEC provides channel security, but by itself doesn't provide "trusted" data, nor provide a "conversion", etc.
Where is the "trust" here? (Sec 9 doesn't really answer this) Who is supposed to run this? Even more so, why is this a "just stick it in the DNS" type solution (see comment #2).

2: "Now it should be noted that the 2^64 attempts is for stealing a specific HHIT.  Consider a scenario of a street photography company with 1,024 UAs (each with its own HHIT); you'd be happy stealing any one of them." This is only true if I want to steal one for this specific street photography company - surely I'd be perfectly happy "stealing" any HHIT that works? Doesn't that make it more on the order of (number of units), not 1024? Also, the "Therefore, the HHIT registration and HHIT/HI registration validation is strongly recommended." bit seems underspecified.

[Ballot comment]
Apologies for the terse review (and terse tone) -- I'm currently traveling and short on time.

I have a few comments and questions related to this document:
1: "Address Block: IANA is requested to allocate a new 28-bit prefix out of the IANA IPv6 Special Purpose Address Block, namely 2001::/23, as per [RFC6890] (TBD6, suggested: 2001:30::/28)."
This seems like a *really* large block of addresses to be taking and using for this purpose - I understand that there is already some concern about the number of address bits being used for the crypto parts, but it does seem incredibly wasteful to be deciding to use this much of the IPv6 Special Purpose block for this -- there are only 32 /28s in the /23. Yes, IPv6 is large, but "no-one will need more that 640k of RAM", IPv4 was originally viewed as massive, etc --- this is 1,267,650,600,228,229,401,496,703,205,376 host addresses.

2: I have some reservations about how much this punts a large amount of work to the DNS -- "Note that if the zone hhit.arpa is ultimately used, some registrar will need to manage this for all HHIT applications.", etc.  Has there been discussion with the DNSOP WG about the potential load profile? And with the IAB about having an entry under .arpa for this? This does feel somewhat like the well known "just put it in the DNS"-type solution (see slide 13 here). Yes, the DNS is an incredibly good, well scaling solution, but there are costs, and I think that more investigation into how this gets used without just shifting costs to someone else is needed. This is repeated in things like "A DET reverse lookup could be to: a69e.ad0.1952.a3ad.1405.280.30.2001.20.10.det.arpa. or: a3ad1952ad0a69e.5.20.10.30.2001.det.remoteid.icao.int." - yes, it *could* be, but this feels like it is assuming that .arpa or .icao.int is happy to serve this function, have the registry, etc.

[Ballot comment]
Thanks for working on this specification.

I have following comments/observations, which I believe will improve this specification if addressed.

- Section 1: says -

        This addition of hierarchy to HITs is an extension to [RFC7401] and requires an update to [RFC7343]. As this document also adds EdDSA (Section 3.4) for Host Identities (HIs), a number of Host Identity Protocol (HIP) parameters in [RFC7401] are updated, but these should not be needed in a DRIP implementation that does not use HIP.

    this actually puts me off, how does a DRIP implementation use HHIT without using RFC7401 when this is all about extending and updating 7401? what are the other options the DRIP implementation can use instead of this? if there are any why do we need this specification? I simply can't understand the claims here.

- I noted that there is downref to  8032, was this indicated in the last call announcement?

- Section 8.2 is shy of giving proper guidance for "Expert review". It points to Section 4.5 of RFC8126 and that section says -

    The required documentation and review criteria, giving clear guidance
  to the designated expert, should be provided when defining the
  registry.  It is particularly important to lay out what should be
  considered when performing an evaluation and reasons for rejecting a
  request.

  I didn't find any such description.

- I also noted that there is lack of discussion on HHIT registration and validation technique. For this I am supporting Romans Discuss point of HHIT registration and validation.

[Ballot comment]
Thanks for working on this specification.

I have following comments/observations, which I believe will improve this specification if addressed.

- Section 1: says -

        This addition of hierarchy to HITs is an extension to [RFC7401] and requires an update to [RFC7343]. As this document also adds EdDSA (Section 3.4) for Host Identities (HIs), a number of Host Identity Protocol (HIP) parameters in [RFC7401] are updated, but these should not be needed in a DRIP implementation that does not use HIP.

    this actually puts me off, how does a DRIP implementation use HHIT without using RFC7401 when this is all about extending and updating 7401? what are the other options the DRIP implementation can use instead of this? if there are any why do we need this specification? I simply can't understand the claims here.

- I noted that there is downref to  8032, was this indicated in the last call announcement?

- Section 8.2 is shy of giving proper guidance for "Expert review". It points to Section 4.5 of RFC8126 and that section says -

    The required documentation and review criteria, giving clear guidance
  to the designated expert, should be provided when defining the
  registry.  It is particularly important to lay out what should be
  considered when performing an evaluation and reasons for rejecting a
  request.

  I didn't any such description.

- I also noted that there is lack of discussion on HHIT registration and validation technique. For this I am supporting Romans Discuss point of HHIT registration and validation.

[Ballot discuss]
** With updates tag for RFC7343, I read the text in Section 3.5.* as providing a generic description of a new ORCHID computation techniques.  Other parts of the text describe how to use it for HIT and HHIT.  If that interpretation is correct:

-- Section 3.5.1. 
  With a 28-bit IPv6 prefix, the
  remaining 100 bits can be divided in any manner between the
  additional information ("Info"), OGA ID, and the hash output.

Since this section is describing a generic ORCHID technique, does this mean one could potentially choose a 0 or 1 bit hash output size?  All the provided security analysis is predicated on a 64-bit HIT.  What is associated analysis and security considerations for smaller HITs?

-- Section 3.5.1.
  The header content consists
  of the Prefix, the Additional Information ("Info"), and OGA ID (HIT
  Suite ID).  Secondly, the length of the resulting hash is set by sum
  of the length of the ORCHID header fields. 

The second sentence is true only if ORCHID setup is according to the DRIP spec: p=28, info=28, OGA-ID=8 to make 64 bits.  However, this is a generic update to define an ORCHID.  The previous text said that an OGA-ID could be 4 bits – 28+28+4 = 60, so if the “resulting hash should be set by the length of the ORCHID header field”, it would be off by 4 bits.

** Section 4.2
  A mapping service (e.g., DNS) MUST provide a trusted (e.g., via
  DNSSEC [RFC4034]) conversion of the 4-character Manufacturer Code to
  high-order 58 bits (Prefix | HID) of the HHIT.

Can this “trust” be described in more detail?  Section 4.4 makes it a point to say “cryptographically bind all content in the ORCHID through the hashing function.  A recipient of a DET that has the underlying HI can directly trust and act on all content in the HHIT”.  Here this information is being split.  Is the out-of-scope mechanism expected to provide a similar guarantee?

** Section 4.6

  The EdDSA25519 HI (Section 3.4) underlying the DET can be used in an
  84-byte self-proof attestation (timestamp, HHIT, and signature of
  these) to provide proof of Remote ID ownership (GEN-1 in [RFC9153]).
  In practice, the Wrapper and Manifest authentication formats
  (Sections 6.3.3 and 6.3.4 of [drip-authentication]) implicitly
  provide this self-attestation.  A lookup service like DNS can provide
  the HI and registration proof (GEN-3 in [RFC9153]).

  Similarly, for Observers without Internet access, a 200-byte offline
  self-attestation could provide the same Remote ID ownership proof.
  This attestation would contain the HDA's signing of the UA's HHIT,
  itself signed by the UA's HI.  Only a small cache that contains the
  HDA's HI/HHIT and HDA meta-data is needed by the Observer.  However,
  such an object would just fit in the ASTM Authentication Message
  (Section 2.2 of [RFC9153]) with no room for growth.  In practice,
  [drip-authentication] provides this offline self-attestation in two
  authentication messages: the HDA's certification of the UA's HHIT
  registration in a Link authentication message whose hash is sent in a
  Manifest authentication message.

I’m having trouble following along on where the guidance for offline verification is described – who exactly signs what with what key and in what format is this stored.  Is this considered in-scope for this document?  Given the asserted security properties,

-- I’ll note that draft-ietf-drip-auth is an informative reference.

-- What exactly needs to be in the offline Observer’s cache?  I couldn’t find that in draft-ietf-drip-auth.

-- Why is the first sentence in the first paragraph present?  It is describing a hypothetical situation that isn’t used in DRIP.  Likewise, the first sentence of the second paragraph also seems like a hypothetical using verbs like “could provide”

-- The text reference a lookup service, how does that service an offline Observer?

** Section 9. 
  Therefore, the HHIT registration and HHIT/HI registration validation
  is strongly recommended.

If validation isn’t done, who are the promised security guarantees of global non-collision possible?  Practically, why isn’t this a MUST?

** Section 9.5.

  The UAS/USS registration
  process should include registering the DET and MUST reject a
  collision, forcing the UAS to generate a new HI and thus HHIT and
  reapplying to the DET registration process.

How does a UAS “generate a new HI” in the case of a CTA2063A or manufacturer hard-coding the HHIT per Section 3.2 of draft-ietf-drip-arch-24?

[Ballot comment]
Thank you to Magnus Nystrom for the SECDIR Review and to Nicholas Gajcowski during the CFRG discussions.

** Section 3.3.1.  Please provide a reference for HIP RVS (RFC8004) and make it a normative reference.

** Section 3.3.1.
  Note that if the zone hhit.arpa is ultimately used, some registrar
  will need to manage this for all HHIT applications.  Thus further
  thought will be needed in the actual zone tree and registration
  process [drip-registries].

This won’t age well.  Either we know the approach for the zone, or the text isn’t included.  This is a proposed standard status document, not one that is experimental.

** Section 3.5.*.  What is means by this document updating RFC7343:

-- Section 3.5:
  This should be viewed as an update to ORCHIDv2 [RFC7343], as it can
  produce ORCHIDv2 output.

-- Section 3.5.1:
  The new ORCHID function is as follows:
  …
Can the text clarify in what way this is intended to be read by the reader – is this new ORCHID function replacing the current ORCHIDv2 generation technique, providing a second way to make an ORCHIDv2 identifier, making an “ORCHIDv2.1”?

** Section 3.5.1.  Proposed clarification:

OLD
p + n + o + m = 128 bits

NEW (or something like that)
Sizeof(p + n + o + m) 128 bits

** Section 4.
  The original UAS ID Types 1 - 3 allow for an UAS ID with a maximum
  length of 20 bytes, this new SSI (Type 4) uses the first byte of the
  ID for the SSI Type, thus restricting the UAS ID of this type to a
  maximum of 19 bytes.  The SSI Types initially assigned are :

  ID 1  IETF - DRIP Drone Remote ID Protocol (DRIP) entity ID.

  ID 2  3GPP - IEEE 1609.2-2016 HashedID8

-- Is this text saying that the HHITs format defined in this text can be used with a UAS ID Type = 1, 2, 3?

-- Why is it germane to talk about 3GPP as a UAS ID Types.  Wouldn’t it be more precise to say something to the effect of “when a SSI Type=4, the first byte of the UAS ID is set to 1 when a DET is used”?

** Section 4.2.  Please provide a normative reference for Base32.  RFC4648? 

** Section 4.2.  Please provide a reference of “Authentication Messages”.

** Section 4.5.
  A registration process,
  [drip-registries], ensures DET global uniqueness (ID-4 in [RFC9153]).

Given Section 4.2, aren’t the out-of-scope mapping process also required in certain circumstances?

** Section 5.
There are two approaches for storing and retrieving DETs using DNS.

Can the text more clearly explain who is retrieving the DETs.

** Section 5.

  The individual DETs may be potentially too numerous (e.g., 60 - 600M)
  and dynamic (e.g., new DETs every minute for some HDAs) to store in a
  signed, DNS zone.  The HDA SHOULD provide DNS service for its zone
  and provide the HHIT detail response.

-- What is the actionable guidance from this text?  The second sentence says HDA SHOULD provide a DNS service.  Is the first sentence saying that using DNSSEC won’t scale?  What is the impact of not using DNSEC?

-- How will revocation be handled if the HAD doesn’t provide a DNS service?

** Section 9.0

  A
  Python scrip t is available to randomly generate 1M HHITs that did not
  produce a hash collision which is a simpler attack than a first or
  second pre-image attack.

-- Per “A Python script is available …”, where is it available?
-- Why is producing a 1M HHIT list sufficient to motivate a reduced risk in second pre-image attack?  What's the "magic" of 1M?

** Section 9.0
  As such, use of DNSSEC by the DET registries is recommended to
  provide trust in HI retrieval.

Didn’t Section 5 say “The individual DETs may be potentially too numerous (e.g., 60 - 600M) and dynamic (e.g., new DETs every minute for some HDAs) to store in a signed, DNS zone” acknowledge that DNSSEC won’t scale or perform.  If that’s the case, this is an odd recommendation.

** Section 9.4

  That is, the MAC address should be
  stable for at least a UA operation.

Where is the definition which time bounds “UA operation”?

** Section 9.5

  The 64-bit hash size does have an increased risk of collisions over
  the 96-bit hash size used for the other HIT Suites

Is it “over … other HIT Suites” or when ORCHIDv2 is used to construct a HIT?

[Ballot comment]
# Internet AD comments for {draft-ietf-drip-rid-28}
CC @ekline

## Comments

### S3.5.1

* "Care must be considering the size" doesn't quite read correctly to me.
  "Consideration must be given to the size of the hash portion..."?

* This whole final paragraph I find a bit obscure.  Especially since
  mentally I'm comparing it to layout depicted in Figure 1. Is "(n)" where
  the RAA and HDA bits get encoded?  I assume that's what's meant by the
  reference to "28 bits" at the end.

  I think just being a bit more explicit should suffice to make it that
  much easier to follow.

## Nits

### S9

* "you'd be happy" -> "an attacker may well be satisfied"

  Consider changing all 2nd person usages to 3rd person.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-drip-rid-25. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

We understand that, upon approval of this document, there are eight actions which we must complete.

First, in the IANA IPv6 Special-Purpose Address Registry located at:

https://www.iana.org/assignments/iana-ipv6-special-registry

a new registration is to be made as follows:

Address Block: TBD (suggested: 2001:30::/28)
Name: DRIP Entity Tags (DETs) Prefix
RFC: [ RFC-to-be ]
Allocation Date: TBD
Termination Date: N/A
Source: False
Destination: False
Globally Reachable: False
Reserved-by-Protocol: False

Second, a new registry page will be created called the Drone Remote ID Protocol. The Hierarchical HIT (HHIT) Prefixes registry will be created on the Drone Remote ID Protocol registry page.

The registration procedure for the registry will be Expert Review as defined in RFC8126. There is an initial registration in the new registry as follows:

HHIT Use: DET
Bits: 28
Value: TBD (suggested: 2001:30::/28)
Reference: [ RFC-to-be ]

Third, a new registry will be created called the Hierarchical HIT (HHIT) Suite ID registry also on the Drone Remote ID Protocol registry page.

The registration procedure for the registry will be IETF Review as defined in RFC8126. There are initial registrations in the new registry as follows:

HHIT Suite          Value Reference
RESERVED            0 [ RFC-to-be ]
RSA,DSA/SHA-256    1    [RFC7401]
ECDSA/SHA-384      2    [RFC7401]
ECDSA_LOW/SHA-1    3    [RFC7401]
EdDSA/cSHAKE128    TBD3 (suggested value 5)  (RECOMMENDED) [ RFC-to-be ]
HDA Private Use 1  TBD4 (suggested value 254) [ RFC-to-be ]
HDA Private Use 2  TBD5 (suggested value 255) [ RFC-to-be ]

Fourth, in the CGA Extension Type Tags registry on the Cryptographically Generated Addresses (CGA) Message Type Name Space registry page located at:

https://www.iana.org/assignments/cga-message-types

a new registration will be made as follows:

CGA Type Tag: 0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40
Reference: [ RFC-to-be ]

In addition, we will also list this document as an additional reference for the CGA Extension Type Tags registry.

Fifth, in the HI Algorithm registry on the Host Identity Protocol (HIP) Parameters registry page located at:

https://www.iana.org/assignments/hip-parameters

a new registration will be made as follows:

Value: TDB
Algorithm Profile: EdDSA
Reference: [RFC8032][ RFC-to-be ]

IANA notes that the authors suggest a value 13 for this registration.

Sixth, a new subregistry will be created called the EdDSA Curve Label on the Host Identity Protocol (HIP) Parameters registry page located at:

https://www.iana.org/assignments/hip-parameters

There are initial registrations in the subregistry as follows:

Algorithm    Curve            Values Reference

EdDSA        RESERVED        0 [ RFC-to-be ]
EdDSA        EdDSA25519      1 [RFC8032]         
EdDSA        EdDSA25519ph    2 [RFC8032]
EdDSA        EdDSA448        3 [RFC8032]         
EdDSA        EdDSA448ph      4 [RFC8032]
            Unassigned      5-65535             

IANA Question: What is the registration procedure for this new subregistry?

Seventh, in the HIT Suite ID registry on the Host Identity Protocol (HIP) Parameters registry page located at:

https://www.iana.org/assignments/hip-parameters

a new registration will be made as follows:

Value: TBD
Suite ID: EdDSA/cSHAKE128
Reference: [ RFC-to-be ]

IANA notes that the authors suggest a value 5 for this registration.

Eighth, in the Algorithm Type Field registry on the IPSECKEY Resource Record Parameters registry page located at:

https://www.iana.org/assignments/ipseckey-rr-parameters

a new registration will be made as follows:

Value: TBD
Description: An EdDSA key is present, in the format defined in [RFC8080]
Reference: [ RFC-to-be ]

IANA notes that the authors suggest a value 4 for this registration.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Please note that specific values cannot be reserved. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

A revised I-D is needed to address the IOT directorate and Gen ART Last Call reviews.
It would be nice to move the -arch and the -rid together from now on.

Good job by the authors (including fast replies to the reviews).

Regards,

-éric

The following Last Call announcement was sent out (ends 2022-05-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-drip-rid@ietf.org, drip-chairs@ietf.org, evyncke@cisco.com, mohamed.boucadair@orange.com, tm-rid@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)) to Proposed Standard


The IESG has received a request from the Drone Remote ID Protocol WG (drip)
to consider the following document: - 'DRIP Entity Tag (DET) for Unmanned
Aircraft System Remote ID (UAS RID)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-05-11. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the use of Hierarchical Host Identity Tags
  (HHITs) as self-asserting IPv6 addresses and thereby a trustable
  identifier for use as the Unmanned Aircraft System Remote
  Identification and tracking (UAS RID).

  This document updates RFC7401 and RFC7343.

  Within the context of RID, HHITs will be called DRIP Entity Tags
  (DETs).  HHITs self-attest to the included explicit hierarchy that
  provides registry (via, e.g., DNS, EPP) discovery for 3rd-party
  identifier attestation.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-drip-rid/



No IPR declarations have been submitted directly on this I-D.

Shepherd write-up for draft-ietf-drip-rid-22

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
    is this the proper type of RFC? Is this type of RFC indicated in
    the title page header?

  This document requests publication as a Proposed Standard RFC. That
  is indicated on the header page. The intended status is justified
  given that the document (1) specifies a modified version of host
  identity tags (initially defined in RFC 7401 that was published in
  Standards Track) and (2) updates RFC 7343 (also published in the
  Standards Track).

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the
    following sections:

Technical Summary:
   
  This document specifies DRIP Entity Tags (DETs) that are used for
  drone identification purposes (a.k.a., UAS Remote ID). DETs rely
  upon Hierarchical Host Identity Tags (HHITs) which are defined as
  self-asserting IPv6 addresses. Also, these HHITs include explicit
  hierarchy to enable DNS queries and discovery of specific registrars
  for 3rd-party identification attestation purposes.

Working Group Summary:

  This document ran 8 versions before adoption by the WG (including a
  version that passed surprisingly through without any validation by
  the submission part of the datatracker and published as draft-ietf-drip-*;
  see https://datatracker.ietf.org/doc/draft-ietf-drip-uas-rid/history/).

  Regular slots were dedicated to this draft in several WG meetings.
  The authors implemented the outcomes of the discussions held in these
  meetings and the mailing list.

  Once the draft was adopted, a note was sent to HIPSEC mailing
  (https://mailarchive.ietf.org/arch/msg/
  hipsec/2ojLTMCR7-YKQ5RJ68pBABF4mSY/) to check if there are any issues
  with the specification (HIP part), but no follow up message was received.

  Early SECDIR and IOTDIR reviews were requested by the Chairs against
  -07. These reviews were addressed by the authors.

  As suggested by the SECDIR reviewer, a review request was sent to the
  CFRG for review (31/08/2021). A discussion in the CFRG mailing list
  was then triggered: https://mailarchive.ietf.org/arch/msg/
  cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) with the outcomes
  implemented in -11.

  A note was also sent to SAAG to seek for reviews, especially the
  privacy section (https://mailarchive.ietf.org/arch/msg/
  saag/5tyVqtjCGKVcSeX9gpS4_feI7YQ/). No follow up message was received :-(

  The draft used to include some actions on behalf of the ICAO (RAA
  assignment, for example), while these are not formally discussed by
  the WG. These statements were removed and an action plan was agreed.

  The WG agreed that no RAA assignment policy will be included in this
  document. Such considerations (e.g., whether to abandon the control on
  the RAA assignment bound to the IANA-assigned prefix or keep the full
  control but have a provision for some delegation) will be covered in
  draft-ietf-drip-registries. From an interoperability, this plan is OK
  as DETs are unambiguously identified by the prefix.

  There was a concern whether /28 prefix is sufficient to cover any
  HHIT needs, not only DETs. The main outcomes were:

  o  The IPv6 prefix is for DRIP use and, as such, the requested prefix
      size is reasonable. This block should be named "DRIP Device
      Entity Tags (DETs) Prefix" to avoid any confusion.

  o  Maintain the request for the IANA /28 prefix.

  o  Add a provision for the use of other prefixes, including network-
      specific prefixes.

  o  To unambiguously identify a DET, create a new registry to list
      prefixes used for DET purposes.
   
  Some issues were reported by IANA against -13: add a registration
  procedure for the new EdDSA Curve Label registry, indicate the upper
  boundary for the registry's Value field, etc.

  Sections 3.4.1 and 3.4.2 discuss HIP parameters that are impacted
  as a side effect of defining EdDSA as a HI algorithm.  These
  parameters are not needed for DRIP. The draft includes two notes to
  make this clear enough.

  At least two implementations were reported to the WG, one of them is
  proprietary.

Document Quality:

  The various reviews helped to enhance the quality of the document.

Personnel:

  The document shepherd is Mohamed Boucadair

  The Responsible Area Director is Éric Vyncke

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.

  At least three detailed reviews were made by the Document Shepherd:

  o  -07: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/
      draft-ietf-drip-rid-07-rev%20Med.pdf

  o  -13: https://raw.githubusercontent.com/boucadair/IETF-Drafts-
      Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf

  o  -18: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/
      draft-ietf-drip-rid-18-rev%20Med.pdf

  The authors have taken into account these various reviews.

  This version is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

  No concern.

(5) Do portions of the document need review from a particular or from
    broader perspective.

  No.

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area Director
    and/or the IESG should be aware of?

  No.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed.

  Yes. IPR responses can be seen at:

  * Robert Moskowitz:  https://mailarchive.ietf.org/arch/msg/tm-rid/H9G2SawqP0PtJyQK6LciyBGULgY/

  * Stuart Card:  https://mailarchive.ietf.org/arch/msg/tm-rid/WL2bPmcLpvMOHMfH-OrEN7UII5E/

  * Adam Wiethuechter:  https://mailarchive.ietf.org/arch/msg/tm-rid/9Ut-t3dVDZmEFz6xHSwcSIssYgs/

  * Andrei Gurtov:  https://mailarchive.ietf.org/arch/msg/tm-rid/fmiSIhWgOsmtvIYGmBPHKVBfpyY/

(8) Has an IPR disclosure been filed that references this document?

  No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with
    it?

  The consensus is solid.


(10) Has anyone threatened an appeal or otherwise indicated extreme
      discontent?

  No.

(11) Identify any ID nits the Document Shepherd has found in this
      document.

  Some issues were found and shared with the authors (e.g., citations
  in abstract, self-contained updated).  These were fixed by the
  authors.

  Idnits still displays the following:

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


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
    document.

  == There are 8 instances of lines with non-RFC3849-compliant IPv6 addresses
    in the document.  If these are example addresses, they should be changed.


  ... but all these are false positives:

  o  The first nit is related to the affiliation of one of the co-
      authors.

  o  The second nit is related to '100.hhit.arpa', but that's a valid
      example.

  o  The third nit is related to the IANA IPv6 prefix.


(12) Describe how the document meets any required formal review
      criteria

  No formal language is used.

(13) Have all references within this document been identified as
      either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready
      for advancement or are otherwise in an unclear state? If such
      normative references exist, what is the plan for their
      completion?

  All normative references are published RFCs or publicly available
  stable specifications.

(15) Are there downward normative references references (see
      RFC 3967)?

  Yes, RFC8032.
  RFC8032 is already listed in https://datatracker.ietf.org/doc/downref/.

(16) Will publication of this document change the status of any
      existing RFCs?

  No.

(17) Describe the Document Shepherd's review of the IANA
      considerations section.

  o  The document creates a new registry for DRIP.  It also creates a
      two subregistries under that registry.  The required policy for
      adding new entries is provided for each of these subregistries.

  o  Updates a set of existing registries.  The required information
      to complete the actions, including where to find the registries, is
      provided.

(18) List any new IANA registries that require Expert Review for
      future allocations.

  "Hierarchical HIT (HHIT) Prefixes"

(19) Describe reviews and automated checks performed by the Document
      Shepherd to validate sections of the document written in a formal
      language.

  N/A

(20) If the document contains a YANG module

  N/A

Shepherd write-up for draft-ietf-drip-rid-22

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
    is this the proper type of RFC? Is this type of RFC indicated in
    the title page header?

  This document requests publication as a Proposed Standard RFC. That
  is indicated on the header page. The intended status is justified
  given that the document (1) specifies a modified version of host
  identity tags (initially defined in RFC 7401 that was published in
  Standards Track) and (2) updates RFC 7343 (also published in the
  Standards Track).

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the
    following sections:

Technical Summary:
   
  This document specifies DRIP Entity Tags (DETs) that are used for
  drone identification purposes (a.k.a., UAS Remote ID). DETs rely
  upon Hierarchical Host Identity Tags (HHITs) which are defined as
  self-asserting IPv6 addresses. Also, these HHITs include explicit
  hierarchy to enable DNS queries and discovery of specific registrars
  for 3rd-party identification attestation purposes.

Working Group Summary:

  This document ran 8 versions before adoption by the WG (including a
  version that passed surprisingly through without any validation and
  published as draft-ietf-drip-*).

  Regular slots were dedicated to this draft in several WG meetings.
  The authors implemented the outcomes of the discussions held in these
  meetings and the mailing list.

  Once the draft was adopted, a note was sent to HIPSEC mailing
  (https://mailarchive.ietf.org/arch/msg/
  hipsec/2ojLTMCR7-YKQ5RJ68pBABF4mSY/) to check if there are any issues
  with the specification (HIP part), but no follow up message was received.

  Early SECDIR and IOTDIR reviews were requested by the Chairs against
  -07. These reviews were addressed by the authors.

  As suggested by the SECDIR reviewer, a review request was sent to the
  CFRG for review (31/08/2021). A discussion in the CFRG mailing list
  was then triggered: https://mailarchive.ietf.org/arch/msg/
  cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) with the outcomes
  implemented in -11.

  A note was also sent to SAAG to seek for reviews, especially the
  privacy section (https://mailarchive.ietf.org/arch/msg/
  saag/5tyVqtjCGKVcSeX9gpS4_feI7YQ/). No follow up message was received :-(

  The draft used to include some actions on behalf of the ICAO (RAA
  assignment, for example), while these are not formally discussed by
  the WG. These statements were removed and an action plan was agreed.

  The WG agreed that no RAA assignment policy will be included in this
  document. Such considerations (e.g., whether to abandon the control on
  the RAA assignment bound to the IANA-assigned prefix or keep the full
  control but have a provision for some delegation) will be covered in
  draft-ietf-drip-registries. From an interoperability, this plan is OK
  as DETs are unambiguously identified by the prefix.

  There was a concern whether /28 prefix is sufficient to cover any
  HHIT needs, not only DETs. The main outcomes were:

  o  The IPv6 prefix is for DRIP use and, as such, the requested prefix
      size is reasonable. This block should be named "DRIP Device
      Entity Tags (DETs) Prefix" to avoid any confusion.

  o  Maintain the request for the IANA /28 prefix.

  o  Add a provision for the use of other prefixes, including network-
      specific prefixes.

  o  To unambiguously identify a DET, create a new registry to list
      prefixes used for DET purposes.
   
  Some issues were reported by IANA against -13: add a registration
  procedure for the new EdDSA Curve Label registry, indicate the upper
  boundary for the registry's Value field, etc.

  Sections 3.4.1 and 3.4.2 discuss HIP parameters that are impacted
  as a side effect of defining EdDSA as a HI algorithm.  These
  parameters are not needed for DRIP. The draft includes two notes to
  make this clear enough.

  At least two implementations were reported to the WG, one of them is
  proprietary.

Document Quality:

  The various reviews helped to enhance the quality of the document.

Personnel:

  The document shepherd is Mohamed Boucadair

  The Responsible Area Director is Éric Vyncke

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.

  At least three detailed reviews were made by the Document Shepherd:

  o  -07: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/
      draft-ietf-drip-rid-07-rev%20Med.pdf

  o  -13: https://raw.githubusercontent.com/boucadair/IETF-Drafts-
      Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf

  o  -18: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/
      draft-ietf-drip-rid-18-rev%20Med.pdf

  The authors have taken into account these various reviews.

  This version is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

  No concern.

(5) Do portions of the document need review from a particular or from
    broader perspective.

  No.

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area Director
    and/or the IESG should be aware of?

  No.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed.

  Yes. IPR responses can be seen at:

  * Robert Moskowitz:  https://mailarchive.ietf.org/arch/msg/tm-rid/H9G2SawqP0PtJyQK6LciyBGULgY/

  * Stuart Card:  https://mailarchive.ietf.org/arch/msg/tm-rid/WL2bPmcLpvMOHMfH-OrEN7UII5E/

  * Adam Wiethuechter:  https://mailarchive.ietf.org/arch/msg/tm-rid/9Ut-t3dVDZmEFz6xHSwcSIssYgs/

  * Andrei Gurtov:  https://mailarchive.ietf.org/arch/msg/tm-rid/fmiSIhWgOsmtvIYGmBPHKVBfpyY/

(8) Has an IPR disclosure been filed that references this document?

  No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with
    it?

  The consensus is solid.


(10) Has anyone threatened an appeal or otherwise indicated extreme
      discontent?

  No.

(11) Identify any ID nits the Document Shepherd has found in this
      document.

  Some issues were found and shared with the authors (e.g., citations
  in abstract, self-contained updated).  These were fixed by the
  authors.

  Idnits still displays the following:

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


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
    document.

  == There are 8 instances of lines with non-RFC3849-compliant IPv6 addresses
    in the document.  If these are example addresses, they should be changed.


  ... but all these are false positives:

  o  The first nit is related to the affiliation of one of the co-
      authors.

  o  The second nit is related to '100.hhit.arpa', but that's a valid
      example.

  o  The third nit is related to the IANA IPv6 prefix.


(12) Describe how the document meets any required formal review
      criteria

  No formal language is used.

(13) Have all references within this document been identified as
      either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready
      for advancement or are otherwise in an unclear state? If such
      normative references exist, what is the plan for their
      completion?

  All normative references are published RFCs or publicly available
  stable specifications.

(15) Are there downward normative references references (see
      RFC 3967)?

  Yes, RFC8032.
  RFC8032 is already listed in https://datatracker.ietf.org/doc/downref/.

(16) Will publication of this document change the status of any
      existing RFCs?

  No.

(17) Describe the Document Shepherd's review of the IANA
      considerations section.

  o  The document creates a new registry for DRIP.  It also creates a
      two subregistries under that registry.  The required policy for
      adding new entries is provided for each of these subregistries.

  o  Updates a set of existing registries.  The required information
      to complete the actions, including where to find the registries, is
      provided.

(18) List any new IANA registries that require Expert Review for
      future allocations.

  "Hierarchical HIT (HHIT) Prefixes"

(19) Describe reviews and automated checks performed by the Document
      Shepherd to validate sections of the document written in a formal
      language.

  N/A

(20) If the document contains a YANG module

  N/A

Shepherd write-up for draft-ietf-drip-rid-20

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
    is this the proper type of RFC? Is this type of RFC indicated in
    the title page header?

  This document requests publication as a Proposed Standard RFC. That
  is indicated on the header page. The intended status is justified
  given that the document (1) specifies a modified version of host
  identity tags (initially defined in RFC 7401 that was published in
  Standards Track) and (2) updates RFC 7343 (also published in the
  Standards Track).

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the
    following sections:

Technical Summary:
   
  This document specifies DRIP Entity Tags (DETs) that are used for
  drone identification purposes (a.k.a., UAS Remote ID). DETs rely
  upon Hierarchical Host Identity Tags (HHITs) which are defined as
  self-asserting IPv6 addresses. Also, these HHITs include explicit
  hierarchy to enable DNS queries and discovery of specific registrars
  for 3rd-party identification attestation purposes.

Working Group Summary:

  This document ran 8 versions before adoption by the WG (including a
  version that passed surprisingly through without any validation and
  published as draft-ietf-drip-*).

  Regular slots were dedicated to this draft in several WG meetings.
  The authors implemented the outcomes of the discussions held in these
  meetings and the mailing list.

  Once the draft was adopted, a note was sent to HIPSEC mailing
  (https://mailarchive.ietf.org/arch/msg/
  hipsec/2ojLTMCR7-YKQ5RJ68pBABF4mSY/) to check if there are any issues
  with the specification (HIP part), but no follow up message was received.

  Early SECDIR and IOTDIR reviews were requested by the Chairs against
  -07. These reviews were addressed by the authors.

  As suggested by the SECDIR reviewer, a review request was sent to the
  CFRG for review (31/08/2021). A discussion in the CFRG mailing list
  was then triggered: https://mailarchive.ietf.org/arch/msg/
  cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) with the outcomes
  implemented in -11.

  A note was also sent to SAAG to seek for reviews, especially the
  privacy section (https://mailarchive.ietf.org/arch/msg/
  saag/5tyVqtjCGKVcSeX9gpS4_feI7YQ/). No follow up message was received :-(

  The draft used to include some actions on behalf of the ICAO (RAA
  assignment, for example), while these are not formally discussed by
  the WG. These statements were removed and an action plan was agreed.

  The WG agreed that no RAA assignment policy will be included in this
  document. Such considerations (e.g., whether to abandon the control on
  the RAA assignment bound to the IANA-assigned prefix or keep the full
  control but have a provision for some delegation) will be covered in
  draft-ietf-drip-registries. From an interoperability, this plan is OK
  as DETs are unambiguously identified by the prefix.

  There was a concern whether /28 prefix is sufficient to cover any
  HHIT needs, not only DETs. The main outcomes were:

  o  The IPv6 prefix is for DRIP use and, as such, the requested prefix
      size is reasonable. This block should be named "DRIP Device
      Entity Tags (DETs) Prefix" to avoid any confusion.

  o  Maintain the request for the IANA /28 prefix.

  o  Add a provision for the use of other prefixes, including network-
      specific prefixes.

  o  To unambiguously identify a DET, create a new registry to list
      prefixes used for DET purposes.
   
  Some issues were reported by IANA against -13: add a registration
  procedure for the new EdDSA Curve Label registry, indicate the upper
  boundary for the registry's Value field, etc.

  Sections 3.4.1 and 3.4.2 discuss HIP parameters that are impacted
  as a side effect of defining EdDSA as a HI algorithm.  These
  parameters are not needed for DRIP. The draft includes two notes to
  make this clear enough.

  At least two implementations were reported to the WG, one of them is
  proprietary.

Document Quality:

  The various reviews helped to enhance the quality of the document.

Personnel:

  The document shepherd is Mohamed Boucadair

  The Responsible Area Director is Eric Vyncke

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.

  At least three detailed reviews were made by the Document Shepherd:

  o  -07: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/
      draft-ietf-drip-rid-07-rev%20Med.pdf

  o  -13: https://raw.githubusercontent.com/boucadair/IETF-Drafts-
      Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf

  o  -18: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/
      draft-ietf-drip-rid-18-rev%20Med.pdf

  The authors have taken into account these various reviews.

  This version is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

  No concern.

(5) Do portions of the document need review from a particular or from
    broader perspective.

  No.

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area Director
    and/or the IESG should be aware of?

  No.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed.

  Yes. IPR responses can be seen at:

  * Robert Moskowitz:  https://mailarchive.ietf.org/arch/msg/tm-rid/H9G2SawqP0PtJyQK6LciyBGULgY/

  * Stuart Card:  https://mailarchive.ietf.org/arch/msg/tm-rid/WL2bPmcLpvMOHMfH-OrEN7UII5E/

  * Adam Wiethuechter:  https://mailarchive.ietf.org/arch/msg/tm-rid/9Ut-t3dVDZmEFz6xHSwcSIssYgs/

  * Andrei Gurtov:  https://mailarchive.ietf.org/arch/msg/tm-rid/fmiSIhWgOsmtvIYGmBPHKVBfpyY/

(8) Has an IPR disclosure been filed that references this document?

  No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with
    it?

  The consensus is solid.


(10) Has anyone threatened an appeal or otherwise indicated extreme
      discontent?

  No.

(11) Identify any ID nits the Document Shepherd has found in this
      document.

  Some issues were found and shared with the authors (e.g., citations
  in abstract, self-contained updated).  These were fixed by the
  authors.

  Idnits still displays the following:

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


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
    document.

  == There are 8 instances of lines with non-RFC3849-compliant IPv6 addresses
    in the document.  If these are example addresses, they should be changed.


  ... but all these are false positives:

  o  The first nit is related to the affiliation of one of the co-
      authors.

  o  The second nit is related to '100.hhit.arpa', but that's a valid
      example.

  o  The third nit is related to the IANA IPv6 prefix.


(12) Describe how the document meets any required formal review
      criteria

  No formal language is used.

(13) Have all references within this document been identified as
      either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready
      for advancement or are otherwise in an unclear state? If such
      normative references exist, what is the plan for their
      completion?

  All normative references are published RFCs or publicly available
  stable specifications.

(15) Are there downward normative references references (see
      RFC 3967)?

  No.

(16) Will publication of this document change the status of any
      existing RFCs?

  No.

(17) Describe the Document Shepherd's review of the IANA
      considerations section.

  o  The document creates a new registry for DRIP.  It also creates a
      two subregistries under that registry.  The required policy for
      adding new entries is provided for each of these subregistries.

  o  Updates a set of existing registries.  The required information
      to complete the actions, including where to find the registries, is
      provided.

(18) List any new IANA registries that require Expert Review for
      future allocations.

  "Hierarchical HIT (HHIT) Prefixes"

(19) Describe reviews and automated checks performed by the Document
      Shepherd to validate sections of the document written in a formal
      language.

  N/A

(20) If the document contains a YANG module

  N/A

Shepherd write-up for draft-ietf-drip-rid-20

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
    is this the proper type of RFC? Is this type of RFC indicated in
    the title page header?

  This document requests publication as a Proposed Standard RFC. That
  is indicated on the header page. The intended status is justified
  given that the document (1) specifies a modified version of host
  identity tags (initially defined in RFC 7401 that was published in
  Standards Track) and (2) updates RFC 7343 (also published in the
  Standards Track).

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the
    following sections:

Technical Summary:
   
  This document specifies DRIP Entity Tags (DETs) that are used for
  drone identification purposes (a.k.a., UAS Remote ID). DETs rely
  upon Hierarchical Host Identity Tags (HHITs) which are defined as
  self-asserting IPv6 addresses. Also, these HHITs include explicit
  hierarchy to enable DNS queries and discovery of specific registrars
  for 3rd-party identification attestation purposes.

Working Group Summary:

  This document ran 8 versions before adoption by the WG (including a
  version that passed surprisingly through without any validation and
  published as draft-ietf-drip-uas-rid).

  Regular slots were dedicated to this draft in several WG meetings.
  The authors implemented the outcomes of the discussions held in these
  meetings and the mailing list.

  Once the draft was adopted, a note was sent to HIPSEC mailing
  (https://mailarchive.ietf.org/arch/msg/
  hipsec/2ojLTMCR7-YKQ5RJ68pBABF4mSY/) to check if there are any issues
  with the specification, but no follow up message was received.

  Early SECDIR and IOTDIR reviews were requested by the Chairs against
  -07. These reviews were addressed by the authors.

  As suggested by the SECDIR reviewer, a review request was sent to the
  CFRG for review (31/08/2021). A discussion in the CFRG mailing list
  was then triggered: https://mailarchive.ietf.org/arch/msg/
  cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) with the outcomes
  implemented in -11.

  A note was also sent to SAAG to seek for reviews, especially the
  privacy section (https://mailarchive.ietf.org/arch/msg/
  saag/5tyVqtjCGKVcSeX9gpS4_feI7YQ/). No follow up message was received :-(

  The draft used to include some actions on behalf of the ICAO (RAA
  assignment, for example) while these are not formally discussed by
  the WG. These statements were removed and an action plan was agreed.

  The WG agreed that no RAA assignment policy will be included in this
  document. Such considerations (e.g., whether to abandon the control on
  the RAA assignment bound to the IANA-assigned prefix or keep the full
  control but have a provision for some delegation) will be covered in
  draft-ietf-drip-registries. From an interperiablity, this plan is OK
  as DETs are unambiguously identified by the prefix.

  There was a concern whether /28 prefix is sufficient to cover any
  HHIT needs, not only DETs. The main outcomes were:

  o  The IPv6 prefix is for DRIP use and, as such, the requested prefix
      size is reasonable. This block should be named "DRIP Device
      Entity Tags (DETs) Prefix" to avoid any confusion.

  o  Maintain the request for the IANA /28 prefix.

  o  Add a provision for the use of other prefixes, including network-
      specific prefixes.

  o  To unambiguously identify a DET, create a new registry to list
      prefixes used for DET purposes.
   
  Some issues were reported by IANA against -13: add a registration
  procedure for the new EdDSA Curve Label registry, indicate the upper
  boundary for the registry's Value field, etc.

  Sections 3.4.1 and 3.4.2 discuss HIP parameters that are impacted
  as a side effect of defining EdDSA as a HI algorithm.  These
  parameters are not needed for DRIP. The draft includes two notes to
  make this clear enough.

  At least two implementations were reported to the WG, one of them is
  proprietary.

Document Quality:

  The various reviews helped to enhance the quality of the document.

Personnel:

  The document shepherd is Mohamed Boucadair

  The Responsible Area Director is Eric Vyncke

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.

  At least three detailed reviews were made by the Document Shepherd:

  o  -07: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/
      draft-ietf-drip-rid-07-rev%20Med.pdf

  o  -13: https://raw.githubusercontent.com/boucadair/IETF-Drafts-
      Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf

  o  -18: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/
      draft-ietf-drip-rid-18-rev%20Med.pdf

  The authors have taken into account these various reviews.

  This version is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

  No concern.

(5) Do portions of the document need review from a particular or from
    broader perspective.

  No.

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area Director
    and/or the IESG should be aware of?

  No.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed.

  Yes. IPR responses can be seen at:

  * Robert Moskowitz:  https://mailarchive.ietf.org/arch/msg/tm-rid/H9G2SawqP0PtJyQK6LciyBGULgY/

  * Stuart Card:  https://mailarchive.ietf.org/arch/msg/tm-rid/WL2bPmcLpvMOHMfH-OrEN7UII5E/

  * Adam Wiethuechter:  https://mailarchive.ietf.org/arch/msg/tm-rid/9Ut-t3dVDZmEFz6xHSwcSIssYgs/

  * Andrei Gurtov:  https://mailarchive.ietf.org/arch/msg/tm-rid/fmiSIhWgOsmtvIYGmBPHKVBfpyY/

(8) Has an IPR disclosure been filed that references this document?

  No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with
    it?

  The consensus is solid.


(10) Has anyone threatened an appeal or otherwise indicated extreme
      discontent?

  No.

(11) Identify any ID nits the Document Shepherd has found in this
      document.

  Some issues were found and shared with the authors (e.g., citations
  in abstract, self-contained updated).  These were fixed by the
  authors.

  Idnits still displays the following:

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


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
    document.

  == There are 8 instances of lines with non-RFC3849-compliant IPv6 addresses
    in the document.  If these are example addresses, they should be changed.


  ... but all these are false positives:

  o  The first nit is related to the affiliation of one of the co-
      authors.

  o  The second nit is related to '100.hhit.arpa', but that's a valid
      example.

  o  The third nit is related to the IANA IPv6 prefix.


(12) Describe how the document meets any required formal review
      criteria

  No formal language is used.

(13) Have all references within this document been identified as
      either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready
      for advancement or are otherwise in an unclear state? If such
      normative references exist, what is the plan for their
      completion?

  All normative references are published RFCs or publically available
  stable specifications.

(15) Are there downward normative references references (see
      RFC 3967)?

  No.

(16) Will publication of this document change the status of any
      existing RFCs?

  No.

(17) Describe the Document Shepherd's review of the IANA
      considerations section.

  o  The document creates a new registry for DRIP.  It also creates a
      two subregistries under that registry.  The required policy for
      adding new entries is provided for each of these subregistries.

  o  Updates a set of existing registries.  The required the information
      to complete the actions, including where to find the registries, is
      provided.

(18) List any new IANA registries that require Expert Review for
      future allocations.

  "Hierarchical HIT (HHIT) Prefixes".

(19) Describe reviews and automated checks performed by the Document
      Shepherd to validate sections of the document written in a formal
      language.

  N/A

(20) If the document contains a YANG module

  N/A

Shepherd write-up for draft-ietf-drip-rid-20

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
    is this the proper type of RFC? Is this type of RFC indicated in
    the title page header?

  This document requests publication as a Proposed Standard RFC. That
  is indicated on the header page. The intended status is justified
  given that the document (1) specifies a modified version of host
  identity tags (initially defined in RFC 7401 that was published in
  Standards Track) and (2) updates RFC 7343 (also published in the
  Standards Track).

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the
    following sections:

Technical Summary:
   
  This document specifies DRIP Entity Tags (DETs) that are used for
  drone identification purposes (a.k.a., UAS Remote ID). DETs rely
  upon Hierarchical Host Identity Tags (HHITs) which are defined as
  self-asserting IPv6 addresses. Also, these HHITs include explicit
  hierarchy to enable DNS queries and discovery of specific registrars
  for 3rd-party identification attestation purposes.

Working Group Summary:

  This document ran 8 versions before adoption by the WG (including a
  version that passed surprisingly through without any validation and
  published as draft-ietf-drip-uas-rid).

  Regular slots were dedicated to this draft in several WG meetings.
  The authors implemented the outcomes of the discussions held in these
  meetings and the mailing list.

  Once the draft was adopted, a note was sent to HIPSEC mailing
  (https://mailarchive.ietf.org/arch/msg/
  hipsec/2ojLTMCR7-YKQ5RJ68pBABF4mSY/) to check if there are any issues
  with the specification, but no follow up message was received.

  Early SECDIR and IOTDIR reviews were requested by the Chairs against
  -07. These reviews were addressed by the authors.

  As suggested by the SECDIR reviewer, a review request was sent to the
  CFRG for review (31/08/2021). A discussion in the CFRG mailing list
  was then triggered: https://mailarchive.ietf.org/arch/msg/
  cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) with the outcomes
  implemented in -11.

  A note was also sent to SAAG to seek for reviews, especially the
  privacy section (https://mailarchive.ietf.org/arch/msg/
  saag/5tyVqtjCGKVcSeX9gpS4_feI7YQ/). No follow up message was received :-(

  The draft used to include some actions on behalf of the ICAO (RAA
  assignment, for example) while these are not formally discussed by
  the WG. These statements were removed and an action plan was agreed.

  The WG agreed that no RAA assignment policy will be included in this
  document. Such considerations (e.g., whether to abandon the control on
  the RAA assignment bound to the IANA-assigned prefix or keep the full
  control but have a provision for some delegation) will be covered in
  draft-ietf-drip-registries. From an interperiablity, this plan is OK
  as DETs are unambiguously identified by the prefix.

  There was a concern whether /28 prefix is sufficient to cover any
  HHIT needs, not only DETs. The main outcomes were:

  o  The IPv6 prefix is for DRIP use and, as such, the requested prefix
      size is reasonable. This block should be named "DRIP Device
      Entity Tags (DETs) Prefix" to avoid any confusion.

  o  Maintain the request for the IANA /28 prefix.

  o  Add a provision for the use of other prefixes, including network-
      specific prefixes.

  o  To unambiguously identify a DET, create a new registry to list
      prefixes used for DET purposes.
   
  Some issues were reported by IANA against -13: add a registration
  procedure for the new EdDSA Curve Label registry, indicate the upper
  boundary for the registry's Value field, etc.

  Sections 3.4.1 and 3.4.2 discuss HIP parameters that are impacted
  as a side effect of defining EdDSA as a HI algorithm.  These
  parameters are not needed for DRIP. The draft includes two notes to
  make this clear enough.

  At least two implementations were reported to the WG, one of them is
  proprietary.

Document Quality:

  The various reviews helped to enhance the quality of the document.

Personnel:

  The document shepherd is Mohamed Boucadair

  The Responsible Area Director is Eric Vyncke

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.

  At least three detailed reviews were made by the Document Shepherd:

  o  -07: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/
      draft-ietf-drip-rid-07-rev%20Med.pdf

  o  -13: https://raw.githubusercontent.com/boucadair/IETF-Drafts-
      Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf

  o  -18: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/
      draft-ietf-drip-rid-18-rev%20Med.pdf

  The authors have taken into account these various reviews.

  This version is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

  No concern.

(5) Do portions of the document need review from a particular or from
    broader perspective.

  No.

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area Director
    and/or the IESG should be aware of?

  No.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed.

  Yes. IPR responses can be seen at:

  * Robert Moskowitz:  https://mailarchive.ietf.org/arch/msg/tm-rid/H9G2SawqP0PtJyQK6LciyBGULgY/

  * Stuart Card:  https://mailarchive.ietf.org/arch/msg/tm-rid/WL2bPmcLpvMOHMfH-OrEN7UII5E/

  * Adam Wiethuechter:  https://mailarchive.ietf.org/arch/msg/tm-rid/9Ut-t3dVDZmEFz6xHSwcSIssYgs/

  * Andrei Gurtov:  https://mailarchive.ietf.org/arch/msg/tm-rid/fmiSIhWgOsmtvIYGmBPHKVBfpyY/

(8) Has an IPR disclosure been filed that references this document?

  No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with
    it?

  The consensus is solid.


(10) Has anyone threatened an appeal or otherwise indicated extreme
      discontent?

  No.

(11) Identify any ID nits the Document Shepherd has found in this
      document.

  Some issues were found and shared with the authors (e.g., citations
  in abstract, self-contained updated).  These were fixed by the
  authors.

  Idnits still displays the following:

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


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
    document.

  == There are 8 instances of lines with non-RFC3849-compliant IPv6 addresses
    in the document.  If these are example addresses, they should be changed.


  ... but all these are false positives:

  o  The first nit is related to the affiliation of one of the co-
      authors.

  o  The second nit is related to '100.hhit.arpa', but that's a valid
      example.

  o  The third nit is related to the IANA IPv6 prefix.


(12) Describe how the document meets any required formal review
      criteria

  No formal language is used.

(13) Have all references within this document been identified as
      either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready
      for advancement or are otherwise in an unclear state? If such
      normative references exist, what is the plan for their
      completion?

  All normative references are published RFCs or publically available
  stable specifications.

(15) Are there downward normative references references (see
      RFC 3967)?

  No.

(16) Will publication of this document change the status of any
      existing RFCs?

  No.

(17) Describe the Document Shepherd's review of the IANA
      considerations section.

  o  The document creates a new registry for DRIP.  It also creates a
      two subregistries under that registry.  The required policy for
      adding new entries is provided for each of these subregistries.

  o  Updates a set of existing registries.  The required the information
      to complete the actions, including where to find the registries, is
      provided.

(18) List any new IANA registries that require Expert Review for
      future allocations.

  "Hierarchical HIT (HHIT) Prefixes".

(19) Describe reviews and automated checks performed by the Document
      Shepherd to validate sections of the document written in a formal
      language.

  N/A

(20) If the document contains a YANG module

  N/A

Shepherd write-up for draft-ietf-drip-rid-20

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
    is this the proper type of RFC? Is this type of RFC indicated in
    the title page header?

  This document requests publication as a Proposed Standard RFC. That
  is indicated on the header page. The intended status is justified
  given that the document specifies a modified version of host identity
  tags (initially defined in RFC 7401 that was published in Standards
  Track).

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the
    following sections:

Technical Summary:
   
  This document specifies DRIP Entity Tags (DETs) that are used for
  drone identification purposes (a.k.a.  UAS Remote ID).  DETs rely
  upon Hierarchical Host Identity Tags (HHITs) which are defined as
  self-asserting IPv6 addresses.  Also, these HHITs include explicit
  hierarchy to enable DNS queries and discovery of specific registrars
  for 3rd-party identification attestation purposes.

Working Group Summary:

  This document ran 8 versions before adoption by the WG (including a
  version that passed surprisingly through without any validation and
  published as draft-ietf-drip-uas-rid).

  Regular slots were dedicated to this draft in several WG meetings.
  The authors implemented the outcomes of the discussions held in these
  meetings and the mailing list.

  Once the draft was adopted, a note was sent to HIPSEC mailing
  (https://mailarchive.ietf.org/arch/msg/
  hipsec/2ojLTMCR7-YKQ5RJ68pBABF4mSY/) to check if there are any issues
  with the specification, but no follow up message was received.

  Early SECDIR and IOTDIR reviews were requested by the Chairs against
  -07.  These reviews were addressed by the authors.

  As suggested by the SECDIR reviewer, a review request was sent to the
  CFRG for review (31/08/2021).  A discussion in the CFRG mailing list
  was then triggered: https://mailarchive.ietf.org/arch/msg/
  cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) with the outcomes
  implemented in -11.

  A note was also sent to SAAG to seek for reviews, especially the
  privacy section (https://mailarchive.ietf.org/arch/msg/
  saag/5tyVqtjCGKVcSeX9gpS4_feI7YQ/). No follow up message was received :-(

  The draft used to include some actions on behalf of the ICAO (RAA
  assignment, for example) while these are not formally discussed by
  the WG. These statements were removed and an action plan was agreed.

  The WG agreed that no RAA assignment policy will be included in this
  document. Such considerations (e.g., whether to abandon the control on
  the RAA assignment bound to the IANA-assigned prefix or keep the full
  control but have a provision for some delegation) will be covered in
  draft-ietf-drip-registries. From an interperiablity, this plan is OK
  as DETs are unambiguously identified by the prefix part.

  There was a concern whether /28 prefix is sufficient to cover any
  HHIT needs, not only DETs.  The main outcomes were:

  o  The IPv6 prefix is for DRIP use and, as such, the requested prefix
      size is reasonable.  This block should be named "DRIP Device
      Entity Tags (DETs) Prefix" to avoid any confusion.

  o  Maintain the request for the IANA /28 prefix.

  o  Add a provision for the use of other prefixes, including network-
      specific prefixes.

  o  To unambiguously identify a DET, create a new registry to list
      prefixes used for DET purposes.
   
  Some issues were reported by IANA raised issues against -13: a
  registration procedure for the new EdDSA Curve Label registry,
  indicate the upper boundary for the registry's Value field, etc.
  Some of these were fixed (see the IANA section).

  Sections 3.4.1 and 3.4.2 discusses HIP parameters that are impacted
  as a side effect of defining EdDSA as a HI algorithm.  These
  parameters are not needed for DRIP.  The draft includes two notes to
  make this clear enough.

  At least two implementations were reported to the WG, one of them is
  proprietary.

Document Quality:

  The various reviews helped to enhance the quality of the document.

Personnel:

  The document shepherd is Mohamed Boucadair

  The Responsible Area Director is Eric Vyncke

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.

  At least three detailed reviews were made by the Document Shepherd:

  o  -07: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/
      draft-ietf-drip-rid-07-rev%20Med.pdf

  o  -13: https://raw.githubusercontent.com/boucadair/IETF-Drafts-
      Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf

  o  -18: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/
      draft-ietf-drip-rid-18-rev%20Med.pdf

  The authors have taken into account these various reviews.

  This version is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

  No concern.

(5) Do portions of the document need review from a particular or from
    broader perspective.

  No.

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area Director
    and/or the IESG should be aware of?

  No.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed.

  Yes. IPR responses can be seen at:

  * Robert Moskowitz:  https://mailarchive.ietf.org/arch/msg/tm-rid/H9G2SawqP0PtJyQK6LciyBGULgY/

  * Stuart Card:  https://mailarchive.ietf.org/arch/msg/tm-rid/WL2bPmcLpvMOHMfH-OrEN7UII5E/

  * Adam Wiethuechter:  https://mailarchive.ietf.org/arch/msg/tm-rid/9Ut-t3dVDZmEFz6xHSwcSIssYgs/

  * Andrei Gurtov:  https://mailarchive.ietf.org/arch/msg/tm-rid/fmiSIhWgOsmtvIYGmBPHKVBfpyY/

(8) Has an IPR disclosure been filed that references this document?

  No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with
    it?

  The consensus is solid.


(10) Has anyone threatened an appeal or otherwise indicated extreme
      discontent?

  No.

(11) Identify any ID nits the Document Shepherd has found in this
      document.

  Some issues were found and shared with the authors (e.g., citations
  in abstract, self-contained updated).  These were fixed by the
  authors.

  Idnits still display the following:

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


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
    document.

  == There are 8 instances of lines with non-RFC3849-compliant IPv6 addresses
    in the document.  If these are example addresses, they should be changed.


  ... but all these are false positives:

  o  The first nit is related to the affiliation of one of the co-
      authors.

  o  The second nit is related to '100.hhit.arpa', but that's a valid
      example.

  o  The third nit is related to the IANA IPv6 prefix.


(12) Describe how the document meets any required formal review
      criteria

  No formal language is used.

(13) Have all references within this document been identified as
      either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready
      for advancement or are otherwise in an unclear state? If such
      normative references exist, what is the plan for their
      completion?

  All normative references are published RFCs or publically available
  stable specifications.

(15) Are there downward normative references references (see
      RFC 3967)?

  The document has the following:

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-CGA'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-HIP'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-IPSECKEY'

  These references should be moved to be listed as Informative.

(16) Will publication of this document change the status of any
      existing RFCs?

  No.

(17) Describe the Document Shepherd's review of the IANA
      considerations section.

  o  The document creates a new registry (with two subregistries).  The
      policy for adding new entries is not called out in the text to
      echo what is in the cited IANA-HIP registry.

  o  Updates a set of existing registries.  All the information to
      complete the actions, including where to find the registries, are
      provided.


(18) List any new IANA registries that require Expert Review for
      future allocations.

  None.

(19) Describe reviews and automated checks performed by the Document
      Shepherd to validate sections of the document written in a formal
      language.

  N/A

(20) If the document contains a YANG module

  N/A

Some notes:
* A note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was received.
* As suggested by the secdir reviewer, a review request was sent to the cfrg for review (31/08/2021)
* A discussion in the cfrg: https://mailarchive.ietf.org/arch/msg/cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021)
* -11 addresses the review from the cfrg
* IANA raised issues against -13:

From IANA:
"The first, which you may be aware of, is that we'll need a registration procedure for the new EdDSA Curve Label registry. In addition, it would be helpful to us if you could indicate the upper boundary for the registry's Value field (e.g. 15, 255, etc.).

The other issue: can you confirm that the "recommended" and "required" notes in the tables at https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid#section-3.4.2 and https://datatracker.ietf.org/doc/html/rfc7401#section-5.2.10 are neither part of the registry nor directed at IANA (a la "suggested value")?"

* Shepherd Reviews:
- 07: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-drip-rid-07-rev%20Med.pdf
-18 https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-drip-rid-18-rev%20Med.pdf
- 13: https://raw.githubusercontent.com/boucadair/IETF-Drafts-Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf

* IPR Checks
-Bob: https://mailarchive.ietf.org/arch/msg/tm-rid/H9G2SawqP0PtJyQK6LciyBGULgY/
- Stu: https://mailarchive.ietf.org/arch/msg/tm-rid/WL2bPmcLpvMOHMfH-OrEN7UII5E/
- Adam: https://mailarchive.ietf.org/arch/msg/tm-rid/9Ut-t3dVDZmEFz6xHSwcSIssYgs/
- Andrei: https://mailarchive.ietf.org/arch/msg/tm-rid/fmiSIhWgOsmtvIYGmBPHKVBfpyY/

* Implementations:
- Andrei
- Adam

===============
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or informative?

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Some notes:
* A note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was received.
* As suggested by the secdir reviewer, a review request was sent to the cfrg for review (31/08/2021)
* A discussion in the cfrg: https://mailarchive.ietf.org/arch/msg/cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021)
* -11 addresses the review from the cfrg
* IANA raised issues against -13:

From IANA:
"The first, which you may be aware of, is that we'll need a registration procedure for the new EdDSA Curve Label registry. In addition, it would be helpful to us if you could indicate the upper boundary for the registry's Value field (e.g. 15, 255, etc.).

The other issue: can you confirm that the "recommended" and "required" notes in the tables at https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid#section-3.4.2 and https://datatracker.ietf.org/doc/html/rfc7401#section-5.2.10 are neither part of the registry nor directed at IANA (a la "suggested value")?"

* Shepherd Reviews:
- 13: https://raw.githubusercontent.com/boucadair/IETF-Drafts-Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf
- 07: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-drip-rid-07-rev%20Med.pdf

* IPR Checks
-Bob: https://mailarchive.ietf.org/arch/msg/tm-rid/H9G2SawqP0PtJyQK6LciyBGULgY/
- Stu: https://mailarchive.ietf.org/arch/msg/tm-rid/WL2bPmcLpvMOHMfH-OrEN7UII5E/
- Adam: https://mailarchive.ietf.org/arch/msg/tm-rid/9Ut-t3dVDZmEFz6xHSwcSIssYgs/
- Andrei: https://mailarchive.ietf.org/arch/msg/tm-rid/fmiSIhWgOsmtvIYGmBPHKVBfpyY/

* Implementations:
- Andrei
- Adam

===============
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or informative?

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Some notes:
* A note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was received.
* As suggested by the secdir reviewer, a review request was sent to the cfrg for review (31/08/2021)
* A discussion in the cfrg: https://mailarchive.ietf.org/arch/msg/cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021)
* -11 addresses the review from the cfrg
* IANA raised issues against -13:

From IANA:
"The first, which you may be aware of, is that we'll need a registration procedure for the new EdDSA Curve Label registry. In addition, it would be helpful to us if you could indicate the upper boundary for the registry's Value field (e.g. 15, 255, etc.).

The other issue: can you confirm that the "recommended" and "required" notes in the tables at https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid#section-3.4.2 and https://datatracker.ietf.org/doc/html/rfc7401#section-5.2.10 are neither part of the registry nor directed at IANA (a la "suggested value")?"
===============
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or informative?

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Some notes:
* A note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was received.
* As suggested by the secdir reviewer, a review request was sent to the cfrg for review (31/08/2021)
* A discussion in the cfrg: https://mailarchive.ietf.org/arch/msg/cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021)
* -11 addresses the review from the cfrg

===============
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or informative?

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Some notes:
* A note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was received.
* As suggested by the secdir reviewer, a review request was sent to the cfrg for review (31/08/2021)
* A discussion in the cfrg: https://mailarchive.ietf.org/arch/msg/cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021)

===============
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or informative?

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Some notes:
* a note was sent to hipsec mailing to check if there an issue with the spec, but no follow up message was received.
* As suggested by the secdir reviewer, a review request was sent to the cfrg for review (31/08/2021)

===============
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or informative?

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

This draft is related to remote identification of “drones”, that can be seen as “flying IoT” objects. We are looking for feedback related to the proposed solution given the constrained nature of such devices.  Hence the iotdir review request.