Document: draft-ietf-isis-hmac-sha-05
Reviewer: Ben Campbell	
Review Date:  2008-10-28
IETF LC End Date: 2008-11-04
IESG Telechat date: (if known)

Summary:

This draft is almost ready for publication as an RFC. (The draft does not identify the intended status--I assume it to be standards track).  
I have some questions that should be addressed first, as well as some minor editorial comments.

Comments:

Substantive:

-- The draft does not state its intended status.

-- The draft suggests that this extension can be used for arbitrary cryptographic authentication mechanisms, and defines how it is used for HMAC-SHA. However, I found no text on how to extend it for other mechanisms. For example, is the hash algorithm list intended to be extensible? Should there be an IANA table for that, then? Are the parameters in this new authentication type assumed to be sufficient for any arbitrary mechanism?

-- Section 2, first bullet point:

Can you provide motivation for a single octet length for Key ID? I'm not saying this is wrong; just that it would be good to know that this is a considered choice rather than an arbitrary one. My instinct is to wonder if limiting the Key-ID space to 256 values is too small. Also, it would be good to mention that administrators will need to keep the Key-ID assignments consistent between members of an SA.

-- Section 2, second bullet:

How is the selected algorithm encoded into the 1-octet Authentication Algorithm field?

-- Section 3.5, 2nd to last paragraph:

I suspect this paragraph has significant security considerations that should be addressed in section 4.

-- Section 3.5, last paragraph:

This paragraph seems to make a normative statement about implementations that _don't_ implement this extension. Is that the intent?

Editorial:

-- Section 1, first paragraph: Lots of acronyms here--please consider expanding on first use.

-- Section 1, last paragraph: I suggest scoping this statement with something to the effect of "At the time of this writing, no openly published..."

-- Section 3.2: 

I assume the area, link, and domain authenticated strings are described in the original IS-IS doc? If so, can you reference them by section?

-- Section 3.3, "K" -- Can you provide a reference for ISO 10589?