[ppml] Policy Proposal: IPv6 Policy Housekeeping - version 2.0
David Williamson
dlw+arin at tellme.com
Fri Aug 31 16:04:57 EDT 2007
I agree entirely. This proposal simply makes sense of policy that was
previously ambiguous or missing.
I'll also agree that the only point of controversy is that that LIR
language, although I also fully support that change. The loophole
could be broadly interpreted as "if you are a big enough company, you
can have IPv6 space - if you are a smaller org, too bad." (The
implementation of the IPv6 PI policy finally put that specific concern
to bed.) Closing the loophole will point large companies at the PI
policy, which also seems like a good plan.
Thanks, Leo, for the effort in driving this one!
-David
On Fri, Aug 31, 2007 at 12:40:43PM -0700, Scott Leibrand wrote:
> Thanks for the explanation.
>
> I support this proposal, as a good and useful cleanup. The only thing
> that seems even remotely controversial to me would be the clarifications
> that your 200 assignments to get an LIR /32 need to be to "other
> organizations". I think this is what was originally intended by the LIR
> /32 policy, and will close a loophole used by some organizations to get
> a /32 when they probably should have gotten IPv6 PI space instead.
>
> -Scott
>
> Leo Bicknell wrote:
> > It's also probably not obvious what happened here.
> >
> > The AC is working with staff on making the NRPM more clear; the
> > intention is to do some minor editing that does not change any
> > policy. Things like improved defintions, better cross references,
> > etc. The AC felt that my original proposal had both policy changes
> > and these sorts of edits in it.
> >
> > The edits have been removed and put in the hopper with the larger
> > editing project which will appear in the future. What's left below
> > are the changes the AC belived are policy changes.
> >
> > Back to my original purpose. I actually don't want to change policy
> > with this cleanup, however there are some places where the policy
> > is ambiguous, or worse not self consisent. In the cases below the
> > "fix" is to make policy, to make it consistent and clear. I have
> > picked what I believe are the most straightforward ways of making
> > the policy clear and consisent however since the isse has been
> > brought up I suspect people will want to debate the points in more
> > detail, and that's fine.
> >
> > To reduce confusion, I've left the change letters the same as before;
> > however there are only now four in this policy.
> >
> > In a message written on Fri, Aug 31, 2007 at 10:18:19AM -0400, Member Services wrote:
> >
> >> The author submitted a revised version of their proposal.
> >>
> >> Regards,
> >>
> >> Member Services
> >> American Registry for Internet Numbers (ARIN)
> >>
> >>
> >> ## * ##
> >>
> >> 1. Policy Proposal Name: IPv6 Policy Housekeeping
> >> 2. Author
> >> 1. name: Leo Bicknell
> >> 2. email: bicknell at ufp.org
> >> 3. telephone: 901 853 9404
> >> 4. organization: Internet Systems Consortium, Inc.
> >> 3. Proposal Version: 2.0
> >> 4. Submission Date: 8/29/2007
> >> 5. Proposal type: modify
> >> 6. Policy term: permanent
> >> 7. Policy statement:
> >>
> >> Change I:
> >>
> >> In section 6.5.1.1.d, replace the existing statement with the new
> >> statement:
> >>
> >> "be an existing, known ISP in the ARIN region or have a plan for
> >> making at least 200 end-site assignments to other organizations
> >> within 5 years."
> >>
> >> Change J:
> >>
> >> Remove section 6.5.3 entirely. Update all subsequent sections to
> >> have new section numbers (6.5.[n-1]).
> >>
> >> Replace part of the text as (new) section 6.5.4.4:
> >>
> >> "All /56 and larger assignments to end sites are required to be
> >> registered either by the LIR or its subordinate ISPs in
> >> such a way that the RIR/NIR can properly evaluate the
> >> HD-Ratio when a subsequent allocation becomes necessary."
> >>
> >> Change K:
> >>
> >> Section 6.5.8.2, add the following sentence to the end of the first
> >> paragraph:
> >>
> >> "An HD-Ratio of .94 must be met for all assignments larger than
> >> a /48."
> >>
> >> Add to the end of the second paragraph:
> >>
> >> "This reservation may be assigned to other organizations
> >> later, at ARIN's discretion."
> >>
> >> Change L:
> >>
> >> Section 6.5.8.3, add a sentence between the two existing sentences:
> >>
> >> "Justification will be determined based on the .94 HD-Ratio
> >> metric."
> >>
> >> 8. Rationale:
> >>
> >> When the IPv6 policy was passed, it was considered to be an "interim"
> >> policy, and it was intended to be similar in all 5 RIR's. Since that
> >> time it has become clear the policy is no longer interim (and proposal
> >> 2007-4 was passed to change just that) and it has also been modified
> >> separately in the different RIR's.
> >>
> >> It was brought to the ARIN AC's attention that there were a number of
> >> problems with "Section 6" of the NRPM as a result of this legacy:
> >>
> >> * The policy contained a large number of items that were not policy.
> >> * The policy contained a few items that were self contradictory.
> >> * The added text was redundant in some cases with existing text.
> >> * The policy was overly vague in a few areas, leaving ARIN staff to
> >> have to make interpretations of what the policy intended.
> >> * Policy changes made since the initial IPv6 policy was adopted have
> >> not always updated all of the relevant sections due to the complexity
> >> of section 6.
> >>
> >> The intent of these changes is not to change any existing policy, but
> >> rather to remove all non-policy items, and update any ambiguous items
> >> with the way that ARIN staff is currently interprets the policy.
> >>
> >> Change I:
> >>
> >> Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64
> >> allocations, but section 6.5.1.1.d was never updated to match
> >> the change. It is believed the intent of the policy, and ARIN
> >> staff's current interpretation of the policy match the updated
> >> text.
> >>
> >> Change J:
> >>
> >> The first part is not policy, and incorrectly states there is no
> >> policy as section 6.5.4 has the policy in it. Take the one useful
> >> part and make it part of the 6.5.4 criteria.
> >>
> >> Change K:
> >>
> >> No metric is currently listed to justify a larger initial
> >> assignment. It is believed ARIN staff is currently applying
> >> the HD-Ratio similar to the ISP policy, this puts that in writing.
> >>
> >> Make it clear that the reservation may not exist in perpetuity.
> >>
> >> Change L:
> >>
> >> No metric is given to justify additional assignments. It is
> >> believed that ARIN staff is currently applying the HD_Ratio
> >> similar to the ISP policy, this puts that in writing.
> >>
> >> 9. Timetable for implementation: Immediate.
> >> 10. Meeting presenter: Leo Bicknell
> >>
> >> END OF TEMPLATE
> >>
> >>
> >> Member Services wrote:
> >>
> >>> ARIN received the following policy proposal. In accordance with the ARIN
> >>> Internet Resource Policy Evaluation Process, the proposal is being
> >>> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
> >>> ARIN's website.
> >>>
> >>> The ARIN Advisory Council (AC) will review this proposal at their next
> >>> regularly scheduled meeting. The AC may decide to:
> >>>
> >>> 1. Accept the proposal as a formal policy proposal as written. If the
> >>> AC accepts the proposal, it will be posted as a formal policy proposal
> >>> to PPML and it will be presented at a Public Policy Meeting.
> >>>
> >>> 2. Postpone their decision regarding the proposal until the next
> >>> regularly scheduled AC meeting in order to work with the author. The AC
> >>> will work with the author to clarify, combine or divide the proposal. At
> >>> their following meeting the AC will accept or not accept the proposal.
> >>>
> >>> 3. Not accept the proposal. If the AC does not accept the proposal,
> >>> the AC will explain their decision. If a proposal is not accepted, then
> >>> the author may elect to use the petition process to advance their
> >>> proposal. If the author elects not to petition or the petition fails,
> >>> then the proposal will be closed.
> >>>
> >>> The AC will assign shepherds in the near future. ARIN will provide the
> >>> names of the shepherds to the community via the PPML.
> >>>
> >>> In the meantime, the AC invites everyone to comment on this proposal on
> >>> the PPML, particularly their support or non-support and the reasoning
> >>> behind their opinion. Such participation contributes to a thorough
> >>> vetting and provides important guidance to the AC in their deliberations.
> >>>
> >>> The ARIN Internet Resource Policy Evaluation Process can be found at:
> >>> http://www.arin.net/policy/irpep.html
> >>>
> >>> Mailing list subscription information can be found at:
> >>> http://www.arin.net/mailing_lists/
> >>>
> >>> Regards,
> >>>
> >>> Member Services
> >>> American Registry for Internet Numbers (ARIN)
> >>>
> >>>
> >>> ## * ##
> >>>
> >>>
> >>> Policy Proposal Name: IPv6 Policy Housekeeping
> >>>
> >>> Author: Leo Bicknell
> >>>
> >>> Proposal Version: 1.0
> >>>
> >>> Submission Date: 8/17/2007
> >>>
> >>> Proposal type: modify
> >>>
> >>> Policy term: permanent
> >>>
> >>> Policy statement:
> >>>
> >>> Change A:
> >>>
> >>> Remove the text between the section 6 header and the section 6.1
> >>> header. Remove section 6.1 entirely. Update all subsequent
> >>> sections to have new section numbers (6.[n-1]).
> >>>
> >>> Change B:
> >>>
> >>> Move the image in section 6.2 to section 2.
> >>>
> >>> Remove sections 6.2.1 to 6.2.6.
> >>>
> >>> Change C:
> >>>
> >>> Move section 6.2.7 to (new) section 2.8, subheading "IPv6".
> >>>
> >>> Create section 2.8, subheading "IPv4", containing the following text:
> >>>
> >>> In IPv4, utilization is the percentage of the address space
> >>> allocated or assigned relative to the total address space.
> >>>
> >>> Change D:
> >>>
> >>> Move section 6.2.8 to (new) section 2.8.
> >>> Move section 6.2.9 to (new) section 2.9.
> >>>
> >>> As this leaves section 6.2 empty, remove section 6.2. Update
> >>> all subsequent sections to have new section numbers (6.[n-1]).
> >>>
> >>>
> >>> Change E:
> >>>
> >>> Remove section 6.3. Update all subsequent sections to have new
> >>> section numbers (6.[n-1]).
> >>>
> >>> Change F:
> >>>
> >>> Remove section 6.4.1. Update all subsequent sections to have new
> >>> section numbers (6.4.[n-1]).
> >>>
> >>> Change G:
> >>>
> >>> Remove section 6.4.2. Update all subsequent sections to have new
> >>> section numbers (6.4.[n-1]).
> >>>
> >>> Change H:
> >>>
> >>> Remove section 6.4.4.
> >>>
> >>> Change I:
> >>>
> >>> In section 6.5.1.1.d, replace the existing statement with the new
> >>> statement:
> >>>
> >>> "be an existing, known ISP in the ARIN region or have a plan for
> >>> making at least 200 end-site assignments to other organizations
> >>> within 5 years."
> >>>
> >>> Change J:
> >>>
> >>> Remove section 6.5.3 entirely. Update all subsequent sections to
> >>> have new section numbers (6.5.[n-1]).
> >>>
> >>> Replace part of the text as (new) section 6.5.4.4:
> >>>
> >>> "All /56 and larger assignments to end sites are required to be
> >>> registered either by the LIR or its subordinate ISPs in
> >>> such a way that the RIR/NIR can properly evaluate the
> >>> HD-Ratio when a subsequent allocation becomes necessary."
> >>>
> >>> Change K:
> >>>
> >>> Section 6.5.8.2, add the following sentence to the end of the first
> >>> paragraph:
> >>>
> >>> "An HD-Ratio of .94 must be met for all assignments larger than
> >>> a /48."
> >>>
> >>> Add to the end of the second paragraph:
> >>>
> >>> "This reservation may be assigned to other organizations
> >>> later, at ARIN's discretion."
> >>>
> >>> Change L:
> >>>
> >>> Section 6.5.8.3, add a sentence between the two existing sentences:
> >>>
> >>> "Justification will be determined based on the .94 HD-Ratio
> >>> metric."
> >>>
> >>> Change M:
> >>>
> >>> Remove section 6.6. Update all subsequent sections to have new
> >>> section numbers (6.[n-1]).
> >>>
> >>> Change N:
> >>>
> >>> Change the title of section 6.7 from "Appendix A: HD-Ratio" to
> >>> "HD-Ratio".
> >>>
> >>> Change O:
> >>>
> >>> Remove section 6.8. Update all subsequent sections to have new
> >>> section numbers (6.[n-1]).
> >>>
> >>> Rationale:
> >>>
> >>> When the IPv6 policy was passed, it was considered to be an "interim"
> >>> policy, and it was intended to be similar in all 5 RIR's. Since that
> >>> time it has become clear the policy is no longer interim (and proposal
> >>> 2007-4 was passed to change just that) and it has also been modified
> >>> separately in the different RIR's.
> >>>
> >>> It was brought to the ARIN AC's attention that there were a number of
> >>> problems with "Section 6" of the NRPM as a result of this legacy:
> >>>
> >>> * The policy contained a large number of items that were not policy.
> >>> * The policy contained a few items that were self contradictory.
> >>> * The added text was redundant in some cases with existing text.
> >>> * The policy was overly vague in a few areas, leaving ARIN staff to
> >>> have to make interpretations of what the policy intended.
> >>> * Policy changes made since the initial IPv6 policy was adopted have
> >>> not always updated all of the relevant sections due to the complexity
> >>> of section 6.
> >>>
> >>> The intent of these changes is not to change any existing policy, but
> >>> rather to remove all non-policy items, and update any ambiguous items
> >>> with the way that ARIN staff is currently interprets the policy.
> >>>
> >>> Change A:
> >>>
> >>> Not policy. Unnecessary. Confusing (policy is interim).
> >>>
> >>> Change B:
> >>>
> >>> Sections 6.2.1 to 6.2.6 are definitions that are already defined in
> >>> section 2.1 to 2.7 Repeating them here is unnecessary. The picture
> >>> is useful though, and should be moved to section 2 as part of the
> >>> definitions.
> >>>
> >>> Change C:
> >>>
> >>> This is a definition item, and should be in the definition section.
> >>> Also, the v4 versions should be defined at the same time.
> >>>
> >>> Change D:
> >>>
> >>> These are both definitions that should be in the definitions section.
> >>>
> >>> Change E:
> >>>
> >>> This is a manifesto, and is not address policy. If anything these
> >>> belong is ARIN's mission statement.
> >>>
> >>> Change F:
> >>>
> >>> Not policy; covered by the RSA as a legal matter.
> >>>
> >>> Change G:
> >>>
> >>> Not policy. A darn good warning though ARIN should include with
> >>> any other boilerplate when issuing address space.
> >>>
> >>> Change H:
> >>>
> >>> Not policy, and covered by actual policy statement 6.5.1.2.
> >>>
> >>> Change I:
> >>>
> >>> Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64
> >>> allocations, but section 6.5.1.1.d was never updated to match
> >>> the change. It is believed the intent of the policy, and ARIN
> >>> staff's current interpretation of the policy match the updated
> >>> text.
> >>>
> >>> Change J:
> >>>
> >>> The first part is not policy, and incorrectly states there is no
> >>> policy as section 6.5.4 has the policy in it. Take the one useful
> >>> part and make it part of the 6.5.4 criteria.
> >>>
> >>> Change K:
> >>>
> >>> No metric is currently listed to justify a larger initial
> >>> assignment. It is believed ARIN staff is currently applying
> >>> the HD-Ratio similar to the ISP policy, this puts that in writing.
> >>>
> >>> Make it clear that the reservation may not exist in perpetuity.
> >>>
> >>> Change L:
> >>>
> >>> No metric is given to justify additional assignments. It is
> >>> believed that ARIN staff is currently applying the HD_Ratio
> >>> similar to the ISP policy, this puts that in writing.
> >>>
> >>> Change M:
> >>>
> >>> References, while useful on the web page and in template instructions
> >>> are not policy.
> >>>
> >>> Change N:
> >>>
> >>> It's not an appendix. It's not even at the end.
> >>>
> >>> Change O:
> >>>
> >>> The background information would be something nice to archive on the
> >>> ARIN web site somewhere, but is not policy and should be removed from
> >>> the policy manual.
> >>>
> >>> Timetable for implementation: Immediate.
> >>>
> >>>
> >>> _______________________________________________
> >>> PPML
> >>> You are receiving this message because you are subscribed to the ARIN Public Policy
> >>> Mailing List (PPML at arin.net).
> >>> Unsubscribe or manage your mailing list subscription at:
> >>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> >>> Help Desk at info at arin.net if you experience any issues.
> >>>
> >>>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to the ARIN Public Policy
> >> Mailing List (PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> >> Help Desk at info at arin.net if you experience any issues.
> >>
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to the ARIN Public Policy
> > Mailing List (PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> > Help Desk at info at arin.net if you experience any issues.
> >
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
More information about the ARIN-PPML
mailing list