RE: WG Last Call: draft-ietf-v6ops-ent-scenarios-02.txt

["Bound, Jim" <jim.bound@hp.com>]

Jonne,

Yes.

/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
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> 
> 
>