On Feb 19, 2008, at 11:51 AM, Joe Maimon wrote:
Owen DeLong wrote:
Barring a prior agreement, what grounds does any third party have
to object?
The argument could be made that some form of prior agreement
exists that the
legacy holders have already received that assignment under those
terms and that the
RIRs have accepted a burden to preserve that.
Well I suppose that would be an interesting question that would
depend on examining a whole bunch of agreements that may or may not
exist and that may or may not have any legal ramification in some
jurisidiction or another and that may or may not apply to successors
in interest who may or may not actually be successors in interest.
Legally speaking, if the registries voluntaried disbanded, thus
requiring a new unencumbered entity to rise from the ashes, how
could any prior agreement be considered binding?
You'd probably need to disband the following entities without
successor arrangements
in order to accomplish this:
1. The RIRs
2. IANA/ICANN
3. USDoC
The third is extremely unlikely.
The second is unlikely.
The first is very unlikely.
At a certain point, the courts will apply the reasonable and prudent
test to the question and likely determine
that someone who received an assignment from SRI-NIC or NSI-NIC had a
reasonable expectation to be
able to use that address space in perpetuity and that whatever
registry had reasonable duty not to duplicate
said assignment. Very likely any ISP routing the assignment to the new
holder would be part of the lawsuit
and would get enjoined from doing so.
Thus, your "Barring a prior agreement" condition is not met.
For that matter, aside from consensus and inertia, what would
stop the operator community as a whole from setting up shop with
a "forked" registry that had no contractual agreements with
anybody prior?
Nothing. However, do you really think that is viable?
1. Consensus would be very hard to achieve.
If the current registries are not fulfilling the needs and have
become irrelevant, consensus for forking becomes more likely.
I think it is unlikely that the current registries will become less
relevant that alternative registries.
The only technical lockin I can spot is reverse dns.
That's substantial, but, having multiple registries competing to
assign the same addresses in
an uncoordinated manner is not likely to be a useful or successful
model in any case.
2. Identifying a single entity to manage such a "forked"
registry vs. a bunch
of islands of registration would be even harder.
All such islands would have a vested interest to work together, and
thus, they might actually do so, just like all internet network
islands do so today.
How do you see this working? Who would determine which addresses went
to which islands for
assignment/allocation?
3. Much breakage and instability would likely result.
Likely not, since any registry wishing to be successfull would be
trying their best not to break anything, in other words, RIR
allocations would likely be honored/duplicated, but swamp would
become fair game.
You still haven't explained who would have the authority to divide up
the swamp between the
competing organizations, all of whom would likely claim full control
of the entire swamp, but,
certainly there would be overlapping conflicts.
4. Do you have any illusion that this would do anything other
than beg
government(s) to try and get involved in regulating address
space?
If there is a breakdown in supply, than there will be an opportunity
for an entity to step forward, if they can promise supply.
Promising supply is an act of fiction.
If iana free pool runs out and registries cant offer any new ones,
whos to say goverments wont start stepping in and "eminent
domain"ing address space and setting up registry shop themselves?
Could be interesting, indeed.
Consensus is still required. Otherwise its just a national private
network, with or without nat.
Yep.
I think the takeaway is that the registries better remain relevant
to ipv4 so long as ipv4 is relevant.
I agree that is the ideal outcome. The bigger question is how best to
achieve this.
Owen
