Subject: [v6ops] How to divide v6ops

From: Fred Baker <[email-masked]>
Date: Thu, 18 Aug 2011 11:47:32 -0700

Folks:

I spent some time on the way home from IETF-81 trying to tease the v6ops charter into two working groups.

One, which continues to be called "IPv6 Operations (v6ops)", is is about IPv6 and the IPv6 component of dual stack networks. The other I am calling "IPv4 Operations (v4ops)" to play up the dualism; this one is about IPv4 and the IPv4 component of dual stack networks. There will be crossover issues that could fall in either category; one hopes that the operators will entertain such discussions in either working group.

I include two proposed charters and a diff between them. It may be most instructive to start from the diff. I would appreciate your thoughts and markups.

If there is general buy-in here and the IESG agrees, we create a [email-masked] list and invite people on v6ops@ to join it. We then divide the documents (of which we now have ~40) between the two working groups and ask the authors of the obvious subset to repost as draft-*-v4ops-*.txt. A quick hash of the current set divides them more-or-less evenly.

For continuity, I have offered to chair v4ops with a co-chair from an operator that is concerned with v4/v6 transition issues to be chosen by Ron; I would continue to co-chair v6ops with Joel. That will likely change over time, of course. At IETF 82, I would suggest that we have two successive days with essentially four hour blocks (eg, two 2-hour meetings), one for v6ops and one for v4ops, to make it easiest for the operators to attend both sets of meetings. That both gives us more time to hold the relevant discussions and a better organizing principle. From there, we can determine future plans.

Fred

---

From: Tina TSOU <[email-masked]>
Date: Thu, 18 Aug 2011 21:39:19 +0000

Fred,
This reminds me the v4tov6transition (v4v6tran) work effort since Maastricht meeting.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Thursday, August 18, 2011 11:48 AM
To: IPv6 Operations
Cc: Ron Bonica
Subject: [v6ops] How to divide v6ops

Folks:

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Aug 2011 10:06:30 +1200

Hi Fred,

Will this reduce the total workload and/or reduce cross-posting?
I have some doubts, since it seems likely that there will be
crossover issues all the time. Nevertheless, dividing the
workload does seem like a reasonable principle. However, it's
only when we see a full list of the drafts to be assigned to the
new WG that we can really see if it will work out.

I don't like the name "v4ops". It seems somewhat contradictory
to draft-george-ipv6-support, although the proposed charter is
completely in line with that draft. Ideally, we'd call it
"legacy-ip-ops" but that isn't possible, so how about "v46ops"?

Regards
   Brian Carpenter

On 2011-08-19 06:47, Fred Baker wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Arturo Servin <[email-masked]>
Date: Thu, 18 Aug 2011 19:34:04 -0300

> Will this reduce the total workload and/or reduce cross-posting?

	I think it would do exactly the opposite.

> "legacy-ip-ops" but that isn't possible, so how about "v46ops"?

Regards,
/as

---

From: Fred Baker <[email-masked]>
Date: Thu, 18 Aug 2011 15:36:21 -0700

> "legacy-ip-ops" but that isn't possible, so how about "v46ops"?

My thought, which I'm not stuck on but is what I'm thinking right now, is that this is actually not very much about anything with a "6" in it. I'm in favor of pushing IPv6 as a technology, but...

It's about the fact that networks that are deploying IPv6 still have to stay in business, and as a result have v4 networks that have to stay running until a certain percentage of their access customers have upgraded CPEs, edge networks, and hosts. Host upgrade is a limited timeframe problem, given that people buy new ones at some rate. CPEs etc can be another discussion; if I have a working CPE, why do I spend $$ to change it? It's in the ISP's interest for them to all go spend that money; I doubt that the average consumer will see it as in their interest also.

Since Tina brought it up, let me comment on how this differs from v4v6tran. It differs in that it is only partially about transition issues or explaining to operators that have completely ignored IPv6 for 15 years and gotten no education the issues brought up in v4v6tran:

   o  How to decide the IPv6 address architecture in the network?
   o  What is the recommended prefix length for a large operator?
   o  What is the recommended prefix length for a medium operator?
   o  What is the recommended prefix length to hand out to customers?
   o  What is the recommended longest prefix length an operator should
      accept from customers?
   o  If privacy is a concern and an operator wants to use ULA in the
      network, what are the guidelines?
   o  How to deploy an IPv4 access network over an IPv6 core network?
   o  How to deploy an IPv6 access network over an IPv4 core network?
   o  Under what considerations, IS-IS should be used?
   o  Under what considerations, OSPFv3 should be used?
   o  What is the longest prefix to be allowed for peering?

and so on. Those are, as the working group pointed out at IETF-79 with very few punches pulled, *NOG questions or "go take one of the many fine courses on the topic".

And it is not at all about introducing someone's latest and greatest tweak on how to put an IPv6 packet into a tunnel, put an IPv4 packet into a tunnel, or slice and dice a port number, unless we're talking about operational experience with deployed technologies.

It is about operating the IPv4 side of a dual stack network. CGN, a+p, and all that.

Attached I have a spreadsheet (csv format) in which I tried to classify where I thought existing documents might go. No comment on whether the working group should actually be working on the draft; my question was "if someone sent in this draft as a -00, which working group might they choose and why". I might obviously be wrong. But it's on the basis of this that I said that the breakout was in the neighborhood of even.

---

From: Tina TSOU <[email-masked]>
Date: Thu, 18 Aug 2011 22:49:13 +0000

Fred,
The questions we listed below were just temporary appear in some of the v4v6tran discussions.
I believe the v4v6tran motivation is pretty much in line with you, "operating the IPv4 side of a dual stack network", and transition to IPv6.

Here is the framework I-D for v4v6tran.
https://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6tran-framework/
Framework for IP Version Transition Scenarios

I don't think it is just *NOG issues.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
http://www.huawei.com/en/solutions/expand-broadband/hw-092950-ipv6.htm

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Thursday, August 18, 2011 3:36 PM
To: Brian E Carpenter
Cc: IPv6 Operations; Ron Bonica
Subject: Re: [v6ops] How to divide v6ops

On Aug 18, 2011, at 3:06 PM, Brian E Carpenter wrote:

> I have some doubts, since it seems likely that there will be crossover 
> issues all the time. Nevertheless, dividing the workload does seem 
> like a reasonable principle. However, it's only when we see a full 
> list of the drafts to be assigned to the new WG that we can really see 
> if it will work out.
> 
> I don't like the name "v4ops". It seems somewhat contradictory to 
> draft-george-ipv6-support, although the proposed charter is completely 
> in line with that draft. Ideally, we'd call it "legacy-ip-ops" but 
> that isn't possible, so how about "v46ops"?

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 18 Aug 2011 16:23:12 -0700

>        I think it would do exactly the opposite.

