Hi Michael and Wei, Thank you for your reply. We have updated the document accordingly.
We have a few followup questions/comments: A) Regarding: >> 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. >> --> > > RFC8520 says "These devices, which this memo refers to as Things, have a > specific purpose." > > So while we haven't given an actual definition in RFC8520 like "specific > purpose device" before, I feel like it's a thing. > I don't mind the rewording above, but I don't love it. Thank you for the explanation. Would the following "a device with a specific purpose" be more agreeable? Perhaps: [RFC8520] provides a standardized way to describe how a device with a specific purpose makes use of Internet resources. B) Regarding: >> 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 >> --> > > Yes, that's great, thank you. Please let us know how we can update. The updated files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9726.txt https://www.rfc-editor.org/authors/rfc9726.pdf https://www.rfc-editor.org/authors/rfc9726.html https://www.rfc-editor.org/authors/rfc9726.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9726-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9726-auth48diff.html (AUTH48 changes only) Note that it may be necessary for you to refresh your browser to view the most recent version. For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9726 Thank you, RFC Editor/st > On Mar 21, 2025, at 5:15 AM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > > Hi, Wei and I have coordinated this response! > > In reviewing the diff, I see: > >> 3.1. Non-Deterministic Mappings >> >> Most importantly, the mapping of the DNS names to IP addresses should >> be non-deterministic. > > The original text said "may be non-deterministic". Changing this to should is > confusing, as this is not creating a requirement, but observing how something > might be. If the word "may" does not work, then "could" would be a better > replacement. "should" just doesn't work here. > > === for the rest: > > 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 > --> > > I think that it's accurate to give it a new BCP number. > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. --> > > (DNS) > (MUD) > round-robin > tailored response > DNSSEC > IoT security > Device Identity > > 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. > --> > > Yes. > > > 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. > --> > > RFC8520 says "These devices, which this memo refers to as Things, have a > specific purpose." > > So while we haven't given an actual definition in RFC8520 like "specific > purpose device" before, I feel like it's a thing. > I don't mind the rewording above, but I don't love it. > > > 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. > --> > > I agree that the original is hard to read. > MUD supports IoT devices, so (B) is better. > IoT devices don't really support MUD directly, but rather infrastructure > around them implement MUD. > > I would reword to: > 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 described by 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 ... > --> > > Yes. > > 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. > --> > > Yes. > > 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 ... > --> > > Yes. > Thank you. We forget that D is MUD is "Description" > > 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 > --> > > Yes. > > 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. > --> > > Yes. > > > 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. > --> > > Usually devices get a list of resolvers (via DHCP or RA), so the bug is "use > a" > > Proposed: > Finally, if a device will ever attempt to use non-local resolvers, > then the addresses of those resolvers needs to be listed in the MUD file > as destinations that are 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. > --> > > Yes, thank you. > > 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. > --> > > Yes. > > > 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 > --> > > Yes, that's great, thank you. > > > 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 > --> > > Yes, that's all correct. I would have written: > CPE: Customer Premise Equipment > > but, I'm sure your version is more accurate. > > > 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. > --> > > Done, thank you. > > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- *I*LIKE*TRAINS* > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
