Send ARIN-PPML mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. Re: Draft Policy ARIN-2013-4: RIR Principles (Andrew Dul)
2. Re: Draft Policy ARIN-2013-4: RIR Principles (Owen DeLong)
----------------------------------------------------------------------
Message: 1
Date: Sat, 01 Jun 2013 12:53:16 -0700
From: Andrew Dul <[email protected]>
To: Jason Schiller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
> JS> RFC-2050 3.1 says:
> JS>
> JS> "IP addresses are valid as long as the criteria continues to be met."
AD> One might construe this statement to directly invalidate existing
legacy allocations
AD> which would now be in ARIN's policy through this policy. Others
might be worried
AD> that this opens the door wider to changing policy to retroactively
revoke allocations
AD> or assignments by changing "criteria". Furthermore, I believe this
idea is already
AD> handled by existing NRPM text and the RSA.
JS> What should we do here?
Lets consider the negative version of this statement
"IP addresses are valid as long as the criteria continues to be met"
One could write it as follows
"IP addresses are not valid as long as the criteria is not met"
There are two issues with the current operational practices of the RIRs
and ARIN specifically with regard to this statement in my opinion.
1. "the criteria" is not really defined here and thus is open to
interpretation exactly what is intended. One could read this as the
whole policy and that is fine, but it would be better if a statement of
principles actually referenced the "community developed number resource
policy" rather than an obscure reference to it. Is this the _original_
criteria when the addresses were issued or the _current_ policy or some
other policy at some time period?
2. ARIN does not "invalidate" IP addresses as soon as the criteria is
not net. ARIN has, in general, only done reclamation in cases of fraud
and lack of payment of registration services fees.
Consider a very simple case (Yes, there are problems with every analog)
ARIN issues an org a /20 who has justified it based on current policy in
the year A. Business cycles happen and the org changes, it is still in
business using its address block, but it could no longer justify a /20
of address space, it could only justify a /21. Should ARIN invalidate
this org's address block? One could say in the ideal world maybe, but
we don't live in that world. The ARIN community has thus far not done
reclamation for this type of issue and I believe it would not be in the
registry community's best interest to do it either.
What "principle" are people hoping to preserve by enshrining this
statement in ARIN's policy. I think some people are trying to say that
if you can't justify the address space any more you shouldn't have it.
While that is probably true in some cases, it may not be true in all
cases and thus we either have to define those cases or consider if a
statement like this should be in a "RIR principles section".
Again I suggest one consider my proposed changes in lieu of the proposed
original statements from RFC-2050.
In order meet the Principles and Goals of the Internet Registry System,
resource holders may be required from time to time to provide an
accounting and current usage of resources currently held. The RIRs
shall set policies to define these accounting mythologies as part of
their community driven policy process.
One might also consider a rewrite of the RFC-2050 statement as well
adding it to the above two sentences.
IP number resources are valid as long as an organization continues
to comply with the terms of the community developed number resource
policy and any registration services agreements between the
organization and the RIR.
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130601/02981de8/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 2 Jun 2013 00:17:04 -0500
From: Owen DeLong <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
On Jun 1, 2013, at 12:24 PM, Andrew Dul <[email protected]> wrote:
> Jason, further comments inline.
>
> On 5/30/2013 10:18 PM, Jason Schiller wrote:
>> Andrew,
>>
>> (Putting aside the RFC-2050 3.1 - does this create a new ability to revoke
>> legacy IPs for the other thread)
>>
>> Your comments boil down to:
>>
>> 1. it comes down to "modernizing" the 2050 text/principles
>> 2. keeping principles in the principles section and not putting specific
>> policy in the principles section.
>>
>> In general I agree with both.
>>
>> I tried to start with 2050 text/principles, and only attempted to go beyond
>> that text where it helped,
>> e.g. such as substituting "efficient use" for conservation (nobody uses
>> conservation) but still paying
>> homage to the conservation section that this principle stems from.
>>
>> It is possible that some of the language from 2050 is to detailed or "policy
>> specific" and should be
>> stripped away and moved into other more relevant sections of the NRPM. This
>> may be a bit tricky to
>> do in separate proposals as you want both things to happen.
>>
>> I propose we ether initially adopt, then decide if certain details should be
>> moved elsewhere, or
>> figure out which specific details should be moved where,and include them in
>> this proposal (or both).
>>
>> But just because there already is a detailed section on say transfers,
>> doesn't mean it shouldn't also
>> be included in the principles section that
>>
>> "The transfer of Internet number resources from one party to another must be
>> approved by the regional
>> registries. The party trying to obtain the resources must meet the same
>> criteria as if they were
>> requesting resources directly from the IR."
>
> I think having a transfers section in the principles, document is
> appropriate, I would point out that today the transfer policies are different
> from the direct RIR policies, e.g. 24months vs. 3 months. So today we don't
> follow the above principle.
>
> I'd propose the following updated text:
>
> The transfer of Internet number resources from one organization to another
> must be approved by a RIR. Transfer policies are created by Internet
> stakeholders through the community driven policy development process.
>
IMHO, this is unnecessary doublespeak.
Having a community policy document that is the result of a community
development process state that the other parts of the same document are
developed through that same document seems redundant to me. The ARIN bylaws and
articles of incorporation cover the existence of the PDP rather well. The PDP
itself is also well documented elsewhere. I don't believe we need to summarize
it again in the NRPM specifically with respect to transfers.
I don't see any need to call transfers out specifically in the principles
separate from other policies.
>>
>> One could image that the ARIN community decides that there should be no
>> transfers, and all
>> redistribution of addresses should be through return to IANA and split
>> equally among the RIRs.
>> In this case the ARIN community could abolish the text on transfers. Would
>> we then loose the
>> principle that if a transfer was to happen (say a new transfer policy in the
>> future) it should be
>> governed by the same principles of getting address space directly from the
>> RIRs?
>>
I don't see that as likely. However, if it were to occur, it would be just as
likely to strike the above proposed language from the principles text at the
same time. Requiring another section to be modified when changing policies just
for the sake of having another section to modify doesn't make sense to me.
>
> While using "sustainability" instead of "conservation" would be a textual
> change, it might be a positive change. To me what the RIRs do with number
> resources today are more closely aligned with the definition of
> sustainability vs conservation.
>
> Sustainability to me means managing a resource for all stakeholders.
> Conservation sometimes means preserving the status quo or excluding certain
> uses to protect the resource.
>
+1
> The word "conservation" appears 3 times in the current posted draft. Just
> substituting the word "sustainability" seems to make sense to me. This might
> however be too much a of a jump for others.
>
>>
>> 4. documentation to promote increased utilization
>>
>> So I think there are a number of reasons accurate documentation is
>> important,
>> and I think one of them is so that the RIR can measure utilization and judge
>> current usage prior to deciding to give additional space. This process
>> causes
>> more efficient utilization over all.
>>
>> I think this aspect is important, and should be included. It is possible
>> the some
>> word smithing may be in order.
>>
>> "Resource holders will be required to provide an accounting of resources
>> currently held
>> in order to provide the necessary transparency and accountability. This
>> information provides
>> IRs the ability to measure efficient utilization of current space prior to
>> allocating or assigning
>> additional space."
>
> I the above proposed text is pretty good.
>
I don't like the title of point 4. I do like the text. I would propose:
4. Documentation of Use of Number Resources
>>
>> 5. transfers
>>
>> I agree, the details of transfer policy should be in the "main" portion of
>> the NRPM, and already is,
>> and that is where the details of transfers should be documented.
>>
>> But I also think RFC-2050 gives us some high level guiding principles wrt
>> transfers:
>> A. RIRs must approve
>> B. must be consistent with the criteria as if they were requesting an IP
>> address directly
>>
Both of those are already enshrined in the existing transfer policy. I don't
see any benefit to moving it elsewhere.
>> I think these principles should be included.
>>
>> I am not opposed to the text "RIRs shall determine IP number resources
>> transfer policies through
>> their community driven policy development process." In fact all policies
>> (except emergency ones)
>> are determined by the community through the PDP...but I'm not sure that
>> changes anything.
>
> See above proposed text and comments.
>
Actually, all policies, including emergency ones are ultimately determined by
the community through the PDP. The difference is that in the case of an
emergency policy, it is implemented first and PDP'd later.
>> 6. audit
>>
>> I think some guiding principle text is important here. This text was
>> lifter from RFC-2050.
>> Again, not intending to create new capabilities here, but think this
>> principle (in some form is important)
>>
>>
>> If the community thinks it is superseded by text in the NRPM and RSA, I am
>> happy to use that text as
>> a basis for pulling out some high-level principles.
>>
>> Is there RSA or NRPM text that is high level enough to use here? How would
>> you propose to create
>> high level principles from the RSA and NRPM text?
>>
I believe audit is adequately covered in NRPM 12. If you believe otherwise,
please state what you specifically think is deficient.
Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130602/4543d2ed/attachment.html>
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 96, Issue 3
****************************************
