Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
1) <!--[rfced] This document has been assigned a new BCP number. Please let us know if this is not correct (i.e., it should be part of an existing BCP). See the complete list of BCPs here: https://www.rfc-editor.org/bcps --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 3) <!--[rfced] FYI, this sentence has been updated as follows for clarity. Please review whether these terms convey the same meaning: "Manufacturer Usage Description (MUD) definitions" replaced with "Manufacturer Usage Descriptions (MUDs)" (plural). We note the plural is used in the abstract of RFC 8520. Original: These concerns become acute as network operators begin deploying RFC 8520 Manufacturer Usage Description (MUD) definitions to control device access. Current: These concerns become acute as network operators begin deploying Manufacturer Usage Descriptions (MUDs), as specified in RFC 8520, to control device access. --> 4) <!--[rfced] Please clarify "a specific purpose device". This term has not been used in past documents; perhaps it is in contrast to "a general-purpose device", a term used in RFC 8520. May it be rephrased as below, or does it mean the same as "a single-purpose device"? Original: [RFC8520] provides a standardized way to describe how a specific purpose device makes use of Internet resources. Perhaps: [RFC8520] provides a standardized way to describe how a device for a specific purpose makes use of Internet resources. --> 5) <!--[rfced] Please clarify "with MUD supporting IoT devices". Does it mean (A) "with IoT devices that support MUD" or (B) "with MUD to support IoT devices" or otherwise? Original: The core of this document, is Section 6, which makes a series of recommendations ("best current practices") for manufacturers on how to use DNS and IP addresses with MUD supporting IoT devices. Perhaps (if A): The core of this document is Section 6, which makes a series of recommendations ("best current practices") for manufacturers on how to use DNS and IP addresses with IoT devices that support MUD. --> 6) <!--[rfced] May this be rephrased for simplicity? Original: The simplest successful strategy for translating DNS names for a MUD controller to take is to do a DNS lookup on the name ... Perhaps: The simplest successful strategy for a MUD controller to translate DNS names is to do a DNS lookup on the name ... --> 7) <!--[rfced] Please review; does the updated sentence convey the intended meaning? It has been rephrased to avoid the use of two "but" phrases in a row. (Also, "literate" was changed to "literal".) Original: An update server might believe that if the connection was on IPv4, that an IPv4 literate would be acceptable, but due to NAT64 [RFC6146] a device with only IPv6 connectivity will often be able to reach an IPv4 firmware update server by name (through DNS64 [RFC6147]), but not be able to reach arbitrary IPv4 address. Current: An update server might believe that if the connection were on IPv4, then an IPv4 literal would be acceptable. However, due to NAT64 [RFC6146], a device with only IPv6 connectivity will often be able to reach an IPv4 firmware update server by name (through DNS64 [RFC6147]) but not be able to reach an arbitrary IPv4 address. --> 8) <!--[rfced] May we change "A MUD file definition" to simply "A MUD file"? We see zero usage of "MUD file definition" in RFC 8520 or other RFCs. Original: A MUD file definition for this access would need to resolve ... Original: A MUD file for this access would need to resolve ... --> 9) <!--[rfced] Should "CDN vendor's DNS" be "CDN provider's DNS" here, because that phrase is used earlier within this section? (Note: The apostrophe was added because it seems possessive was intended.) Original: the CDN vendors DNS will do all the appropriate work Current: the CDN vendor's DNS will do all the appropriate work Perhaps: the CDN provider's DNS will do all the appropriate work --> 10) <!--[rfced] May "now" be removed from these two sentences, or do you want to use a different phrase? (The preceding sentence is included for context.) Original: There are currently tools that help with the definition and analysis of MUD files, see [mudmaker]. The remaining difficulty is now the actual list of expected connections to put in the MUD file. An IoT manufacturer must now spend some time reviewing the network communications by their device. Perhaps (if removing two instances of "now"): There are currently tools that help with the definition and analysis of MUD files; see [mudmaker]. The remaining difficulty is the actual list of expected connections to put in the MUD file. An IoT manufacturer must spend some time reviewing the network communications by their device. --> 11) <!--[rfced] FYI, this sentence has been updated to use singular "resolver" and "destination". Please let us know if that was not the intention. Original: Finally, if a device will ever attempt to use a non-local resolvers, then the address of that resolver needs to be listed in the MUD file as destinations that are to be permitted. Current: Finally, if a device will ever attempt to use a non-local resolver, then the address of that resolver needs to be listed in the MUD file as a destination that is to be permitted. --> 12) <!-- [rfced] FYI, for the references to Wikipedia pages - [AmazonS3], [Akamai] [boywhocriedwolf] - we have updated the data to the most current revision and updated the URL to the date-specific URL. Please let us know if you prefer otherwise. --> 13) <!--[rfced] Please clarify "the Editors' copy of internet drafts". What is this referring to? If this is referring to I-Ds created using the i-d template build system, then perhaps "including the Editors' copies of some Internet-Drafts that are stored on GitHub". Original: For instance, github.io, which is used for hosted content, including the Editors' copy of internet drafts stored on github, does not actually publish any DNS names. Current: For instance, github.io, which is used for hosted content, including the Editors' copy of Internet-Drafts stored on GitHub, does not actually publish any DNS names. --> 14) <!-- [rfced] We see some inconsistencies with the following terms. Please review and let us know if any updates are needed. edns-client-subnet (ECS) EDNS0 option edns-client-subnet option edns-client-server EDNS0 --> 15) <!-- [rfced] FYI - we added expansions to the following acronyms. Please verify that these are correct. DNS-SD: DNS-based Service Discovery mDNS: Multicast DNS CPE: Customer Premises Equipment --> 16) <!-- [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. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> Thank you. RFC Editor/st/ar On Mar 20, 2025, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2025/03/19 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 * rfc-edi...@rfc-editor.org (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). * auth48archive@rfc-editor.org, 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, auth48archive@rfc-editor.org 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/rfc9726.xml https://www.rfc-editor.org/authors/rfc9726.html https://www.rfc-editor.org/authors/rfc9726.pdf https://www.rfc-editor.org/authors/rfc9726.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9726-diff.html https://www.rfc-editor.org/authors/rfc9726-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9726-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9726 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9726 (draft-ietf-opsawg-mud-iot-dns-considerations-19) Title : Operational Considerations for Use of DNS in Internet of Things (IoT) Devices Author(s) : M. Richardson, W. Pan WG Chair(s) : Henk Birkholz, Joe Clarke Area Director(s) : Mahesh Jethanandani, Mohamed Boucadair -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
