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. > > 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. > 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. > > 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? > 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