Re: WG Last Call: draft-ietf-v6ops-application-transition-01.txt (fwd)

[Brian E Carpenter <brc@zurich.ibm.com>]

Pekka Savola wrote:
> 
> (co-chair hat on)
> 
> Just a reminder -- the WGLC for the application transition document
> was issued just prior to the IETF, and still runs for about a week or
> so.  Please provide feedback.  Thanks!

"A week or so" expires today or so :-) 

Most of my comments on the previous version have been addressed. I remain 
a little unhappy about one paragraph. Here's the previous interchange between 
me and Pekka:

> > > 7. Transition mechanism considerations
> > > 
> > >      A mechanism, [NAT-PT], introduces a special set of addresses,
> > >      formed of NAT-PT prefix and an IPv4 address; this refers to IPv4
> > >      addresses, translated by NAT-PT DNS-ALG.  In some cases, one might
> > >      be tempted to handle these differently.
> > > 
> > >      However, IPv6 applications must not be required to distinguish
> > >      "normal" and "NAT-PT translated" addresses (or any other kind of
> > >      special addresses, including the IPv6-mapped IPv4-addresses):  that
> > >      would be completely unscalable, and if such distinction must be
> > >      made, it must be done elsewhere (e.g. kernel, system libraries).
> > 
(BC)> > I'm not sure why it would be unscalable - messy, yes, but not unscalable.
> 
(PS)> Maybe we're using different words to describe the same issue.  I call 
> this unscalable because I do not want to see every application to 
> implement it's own version of this (about 50% of them being probably 
> incorrect or otherwise wrong :-).
> 
(BC)> > Also, what if an application *wants* to treat a NAT-PT based session differently
> > (i.e. implement some legacy features because it knows that the other end
> > is IPv4)? Shouldn't the socket API be capable of telling the upper layer
> > "this address was translated"?
> 
(PS)> Maybe yes, but the point is that APIs do not provide these *today*.  
> If they did, I don't think there would be all that many problems
> having something like this implemented as part of APIs.  


(back to today...)

I see Pekka's points but the phrase "that would be completely unscalable"
still worries me. Could we replace it, for example by
"that would be completely impractical" ?

Incidentally, this document is referenced by the GGF draft on
IPv6 guidelines for GGF protocol designers, which by strange coincidence
finishes WG Last Call over in the GGF today too. See
http://forge.gridforum.org/projects/ipv6-wg/document/draft-ggf-ipv6-ip-independent-guide-00/en/1

(Warning- some mailers may split this URL into two pieces.)

   Brian