[ppml] Policy Proposal 2005-3: Lame Delegations

[Edward Lewis]

At 12:12 -0800 3/20/05, Owen DeLong wrote:

>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:

I've been assuming (assuming!) that the percentages would be 
reversed, but you could be right.  Not arguing, just pointing out 
where I had been coming from.

>	+	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 is a step in the right direction.

There's a tangential issue on the horizon though that might feed into 
this.  The tangential issue is DNSSEC - and I don't mean to start a 
discussion on that here, this is a future topic.  The reason I 
mention it is that for DNSSEC, *if* it becomes a reality, there is a 
need to store data per DNS zone, something ARIN does not do up to now.

To cut to the chase, splitting the allocation's zones into lame and 
not lame might be a "degenerate case" of having to store unique data 
(public keys for DNSSEC) per zone within an allocation.

>		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)

Yes, the database demonstrates the capability of handling arbitrary 
ranges of addresses, CIDR is not a prerequisite.  The capability that 
is needed for lame delegation and potentially DNSSEC is the ability 
to store per zone.

What I'm saying is that we should seek an engineering opinion on what 
you are suggesting, with some assessment of what *would be* needed 
for DNSSEC and future trends in DNS.

>	+	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.

What membership should consider is an estimate of the engineering to 
achieve the latter, or just treating allocations that are completely 
lame.  (The latter is a  lower hanging fruit that would beneficial to 
solve for probably a lot less effort.)  As you say about the prior 
bullet, violating "do no harm" you are right and I would not 
recommend throwing out good zones with the bad.

>>  I think this proposal ought to be targeted at something, it makes a
...
>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

...

I don't think that we will wind up disagreeing.  (That's so not 
"consensus." ;))  I mention these goals for consideration, but if the 
membership decides it's not important to pick one, both, or others, 
then I will consider this a learning experience.  As in - trying to 
adjust the detail with which we document policies.

>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

Ack.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Achieving total enlightenment has taught me that ignorance is bliss.