Yes, I can provide text. A lot of the problems come from the specific name examples, so that requires some work. Early next week at best.
Sent from my Windows 10 phone From: Ted Lemon Sent: Friday, April 29, 2016 7:50 PM To: John R Levine Cc: dnsop WG; Christian Huitema Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-isp-ip6rdns On Apr 29, 2016 4:15 PM, "John Levine" <jo...@taugh.com> wrote: [Christian Huitema wrote:] >John is correct there. This draft appears to solve a marginal problem, while >creating a huge privacy issues. In fact, I could not find any privacy >consideration in the text, while provisions such are placing a user name and >location in a PTR record are really privacy hostile. I think the authors >should seriously look at the privacy issues and rewrite the draft before it >progresses any further. The document as written just documents the available options for populating the reverse tree, should the reader wish to do so. It does not specify any particular behavior. Describing it as privacy-hostile is nonsensical, since it doesn't recommend any behavior. The document could be improved by a privacy considerations section that describes the privacy considerations relating to those solutions that have privacy implications. This should be relatively straightforward and I can contribute text if Christian doesn't want to. The author is Lee Howard, who works for a large cable ISP. Perhaps he could just tell us what the motivation for the document is. This document was adopted by the working group. At that time, Lee explained in great detail what the motivation for the document is. I can actually picture him explaining. I am fairly sure he's done it more than once. Now that we are at last call, it is no longer the time for Lee to justify why this document exists. If there is a problem with it, you should tell us what it is. It also occurs to me that it'd be worth pointing out that contexts matter. For example, since my hosting provider doesn't handle v6 yet, I have the usual tunneled /64 from HE. They delegate the rDNS to me, I configure servers with fixed addresses and fixed rDNS and it works fine. That's a reasonable scenario (with or without the tunnel) for hosting customers. That's what I do too, frustratingly. But bearing in mind that this document is enumerating the set of possible approaches that ISPs could take, I think that's the context: the options ISPs have for addressing this problem, should they choose to do so (indeed, one of the options presented is "don't bother.") Responding to Stephane's criticism of the references to RFC 1912, I think I agree that referring to 1912 as BCP is not valid. 1912 was published quite a long time ago. I think there is substantial agreement within the IETF that the practices described in 1912 are not in any way "best." So publishing a document now that affirms what 1912 says isn't the right thing to do. This is easily fixed, though. Just don't refer to 1912 advice on PTR records as best practice. E.g.,: OLD: Best practice is that "Every Internet-reachable host should have a name" [RFC1912] that is recorded with a PTR resource record in the .ARPA zone, and "PTR's should use official names and not aliases" [RFC1033]. Some network services perform a PTR lookup on the source address of incoming packets before performing services. NEW: RFC 1912 recommended that "every internet-reachable host should have a name" and says "Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all." Although the second of these two recommendations is no longer considered to be a "best practice," some network services still do perform a PTR lookip on the source address of incoming connections and verify that the PTR and A records match before providing service. This actually looks like an oversight--everywhere else in the document the text is clear that supporting this particular behavior as documented in RFC 1912 is not required, but just something ISPs might do to support services that require RFC 1912 compliance.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
