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

Guys,

Please hold your horses. The AD has made the call. I don't think we need to 
have a poll on that.

Cheers,
Ole

> On 15 Mar 2017, at 03:47, Suresh Krishnan 
> <suresh(_dot_)krishnan(_at_)ericsson(_dot_)com> wrote:
>
> Thanks to everyone who commented during the IETF Last Call of 
> draft-ietf-6man-rfc2460bis-08. The IETF last call discussion for this draft 
> was mainly focused around the text in Section 4 that discusses the handling 
> of extension headers. The biggest concern raised was that the current text is 
> ambiguous on whether header insertion is allowed on intermediate nodes or 
> not. There were some people arguing that an explicit prohibition is not 
> necessary as the text is already clear, while others believed that explicitly 
> listing the prohibitions will minimize any misunderstandings in the future. 
> There was also a small number of people who wanted to explicitly allow header 
> insertion and describe how to do it, but this was clearly out of scope for 
> this draft (but may be in scope for future work in 6man). Overall, no one 
> argued against the fact that the intent of the text in RFC2460 was to forbid 
> insertion of extension headers on any other node but the source of the 
> packet.  The only argument made against adding clarifying text was that the 
> text was already clear. Given this, I believe there is consensus to add 
> explicit text about header insertion into the draft before it progresses 
> further. I have discussed this with the editor and the document shepherd and 
> would like to propose the following text change.
>
> OLD (from -08):
>
> The insertion of Extension Headers by any node other than the source
> of the packet causes serious problems.  Two examples include breaking
> the integrity checks provided by the Authentication Header Integrity
> [RFC4302], and breaking Path MTU Discovery which can result in ICMP
> error messages being sent to the source of the packet that did not
> insert the header, rather than the node that inserted the header.
>
> One approach to avoid these problems is to encapsulate the packet
> using another IPv6 header and including the additional extension
> header after the first IPv6 header, for example, as defined in
> [RFC2473]
>
> With one exception, extension headers are not processed 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...
>
> 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...
>
> Please feel free to comment either privately or on list if you have any 
> concerns with this resolution going forward.
>
> Regards
> Suresh
>
> P.S.: There were also other editorial issues that were raised during last 
> call and they should be addressed in the next version of the 
> draft--------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6(_at_)ietf(_dot_)org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

signature.asc
Description: Message signed with OpenPGP