+1 ... this may just be my knee jerk reaction to change.

It's unclear to me who benefits from this.... but this kinda sounds like
what behave is looking for as it attempts to wind down (on list response
seems to opppose behave shutting down)

I preffer having one community focused on moving v6 forward with ipv4 in
mind ....instead of the v4 life support group and the v6ops group with lots
of cross posting

Cb
> >> One, which continues to be called "IPv6 Operations (v6ops)", is is
about IPv6 and the IPv6 component of dual stack networks. The other I am
calling "IPv4 Operations (v4ops)" to play up the dualism; this one is about
IPv4 and the IPv4 component of dual stack networks. There will be crossover
issues that could fall in either category; one hopes that the operators will
entertain such discussions in either working group.
> >>
> >> I include two proposed charters and a diff between them. It may be most
instructive to start from the diff. I would appreciate your thoughts and
markups.
> >>
> >> If there is general buy-in here and the IESG agrees, we create a
[email-masked] list and invite people on v6ops@ to join it. We then divide
the documents (of which we now have ~40) between the two working groups and
ask the authors of the obvious subset to repost as draft-*-v4ops-*.txt. A
quick hash of the current set divides them more-or-less evenly.
> >>
> >> For continuity, I have offered to chair v4ops with a co-chair from an
operator that is concerned with v4/v6 transition issues to be chosen by Ron;
I would continue to co-chair v6ops with Joel. That will likely change over
time, of course. At IETF 82, I would suggest that we have two successive
days with essentially four hour blocks (eg, two 2-hour meetings), one for
v6ops and one for v4ops, to make it easiest for the operators to attend both
sets of meetings. That both gives us more time to hold the relevant
discussions and a better organizing principle. From there, we can determine
future plans.

---

From: Keith Moore <[email-masked]>
Date: Thu, 18 Aug 2011 22:37:21 -0400

It's pretty clear to me that v6ops is overloaded with work.  Though of course, splitting the group into two groups that contain most of the same people won't really help the load.  It might create the illusion of less load, but the principal resource constraint would still be there.

So the first thing I'd recommend is triage - sort the work items into urgent, necessary, and nonessential.  And I'd strongly recommend that at least the nonessential work and maybe some of the necessary work get pursued elsewhere (other WGs when appropriate, otherwise as individual submissions, or abandon as the authors see fit).  Newly proposed work needs to be subjected to the same criteria - not "does the group want to adopt this as a work item?" but "is this work urgent, not urgent but still necessary, or nonessential?"

Keith

On Aug 18, 2011, at 2:47 PM, Fred Baker wrote:

> <charter-diff.html><v6ops-charter.txt><v4ops-charter.txt>_______________________________________________
> v6ops mailing list
> [email-masked]

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 18 Aug 2011 19:42:12 -0700

On Aug 18, 2011 7:37 PM, "Keith Moore" <[email-masked]> wrote:
>
> It's pretty clear to me that v6ops is overloaded with work.  Though of
course, splitting the group into two groups that contain most of the same
people won't really help the load.  It might create the illusion of less
load, but the principal resource constraint would still be there.
>
> So the first thing I'd recommend is triage - sort the work items into
urgent, necessary, and nonessential.  And I'd strongly recommend that at
least the nonessential work and maybe some of the necessary work get pursued
elsewhere (other WGs when appropriate, otherwise as individual submissions,
or abandon as the authors see fit).  Newly proposed work needs to be
subjected to the same criteria - not "does the group want to adopt this as a
work item?" but "is this work urgent, not urgent but still necessary, or
nonessential?"
> Keith

This sounds smart to me.

Cb

> > One, which continues to be called "IPv6 Operations (v6ops)", is is about
IPv6 and the IPv6 component of dual stack networks. The other I am calling
"IPv4 Operations (v4ops)" to play up the dualism; this one is about IPv4 and
the IPv4 component of dual stack networks. There will be crossover issues
that could fall in either category; one hopes that the operators will
entertain such discussions in either working group.

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 19 Aug 2011 06:41:39 +0000

> "legacy-ip-ops" but that isn't possible, so how about "v46ops"?

Support Brian's concern. We are talking about closing behave WG in order to give the world the right signal: v4 should be stopped, no more efforts will be put on v4. The name of "v4ops" will give out the opposite message.

Sheng
 
> about IPv6 and the IPv6 component of dual stack networks. The other I
> am calling "IPv4 Operations (v4ops)" to play up the dualism; this one
> is about IPv4 and the IPv4 component of dual stack networks. There will
> be crossover issues that could fall in either category; one hopes that
> the operators will entertain such discussions in either working group.
> >
> > I include two proposed charters and a diff between them. It may be
> most instructive to start from the diff. I would appreciate your
> thoughts and markups.
> >
> [email-masked] list and invite people on v6ops@ to join it. We then
> divide the documents (of which we now have ~40) between the two working
> groups and ask the authors of the obvious subset to repost as draft-*-
> v4ops-*.txt. A quick hash of the current set divides them more-or-less
> evenly.
> >
> operator that is concerned with v4/v6 transition issues to be chosen by
> Ron; I would continue to co-chair v6ops with Joel. That will likely
> change over time, of course. At IETF 82, I would suggest that we have
> two successive days with essentially four hour blocks (eg, two 2-hour
> meetings), one for v6ops and one for v4ops, to make it easiest for the
> operators to attend both sets of meetings. That both gives us more time
> to hold the relevant discussions and a better organizing principle.
> From there, we can determine future plans.
> >
> > Fred
> >
> >
> >

---

From: Randy Bush <[email-masked]>
Date: Fri, 19 Aug 2011 06:18:26 -0400

> I prefer having one community focused on moving v6 forward with ipv4
> in mind ....instead of the v4 life support group and the v6ops group
> with lots of cross posting

agree.

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 19 Aug 2011 06:23:42 -0400

to amplify.  we all have to live in a world with ipv4 and, if we are
lucky, ipv6.  and they interact.  pretending otherwise is a fantasy
around which i can not wrap my head.  as operators, we have a set of
problems that need to be solved in concert, and almost none of the hard
ones are divisible.

randy

---

From: "George, Wesley" <[email-masked]>
Date: Fri, 19 Aug 2011 09:49:48 -0400

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Thursday, August 18, 2011 6:36 PM

On Aug 18, 2011, at 3:06 PM, Brian E Carpenter wrote:

> crossover issues all the time.
WEG] I share this concern. This WG's workload problem is not solved by divide and conquer unless it's very carefully done. I think it would be better solved by a more focused charter for this WG that allows us to direct more work to either the general ops area or to the individual submission stream (or the bit bucket). So I support a charter change (as I stated in http://www.ietf.org/mail-archive/web/v6ops/current/msg09975.html), but likely not in the interest of splitting the group.
<snip>
It's about the fact that networks that are deploying IPv6 still have to stay in business, and as a result have v4 networks that have to stay running until a certain percentage of their access customers have upgraded CPEs, edge networks, and hosts. <snip>
WEG] while this is true, with the exception of address availability constraints, that's been the case for years. We already have a group to deal with general IPv4 operational issues- OpsAWG. An IPv4 network that happens to be dual-stack is operated pretty much the same way as an IPv4 network that isn't, so I don't support making a distinction. What you're actually talking about is IPv4 extension, and that's a space that IMO has been well-worn, between Behave, this group, and softwires.

Since Tina brought it up, let me comment on how this differs from v4v6tran. It differs in that it is only partially about transition issues or explaining to operators that have completely ignored IPv6 for 15 years and gotten no education the issues brought up in v4v6tran:
<snip> Those are, as the working group pointed out at IETF-79 with very few punches pulled, *NOG questions or "go take one of the many fine courses on the topic".
WEG] Agree. The proposal for v4v6tran was flawed. But...
And it is not at all about introducing someone's latest and greatest tweak on how to put an IPv6 packet into a tunnel, put an IPv4 packet into a tunnel, or slice and dice a port number, unless we're talking about operational experience with deployed technologies.
WEG] I think that this is really the decision point: Either we need a new WG (which probably should be called v4v6tran) that is explicitly chartered to deal with IPv4 transition and extension issues in operational networks because there is still a good bit of work to be done there, or consensus is that we are at a point where we should probably just call IPv4 transition and extension work complete. If it's believed to be complete, the burden of proof for new flavors and tweaks is to show why the existing solutions fundamentally won't work in such a way that it's applicable as more than a one-off. Personally, I think it's done, at least until we have significant deployment experiences to examine.
It is about operating the IPv4 side of a dual stack network. CGN, a+p, and all that.

WEG] No, that is about operating the IPv4 side of a network without adequate IPv4 resources, and that is far different than your proposed charter changes.
Wes George

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "t.petch" <[email-masked]>
Date: Fri, 19 Aug 2011 17:54:45 +0200

---- Original Message -----
From: "Fred Baker" <[email-masked]>
To: "IPv6 Operations" <[email-masked]>
Cc: "Ron Bonica" <[email-masked]>
Sent: Thursday, August 18, 2011 8:47 PM

I spent some time on the way home from IETF-81 trying to tease the v6ops charter
into two working groups.

One, which continues to be called "IPv6 Operations (v6ops)", is is about IPv6
and the IPv6 component of dual stack networks. The other I am calling "IPv4
Operations (v4ops)" to play up the dualism; this one is about IPv4 and the IPv4
component of dual stack networks. There will be crossover issues that could fall
in either category; one hopes that the operators will entertain such discussions
in either working group.

If there is general buy-in here and the IESG agrees, we create a [email-masked]
list and invite people on v6ops@ to join it. We then divide the documents (of
which we now have ~40) between the two working groups and ask the authors of the
obvious subset to repost as draft-*-v4ops-*.txt. A quick hash of the current set
divides them more-or-less evenly.

<tp>
Fred

~40 documents sounds a lot, but I see only 9 draft-ietf-v6ops* of which one is
dead, two are in the RFC Editor queue, two are with the IESG leaving only four
documents active with the WG.

There are 32 individual submissions listed on the charter page but I would not
expect many of those to take up much time - eg those on 'Experiences ...' should
either be published or forgotten.

What I see on the v6ops list is intense discussion, more than any other list I
subscribe to, about, mostly, one topic at a time, with no clear sense of where
this is going.  And my impression is that the most difficult discussions are not
really v6ops at all, that is there is something that does not work, or does not
work well, and the solution could be a protocol change; in which case, punt it
to 6man, make them do more, in looking at a protocol solution for an operational
problem.

Tom Petch
</tp>

For continuity, I have offered to chair v4ops with a co-chair from an operator
that is concerned with v4/v6 transition issues to be chosen by Ron; I would
continue to co-chair v6ops with Joel. That will likely change over time, of
course. At IETF 82, I would suggest that we have two successive days with
essentially four hour blocks (eg, two 2-hour meetings), one for v6ops and one
for v4ops, to make it easiest for the operators to attend both sets of meetings.
That both gives us more time to hold the relevant discussions and a better
organizing principle. From there, we can determine future plans.

Fred

--------------------------------------------------------------------------------

> Description of Working Group
>
> The global deployment of IPv6 is underway, creating an IPv4/IPv6
> Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks
> and nodes. This deployment must be properly handled to avoid the
> division of the Internet into separate IPv4 and IPv6 networks while
> ensuring addressing and connectivity for all IPv4 and IPv6 nodes.
>
> The IPv6 Operations Working Group (v6ops) develops guidelines for
> the operation of a shared IPv4/IPv6 Internet and provides operational
> guidance on deployment of IPv6 into existing IPv4-only networks,
> deployment of new IPv6-only networks, and the general operation of
> IPv6 networks.
>
> The main focus of the IPv6 Operations WG is to look at the current
> and expected operational issues in the operation of IPv6 networks.
>
> The goals of the IPv6 Operations Working Group are:
>
> 1. Solicit input from network operators and users to identify
> operational issues in IPv6 networks or the IPv6 component of shared
> IPv4/IPv6 networks, and determine solutions or workarounds to those
> issues. These issues will be documented in Informational or BCP
> RFCs, or in Internet-Drafts.
>
> This work should primarily be conducted by those areas and WGs which
> are responsible and best fit to analyze these problems, but IPv6
> Operations may also cooperate in focusing such work.
>
> 2. Publish Informational or BCP RFCs that identify potential security
> risks in the operation of IPv6 networks or the IPv6 component of
> shared IPv4/IPv6 networks, and document operational practices to
> eliminate or mitigate those risks.
>
> This work will be done in cooperation with the Security area and
> other relevant areas or Working Groups.
>
> 3. As a particular instance of (1) and (2), provide feedback to the
> IPv6 Maintanence WG regarding portions of the IPv6 specifications
> that cause, or are likely to cause, operational or security concerns,
> and work with the IPv6 WG to resolve those concerns. This feedback
> will be published in Internet-Drafts or RFCs.
>
> 4. Publish Informational or BCP RFCs that identify and analyze
> solutions for deploying IPv6 within common network environments,
> such as ISP Networks, Enterprise Networks, Unmanaged Networks
> (Home/Small Office), and Cellular Networks.
>
> These documents should serve as useful guides to network operators
> and users on strategies for IPv6 deployment within their existing
> IPv4 networks, as well as in new network installations.
>
> These documents should not be normative guides for IPv6 operation,
> nor are they about describing things of interest to only isolated
> operators.  The primary intent is to identify and specify approaches
> that multiple operators find useful.
>
> IPv6 operational and deployment issues with specific protocols or
> technologies (such as Applications, Transport Protocols, Routing
> Protocols, DNS or Sub-IP Protocols) are the primary responsibility
> of the Groups or areas responsible for those protocols or technologies.
> However, the IPv6 Operations WG may provide input to those areas/Groups,
> as needed, and cooperate with those areas/Groups in reviewing
> solutions to IPv6 operational and deployment problems.
>
> Work items within this scope will be adopted by the WG only if there
> is a substantial expression of interest from the community and if
> the work clearly does not fit elsewhere in the IETF.
>
> There must be a continuous expression of interest for the WG to
> work on a particular work item. If there is no longer sufficient
> interest in the WG in a work item, the item may be removed from the
> list of WG items.
>
> Specification of protocols or transition mechanisms is out of scope
> of the WG.
>

