Subject: WG Review: IPv6 Maintenance (6man)

From: The IESG <[email-masked]>
Date: Fri, 11 Oct 2013 09:38:32 -0700

The IPv6 Maintenance (6man) working group in the Internet Area of the
IETF is undergoing rechartering. The IESG has not made any determination
yet. The following draft charter was submitted, and is provided for
informational purposes only. Please send your comments to the IESG
mailing list (iesg at ietf.org) by 2013-10-21.

IPv6 Maintenance (6man)
------------------------------------------------
Current Status: Active WG

Chairs:
  Robert Hinden <[email-masked]>
  Ole Troan <[email-masked]>

Assigned Area Director:
  Brian Haberman <[email-masked]>

Mailing list
  Address: [email-masked]
  To Subscribe: https://www.ietf.org/mailman/listinfo/ipv6
  Archive: http://www.ietf.org/mail-archive/web/ipv6

Charter:

The 6man working group is responsible for the maintenance, upkeep, and
advancement of the IPv6 protocol specifications and addressing
architecture. It is not chartered to develop major changes or additions
to the IPv6 specifications. The working group will address protocol
limitations/issues discovered during deployment and operation.  It will
also serve as a venue for discussing the proper location for working on
IPv6-related issues within the IETF.

6man is the design authority for extensions and modifications to the IPv6
protocol. The working group may at its discretion, review any document
extending or modifying the protocol, carried out in another working
group, and may determine that 6man working group consensus is needed
before any of those documents can progress for publication.

Milestones:
  Done     - Submit RH0 Deprecation specification to IESG as a Proposed
Standard
  Done     - Submit PPP Compression Negotiation specification to IESG as
a Proposed Standard
  Done     - Determine way forward for ULA-C specification
  Nov 2013 - Resolve open issues with "U/G" bits in Interface Identifiers
  Mar 2014 - Develop approach for IPv6 Fragmentation
  Mar 2014 - Develop approaches for IPv6 Extension Headers (Hop-by-Hop
and Destination)
  Jul 2014 - Advance IPv6 core specifications to Internet standard

---

From: Arturo Servin <[email-masked]>
Date: Sun, 13 Oct 2013 11:35:13 -0200

Would you expand a bit on this?

	And after the discussions in Berlin about fragmentation, the dates of
the milestones look a bit ambitious to me.

Regards,
as

On 10/11/13 2:38 PM, The IESG wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Oct 2013 15:02:44 +1300

>   Mar 2014 - Develop approach for IPv6 Fragmentation

Possibly ambitious, but it is the logical next step beyond
draft-ietf-6man-oversized-header-chain.

>   Mar 2014 - Develop approaches for IPv6 Extension Headers (Hop-by-Hop

Shouldn't the first step be to develop a problem statement, once the
current drafts relevant to this topic are done and dusted?

>   Jul 2014 - Advance IPv6 core specifications to Internet standard

That date is ambitious.

I think there's a missing goal, something like

 - Define relationship and boundary between DHCPv6-based and RA/ND-based
   host configuration mechanisms. (This is partly an operational topic, but
   it lies behind a whole bunch of discussions in various WGs).

     Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 15 Oct 2013 03:02:42 +0000

Hi, Dear all

> -----Original Message-----
> From: Brian E Carpenter [email-masked] [mailto:[email-masked]] On Behalf Of
>  - Define relationship and boundary between DHCPv6-based and
> RA/ND-based host configuration mechanisms. (This is partly an 
> operational topic, but it lies behind a whole bunch of discussions in various WGs).

[Bing] I support this topic. Personally, I've got involved into a specific issue on this topic, which is regarding the ND/DHCPv6 interaction on host configuration. 

More specifically, one example is the variation of the host behavior of interpreting the M/O flags. Different operating systems have followed different ways. This is because the M/O behaviors defined in current ND/SLAAC standards are ambiguous. This issue was firstly raised in [RFC5887] (See details in Section 5.1.1, the 6th&7th paragraph), and then identified as a gap in [RFC7010] (See Section 5.1). 
We also have raised a couple of times discussion in 6man, the most recent one was in IETF84 (http://www.ietf.org/proceedings/84/slides/slides-84-6man-3.pptx). 

There were not a few people participated in the discussion of the above issue, IIRC, the majority of them agreed the problem. So I think it would be good to if it could be added in the charter.

Best regards,
Bing

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 15 Oct 2013 05:52:28 +0000

> More specifically, one example is the variation of the host behavior of
> interpreting the M/O flags. Different operating systems have followed
> different ways. This is because the M/O behaviors defined in current
> ND/SLAAC standards are ambiguous. This issue was firstly raised in [RFC5887]
> (See details in Section 5.1.1, the 6th&7th paragraph), and then identified as a
> gap in [RFC7010] (See Section 5.1).
> We also have raised a couple of times discussion in 6man, the most recent
> one was in IETF84
> (http://www.ietf.org/proceedings/84/slides/slides-84-6man-3.pptx).

[Bing] Sorry, above is the former one, the most recent one is in IETF86: 
www.ietf.org/proceedings/86/slides/slides-86-6man-4.pdf

Best regards,
Bing