Re: [DNSOP] draft-howard-isp-ip6rdns-07.txt
>Looking for a few folks to do a close read. Send notes to the list, and >I'll make necessary revisions. If it's baked, I think there's consensus. I read through it. It's basically fine but of course here are a few suggestions. I'd redo sec 1.2 to make it clearer what the serious problems are. I don't think that the length of the names is a big deal, computers can deal with that. The problems are a) the address space is far too large to cover with static names as we do in IPv4 and, b) you can't easily tell where the hosts are. On IPv4 networks, addresses are usually configured either statically or by DHCP, so the network operator knows what addresses are assigned befor the hosts do. On IPv6, SLAAC means that hosts choose addresses effectively at random, so there are new and not widely used mechanisms (described later) to percolate those addresses back to the network and assign names to them. It would also be reasonable to offer as a concrete proposal that hosts with static addresses have forward and reverse DNS, while those without have no rDNS, and don't have forward DNS provided by the ISP. (If they want to use dyndns, go ahead.) In the list of ways to dynamically insert DNS records, it seems to me that most current home gateways are plenty capable to act as DNS servers or whatever, so the issue isn't that they can't, but that nontechnical users wouldn't be able to manage them, while malware would. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-howard-isp-ip6rdns-07.txt
Lee, I will read through this in the next day or so. Thanks, Sean > On Mar 31, 2015, at 9:46 AM, Lee Howard wrote: > > There's been no discussion since this revision. > The Chairs have asked for a couple of reviews. I've asked a couple of > folks, but haven't had any response. > > Looking for a few folks to do a close read. Send notes to the list, and > I'll make necessary revisions. If it's baked, I think there's consensus. > > Thanks, > > Lee > >> On 2/15/15, 11:56 AM, "Lee Howard" wrote: >> >> Per discussion, I have added the four use cases discussed at a previous >> meeting. >> The "Recommendations" section is now "Considerations and Recommendations." >> The guidance from the WG was that ISPs should be advised of how PTRs are >> used, so they can decide how important it is to populate them. I left in >> the recommendations from before, since an ISP might decide it's important. >> >> I think the references to other ongoing work are up to date, but let me >> know if I've missed anything, please. >> >> We had pretty strong support the last time we discussed aloud (spontaneous >> applause). Is this document ripe for publication? >> >> >> Thanks, >> Lee >> >> On 2/15/15 11:46 AM, "internet-dra...@ietf.org" >> wrote: >> >>> >>> A new version of I-D, draft-howard-isp-ip6rdns-07.txt >>> has been successfully submitted by Lee Howard and posted to the >>> IETF repository. >>> >>> Name:draft-howard-isp-ip6rdns >>> Revision:07 >>> Title:Reverse DNS in IPv6 for Internet Service Providers >>> Document date:2015-02-16 >>> Group:Individual Submission >>> Pages:14 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-howard-isp-ip6rdns-07.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-howard-isp-ip6rdns/ >>> Htmlized: http://tools.ietf.org/html/draft-howard-isp-ip6rdns-07 >>> Diff: >>> http://www.ietf.org/rfcdiff?url2=draft-howard-isp-ip6rdns-07 >>> >>> Abstract: >>> In IPv4, Internet Service Providers (ISPs) commonly provide IN- >>> ADDR.ARPA information for their customers by prepopulating the zone >>> with one PTR record for every available address. This practice does >>> not scale in IPv6. This document analyzes different approaches and >>> considerations for ISPs in managing the ip6.arpa zone for IPv6 >>> address space assigned to many customers. >>> >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >> >> >> ___ >> 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [Errata Verified] RFC7477 (4307)
The following errata report has been verified for RFC7477, "Child-to-Parent Synchronization in DNS". -- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7477&eid=4307 -- Status: Verified Type: Editorial Reported by: Donald Eastlake 3rd Date Reported: 2015-03-19 Verified by: Kathleen Moriarty (IESG) Section: sec 2, page 4 Original Text - nonpunishable data Corrected Text -- nonpublishable data Notes - confusing typo, confirmed with author. -- RFC7477 (draft-ietf-dnsop-child-syncronization-07) -- Title : Child-to-Parent Synchronization in DNS Publication Date: March 2015 Author(s) : W. Hardaker Category: PROPOSED STANDARD Source : Domain Name System Operations Area: Operations and Management Stream : IETF Verifying Party : IESG ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-howard-isp-ip6rdns-07.txt
Commenting on an old draft I had worked/started with Lee on many years ago! 1) The intro should make it clear that this document DOES NOT recommend any solutions, it just describe the trade-offs. In fact, none of the solutions are really good. 2) there should be a longer discussion of hosts using privacy extensions RFC4941. What is the intended behavior here? Do those hosts need/want a reverse DNS entry? There is some text in section 2.3.1 but, IMHO, there should be a whole section toward the beginning of the document discussing this. 3) There is another solution, that is do nothing, i.e. Do NOT populate the reverse tree. Probably ISPs on that path would like to see an update to RFC1033 & RFC1912 to explicitly say that the PTR record requirement is relaxed in IPv6 (and maybe in IPv4 as well?) The mere fact that this draft is still here many years after the effort was started should tell us something It would appear as if the world is on path 3) above. Alain. On 3/31/15, 9:46 AM, "Lee Howard" wrote: >There's been no discussion since this revision. >The Chairs have asked for a couple of reviews. I've asked a couple of >folks, but haven't had any response. > >Looking for a few folks to do a close read. Send notes to the list, and >I'll make necessary revisions. If it's baked, I think there's consensus. > >Thanks, > >Lee > >On 2/15/15, 11:56 AM, "Lee Howard" wrote: > >>Per discussion, I have added the four use cases discussed at a previous >>meeting. >>The "Recommendations" section is now "Considerations and >>Recommendations." >>The guidance from the WG was that ISPs should be advised of how PTRs are >>used, so they can decide how important it is to populate them. I left in >>the recommendations from before, since an ISP might decide it's >>important. >> >>I think the references to other ongoing work are up to date, but let me >>know if I've missed anything, please. >> >>We had pretty strong support the last time we discussed aloud >>(spontaneous >>applause). Is this document ripe for publication? >> >> >>Thanks, >>Lee >> >>On 2/15/15 11:46 AM, "internet-dra...@ietf.org" >> >>wrote: >> >>> >>>A new version of I-D, draft-howard-isp-ip6rdns-07.txt >>>has been successfully submitted by Lee Howard and posted to the >>>IETF repository. >>> >>>Name:draft-howard-isp-ip6rdns >>>Revision:07 >>>Title: Reverse DNS in IPv6 for Internet Service Providers >>>Document date: 2015-02-16 >>>Group: Individual Submission >>>Pages: 14 >>>URL: >>>http://www.ietf.org/internet-drafts/draft-howard-isp-ip6rdns-07.txt >>>Status: >>>https://datatracker.ietf.org/doc/draft-howard-isp-ip6rdns/ >>>Htmlized: http://tools.ietf.org/html/draft-howard-isp-ip6rdns-07 >>>Diff: >>>http://www.ietf.org/rfcdiff?url2=draft-howard-isp-ip6rdns-07 >>> >>>Abstract: >>> In IPv4, Internet Service Providers (ISPs) commonly provide IN- >>> ADDR.ARPA information for their customers by prepopulating the zone >>> with one PTR record for every available address. This practice does >>> not scale in IPv6. This document analyzes different approaches and >>> considerations for ISPs in managing the ip6.arpa zone for IPv6 >>> address space assigned to many customers. >>> >>> >>> >>> >>> >>>Please note that it may take a couple of minutes from the time of >>>submission >>>until the htmlized version and diff are available at tools.ietf.org. >>> >>>The IETF Secretariat >>> >> >> >>___ >>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 smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-howard-isp-ip6rdns-07.txt
Hi Lee, I will review. Thanks, Stephan > -Original Message- > From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Lee Howard > Sent: Tuesday, March 31, 2015 6:47 AM > To: dnsop@ietf.org > Subject: [DNSOP] draft-howard-isp-ip6rdns-07.txt > > There's been no discussion since this revision. > The Chairs have asked for a couple of reviews. I've asked a couple of folks, > but haven't had any response. > > Looking for a few folks to do a close read. Send notes to the list, and I'll > make > necessary revisions. If it's baked, I think there's consensus. > > Thanks, > > Lee > > On 2/15/15, 11:56 AM, "Lee Howard" wrote: > > >Per discussion, I have added the four use cases discussed at a previous > >meeting. > >The "Recommendations" section is now "Considerations and > Recommendations." > >The guidance from the WG was that ISPs should be advised of how PTRs > >are used, so they can decide how important it is to populate them. I > >left in the recommendations from before, since an ISP might decide it's > important. > > > >I think the references to other ongoing work are up to date, but let me > >know if I've missed anything, please. > > > >We had pretty strong support the last time we discussed aloud > >(spontaneous applause). Is this document ripe for publication? > > > > > >Thanks, > >Lee > > > >On 2/15/15 11:46 AM, "internet-dra...@ietf.org" > > > >wrote: > > > >> > >>A new version of I-D, draft-howard-isp-ip6rdns-07.txt has been > >>successfully submitted by Lee Howard and posted to the IETF > >>repository. > >> > >>Name: draft-howard-isp-ip6rdns > >>Revision: 07 > >>Title: Reverse DNS in IPv6 for Internet Service Providers > >>Document date: 2015-02-16 > >>Group: Individual Submission > >>Pages: 14 > >>URL: > >>http://www.ietf.org/internet-drafts/draft-howard-isp-ip6rdns-07.txt > >>Status: > >>https://datatracker.ietf.org/doc/draft-howard-isp-ip6rdns/ > >>Htmlized: http://tools.ietf.org/html/draft-howard-isp-ip6rdns-07 > >>Diff: > >>http://www.ietf.org/rfcdiff?url2=draft-howard-isp-ip6rdns-07 > >> > >>Abstract: > >> In IPv4, Internet Service Providers (ISPs) commonly provide IN- > >> ADDR.ARPA information for their customers by prepopulating the zone > >> with one PTR record for every available address. This practice does > >> not scale in IPv6. This document analyzes different approaches and > >> considerations for ISPs in managing the ip6.arpa zone for IPv6 > >> address space assigned to many customers. > >> > >> > >> > >> > >> > >>Please note that it may take a couple of minutes from the time of > >>submission until the htmlized version and diff are available at > >>tools.ietf.org. > >> > >>The IETF Secretariat > >> > > > > > >___ > >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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-howard-isp-ip6rdns-07.txt
There's been no discussion since this revision. The Chairs have asked for a couple of reviews. I've asked a couple of folks, but haven't had any response. Looking for a few folks to do a close read. Send notes to the list, and I'll make necessary revisions. If it's baked, I think there's consensus. Thanks, Lee On 2/15/15, 11:56 AM, "Lee Howard" wrote: >Per discussion, I have added the four use cases discussed at a previous >meeting. >The "Recommendations" section is now "Considerations and Recommendations." >The guidance from the WG was that ISPs should be advised of how PTRs are >used, so they can decide how important it is to populate them. I left in >the recommendations from before, since an ISP might decide it's important. > >I think the references to other ongoing work are up to date, but let me >know if I've missed anything, please. > >We had pretty strong support the last time we discussed aloud (spontaneous >applause). Is this document ripe for publication? > > >Thanks, >Lee > >On 2/15/15 11:46 AM, "internet-dra...@ietf.org" >wrote: > >> >>A new version of I-D, draft-howard-isp-ip6rdns-07.txt >>has been successfully submitted by Lee Howard and posted to the >>IETF repository. >> >>Name: draft-howard-isp-ip6rdns >>Revision: 07 >>Title:Reverse DNS in IPv6 for Internet Service Providers >>Document date:2015-02-16 >>Group:Individual Submission >>Pages:14 >>URL: >>http://www.ietf.org/internet-drafts/draft-howard-isp-ip6rdns-07.txt >>Status: >>https://datatracker.ietf.org/doc/draft-howard-isp-ip6rdns/ >>Htmlized: http://tools.ietf.org/html/draft-howard-isp-ip6rdns-07 >>Diff: >>http://www.ietf.org/rfcdiff?url2=draft-howard-isp-ip6rdns-07 >> >>Abstract: >> In IPv4, Internet Service Providers (ISPs) commonly provide IN- >> ADDR.ARPA information for their customers by prepopulating the zone >> with one PTR record for every available address. This practice does >> not scale in IPv6. This document analyzes different approaches and >> considerations for ISPs in managing the ip6.arpa zone for IPv6 >> address space assigned to many customers. >> >> >> >> >> >>Please note that it may take a couple of minutes from the time of >>submission >>until the htmlized version and diff are available at tools.ietf.org. >> >>The IETF Secretariat >> > > >___ >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
