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

[Carlos Pignataro <[e-mail]>]

👍🏼

Carlos Pignataro reacted via Gmail
<https://www.google.com/gmail/about/?utm_source=gmail-in-product&utm_medium=et&utm_campaign=emojireactionemail#app>

On Thu, Oct 22, 2026 at 10:34 PM Ran Atkinson <[e-mail]>
wrote:

> 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
> >>
> >
>
>