[sunset4] v6ops charter update discussion

Mon, 13 Apr 2015 16:59:55 -0700 

Lee and I are reviewing the v6ops charter. I have attached a proposed charter 
and diffs against the current one. Joel has not commented on this yet, and 
while we have run it by the sunset4 chairs, we haven’t gotten a reading from 
them. Sunset4 is relevant because possibly the ipv4-as-a-service discussion 
would be better handled there. In this email, I’m soliciting opinions in 
general.

The charter update started with Lee feeling that the fourth bullet of our 
current charter, which reads
    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.
       (http://datatracker.ietf.org/wg/v6ops/charter/)
is largely done. We know how to deploy IPv6.

In addition, I think we need, collectively, to figure out how to get to 
IPv6-only. A large issue is “so how do we connect to IPv4 content and services 
from an IPv6-only network”, which is where ipv4-as-a-service comes in. I 
propose adding a bullet item regarding a road map to IPv6-only.

    4. Describe an operational roadmap to IPv6-only network deployment, 
       with or without IPv4 delivered as an overlay or translation
       service.

In my mind, that includes operational discussions of deployments and deployment 
issues in IPv4-as-a-service; one possible update would be to make that more 
explicit.

In other respects, the update is mostly editorial.

The other three tasks remain unchanged - collect operational experience, 
identify operational and security risks, and turn them over to other working 
groups - notably 6man.

Hoping for your input. Do you agree with these changes? If not, what changes, 
or further changes, would you recommend? 

As to proposed milestones, I’d like to believe that 

these are done:
   draft-ietf-v6ops-6to4-to-historic
   draft-ietf-v6ops-cidr-prefix

we can finalize and ship these by July:
   draft-ietf-v6ops-design-choices
   draft-ietf-v6ops-pmtud-ecmp-problem

and these by November:
   draft-ietf-v6ops-siit-dc-*
   (would like a deployment report for siit-dc and siit-dc-2xlat in support)
   (would like one for 464xlat as well)

On another point, Lee and I have been discussing the operational reports we had 
at IETF 92, and feel that was time well spent. Those had a common thread, which 
was the deployment of Softwire’s MAP-E and MAP-T technologies in their 
networks. We are thinking about asking companies deploying IPv6 in Europe, 
Asia, and South America to make reports in the coming three meetings, on their 
IPv6 deployments and the issues they face. Would that be of general interest? 
How would you propose to tune that concept?


Charter for 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,
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 how to deploy and operate IPv6 in new and existing
networks.

The main focus of the IPv6 Operations Working Group is to look at
the deployment and operational issues in IPv6 networks.

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 Working
Groups 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 Maintenance Working Group regarding portions of the IPv6
specifications that cause, or are likely to cause, operational or
security concerns, and work with the IPv6 Working Group to resolve
those concerns. This feedback will be published in Internet-Drafts
or RFCs.

4. Describe an operational roadmap to IPv6-only network deployment,
with or without IPv4 delivered as an overlay or translation service.

These documents should document IPv6 operational experience, including
interactions with IPv4, in dual stack networks, IPv6 networks with
IPv4 delivered as an overlay or translation service, or IPv6-only
networks. They should not be normative guides for IPv6 deployment.
Their primary intent is not to capture the needs for new solutions,
but rather to describe which approaches work, and in what circumstances.

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 Working Group may provide input to those
areas/groups, as needed, and cooperate with those areas/groups in
reviewing solutions to IPv6 operational and deployment problems.

Future work items within this scope will be adopted by the Working
Group 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 Working
Group to work on a particular work item. If there is no longer
sufficient interest in the Working Group in a work item, the item
may be removed from the list of Working Group items.

Specifying any protocols or transition mechanisms is out of scope
of the Working Group.
Title: Diff: v6ops-charter-old.txt - v6ops-fred2-charter.txt
 v6ops-charter-old.txt   v6ops-fred2-charter.txt 
Charter for Working Group Charter for Working Group
The global deployment of IPv6 is underway, creating an IPv4/IPv6 The global deployment of IPv6 is underway, creating an IPv4/IPv6
Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks
and nodes. This deployment must be properly handled to avoid the and nodes. This deployment must be properly handled to avoid the
division of the Internet into separate IPv4 and IPv6 networks while division of the Internet into separate IPv4 and IPv6 networks,
ensuring addressing and connectivity for all IPv4 and IPv6 nodes. ensuring addressing and connectivity for all IPv4 and IPv6 nodes.
The IPv6 Operations Working Group (v6ops) develops guidelines for The IPv6 Operations Working Group (v6ops) develops guidelines for
the operation of a shared IPv4/IPv6 Internet and provides operational the operation of a shared IPv4/IPv6 Internet and provides operational
guidance on how to deploy IPv6 into existing IPv4-only networks, guidance on how to deploy and operate IPv6 in new and existing
as well as into new network installations. networks.
The main focus of the v6ops WG is to look at the immediate deployment The main focus of the IPv6 Operations Working Group is to look at
issues; more advanced stages of deployment and transition are a the deployment and operational issues in IPv6 networks.
lower priority.
The goals of the v6ops working group are: The goals of the v6ops working group are:
1. Solicit input from network operators and users to identify 1. Solicit input from network operators and users to identify
operational issues with the IPv4/IPv6 Internet, and determine operational issues with the IPv4/IPv6 Internet, and determine
solutions or workarounds to those issues. These issues will be solutions or workarounds to those issues. These issues will be
documented in Informational or BCP RFCs, or in Internet-Drafts. documented in Informational or BCP RFCs, or in Internet-Drafts.
This work should primarily be conducted by those areas and WGs which This work should primarily be conducted by those areas and Working
are responsible and best fit to analyze these problems, but v6ops Groups which are responsible and best fit to analyze these problems,
may also cooperate in focusing such work. but v6ops may also cooperate in focusing such work.
2. Publish Informational or BCP RFCs that identify potential security 2. Publish Informational or BCP RFCs that identify potential security
risks in the operation of shared IPv4/IPv6 networks, and document risks in the operation of shared IPv4/IPv6 networks, and document
operational practices to eliminate or mitigate those risks. operational practices to eliminate or mitigate those risks.
This work will be done in cooperation with the Security area and This work will be done in cooperation with the Security area and
other relevant areas or working groups. other relevant areas or working groups.
3. As a particular instance of (1) and (2), provide feedback to the 3. As a particular instance of (1) and (2), provide feedback to the
IPv6 WG regarding portions of the IPv6 specifications that cause, IPv6 Maintenance Working Group regarding portions of the IPv6
or are likely to cause, operational or security concerns, and work specifications that cause, or are likely to cause, operational or
with the IPv6 WG to resolve those concerns. This feedback will be security concerns, and work with the IPv6 Working Group to resolve
published in Internet-Drafts or RFCs. 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 4. Describe an operational roadmap to IPv6-only network deployment,
and users on possible ways how to deploy IPv6 within their existing with or without IPv4 delivered as an overlay or translation service.
IPv4 networks, as well as in new network installations.
These documents should not be normative guides for IPv6 deployment, These documents should document IPv6 operational experience, including
and the primary intent is not capture the needs for new solutions, interactions with IPv4, in dual stack networks, IPv6 networks with
but rather describe which approaches work and which do not. IPv4 delivered as an overlay or translation service, or IPv6-only
networks. They should not be normative guides for IPv6 deployment.
Their primary intent is not to capture the needs for new solutions,
but rather to describe which approaches work, and in what circumstances.
IPv6 operational and deployment issues with specific protocols or IPv6 operational and deployment issues with specific protocols or
technologies (such as Applications, Transport Protocols, Routing technologies (such as Applications, Transport Protocols, Routing
Protocols, DNS or Sub-IP Protocols) are the primary responsibility Protocols, DNS or Sub-IP Protocols) are the primary responsibility
of the groups or areas responsible for those protocols or technologies. of the groups or areas responsible for those protocols or technologies.
However, the v6ops WG may provide input to those areas/groups, as However, the v6ops Working Group may provide input to those
needed, and cooperate with those areas/groups in reviewing solutions areas/groups, as needed, and cooperate with those areas/groups in
to IPv6 operational and deployment problems. reviewing solutions to IPv6 operational and deployment problems.
Future work items within this scope will be adopted by the WG only Future work items within this scope will be adopted by the Working
if there is a substantial _expression_ of interest from the community Group only if there is a substantial _expression_ of interest from
and if the work clearly does not fit elsewhere in the IETF. 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 There must be a continuous _expression_ of interest for the Working
work on a particular work item. If there is no longer sufficient Group to work on a particular work item. If there is no longer
interest in the WG in a work item, the item may be removed from the sufficient interest in the Working Group in a work item, the item
list of WG items. may be removed from the list of Working Group items.
Specifying any protocols or transition mechanisms is out of scope Specifying any protocols or transition mechanisms is out of scope
of the WG. of the Working Group.
 End of changes. 11 change blocks. 
34 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 
_______________________________________________
sunset4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sunset4

Reply via email to