[ppml] Policy Proposal 2005-3: Lame Delegations

[Owen DeLong]

> Let's say I, an ISP, am allocated 365.29.0.0-365.29.31.255, which is
> equivalent to 365.29.0/19, and I register "ns0.example". as my name
> server for this range.  (I'm using one name server to keep the example
> simple.)
[snip]

> The question is: What happens if, after a few months, I've
> "reassigned-simple" the first 10 "/24's" worth of space and set up
> reverse for them, but haven't set up reverse for the the remaining zones?
> 
> I.e., [0,1,2,3,4,5,6,7,8,9].29.365.in-addr.arpa are configured and
> running on ns0.example.  The zones from [10..31.29.365].in-addr.arpa are
> not configured.
> 
[snip]

Got it.  In this case, I think that ARIN contacting the ISP and educating
them will work 99+% of the time.  In that 1% case, I think there are a
few options, and, frankly, I'm not sure which is best:

	+	ARIN record boundaries are somewhat independent of
		actual allocation size.  For example, I have a /23
		which, due to historical reasons, is recorded in
		ARIN databases as two /24s.  As a result, ARIN could
		split the allocation into:

		365.29.0.0-365.29.9.255 and 365.29.10.0-365.29.31.255

		This would allow my originally proposed solution to
		work just fine.  Of course, then the ISP has to correct
		things prior to being able to make in-addrs work for
		any new assignments they issue from the block.  This
		is not necessarily a bad thing in my opinion.

		(And yes, the ARIN database is capable of non-bit-aligned
		allocations, several such blocks exist already)

	+	ARIN could mark the whole record lame, and remove the
		delegations from DNS, but, I think that would violate
		the "First, do no harm." principle.

	+	ARIN could flag the whois record as partially lame.  The
		lame portions could be removed from DNS.  Again, this has
		the same tradeoff listed in the first option.

> I think this proposal ought to be targeted at something, it makes a
> difference when trying to engineers a solution.  ARIN staff is to be
> given the latitude in making implementation decisions, but the membership
> ought to given the staff an indication of "what to optimize for."
> 
OK... On that we can agree to disagree.  I think both are worthwhile goals,
and, I think both can be accomplished.  In general, I expect the need
to flag and/or remove delegation to be the exception and not the rule.
Especially for blocks like you describe.  I think when it does come up,
it will mostly relate to legacy allocations and assignments, not recent
ones.  Recent issues, ARIN will usually be able to contact the
recipient and educate them.

[snip]

>> Again, I do not think that ARIN should take any action in regards to
>> data or DNS entries which are not delgated by ARIN (e.g. LAME SWIPs
>> should not be modified by ARIN, although it would be good if ARIN
>> contacted the upstream supplying the SWIP under the first part of
>> this policy).
> 
> That's a good bounding for the policy.  On the one hand, such lameness is
> also a problem and ARIN has the data to test for it, on the other hand,
> this would be unmanageable.  Maybe in the future, but definitely not now.
> And maybe not even in the future.
> 
Even in the future, I don't think ARIN should take action beyond that
first degree of separation.  ARIN should contact the ORG which received
the resource from ARIN.  That ORG should be responsible for contacting
their downstream or otherwise mitigating the problem.  Regardless of
what ARIN can do, drawing the boundary here simplifies a number of legal
issues and other potential pitfalls.

Owen


-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050320/1b53427b/attachment.sig>