[ppml] Policy Proposal 2005-3: Lame Delegations

[Richard Jimmerson]

Owen,

Message received.

We can consider these options in the staff impact analysis that is conducted
for each new policy proposal.

I'll contact you off list for clarification about which options you are
asking be considered.

Richard Jimmerson
Director of External Relations
American Registry for Internet Numbers (ARIN) 

> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com] 
> Sent: Monday, March 21, 2005 1:57 AM
> To: Edward Lewis
> Cc: ppml at arin.net; richardj at arin.net
> Subject: Re: [ppml] Policy Proposal 2005-3: Lame Delegations
> Importance: High
> 
> 
> [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
>