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*
signature.asc
Description: PGP signature
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
