Re: What if? [was Re: Extension Header Insertion]

[Fernando Gont <[e-mail]>]

On 10/12/19 20:12, Warren Kumari wrote:
> On Tue, Dec 10, 2019 at 7:51 PM Brian E Carpenter
> <[e-mail]> wrote:
>>
>> Thanks Darren. I will hold off on the spring draft until we see a new version, since several of us are simply repeating ourselves at this point.
>>
>> On balance I'm inclined to point a finger at RFC8200:
>>
>>>    Each extension header should occur at most once, except for the
>>>    Destination Options header, which should occur at most twice (once
>>>    before a Routing header and once before the upper-layer header).
>>
>> I now think that either that "should" should be a "must", or there
>> should be an explicit statement that only one routing header is
>> allowed. The complexities of multiple routing headers are endless.
>>
>> What do others think?
> [ Of hats, I have none... ]
> 
> I think that not having RFC2119 language in this section is very
> unfortunate, and creates a situation where different people read
> different things into it (and are convinced that their interpretations
> are clearly the right ones....)

+1 . Although I think RFC8200 should have employed RFC2119 language
everywhere.



> I personally think that the spirit behind the Postel principle
> applies, and that the should is a prohibition against there being more
> than one, and that if receivers happen to do something sane in this
> case, it is close to luck, not spec.

+1 on this one. That said, the requirement to process any weird
combination eventually means lots of unnecessary code and analsys to
handle weird combinations (such as the one being discussed) that should
actually never happen.

Thanks,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1