[ppml] Policy Proposal 2005-3: Lame Delegations

[Owen DeLong]

[Attn: Richard Jimmerson
  About the middle of this message there is a question where I think we
  need some feedback from ARIN staff about what is/isn't possible and what
  is easiest.  We've got a few different tradeoffs to consider, and, we'd
  like staff feedback on the implementation of each.

Thanks,

Owen]


--On Sunday, March 20, 2005 21:27 -0500 Edward Lewis <Ed.Lewis at neustar.biz> 
wrote:

> 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.
>
Well... Not sure.  For legacy delegations, you're probably right, contact
will probably be a challenge.  However, for these, the likelihood of your
issue for partial lameness is also smaller.  For more recent delegations,
the contact data is more likely to be correct and workable, so, the
likelihood that the ORG receiving the delegation will correct the server
upon notification and training (it's not really hard, afterall), is,
IMHO, relatively high.

>>	+	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.
>
Well, since ARIN doesn't really have any convenient way to determine what
the boundaries of a DNS Zone are, that's going to be pretty hard for
ARIN to do.

> 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.
>
So it is expected that ARIN will store the public keys for zones not
delegated by ARIN?  That seems like a flaw in the DNSSEC design if it
is the case.  I don't see any reason ARIN would want to get involved
in that.

>>		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.
>
Well, a "Zone" is an arbitrarily bounded range of addresses when talking 
about
reverse, so, that's possible, but, I'm still not sure how ARIN gets involved
in determining "Zones" where ARIN doesn't delegate the 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.
>
I think I understand where you're coming from, but, I remain unconvinced
that ARIN should base policy on an assumption that a working group will
heap a responsibility on ARIN that it has not yet had any discussion about
accepting.  If this policy needs modification to accommodate DNSSEC
public key storage by ARIN, then, that modification should be part of
the policy proposal that implements ARIN doing public key storage
for DNSSEC.  Until then, policy should be based on what we know and not
what we think might happen in an IETF working group.

>>	+	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'm not sure whether the first or third option is the lower hanging fruit.
I'd need to get an assessment from ARIN staff on that.  Perhaps Richard
is watching the list and will ask staff based on this message and post
something to the list (Richard?).  Otherwise, I'm sure it will be part
of the discussion in Orlando, and, staff will follow up on it.
(actually, I'm CCing richardj on this to call it to his attention.

>>>  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.
>
OK... Well, if it's important to pick, I pick both.  If it's not important
to pick, then, it doesn't matter. :-)  Others, I'd need to know what they
were to evaluate.


Owen
-------------- 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/05592cd5/attachment.sig>