Re: RFC 8200: The Devil's Paragraph

[Fernando Gont <[e-mail]>]

On 27/2/20 23:08, Brian E Carpenter wrote:
> Ron,
> 
> Rather than getting involved in the errata/appeal discussion, I'll comment here.
> 
> On 28-Feb-20 11:52, Ron Bonica wrote:
>> Folks,
>>
>> Looking more closely at “The Devil’s Paragraph”, it may have a few problems.  Currently, it says:
>>
>> “Extension headers (except for the Hop-by-Hop Options header) are not
>>     processed, inserted, or deleted by any node along a packet's delivery
>>     path, until the packet reaches the node (or each of the set of nodes,
>>     in the case of multicast) identified in the Destination Address field
>>     of the IPv6 header.”
>>
>> The problem is that the rules for processing, insertion and deletion are different. It should say the following about extension header processing:
>>   
>> “The Hop-by-Hop Options header can be processed by any node in packet’s delivery path.
> 
> The word "process" itself is troublesome, and I believe I said this at some point in the 2460bis discussion. I'd rather see it broken into two parts
>    "read and interpreted"
>    "modified (without changing the data length)"
> with separate rules for each.

The problem is, that as anything that's produced by humans, if you want, 
you will probably always find something that could have been said better.

When it comes to this discussion, it has always bee clear to everyone 
that IPv6 does not support header insertion/removal along the delivery path.

In fact, even with RFC2460, it was only the proponents of RFC2460 that 
said there was ambiguity, and that's why we tried to add more text and 
polish the existing one.

One would expect that if in good faith/will, you try to understand the 
intent, and if not clear, you go to the source (i.e., the folks that 
worked on the spec (ideally the authors, and possibly folks that 
participated in the process).

But in this case, it has been totally the opposite: the proponents have 
tried to lecture 6man about their own interpretation of the standard, 
and when faced with the response, essentially they did their best to 
intentially leave as much ambiguity in the spec as possible, to prepare 
the playground we are seeing. -- remember 6man shipped rfc2460bis with 
no clarification on the topic, and only incororated it as a result of 
IETF LC.

So we're now operating in a mode of having to craft text knowing that 
folks will willingly try to read from it what they want to read.

Similarly, I have submitted an errata (which fixes other issues with the 
EH-processing text).. but still pretending that the intent of RFC8200 is 
not clear.

-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492