RE: Oops! Accepting Enterprise Scenarios as WG Item

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

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