[RTG-DIR]Re: draft-ietf-teas-rsvp-auth-v2-02 early Rtgdir review

[Ran Atkinson <[e-mail]>]

Hi,

For consistency, I think RSVP ought to use the same words that IPsec uses for its security transforms in the IANA Registry.

Please see RFC-8221, Section 5, page 7, which uses “Status” rather than “Implementation Status”.  

My apologies for the tardy response to this thread.

Yours,

Ran

> On Oct 21, 2026, at 20:40, Carlos Pignataro <[e-mail]> wrote:
> 
> Hi, Tony,
> 
> Thanks for the responses — please find one follow-up inline.
> 
>> On Oct 21, 2026, at 6:52 PM, Tony Li <[e-mail]> wrote:
>> 
>> Hi Carlos,
>> 
>> Please see inline.
>> 
>> 
>>> From: "Carlos Pignataro via Datatracker - noreply at ietf.org" <[e-mail]>
>>> Subject: draft-ietf-teas-rsvp-auth-v2-02 early Rtgdir review
>>> 
>>> 1. Section 7 (IANA) uses RFC 2747 as the reference for HMAC-MD5, with a SHOULD,
>>> but this RFC obsoletes RFC 2747. This looks self-contradicting, particularly
>>> without MTI algo.
>> 
>> 
>> I believe that Joel Halpern has already addressed this comment.
>> 
>> 
>>> 2. Also, the column "Implementation Status" seems to be a misnomer, or a
>>> conflict with RFC 7942. Is that Requirement Level?
>> 
>> 
>> No, that was intentional. It has no relationship to RFC 7942, which does not have a trademark on “Implementation Status”.  We infer that you’re unhappy with the terminology.  Would you be happier with “Implementation Recommendation”?
> 
> 
> Frankly, the choice of words would have no influence on my happiness level — that said, I believe "Implementation Recommendation” is more accurate and less conflicting/distracting.
> 
> Best,
> 
> Carlos.
> 
>> 
>> 
>>> 3. Section 2 says the HF flag is a SHOULD. Section 4.3 says MUST.
>> 
>> 
>> Thank you, we will amend section 2.
>> 
>> 
>>> 4. In S4.1.1, is "computed over the message" enough clarity?
>> 
>> 
>> Given that this is the high level overview, we believe so.
>> 
>> 
>>> 5. Security association selection is based on the egress interface -- are there
>>> issues with RSVP with unnumbered, or budnle links?
>> 
>> 
>> Not that we know of.  Bundled links (i.e., LAGs) are an abstraction of multiple links into a single link.  RSVP operates at the level of the abstraction.  Similarly, the security association for an unnumbered link is specific to the link that the message arrived on.  Thus, numbering is not relevant, and unnumbered links are not an issue.
>> 
>> 
>>> 6. What is the length of the Challenge Cookie?
>> 
>> 
>> The challenge is variable length.  Its length for a given object is easily derived from the RSVP Object Header [RFC 2205, section 3.1.1], which defines a 16 bit length field for the object.  There are two reserved octets and then key identifier, of 48 bits, so the object length minus 8 octets gives the challenge length in octets.
>> 
>> Cheers,
>> Ran & Tony
>> 
>