--------------------------------------------------------------------------------

> Description of Working Group
>
> The global deployment of IPv6 is underway, creating an IPv4/IPv6
> Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks
> and nodes. This deployment must be properly handled to avoid the
> division of the Internet into separate IPv4 and IPv6 networks while
> ensuring addressing and connectivity for all IPv4 and IPv6 nodes.
>
> The IPv4 Operations Working Group (v4ops) develops guidelines for
> the operation of a shared IPv4/IPv6 Internet and provides operational
> guidance on the use of IPv4 and IPv4/IPv6 transition mechanisms in
> IPv4/IPv6 networks.
>
> The main focus of the IPv4 Operations WG is to look at the current
> and expected operational issues in the operation of IPv4 networks.
>
> The goals of the IPv4 Operations Working Group are:
>
> 1. Solicit input from network operators and users to identify
> operational issues in IPv4 networks or the IPv4 component of shared
> IPv4/IPv6 networks, and determine solutions or workarounds to those
> issues. These issues will be documented in Informational or BCP
> RFCs, or in Internet-Drafts.
>
> This work should primarily be conducted by those areas and WGs which
> are responsible and best fit to analyze these problems, but IPv4
> Operations may also cooperate in focusing such work.
>
> 2. Publish Informational or BCP RFCs that identify potential security
> risks in the operation of IPv4 networks or the IPv4 component of
> shared IPv4/IPv6 networks, and document operational practices to
> eliminate or mitigate those risks.
>
> This work will be done in cooperation with the Security area and
> other relevant areas or Working Groups.
>
> 3. As a particular instance of (1) and (2), provide feedback to the
> Internet Area regarding portions of the IPv4 specifications that
> cause, or are likely to cause, operational or security concerns,
> and work with the Internet Area to resolve those concerns. This
> feedback will be published in Internet-Drafts or RFCs.
>
> 4. Publish Informational or BCP RFCs that identify and analyze
> solutions for IPv4-related issues within common network environments,
> such as ISP Networks, Enterprise Networks, Unmanaged Networks
> (Home/Small Office), and Cellular Networks.
>
> These documents should serve as useful guides to IPv4 network
> operators and users.
>
> These documents should not be normative guides for IPv4 operation,
> nor are they about describing things of interest to only isolated
> operators.  The primary intent is to identify and specify approaches
> that multiple operators find useful.
>
> IPv4 operational and deployment issues with specific protocols or
> technologies (such as Applications, Transport Protocols, Routing
> Protocols, DNS or Sub-IP Protocols) are the primary responsibility
> of the Groups or areas responsible for those protocols or technologies.
> However, the IPv4 Operations WG may provide input to those areas/Groups,
> as needed, and cooperate with those areas/Groups in reviewing
> solutions to IPv4 operational and deployment problems.
>
> Work items within this scope will be adopted by the WG only if there
> is a substantial expression of interest from the community and if
> the work clearly does not fit elsewhere in the IETF.
>
> There must be a continuous expression of interest for the WG to
> work on a particular work item. If there is no longer sufficient
> interest in the WG in a work item, the item may be removed from the
> list of WG items.
>
> Specification of protocols or transition mechanisms is out of scope
> of the WG.
>

---

From: Chris Donley <[email-masked]>
Date: Fri, 19 Aug 2011 14:07:22 -0600

I think there is a need for v4 coexstence/transition work, along what you
are proposing:
* How to deploy CGNs/other transition technologies with v4 components
* transition technology experiences
* How do we do CGN logging? What format do we use for the messages?
* NAT444, 6to4, a+p issues, etc.

With the proposed BEHAVE shut down, there isn't a clear place to take this
work - v6ops, softwires, 6man, intarea, homenet, and opsarea all seem to
fit pieces of it.  I believe that this work would benefit from being in
its own wg.  However, I agree with others that v4ops is perhaps not the
right name.  Coexistence Ops (co-ops)?  Also, I think that the charter
should be tightened (per draft-george and other comments on the list) to
focus on IPv4/IPv6 transition/coexistence operational and security issues,
and not on general IPv4 network/security operations.

Chris

On 8/18/11 4:36 PM, "Fred Baker" <[email-masked]> wrote:

>My thought, which I'm not stuck on but is what I'm thinking right now, is
>that this is actually not very much about anything with a "6" in it. I'm
>in favor of pushing IPv6 as a technology, but...
>
>It's about the fact that networks that are deploying IPv6 still have to
>stay in business, and as a result have v4 networks that have to stay
>running until a certain percentage of their access customers have
>upgraded CPEs, edge networks, and hosts. Host upgrade is a limited
>timeframe problem, given that people buy new ones at some rate. CPEs etc
>can be another discussion; if I have a working CPE, why do I spend $$ to
>change it? It's in the ISP's interest for them to all go spend that
>money; I doubt that the average consumer will see it as in their interest
>also.
>
>Since Tina brought it up, let me comment on how this differs from
>v4v6tran. It differs in that it is only partially about transition issues
>or explaining to operators that have completely ignored IPv6 for 15 years
>and gotten no education the issues brought up in v4v6tran:
>
>and so on. Those are, as the working group pointed out at IETF-79 with
>very few punches pulled, *NOG questions or "go take one of the many fine
>courses on the topic".
>
>And it is not at all about introducing someone's latest and greatest
>tweak on how to put an IPv6 packet into a tunnel, put an IPv4 packet into
>a tunnel, or slice and dice a port number, unless we're talking about
>operational experience with deployed technologies.
>
>Attached I have a spreadsheet (csv format) in which I tried to classify
>where I thought existing documents might go. No comment on whether the
>working group should actually be working on the draft; my question was
>"if someone sent in this draft as a -00, which working group might they
>choose and why". I might obviously be wrong. But it's on the basis of
>this that I said that the breakout was in the neighborhood of even.
>

---

From: Tina TSOU <[email-masked]>
Date: Fri, 19 Aug 2011 20:47:11 +0000

Chris,
That's exactly the main part what v4v6tran work and the framework I-D asked.

