Hi Adam, Thank you for your quick response. We moved the in-text citation for RFC 8005 and reposted the files: 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 difs: https://www.rfc-editor.org/authors/rfc9886-diff.html https://www.rfc-editor.org/authors/rfc9886-rfcdiff.html (side by side) With this update, we believe you approve the RFC for publication and have noted your approval on the AUTH48 page <https://www.rfc-editor.org/auth48/rfc9886>. Thank you, Sandy Ginoza RFC Production Center > On Dec 15, 2025, at 2:20 PM, Adam Wiethuechter > <[email protected]> wrote: > > Hi Sandy, > > Inline. > > -------- > 73, > Adam T. Wiethuechter > Trustworthy Systems Engineer // AX Enterprize, LLC > > From: Sandy Ginoza <[email protected]> > Sent: Monday, December 15, 2025 1:21 PM > To: Adam Wiethuechter <[email protected]> > Cc: RFC Editor <[email protected]>; [email protected] > <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; Daniel Migault > <[email protected]>; Eric Vyncke <[email protected]>; > [email protected] <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9886 <draft-ietf-drip-registries-33> for your > review > [You don't often get email from [email protected]. Learn why this > is important athttps://aka.ms/LearnAboutSenderIdentification ] > > 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. > > <atw> > The reference of RFC 8005 is in the wrong place. Please change as follows. > > OLD: > The HHIT Resource Record (HHIT, RRType 67) [RFC8005] is a metadata > record for various bits of HHIT-specific information that isn't > available in the pre-existing HIP RRType. The HHIT RRType does not > replace the HIP RRType. The primary advantage of the HHIT RRType > over the existing RRType is the mandatory inclusion of the Canonical > Registration Certificate containing an entity's public key signed by > the registrar, or other trust anchor, to confirm registration. > > NEW: > 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 [RFC8005]. The HHIT RRType does > not > replace the HIP RRType. The primary advantage of the HHIT RRType > over the existing RRType is the mandatory inclusion of the Canonical > Registration Certificate containing an entity's public key signed by > the registrar, or other trust anchor, to confirm registration. > </atw> > > 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. > > <atw> > Thank you. > </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> > > RPC: We have updated to match B - please let us know if any changes are > needed. > > <atw> > Looks good to me, thanks. > </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> > > RPC: We have updated the text to use “zone” - please let us know if any > changes are needed. > > <atw> > Thank you. > </atw> > > > 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]
