Hi Elliot, In my previous review, I had asked about how MUD intersects with my zerotouch draft, which has the device reaching out to either a well-known Internet-based or deployment-specific HTTPS resource. But the need to reach out to these HTTPS resources should only be during the device's initial bootstrap process. You said before something about an initial policy followed by an on-going policy, but I don't see that here. Did I miss it?
What is the default behavior of the switch, when no MUD file is available. Section 4 says "Anything not explicitly permitted is denied", but that section discusses the processing of a MUD file, not when there is no MUD file. I'm assuming the goal is for the switch to deny traffic (fail close) when no MUD file can be found, but I worry that this may lead to unhappy operators as new product deployments (not having MUD support) are constantly blocked by the switches... Building upon the above two comments, I'm assuming that the switch could be configured to *always* allow access to some resources, even when no MUD file is found. Is this what you had in mind? Nits: s1.3: "Thing" here is distracting. Can you change to "device"? s1.4: replace "Our work" with something like "The solution"? s1.5: inconsistent capitalization in manufacturer class names s1.6: I see Thing here too. Is this necessary? Isn't the solution for non-IoT devices too? s1.6: you might want to include a ref to RFC 8174, per RFC 8174. s1.7: the text talks about NMSs and websites, but I think you mean controller and mud server, right? s1.8: #7, how is "disconnect" defined? <skimmed a bunch here> regarding s3.4 and s3.7, is it possible to roll 'masa-server' into an extension? Also, note that the brski-07 draft says nothing about this draft, so the relationship between the two is unclear. I'd like to see references to brski removed from this draft if possible, with a preference for the brski draft to define its own "extension" is desired. <skimmed a bunch more here> s17: s/Watson/Watsen/ - an all too common typo in my life! ;) Thanks, Kent _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
