[DNSOP] comments on draft-howard-isp-ip6rdns-01

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

I've read this document.  I don't have a strong opinion on the content
(after all, it's an analysis document, not proposing something
specific), but I've found it generally sensible.  So, if the question
is whether to adopt it as a wg item, I'd say yes.

Here are some technical comments and minor nits.

- Section 1.1

         1.user.anytown.AW.example.com.  IN A 1.2.0.192.IN-ADDR-ARPA.
         2.user.anytown.AW.example.com.  IN A 2.2.0.192.IN-ADDR-ARPA.
	 ...
these should be
         1.user.anytown.AW.example.com.  IN A 192.0.2.1
	 etc.

- Section 1.2

   A sample entry for 2001:db8:f00::0012:34ff:fe56:789a
   might be:

  This doesn't follow the recommended textual format described in
  draft-ietf-6man-text-addr-representation-01:-)
  Besides, the format seems to be awkward (even though it's completely
  valid syntax-wise) in that the leading zeros are omitted in some
  16-bit fields (db8 and f00) and included in some other (0012).  It's
  not a strong opinion, but I'd suggest formatting the address in some
  seemingly consistent manner.  For example,
  2001:db8:f00:0:12:34ff:fe56:789a
  (this is the draft-ietf-6man-text-addr-representation-01 style)
  or
  2001:0db8:0f00:0000:0012:34ff:fe56:789a

- Section 1.2

   Since 2^^96 possible addresses could be configured in the 2001:db8:
   f00/48 zone alone, it is impractical to write a zone with every

  2^^96 should be 2^^80 and f00/48 should f00::/48.
  Likewise, the subsequent sentence may be fixed accordingly:

   If 1000 entries could be written per
   second, the zone would still not be complete after two quintillion
   years.

 I didn't check the math but if "two quintillion" corresponds to
 2^^96, it should be updated.

- Section 1.2

   Furthermore, since the 64 bits in the host portion of the address are
   frequently assigned using SLAAC [RFC4826] when the host comes online,

 s/[RFC4826]/[RFC4862]/
 The same fix should apply to Section 5.1.

- Section 2.1

   Some ISP DNS administrators may choose to provide only a NXDOMAIN
   response to PTR queries for subscriber addresses.

 I'd suggest changing NXDOMAIN to NXDomain per
 http://www.iana.org/assignments/dns-parameters (thanks to Peter for
 telling me the reference).

- Section 2.1

   Providing no data
   in response to PTR queries does not satisfy the expectation in
   [RFC1912] for entries to match.

 I'm afraid the phrase "no data" might be misleading here, because it
 can specifically mean a "NoError, no answer" response.  But in this
 context it should mean a more general failure (or actually intending
 NXDomain rather than "NoError, no answer").  I'd change "no data" to,
 e.g., "a negative response"

- Section 2.2

   Consider a PTR lookup on 2001:db8:f00:1234:0012:34ff:fe56:789a
   against the following entries:
   [...3 possible RRs]
   The administrator should determine what response would be returned
   for such a query.

 I didn't understand the last sentence in this context.  If a zone has
 the three listed RRs, there's no room for administrator decision: the
 second PTR will be the answer with no ambiguity.  Maybe I simply
 misunderstand the text.  Could you clarify that?

- Section 2.3.

   No authentication of dynamic
   DNS updates is inherently provided; implementers should consider use
   of DNSsec [RFC2535], [...]

 I don't understand how RFC2535 helps here.  Did you actually mean
 RFC2845 (TSIG)?  BTW, if this really means RFC2535, RFC403x variants
 would be a better reference, and the common acronym is all capital:
 DNSSEC.

- Section 2.3.1

   Since the typical residential user cannot
   configure IPv6 addresses and resolving name servers on their hosts,
   the ISP should provide address information conventionally (i.e.,
   their normal combination of RAs, SLAAC, DHCP, etc.), [...]

 How are RAs and SLAAC different in this context?

- Section 2.3.1

   Once it learns its address, and has a resolving name server, the host
   must perform an SOA lookup on the ip6.arpa record to be added, to
   find the owner, which will lead to the NS record.

 I don't understand the "which will lead to the NS record" part.  My
 understanding is that the SOA lookup will "lead to" the SOA record of
 the appropriate ip6.arpa zone, whose MNAME field gives the primary
 server to which dynamic update requests should be sent.  I don't
 understand how NS is related here.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.