Subject: Adoption call of draft-gont-6man-deprecate-atomfrag-generation for 6MAN

From: Ole Troan <[email-masked]>
Date: Mon, 13 Oct 2014 08:30:18 +0200

All,

The authors have requested an adoption call for this document as a standards track document.

Please provide a view with reasons as to whether the WG should adopt this or not.

This message starts a one week 6MAN Working Group call on adopting:

	Title           : Deprecating the Generation of IPv6 Atomic Fragments
	Author(s)    : F. Gont, W. Liu
	Filename    : draft-gont-6man-deprecate-atomfrag-generation-00
	Pages        : 6
	Date          : 2014-08-19

http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00

The call ends on October 20th, 2014.

Regards,

Bob Hinden & Ole Trøan

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 13 Oct 2014 09:15:54 +0200 (CEST)

> Please provide a view with reasons as to whether the WG should adopt this or not.

I support that we're taking a good look at this problem.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Oct 2014 08:27:19 +1300

> I support that we're taking a good look at this problem.

Yes. This is (another) case where our standards allow bad things
to happen, so we should try to fix it, and I think this draft
heads in the direction of a fix.

   Brian

---

From: Tina TSOU <[email-masked]>
Date: Mon, 20 Oct 2014 13:35:55 +0000

Dear all,

I support adoption of this document as a WG item.

It addresses a concrete issue with the current specs, offering a straightforward mitigation.

Thank you,
Tina

On Oct 13, 2014, at 9:27 PM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

All,

The authors have requested an adoption call for this document as a
standards track document.

Please provide a view with reasons as to whether the WG should adopt
this or not.

  Brian

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

---

From: JF Tremblay <[email-masked]>
Date: Mon, 20 Oct 2014 16:04:08 -0400

> heads in the direction of a fix.

I second this, and support adoption of this document by the wg. 

Btw, is it usual to have a wg adoption call over one week only? Just wondering. 

-------------------
To the authors: 

The following sentence in section 3, page 3, struck me as weirdly constructed. 

 Once the attack packet has been fired, it
   will be the aforementioned routers themselves the ones dropping their
   own traffic.

Beside behing fairly hard to parse, I’m not sure it’s right. If only inbound ACLs are configured to drop atomic fragments, the packets might not get dropped locally, if this was the intended meaning.

JF

---

From: Ole Troan <[email-masked]>
Date: Tue, 21 Oct 2014 09:43:06 +0200

JF,

> Btw, is it usual to have a wg adoption call over one week only? Just wondering. 

the main question we're trying to get answered in an adoption call is "Is there strong working group support for working on the draft?". 

we often let the discussion run over the dead-line if required. and there is as you have seen ample opportunity to argue over the chair's judgement of what consensus is afterwards.

in this case we wanted to run through about 4 adoption calls in series, if others think one week is too short as well, I'm sure we can do two weeks calls in the future.

cheers,
Ole

---

From: Qiong <[email-masked]>
Date: Tue, 21 Oct 2014 18:38:41 +0800

Hi all,

I reviewed this draft and support adoption of this document as a wg draft.
Some comments below (editorial).
  Page 1, Abstract:
> The core IPv6 specification requires that when a host receives an
> ICMPv6 "Packet Too Big" message reporting a "Next-Hop MTU" smaller
> than 1280, the host includes a Fragment Header in all subsequent
 In IPv6, the corresponding field is called just "MTU".
  Page 2:
> Section 5 of [RFC2460] states that, when a host receives an ICMPv6
> "Packet Too Big" message [RFC4443] advertising a "Next-Hop MTU"
> smaller than 1280 (the minimum IPv6 MTU), the host is not required
> to
 Same as above.
 Page 3, Section 1:
> Section 6 formally
> updates RFC6145 such that it does not relies on the generation of
> IPv6 atomic fragments.
 Please replace "relies" with "rely".
 Page 6, Section 4:
> 3. ECMP routing [RFC2992] with more than one translator are employed
> for e.g., redundancy purposes
 Please replace "are" with "is".
 Page 11, Section 6:
> This approach allows Path MTU Discovery to operate end-to-end for
> paths whose MTU are not smaller than minimum IPv6 MTU of 1280 (which
> corresponds to MTU of 1260 in the IPv4 domain).
 Please replace "minimum IPv6 MTU" with "the minimum IPv6 MTU".

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/
<http://sourceforge.net/projects/laft6/>*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/
<http://sourceforge.net/projects/pcpportsetdemo/> *
===============================================