Best Regards,
Tina TSOU

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Donley
Sent: Friday, August 19, 2011 1:07 PM
To: Fred Baker; Brian E Carpenter
Cc: IPv6 Operations; Ron Bonica
Subject: Re: [v6ops] How to divide v6ops

Chris

---

From: Keith Moore <[email-masked]>
Date: Fri, 19 Aug 2011 17:06:24 -0400

On Aug 19, 2011, at 4:07 PM, Chris Donley wrote:

> fit pieces of it.

That, at least, seems to indicate that simply splitting this group is not a good idea.  It might be that some sort of rearranging or clarification of the scopes of several working groups is in order.   That exercise should make it clear if there are areas not adequately covered for which one or more additional WGs might be appropriate.

Keith

---

From: Rémi Després <[email-masked]>
Date: Sat, 20 Aug 2011 16:46:24 +0200

> On Aug 18, 2011 7:37 PM, "Keith Moore" <[email-masked]> wrote:
...
> > So the first thing I'd recommend is triage - sort the work items into urgent, necessary, and nonessential.  And I'd strongly recommend that at least the nonessential work and maybe some of the ne…

+1

RD

---

From: Rémi Després <[email-masked]>
Date: Sat, 20 Aug 2011 16:46:27 +0200

+1

RD

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 20 Aug 2011 12:25:41 -0700

>>> with lots of cross posting

One has to recognize that expectations of stack changes in existing ipv4 speaking devices, particularly non-dual-stack devices are unrealistic. So keeping ipv4 in mind, really means keeping our legacy in  mind because the hosts themselves aren't going to change.

---

From: Fred Baker <[email-masked]>
Date: Sat, 20 Aug 2011 18:14:23 -0700

> One has to recognize that expectations of stack changes in existing ipv4 speaking devices, particularly non-dual-stack devices are unrealistic. So keeping ipv4 in mind, really means keeping our leg…

It's not limited to the hosts. In my case, every host in the house speaks IPv6 with the exception of my wife's printer, the Cisco 7960 on my desk, and our various Android, Samsung, and Motorola telephones. The 7960 could; it's a matter of a software upgrade. What prevents me from speaking IPv6 anywhere else is my CPE router (I in fact upgraded the software; however, the only reason I had to do so was that I wanted to), my service provider (Cox), and the company I VPN into (Cisco IT runs IPv6 in some places, but not everywhere and specifically not on DMVPN access and not on internal telephones). I personally fixed the external problem in part by getting an HE tunnel; again, I am motivated to, but I'm unusual in that regard.

Keeping IPv4 in mind is in part driving with the eyes glued on the rearview mirror and looking at Windows XP. That said, I think the biggest single impediment, given that the ISP offers IPv6 service, will be the CPE Router, not the host. I suspect that getting people to upgrade them will mean the ISPs getting somehow into cahoots with the CPE Router vendors and offering an upgrade service to their residential/SOHO customers. Ideally, that would be a software download, but I'm not holding my breath for a number of obvious reasons. If we want that to be an equipment upgrade - which the vendors will want it to be - that's something ISPs and CPE router vendors will need to sell to their customers.

I'm going to shut up before some lawyer tells me I'm afoul of some anti-anticompetitive-behavior law.

---

From: Erik Kline <[email-masked]>
Date: Sun, 21 Aug 2011 10:30:27 +0900

> For continuity, I have offered to chair v4ops with a co-chair from an operator that is concerned with v4/v6 transition issues to be chosen by Ron; I would continue to co-chair v6ops with Joel. That…

+1 to giving the schedule split @82 a try.  The general feeling could
be partially gauged by attendance.  I,for one, could very easily skip
the v4ops-focused session.

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 20 Aug 2011 18:31:32 -0700

Consumer owned CPE will be replaced eventually because they have in the past and they do age out of the network, but it's not fast, and it's not coupled to ISP activites when you talking about the installed base.

If an ISP controls the CPE, they can control that outcome more directly (free for example).  

I'm fundamentally convinced that we don't get to mess with the installed base, so we should be focused on devices that don't yet exist (as targets for innovation), or those that exist  and will in the near term, that have v6 as it is currently conceived rather than as we would like it to be (assuming there is variance).

Joel's widget number 2

---

From: Rémi Després <[email-masked]>
Date: Sun, 21 Aug 2011 17:50:33 +0200

Hi, Fred,

In view of your interesting comment below (now between ***'s), you opinion, and that of v6ops contributors, on the 6a44 approach, will be quite useful.

The 6a44 proposal, co-authored with Brian Carpenter, Dan Wing, and Sheng Jiang, is about offering IPv6, plug-and-play and in production-quality, behind _unmodified_ CPEs, to all hosts that have the appropriate upgrade. 

The solution is operationally simple, and easily scalable because it is stateless (per-customer states neither in ISP nodes nor in hosts).

Ref is tools.ietf.org/html/draft-despres-6a44-00.
(Since no WG found such a goal in its scope, it has been posted as independent submission.) 

Regards,
RD

Le 21 août 2011 à 03:14, Fred Baker a écrit :

> Keeping IPv4 in mind is in part driving with the eyes glued on the rearview mirror and looking at Windows XP.

***
> That said, I think the biggest single impediment, given that the ISP offers IPv6 service, will be the CPE Router, not the host. I suspect that getting people to upgrade them will mean the ISPs getting somehow into cahoots with the CPE Router vendors and offering an upgrade service to their residential/SOHO customers. Ideally, that would be a software download, but I'm not holding my breath for a number of obvious reasons. If we want that to be an equipment upgrade - which the vendors will want it to be - that's something ISPs and CPE router vendors will need to sell to their customers.
***

---

From: "t.petch" <[email-masked]>
Date: Mon, 22 Aug 2011 10:00:01 +0200

----- Original Message -----
From: "Fred Baker" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: "IPv6 Operations" <[email-masked]>; "Ron Bonica" <[email-masked]>
Sent: Friday, August 19, 2011 12:36 AM
On Aug 18, 2011, at 3:06 PM, Brian E Carpenter wrote:
My thought, which I'm not stuck on but is what I'm thinking right now, is that
this is actually not very much about anything with a "6" in it. I'm in favor of
pushing IPv6 as a technology, but...

It's about the fact that networks that are deploying IPv6 still have to stay in
business, and as a result have v4 networks that have to stay running until a
certain percentage of their access customers have upgraded CPEs, edge networks,
and hosts. Host upgrade is a limited timeframe problem, given that people buy
new ones at some rate. CPEs etc can be another discussion; if I have a working
CPE, why do I spend $$ to change it? It's in the ISP's interest for them to all
go spend that money; I doubt that the average consumer will see it as in their
interest also.

<tp>

My experience, probably atypical, is the opposite.

I run an elderly PC with elderly software because the cost of transition to
anything newer is so high; I occasionally have a problem - eg the IANA home page
will not display correctly - but nothing I cannot live with.

By contrast, in a parallel field, I have replaced a 'CPE', my digibox for
terrestial TV, several times.  The monetary cost is low (50 to 100 dollar), the
functionality is improved with a new box, the user interface is almost a
standard so I have little need for 're-training' etc.  When I encounter a
problem, I bin the box and replace it, and would do just the same for my ADSL
CPE.

The other parallel is the mobile phone, where every so often I get a message
saying that when I switch the phone off, I will activate new software. This I do
not want; I am deeply suspicious of an organisation I do not trust downloading
new software onto my hardware to be activated at at time I do not really control
 (ie the battery going flat).  Another beauty of the ADSL CPE is that I can buy
one from a third party, and then my ISP cannot impose new software on me at a
time of its choosing.

Tom Petch

<snip>

---

From: Thomas Narten <[email-masked]>
Date: Tue, 23 Aug 2011 11:46:46 -0400

IMO, the real elephant in the room is that there are too many drafts
covering marginal work topics. But rather than tell people "no", we
allow work to continue, even enable it (e.g., by saying "we'll discuss
further on the list", when in fact, little useful discussion happens
but the ID gets respun and gets presented again at the next
meeting). And given the that the WG (and in fact any WG) has a finite
amount of clue/cycles, if you stretch that too thin, you start
thrashing, and then you are really in a fix.

The WG needs to focus on stuff that matters, and say "no" to
everything else.

Absent a real willingness to do this, splitting the WG up is nothing
more then rearranging the deck chairs...

Thomas

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 23 Aug 2011 09:54:57 -0700

> more then rearranging the deck chairs...

Fully agree. We need to 'fast fail' marginal work out of the group.

Cb

---

From: Warren Kumari <[email-masked]>
Date: Tue, 23 Aug 2011 14:04:43 -0400

> more then rearranging the deck chairs...

Fully agree.

We should also keep in mind that, even if we do say "No" to a bunch of things, there is *still* going to be a huge amount of work for the Chairs to deal with, and they deserve some recognition and support for handling this...

W

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Aug 2011 09:05:08 +1200

+1. I just said something similar on softwires.

Regards
   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 24 Aug 2011 00:54:43 +0000

Fully agree. In some observation, v6ops has developed towards a forum, which allows any IPv6-relevant topics to be presented.

It will work well if the chairs can simply say "no" to these works that stands no/minimum change to become v6ops wg drafts.

Sheng

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Thomas Narten
> Sent: Tuesday, August 23, 2011 11:47 PM
> To: Fred Baker

---

From: Thomas Narten <[email-masked]>
Date: Wed, 24 Aug 2011 10:42:54 -0400

Sheng Jiang <[email-masked]> writes:

> Fully agree. In some observation, v6ops has developed towards a
>  forum, which allows any IPv6-relevant topics to be presented.

> It will work well if the chairs can simply say "no" to these works
>  that stands no/minimum change to become v6ops wg drafts.

Not fair to push all of this onto the chairs. The WG has been very
much an enabler of the current behavior, and the chairs (rightly) are
limited in how much they can go against the flow of a WG. I would like
to see stronger pushback from the chairs on taking on work (unless
there is clear and strong support for doing the work), but the WG
needs to get on board with such an approach as well.

We really need to come up with some concrete guidelines for deciding
how to evaluate whether there is sufficient WG support for a
document. It needs to reflect the reality that:

  - given the size of the v6ops WG (and the topic of v4/v6
    transition/coexistance/keep-existing-stuff-alive-a-little-longer),
    you will always find a small number of folk willing to support a
    document. But that should not be good enough, it needs to be a
    significant fraction of the WG. The document needs to be deemed as
    actually useful/important, as opposed to just "harmless" or "maybe
    useful"

  - this WG (not unlike others) has succumbed to the practice where
    folk won't oppose a document, presumably because if they do, they
    won't later get support for documents of their own. I.e., I'll
    scratch your back if you scratch mine. The result (again) is that
    any document will get *some* support and the WG collectively
    shares responsibility for accepting marginal documents. But we
    need to get back to the IETF's core purpose, which is producing
    useful documents. It is not to pad CVs, or justify one's
    attendance.

I'd suggest the development of some more concrete/objective criteria
for deciding whether to take on documents. One that makes it clear
that not all work that *might* be useful to *someone* needs to be
done.

Also, we have a broader problem of many documents that are "WG
shopping". Rather than discuss the merits of the work, the discussion
is more about finding what WG the work should be done in. I.e., if one
WG doesn't want it, go find another WG that might. We see that problem
in spades in the v6ops/softwire/behave area.

Also, we have too many documents on what seems like the same basic
topic/issue. But because there are so many of them, we (collectively)
are effectively overwhelmed and then rather than either killing them
or merging them, we let them continue on in a sort of twilight zone
where they are neither accepted nor rejected items.

Curmudgeonly yours,

Thomas

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Aug 2011 12:10:29 -0400

> that not all work that *might* be useful to *someone* needs to be

A broader problem is that few individual WG members see the total cost of the WG taking on another document.  It's not just the amount of time spent by those editing the WG document and reviewing it in detail.   It also takes up the attention of the WG for as long as the document remains a topic of conversation.  It also takes up the shepherd's time and attention, the principal AD's time and attention, perhaps the time and attention of members of the directorate, and sometimes the time and attention of other ADs or all of IESG.  All of that translates to the inability of the WG and IESG and the community in general to work on what might be more important (in the long run) or urgent matters.

So when the WG is being polled to ask "who is interested in working on this document" that's arguably the least of the cost.   And at least for WG documents, the bar should probably be _much_ higher than "might someday be useful to someone".   For the latter category documents, there remain other means of publication: individual submissions for new RFCs (especially informational or experimental), RFC errata for existing RFCs, and avenues outside of IETF.

Keith

---

From: Randy Bush <[email-masked]>
Date: Thu, 25 Aug 2011 19:05:26 +0900

> thrashing, and then you are really in a fix.

this problem is far from limited to this wg.  it is endemic and very
damaging.

    "It's perfectly appropriate to be upset.  I thought of it in a
    slightly different way--like a space that we were exploring and, in
    the early days, we figured out this consistent path through the
    space: IP, TCP, and so on.  What's been happening over the last few
    years is that the IETF is filling the rest of the space with every
    alternative approach, not necessarily any better.  Every possible
    alternative is now being written down.  And it's not useful."  
    -- Jon Postel

randy

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 25 Aug 2011 20:56:00 -0700

> thrashing, and then you are really in a fix.

While I largly agree with the sentiment, we've also engaged in some
signficant backpressure on not presenting documents which have not been
discussed.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 28 Aug 2011 16:44:18 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomas Narten
Sent: Tuesday, August 23, 2011 11:47 AM
To: Fred Baker (fred)
Cc: IPv6 Operations; Ron Bonica
Subject: Re: [v6ops] How to divide v6ops

>more then rearranging the deck chairs...

During the past two years or so I have seen repeated allusions to the
fact that v6ops is overloaded but I haven't seen any evidence.  Granted
a lot of drafts get submitted to v6ops but many do not get discussed in
the mailer and thus such documents should not be even considered for
presentation at an IETF.  +1 to Thomas and others on marginal work to be
punted out.   

Hemant

---

From: Fred Baker <[email-masked]>
Date: Sun, 28 Aug 2011 16:25:02 -0700

On Aug 28, 2011, at 2:44 PM, Hemant Singh (shemant) wrote:

> During the past two years or so I have seen repeated allusions to the fact that v6ops is overloaded but I haven't seen any evidence. 

Actually, we usually have at least one draft in discussion on the mailer. That's how we run WGLCs, and to pick one sequence, we went through ten drafts in two-week discussions in April and May. To give you a measure of what folks currently wish v6ops was discussing (45 drafts, several of which are seriously off-topic and a few are in the IESG or RFC Editor lists), see the list at the end of this note.

45 drafts, or even 20, is a lot of work in a working group. There are currently 2012 posted internet drafts; if they are all in discussion in a working group (which they are not - many are not being discussed, and some are in the IESG or the RFC Editor's lists), that's 16 per working group on average. Think about it.

As to the comment about the chairs not saying "no", the chairs have repeatedly asked for working group input on what it wants to discuss, and generally get negligible comment - 19 out of nearly 300 f2f attendees in IETF-79, 14 of mailing list members in June. For IETF-81, we scheduled 20 of the 42 then-posted drafts for discussion, and added a couple more when we were able to arrange for a third meeting. Setting aside half the drafts constitutes "saying 'no' to some" in my book. For those that have asked for additional editorial control, I think it also implies the application of the charter as editorial control.

If folks want to make helpful comments, they can tell us how best to divide or tighten up the charter so that they get happier with the editorial control. They can also reply to questions sent to the working group by the chairs.

http://datatracker.ietf.org/doc/draft-andrews-v6ops-6to4-router-option
  "6to4 DHCP Relay Router Option", Mark Andrews, 10-May-11

http://datatracker.ietf.org/doc/draft-asati-v6ops-dad-loopback
  "IPv6 DAD Enhancements for handling Layer1 Loopbacks", Rajiv Asati, Eli
  Dart, 24-Aug-11

http://datatracker.ietf.org/doc/draft-chen-v6ops-ipv6-bearer-network-trials
  "IPv6 Practices on China Mobile IP Bearer Network", Gang Chen, Tianle
  Yang, Lianyuan Li, Hui Deng, 4-Jul-11

http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-cpe
  "NAT64-CPE Mode Operation for Opening Residential Service", Gang Chen,
  Hui Deng, 10-Jul-11

http://datatracker.ietf.org/doc/draft-chown-v6ops-address-accountability
  "IPv6 Address Accountability Considerations", Tim Chown, 11-Jul-11

http://datatracker.ietf.org/doc/draft-chown-v6ops-call-to-arms
  "World IPv6 Day Call to Arms", Tim Chown, Mat Ford, Stig Venaas,
  7-Jun-11

http://datatracker.ietf.org/doc/draft-dec-stateless-4v6
  "Stateless 4Via6 Address Sharing", Wojciech Dec, Rajiv Asati, Congxiao
  Bao, Hui Deng, 11-Jul-11

http://datatracker.ietf.org/doc/draft-deng-v6ops-aplusp-experiment-results
  "Implementing AplusP in the provider's IPv6-only network", Xiaohong
  Deng, Tao Zheng, Mohammed Boucadair, France Telecom, Xiaohong Huang, Qin
  Zhao, Yan Ma, 8-Jul-11

http://datatracker.ietf.org/doc/draft-denog-v6ops-addresspartnaming
  "Naming IPv6 address parts", Lutz Donnerhacke, Richard Hartmann, Kay
  Rechthien, Leon Weber, Ronny Boesger, Thorsten Dahm, Joerg Dorchain,
  Sascha Lenz, Michael Horn, Jan Walzer, Sebastian Wiesinger, 7-Apr-11

http://datatracker.ietf.org/doc/draft-elkins-6man-ipv6-diagnostic-header
  "IPv6 Diagnostic Header", Nalini Elkins, Lawrence Kratzke, Michael
  Ackermann, 4-Jul-11

http://datatracker.ietf.org/doc/draft-fling-v6ops-hybrid-bridged-routed
  "A Hybrid IPv6 Service model of Bridged and Routed Mode", Chih-Cheng
  Tsao, Fang-Yu Ling, 8-Apr-11

http://datatracker.ietf.org/doc/draft-gashinsky-v6nd-enhance
  "Operational Neighbor Discovery Problems and Enhancements.", Warren
  Kumari, 29-Jun-11

http://datatracker.ietf.org/doc/draft-gont-v6ops-ra-guard-evasion
  "IPv6 Router Advertisement Guard (RA-Guard) Evasion", Fernando Gont, UK
  CPNI, 7-Jun-11

http://datatracker.ietf.org/doc/draft-gundavelli-v6ops-pmipv6-address-reservations
  "Reserved IPv6 Interface Identifier for Proxy Mobile IPv6", Sri
  Gundavelli, 8-Aug-11

http://datatracker.ietf.org/doc/draft-hilliard-v6ops-ipv6-discard-prefix
  "A Discard Prefix for IPv6", Nick Hilliard, 4-Jul-11

http://datatracker.ietf.org/doc/draft-hu-v6ops-radius-issues-ipv6
  "RADIUS issues in IPv6 deployments", Jie Hu, Yulong Ouyang, Qian Wang,
  14-Mar-11

http://datatracker.ietf.org/doc/draft-ietf-v6ops-3gpp-eps
  "IPv6 in 3GPP Evolved Packet System", Jouni Korhonen, Jonne Soininen,
  Basavaraj Patil, Teemu Savolainen, Gabor Bajko, Kaisu Iisakkila,
  20-Aug-11

http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic
  "Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to
  Historic status", Ole Troan, 24-Jun-11

http://datatracker.ietf.org/doc/draft-ietf-v6ops-happy-eyeballs
  "Happy Eyeballs: Success with Dual-Stack Hosts", Dan Wing, Andrew
  Yourtchenko, 11-Jul-11

http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router-bis
  "Advanced Requirements for IPv6 Customer Edge Routers", Hemant Singh,
  Wes Beebee, Chris Donley, Barbara Stark, Ole Troan, 10-Jul-11

http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat
  "IPv6 Multihoming without Network Address Translation", Ole Troan, David
  Miles, Satoru Matsushima, Tadahisa Okimoto, Dan Wing, 29-Mar-11

http://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6tran-framework
  "Framework for IP Version Transition Scenarios", Brian Carpenter, Sheng
  Jiang, Victor Kuarsingh, 26-Jul-11

http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications
  "IPv6 AAAA DNS Whitelisting Implications", Jason Livingood, 8-Jun-11

http://datatracker.ietf.org/doc/draft-jjmb-v6ops-comcast-ipv6-experiences
  "Comcast IPv6 Trial/Deployment Experiences", John Jason Brzozowski,
  Chris Griffiths, 8-Jul-11

http://datatracker.ietf.org/doc/draft-kanizsai-v6ops-anycast-data-aggregation
  "IPv6 anycast based feedback data aggregation", Zoltan Kanizsai, Laszlo
  Bokor, Gabor Jeney, Gianmarco Panza, 7-Mar-11

http://datatracker.ietf.org/doc/draft-keranen-ipv6day-measurements
  "Some Measurements on World IPv6 Day from End-User Perspective", Ari
  Keranen, Jari Arkko, 11-Jul-11

http://datatracker.ietf.org/doc/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel
  "6to4 Provider Managed Tunnels", Victor Kuarsingh, Yiu Lee, Olivier
  Vautrin, 13-Mar-11

http://datatracker.ietf.org/doc/draft-kuarsingh-wireline-incremental-ipv6
  "Wireline Incremental IPv6", Victor Kuarsingh, 4-Jul-11

http://datatracker.ietf.org/doc/draft-li-v6ops-load-balancing-requirement
  "Analysis on Load Balancing Requirement in IPv4/IPv6 Transition",
  Zhenqiang Li, Qin Zhao, Xiaohong Huang, Yan Ma, KuiKe Building

http://datatracker.ietf.org/doc/draft-matsushima-v6ops-transition-experience
  "Use case and consideration experiences of IPv4 to IPv6 transition",
  Satoru Matsushima, Yuji Yamazaki, Chunfa Sun, Masato Yamanishi, Jie
  Jiao, 29-Mar-11

http://datatracker.ietf.org/doc/draft-sarikaya-v6ops-prefix-delegation
  "DHCPv6 Prefix Delegation as IPv6 Migration Tool in Mobile Networks",
  Behcet Sarikaya, Frank Xia, Ted Lemon, 16-Jun-11

http://datatracker.ietf.org/doc/draft-sun-v6ops-laft6
  "LAFT6: Lightweight address family transition for IPv6", Qiong Sun,
  Chongfeng Xie, 14-Mar-11

http://datatracker.ietf.org/doc/draft-sunq-v6ops-contents-transition
  "Rapid Transition of IPv4 contents to be IPv6-accessible", Qiong Sun,
  Chongfeng Xie, Qian Liu, Xing Li, Jacni Qin, Dong Liu, 11-Jul-11

http://datatracker.ietf.org/doc/draft-sunq-v6ops-ivi-sp
  "Considerations for Stateless Translation (IVI/dIVI) in Large SP
  Network", Qiong Sun, Chongfeng Xie, Xing Li, Congxiao Bao, Ming Feng,
  6-Mar-11

http://datatracker.ietf.org/doc/draft-tan-v6ops-fast6-aaa
  "AAA for broadband access in IPv6 transition", Jinghua Tan, GuoLiang
  Yang, Cathy Zhou, 6-Jul-11

http://datatracker.ietf.org/doc/draft-tan-v6ops-nat64-experiences
  "Experience from NAT64 applications", Jinghua Tan, JinYan Lin, Weibo Li,
  7-Mar-11

http://datatracker.ietf.org/doc/draft-templin-v6ops-isops
  "Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP",
  Fred Templin, 27-Jul-11

http://datatracker.ietf.org/doc/draft-troan-v6ops-6to4-update
  "Connection of IPv6 Domains via IPv4 Clouds (6to4) as Last Resort", Ole
  Troan, Keith Moore, James Woodyatt, 10-Aug-11

http://datatracker.ietf.org/doc/draft-tsou-v6ops-multicast-transition-v6only
  "Multicast Transition to IPv6 Only in Broadband Deployments", Tina Tsou
  (Ting ZOU), Tom Taylor, 14-Mar-11

http://datatracker.ietf.org/doc/draft-v6ops-multihoming-without-ipv6nat
  "IPv6 Multihoming without Network Address Translation", Ole Troan, David
  Miles, Satoru Matsushima, Tadahisa Okimoto, Dan Wing, 29-Mar-11

http://datatracker.ietf.org/doc/draft-vanrein-v6ops-6bed4
  "IPv6 Tunneling for Embedded Systems (6bed4)", Rick van Rein, 25-Jul-11

http://datatracker.ietf.org/doc/draft-xli-v6ops-ivi-icmp-address
  "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, Congxiao
  Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 25-Jul-11

http://datatracker.ietf.org/doc/draft-yang-v6ops-fast6-pppoe
  "Fundamental Architecture of Services Provider's network Transitioning
  to IPv6 (FAST6) -- PPPoE Broadband Access", GuoLiang Yang, JinYan Lin,
  Jinghua Tan, 11-Jul-11

http://datatracker.ietf.org/doc/draft-yang-v6ops-fast6-tools-selection
  "The analysis of tools selection for broadband ISPs", GuoLiang Yang,
  Cancan Huang, Youming Wu, 11-Jul-11

http://datatracker.ietf.org/doc/draft-yang-v6ops-space6-icp
  "Service-Provider Application Cloud-based Engine for IPv6", GuoLiang
  Yang, ZhiLan Huang, Weibo Li, 9-Jun-11

---

From: Doug Barton <[email-masked]>
Date: Sun, 28 Aug 2011 16:37:14 -0700

On 8/28/2011 4:25 PM, Fred Baker wrote:
> As to the comment about the chairs not saying "no", the chairs have repeatedly asked for working group input on what it wants to discuss, and generally get negligible comment

Speaking for myself, my reactions to seemingly off-topic stuff tend to
fall into 3 broad categories:

1. That's a really bad idea (in which case I usually say so).
2. That sounds wacky to me, but there may be something about it that I'm
not seeing, so I'll wait and see if someone smarter than me comments.
3. Oy, again? Seriously? I hope the chairs do something about it. :)

What might be helpful (and I'm sorry to even suggest this, since I know
y'all are not really looking for more stuff to do) would be for the
chairs to be a teensy bit more assertive in edging stuff closer to the
cliff. I.e., if something seems like it's not getting enough support
post a message to the effect of, "This item doesn't seem to have the
support of the group. Unless $P people speak up within $D days we will
assume the group is not interested." Derivation of reasonable values of
P and D left as an exercise ...

hth,

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/