[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt
And thanks for all the edits and comments I have to assemble all and now
do edit.
Thanks again,
/jim
> -----Original Message-----
> From: Soininen Jonne (Nokia-NET/Helsinki)
> [mailto:jonne.soininen@nokia.com]
> Sent: Tuesday, June 01, 2004 4:42 AM
> To: Bound, Jim
> Cc: ext Pekka Savola; v6ops@ops.ietf.org
> Subject: RE: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt
>
> Jim,
>
> (not answering this mail, but the last call in general)
>
> I checked the list of comments that the document got and
> there was a few that result in changes to the document. Could
> you, please, implement the agreed comments and then we (the
> chairs) can start pushing the document through to the IESG.
>
> Thank you for your efforts!
>
> Cheers,
>
> Jonne.
>
> On Tue, 2004-05-25 at 18:12, ext Bound, Jim wrote:
> > Of course we will reword/add clarity per the input to make clear
> > network c scenario. Also realize users are seeing the benefit for
> > cost reasons to move to IPv6 native networks sooner rather
> than later
> > and this is affecting transition planning in process now. But your
> > bias is clear in all discussion.
> >
> > /jim
> >
> > > -----Original Message-----
> > > From: owner-v6ops@ops.ietf.org
> > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Bound, Jim
> > > Sent: Tuesday, May 25, 2004 10:46 AM
> > > To: Pekka Savola; rfgraveman@nac.net
> > > Cc: v6ops@ops.ietf.org
> > > Subject: RE: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt
> > >
> > > This will never be added to this document your out of control but
> > > thanks for your opinion. You continue to miss the point
> of Native
> > > IPv6 deployment. And realize as you say your are ONE person here
> > > not a GATE to our hard work and efforts to work on
> specifications.
> > > To even say that this scenarios is unfit in a mail on this
> > > honoroable list of highly techncial and well informed, long time,
> > > engieers, architects and many of us who have been implementing,
> > > shipping, and deploying
> > > Ipv6 for many years and you the IETF spec reviewer to say that a
> > > scenario is unfit when you have nothing more in bullets clearly
> > > demonstrates your bias and continued denial of a deployment model
> > > that is not just for defense networks but Telcos, Enterprises you
> > > don't know anytbing about is beyond my comprehension. I
> am so tired
> > > of your biased input I am uclear if I can even work with
> you anymore
> > > as one of the true leaders and workers of
> > > IPv6 that does more than sit around and pontificate on
> specifications.
> > > It is unfortunate that you are a co-chair of the working
> group with
> > > such a bias.
> > >
> > > /jim
> > >
> > > > -----Original Message-----
> > > > From: owner-v6ops@ops.ietf.org
> > > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola
> > > > Sent: Tuesday, May 25, 2004 2:29 AM
> > > > To: rfgraveman@nac.net
> > > > Cc: v6ops@ops.ietf.org
> > > > Subject: Re: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt
> > > >
> > > > On Mon, 24 May 2004 rfgraveman@nac.net wrote:
> > > > > > I think Example network C, a security defense
> network, is not
> > > > > > mainstream enough to be applicable to be
> investigated in the
> > > > > > scenarios. There are probably 1, 5 or 10 such networks
> > > > in the world.
> > > > > > We should be focusing on more common scenarios (even
> > > > > > addressing "80/20" would be good). [I have a few specific
> > > > > > comments for clarification within this example, but
> I'll send
> > > > > > them if this example is not replaced by something else.] ...
> > > > >
> > > > > OTOH, some of these networks are large, and they buy a lot of
> > > > > equipment, so some major vendors take their
> requirements quite
> > > > > seriously. Therefore, I would be against dropping this
> > > case. We can
> > > > > discuss further whether this is exactly the right
> > > > characterization, however.
> > > >
> > > > I can see the argument why this needs to be considered ..
> > > > money is a language everybody understands .. but I'm concerned
> > > > that this would be painted as a "model" for v6 deployment, i.e.,
> > > that other
> > > > enterprises which have very little in common with such defense
> > > > networks would start mimicking their deployment strategies just
> > > > because those are the ones described in our documents. This is
> > > > why I'm worried about keeping this here.
> > > >
> > > > But let's hear if there are more opinions about this.
> > > >
> > > > In any case, if it stays, this could probably be
> clarified a bit,
> > > > like:
> > > >
> > > > A Security Defense Network Operation:
> > > >
> > > >
> > > > ==> add here something like:
> > > >
> > > > Note that these kind of networks are uncommon and
> unfit to be a
> > > > model or example for deployment for enterprises in
> general.
> > > > However, due to their importance to the vendor
> community, their
> > > > requirements should be considered explicitly.
> > > >
> > > > ...
> > > >
> > > > - External network required at secure specific points.
> > > >
> > > > ==> I had hard time parsing this, "at secure"? Did you mean:
> > > >
> > > > - External network is required, but only at
> specific, secure,
> > > > exit points.
> > > >
> > > > ...
> > > >
> > > > - Network must be able to absorb ad-hoc creation of
> > > sub-Networks.
> > > >
> > > > ==> I didn't quite understand what this meant, please
> > > clarify. (I've
> > > > a hunch, but..)
> > > >
> > > > - Entire parts of the Network are completely mobile.
> > > >
> > > > ==> are we talking about a mobile network (NEMO sense),
> or nomadic
> > > > network (network de-attaches, moves, network
> > > > re-attaches) ? The latter would at least be feasible,
> while the
> > > > former may be a bit more problematic. Maybe worth
> > > clarifying a bit..
> > > >
> > > > - Network must be able to bolt on to the Internet to share
> > > > bandwidth as required from Providers.
> > > >
> > > > ==> "bolt on to the Internet" ? I wasn't sure what this
> > > was trying to
> > > > say -- that the network must be able to multihome for
> load-sharing
> > > > purposes, or...?
> > > >
> > > > - Nodes must be able to access IPv4 legacy
> > > applications over IPv6
> > > > network.
> > > >
> > > > ==> are these internal legacy apps, external ones, or
> > > possibly both?
> > > > Isn't this assumptive about IPv6 deployment ("v6-only") and
> > > unfit for
> > > > requirements?
> > > >
> > > > --
> > > > Pekka Savola "You each name yourselves
> king, yet the
> > > > Netcore Oy kingdom bleeds."
> > > > Systems. Networks. Security. -- George R.R. Martin: A Clash of
> > > > Kings
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
>
>
>