Subject: Re: Moving draft-ietf-6man-deprecate-atomfrag-generation forward (Re: I-D Action: draft-ietf-6man-deprecate-atomfrag-generation-03.txt)

From: Tore Anderson <[email-masked]>
Date: Thu, 6 Aug 2015 13:06:37 +0200

Hi,

6145bis is now being discussed in v6ops. It incorporates one of the two
major changes implemented by this draft, by ensuring that a stateless
translator will not emit ICMPv6 PTBs with MTU < 1280.

However, 2460bis does *not* contain the other major change, i.e., it
does not remove the requirement for IPv6 nodes to handle such PTBs
with MTU < 1280 by emitting atomic fragments. See the last paragraph of
section 5 in draft-hinden-6man-rfc2460bis-00.

With that in mind, it would be good to have a clarification on how we
can proceed with this document. For what it's worth, I find Fernando's
argumentation below persuasive, and would support proceeding with
publishing it as a separate document that 2460bis in turn can
incorporate/refer to.

Tore

* Fernando Gont <[email-masked]>

> Hi, Ole,
> 
> On 07/13/2015 05:06 AM, Ole Troan wrote:
> [....]
> >> * It would seem to me that it would even make RFC2460bis go
> >> smoother if it simply incorporates changes that have already
> >> settled on RFCs. -- i.e., the changes would have already been
> >> reviewed by the IETF community, and RFC2460bis would just be
> >> "RFC2460+updates”.
> > 
> > yes, that’s the intention. only errata and updated-by documents. then
> > we can see if we can make an exception for the atomfrag-generation
> > paragraph. I would hope we didn’t have to publish that as an RFC,
> > just so that we could get the paragraph removed.
> 
> IMO, publishing this document is useful for a number of reasons:
> 
> 1) If you just omit the paragraph in RFC2460bis, you're not signaling
> existing implementations that they should stop generating atomic
> fragments. Most likely, existing implementations will not be updated.
> 
> 2) This document provides a rationale for the change. Unless one wants
> to incorporate the discussion/rationale in RFC2460bis (probably
> undesirable), this I-D can document the rationale, and RFC2460 just
> incorporate the update without much discussion and a reference to this
> I-D/RFC.
> 
> 3) Having RFC2460bis just incorporate errata and updating RFCs seems to
> be a smoother path, since all updates will have been vetted by the IETF
> community already.
> 
> 4) Given the current state of this document (around for a while, and
> stable), that RFC6145bis benefits both from the change and the
> rationale, and given the above considerations regarding RFC2460bis, and
> that it's unclear the timeframe of publication of RFC2460bis, I'd go on
> and publish this document as an RFC.
> 
> Thanks!
> 
> Cheers,

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Fri, 7 Aug 2015 06:13:00 +0000

Hi all,

I second to Tore here. IMHO, I think it is way better to progress this document and publish as an RFC, and have RFC2460bis eventually incorporate the corresponding changes and point to that RFC for a rationale for the change.

Regards,
Will 

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Tore Anderson
> Sent: Thursday, August 06, 2015 7:07 PM
> To: Fernando Gont
> Cc: [email-masked]; 6man WG
> Subject: Re: Moving draft-ietf-6man-deprecate-atomfrag-generation forward
> (Re: I-D Action: draft-ietf-6man-deprecate-atomfrag-generation-03.txt)
> Importance: High
> 
> Hi,
> 
> 6145bis is now being discussed in v6ops. It incorporates one of the two major
> changes implemented by this draft, by ensuring that a stateless translator will
> not emit ICMPv6 PTBs with MTU < 1280.
> 
> However, 2460bis does *not* contain the other major change, i.e., it does not
> remove the requirement for IPv6 nodes to handle such PTBs with MTU < 1280
> by emitting atomic fragments. See the last paragraph of section 5 in
> draft-hinden-6man-rfc2460bis-00.
> 
> With that in mind, it would be good to have a clarification on how we can
> proceed with this document. For what it's worth, I find Fernando's
> publishing it as a separate document that 2460bis in turn can incorporate/refer
> to.
> 
> Tore
> 
> > > yes, that’s the intention. only errata and updated-by documents.
> > > then we can see if we can make an exception for the
> > > atomfrag-generation paragraph. I would hope we didn’t have to
> > > publish that as an RFC, just so that we could get the paragraph removed.
> >
> > 3) Having RFC2460bis just incorporate errata and updating RFCs seems
> > to be a smoother path, since all updates will have been vetted by the
> > IETF community already.
> >
> > rationale, and given the above considerations regarding RFC2460bis,
> > and that it's unclear the timeframe of publication of RFC2460bis, I'd
> > go on and publish this document as an RFC.
> >
> > Thanks!
> >
> > Cheers,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Ole Troan <[email-masked]>
Date: Mon, 10 Aug 2015 12:15:05 +0200

Tore,

> publishing it as a separate document that 2460bis in turn can

if the only thing we need to do is to remove the offending paragraph in 2460bis, I think it is a waste of time having to publish a new RFC just to achieve that.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 10 Aug 2015 13:04:54 +0200

> El 10/8/2015 7:15, "Ole Troan" <[email-masked]> escribió:
> >
> >
> I've elaborated about this in a separate email.bIf you just delete the paragraph, chances are that implementations will not be updated. There has to be a clear signal, and the corresponding rationale (besides other things, noted in.my email, such as the timeframe for rfc2460bis, etc).

do we know what current implementations do?
I’m pretty sure that on IOS we ignored that paragraph and did not implement atomic fragment generation.
Tim, is this something you test for at IOL?

> So I think there's value in publishing this document "as is". Even for tye sake of rfc2460bis. So why not proceed with it?

because there is a cost to the community associated with publishing an RFC.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Aug 2015 20:58:08 +0200

Hi, Ole,

[I think I had responded to this one... or else it didn't make it to the
list.. so..]

On 08/10/2015 01:04 PM, Ole Troan wrote:
>>> if the only thing we need to do is to remove the offending
>>> paragraph in 2460bis, I think it is a waste of time having to
>>> publish a new RFC just to achieve that.
>> 
>> I've elaborated about this in a separate email.bIf you just delete
>> the paragraph, chances are that implementations will not be
>> updated. There has to be a clear signal, and the corresponding
>> rationale (besides other things, noted in.my email, such as the
>> timeframe for rfc2460bis, etc).
> 
> do we know what current implementations do? I’m pretty sure that on
> IOS we ignored that paragraph and did not implement atomic fragment
> generation. Tim, is this something you test for at IOL?

I've tested this myself. And part of the results are in Appendix A of
RFC6946 (<https://tools.ietf.org/html/rfc6946#appendix-A>). I'd expect
that such table is enough of a datapoint...

>> So I think there's value in publishing this document "as is". Even
>> for tye sake of rfc2460bis. So why not proceed with it?
> 

If the cost is examining the change and the rationale, one way or
another it has to be done anyway.

As I noted in a previous email:

Should we ship?

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