On Mon, Aug 22, 2016 at 03:51:09PM -0400, Kathleen Moriarty wrote: > > The underlying I2RS question is how to mark nodes in such a way that the > > insecure transport protocols may be permitted to publish them without > > requiring every single node to be audited if you have relatively weak > > deployment considerations? If the answer is "read the security > > considerations and write a filter", it's not the answer i2rs is looking for. > > I think it's just that it is easier to mark the items that require > confidentiality and integrity protection, when that is clear, rather > than trying to figure out that something is absolutely not in need of > any confidentiality and integrity protections.
I think I2RS has done generally better than that. When not so marked, the intent is secure. >From a syntactic standpoint, it's much nicer to add keywords for the exceptions rather than the default. :-) > In this case, you are > not saying that items don't need security, you are just not taking an > official stance and it's up to the user to turn on or off the default > knob for session transport security. Mostly I'm saying that once you have annotated some data node as being "okay to be insecure", the user can have tools to programmatically act upon that based on information in the model. Lacking that, we're back in SNMP land wherein people have to put in per-object filters to implement this. Note this is "can act". It'd be fine to have your policy be "even if marked insecure, leave secure". It's even fine, IMO (but not as an author of this document), for such "leave secure unless otherwise configured" to be the mandatory to implement default. I'm somewhat curious if you've done such configuration in SNMP. It's a PITA. :-) -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
