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

From: "Bound, Jim" <[email-masked]>
Date: Tue, 21 Oct 2003 14:10:00 -0400

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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Wed, 22 Oct 2003 09:45:26 +0300 (EEST)

Hi,

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

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

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

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

> Could we get technical or architecture statements to replace the above

Maybe, if I can think of one ;-)
 
> supported, 

Yep.

> not that the draft is against IPv6 applications being

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