Subject: Revised 6MAN Charter

From: Brian Haberman <[email-masked]>
Date: Thu, 16 Aug 2007 06:35:54 -0400

All,
     I have revised the charter for the proposed IPv6 maintenance WG
based on comments received.  Please review.

Regards,
Brian

IPv6 Maintenance Working Group (6man)
------------------------------------------------------------------------

Chair(s):

     Robert Hinden <[email-masked]>
     Brian Haberman <[email-masked]>

Internet Area Director(s):

     Jari Arkko <[email-masked]>
     Mark Townsley <[email-masked]>

Internet Area Advisor:

     Jari Arkko <[email-masked]>

Mailing Lists: [email-masked]

Description of Working Group:

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.

The working group's work items are as follows:

     o Shepherd completion of standardization of RA Flags Option
     o Shepherd completion of standardization of the RH0 Deprecation document
     o Complete standardization of IPv6 over PPP Compression Negotiation as a Proposed Standard
     o Complete work on Centrally Allocated Unique Local Addresses (ULA-C)

All new work items not listed above require the approval of the working
group and IESG before they will be taken on by the working group.

Goals and Milestones:

Oct 2007     Submit RH0 Deprecation specification to IESG as a Proposed Standard
Jan 2008     Submit PPP Compression Negotiation specification to IESG as a Proposed Standard
Mar 2008     Determine way forward for ULA-C specification

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

---

From: Tim Chown <[email-masked]>
Date: Mon, 20 Aug 2007 11:54:29 +0100

This looks OK to me.

One warm ipv6 wg topic at present that may (or may not) need adding is 
the resurgence of the issues discussed in Thomas Narten's 3177bis draft
(http://tools.ietf.org/html/draft-narten-ipv6-3177bis-48boundary-02)
which I think has expired?

Or is this being left solely as an RIR issue?

Also, could the cahirs confirm the final status of the existing eight WG
drafts as listed at:
http://www.ietf.org/html.charters/ipv6-charter.html

Four of these aren't mentioned in the revised charter; are they
expected to complete before 6MAN forms?

Tim

-- 
Tim

---

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Aug 2007 15:26:54 +0300

> expected to complete before 6MAN forms?

http://tools.ietf.org/wg/ipv6/ gives the status of the various items.
Basically, anything that is RFC Editor's queue need not be
listed any more. Some rechartering efforts have ignored
documents in IESG Processing stage too, because it can be
assumed that the documents get approved before the charter.

Jari

---

From: Tim Chown <[email-masked]>
Date: Mon, 20 Aug 2007 14:07:48 +0100

> assumed that the documents get approved before the charter.

Thanks Jari, in which case all looks well... the RFC Editor Queue drafts
were not mentioned, but as you say these should be approved before 6MAN
becomes active.

RFC-Editor's Queue:
draft-ietf-ipv6-2461bis-11
draft-ietf-ipv6-over-ppp-v2-03
draft-ietf-ipv6-privacy-addrs-v2-05
draft-ietf-ipv6-rfc2462bis-08

-- 
Tim

---

From: Brian Haberman <[email-masked]>
Date: Mon, 20 Aug 2007 13:28:51 -0400

> draft-ietf-ipv6-rfc2462bis-08

Tim,
      Yes, I intentionally left documents in the RFC Editor's Queue out 
of the 6MAN charter.

Regards,
Brian

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 20 Aug 2007 15:34:51 -0500

Hi Brian,

One of the tasks that the 6MAN WG is chartered for is : " Shepherd
completion of standardization of RA Flags Option"

Will this WG also standardize any new flags or options for the RA that are
currently being discussed?
The question arises from the work on specifying a flag/option in the RA for
indicating Proxy MIP6 (PMIP6) support or capability in the network (I-D:
draft-damic-netlmm-pmip6-ind-discover-01)

-Raj

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 20 Aug 2007 18:17:17 -0400

Hi Raj,

> draft-damic-netlmm-pmip6-ind-discover-01)

My gut feel it that it should not be standardized in 6man. The WG that 
is interested in the flag (in this case, netlmm) must standardize it. 
But the document needs to end up updating 2461 bis (aka 4861).

Cheers
Suresh

---

From: Jari Arkko <[email-masked]>
Date: Tue, 21 Aug 2007 07:30:04 +0300

I also believe that the PMIP capability mechanism is something
that should come out of the discussions in NETLMM. Of course,
the IPv6 experts need to be consulted.

Jari

---

From: David Malone <[email-masked]>
Date: Tue, 21 Aug 2007 11:15:08 +0100

> (http://tools.ietf.org/html/draft-narten-ipv6-3177bis-48boundary-02)

I note that the IPv6 tools.ietf.org seems to be down or inaccessable
since late last week. A nearby hop is returning no route to host
and address inaccessable messages. I tried mailing Kurt, but I
haven't heard back yet.

	David.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 21 Aug 2007 13:57:14 +0300

It works for me, but only in v4. Some routing issue in v6
side. Ccing Henrik who runs these sites.

Jari

---

From: Ignatios Souvatzis <[email-masked]>
Date: Tue, 21 Aug 2007 16:48:42 +0200

> side. Ccing Henrik who runs these sites.

traceroute to tools.ietf.org (2001:698:9:31:214:22ff:fe21:bb), 30 hops max, 60 byte packets
 1  exp (2001:638:403:5050:2d0:b7ff:fe75:c02c)  5.680 ms  0.854 ms  0.767 ms
 2  2001:638:403:f01::1  4.253 ms  2.294 ms  2.286 ms

[...]

12  2001:698:9:2:208:21ff:fe87:3480  28.866 ms  27.888 ms !H 
13  * 2001:698:9:2:208:21ff:fe87:3480  28.857 ms  27.453 ms !H
14  2001:698:9:2:208:21ff:fe87:3480  3139.250 ms !A *  3025.377 ms !A

so some sort of problem near the destination host.

	-is