Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

[Jen Linkova <[e-mail]>]

On Fri, Mar 31, 2017 at 1:09 AM, Brian E Carpenter
<[e-mail]> wrote:
>>> NEW:
>>>
>>>  With one exception, extension headers are not examined, 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...
>>
>> I have some concerns with how that sentence AND the following note
>> comes together:
>>
>> "  With one exception, extension headers are not examined, 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.  Note: If an intermediate forwarding node examines
>>    an extension header for any reason, it must do so in accordance with
>>    the provisions of [RFC7045].  "
>>
>> I'm afraid that the lack of the normative language strikes back..
>
> Exactly the opposite, IMHO. I think it's much better like this than it
> would be under RFC2119 (although in fact that doesn't change the
> English meaning of 'must'). The "Note:" describes a situation where
> middleboxes are actually breaking the rule. We had that fight before
> RFC7045.

Shell we then say
'Extension headers are not processed by intermediate nodes unless
those nodes strictly
follow [RFC7045].  With one exception, extension headers are not modified,
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."
?


-- 
SY, Jen Linkova aka Furry