Subject: Proposal : Common issues across Scenarios Design Team should be new work item

From: "Bound, Jim" <[email-masked]>
Date: Fri, 24 Oct 2003 00:47:48 -0400

Folks,

We got some input to address this in DNS or that in DNS or address this
for Mail or that for Mail for Enterprise work.  These I am thinking
common problems for all scenarios. How dynamic DNS updates work in
secure manner over an IPv4 Tunnel, as example, is the same
issue/resolution for Enterprise, 3GPP, ISP, and Unmanaged.

Do we need to select out common scenario issues for any network and make
that its own scenario document.

This would also avoid having to identify these issues in the above spec
work because the common scenarios spec would be first read or second
read to define how one deploys or transtions to IPv6.

Why do this:

1.  This would speed up efforts to deliver the four scenarios documents.

2.  It would support a focus for the common scenario issues.

3.  ISP, 3GPP, and Umanaged have not put this in their specs for the
most part thus it is no work for them.

4.  Enterprise work does not become the designated v6ops dumping ground
for common problems for application issues that are relevant to all
scenarios.  And this will slow down the process to complete the
Enterprise.  ISP scenarios face similar problem potentially.

5.  Users of any scenario focus we need to create can learn the base
common application or infrastructure scenarios common to any network
definition scenario.

Proposal: Begin a new design team and effort to work on the common IPv6
operational issues across any scenario that must be addressed (e.g. DNS,
Porting, Mail).  There are also probably common security issues for all
scenarios in addition to the specific ones for each scenario work effort
in v6ops.

Comments?

thanks
/jim

---

From: Pekka Savola <[email-masked]>
Date: Fri, 24 Oct 2003 12:18:07 +0300 (EEST)

Hi,

Thanks for the proposal.  We'll take it in the consideration.  There have
been a bit similar activities in the past, and a few others in the
pipeline (examples: the NAT-PT applicability work, the unmanaged
connectivity document), but these have been specific rather than generic
documents.  A few personal initial thoughts below.

> issue/resolution for Enterprise, 3GPP, ISP, and Unmanaged.

Right.  It would seem to make sense to bundle certain kinds of things 
together.

Of course, it would be useful to have a couple of specific examples on the 
table to see what kind of activities would be needed.  That is, there are 
often similar activity (e.g. on DNS), but the actual perspective may be 
entirely different (more of this at the end of this mail).

A potential downside of this may be that the "common scenarios" might lose
the focus of the scenarios.

> 1.  This would speed up efforts to deliver the four scenarios documents.

This is possible.  It might also mean that the scenarios documents 
themselves could be rather compact and would have to wait for the common 
scenarios document.  The question here is whether the four scenarios 
documents could stand on their own and progress independently of the 
common scenarios.

I.e., I think it would be useful to try to identify whether this "common"  
work would be additional text, clarification and suggestions -- and the
original document would still contain a very short summary of the issue --
or whether the common work would replace portions of the scenarios
documents.

> Enterprise.  ISP scenarios face similar problem potentially.

This is a valid concern, and we should try to avoid this.  We've tried
avoiding this (at least at this point) in ISP by omitting some details,
but they could be useful later on, or separately analyzed.. so it's 
difficult to say.
 
> scenarios in addition to the specific ones for each scenario work effort

To be able to get a better idea what this would entail, it would probably
make sense to try to summarize a bit more detailed "requirements" for
these common scenarios (e.g., which parts of DNS need to be handled like
this, what are the issues in mail handling, etc.).  Without a clear
"charter for the work", it'd be difficult to trying to figure out the best
way to solve the problem.

One thing to be kept in mind here is that these "common scenarios" could 
be either descriptions on how you go about doing things in general (like 
itojun's IPv6 SMTP document from IPv6 WG), or targeted at the scenarios 
identified in the scenarios documents.  If there is a disconnect here, we 
could be down the rathole of "transition mechanisms without scenarios".

That is, either the primary purpose of the documents is dissemination of
information how one could go about deploying IPv6 (highly useful), or
identifying mechanisms or protocol actions needed for the deployment (when
the connection the scenarios themselves must be clearer).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 29 Oct 2003 08:31:18 +0100

Jim,

> scenarios in addition to the specific ones for each scenario work 

isn't what you are really saying that there might be issues identified 
by the DTs that really should go to other WGs?

- - kurtis -