{sorry, this email is the result of several interrupted editing sessions, and
might be more rambly than I'd like. -14 just posted, but more small changes
described in this email}Murray Kucherawy via Datatracker <[email protected]> wrote: > I understand why this is seeking BCP status, but I think it's unusual for > something claiming to be "Considerations" to seek that status. I think this is > more suited to Informational. Hi, I am open to changes that align the title more with the intended status. I looked through rfc-index, and you are right: documents with the word Considerations in the title (which are not referring to "Security Considerations" or "IANA Considerations") are informational. My title is "Operational Considerations" RFC9098: Operational Implications of IPv6 Packets with Extension Headers (Info) RFC9099: Operational Security Considerations for IPv6 Networks (Info) RFC8906: A Common Operational Problem in DNS Servers: Failure to Communicate. (BCP) RFC8207: BGPsec Operational Considerations. (BCP) RFC8206: BGPsec Considerations for Autonomous System (AS) Migration. (standard) Informational drafts usually don't use BCP14 keywords, but they can. To me, this is about communicating a practice, and so BCP makes sense. > Please expand "ECH" on first use. fixed: } In TLS 1.3 {{?RFC8446}}, with or without the use of Encrypted Client Hello } (ECH) {{?I-D.ietf-tls-esn > If Section 3.1 describes a "failing strategy", why is it only NOT RECOMMENDED? NOT RECOMMENDED == SHOULD NOT, and you feel I ought to write MUST NOT? I can write "MUST NOT". > In Section 3.2, what is a "physical ACL"? That's a good question. I guess that I am distinguishing between the high-level policy objection ("Permit port 80 traffic to example.com") from the thing placed into the hardware, ("permit tcp port 80 traffic to {93.184.216.34,2606:2800:220:1:248:1893:25c8:1946} and allow return traffic") I will change the word to "actual". Does that work for you? > Also, Section 3.2 seems to use a lot of space describing the benefits of DNS > caching, TTLs, etc. Someone with a moderate understanding of DNS would already > get all of this. I think it could use some editing down. If the manufacturers of the IoT devices had a moderate understanding of DNS, would they even be reading this document? However, I see that I have SHOULD's in a section of the document which is intended to just be illustrative. I have edited those out. The reason the successful strategy is detailed is because there there are still corner cases where it can fail even if the MUD controller does everything right. Those corner cases are under the control of the IoT device manufacturer. > Section 4.1: I think "inprotocol" should be "in-protocol", although I > don't know if that's a word either. I would use neither; it's fine > without. I have rewritten this section: https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/commit/248ee9d3e23687a5fb2479e2276c3adf8f2443c8 This is also in answer to Dave Thaler's review. > Also in Section 4.1, the final paragraph (or at least its first sentence) seems > a bit mangled. > The title of Section 6.1 doesn't appear (to me) to match what it says. > For Section 6.4, can we define "geofenced" or provide a reference? This is the > first time that term is used in this document. I've changed this to "tailored names" as that's what rfc7871 says they are. > For a BCP, Section 6.5 feels mushy. It says the best practice is (thing), but > then buffers it with SHOULDs. I think you should say what the best practice is > and stop. If someone elects to deviate, then they're not doing what the best > practice is. I see your point. The core point is the first line: IoT Devices SHOULD prefer doing DNS with the DHCP provided DNS servers, or DNS servers learnt from Router Advertisements {{?RFC8106}}. and I'm struggling to rewrite that without SHOULD (or should). Maybe: The best practice is for IoT Devices to do DNS with the DHCP provided DNS servers, or DNS servers learnt from Router Advertisements {{?RFC8106}}. https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/commit/fe4b85702897c82d71e8abdc678f58234f511c95 > === > From Orie Steele, incoming ART Area Director: > In 4.2. Use of non-deterministic DNS names in-protocol >> Within that control protocol references are made to additional content at >> other URLs. The values of those URLs do not fit any easily described pattern >> and may point at arbitrary names. > Seems to rely on RFC9238 to define what constitutes a well formed URL, which in > turn references RFC3986 > https://www.rfc-editor.org/rfc/rfc3986#section-7.1 Orie, I think you are mis-understanding. Of course it ought to be a valid URL (or component of one). The issue is that the actual content may be unknown at device manufacturer/MUD-file update time. For instance, facebook images come from places like: https://scontent.fykz2-1.fna.fbcdn.net and I doubt that the "fykz2-1" is constant, or in anyway predictable enough to put into a MUD file. (nice that it has "face:b00c" in the v6 though) Maybe, all of the fbcdn.net fits into a single /64. Well. In this case I see these IPs are from Telus where FB has a CDN node, likely because I'm tethered to my Telus SIM phone right now. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
