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(_at_)ietf(_dot_)org https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf