Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-exthdr-03.txt>

From: RJ Atkinson <[email-masked]>
Date: Fri, 1 Jul 2011 10:00:45 -0400

On 30th June 2011, Bob Hinden wrote:
> This message starts a two week 6MAN Working Group Last Call on advancing:
> 
> 	Title           : An uniform format for IPv6 extension headers
> 	Author(s)       : Suresh Krishnan
>                          Erik Kline
>                          James Hoagland
>                          Manav Bhatia
> 	Filename        : draft-ietf-6man-exthdr-03.txt
> 	Pages           : 8
> 	Date            : 2011-06-27
> 	
>        
> http://tools.ietf.org/html/draft-ietf-6man-exthdr-03
> 
> 
> as a Proposed Standard.  Substantive comments and statements of support
> for advancing this document should be directed to the mailing list.  
> Editorial suggestions can be sent to the authors.  This last call
> will end on 14 July 2011.

I support publishing this as a Proposed Standard.  

This revision resolves my earlier concerns that it is
highly undesirable to define *any* new IPv6 Extension Headers
(since defining any new IPv6 Extension Header will break 
multiple existing IPv6 deployments).

On 1st July 2011, David Malone wrote, in part:
> Fixing this could be a simple as changing the title and abstract, 
> plus possibly adding something in Section 4 to actually encourage 
> use of the uniform format.

I do not have any philosophical objections to the suggested
edit of the document Title and expansion of the Abstract.

Perhaps the lone sentence in Section 4 could be reworded
into RFC-2119 language.  Candidate replacement text might be:

	If any IPv6 Extension Headers are defined in future,
	keeping in mind the restrictions above in Section 3
	and also the restrictions specified in RFC-2460,
	they MUST use the consistent format defined in Figure 1.
	This enables future IPv6 implementations to skip over 
	unknown IPv6 Extension Headers and continue to further 
	process the IPv6 header chain.

Yours,

Ran

---

From: Karl Auer <[email-masked]>
Date: Sat, 02 Jul 2011 08:53:24 +1000

> multiple existing IPv6 deployments).

It seems strange to me that we define "IPv6 Extension Headers", then
refuse to allow any further extensions! That was largely the point and
purpose of the exercise.

That said, it is always "highly undesirable" to make changes to a
deployed protocol UNLESS the changes can safely be ignored. It will
depend on the function of any future extension headers as to whether
they will be able to be safely ignored. On the other hand, if an
extension is needed, then it is needed, and the community will have to
make the tradeoff between the undesirability of a change and the
desirability of a new feature.

This draft means that if an application runs into headers it does not
understand, then at least it can skip them neatly. If *skipping* them
causes problems, then at least the authors *should have* been aware that
new extension headers might come along, and *should have* planned for
that in some way.

Hm, I think I might just have used more words to say what you said :-)

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 7 Jul 2011 15:11:30 -0400

Hi Ran,
  The text you proposed seems reasonable. I will make the change in the next rev.

Thanks
Suresh

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of RJ Atkinson [[email-masked]]
Sent: Friday, July 01, 2011 10:00 AM
To: [email-masked]
Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-exthdr-03.txt>

Yours,

Ran

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------