Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Brian E Carpenter 写道:
> 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).
>   

+1

xing

> Regards
>     Brian
>
>
>  
>
>
>
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>