Re: WG Last Call: draft-ietf-v6ops-unmaneval-02.txt

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 21 May 2004, Pekka Savola wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unmaneval-02.txt

As for my personal comments on -02, see below.

substantial
-----------

   In a configured solution, a host or a router identifies itself to a
   tunneling service to set up a "configured tunnel" with an explicitly
   defined "tunnel router". The amount of actual configuration may vary
   from manually configured static tunnels to dynamic tunnel services
   requiring only the configuration of a "tunnel broker".

==> maybe add here something to the effect:
                                                        , or
   even a completely automatic discovery of the tunnel router.

(that's certainly an important goal, one that we're working towards!)

....

   When the local ISP is willing to provide a configured tunnel
   solution, we should make it easy for the host in case A to use it.

==> add here or in 2.3 something like:

   The requirements for such a service are presented in another
   document [TUNREQS].
 
(there TUNREQS is an informational reference to Alain and Florent's recent
doc.)

   The IETF should quickly provide a recommended procedure for
   provisioning the DNS resolver in IPv6-only hosts, either by
   standardizing the proper DHCPv6 subset, or by recommending an
   alternate convention.

==> the DHCPv6 subset has already been standardized, so I think the original
intent would be preserved if one just removed everything after ",either .."

...

   
   [TEREDO] C. Huitema. "Teredo: Tunneling IPv6 over UDP through NATs."
   Work in progress.
   
  
   [TSP] M. Blanchet, "IPv6 Tunnel Broker with the Tunnel Setup
   Protocol(TSP)". work in progress.
   
   [DSTM] J. Bound, "Dual Stack Transition Mechanism". Work in
   progress.

==> these must be moved over to Informative section, otherwise they'd block
the publication of this doc, and we don't want that.

editorial
---------

   The requirements for unmanaged networks are expressed by analyzing
   four classes of application: local, client, peer to peer, and

==> s/application/applications/ ?

   Automatic tunnels generally cannot provide the same level of
   service. The IPv6 address is only as stable as the underlying IPv4
   address,

==> s/address/address (and port)/ for Teredo case?

   These costs are largely inexistent when the tunnels are configured 

==> s/in/non-/ ?

   v6-v6 path. (The native ISP do not have an incentive to provide
   relays for general use; they are expected to restrict access to

==> s/do/does/ ?

   native or 6to4 hosts are de-facto multi-homed to native and Teredo,

==> s/multi-homed/"multi-homed"/ (this is probably not a considered real
multihoming...)

   require such mechanism, but they incur the risk of "head of queue   
   blocking", which may translate in poor performances. Given the

==> s/performances/performance/

   The automatic solutions have to rely on a "lower common denominator"

==> s/lower/lowest/ (or was this intentional?)

   today to carry IPv4, but in many cases could easily carry IPv6. For
   example, the IETF standard, L2TP, includes a PPP layer that can

==> s/, the IETF standard, L2TP,/L2TP,/ (it's not officially a standard, but
proposed stanadard, and this seems irrelevant here)

   IPv6 capable hosts may be willing to provide services accessible
   from the global Internet. They will thus need to document their
   address in a server that is publicly available. IPv4 hosts in

==> s/document/publish/

   A simplified form of case B occurs is a single host with a global

==> remove "occurs" ?

   [NAT-PT] Tsirtsis, G., and P. Srisuresh. "Network Address
   Translation - Protocol Translation (NAT-PT)." RFC 2766, February
   2000.

==> this reference was not used in the body of the draft, so remove?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings