On Thu, Jan 19, 2017 at 10:57 AM, Susan Hares <[email protected]> wrote:
> Andy: > > > > This is probably a good idea. Does the NACM apply equally to NETCONF and > RESTCONF? > > > Yes -- well, soon - there is a 6536bis draft to add RESTCONF and YANG 1.1 support to NACM. > Sue > Andy > > > *From:* Andy Bierman [mailto:[email protected]] > *Sent:* Thursday, January 19, 2017 1:56 PM > *To:* Susan Hares > *Cc:* Juergen Schoenwaelder; [email protected]; > [email protected]; Kathleen Moriarty; The IESG; [email protected] > *Subject:* Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > Hi, > > > > I realized that the NACM "default-deny-write" and "default-deny-all" tags > are > > very similar. We are deciding (in the data model) that the data node > > can never be sent without an explicit NACM rule allowing it. > > (I have never heard from a customer that they want this NACM rule ignored). > > We do not abuse these NACM tags. They are rarely used. > > I think the same will be true for the I2RS extension. > > > > > > Andy > > > > > > On Thu, Jan 19, 2017 at 10:47 AM, Susan Hares <[email protected]> wrote: > > Andy: > > > > You are right to comment that – the “flip side of this extensions is that > any node not properly tagged must not be SENT”. The purpose of tagging is > devices which test protocol conformation can test these portions of the > model. If buyers demand that these restrictions are followed, then these > restrictions will not be ignored. Like you and Juergen, I really hope that > the IESG will very carefully evaluate any I2RS YANG Model that suggest > sending data over non-secure transport. > > > > Sue Hares > > > > *From:* Andy Bierman [mailto:[email protected]] > *Sent:* Thursday, January 19, 2017 1:31 PM > *To:* Susan Hares > *Cc:* Juergen Schoenwaelder; [email protected]; > [email protected]; Kathleen Moriarty; The IESG; [email protected] > *Subject:* Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > Hi, > > > > I strongly agree with Juergen on this issue. > > But you can easily design a YANG extension that indicates a data node > > is OK for insecure transport. > > > > I trust that the IESG will evaluate every object of this type and > > decide whether it is really OK for disclosure in every possible > > usage scenario. > > > > The flip-side of this extension is that any node not properly tagged > > MUST NOT be sent without the proper security protocols. > > This rule will likely be ignored, since (as Juergen pointed out) > > this is a deployment decision, not a modeling decision. > > > > > > Andy > > > > > > On Thu, Jan 19, 2017 at 10:15 AM, Susan Hares <[email protected]> wrote: > > Juergen: > > I recognize that dislike insecure communication. You made a similar > comment > during the WG LC and IETF review of > draft-ietf-i2rs-protocol-security-requirements. However, the > draft-ietf-i2rs-protocol-security-requirements were passed by the I2RS WG > and approved by the IESG for RFC publication and it contains the non-secure > communication. The mandate from the I2RS WG for this shepherd/co-chair is > clear. > > As the shepherd for the topology drafts, I try to write-up something that > might address Kathleen's Moriarty's concerns about the topology draft's > security issues about privacy and the I2RS ephemeral control plane data > store. I welcome an open discussion on my ideas > (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). > The > yang doctor's YANG security consideration template > (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and the > privacy related RFCs (RFC6973) note that some information is sensitive. > Hopefully, this document extends these guidelines to a new data store. > > Cheerily, > Sue Hares > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:[email protected]] > Sent: Thursday, January 19, 2017 10:34 AM > To: Susan Hares > Cc: 'Kathleen Moriarty'; 'The IESG'; > [email protected]; [email protected]; > [email protected] > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > For what it is worth, I find the notion that data models may be written for > a specific non-secure transport plain broken. There is hardly any content > of > a data model I can think of which is generally suitable for insecure > transports. > > Can we please kill this idea of _standardizing_ information that is > suitable > to send over non-secure transports? I really do not see how the IETF can > make a claim that a given piece of information is never worth protecting (= > suitable for non-secure transports). > > Note that I am fine if in a certain trusted tightly-coupled deployment > information is shipped in whatever way but this is then a property of the > _deployment_ and not a property of the _information_. > > /js > > On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > > Kathleen: > > > > I have written a draft suggesting a template for the I2RS YANG modules > which are designed to exist in the I2RS Ephemeral Control Plane data store > (configuration and operational state). > > > > Draft location: > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/ > > > > I would appreciate an email discussion with the security ADs, OPS/NM ADs, > and Routing AD (Alia Atlas). I agree that this I2RS YANG data model (L3) > and the base I2RS topology model should both provide updated YANG Security > Considerations sections. I would appreciate if Benoit or you hold a discuss > until we sort out these issues. > > > > Thank you, > > > > Sue > > > > -----Original Message----- > > From: Kathleen Moriarty [mailto:[email protected]] > > Sent: Wednesday, January 18, 2017 9:44 PM > > To: The IESG > > Cc: [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected] > > Subject: Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > Kathleen Moriarty has entered the following ballot position for > > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut > > this introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I agree with Alissa's comment that the YANG module security consideration > section guidelines need to be followed and this shouldn't go forward until > that is corrected. I'm told it will be, thanks. > > > > > > > > _______________________________________________ > > i2rs mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/i2rs > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > > > > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
