Hi Kent,
On 9/26/17 10:17 PM, Kent Watsen wrote: > I'm not disputing the value of being able to relay such information (though > it's missing in the brski draft), I'm just thinking that rather than hardcode > something into the base MUD file description, that the same can be done using > the extension mechanism that this draft is defining instead. Same data, just > declared differently. If there is a claim that it is too hard, then I'd > recommend spending more time examining the extension mechanism now rather > than after this becomes an RFC. > > That said, maybe we should challenge the necessity of this field, or at least > examine to what end this idea is valid. First, just to throw it out there, > why not also add a "zerotouch-server" field? I'm guessing that this field > enables lazy-binding so, rather than a device hardcoding such info, it be > determined operationally. Other resources apply too, right? Sometimes > devices need to reach out to well-known resources for e.g., anti-x signature > packs. Would the location for these resources also be map-able via a MUD > file? Note that I'm not actually advocating for any of this at the moment, > just trying to understand what's intended here. > > As I mentioned in an earlier message, I'm inclined to want to remove rather than add, and I think it's a reasonable suggestion to remove the masa-server to an extension that can then be discussed in the ANIMA WG. It may interest you to know the reasoning for it being there in the first place: initially there was no way in the BRSKI draft to find the masa server, and this seemed like a simple solution. Now that they have solved for that separately, I do like the idea of the server being listed in the MUD file, but as an extension, for the simple reason that the manufacturer can keep certificates small by listing this in the MUD file. I invite you to do the same for a zerotouch-server. Thanks for calling this out. Eliot
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
