[OPSAWG] ietf-opsawg-mud-iot-dns-considerations-02 -- comments from IETF111 meeting

[Michael Richardson <[e-mail]>]

Michael Richardson <[e-mail]> wrote:
    > On 2021-07-11 8:21 p.m., [e-mail] wrote:
    >>
    >> A New Internet-Draft is available from the on-line Internet-Drafts
    >> directories.  This draft is a work item of the Operations and
    >> Management Area Working Group WG of the IETF.
    >>
    >> Title : Operational Considerations for use of DNS in IoT devices
    >> Authors : Michael Richardson Wei Pan


    > Hi, I was reviewing this document to determine what, if any, update I
    > needed to make before today's ID deadline.  We talked about this
    > document at IETF111, my presentation is at:
    > https://datatracker.ietf.org/meeting/111/materials/slides-111-opsawg-operational-considerations-for-use-of-dns-in-iot-devices-00

    > The video for this document from IETF111 is at:
    > https://youtu.be/wKHtWF- CdxY?t=4407

...
    > My recommendation is that we simply advise that manufacturers just
    > shouldn't do geofenced things in MUD files.  There is has been no
    > discussion, but also no discussion about this.  I would appreciate
    > someone to disagree with me here.

Eliot's push back was that somehow the local MUD controller environment
needs to fix this.  I went back again to the video and listened to Eliot's
words:

1) DNSOP may not like some of the things that actually get done to deal with
this.

2) One of the things that get done is that queries can be intercepted in the
   network, and then one deals with the response, and record that.

3) one manages things ... be conservative about cache time outs.

4) What's important for the client (the device), is that if the connection
   breaks then they retry the query, and not just the attempt to the same
   address.

5) the other issue (discussed on list), if there is more complete integration
   between the nameserver and the access control function in the network,
   then this issue is obviated.

MCR: all of this is good suggestion, breaks for DNS over HTTPS.
     Once of the advice is that they really shouldn't do that.

Eliot agrees with this point.

I think that in the document posted that it says this already.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide