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. --> 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. --> 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. --> 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. --> 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. --> 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. --> 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. --> 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 --> 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. --> 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. --> 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> --> 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>. --> 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. --> 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>. --> 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 --> 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 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. --> 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. --> 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]
