Re: [Sidrops] version negotiation

[Claudio Jeker <[e-mail]>]

On Wed, Jan 03, 2024 at 11:29:15AM -0800, Randy Bush wrote:
> claudio:
> 
> > I think paragraph 2 and 3 (both about Q < N) should be merged.
> 
> choice of style
> 
> > Current paragraph 4 makes the negotiation much clearer (but 'with a
> > Protocol Version Q of the version N in the Error Report' is a mouth
> > full).
> 
> some of us have big mouths :)
> 
> but i will confess to qualms about long run-on sentences.  i'll work on
> that
> 
> > What is unclear what should happen when "unless it has already failed
> > at that version" comes into play? Should it abort like in the last
> > paragraph?
> 
> i think that is deadly.  speaking of run-on sentences
> 
>    If the router query has version Q > N, the cache MUST send an Error
>    Report (Section 5.11) with Protocol Version N and Error Code 4
>    ("Unsupported Protocol Version").  The router SHOULD send another
>    query with a Protocol Version Q of the version N in the Error Report,
>    unless it has already failed at that version, which indicates a fatal
>    error in programming of the cache which SHOULD result in transport
>    termination.

How about:
The router SHOULD downgrade its protocol version to N and send another
query with that version unless it has already failed at that version ...
 
In any case clarifying such edge conditions is important to help
developers implement the protocol correctly.

> > Now this changes the sematics of Error Code 4.  So Section 13 needs to be
> > adjusted. Error code 4 should not be fatal but have special handling as
> > described in Section 7. This is required because:
> >    Errors which are considered fatal MUST cause the session to be dropped,
> >    and the router MUST flush all data learned from that cache.
> 
> i am less sure of this.  note that is the session which must be dropped,
> not the transport.  and the session has not yet even been established
> if we're still negotiating versions.

Please reconsider since this bit is utterly confusing. The RFC does not
explain this distinction. If this is the case how should Error 0 and 1 be
handle? It seems there is multiple level of fatal here. At least I see no
way to gracefully handle a corrupt data error without reestablishing a new
session.

I dislike how underspecified the error handling in all the RTR RFCs is.
In my opionion this deserves the same scrutiny as the other RPKI RFCs.

-- 
:wq Claudio