[Gen-art] Gen-ART Early Review of draft-ietf-opsawg-mud-iot-dns-considerations-02

[Paul Kyzivat <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at <​ 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-opsawg-mud-iot-dns-considerations-02
Reviewer: Paul Kyzivat
Review Date: 2021-12-18
IETF LC End Date: ?
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.

General Thoughts:

I struggled in choosing a Summary statement. I'm caught between:

* This draft is on the right track but has open issues, described in the 
review.

* This draft has serious issues, described in the review, and needs to 
be rethought.

I don't feel qualified to make that call, so I've gone with the more 
positive choice.

One reason for by ambivalence is that I'm uncertain if the things 
recommended in this document are *good enough* to be described as BCPs. 
I would hope that following BCPs would give high probability of 
successful deployment. I'm not convinced of that.

The real question may be whether the MUD approach can work for all the 
types of deployment that IoT manufacturers might want to use? And if so 
whether RFC8520 together with some BCPs is sufficient to accomplish that?

Issues:

Major: 3
Minor: 2
Nits:  3

1) MAJOR: Section 3: Probabilistic results

Several if the strategies in this section appear to be probabilistic in 
nature. E.g.,

    ... the list may have
    changed between the time that the MUD controller did the lookup and
    the time that the IoT device does the lookup ...
    In order to compensate for this, the MUD controller SHOULD regularly
    do DNS lookups.

Even with regular lookups the IoT devices could experience intermittent 
failures. IMO the document needs to explore this issue. Is it good 
enough if it sometimes fails when the list changes? Should the device do 
something to mitigate the issue?

2) MAJOR: Section 3: Installation Specific Mechanisms

I'm bothered by the statement: "In this case, additional installation 
specific mechanisms are probably needed to get the right view of DNS." 
Isn't this just hand waving? (I.e. you can't currently imagine a 
solution?) "Installation specific" is particularly troubling, since its 
hard to imagine what an operator doing the installation would be capable 
of doing.

I think you need to dig deeply into this, or else somehow scope the 
problem to exclude it.

3) MAJOR: Section 6: Recommendations

While following these recommendations may be helpful in achieving 
workable deployments involving MUD it seems unlikely that all 
manufacturers of IoT devices would be able to comply with them all. 
(E.g., Do not use geofenced names.) What are manufacturers who can't 
comply to do?

4) MINOR: Section 3: Strategies to map names

The statement: "This is not a successful strategy, and do not use it." 
seems to be out of place here. Shouldn't this be in section 6?

5) MINOR: Section 4: Anti-Patterns

It isn't clear what you want done with these. I presume you want to tell 
device manufacturers to stop doing these things. If so, then I suggest 
you add BCPs recommending what manufacturers should do instead.

6) NIT: XXX

The document uses "XXX --" in several places. I'm assuming the intent is 
to expand these in a future version.

7) NIT: Section 1: Section cross references

This section refers to "The first section ... The second section ... The 
third section ... The fourth section ...". However the section numbers 
of the appropriate sections are 3,4,5,6. You need to switch to referring 
to sections by numbers that are specified by xrefs.

8) NIT: Section 1: "DNS Presolution"

Is the use of "DNS presolution" intentional, or did you mean "DNS 
resolution"? While "presolution" is a word, I don't find any meaning for 
"DNS presolution".