[arin-ppml] Fw: Accusationof fundamentalconflictofinterest/IPaddress policypitched directly to ICANN
Owen DeLong
owen at delong.com
Thu May 5 14:04:46 EDT 2011
On May 5, 2011, at 7:04 AM, Mike Burns wrote:
> Hi Owen, answers in italics
> Now, if you mentioned the judiciary, you might have a point, but, you did not. You chose
> the governor.
>
> Small case "g" governor, see how semantic this can get. I think with your response, my concept is clear.
> If you pretend I mentioned judiciary, then maybe you can sense that what I am trying to say is that it can be argued either way in terms of authority.
> And that argument is boring. I don't think the authority structure is as clear as you describe. Or as I conceive it.
> Could be that is uniquely murky, and seems to be in the midst of transition away from US government control, in any case, leading to further murkiness.
I was not intending or considering that Governor vs. governor was significant to the discussion.
There is no parallel to the judiciary in the IP number resource policy world. Perhaps there should be,
but, as it currently stands, there is not.
> >
> >
> No, it proffers one possible set of requirements which could be used to do so.
> That is (and was) my point. Other than the author, there is no reliable evidence
> that anyone has reviewed or accepted this as the way such a thing should
> be done, let alone the way they would be done if such a structure were to be
> created.
>
> OK, we can read the letter. It's pretty clear it's a proposed (not ratified) set of standards for private ip registries, based on those existing for DNS registries.
> I never said it was reviewed or accepted, just that Benson's proposals lacked these kinds of regulations on new registry entities.
> I don't pretend to know what would happen if the author of the letter's proposals were accepted, and the Board of ICANN decided to implement them.
> My suspicion is that they would somehow become policy, though through what mechanism, I don't know.
I agree that the lack of these specifications was one of the shortcomings of Benson's proposals.
For them to become policy, they would have to go through the global policy development process.
That is the only currently defined mechanism for the creation of IANA level policy. That has been
my point from the beginning. I realize it is an answer you don't like to hear, but, it really is the
true and correct answer.
>>>
>>> I just skimmed it, but if the community decided that Benson's proposals suffered only from a lack of oversight, and required action at a global level, then perhaps they will add their voice to the support which I offered.
>>>
>> Perhaps, but, you would still need a global policy proposal to voice support for.
>>
>> Unless ICANN board actually does make the decision they are being asked to make. The link above is policy proposal on the ICANN correspondence page, and it is referenced in this letter:
>> http://www.icann.org/en/correspondence/holtzman-to-olive-02mar11-en.pdf providing reasons for requesting the decision at the ICANN board level. Based on the appeal to the authority of the DoC contract, I expect there could be a further appeal to the DoC or NTIA level if the ICANN board decides not to make a decision. It is interesting that ICANN requested information from ARIN instead of summarily dismissing the request as coming outside of policy. ARIN's reply to ICANN is on the same site.
>>
> I cannot see any correspondence that shows ICANN board requesting information from ARIN that was done after ICANN received this letter.
> Can you point to a link to such?
>
> Here is the sequence
> http://icann.org/en/correspondence/holtzman-to-beckstrom-27jan11-en.pdf T
> This was a letter of complaint to ICANN and a request for an appeal at the ICANN level based on authority derived from the DoC contract.
>
> http://icann.org/en/correspondence/beckstrom-to-curran-01mar11-en.pdf
> This is the letter from ICANN to ARIN which requests more information instead of summarily dismissing the request as coming outside of normal policy development channels.
>
> http://icann.org/en/correspondence/curran-to-beckstrom-02mar11-en.pdf
> This is John Curran's reply to ICANN
>
> http://icann.org/en/correspondence/holtzman-to-olive-02mar11-en.pdf
> This is the letter which includes the proposed regulations on new registries.
> I'm pretty sure that's the flow. A request last year from Depository to ARIN for bulk whois data in order to provide directory services.
> ARIN denies it and says it violates the AUP, it's not a valid purpose for bulk access.
> Then the letters above start, the first one is an appeal to ICANN, which I took as a means of going over ARIN's head, although such talk of levels is like a verbal Escher drawing, apparently.
> You seem certain that ICANN both won't and can't make this decision and make it apply to ARIN's sharing of whois data. I'm not so sanguine.
> I think courts seem more likely to deal with contracts then Memorandums and Agreements of Understanding.
> My guess, and I'm not a lawyer, is that should push come to shove in a legal arena, the courts may decide that the authority comes from the DoC contract.
> It could be as you say, that ICANN has no authority to dictate anything to ARIN; the letters say there is no contract between ARIN and ICANN.
> Just a guess, and I could be wrong. If it turns out that ICANN either can't or won't make the decision, as John points out in his letter, (or maybe elsewhere) that there remains the ability to change the global policy which specifies regional registry properties which he believes preclude private registries. Perhaps ICANN has power to make those changes, and the ARIN MoU would then require ARIN to submit?
>
Yes, the first letter is an appeal to ICANN to override ARIN's decision about ARIN's implementation
of ARIN's bulk whois policy. It is not clear that ICANN has any such ability, but, I suspect that ARIN
will probably cooperate with ICANN in clarifying any misunderstandings about the ARIN bulk
whois policy. If it is somehow agreed that ARIN did not act according to their own policy, I suspect
ARIN will modify their behavior accordingly until such time as the policy is changed either by the
emergency authority of the BoT or by the community.
There is no contract between ICANN and ARIN that would force ARIN to do ICANN's bidding, so,
I'm not sure what your statement about courts giving preference to contracts is intended to
accomplish.
I'm not a lawyer, either, but I suspect that the courts may well decide that authority comes from
the DoC contract. The question, however, is authority over what. The DoC contract only specifies
the IANA function as it relates to IP addresses to my understanding. The IANA function in
this regard is to delegate large blocks of IP addresses to the RIRs, to keep track of those
allocations, and to manage the in-addr.arpa zone accordingly. IANA doesn't even operate
a whois server to the best of my knowledge. There's no contract stating that IANA retains
any authority over addresses once they have been issued to RIRs or any authority over
the behavior of the RIRs.
The ability to change the global policy is specified in the global policy development
process. It might be worth considering the following from the MoU between the
RIRs and ICANN:
5. Global Policy Development Process
Global policies are defined within the scope of this agreement as Internet number resource policies that have the agreement of all RIRs according to their policy development processes and ICANN, and require specific actions or outcomes on the part of IANA or any other external ICANN-related body in order to be implemented.
Global policies will be developed in the context of this agreement, according to the processes defined by attachment A to this MoU.
Under this agreement the ICANN Board will ratify proposed global policies in accordance with the Global Policy Development Process, using review procedures as determined by ICANN. ICANN will publish these procedures no later than ninety (90) days from the date of the signature of this agreement by all parties.
6. Service Regions
The regions serviced by each RIR shall be defined by the RIRs in a manner of their choosing. The NRO shall ensure that all possible service areas are encompassed.
7. Arbitration
In the event that the NRO is in dispute with ICANN relating to activities described in this MoU, the NRO shall arrange arbitration via ICC rules in the jurisdiction of Bermuda or such other location as is agreed between the NRO and ICANN. The location of the arbitration shall not decide the laws to be applied in evaluating this agreement or such dispute.
As you can see from the above text:
1. Global policies require the agreement of all RIRs according to their
policy development processes _AND_ ICANN.
2. Global policies are developed according to the processes defined
by attachment A (at the bottom of the same web page):
Worth noting especially are paragraphs 2, 3, and 4 which define the
way that the text emerges from the collective policy processes of the
five RIRs and their communities. For reference, the NRO NC is
comprised of the elected representatives from each of the RIR
regions. They are elected by the communities of those regions.
The NRO EC is comprised of the 5 RIR CEOs. The ASO AC is
comprised of the NRO NC and is essentially synonymous with
the NRO NC.
Paragraphs 5 and 6 define the way the ASO AC reviews the process
and ratifies the policy proposal (or not).
Paragraph 7 specifies that the ASO AC forwards a ratified proposal to
the ICANN board.
Paragraphs 8-10 govern the ICANN board's actions with respect to
a proposal which has completed paragraph 7. Note that there is a strong
bias built in to this step towards accept and that rejection requires a
supermajority (2/3rds) of the ICANN board.
In other words, there is a global policy development process. That process was
agreed to by the RIRs _AND_ ICANN in the MoU. The policy is designed to clearly
ensure that the global policy process is governed by the collective agreement of
the RIR communities.
There is no provision for appeal outside of this process to create or change global
policies.
>
> >Proper stewardship is to make policy that will increase the supply of addresses and bring down their price, while increasing whois reliability and removing the biggest distinction between legacy and >non-legacy addresses.
> >In general, I would agree with you about the goals of proper stewardship. Obviously, I do not
> >think that is the effect competing registries would have.
>
> Maybe I have found an appealing argument in the idea that increasing supply will reduce price. Since in a post-exhaust world, even those with need will have to pay for IP addresses, maybe the best stewardship is the policy which will lead to the lowest price? Should frame the debate in that way? Which policies should be implemented which will create the greatest supply to replace the free pool, in order that price be driven down? Which types of markets lead to lowest prices, those with fewer regulations or those with more regulations? Is low price to be desired by the proper steward? Now we are stewards of the rules and not the addresses.
>
Since I believe that a free market is open to speculators and speculators only serve to increase
the price, it is hard to say that a completely free market would reduce price.
Additionally, there is a dichotomy in the particular market scenario in question in that increased
price will likely lead to increased supply (to some extent) and increased supply _MIGHT_ lead
to decreased price. I suspect for the latter to be true, it would require a vastly increased supply
which will not be possible until IPv4 addresses are largely irrelevant, at which time they will
again be readily available anyway.
>
>
>> Are you accusing the APNIC community of abandoning stewardship, and if they did, why do you think they did that? Is the region largely peopled by IPv4 profiteers?
>>
> >Yes. I believe that the transfer policy in the APNIC region was an abandonment of their
> >stewardship role and I have said as much on their policy development mailing list.
> >Why? Because Geoff Huston and a few other leaders in that community pushed long
> >and hard to get that position adopted mainly by creating fear that failing to do so would
> >render all RIR policy meaningless because the RIR policy would simply be bypassed
> >in favor of people doing what they wanted anyway.
>
> >Personally, I think that argument is absurd. Making theft legal just because you can't
> >stop people from stealing makes no sense to me.
>
> Well, that information leads me to discount the deaggregation argument against removing need requirements.
> I consider Geoff Huston to be en expert on BGP tables and defer to his judgement here.
> Clearly he did not see the risk of BGP table growth as a cause to retain needs requirements.
> I hope the ARIN community can take away the idea that it is not just a few IPv4 profiteers who have different visions of stewardship.
Quite the contrary... You should listen to or read Geoff's entire argument before drawing
such (IMHO erroneous) conclusions about his statements.
Geoff has recognized that a market will create aggregation concerns in the BGP tables. However, his
argument is that these are inevitable and the RIRs refusing to recognize transfers in whois will not
reduce them.
Obviously I don't completely agree with him that the number of transfers taking place will not or can not
be reduced by RIR policy. Geoff's theory is that all policy can accomplish is to prevent the transfers
from being visible in whois. My belief is that most organizations will choose to play by the rules and
will not want space that is not visible in whois. Further that most ISPs (at least the majority of the
very large ones) will actually consider whois registrations in the process of deciding what is or is
not an acceptable prefix to route for a given customer.
Obviously, Geoff and I disagree on this matter. However, we both agree that transfers are and will
be detrimental to the BGP table.
Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110505/f886f295/attachment.htm>
More information about the ARIN-PPML
mailing list