Subject: [sunset4] proposed charter change

From: Lee Howard <[email-masked]>
Date: Fri, 11 Apr 2014 16:47:53 -0400

At the London meeting, we discussed draft-george-ipv6-support-02.
There was strong support for updating the charter to include it as a work
item.

The RFC review might already fit within the gap analysis part of
the charter. Proposed charter addition:

Apr 2015 - Submit advice on IPv6 support within IETF work

Lee

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 14 Apr 2014 14:49:18 -0400

Lee,
 we, co-chairs, already(during last IETF week) filled in that milestone in the datatracker, however, since it has not been approved yet by the AD, you can't see it. Here is the view I see as wgchair:

Dec 2014	
IPv6 Support Within IETF work awaiting accept
draft-george-ipv6-support

(as you see, I was more optimistic than you for the delivery time...;-)

Marc.

Le 2014-04-11 à 16:47, Lee Howard <[email-masked]> a écrit :

> _______________________________________________
> sunset4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sunset4

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Apr 2014 13:56:41 -0500

>  we, co-chairs, already(during last IETF week) filled in that milestone in the datatracker, however, since it has not been approved yet by the AD, you can't see it. Here is the view I see as wgchai…

It's not been approved because (as the minutes reflect) this is not what we agreed to in the meeting.   We have to update the charter before taking on this document as a working group document.   This is too significant for me to just approve it as a new milestone.

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 14 Apr 2014 15:01:49 -0400

Le 2014-04-14 à 14:56, Ted Lemon <[email-masked]> a écrit :

> It's not been approved because (as the minutes reflect) this is not what we agreed to in the meeting.   We have to update the charter before taking on this document as a working group document.

if you mean changing the charter text, then I misunderstood.  I thought we were saying that by adding a milestone, we were "effectively" changing the charter. Which I think not what you wanted to say.  You want to work on a new text of the charter?

>   This is too significant for me to just approve it as a new milestone.

Marc.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Apr 2014 14:08:15 -0500

> if you mean changing the charter text, then I misunderstood.  I thought we were saying that by adding a milestone, we were "effectively" changing the charter. Which I think not what you wanted to s…

Milestones are orthogonal to the charter.  I could approve a milestone, and you could work on it, and that would be okay in theory, but this document needs a clear IETF consensus, so I don't want to do it that way.

I would replace the part from "Initial work items are:" down to the bottom with this:

Current work items are:

* NAT64 port allocation and address sharing methods involving
scenarios where an IPv6-only node is present (and NAT44, as it
overlaps NAT64 address sharing and port use). This may require a
description of the use of an existing protocol, the development
of extensions to an existing protocol, or the definition of an
entirely new protocol.

* Gap analysis of IPv4/IPv6 features to facilitate IPv4 sunsetting

* Provisioning methods to signal a dual-stack host to disable or
depreference the use of IPv4

* BCP recommending that except in unusual cases, new work in the IETF
  should either be stack-agnostic, or IPv6-only.

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 14 Apr 2014 15:44:17 -0400

> I would replace the part from "Initial work items are:" down to the bottom with this:

fine by me. (I would change "stack-agnostic" to "IP version-agnostic" but that is a detail).  

Do people in the wg disagree with Ted proposal?  

Marc.

---

From: Lee Howard <[email-masked]>
Date: Mon, 14 Apr 2014 17:02:50 -0400

On 4/14/14 3:08 PM, "Ted Lemon" <[email-masked]> wrote:

>> if you mean changing the charter text, then I misunderstood.  I thought
>>we were saying that by adding a milestone, we were "effectively"
>>changing the charter. Which I think not what you wanted to say.  You
>>want to work on a new text of the charter?
>
>Milestones are orthogonal to the charter.  I could approve a milestone,
>and you could work on it, and that would be okay in theory, but this
>document needs a clear IETF consensus, so I don't want to do it that way.
>
...
>  should either be stack-agnostic, or IPv6-only.

I can live with that.

It leaves the details of defining the "unusual cases" to the document
itself.

Lee

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 16 Apr 2014 16:53:16 +0000

> Apr 2015 - Submit advice on IPv6 support within IETF work

I’m OK with the charter addition. 

One thing that isn’t clear to me from the document is what the reporting mechanism is. Were I the AD, I would find myself looking up, for each working group, the counterpart to http://datatracker.ietf.org/doc/search/?name=v6ops&rfcs=on&activedrafts=on&sort= (which gives all RFCs and current Internet Drafts for a working group) and asking that working group to report on its RFCs and current Internet Drafts. I would then do a coverage check, and wonder to myself what to do with working groups that have been closed.

The alternative would be to send an email to each set of authors on RFCs. Wow...

And then, what comes back? One might hope that for a number of working groups, an email response to sunset4 might suffice. For example, in SAVI, IPv4 was treated as a solved problem; the only real question before the working group was source address validation for IPv6, and that being done in Switched Ethernet networks - Wifi, which is analogous but may have different dynamics internal to the switch domain, was not addressed. But I might expect that whoever spoke for SAVI might literally say as much in an email, leaving it to sunset4 to summarize that information as it chose. Or, if we literally are asking RFC Authors to review their documents, provide a wiki in which they can update their results.

I suspect we’d need some administrative support, in the form of the answer to the question “for each RFC sequenced 3100..present, what are the email addresses of the authors, and what working group did it come from?” Phil Nesser might not be available...

---

From: Lee Howard <[email-masked]>
Date: Mon, 21 Apr 2014 18:09:29 -0400

On 4/16/14 12:53 PM, "Fred Baker (fred)" <[email-masked]> wrote:
>
>One thing that isn¹t clear to me from the document is what the reporting
>mechanism is. Were I the AD, I would find myself looking up, for each
>working group, the counterpart to
>http://datatracker.ietf.org/doc/search/?name=v6ops&rfcs=on&activedrafts=on
>&sort= (which gives all RFCs and current Internet Drafts for a working
>group) and asking that working group to report on its RFCs and current
>Internet Drafts. I would then do a coverage check, and wonder to myself
>what to do with working groups that have been closed.
>
>And then, what comes back? One might hope that for a number of working
>groups, an email response to sunset4 might suffice. For example, in SAVI,
>IPv4 was treated as a solved problem; the only real question before the
>working group was source address validation for IPv6, and that being done
>in Switched Ethernet networks - Wifi, which is analogous but may have
>different dynamics internal to the switch domain, was not addressed. But
>I might expect that whoever spoke for SAVI might literally say as much in
>an email, leaving it to sunset4 to summarize that information as it
>chose. Or, if we literally are asking RFC Authors to review their
>documents, provide a wiki in which they can update their results.
>
>I suspect we¹d need some administrative support, in the form of the
>answer to the question ³for each RFC sequenced 3100..present, what are
>the email addresses of the authors, and what working group did it come
>from?² Phil Nesser might not be available...

We intentionally did not provide too much detail, because there are
several ways the work could be done.  I'd be happy to leave it up to the
IESG to figure out how to do it. Or we can provide them options, which
don't necessarily have to be in the document.  From what I understand, the
previous review was done under contract with somebody who was willing to
pay for the work; it would be great if another such benefactor were found.

Alternatively, ADs could volunteer some area participants, such as
Directorate members, to list all the RFCs and provide the review.  The
previous review was completed with the publication of a series of RFCs;
reviews-in-progress could be maintained as internet-drafts.  But I agree
that a wiki or similar resource would be better for updating state.

Lee