On Thu 26 Feb 2026 at 21:11 +0000, Mike Bishop wrote:
> > > # Requirement for Validation
> > >
> > > I remember (and concur with) the decision not to over-specify beyond
> > > the requirement to validate. The question is what specifically the
> > > client can send on the incipient path before validation completes. RFC
> > > 9000 imposes no restrictions on what can be sent, only how much; this
> > > specification prohibits sending "any data," apparently referencing
> > > Section 8.2 of RFC 9000 to define that restriction, but I don't see it
> > > there.
> > >
> > > If the intention is to match RFC 9000 and not restrict, then I think
> > > the wording needs a tweak to remove that implication​. If there is a
> > > new restriction being imposed, it should be explicitly stated and
> > > justified.
> >
> > [MK] As far as I recall this formulation was not meant as any
> > restriction. However, you need to say something in the sentence
> > about _when_ path validation needs to happens. I guess we could also
> > say something like “before a path can be used” but that also very
> > blurry. Not sure what a better formulation is? Any proposals? Again,
> > given we discussed this sentence so much, I would prefer to not
> > change it again. As nobody else brought this up, maybe it reasonably
> > clear enough…?
>
> [MB] I think the simplest fix is to delete the words "before sending
> any data". There's no actual requirement on when validation happens
> relative to anything else that happens on the path, only that the
> anti-amplification limit remains in place until it has.

This validation is mandated for the client in the discussed
paragraph. It is my understanding that the anti-amplification limit only
applies to the server. So whether this path validation fails or not
seems to have no influence on how much data the client is allowed to
send to the server in the proposed wording.

It makes this validation being a MUST seem an odd choice. RFC9000 §9.1
only has a MAY for validation of new paths when migrating. In all
fairness, I'm still unclear on the intention of the validation in the
current spec.


Cheers,
Floris

Reply via email to