Subject: Feedback on proposed charter from the IESG

From: David Kessens <[email-masked]>
Date: Thu, 6 Jan 2005 18:45:54 -0800

I sent the following mail to the list before I went on a vacation trip
for the holidays. However, my mail didn't make it to the list for
unknown reasons, therefore I am trying it again.

David Kessens
---

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Jan 2005 08:53:36 +0200 (EET)

Folks,

(co-chair hat on)

Your input is needed.  The WG needs to form an opinion the charter. 
It seems that charter was considered too open-ended (and I personally 
agree with it, I just can't think of ways to make it less so, without 
severely restricting the work that could be pursued by the WG).

Do you have suggestions for, e.g.:
  - what classes of documents are such that we should be working on
    (with sufficient specifity so it doesn't seem open-ended),
  - good criteria on how to make decisions on documents that will be
    accepted and which will not, or
  - anything which SHOULD NOT be in the charter?

The proposed charter was posted on the list on Dec 21st, but I'm also 
attaching it here.

Please send your thoughts, preferably this week.

(hat off)

On Thu, 6 Jan 2005, David Kessens wrote:
[...]
> The charter is still a bit open ended. What is really missing is good
> criteria on how to make decisions on documents that will be accepted
> and which will not.
>
> For example, the list of proposed milestones is rather extensive and
> we were not entirely convinced that every single document on the list
> really needs to be worked on in the v6ops working group.
>
> As is not uncommon in the Operations Area, this working group will
> have some topics in the charter that will be somewhat open ended.
> However, that doesn't mean that we should take on any work that has
> remotely something to do with the operational aspects of running an
> ipv6 Internet network.
>
> Questions that come to my mind that are important to ask are:
>
> Is there really an audience that needs a particular document (eg. not
> just a very specific audience but a broad group of users)? Is there
> expertise in the working group to work on the topic (eg. more than
> just a few people should have a good understanding) ? Did the people
> that express willingness to work on a topic actually read the proposed
> internet draft ? Are there more than a few people willing to
> contribute, and an even larger group to review the document ?
>
> I hope that this helps to guide the discussion to get a solid new
> charter in place.
>
> David Kessens
> ---

==============
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 guidance for
network operators on how to deploy IPv6 into existing IPv4-only
networks, as well as into new network installations.

The main focus of the v6ops WG is to look at the immediate
deployment issues; more advanced stages of deployment and transition
are a lower priority.

The goals of the v6ops working group are:

1. Solicit input from network operators and users to identify
   operational issues with the IPv4/IPv6 Internet, 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
   v6ops may also cooperate in focusing such work.

2. Publish Informational or BCP RFCs that identify potential security
   risks in the operation 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 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 (including Core, HFC/Cable, DSL & Dial-up networks),
   Enterprise Networks, Unmanaged Networks (Home/Small Office), and
   Cellular Networks.

   These documents should serve as useful guides to network
   operators and users on possible ways how to deploy IPv6 within their
   existing IPv4 networks, as well as in new network installations.

   These documents should not be normative guides for IPv6 deployment,
   and the primary intent is not capture the needs for new solutions,
   but rather describe which approaches work and which do not.

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 v6ops 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.

Specifying any protocols or transition mechanisms is out of scope of
the WG.

Goals and Milestones:

  Nov 04	 Adopt document describing how to use IPsec with draft-ietf-v6ops-mech-v2 as WG item
  Nov 04  Adopt document describing issues with NAT-PT as WG item
  Dec 04  Adopt IPv6 Security Overview as WG item
  Dec 04  Adopt IPv6 deployment using VLANs as WG item
  Jan 05  Adopt ISP IPv6 Deployment Scenarios in Broadband Access Networks as WG item
  Jan 05  Adopt IPv6 Network Architecture Protection as WG item
  Feb 05  Ensure draft-ietf-v6ops-v6onbydefault keeps going forward for RFC publication
  Feb 05  Submit IPv6 deployment using VLANs to IESG for Info
  Mar 05  Submit document on IPsec w/ draft-ietf-v6ops-mech-v2 to IESG for Info
  Mar 05  Submit document describing issues with NAT-PT to IESG for Info
  Apr 05  Submit Enterprise Deployment Analysis to IESG for Info
  Apr 05  Submit IPv6 Network Architecture Protection to IESG for Info
  May 05  Submit IPv6 Security Overview to IESG for Info
  May 05  Submit ISP IPv6 Deployment Scenarios in Broadband Access Networks to IESG for Info
=================

---

From: Tim Chown <[email-masked]>
Date: Tue, 11 Jan 2005 14:06:53 +0000

It seems to be a bit of a catch-22.  The charter needs to be open ended
such that any operational issue not specifically relevant to another WG
can be adopted, yet the IESG wants to reduce the scope of what can be
adopted, without knowing in advance what those items might be.

I say we should run with this charter for now, and refine it if the IESG
can cite specific examples of hwere it thinks we (you :) are going wrong
in adopting 'inappropriate' items.

Of all the questions the IESG asks, the key one is "is there really an 
audience that needs a particular document?", and I feel if we can answer
yes to that *and* there is connsesus to adopt and people to work on it, 
and it isn't the domain of another existing WG, then we do so.

Tim

-- 
Tim

---

From: Alain Durand <[email-masked]>
Date: Tue, 11 Jan 2005 06:28:24 -0800

Of course, one could have the exact opposite point of view.
We put the wg in sleep mode and when a new issue comes up
we recharter to that purpose...

That would ensure that an adequate level of review is made
before any new work is started. Of course, this requires
a very reactive IESG so that no extra delays are introduced...

	- Alain.

On Jan 11, 2005, at 6:06 AM, Tim Chown wrote:

>>  Jan 05  Adopt ISP IPv6 Deployment Scenarios in Broadband Access 
>> Networks
>>  as WG item
>>  Feb 05  Ensure draft-ietf-v6ops-v6onbydefault keeps going forward 
>> for RFC
>>  publication
>>  Mar 05  Submit document on IPsec w/ draft-ietf-v6ops-mech-v2 to IESG 
>> for
>>  Info
>>  May 05  Submit ISP IPv6 Deployment Scenarios in Broadband Access 
>> Networks
>>  to IESG for Info
>> =================
>
> -- 
> Tim
>
>
>

---

From: "EricLKlein" <[email-masked]>
Date: Tue, 11 Jan 2005 16:52:16 +0200

I prefer Tim's version as there are still too many open items that we need
to resolve and finalize to be put into "sleep mode." With the understanding
that every new item we take on is checked more carefully for the audience
and people willing to work on it.

As It appears to me, we need to be active or ended. Sleep mode is a sure way
to make sure nothing gets done.

Eric

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Jan 2005 16:58:04 +0200 (EET)

> to make sure nothing gets done.

Well.. there is a middle ground: charter certain work items *now* and 
specify that adding new work items requires rechartering.

That should be enough for the next year or so, though potential new 
items could not be adopted, without having to go to complete sleep.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Alain Durand <[email-masked]>
Date: Tue, 11 Jan 2005 07:22:34 -0800

On Jan 11, 2005, at 6:52 AM, EricLKlein wrote:

> to resolve and finalize to be put into "sleep mode."

I guess I should have been clearer. I meant sleep after
current work items are completed.

	- Alain.

---

From: "EricLKlein" <[email-masked]>
Date: Tue, 11 Jan 2005 17:21:09 +0200

Ok, so there are currently 4 options (roughly summarized as follows):

1. Keep taking new items until told we have overstepped (Open ended approach
proposed by Tim)
2. Keep current items, and make new items fit stricter acceptance process
(active middle approach proposed by Eric)
3. Keep current items, and specify that adding new work items requires
re-chartering (middle approach proposed by Pekka)
4. Keep Current items and re-charter as new issues come up (Sleep mode as
proposed by Alain)

Have I got all of the contenders straight?

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Jan 2005 19:17:29 +0200 (EET)

> (active middle approach proposed by Eric)

No problem there, but the key point remains -- what would be that 
stricter acceptance process? :)

> 4. Keep Current items and re-charter as new issues come up (Sleep mode as

I think these are basically the same.  If there are no new items after 
done with those currently being chartered (and we still would need to 
discuss which those would be), the WG either goes to sleep or is shut 
down.. we don't have to decide which at this point.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Jan 2005 14:23:15 +0100

> down.. we don't have to decide which at this point.

I would suggest a 2.5 approach:

Make the charter obviously in two parts:

First part: general statement of purpose, maybe a bit shorter
than the current version, plus a new bit that sets the level
for new work items, e.g.

   Future work items within this scope will be adopted by the
   WG only if there is a substantial expression of interest
   from the operational community and if the work clearly does
   not fit elsewhere in the IETF.

Second part: the menu of currently chartered work items (not
just the list of milestones).

And yes, adding work items and milestones will be a charter
update, involving the AD and perhaps the IESG. That's what
they are "paid" for.

    Brian