RE: Feedback on proposed charter from the IESG

["Bound, Jim" <jim.bound@hp.com>]

Hi Pekka,

My responses below.  I essentially support what Tim stated and as Alain
suggested when we are done with items and no new work meets the bar we
set we enter sleep mode.  So support Tim+Alain as caveat to my inline
response. 

> 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),

I believe current input is good and basically needs of the operational
community for deployment.

But I want to note what "operational community" means and maybe we need
to call that out from v6ops view very clearly:

Operational Community:

1. Providers (telco, ISPs, IXs, Mobile Greenfield to deploy 3G IMS et al
they are all different)

2. Enterprises that require operational work from within the IETF for
Enterprise operation.

3. Liaison consortias for deployment that provide v6ops via IETF
operational requirements.  Examples are IPv6 Forum, ICANN, NANOG,
Registries, ATIS www.atis.org, NCOIC www.ncoic.org, etc.

So I would like to see operational requirements defined at least for our
charter.

>   - 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?

I think that is work we need to do in the WG now and should have its own
mail thread topic is my input. So won't list it in this response.

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

Suggest you as chair begin separate mail thread as I state above for
this discussion.  It is to important to embed in this subject title is
my suggestion.

> >
> > 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 think the answer to the current work to all of the above is yes both
here in v6ops and in the v6ops understanding of the operational
community.

> >
> > I hope that this helps to guide the discussion to get a solid new 
> > charter in place.

I think the IESG gave us good feedback to think about.

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

I think the above needs re-wording.

Suggested replacement text:

The global deployment of IPv6 is in process. As the deployment evolves
some basic operational requirements will exist, and new operational
requirements will be learned. The IPv6 Operations Working Group is an
IETF working group to work on these operational requirements.

To scope the work for the IPv6 Operations Working Group we define and
provide examples of work within the scope of operational requirements.

[This is the mail thread discussion I suggest above to fill out the
above sentence]

Define operational community, and then criteria in that mail thread as
WG discussion.

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

Above replace and state: "provides operational guidance" 

Remove "network operators" our work is useful to Managers, Architects,
et al who will deploy IPv6. 

Re-write below:

The IPv6 Operations Working Group (v6ops) develops guidelines 
for the operation of a shared IPv4/IPv6 Internet and provides 
Operational guidance 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.

I would suggest this is premature if we are to have a criteria
discussion.  I think it will hold but lets check.

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

I think the above are useful results in response to needs to us based on
the criteria which is what is missing in our charter.

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

This is important to do within the IETF community of interests I agree.

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

I am not happy about this but that is fine lets move on.  I do think
authors of transition mechanism should send them to this list so they
know they exist.

> 
> 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 =================

I support all of the above being completed as work items for v6ops.

Thanks for asking,
/jim