Hi Kent, I'll respond in two messages (I need to get more info in one case).
On 9/26/17 2:57 AM, Kent Watsen wrote: > 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? I think so. There is the notion of “cache-validity” with the idea being that one can change the policy from time to time. The policy does not itself expire, but the idea with “cache-validity” is that mud controllers shouldn't pester the mud file server any sooner than that period. > 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... Fair question. If no MUD file is available, it's a deployment decision as to how to proceed (much as it is today). The intent of Section 4 is that one should assume that the end of an ACL is the JSON equivalent of "deny any". Should I clarify this? > > > 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? Yes. I can clarify this as well. > > > Nits: I'll check each of these, but the term "Thing" is intended to be used consistently, and changes made were in response to Robert Sparks' review. I'll make sure that each is as intended. > 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. I am tempted to agree. This is the one that may need just a day or two to consider, perhaps with a conversation with Max and the ANIMA folk. > > <skimmed a bunch more here> > > s17: s/Watson/Watsen/ - an all too common typo in my life! ;) > Deepest apologies. I know how you feel. Eliot
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
