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".
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art