On 9/15/10 4:36 PM, Bhatia, Manav (Manav) wrote: > Hi Samuel, > > Thanks for the review. > >> Is there a way to present this information more compactly? I >> suggest a table with routing protocol on one axis, crypto suite on >> another, and requirement status in the elements (perhaps with a >> cite to the doc that sets the requirement). You might separely say >> "MANDATORY to implement, OPTIONAL to use, NOT SUGGESTED for use". > > This is precisely what we were doing till the OPSEC WG members asked > us to change the format to the current one. And the current method is still the right way to do it imho. the doc is not intended to impose the requirement on protocol authors, rather to point out how requirements would shift in the case of prference for another algorithm... >> >> You could also put suggestions and speculation about the future in >> the same table, though you may need to define some terms. And it > > We were using extended 2119 terms like SHOULD+, MUST- and MAY+ > originally and these were again removed because of the strong > consensus in the WG in favor of the current text. They were confusing, and detracted from the recomendations. to cite a particular section that I think underscores this: IS-IS implementations SHOULD provide support for the generic cryptographic authentication scheme [RFC5310] and it is our understanding that interoperability considerations will require change to a MUST as operators migrate to this authentication scheme. which I interpret as: RFC 5310 states that is-is implementations should implement support for the generic cryptographic authentication scheme. If at some future date recommendations were to support a key method other than HMAC-MD5 then it would follow that support for the generic cryptographic authentication scheme would become a requirement. SHOULD- MUST+ makes interpreting that a WTF moment. >> needs to be clear when this doc diverges from past ones or makes a >> new statement. I have not gone back through the previous docs to >> confirm that this doc isn't changing anything. >> >> I see a whole bunch of lower case "may" and "should", and I'm >> wondering what to make of them. that they are not normative language. >> In describing each routing protocol's authentication options, it >> would be helpful to say whether there's any in-band negotiation >> available. > > I am not sure I understand whats being meant by in-band negotiation > here? this document is focused on operational considerations of exist protocols so for example a karp supplied kmp is probably out of scope for the document in it's present form. >> If so, more needs to be said about that in the security >> considerations. If not, it should be documented here. >> >> I don't need to hear three or four separate times that cleartext >> passwords are bad. > > Just making sure that folks don't miss this! :) > >> >> Minor: remove citations from the abstract (per rfc editor policy). > > Sure, will do. > > Cheers, Manav > >> >> -- Sam >> >> > _______________________________________________ Ietf mailing list > Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf