Re: Gen-ART LC review of draft-ietf-isis-hmac-sha-05

[Ben Campbell <ben at estacado.net>]

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 mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf