My comments inline,
> On Sep 26, 2017, at 12:37 AM, Eliot Lear <[email protected]> wrote: > > 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. The relevant intersection would be if/how/when MUD deny’s or allows a connection to the netconf zerotouch bootstrap service as described in: https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-17#section-4.4 ? I think the MUD I think the MUD ‘controller’ or ‘my-controller’ mechanism would be used to ensure devices of this class can access the indicated “internet-based” or “deployment-specific HTTPS resource” bootstrap-server? Similarly for anima devices might be limited to only contacting their local BRSKI registrar via ‘my-controller'? Assuming my interpretation is correct I don’t see any change needed in the text about this. >> 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. I think the current text is valid and correct. I vote against any changes in this area: Distribution of the MASA server URL is informative to the local network infrastructure. Support for this mechanisms allows a local network infrastructure to know which MASA service to contact for this device. Allowing this within MUD provides an optimization opportunity for vendors that are anima BRSKI compatible. They can either implement the MASA extension URL, and any other urls, within their initial device identity -or- they can implement only the MUD URL extension. Space and changes to the device identity certificate are limited and difficult so an indirection through the MUD service is a valuable approach. To make this extensible either BRSKI (et all ) needs to extend the yang models much the way it does with the voucher document or there needs to be a MUD specific extension method (iana namespace declared within MUD?) or something. I don’t see how that fits together cleanly and don’t see solving those questions as necessary at this time. - max > >> >> <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 > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
