Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08

[Michael Richardson <[e-mail]>]

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.

[e-mail] 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide