[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Oops! Accepting Enterprise Scenarios as WG Item
OK these will be in there for sure. It has its own section too.
/jim
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> Sent: Friday, February 21, 2003 10:57 AM
> To: Bound, Jim
> Cc: Alain Durand; Margaret Wasserman; v6ops@ops.ietf.org
> Subject: Re: Oops! Accepting Enterprise Scenarios as WG Item
>
>
> Jim, I think you're misinterpreting my use of the b-word. I'm
> not (of course) talking about business models. I'm talking
> about scenarios. For example:
>
> A bank running a massive ATM network with some number of gazillions
> of transactions per second against central databases.
>
> An engineering company running distributed design systems
> across 20 different sites around the world.
>
> A pharmaceutical company running both compute-intensive and ERP
> applications.
>
> etc. Each one fleshed out with how they do things today, and
> what they want to achieve by adding IPv6.
>
> Brian
>
> "Bound, Jim" wrote:
> >
> > Brian,
> >
> > > I share some of Alain's concerns. I think that enterprise
> customers
> > > will not look at IPv6 as a goal in itself, but as a tool
> for certain
> > > business scenarios they need to support.
> >
> > We discussed this on the team. I agree with business justification.
> >
> > > So
> > > I think the draft should start with a set of business
> scenarios, and
> > > then maybe continue with the technology scenarios (plus
> analysis of
> > > which business scenarios they support). At the end, it
> would then be
> > > possible to deduce which technology scenarios are useful.
> >
> > We discussed this and this is not an IETF mission or purpose. The
> > business scenarios are not common and will vary. If we pick X
> > business scenarios and leave out Y then the Y types will
> not be happy.
> > This is not a goal of any scenario document unmanaged, ISP,
> or 3gpp.
> > So I would suggest that this is not on any of the design
> teams plates.
> > If your correct and I do not believe you are to add this
> then none of
> > the current scenarios should be moved to the IESG.
> >
> > >
> > > However, I wouldn't advocate pulling back the draft. I think we
> > > should just ask the team to go back and develop the business
> > > scenarios (or use cases, if you prefer the term). And if
> necessary,
> > > pull in more expertise for this (e.g. to cover Big Iron and major
> > > data centers and hosting centers).
> >
> > We have that expertise for "operations" and will not focus on data
> > center or big iron. Reason is that one persons belief of
> data center
> > or big iron is not the same as anothers. In the follow on draft
> > analysis of the enterprise which will be technical will have
> > assumptions that a "data center" could use.
> >
> > That being said I would suggest the IPv6 Forum, Asian IPv6
> Task Force,
> > North American IPv6 Task Force have the business scenarios
> and cases
> > done. It is also those forum charter not the IETF.
> >
> > Also would suggest if we want to focus on the data center
> specifically
> > we should build a separate draft and set of work to discuss
> first what
> > it means and then execute on those assumptions it should
> not be part
> > of the enterprise work.
> >
> > This team and work should be the dumping ground for all the
> things we
> > have to do that are not covered in the other specs. Or
> else we will
> > be here for 5 years working on this and this team is not
> going to do
> > that. Like DNS is the dumping ground for anything we cannot
> figure out
> > in our community to store data I would suggest and that is
> wrong too.
> >
> > Regards,
> > /jim
> > >
> > > Brian
> > >
> > > Alain Durand wrote:
> > > >
> > > > Margaret,
> > > >
> > > > First, I would like to say that I appreciate the effort of
> > > the design
> > > > team to address such a difficult issue.
> > > >
> > > > However, that said, I'm not very comfortable with this
> document.
> > > > On one hand, it is badly needed and already very late, on the
> > > other hand,
> > > > I'm not sure it is taking the right direction.
> > > >
> > > > I already have commented several times that this design team is
> > > > way too 'transition tool' centric in its approach,
> somehow making
> > > > the hidden assumption that solving the 'enterprise' case in the
> > > > (yet to
> > > > come) analysis/solution
> > > > document will consist only of picking the 'right'
> transition tool
> > > > developed by NGtrans.
> > > >
> > > > What I would like to see are things like the following
> > > > instantiated for a set of 'typical' enterprise environment:
> > > >
> > > > - how does the internal networks looks like?
> > > > - how is the networks are managed?
> > > > (who is responsible, what is outsourced, is IT
> > > competent/reliable
> > > > or not ...)
> > > > - what are the procedure/tools in place to manage the network?
> > > > (not only SNMP, but for example tools to create DNS
> zone files)
> > > > - is the public internet used (via VPN...)?
> > > > - what are the connections to the Internet?
> > > > - Is the v4 address space private or public?
> > > > - Is the v4 address space 'portable'? (hint: do they need
> > > portable v6
> > > > address space)
> > > > - How much v4 address space is available?
> > > > - Are they multi-homed?
> > > > - how is security enforced?
> > > > - how does the datacenter looks like if there is one?
> > > > - what kind of applications are used in the
> > > > Internet/intranet/extranets/...)
> > > > (is it in-house code? is the source code available?
> is an Ipv6
> > > > version of the
> > > > code available to buy?....)
> > > > - how naming service/directory service is performed (two face
> > > > DNS?) -...
> > > >
> > > > There is a little of that buried in section 4, variable
> > > description,
> > > > but I think this document should really instantiate those
> > > > variables and more (the ones I just described above for example,
> > > certainly much
> > > > more)
> > > > in a set of several 'typical' enterprise environments
> instead of
> > > > focusing on cases describing how enterprises are thinking
> > > of deploying
> > > > v6 at the IP level
> > > > (section 5, which is basically which networks to connect)
> > > or abstract
> > > > cases of transition mechanisms
> > > > (section 6, point of transition methods) which belongs
> not in this
> > > > document but in the solution document.
> > > >
> > > > With this in mind, I would not recommend the wg adopting this
> > > > document.
> > > >
> > > > - Alain.
> > > >
> > > > On Thursday, February 20, 2003, at 08:46 AM, Margaret Wasserman
> > > > wrote:
> > > >
> > > > >
> > > > > Hi All,
> > > > >
> > > > > I made a mistake last week and approved the
> publication of the
> > > > > enterprise scenarios document as a WG work item
> without actually
> > > > > checking with the WG first... Sorry.
> > > > >
> > > > > So, let's do this the right way...
> > > > >
> > > > > The enterprise scenarios/analysis team believes that
> the current
> > > > > version of their scenarios document is ready for
> consideration
> > > > > as a v6ops WG item. The document can be found at:
> > > > >
> > > > >
> > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-entnet-sc
> > enario
> > > > s-
> > > > 00.txt
> > > >
> > > > This work is clearly within the charter of v6ops.
> > > >
> > > > Could members of the WG please comment on whether you
> believe that
> > > > this document should be accepted as a WG item? In other words,
> > > > does
> >
> > > > it take the right technical direction, and would it serve as a
> > > > useful basis for our work? Is it sufficiently complete
> that it is
> > > > ready for WG review and refinement?
> > > >
> > > > If there is sufficient support to accept this document, it will
> > > > remain a WG work item. If not, we will move it back to
> individual
> > > > submission status.
> > > >
> > > > Sorry for my mistake and any confusion it may cause.
> > > >
> > > > Margaret
>