[arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-6: Remove Operational Reverse DNS Text

Mon Apr 27 12:42:24 EDT 2015

Vote against..

In my opinion, the granting of a public IPv4 (or IPv6) address space 
SHOULD come alone with some responsibility, including 
'rwhois/SWIP/routing/rDNS obligations'.

I would rather have more work done by the community at large to reach 
consensus on those things, even IF ARIN has little enforcement mandate 
at this time, we should be able to reference it in discussions.

I suggest abandoning "Recommended Draft Policy ARIN-2014-6" and work on 
better language.

On 15-04-27 09:05 AM, ARIN wrote:
> The ARIN Advisory Council (AC) met on 15 April 2015 and decided to
> send the following to last call:
>
>    Recommended Draft Policy ARIN-2014-6: Remove Operational Reverse DNS
> Text
>
> Feedback is encouraged during the last call period. All comments should
> be provided to the Public Policy Mailing List. This last call will
> expire on 11 May 2015. After last call the AC will conduct their
> last call review.
>
> The draft policy text is below and available at:
> https://www.arin.net/policy/proposals/
>
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Recommended Draft Policy ARIN-2014-6
> Remove Operational Reverse DNS Text (was: Remove 7.1)
>
> Date: 21 January 2014
>
> AC's assessment of conformance with the Principles of Internet Number
> Resource Policy:
>
> 2014-6 enables fair and impartial number resource administration by
> removing technical statements that are not related to number policy from
> the NRPM. It is technically sound to remove operational practice from
> the NRPM; indeed this act serves as a forcing function for a best
> practices document that is both more detailed and more approachable than
> the policy statement that was removed. Discussion of the previous
> revision of 2014-6 centered around "why are you fixing this for IPv4 and
> not IPv6", and the most recent changes reflect that community feedback.
> There has not been notable opposition to the notion of removing
> operational language from the NRPM.
>
> Problem Statement:
>
> 7.1 attempts to assert rules on rDNS management at ARIN. It fails to do
> so because it only addresses in-addr.arpa (missing equally important
> rules in ip6.arpa). It's also not based on any RFC; it's an arbitrary
> decision made by ARIN technical staff. We should remove this text from
> policy, as it represents operational practice rather than ARIN number
> policy.
>
> In feedback received at public policy meetings and on the PPML mailing
> list, the Community expressed a desire for IPv4 and IPv6 policy on
> reverse DNS to be congruent (that is to say, it makes no sense to remove
> 7.1 without addressing 6.5.6 which is similarly operationally
> prescriptive) and bring this proposal forward again.
>
> Policy statement:
>
> Remove 7.1
>
> Remove 6.5.6
>
> Comments:
>
> a.Timetable for implementation: Immediate
>
> b.Anything else:
> 7.1. Maintaining IN-ADDRs
>
> All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses
> from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain
> records for their respective customers. For blocks smaller than /16, and
> for the segment of larger blocks  smaller than /16, ARIN can maintain
> IN-ADDRs.
>
> 6.5.6. Reverse lookup
>
> When an RIR delegates IPv6 address space to an organization, it also
> delegates the responsibility to manage the reverse lookup zone that
> corresponds to the allocated IPv6 address space. Each organization
> should properly manage its reverse lookup zone. When making an address
> assignment, the organization must delegate to an assignee organization,
> upon request, the responsibility to manage the reverse lookup zone that
> corresponds to the assigned address.
>
> #####
>
> ARIN STAFF & LEGAL ASSESSMENT
>
> Draft Policy ARIN-2014-6
> Remove Operational Reverse DNS Text
>
> Date of Assessment: March 17, 2015
>
> 1. Summary (Staff Understanding)
> This proposal would remove 6.5.6 and 7.1, thus removing reverse DNS
> language from the NRPM.
>
> 2. Comments
> A. ARIN Staff Comments
> This change to NRPM will not change the DNS service that ARIN performs.
> This proposal can be implemented as written.
>
> ARIN registration services staff occasionally receives a telephone or
> email inquiry asking how reverse DNS services can be set up for a
> company. In the cases the company is a downstream customer of an ISP who
> has received a direct allocation from ARIN, staff explains this service
> can be set up for them by their service provider. On rare occasion, the
> company presses for a reference that states this is done by their ISP,
> and not ARIN. In those cases staff will refer them to the language
> currently in the NRPM.
>
> In the case the language is removed from NRPM, ARIN staff will create a
> resource for the ARIN public website that describes how ARIN's Reverse
> DNS services are provided; including who is able to establish Reverse
> DNS service for different types of registration records.
>
> B. ARIN General Counsel â€“ Legal Assessment
> The policy does not create legal concerns.
>
> 3. Resource Impact
> This policy would have minimal impact from an implementation standpoint.
> It is estimated implementation would occur within 3 months after
> ratification by the ARIN Board of Trustees. The following tasks will be
> completed for implementation:
> Versioned change to NRPM
> Updated guidelines on ARIN website describing reverse DNS services (to
> act as general information resource and serve as new reference point for
> situation described in staff comments).
> Staff training
>
> 4. Proposal / Draft Policy Text Assessed
>
> Draft Policy ARIN-2014-6
> Remove Operational Reverse DNS Text (was: Remove 7.1)
>
> Date: 21 January 2015
>
> Problem Statement:
>
> 7.1 attempts to assert rules on rDNS management at ARIN. It fails to do
> so because it only addresses in-addr.arpa (missing equally important
> rules in ip6.arpa). It's also not based on any RFC; it's an arbitrary
> decision made by ARIN technical staff. We should remove this text from
> policy, as it represents operational practice rather than ARIN number
> policy.
>
> In feedback received at public policy meetings and on the PPML mailing
> list, the Community expressed a desire for IPv4 and IPv6 policy on
> reverse DNS to be congruent (that is to say, it makes no sense to remove
> 7.1 without addressing 6.5.6 which is similarly operationally
> prescriptive) and bring this proposal forward again.
>
> Policy statement:
>
> Remove 7.1
>
> Remove 6.5.6
>
> Comments:
>
> a.Timetable for implementation: Immediate
>
> b.Anything else:
>
> 7.1. Maintaining IN-ADDRs
>
> All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses
> from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain
> records for their respective customers. For blocks smaller than /16, and
> for the segment of larger blocks smaller than /16, ARIN can maintain
> IN-ADDRs.
>
> 6.5.6. Reverse lookup
>
> When an RIR delegates IPv6 address space to an organization, it also
> delegates the responsibility to manage the reverse lookup zone that
> corresponds to the allocated IPv6 address space. Each organization
> should properly manage its reverse lookup zone. When making an address
> assignment, the organization must delegate to an assignee organization,
> upon request, the responsibility to manage the reverse lookup zone that
> corresponds to the assigned address.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.