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

["Pouffary, Yanick" <yanick.pouffary@hp.com>]

Hi Pekka

The list of 'subjects' transition related issues we came up with is:
- DNS 
- Application 
- Security 
- Transition tool management 
- Possibly Stateless/Stateful policy interactions
- others?

We do not expect everything to belong to this WG for sure. 

BTW individual documents have already been written for some of these
subjects like the one for application
draft-shin-v6ops-application-transition-01.

This activity would not take away from the scenarios document it would
help avoiding each document to have to cover these 'subjects' in full
depth.

We believe this activity should be done in parallel.

Yanick

-----Original Message-----
From: Pekka Savola [mailto:pekkas@netcore.fi] 
Sent: Friday, October 24, 2003 11:18 AM
To: Bound, Jim
Cc: v6ops@ops.ietf.org
Subject: Re: Proposal : Common issues across Scenarios Design Team
should be new work item

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.

On Fri, 24 Oct 2003, Bound, Jim wrote:
> 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.

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.

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

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

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