On 28-May-20 07:18, Zafar Ali (zali) wrote:
> WH> My position remains that RFC8663 is a valid alternative and is available;
> I am against WG adoption of CRH.
>
> The industry widely supports RFC8663.
Can you remind us which major operators rely on RFC8633 today? After all, the
RFC is only 5 months old.
> Instead of denying the evidence, could the CRH authors and proponents finally
> understand that people are not opposed to new ideas?
>
> People are reminding a long-standing practice of the IETF process. Before
> tackling a new piece of work, a working group must perform a due diligence on
>
> 1. whether this new work is redundant with respect to existing IETF
> protocols,
> 2. whether this new work would deliver genuine benefits and use-cases.
I don't know where you get that "must" from since the IETF has no rules to
govern the process of draft adoption. (There will be a draft about that
shortly, for possible discussion in gendispatch, but today there are no rules).
There is some general guidance about redundancy, in RFC1958:
"3.2 If there are several ways of doing the same thing, choose one.
If a previous design, in the Internet context or elsewhere, has
successfully solved the same problem, choose the same solution unless
there is a good technical reason not to. Duplication of the same
protocol functionality should be avoided as far as possible, without
of course using this argument to reject improvements."
So, in so far as we have guidance on when to accept apparent duplication, it is
around two judgments: "there is a good technical reason" and "improvements".
> It is factually and logically clear to the working-group that the currently
> submitted CRH documents.
>
> 1. fail to position CRH with respect to existing standard widely supported
> by the industry (e.g., RFC8663)
> 2. fail to isolate new benefit or use-case [1]
Neither of those things are required in a protocol spec. I'm not saying they
are unimportant, or that they should not inform the adoption decision, but they
have been discussed on this mailing list and IMHO that is sufficient for the WG
decision.
I'm not competent to "position" CRH. That's why I'd like hear from the Routing
Area ADs. However, I will comment that it takes about 10 minutes to read and
understand the CRH spec. It would take several days to read and understand the
SRV6 material to the point of fully understanding RFC8574 (I know because I
tried), and RFC8663 also needs a lot of background reading. There are a couple
of other items in RFC1958 that seem relevant to this:
"3.5 Keep it simple. When in doubt during design, choose the simplest
solution.
3.6 Modularity is good. If you can keep things separate, do so."
CRH factually and logically wins on those criteria.
The use case is: some operators want this. That has been enough for the IETF
since 1986 (and is of course much more important than vendor preferences).
Regards
Brian
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
