Subject: Re: <draft-ietf-6man-rfc2460bis-02.txt>

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 5 Jan 2016 15:49:56 +0100

I reviewed the changes.  They look ok.  I found one nit:

> For this purpose, the Encapsulating Security Payload (ESP) is not
> considered an extension headers.
                                 ^ strike s.

Additionally, I think rfc2460bis lists all extension headers.

If so, I would like to suggest to refer to the Mobility Header extension 
header.  This extension header is defined in RFC6275 "Mobile IPv6".

Is this ok?

Alex

Le 16/12/2015 08:56, Bob Hinden a écrit :
> I published the -02 version of 6man working group draft of
> rfc2460bis.  Links below.
>
> It has the changes based on the discussion at the 6MAN session at the
> Yokohama IETF.  These include
>
> Added text to Section 4.8 "Defining New Extension Headers and
> Options" clarifying why no new hop by hop extension headers should be
> defined.
>
> Added text to Fragment Header process on handling exact duplicate
> fragments.
>
> A few editorial changes.
>
> A diff from the -02 version can be found at:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-02
>
> Please review the changes.
>
> Thanks, Bob
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the IPv6 Maintenance
>> Working Group of the IETF.
>>
>> Title           : Internet Protocol, Version 6 (IPv6)
>> Specification Authors         : Stephen E. Deering Robert M.
>> Hinden Filename        : draft-ietf-6man-rfc2460bis-02.txt Pages
>> : 37 Date            : 2015-12-15
>>
>> Abstract: This document specifies version 6 of the Internet
>> Protocol (IPv6), also sometimes referred to as IP Next Generation
>> or IPng.  It obsoletes RFC2460
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-02
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-02
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> --------------------------------------------------------------------
>>
>>
IETF IPv6 working group mailing list
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 6 Jan 2016 08:06:26 +1300

> Additionally, I think rfc2460bis lists all extension headers.

No it doesn't. We have an explicit IANA registry for that, as defined by RFC 7045:
http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header

   Brian

> 
> If so, I would like to suggest to refer to the Mobility Header extension header.  This extension header is defined in RFC6275
> "Mobile IPv6".
> 
> Is this ok?
> 
> Alex
> 
> 
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Bob Hinden <[email-masked]>
Date: Tue, 5 Jan 2016 15:23:28 -0800

> On Jan 5, 2016, at 11:06 AM, Brian E Carpenter <[email-masked]> wrote:
> 

Correct.  Looking at the document, I think it would make sense to add to the end of Section 4 a reference to that IANA registry.

Thanks,
Bob

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Jan 2016 13:22:50 +0100

Le 06/01/2016 00:23, Bob Hinden a écrit :
>>>> For this purpose, the Encapsulating Security Payload (ESP) is
>>>> not considered an extension headers.
>>> ^ strike s.
>>>
> Correct.  Looking at the document, I think it would make sense to add
> to the end of Section 4 a reference to that IANA registry.

I agree.

Alex

>
> Thanks, Bob
>
>
>>
>> Brian
>>
>>>
>>> If so, I would like to suggest to refer to the Mobility Header
>>> extension header.  This extension header is defined in RFC6275
>>> "Mobile IPv6".
>>>
>>> Is this ok?
>>>
>>> Alex
>>>
>>>
>>>> It has the changes based on the discussion at the 6MAN session
>>>> at the Yokohama IETF.  These include
>>>>
>>>> Options" clarifying why no new hop by hop extension headers
>>>> should be defined.
>>>>
>>>> Added text to Fragment Header process on handling exact
>>>> duplicate fragments.
>>>>
>>>> A few editorial changes.
>>>>
>>>>
>>>> Thanks, Bob
>>>>
>>>>> A New Internet-Draft is available from the on-line
>>>>> Internet-Drafts directories. This draft is a work item of the
>>>>> IPv6 Maintenance Working Group of the IETF.
>>>>>
>>>>> Hinden Filename        : draft-ietf-6man-rfc2460bis-02.txt
>>>>> Pages : 37 Date            : 2015-12-15
>>>>>
>>>>> Protocol (IPv6), also sometimes referred to as IP Next
>>>>> Generation or IPng.  It obsoletes RFC2460
>>>>>
>>>>>
>>>>> submission until the htmlized version and diff are available
>>>>> at tools.ietf.org.
>>>>>
>>> IETF IPv6 working group mailing list [email-masked] Administrative
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> IETF IPv6 working group mailing list [email-masked] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Jan 2016 13:34:42 +0100

> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header

I can agree one should rather look explicitly at a IANA registry to find 
all extensions headers.

At the same time, it would be expected that EH text in rfc2460 would 
apply equally well to each particular EH.

Especially, what EHs were "currently defined" at the time of 2460 became 
more numerous now for new2460.

For example, the following text:
> 4.2.  Options
>
>    Two of the currently-defined extension headers -- the Hop-by-Hop
>    Options header and the Destination Options header -- carry a variable
>    number of type-length-value (TLV) encoded "options", of the following
>    format:

should rather say "_Three_ of the currently-defined extension headers -- 
the Hop-by-Hop Options header, the Destination Options header and the 
Mobility Header -- carry a variable number of TLVs...".

Or maybe it could say "Some of the EHs (e.g. HbH, DO, MH, other) carry a 
variable number of TLVs".

Otherwise, 2460 reads as _only two_ _currently-defined_ EHs carry TLVs. 
  Which doesn't read quite right because the new MH (absent when 2460 
was out) carries a variable number of TLVs too.

For ref the Mobility Header is at:
http://tools.ietf.org/html/rfc6275#section-6.1

Yours,

Alex

or

---

From: Bob Hinden <[email-masked]>
Date: Wed, 6 Jan 2016 09:52:27 -0800

Alexandre,

> On Jan 6, 2016, at 4:34 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> I can agree one should rather look explicitly at a IANA registry to find all extensions headers.
> 
> At the same time, it would be expected that EH text in rfc2460 would apply equally well to each particular EH.
> 
> Especially, what EHs were "currently defined" at the time of 2460 became more numerous now for new2460.
> 
> should rather say "_Three_ of the currently-defined extension headers -- the Hop-by-Hop Options header, the Destination Options header and the Mobility Header -- carry a variable number of TLVs...".
> 
> Or maybe it could say "Some of the EHs (e.g. HbH, DO, MH, other) carry a variable number of TLVs".
> 
> Otherwise, 2460 reads as _only two_ _currently-defined_ EHs carry TLVs.  Which doesn't read quite right because the new MH (absent when 2460 was out) carries a variable number of TLVs too.

I think it referring to the extension headers defined in this document.  But I agree it could be clearer, and will fix.

Thanks,
Bob