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

Re: Feedback on proposed charter from the IESG



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
----- Original Message ----- 
From: "Alain Durand" <Alain.Durand@Sun.COM>
To: "Tim Chown" <tjc@ecs.soton.ac.uk>
Cc: <v6ops@ops.ietf.org>
Sent: 11 January, 2005 4:28 PM
Subject: Re: Feedback on proposed charter from the IESG


> 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:
>
> > 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
> >
> > On Tue, Jan 11, 2005 at 08:53:36AM +0200, Pekka Savola wrote:
> >> 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
> >> =================
> >
> > -- 
> > Tim
> >
> >
> >
>
>
>