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

Thank you, these are excellent suggestions.
In particular, you raise several points that require clarification; I will
try to respond in the near future.

Lee

> -----Original Message-----
> From: dnsop-bounces@ietf.org [mailto:dnsop-bounces@ietf.org] On Behalf Of
JINMEI
> Tatuya / ????
> Sent: Tuesday, November 10, 2009 9:51 AM
> To: lee.howard@twcable.com; alain_durand@cable.comcast.com
> Cc: dnsop@ietf.org
> Subject: [DNSOP] comments on draft-howard-isp-ip6rdns-01
> 
> 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.
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop