Re: Comments: draft-savola-v6ops-transarch-01.txt

[Pekka Savola <pekkas@netcore.fi>]

Hi,

Thanks for comments, Jim.  Basically I agree with about all of them.  More 
inline..

On Tue, 21 Oct 2003, Bound, Jim wrote:
> Specific Comments:
> 
>    Robustness is also essential: the mechanism and the architecture must
>    be reliable and robust, to encourage the adoption.  Also, mechanisms
>    must not be less robust than their IPv4 counterparts: quite the
>    contrary.  It is highly desirable to aim for building the
>    architecture which does not depend on known-unreliable components
>    (for example, certain operational modes of IPv4 NAT's); otherwise,
>    the whole architecture is easily deemed unreliable.
> 
> Confused on what is trying to be said regarding IPv4 counter parts?  How
> can an IPv6/IPv4 transition mechanism have a counter part.  I get the
> point but this needs word-smithing to tighten up the point for
> robustness.  Also I don't think any mechanisms proposed in our history
> rely on IPv4 parts that do not work well?

Agree that this should probably be reworded to flesh out the point better.  
The point was basically that mechanisms which rely on certain behaviour of
NATs are likely rather unreliable.  There may be other pieces in the IPv4
infrastructure which might crash down if we started building something on
top of them..

>    In absence of a plan, the transition must be made so that the future
>    transition options will not be end-ran, and only "safe" transitionary
>    actions are executed.  For example, deploying dual-stack nodes with
>    currently only IPv4 connectivity does not end-run any transitionary
>    goals, but is an important step that must be done anyway.
> 
> Not sure what end-ran or end-run defines? 
> 
> What exactly does "safe transitonary actions" mean?
> 
> I am having a hard time parsing the point of this paragraph? 

Agreed.  The point is that when we don't know for sure how the transition 
would progress, it seems to make most sense only to actively engage in 
activities that progress the transition in any case (e.g., deployment of 
dual-stack).  In that way, even if there will be problems in other fronts, 
we don't lose anything.

>  Mechanisms:
>    Deployment models for IP nodes:
>    And services:
> 
> Each of the above should be their own section with descriptions in depth
> technically what they mean and imply to a transition architecture.
> Bullets are simply not enough in this case for a document labeled with
> the word "architecture" in it.  I am willing to help with this offline
> as I can find the spare cycles.

The mechanisms is already covered at some length, but some of these could 
indeed be fleshed out a bit.  I didn't do it because it didn't seem as if 
there was a lot to be said of each.. but I'm certain some words can be 
found, at least.  Any text/ideas would be helpful.

>    The intuitive answer to both of these would appear to be: "if you
>    really want to shoot yourself in the foot, do not blame the person
>    who sold you the gun -- or at least get prepared for a big hospital
>    bill."
> 
> Could we get technical or architecture statements to replace the above
> please :--)

Maybe, if I can think of one ;-)
 
>   The desire to go straight to IPv6-only seems to be mainly caused by a
>    dream of fast transition especially in some more evolved networks.
>    However, this seems counter-productive.
> 
> Important.  My impression is the hot button for this draft is that nodes
> and networks will best be served by dual IPv4 and IPv6 layers being
> supported, 

Yep.

> not that the draft is against IPv6 applications being
> deployed or IPv6 gradually becoming dominant for network operations over
> time.  I think this point is very important to be clear on in this work.

Of course not.  It probably would use some wordsmithing as well, yes.

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