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

[Pekka Savola <pekkas@netcore.fi>]

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