RE: DSTM

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

> This seems to me to be something that won't be compelling 
> scenario for quite some time. In other words, not something 
> we need to focus on in the short term.

It is now and in the short term.  I can go offline with you and get into
details if you like as sharing who and where is not acceptable here for
any deployment scenario uman, ISP, or enterprise.  But, as IESG member I
could take you into confidence if that is possible but I have seen no
one disclose anything other than general deployment scenarios and DSTM
should not have to either.

I think whether we work on it is up to the working group not you, or I,
or the chairs.

> 
> Let me repeat the question  I asked previously:
> 
>    Which of the scernarios that the WG has developed call for DSTM (or
>    something like DSTM)?
> 
> One of the purposes of the scenario analysis was to 
> understand which transition mechanisms were really important 
> so that we could focus on them. Also, understanding which are 
> the core pieces would help us label the RFCs more 
> appropriately (e.g., Standards track vs. experimental).

I responded to that see the Enterprise Scenarios draft.

> 
> > In addition the user/client does not want to use any protocol 
> > transition that requires architecturally defined prefix within the
> > IPv6 network (e.g. 6to4, Teredo).
> 
> I don't understand this. What is the _technical_ requirement here?_

Some enterprises will not want 2002:: or any hard coded prefix in their
sites network addresses only IPv6 aggregatable address prefixes assigned
to the site.  Transition will use IPv6 or IPv4 addresses not Transition
prefixes and DSTM supports that operational model.

Regards,
/jim

> 
> Thomas
> 
>