Hi Adam, Jim, Adam, thank you for your reply. We have updated the document as described below and posted the files here: https://www.rfc-editor.org/authors/rfc9886.xml https://www.rfc-editor.org/authors/rfc9886.txt https://www.rfc-editor.org/authors/rfc9886.pdf https://www.rfc-editor.org/authors/rfc9886.html
AUTH48 diffs: https://www.rfc-editor.org/authors/rfc9886-auth48diff.html https://www.rfc-editor.org/authors/rfc9886-auth48rfcdiff.html (side by side) Comprehensive diffs: https://www.rfc-editor.org/authors/rfc9886-diff.html https://www.rfc-editor.org/authors/rfc9886-rfcdiff.html (side by side) Note that as part of item 5, we added an informative reference to RFC 8005. In addition, Jim’s input was requested on the following items. We highlight them here for easy access. Please see our notes below. > 11) <!-- [rfced] The text below has been removed as requested. However, > please confirm that the info within the CSV file is not meant to be held in > the IANA registry. > > <t indent="3">The CSV file found for the ISO to RAA mapping > is on <eref > target="https://github.com/ietf-wg-drip/draft-ietf-drip-registries/commit/a8da51bfcafcdf91878f8862c52830aa736782c9";>GitHub</eref>. > RFC Editor, please remove this note after IANA initializes the registry but > before publication.</t> > --> > > <atw> > That was my understanding - any registry value(s) would be added to the > registry as needed when a Nation adopts DRIP and is delegated by IANA. > Jim/Dan/Eric, can you confirm this was what agreed upon? > </atw> RPC: We have not taken any action here. > 13) <!-- [rfced] For clarity, we suggest updating the text as follows. > Please review and let us know if the text may be updated. > > Original: > These components interface the DIME into the DNS hierarchy and thus > operation SHOULD follow best common practices, specifically in > security (such as running DNSSEC) as appropriate except when national > regulations prevent it. > > Perhaps A: > These components interface the DIME with the DNS hierarchy and thus > operation SHOULD follow best common practices, specifically in > security (such as running DNSSEC) as appropriate except when national > regulations prevent it. > > Perhaps B: > These components connect the DIME with the DNS hierarchy and thus > operation SHOULD follow best common practices, specifically in > security (such as running DNSSEC) as appropriate except when national > regulations prevent it. > --> > > <atw> > I am more incline for B rather than A unless Jim has a differing opinion. > </atw> RPC: We have updated to match B - please let us know if any changes are needed. > 17) <!-- [rfced] Please review the "Inclusive Language" portion of the > online Style Guide > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this nature > typically result in more precise language, which is helpful for readers. > > For example, please consider whether the following should be updated: > > master > > Section 5.1.1 (master file): > Note that > the data has internal subfields but these do not appear in the master > file representation; only a single logical base64 string will appear. > > Section 5.2.1 (master file): > Note that > the data has internal subfields but these do not appear in the master > file representation; only a single logical base64 string will appear. > --> > > <atw> > This specific section of text was lifted directly from RFC4398 Section 2.2. > If there is any issue with using what I was understood to be a "term of art" > then please change "master" to "zone". > Jim do you approve of my suggested change? > </atw> RPC: We have updated the text to use “zone” - please let us know if any changes are needed. Please review and let us know if any additional updates are desired or if you approve the RFC for publication. Thank you, Sandy Ginoza RFC Production Center > On Dec 9, 2025, at 5:47 PM, Adam Wiethuechter > <[email protected]> wrote: > > Hello. See inline. > > We would also like to add the following sentence to the existing paragraph of > the "Acknowledgements" section: > > "The authors would also like to thank the DRIP chairs and AD, the reviewers > from the various Directorates, and the members of the IESG at time of > publication." > > -------- > 73, > Adam T. Wiethuechter > Trustworthy Systems Engineer // AX Enterprize, LLC > > From: [email protected] <[email protected]> > Sent: Monday, December 8, 2025 5:53 PM > To: Adam Wiethuechter <[email protected]>; [email protected] > <[email protected]> > Cc: [email protected] <[email protected]>; [email protected] > <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; [email protected] > <[email protected]>; [email protected] > <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9886 <draft-ietf-drip-registries-33> for your > review > Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the source file. > > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. --> > > <atw> > drone, UAS, trustworthy identification, dns, reverse lookup, ipv6, orchid, > public registry > </atw> > > 2) <!-- [rfced] Why is "Authentication" capitalized? Does it perhaps refer > to Authentication Messages or an authentication approach? > > Original: > Cryptographic > (public) keys are used to authenticate anything signed by a DET, such > as in the Authentication defined in [RFC9575] for Broadcast RID. > --> > > <atw> > It refers to "Authentication Messages", please make the correction. > </atw > > 3) <!-- [rfced] We are having trouble parsing this sentence. Is the scope > a) DNS registration of DETs with the DNS delegation of the reverse domain > of the IPv6 prefix and b) RRsets used to handle DETs? Also, is "of IPv6 > Prefix" correct - perhaps it should be "of the IPv6 prefix" or "of IPv6 > prefixes"? Please review. > > Original: > The scope of this document is the DNS registration of DETs with the > DNS delegation of the reverse domain of IPv6 Prefix, assigned by IANA > for DETs 2001:30::/28 and RRsets used to handle DETs. > > Perhaps: > The scope of this document is the DNS registration of DETs with the > DNS delegation of the reverse domain of the IPv6 Prefix (2001:30::/28 > for DETs) and RRsets used to handle DETs. > --> > > <atw> > The suggestion works for me. > </atw> > > 4) <!-- [rfced] "HHIT/DET" is a bit confusing, and it is not used elsewhere > in this document or any RFCs. Because DETs are a specific instance of > HHIT, may we refer to just DET? Note that we deleted "as" from "is as an > IPv6 address" in the suggested text. Please review and let us know how > this text may be clarified. > > Original (prior sentence included for context): > [RFC9374] defines the HHIT and further specifies an instance of them > used for UAS RID called DETs. The HHIT/DET is a 128-bit value that > is as an IPv6 address intended primarily as an identifier rather than > locator. > > Perhaps (note that we made "DETs" singular here): > [RFC9374] defines the HHIT and further specifies an instance of them > used for UAS RID called DET. The DET is a 128-bit value that > is an IPv6 address intended primarily as an identifier rather than > locator. > --> > > <atw> > Your suggestion works for me. > </atw> > > 5) <!-- [rfced] Would it be beneficial to the reader to include a reference > for HIP RRType? Perhaps an informative reference to RFC 8005? > > Original: > The HHIT Resource Record (HHIT, RRType 67) is a metadata record for > various bits of HHIT-specific information that isn't available in the > pre-existing HIP RRType. > --> > > <atw> > Yes, please add a reference to RFC8005 here thanks. > </atw> > > 6) <!-- [rfced] Is the public information static or is the UAS BRID static? > > Original: > The UAS Broadcast RID Resource Record (BRID, RRType 68) is a format > to hold public information typically sent over UAS Broadcast RID that > is static. > --> > > <atw> > The public information is static. > To clarify, the word "public" is redundant as information sent over UAS > Broadcast RID is inherently static. > Removing the word "public" should make the sentence clearer. > </atw> > > 7) <!-- [rfced] You provided this response to our question about whether > there is any text that should be handled cautiously: > > <atw> > The IANA considerations for the prefix and RAA allocations. > </atw> > > Please review the updates closely and let us know if any changes are > needed. In particular, please note that the following text has been > updated based on input from IANA. Please let us know any concerns. > > Original: > The reverse domain for the DET Prefix, i.e., 3.0.0.1.0.0.2.ip6.arpa., > is managed by the IANA following the usual IANA rules. > > Current: > The reverse domain for the DET Prefix, i.e., 3.0.0.1.0.0.2.ip6.arpa., > is managed by the IANA. > --> > > <atw> > I am happy with this. Thank you for checking with us. > </atw> > > 8) <!-- [rfced] Table 1: We see some differences between the Allocation > column and what appears in the IANA registry (for example, the registry > does not mention "ISO 3166-1 Countries"). We believe this is intentional, > but please review and let us know if any change are needed. > > Note that we have removed "N/A" for the Reserved values in the Policy > column to align with the IANA registry. Please let us know any concerns. > > See the DRIP RAA Allocations registry here: > https://www.iana.org/assignments/drip/drip.xhtml#drip-raa > --> > > <atw> > I believe there is no issue here, thank you for checking. > </atw> > > 9) <!-- [rfced] To match the column header in the IANA registry, should > "Policy Reference" be "Reference" here? If this change is acceptable, note > that RAA Registration Form would be updated as well. > > Original: > Policy Reference: A publicly accessible link to the requirements for > prospective HDA operators to register under this RAA. This field > is OPTIONAL. > > Perhaps: > Reference: A publicly accessible link to the requirements for > prospective HDA operators to register under this RAA. This field > is OPTIONAL. > --> > > <atw> > Yes please make the switch; with the additional following change as we do not > want to lose the word policy here as it is important: > > OLD Perhaps: > Reference: A publicly accessible link to the requirements for > prospective HDA operators to register under this RAA. This field > is OPTIONAL. > > NEW Perhaps: > Reference: A publicly accessible link to the policy requirements for > prospective HDA operators to register under this RAA. This field > is OPTIONAL. > </atw> > > 10) <!-- [rfced] For readability, may we update the text as follows? > > Original: > This range is set to IESG Approval (Section 4.10 of [RFC8126]) and > IANA will liaise with the ICAO to verify the authenticity of > delegation requests (using Figure 6) by CAAs. > > Perhaps: > The registration policy for this range is set to IESG Approval > (Section 4.10 of [RFC8126]) and > IANA will liaise with the ICAO to verify the authenticity of > delegation requests (using Figure 6) by CAAs. > --> > > <atw> > Your update is acceptable. > </atw> > > 11) <!-- [rfced] The text below has been removed as requested. However, > please confirm that the info within the CSV file is not meant to be held in > the IANA registry. > > <t indent="3">The CSV file found for the ISO to RAA mapping > is on <eref > target="https://github.com/ietf-wg-drip/draft-ietf-drip-registries/commit/a8da51bfcafcdf91878f8862c52830aa736782c9";>GitHub</eref>. > RFC Editor, please remove this note after IANA initializes the registry but > before publication.</t> > --> > > <atw> > That was my understanding - any registry value(s) would be added to the > registry as needed when a Nation adopts DRIP and is delegated by IANA. > Jim/Dan/Eric, can you confirm this was what agreed upon? > </atw> > > 12) <!-- [rfced] May we update the section title of 6.2.2 to be plural? > Note that we would request that IANA update their registry accordingly. > > Original: > 6.2.2. HHIT Entity Type > > This document requests a new registry for HHIT Entity Type under the > DRIP registry group (https://www.iana.org/assignments/drip). > > Perhaps: > 6.2.2. HHIT Entity Types > > IANA has created a new registry for HHIT Entity Types under the > "Drone Remote ID Protocol" registry group > <https://www.iana.org/assignments/drip>. > --> > > <atw> > Yes this can become plural. > </atw> > > 13) <!-- [rfced] For clarity, we suggest updating the text as follows. > Please review and let us know if the text may be updated. > > Original: > These components interface the DIME into the DNS hierarchy and thus > operation SHOULD follow best common practices, specifically in > security (such as running DNSSEC) as appropriate except when national > regulations prevent it. > > Perhaps A: > These components interface the DIME with the DNS hierarchy and thus > operation SHOULD follow best common practices, specifically in > security (such as running DNSSEC) as appropriate except when national > regulations prevent it. > > Perhaps B: > These components connect the DIME with the DNS hierarchy and thus > operation SHOULD follow best common practices, specifically in > security (such as running DNSSEC) as appropriate except when national > regulations prevent it. > --> > > <atw> > I am more incline for B rather than A unless Jim has a differing opinion. > </atw> > > 14) <!-- [rfced] [ISO-3166-2] Please review. > The URL below goes to a page titled “ISO 3166 > Country Codes”, but this reference appears to be specifically to Part > 1 of ISO 3166 (ISO 3166-1). > We found the following URL for the most up-to-date version of ISO 3166-1 > (ISO 3166-1:2020): https://www.iso.org/standard/72482.html > > Would you like to update this reference to point to the most > up-to-date version of ISO 3166-1? Or would you like this reference to > point to the more general page for ISO 3166? > > Current: > > [ISO3166-1] > ISO, "Codes for the representation of names of countries and their > subdivisions - Part 1: Country code", ISO 3166-1:2020, August 2020, > <https://www.iso.org/iso-3166-country-codes.html>. > > Perhaps: > [ISO-3166] > ISO, "Country Codes", ISO 3166, > <https://www.iso.org/iso-3166-country-codes.html>. > > --> > > <atw> > Please make the switch to the latest only. > I beleive we should keep it specific as we pull explicitly from the 3166-1 > for its numeric variant. > If there is precedence to have a more general link for such cases with ISO I > am willing to defer. > </atw> > > 15) <!-- [rfced] Regarding artwork and sourcecode elements: > > Per Adam's response to the Intake form: > "The only sourcecode in this document is a series of CDDL blocks." > > A) FYI - We updated two artwork elements to sourcecode with the type set to > "cddl": Figures 4 and 5. > > B) We also updated Figures 9 through 21 to sourcecode, but we have left the > type empty (i.e., type="empty"). Please let us know if the type should be > set or if you prefer they be left empty. See the list of known types > available here: > https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types > --> > > <atw> > Thank you. Figures 9-21 are example snippets of DNS zone files - so being > left blank should suffice. > </atw> > > 16) <!-- [rfced] We have the following questions regarding terminology: > > a) Throughout the text, the following terminology appears to be capitalized > inconsistently. Please review these occurrences and let us know if/how they > may be made consistent. > > Apex vs apex > > <atw> > I used "Apex" when an entity is taking on that "role" and "apex" when being > used in a technical context. > </atw> > > b) Please consider whether "Authoritative Name Servers" should be > lowercase. Lowercase is far more common in RFCs. The majority of > uppercase instances are where the phrase is part of a document or section > Title. > --> > > <atw> > If it is standard to have it all lower case then please change it. I was > attempting to emphasize it for readers with unfamiliarity. > </atw> > > 17) <!-- [rfced] Please review the "Inclusive Language" portion of the > online Style Guide > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this nature > typically result in more precise language, which is helpful for readers. > > For example, please consider whether the following should be updated: > > master > > Section 5.1.1 (master file): > Note that > the data has internal subfields but these do not appear in the master > file representation; only a single logical base64 string will appear. > > Section 5.2.1 (master file): > Note that > the data has internal subfields but these do not appear in the master > file representation; only a single logical base64 string will appear. > --> > > <atw> > This specific section of text was lifted directly from RFC4398 Section 2.2. > If there is any issue with using what I was understood to be a "term of art" > then please change "master" to "zone". > Jim do you approve of my suggested change? > </atw> > > > Thank you. > > Sandy Ginoza > RFC Production Center > > > > On Dec 8, 2025, at 2:47 PM, [email protected] wrote: > > *****IMPORTANT***** > > Updated 2025/12/08 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * [email protected] (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * [email protected], which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > [email protected] will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9886.xml > https://www.rfc-editor.org/authors/rfc9886.html > https://www.rfc-editor.org/authors/rfc9886.pdf > https://www.rfc-editor.org/authors/rfc9886.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9886-diff.html > https://www.rfc-editor.org/authors/rfc9886-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9886-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9886 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC 9886 (draft-ietf-drip-registries-33) > > Title : DRIP Entity Tags in the Domain Name System > Author(s) : A. Wiethuechter, Ed., J. Reid > WG Chair(s) : Daniel Migault, Murray Kucherawy > > Area Director(s) : Erik Kline, Éric Vyncke > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
