[ppml] Proposed Policy: Capturing Originations in Templates

[Owen DeLong]

--On February 10, 2006 10:47:23 AM +0000 Michael.Dillon at btradianz.com wrote:

>> I oppose this policy... It represents a duplication of effort.  There
> are
>> already
>> a number of routing registries (RADB, ARIN RR, etc.) which can be used
> to
>> express such data in far greater detail and a more useful fashion.
> Please,
>> let's not reinvent the wheel with a new inferior solution to an already
>> solved problem.
>
> One could argue that existing routing registries suffer
> from a stale data problem due to the fact that there is
> not an authoritative source of the data. If ARIN would
> operate a routing registry, they have the potential of
> solving the stale data problem.
>
Since the policy makes this data optional in any assignment,
this data in ARINs database would have a similar issue, no?

> I wonder why the policy doesn't just say that ARIN
> will operate a routing registry and, for each allocated
> or assigned address block, collect the list of the ASes that
> the block owner permits to originate address prefixes
> within the address block.
>
ARIN already operates a routing registry, but, registration in
an RR requires more data than simply a list of valid origins.
This is both good and bad.  It's good in that the data in the
RR is specific enough that it can actually be used to build
real ACLs and configuration statements for routers.  It's bad
in that it breeds a certain amount of complexity.  It's good
in that it provides syntax for specifying which AS can originate
which prefix rather than just a list of ASs each of which is
allowed to originate some unknown subset of a given prefix.

> It would make for simpler wording and achieve much the
> same ends.
>
I'm still not seeing that this buys us anything we don't already
have, except yet another place for this data to be poorly maintained.

> It would not be duplication of effort any more
> than it is duplication of effort for ARIN to operate
> DNS servers containing in-addr.arpa delegations. After
> all, every ARIN member already operates a DNS server so
> why does ARIN duplicate the effort instead of publishing
> a BIND zone file on their website?
>
Huh?  This made no sense to me.  ARIN's DNS servers participate
at a different level of the hierarchy than the ARIN resource
recipients (not limited to members). Those delegations are not
a duplication of effort, they are a required part of the
database structure.

Since there is no correct way to translate the data being proposed
to be collected into RPSL (at least not with accurate results),
I don't see it being placed in the RR by any automatic process
from the template.

Owen

-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- 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/20060210/946b27d8/attachment.sig>