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" <l...@asgard.org> 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" <l...@asgard.org> 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"
>><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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to