[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WG Review: IPv6 Operations (v6ops)
- To: "Fred L. Templin" <ftemplin@IPRG.nokia.com>, <v6ops@ops.ietf.org>
- Subject: RE: WG Review: IPv6 Operations (v6ops)
- From: "Bound, Jim" <Jim.Bound@hp.com>
- Date: Wed, 4 Sep 2002 22:35:33 -0400
- Delivery-date: Wed, 04 Sep 2002 19:38:07 -0700
- Envelope-to: v6ops-data@psg.com
- Thread-index: AcJTo0CO5z1YJFVPTOSkPO1y64RmWAA4X26w
- Thread-topic: WG Review: IPv6 Operations (v6ops)
I believe Fred has made a valid point on input to the charter. The one-size-fits-all is not a good way to view a tool. This is a good catch in the wording of the charter.
thanks
/jim
> -----Original Message-----
> From: Fred L. Templin [mailto:ftemplin@IPRG.nokia.com]
> Sent: Tuesday, September 03, 2002 7:49 PM
> To: v6ops@ops.ietf.org
> Subject: Re: WG Review: IPv6 Operations (v6ops)
>
>
> Comments on the new proposed charter follow:
>
>
> > * To: IETF-Announce: ;
> > * Subject: WG Review: IPv6 Operations (v6ops)
> > * From: Steve Coya <scoya@cnri.reston.va.us>
> > * Date: Tue, 27 Aug 2002 10:05:36 -0400
> > * Cc: new-work@ietf.org
> >
> > A new IETF working group has been proposed in the Operations and
> > Management Area. The IESG has not made any determination as yet.
> >
> > The following Description was submitted, and is provided for
> > informational purposes only:
> >
> >
> > IPv6 Operations (v6ops)
> > -----------------------
> >
> > Current Status: Proposed Working Group
> >
> > 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
>
> The term "operational" needs to be defined. The above could
> be interpreted as implying that sub-optimal solutions are
> satisfactory, as long as they work in some fashion. I would
> like to see the term "operational" defined in such a way that
> the best solution for the problem space is considered; not
> just a one-size-fits-all solution that may be sub-optimal.
>
> > (7) Identify open operational or security issues with the deployment
> > solutions documented in (5) and fully document those open
> > issues in Internet-Drafts or Informational RFCs. Work to find
> > workarounds or solutions to basic, IP-level deployment issues
> > that can be solved using widely-applicable transition
> mechanisms,
> > such as dual-stack, tunneling or translation.
> >
> > If the satisfactory resolution of a deployment issue requires
> > the standardization of a new, widely-applicable transition
> > mechanism that does not properly fit into any other IETF WG or
> > area, the v6ops WG will standardize a transition mechanism
> > to meet that need.
>
> I find the above wording biased, since "widely-applicable" seems to
> be the only selection criteria mandated for the standardization of
> new mechanisms. I would like to see the above changed to allow for
> standardization of the best mechanism for a particular scenario;
> not just a one-size-fits-all.
>
> By way of analogy, four-door sedans are "widely-applicable"
> vehicles. But:
>
> - minivans are a better choice for large families
> - pick-ups are a better choice for hauling large loads
> - 4wd's are a better choice for off-road driving
> - etc.
>
> Summary - the wording in sections (1) and (7) seems to mandate
> lowest-common-denominator solutions and ignore solutions that
> provide a better fit.
>
> Fred Templin
> ftemplin@iprg.nokia.com
>
>
>
>