Re: [babel] Robert Wilton's Discuss on draft-ietf-babel-rtt-extension-05: (with DISCUSS)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Juliusz,

I think that you should go further and cite the text as normative.  Publishing the document as proposed standard doesn’t require that the algorithm be perfect, or no better algorithm exists.  It just needs to be good enough and clearly documented.

If someone finds some issues with it then they will probably write a new RFC that addresses those issues, potentially replacing this document, or parts of this document.

Regards,
Rob



From: Juliusz Chroboczek <[e-mail]>
Date: Friday, 16 February 2024 at 11:47
To: Rob Wilton (rwilton) <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Donald Eastlake <[e-mail]>
Subject: Re: Robert Wilton's Discuss on draft-ietf-babel-rtt-extension-05: (with DISCUSS)
Hello Robert,

> Thanks for this document.  I've balloted "discuss" on this document because I
> would like to have a discussion with the responsible AD and other ADs as to
> whether Standards Track is the right classification for this document based on
> the text below, where it seems like a key part of the solution is only
> experimental.

I think I've been too cautious in writing this document.

The algorithm described in this document has been deployed since 2014 on
thousands of routers (I'd be allowd to give you the data I have orally,
but I'm unfortunately not allowed to make it public).  I has also been
carefully studied in the lab by the authors, as described in the reference
[DELAY-BASED] of the draft.

There are two reasons why the second part of the document is not
normative :

  - while we have a strong confidence that the algorithm works well, both
    in the real world and in worst-case simulation, we do not fully understand
    why it works as well as it does (we have no proof);

  - there might be better algorithms, and we do not wish to engrave this
    specific algorithm in the marble of a normative document.

I will rewrite the document to mark this part as "non-normative" rather
than "experimental".

> I appreciate that this document is also defining new TLVs, but the
> pertinent IANA registry policy is only specification required, and there
> is also reserved IANA values for experimental TLVs that could also be
> used, if appropriate.

The algorithm has been successfully deployed for ten years now, it's fair
to say that the experiment has now concluded.

-- Juliusz