Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

Here is my review of draft-ietf-v6ops-unman-scenarios-00.txt,
I have no concern but some comments and editorial remarks.

Comments

 I have no concern about the limitation to a single subnet as soon
 as it is clear from the beginning (and it is the case).

 A very common scenario (the one I use personally) is a VPN (with
 IPsec or SSH or both) which injects the home network into a virtual
 home site. I don't know if this should be explicitly considered but
 at least it should be put out of the scope of the document by
 a statement in the introduction.

 A DNS server can be recursive (i.e., be a "DNS proxy") or not. As
 almost all resolvers don't support recursion them selves, this is
 an important detail when the DNS crosses IP version domains.

Typos & co:

 2	Topology

   (ISP)connection. Several hosts are connected to the subnet:

=> (ISP) connection. Several hosts are connected to the subnet:

 3	Applications

   types of applications: local, client, servers and peer-to-peers.

=> types of applications: local, client, server and peer-to-peer.

 3.1	Local applications

   of the unmanaged network. Typical examples are the sharing of file

=> of the unmanaged network. Typical examples are the sharing of files

 3.2	Client applications

   Local applications tend to work correctly in IPv4 unmanaged

=> Client applications tend to work correctly in IPv4 unmanaged

 4.2	Requirements of client applications

   servers. In an IPv6 network, the client must be able to locate a DNS
   server.

=> perhaps this is the good place to introduce recursive DNS servers?
Note: in BIND the recursion part is in the server itself, i.e., even a
caching only server adds recursion support to the resolver but the
scenarios are about *unmanaged* networks, i.e., IMHO without any
BIND server by default.

 4.2.1	Privacy requirement of client applications

=> I agree with the conclusion.

 4.4	Requirements of server applications

=> insert a page break between 4.3 and 4.4 sections.

 5.1.2	Addresses and connectivity in Case A

   to deploy, and light weight; it will have to involve tunneling over
   UDP, as this is the practical way to traverse a NAT. If servers are

=> s/UDP/& or TCP/
(SSH is a good example of TCP tunneling which works through NATs)

 5.2.1	Application support in Case B

   all, and to just continue fielding IPv6-only devices. The remaining

=> please replace "fielding" by a more common term.

 5.2.2	Addresses and connectivity in Case B

   be assessed in a companion memo [EVAL].

=> as soon as there is a reference to [EVAL], there should be others.

 5.2.3	Naming services in Case B

   compared in the evaluation draft.

=> add [EVAL].

 5.4.1	Application support in Case D

   by providing IPv4-over-IPv6 tunnels. Our analysis concludes that a
   tunnel service will be vastly preferable.

 and

   The proper alternative to application relays and network address
   translation is the provision of an IPv4-over-IPv6 service.

=> I agree (:-)!!!

 5.4.3	Naming services in Case D

   The gateway should be able to act as a "DNS proxy" for the remaining
   IPv4 only hosts.

=> this "DNS proxy" is in fact a recursive DNS server running on a dual
stack node.

 11	References

=> should be split into two sections, etc.

   [EVAL] Evaluation of Transition Mechanisms for Unmanaged Networks,
   work in progress.

=> please add the name of the last version of the draft.

=> there is a [6TO4] in 5.3.2.

 Table of Contents:

=> move to front.

Thanks

Francis.Dupont@enst-bretagne.fr