Reviewer: Robert Sparks Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-opsawg-mud-20 Reviewer: Robert Sparks Review Date: 2018-04-09 IETF LC End Date: 2017-11-07 IESG Telechat date: 2018-04-19 Summary: Almost ready but with minor issues to address before publication as a standards track RFC Minor issues: Section 3.15 is confused, and I don't think you'll get the implementation you intend with the MUST in the current language. direction-indicated is not a flag. The text about dropping should talk about matching the direction that was indicated. The quoted issues below are from my early review of -08. I don't think they've been addressed or responded to. Apologies if I missed a response. > The document proposes "reputation services". It needs more words about > whether those exist, and what scopes the architecture imagines (an > enterprise might have a different idea of a reputation service than a > residence). There is a notion of "decent web reputations" in the security > considerations section. Who determines that? The security considerations > section should talk about attacks against the reputation services. > I think there needs to be more discussion of the PKI used for signing MUD > files. > Consider discussing whether the stacks used by typical things will let > them add DHCP options (or include bits in the other protocols being > enabled). If it's well known (I can't say) that these stacks typically > _won't_ provide that functionality, then you should punch up the > discussion of the controllers mapping other identifiers to MUD URLs on > behalf of the thing. > You suggest the DHCP Client (which is a thing) SHOULD log or report > improper acknowledgments from servers. That's asking a bit much from > a thing. I suspect the requirement is unrealistic and should be removed > or rewritten to acknowledge that things typically won't do that. > The security and deployment considerations sections talk about what the > need for coordination if control over the domain name used in the URL > changes. It should talk more about what happens if the new administration > of the domain is not interested in facilitating a transition (consider > the case of a young company with a few thousand start-up-ish things out > there that loses a suit over its name). Please discuss whether or not > suddenly losing the MUD assisted network configuration is expected to > leave the devices effectively cut-off. > Right now, you leave the DHCP server (when it's used) responsible for > clearing state in the MUD controller. Please discuss what happens when > those are distinct elements (as you have in the end of section 9.2) and > the DHCP server reboots. Perhaps it would make sense for the DHCP server > to hand the length of the lease it has granted to the MUD controller and > let the MUD controller clean up on its own? Nits: There is tension between the paragraph in the introduction that characterizes the manufacturer as the entity that provides the mud file and the third bullet in the intent list about speeding vulnerability resolution for devices that are no longer supported by the manufacturer (you intend here that someone other than the original manufacturer or integrator is providing a new mud file). Instead of "A light bulb is intended to light a room.", I suggest "A light bulb is intended to light a given space." (There are lightbulbs meant for outdoor use, and others for only inside cabinets or appliances.) Instead of "We make use of YANG because of the time and effort spent to develop accurate..." I suggest "We make use of YANG because it provides accurate..." At the end of section 1.7, instead of "For these reasons only a limited subset YANG-based configuration is permitted in a MUD file.", I suggest "For these reasons, the YANG-based configuration in a MUD file is limited to the YANG modules defined in this document." or something similar. In section 3.6, the parenthesized clause does not belong in the sentence in which it currently appears. I suggest it belongs somewhere in the previous sentence. In section 3.13 you talk about classes that are standardized. Where does someone find out about standardized classes? Micro-nits: "Our work begins with" in section 1.5 is awkward and I suspect will cause problems if this document is translated into other languages. At "======= The MUD URL identifies" in section 5, I suggest deleting the = signs. Please provide a reference or better description for "so-called east-west infection"" The string "enorcement" appears a couple of times in the models. It is intended to be "enforcement".
