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-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of JINMEI > Tatuya / ???? > Sent: Tuesday, November 10, 2009 9:51 AM > To: lee.how...@twcable.com; alain_dur...@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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
