Re: [v6ops] A question: Interim meeting

["George, Wesley" <[e-mail]>]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Fred Baker
Sent: Wednesday, July 27, 2011 5:32 PM
To: IPv6 Operations
Subject: [v6ops] A question: Interim meeting

Given the growth of drafts in v6ops, ...I'm thinking about an interim meeting...
Are folks interested in having such a meeting?

[WEG] tl;dr version - speaking for myself, probably not, because I think that more meetings is treating the symptom, not the underlying cause. I think this is a charter/goals problem causing a workload/meeting problem, not a workload problem causing a meeting problem.

Longer version -
My question to the chairs and those in support of an interim is: what would the goal of such a meeting be? IETF WGs are supposed to be conducting business primarily over the list, and meetings are for resolving things that need to be resolved face-to-face either because they are too contentious to be done strictly via email or because you need some people in the same room to collaborate in real-time about the problem and the solution. Interims are usually to push forward on milestone work items, not to compensate for a lack of discussion on the list.

I don't support having another meeting simply because we have more drafts submitted to the WG that we didn't discuss. I feel like V6ops has become the gateway of last resort for anything with "IPv6" in the draft that is looking for a home, especially if it has to do with transition technologies. As a result, the signal to noise ratio has gotten unmanageable, as evidenced by the need for 3 sessions and the 40-odd drafts currently on our docket to either adopt, consolidate or ignore. No matter how many meetings we have, this group certainly doesn't have the cycles to add valuable review and comments to all of them, and it probably shouldn't adopt most of them, if for no other reason than they'd be just fine as individual submissions.

Perhaps the better solution is to spend some time contemplating our charter, and determine whether more of these drafts belong somewhere else, or whether we simply need to let more of them expire/pursue individual submission in the interest of pushing the inverse relationship between quantity and quality back the other direction somewhat by letting us focus on fewer drafts as a WG.
We currently have no milestones in our charter that are not completed, and I think we're suffering from far too broad of a charter, coupled with too low of a bar when deciding what drafts should be adopted as WG items or discussed in the meeting, and that is what is leading to the high draft load. People are contributing - that's a good thing. But they need some guidance to ensure that what they're contributing is useful.
This is supposed to be an operations group, but I feel like we spend an inordinate amount of time focused on BCP and theoretical analysis/overview/survey on things with which we have very little actual operational experience because they're not widely deployed yet. If we're not doing that, we're discussing tweaked transition technologies whose main point is, "yes, but $existing_implementation doesn't solve this corner case over here..." and the authors proceed as if new work is necessary instead of trying to find a common ground that makes the existing solution more flexible and widely applicable. Consequently, the output of both work streams is of questionable value since each one seems to be written with such a narrow focus that it's unlikely to be applicable outside of the specific case the authors had in mind when writing it.

IPv6 (and its associated transition technologies) is pretty well-baked at this point. IMO, what v6ops needs to be focused on is:
 * refining existing implementations and recommendations based on the results of actual, at-scale deployments (and yes I realize this means that potential authors must wait for them to exist in some cases)
 * security/scaling considerations
 * a gap analysis around what features in IPv4 are still missing or incomplete in IPv6 with an eye towards enabling true IPv6-only network implementations
Continuing CPE requirements work is an open question given the existence of homenet.
We should *not* be focused on building more "better mousetraps" to aid in transition without very clear signals from operators/implementers that there are gaps in the existing tools that need to be addressed. We also need to stop writing more survey/recipe documents for deployment unless they are specifically solicited by the operator community or specific technology SDO (3gpp, etc) so that we know that someone will actually pay attention to them and can provide expertise to review them. We are not going to speed the rate of IPv6 deployment and adoption by burying it in words to cover every possible permutation with 3 different solutions.

Sorry for the long-ish rant, hopefully it's constructive, no offense to any individual authors or contributors was intended.

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.