This changes I made based upon your comments are at: https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/pull/12
I've merged it to make/post -10, but if you are further comments and want to
suggest other changes in the github, please go ahead.
mohamed.boucad...@orange.com wrote:
> * I don't think we can leave the ref to the bootstrap I-D as that was
> abandoned since a while. I was delete that citation.
> * Not sure why DoT/DoH is explicitly mentioned in that text. I think
> the reasoning should be more about encrypted DNS in general.
okay, the key point is to use local DNS.
> The ADD WG is currently only focusing on insecure discovery
> mechanisms like DHCP/RA [I-D.ietf-add-dnr] and DNS based discovery
> mechanisms ([I-D.ietf-add-ddr]).
> I would refresh the text as both DNR and DDR are to be published as
> RFCs.
okay: fixed. RPC usually catches that.
They aren't actually RFCs yet (AUTH48 today) :-)
> * Also, not sure it is worth mentioning here given the scope, but
> secure discovery is possible with draft-ietf-ipsecme-add-ike.
No, it's not worth mentioning, because IoT devices are generally, not using
IPsec.
(Generally, because I know of at least one big thing that does use IPsec for
remote maintenance/monitoring. But I would expect a MUD definition to
describe how the IPsec tunnel can work, and if it uses DNS to find the tunnel
end-point, that this would occur before the tunnel is up)
> * Not sure I would maintain "Use of public QuadX resolver" as there are
> public resolvers that are not Quads
RFC8499 hints at "public resolver", under "open resolver", but does not
actually define that term. I'll update to rfc8499bis ID too.
> * "This should include the port numbers (53, 853 for DoT, 443 for
> DoH)": these are default ports numbers. Alternate port numbers can be
> used and thus be configured.
Yes, I'm saying to include the port numbers. Don't assume defaults.
> Aaah, BTW please remove this entry:
> [I-D.peterson-doh-dhcp]
> Peterson, T., "DNS over HTTP resolver announcement Using
> DHCP or Router Advertisements", Work in Progress,
> Internet-Draft, draft-peterson-doh-dhcp-01, 21 October
> 2019, <https://www.ietf.org/archive/id/draft-peterson-doh-
dhcp-01.txt> .
Done.
> and double check the normative references. I'm sure those at least are
not normative:
> [Akamai] "Akamai", 2019,
> <https://en.wikipedia.org/wiki/Akamai_Technologies>.
> [AmazonS3] "Amazon S3", 2019,
> <https://en.wikipedia.org/wiki/Amazon_S3>.
Made informative.
> [I-D.ietf-dnsop-terminology-ter]
> Hoffman, P. E., "Terminology for DNS Transports and
> Location", Work in Progress, Internet-Draft, draft-ietf-
> dnsop-terminology-ter-02, 3 August 2020,
> <https://www.ietf.org/archive/id/draft-ietf-dnsop-
terminology-ter-02.txt> .
RFC8499bis now, and I think it should be normative.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
