Application Aspects of IPv6 Transition
draft-ietf-v6ops-application-transition-03

No further objection - Steve and Ted cover my concerns.

I don't really buy the assertion that applications are either "IPv4 applications" or "IPv6 applications".  A well designed application will rely on things like APIs to lower software layers (as described in section 6) to avoid such low-level dependencies.  I can, however, see user interface issues when there's a need to enter and display IP addresses, for example, but this document doesn't describe UI issues at all.

DNS applications, such as resolvers, are of course another matter.  The document does a good job of explaining the transition issues facing client-side DNS implementations, but the title seems to imply that the scope extends beyond DNS clients.  A title change may make the scope more clear.

Bump in the Stack and bump in the api should be spelled out at first
use. 

I think it would be useful to include the DNS resolver explicitly in the diagrams in
Section 2.  Its behavior is important enough to the set that inclusion would be useful
If the authors disagree, however, I will not press the point.

I also believe that this text:


     It is bad practise to add an AAAA record for a node that does not
     support all the services using IPv6 (rather, an AAAA record for the
     specific service name and address should be used). However, the
     application cannot depend on "good practise", and this must be
     handled.

is somewhat confusing.  It might be useful to rephrase this as "system
administrators should associate v6-specific names with v6 interfaces when
nodes having both v4 and v6 interfaces offer some services only over
v6 or v4".