Thanks--comments imbedded. I have edited out items that I think are
closed.
In summary, you have addressed all of my substantive comments.
Anything remaining is editorial, and minor at that.
On Oct 28, 2008, at 8:35 PM, Bhatia, Manav (Manav) wrote:
[...]
-- 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.
On re-reading the section, I realize that I mistakenly thought the
Auth-Type field in the new TLV carried the selected hash algorithm. I
now realize that this field is only there for backwards compatibility,
and merely indicates you are using this specific authentication model,
as opposed to one of the legacy mechanisms. So nevermind :-)
[...]
-- Section 2, second bullet:
How is the selected algorithm encoded into the 1-octet
Authentication
Algorithm field?
Section 2 details the parameters associated by the ISIS Security
association indexed by the Key ID. One does not need to carry this in
the ISIS PDU. Its, as I mentioned above, derived at the receiving
end by
a lookup done against the Key ID.
This comment was related to the misread I mentioned above--so, again,
nevermind :-)
[...]
-- 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?
Yes, it was intentional.
Let me push on that a minute--how can this draft make normative
statements about implementations that don't support this draft? To put
a sharper point on it, you can't assume that someone who is not
implementing this draft will even read this draft.
If you are in fact describing existing behavior rather than specifying
a new normative requirement, then it would probably be better to avoid
normative language, or state is in the form of "according to RFC XXXX,
implementations MAY..."
(On the other hand, since this is a MAY, it's probably less of an
issue than if it were a stronger normative statement.)
-- Section 8
The author list here does not match the first page. Should some of
these move to a "Contributors" section?
Will fix this.
See other emails on this one.
Thanks!
Ben.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf