Subject: Re: Definition of Extension Header in draft-ietf-6man-oversized-header-chain-05.txt (was Re: I-D Action: draft-ietf-6man-oversized-header-chain-05.txt)

From: Fernando Gont <[email-masked]>
Date: Mon, 02 Sep 2013 21:20:40 -0300

On 08/31/2013 10:28 PM, Brian E Carpenter wrote:
> Hi Fernando,
> 
> I'm biased, but I'd prefer the reference (your first suggestion), unless
> the ext-transmit draft gets stuck in the process, in which case you could
> make an editorial change later, even up to AUTH48.

As noted, I'm open to any of the two options. That said, would a
normative ref to draft-ietf-6man-ext-transmit be really appropriate/correct?

If you think about it, that'd be an "informational reference" rather
than an authoritative one... (you don't need to read
draft-ietf-6man-ext-transmit to understand
draft-ietf-6man-oversized-header-chain-05.txt). For instance, the IANA
registry itself is not a normative reference.

Anyone else has an opinion on this one? Chairs?

> BTW check the IANA URL too; I think you had a pointer to a .txt file, but
> these days IANA is .xml based.

Do you know which file is the authoritative one?

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Sep 2013 17:03:48 +1200

Hi Fernando,

> registry itself is not a normative reference.

Logically, you're correct. It would just be a shame for it to come out
as a "work in progress" reference instead of an RFC. Maybe we can ask for
the two RFCs to be published at the same time.

> Do you know which file is the authoritative one?

If you follow links from the IANA home page, you get to
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
As far as I know that is the primary reference.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 03 Sep 2013 04:03:01 -0300

> the two RFCs to be published at the same time.

Agreed. I will rev the I-D as described (but with an informational ref
to your I-D), and will note the RFC-Ed about this. -- However, my take
is that this will be nevertheless the case (draft-ietf-6man-ext-transmit
will be published at the same time or before oversized-header-chain).

> As far as I know that is the primary reference.

Ok, I will replace the TXT URL with the XML URL -- worst case scenario,
this will fixed (if needed) later on.

Thanks so much!

Cheers,

---

From: Ole Troan <[email-masked]>
Date: Tue, 3 Sep 2013 12:44:03 +0200

> will be published at the same time or before oversized-header-chain).

I would prefer a normative reference to the ext-transmit document for the definition of extension headers.
I agree that we should publish these two documents together.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 03 Sep 2013 08:00:26 -0300

On 09/03/2013 07:44 AM, Ole Troan wrote:
>>>> As noted, I'm open to any of the two options. That said,
>>>> would a normative ref to draft-ietf-6man-ext-transmit be
>>>> really appropriate/correct?
>>>> 
>>>> If you think about it, that'd be an "informational reference"
>>>> rather than an authoritative one... (you don't need to read 
>>>> draft-ietf-6man-oversized-header-chain-05.txt). For instance,
>>>> the IANA registry itself is not a normative reference.
>>> 
>>> Logically, you're correct. It would just be a shame for it to
>>> come out as a "work in progress" reference instead of an RFC.
>>> Maybe we can ask for the two RFCs to be published at the same
>>> time.
>> 
>> Agreed. I will rev the I-D as described (but with an
>> informational ref to your I-D), and will note the RFC-Ed about
>> this. -- However, my take is that this will be nevertheless the
>> case (draft-ietf-6man-ext-transmit will be published at the same
>> time or before oversized-header-chain).
> 

I have no problem with that option... However, the thing is that the
reference is not normative in nature (i.e., IMHO it would be
incorrect, as discussed with Brian). (please see the P.S., anyway).

> I agree that we should publish these two documents together.

+1 for this. Isn't there a way to request this without a normative ref?

P.S.: Please do let me know if you'd like me to proceed with a
normative ref... either way is fine with me...

Thanks!

Cheers,

---

From: Ole Troan <[email-masked]>
Date: Tue, 3 Sep 2013 13:22:27 +0200

Fernando,

> incorrect, as discussed with Brian). (please see the P.S., anyway).

  Extension Headers are defined in Section 4 of [RFC2460].
  As a result of [draft-ietf-6man-ext-transmit], [IANA-PROTO] provides
  a list of assigned Internet Protocol Numbers and designates which of
  those protocol numbers also represent extension headers.

I'm fine with this text.
I think the separation of extension headers and ULPs
that ext-transmit codifies is vital for implementing oversized-header chain.

could there be a reference to ext-transmit also in the terminology section?

> +1 for this. Isn't there a way to request this without a normative ref?

yes, we can do that. the authors just need to request that from the RFC editor.
http://www.rfc-editor.org/cluster_def.html

(I assume the shepherd or chairs count for that as well.)

> normative ref... either way is fine with me...

let's go with normative.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 03 Sep 2013 09:01:15 -0300

On 09/03/2013 08:22 AM, Ole Troan wrote:
>>> 
>>> I would prefer a normative reference to the ext-transmit
>>> document for the definition of extension headers.
>> 
>> I have no problem with that option... However, the thing is that
>> the reference is not normative in nature (i.e., IMHO it would be 
> Extension Headers are defined in Section 4 of [RFC2460]. As a
> result of [draft-ietf-6man-ext-transmit], [IANA-PROTO] provides a
> list of assigned Internet Protocol Numbers and designates which of 
> I'm fine with this text. I think the separation of extension
> headers and ULPs that ext-transmit codifies is vital for
> implementing oversized-header chain.
> 

The above para is meant for the Terminology section.

>> normative ref... either way is fine with me...

Ok. Please let me know if we're fine with the above change (para that
goes in the Terminology section + normative reference) and I'll rev
the I-D.

Thanks!

Cheers,

---

From: Ole Troan <[email-masked]>
Date: Tue, 3 Sep 2013 14:11:57 +0200

Fernando,

thanks, that's fine!

cheers,
Ole

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 3 Sep 2013 17:43:48 +0000

Brian,

I tend to agree. 

Maybe we could leave the draft alone and put something in the Shepherd's write-up reminding the IESG that this draft relies upon draft-ietf-6man-ext-transmit progressing first.
                                   Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian E Carpenter
> Sent: Saturday, August 31, 2013 9:29 PM
> To: Fernando Gont
> Cc: 6man
> Subject: Re: Definition of Extension Header in draft-ietf-6man-
> oversized-header-chain-05.txt (was Re: I-D Action: draft-ietf-6man-
> oversized-header-chain-05.txt)
> 
> Hi Fernando,
> 
> I'm biased, but I'd prefer the reference (your first suggestion),
> unless the ext-transmit draft gets stuck in the process, in which case
> you could make an editorial change later, even up to AUTH48.
> 
> BTW check the IANA URL too; I think you had a pointer to a .txt file,
> but these days IANA is .xml based.
> 
> Regards
>    Brian
> 
> On 01/09/2013 08:50, Fernando Gont wrote:
> > On 08/31/2013 04:58 PM, Brian E Carpenter wrote:
> >>> 3.  Terminology
> >>>
> >>>    For the purposes of this document, the terms Extension Header,
> Header
> >>>    Chain, First Fragment, and Upper-layer Header are used as
> follows:
> >>>
> >>>    Extension Header:
> >>>
> >>>       [IANA-PROTO] provides a list of assigned Internet Protocol
> Numbers
> >>>       and designates which of those protocol numbers also represent
> >>>       extension headers.
> >> The final clause is totally incorrect - the IANA list does not
> >> (today) identify extension headers. draft-ietf-6man-ext-transmit has
> >> the details in its IANA Considerations.
> >>
> >> Assuming draft-ietf-6man-ext-transmit is approved, this will change,
> >> but for that purpose you'd need a blocking (normative) reference to
> >> draft-ietf-6man-ext-transmit to guarantee the correct sequence of
> >> publication.
> >
> > I thought that's what we were intending (assuming
> > draft-ietf-6man-ext-transmit goes smoothly) -- but I realize we
> missed
> > the procedural piece of making sure of the correct sequence of
> > publication. So I guess possible paths are:
> >
> > 1) Changing the above paragraph to something along the lines of:
> >
> > (or something along these lines... please suggest alternative
> phrasing
> > if deemed appropriate)
> >
> > 2) Change the above paragraph to:
> >
> >    Extension Headers are defined in Section 4 of [RFC2460], and
> various
> >    extension headers have been specified in [RFC2460] itself and in
> >    other later documents.
> >
> > (which IMO would still be fine, since we don't really need to provide
> > the full list here)
> >
> > Thoughts?
> >
> > Thanks!
> >
> > Cheers,
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 3 Sep 2013 17:47:40 +0000

Please disregard my last message, below. I just read Ole's recommendation and am fine with it.

                                Ron

> Ronald Bonica
> Sent: Tuesday, September 03, 2013 1:44 PM
> To: Brian E Carpenter; Fernando Gont
> Cc: 6man
> Subject: RE: Definition of Extension Header in draft-ietf-6man-
> Maybe we could leave the draft alone and put something in the
> Shepherd's write-up reminding the IESG that this draft relies upon
> draft-ietf-6man-ext-transmit progressing first.
>                                    Ron
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Brian E Carpenter
> > >> (today) identify extension headers. draft-ietf-6man-ext-transmit
> > >> has the details in its IANA Considerations.
> > >>
> > >> Assuming draft-ietf-6man-ext-transmit is approved, this will
> > >> change, but for that purpose you'd need a blocking (normative)
> > >> reference to draft-ietf-6man-ext-transmit to guarantee the correct
> > >> sequence of publication.
> > >
> > >    a list of assigned Internet Protocol Numbers and designates
> which
> > of
> > > (which IMO would still be fine, since we don't really need to
> > > provide the full list here)
> > >
> > > Thoughts?
> > >
> > > Thanks!
> > >
> > > Cheers,