[Drip] Re: Mike Bishop's Discuss on draft-ietf-drip-registries-29: (with DISCUSS and COMMENT)

[Mike Bishop <[e-mail]>]

Mostly. I was expecting https://github.com/ietf-wg-drip/draft-ietf-drip-registries/blob/a8da51bfcafcdf91878f8862c52830aa736782c9/iso3166-raa.csv, but -30 uses https://github.com/ietf-wg-drip/draft-ietf-drip-registries/commit/a8da51bfcafcdf91878f8862c52830aa736782c9 instead. Probably close enough; I'll clear my DISCUSS after I see a thumbs-up from IANA.

Thank you!

________________________________
From: Eric Vyncke (evyncke) <[e-mail]>
Sent: Thursday, June 5, 2025 9:47 AM
To: Mike Bishop <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [Drip] Mike Bishop's Discuss on draft-ietf-drip-registries-29: (with DISCUSS and COMMENT)


Hello Mike,



Does -30 address your issue about “the mapping between ISO 3166-1 Numeric Nation Codes and RAAs is specified as a CSV file..” as there is a specific commit version in section 6.2.1 ?



You may have seen IANA replies on a separate thread on this topic.



Regards



-éric





From: Mike Bishop via Datatracker <[e-mail]>
Date: Tuesday, 3 June 2025 at 17:36
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [Drip] Mike Bishop's Discuss on draft-ietf-drip-registries-29: (with DISCUSS and COMMENT)

Mike Bishop has entered the following ballot position for
draft-ietf-drip-registries-29: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-drip-registries/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The mapping between ISO 3166-1 Numeric Nation Codes and RAAs is specified as a
CSV file on the main branch of a GitHub repo. This seems problematic in two
ways:

- First, it is not an archival resource; future commits to the GitHub repo
could modify it without notice. At the very least, this should link to the
version of the file in a specific commit so that it cannot change without
modifying the link in the document.

- Second, the link does not appear in the document's references and probably
should.

I'm sympathetic to the desire not to add a 4k row table in an appendix. Have
you collaborated with IANA on the best way for them to receive the initial
values of this registry?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I second Gunter's observation that this document does not cater to new readers.
The term DRIP is not introduced in the document, and RFC9153/RFC9434 is not
clearly associated to this acronym to help anyone figure it out. There are
several unfamiliar abbreviations just in Figure 1, which should be setting the
framework for understanding the rest of the document. (GCS, AAA, etc.) While I
appreciate the pointer to RFCs 9153, 9374, and 9434 for terminology, a list of
the terms being imported from them would be useful to help readers look up
terminology as needed. A brief explanation of what DRIP is and what role this
document's work plays in that would go a long way.

Related, I don't see a definition or reference for the term "nibble
revers(ed|ing)" beyond "convention". You already have the STD88 reference,
which uses similar language; I'd just point to it where appropriate. (From
STD88, "The sequence of nibbles is encoded in reverse order, i.e. the low-order
nibble is encoded first, followed by the next low-order nibble and so on. Each
nibble is represented by a hexadecimal digit.")

The "Canonical Registration Certificate" is mentioned as a field in the HHIT
RRType without further context about what this is or how it is used. Please
provide references inline as appropriate.

In Section 5.2, I was not able to parse the phrase "public information
typically sent of the UAS Broadcast RID that is static". Is there a missing or
substituted word here? If not, is there a different word order that would be
easier to understand?

In Section 6.1, the DE's authority is confusing to me in two ways. First, if
the DE is "expected to process these delegation requests on a first-come,
first-served basis," what need is there for the DE? Just permit IANA to
allocate this space directly. Second, what does it mean that "[t]he DE will
have the discretion to perform minimal technical checks" if the DE "[can]not
enforce these"? Again, performing unenforceable checks could be done by any
member of the public and doesn't require a DE.

I note that the raft of DNS BCPs and RFCs to which security guidance is
delegated are all informational. This may be correct, as this is guidance
rather than a compatibility requirement, but please double-check that you don't
intend any of these to be normative.

===NITS FOLLOW===

Abstract, "DRIP specific" => "DRIP-specific"

Section 4, "UAS specific" => "UAS-specific"

Section 5.1, "HHIT specific" => "HHIT-specific"

Section 6.1, "ie" => "i.e."

Section 7.1, "following RFC" => "following RFCs" (or just drop it entirely,
e.g. "[RFC7720], ...., and [RFC3007] provide suitable guidance.")



--
Tm-rid mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]