[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposed new v6ops charter



Hi Pekka, all,

Thanks a lot for the openness in making this changes in the list. I think
this is a very important sign of moving into a good direction.

Now, get back to the work ;-)

I mostly agree with your proposed changes, but I've some concerns on number
6. I think it should stay as we have it now, because it already says that
first we will try to do that work (if required), in the most appropriate WG,
and only will be done in v6ops if there is not another option on that
direction.

Also not sure if 3 and 7 should be removed, even if the work is already
done. May be to state that this has been already accomplished ? It seems to
me that removing it is like "canceling" (or out-chartering) the work already
done, which obviously is not what we want to do, right ? Note that I'm not
opposing to this change, just will like to make sure that is the right way
to proceed.

Finally, if we accept as a WG item (which I agree), the IPv6 NAP, then we
should be fair and accept also, at least, the IPv6 Distributed Security
problem statement and requirements documents.

Regards,
Jordi


> De: Pekka Savola <pekkas@netcore.fi>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Fri, 12 Nov 2004 15:46:08 +0200 (EET)
> Para: v6ops@ops.ietf.org
> Asunto: proposed new v6ops charter
> 
> Hi,
> 
> (co-chair hat on)
> 
> Below is the proposed draft charter for v6ops (I didn't renumber the
> sections at this point) to narrow down the focus.
> 
> This is roughly the same as presented at the meeting, with a couple of
> comments/corrections:
> 
> - clarify what "v6-in-v4 using IPsec" meant
> - shift the milestone dates forward a little bit
> - not change the statement on "all protocol work is outside of
> scope": justification being that it may make sense to give out clearly
> "the high-order bit" of what v6ops is (in principle) NOT doing
> (without rechartering)
> - not put back the applications section, as that seems to been done
> elsewhere, and the expertise is elsewhere.  This could be done as part
> of ops work as well.
> 
> The charter proposal is below, and at the following URLs.
> 
> http://netcore.fi/pekkas/ietf/temp/v6ops-dow.txt
> http://netcore.fi/pekkas/ietf/temp/v6ops-dow.html (the diff)
> 
> Comments?  Suggestions?  Please try to send them within a week or so.
> 
> (hat off)
> .................
> 
> [[ the most important changes:
> 
> - remove item 3 on application development and v4 dependencies
> (already done)
> - remove standardization of mechanisms from item 6
> - remove responsibility of existing basic v6 transition mechanisms
> - add new milestones and documents
> 
> existing issues still:
> - "operational/security issue" is still a blurry concept
> - should _someone_ be responsible for the protocols? [this is not
>   commonplace at IETF, though]
> - the scenarios docs are still there, but they do not trigger any
>   protocol work
> ]]
> 
> 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
> global 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 v6ops working group will:
> 
> 1. Solicit input from network operators and users to identify
>  operational or security issues with the IPv4/IPv6 Internet, and
>  determine solutions or workarounds to those issues.  This includes
>  identifying standards work that is needed in other IETF WGs or
>  areas and working with those groups/areas to begin appropriate
>  work.  These issues will be documented in Informational or BCP
>  RFCs, or in Internet-Drafts.
> 
>  For example, important pieces of the Internet infrastructure
>  such as DNS, SMTP and SIP have specific operational issues when
>  they operate in a shared IPv4/IPv6 network. The v6ops WG will
>  cooperate with the relevant areas and WGs to document those
>  issues, and find protocol or operational solutions to those
>  problems.
> 
> 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 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.
> 
> 5. 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 how to deploy IPv6 within their existing
>  IPv4 networks, as well as in new network installations.
> 
> 6. Identify open operational or security issues with the deployment
>  scenarios documented in (5) and fully document those open
>  issues in Internet-Drafts or Informational RFCs.
> 
> 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 group will provide input to those areas/groups, as
> needed, and cooperate with those areas/groups in developing and
> 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
> Adopt document describing issues with NAT-PT as WG item
> Dec 04
> Adopt IPv6 Security Overview as WG item
> Adopt IPv6 deployment using VLANs as WG item
> 
> Jan 05
>                Adopt ISP IPv6 Deployment Scenarios in Broadband Access
> Networks as WG item
> Adopt IPv6 Network Architecture Protection as WG item
> 
> Feb 05
>                Submit IPv6-in-IPv4 Tunneling using IPsec to IESG for Info
> Submit IPv6 deployment using VLANs as WG item
> 
> Mar 05
>                Submit IPv6 Security Overview to IESG for Info
> Submit document describing issues with NAT-PT to IESG for Info
> Submit Enterprise Deployment Analysiss to IESG for Info
> 
> Apr 05        Submit IPv6 Network Architecture Protection to IESG for Info
> 
> May 05        Submit ISP IPv6 Deployment Scenarios in Broadband Access
Networks to 
> IESG for Info
> 
> 



**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.