durand-v6ops-natpt-dns-alg-issues-00 comments

[Pekka Savola <pekkas@netcore.fi>]

Hi,

A few comments.  There seems to be some bashing of DNSALG, but there is a 
draft on how to fix those issues too -- and AFAIR, it fixes adequately 
most of the issues.  Instead bashing DNS-ALG and advocating NAT-PT++ 
perhaps a more comprehensive look at the subject would be useful.

One robustness comment below, the rest are editorials.

5.2 Robustness of NAT-PT with DNS-ALG

   The DNS-ALG needs to actively monitor the NAT-PT boxes, to detect the
   potential failure of one of them and remove it from the list of valid
   translators. In practice, this means that the prefix associated to
   that translator will not be used anymore by the DNS-ALG to respond to
   DNS queries.  For this to work, the DNS-ALG must set the TTL of the
   DNS answer to zero and user applications are expected to respect that
   TTL, i.e. not cache the name to address mapping, even for a short
...

==> same routing the prefix-approach applies with DNS-ALG too.

editorials
----------

Status of this memo

   This memo provides information to the Internet community.  It does
   not specify an Internet standard of any kind.  This memo is in full
   conformance with all provisions of Section 10 of RFC2026 [RFC2026].

==> boilerplate is missing newlines etc.

1. Introduction:  non DNS ALG solution

   Note: This section does not provide a complete description of a non
   DNS ALG solution for NAT-PT, but provide a quick overview of such a
==> s/provide/provides/

   solution to understand better the discussions of the next sections.
==> s/understand better/better understand/

   The way this is envision to work is that an IPv6 application running
==> s/envision/envisioned/

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