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

From: Timothy Winters <[email-masked]>
Date: Wed, 2 Sep 2015 15:02:53 -0400

Hi,

I wanted to respond to Ole's questions about atomic fragments being
tested.  Both IPv6 Ready and USGv6 require the generation of atomic
fragments based on the text in RFC 2460.

We've recently seen some Linux-based implementations that are failing to
perform atomic fragments based on this draft.

~Tim

On Thu, Aug 13, 2015 at 2:58 PM, Fernando Gont <[email-masked]>
wrote:

> 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:
> >> El 10/8/2015 7:15, "Ole Troan" <[email-masked]> escribió:
> >>>
> >>>
> >>> 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?
> >
> > because there is a cost to the community associated with publishing
> > an RFC.
>
> 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:
>
> 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.
>
> Should we ship?
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [email-masked]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>

-- 

Timothy Winters
UNH-IOL Senior Executive, Software and IP Networking
603-421-4987
IOL INTACT <https://www.iol.unh.edu/solutions/test-tools/intact>, an IPv6
test tool, helped participants verify products and prototypes at the CEA’s
IPv6 plugfest.
Read more at: http://bit.ly/1IOKePo

---

From: Fernando Gont <[email-masked]>
Date: Thu, 3 Sep 2015 21:56:02 -0300

> perform atomic fragments based on this draft.

That's yet another reason why just "silently removing the paragraph" is
not the most sensible thing to do, IMO.

Thanks,