[ppml] Staff Comments Regarding Policy Proposal 2006-3

[Michael.Dillon at btradianz.com]

> Comparing the text above to 2006-3 as written, they are remarkably
> similar except that:
>   - 2006-3 explicitly makes providing an AS list to ARIN optional

No policy currently makes it mandatory. Why specify that
it is optional?

>   - 2006-3 limits the redistributiuon restrictions ARIN can put on
>     the publiched list

The whois directory and the routing registry 
are already published by ARIN and already have
redistribution guidelines. Why should this data
be treated differently? If it goes in the whois
directory, it inherits the whois rules, if it 
goes in the registry, it inherits the registry
rules. In any case, it is published, i.e. made
public, so any restrictions on redistribution
are virtually impossible to apply. The only thing
that stops me from redistributing this data with
my own AS added to the list, is that nobody would
accept my copy of the data. Why try to fix a
theoretical problem that does not exist in the
real world.

>   - 2006-3 gives ARIN almost complete discretion to choose the
>     publication mechanism without setting a timelime nor requiring
>     a particular methodology

And that is a bit too vague, IMHO. My wording adds
a fairly light touch but it does set a deadline
so that something actually gets done.

>   - 2006-3 clearly gives ARIN the option of adding additional forms
>     of publication in the furture (an IRR, a certificate system, etc.)

And my wording regards the form of publication to
be outside the scope of the policy and inside the
scope of the working group. Since it is not in the
policy, ARIN is automatically free to change it at 
any time. 

>   - 2006-3 requires ARIN to (proactively) provide an opportunity to
>     update the AS list every time any other maintenance is done on the
>     address block

Seems to me exactly what the staff would do if left
to their own devices. On the other hand, if you believe
that the staff are dumb, it is better to give them some
rope and let them hang themselves with it. That way, the
trustees can get better staff. In any case, best dealt
with outside the policy.

> At the very least, that providing an AS list is optional and that ARIN
> may not restrict distribution of the aggregated data.  I think the
> instruction to ARIN to invite registrants to provide an AS list at
> particular times is pretty important, too.

I think you are picking nits. Even though my wording is
concise and leaves out irrelevant process details, it still
sucks. It fails to define the scope of this whole thing. It
fails to specify ARIN's role and responsibilities within that scope.

ARIN is the authority at the top of the DELEGATION TREE
for IP address ranges. ARIN delegates ranges to organizations.
In turn, these organizations may delegate sub ranges and so
on for an unspecified, though small, number of levels. 
A policy could give ARIN the responsibility to maintain
an publish authoritative delegation data for this 
hierarchy in a form which can be used within the Internet
routing system. If ARIN would provide a mechanism 
for delegees of a range to publish the list of allowed
originating ASes for that range, then it would support
a more secure Internet routing system. The policy really
should start with something on this level and leave 
the details to either the staff, or an implementation
working group.

> To be clear, I have doubts about the accuracy of the staff statement: 
> "The policy duplicates capabilities of the routing registry and could 
> be addressed by enhancing this existing functionality."

I think they mean that ARIN already runs a 
routing registry so that organizations can
publish information about delegated address
ranges and SUBNETS OF DELEGATED RANGES. Of course
the IRR is targeted at AS holders, but could easily
be extended to support address range holders as well
and could easily support additional attributes.

> Two key parts of this proposal, the 
> regular invitations to update the AS lists and the implicit 
> authentication provided by the template system, might be hard to 
> incorporate into ARIN's existing IRR.

That is precisely the reason I suggested a working
group with a deadline. It might be hard or it might
be easy. Rather than hang the whole policy on some
"might be"'s, I think it works better to hash this
out in the open, after the policy has been approved
and ratified by the BoT. The WG may decide that even
if it is hard, it is still beneficial and the best
way to proceed. Or not.

> There's also the question of 
> how to handle the existing, poorly authenticated, data present in the 
> IRR.  On the whole, the proponents of this proposal were concerned 
> that trying to "enhance" the existing IRR would be intractable. 

Sounds like another good reason for a WG.

> Accordingly, this proposal gives ARIN the leeway to publish the data 
> in an IRR or elsewhere, including in a certificate system, as it deems 
> feasible.

As you know, I prefer that they just set up an
LDAP server and be done with it. ;-)

--Michael Dillon