Hello, My plan is to re-read the posted draft, but if you plan to include Stephen's updates as well, I can wait to review that. I'll have to read the text to see where we are at as there have been a lot of messages on this thread and updates from other related AD comments/disucusses. I'm still concerned about a few things, but will see if that matters in the text.
I believe I responded on the heading for the mutual authentication suggesting that it should really be identifiers and authentication instead of mutual authentication. I don't expect to see explicit guidelines on mutual auth, but with that as the header, I would have. Thanks, Kathleen On Mon, Aug 22, 2016 at 8:46 AM, Susan Hares <[email protected]> wrote: > Juergen: > > Thank you for your input. > > I can find nothing new in your input that was not covered in the I2RS WG > discussions. As far as I can tell you are re-iterating a discussion that > occurred in the WG, and was closed. I have given example (BGP route-view, > web-service up) as events which currently in the public and have been > requested by some operators. Please note that the operator should have a > knob that says "always" secure-transport. > > Sue > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:[email protected]] > Sent: Monday, August 22, 2016 6:08 AM > To: Susan Hares > Cc: 'Andy Bierman'; 'Lou Berger'; [email protected]; 'Alissa Cooper'; > [email protected]; 'Kathleen Moriarty'; 'IESG'; 'Jeffrey Haas'; 'Joel > Halpern'; [email protected] > Subject: Re: [i2rs] Kathleen Moriarty's Discuss on > draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT) > > On Fri, Aug 19, 2016 at 12:55:53PM -0400, Susan Hares wrote: >> Andy: >> >> >> >> The easy of reviewing per leaf – is why I suggested the per leaf. >> >> I also agree it is important to mention this non-secure/secure requirement >> to the PUSH work team we are both on. >> >> >> >> Should I change: >> >> Old: / >> >> A non-secure transport can be used for publishing telemetry data or >> >> other operational state that was specifically indicated to non- >> >> confidential in the data model in the Yang syntax. / >> >> New: >> >> / A non-secure transport can be used for publishing telemetry data or >> >> other operational state that was specifically indicated to non- >> >> confidential in the data model. / >> > > Tagging something in the data model as 'non-confidential' remains a flawed > idea. What can be considered 'non-confidential' depends on the deployment > scenario. It is even worse to standardize some piece of information as > 'non-confidential'. How can the IETF claim that something is always > 'non-confidential'? (And note, a non-secure transport is not just about > confidentiality, it also implies that boxes on the path can arbitrarily > change the information.) > > In case this is not clear: What we have done for ~30 years is to have the > decision which information goes into an insecure transport be taken by an > access control model. This makes the decision runtime configurable and thus > things can be deployment specific. This has worked for 30 years and I have no > problem with this. What I am struggling with is the idea to standardize parts > of YANG data models as 'non-confidential'. > > /js > > -- > 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/> > -- Best regards, Kathleen _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
