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

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

sorry wrong list.  Please do not respond.
/jim

> -----Original Message-----
> From: Bound, Jim [mailto:jim.bound@hp.com] 
> Sent: Tuesday, October 21, 2003 2:08 PM
> To: ipv6@ietf.org
> Subject: Comments: draft-savola-v6ops-transarch-01.txt
> 
> 
> This draft can become useful, but needs more WG discussion 
> and I suggest we have that here and give Pekka input.  
> Document needs spell checker for some wordsm, and sentence 
> structure check.  Also to mahy cliches used that convey no 
> technical message to me as a reader.  I think the document 
> important but needs much more work here in the WG.
> 
> 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?
> 
>    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? 
> 
>  Mechanisms:
>      o Providing IPv6 connectivity
>      o Protocol translation
>      o Application-specific protocol interoperability (ie. 
> ALG or proxy)
> 
>    Deployment models for IP nodes:
>      o IPv4-only
>      o Dual-stack with only IPv4 connectivity
>      o Dual-stack w/ IPv4/6 connectivity
>      o Dual-stack with only IPv6 connectivity
>      o IPv6-only
> 
>    And services:
>      o IPv4-only
>      o Separate IPv4 and IPv6
>      o IPv4/6
>      o IPv6-only
> 
> 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.
> 
>    2.3. Transition Mechanism Deployment Considerations
> 
>    There are a few very important questions which must be addressed in
>    the cases where a transition mechanism deployment is deemed
>    necessary.  For example:
> 
>      o if I deploy IPv6-only service, whose burden is it to enable its
>        use by all clients I wish to make it accessible to?
> 
>      o if I deploy IPv6-only nodes, or dual-stack nodes with only IPv6
>        connectivity, whose burden is it to enable them to 
> access all the
>        services they want?
> 
>      o how much easier would it be to go for dual-stack approach
>        instead?
> 
>    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 :--)
> 
>   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, 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.
> 
> /jim
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------