[ppml] 2003-5 rwhois/reassignment info

[Einar Bohlin]

I commented earlier on rwhois, and hopefully 
I can get this in before rwhois policy is set in stone.
I finally got a minute to think about what was really 
bugging me about it and it's not the technical details,
it's the entire reassignment info operation.

What is reassignment info today?

It's a network and organization, and a POC.

In a perfect world the POC was someone who was
responsible for the network.  This grew out of the
ancient requirement of a POC for every host.
But in reality today the POC is an email to which one
reports abuse and spam, as well as a handy address to deliver
spam to.

More and more ISPs have said that they want to be the POC
for reassignments.  They want to screen their customers.
There's an ARIN policy for this for residential customers,
it's in the IPV4 policy doc.  And in general ARIN allows the
ISP to be the POC for all reassignments (see the
reassign simple template).  RIPE and APNIC allow the ISP to
be the POC too, I asked them.

When the POC is the ISP, all that's left for reassignment info
is utlization info.  And I think it's only the registry that
needs that info.  RFC 2050 says the registries determine how
reassignment info is submitted.  Today they are swip and rwhois.
Someone else mentioned LDAP, that could be an option.  
But what happened to text file as an option?  That's
how I check endusers, and how I could easily check
downstream ISPs.  What do you think?

And without a specific POC for a reassignment, 
why does utilization info need to be publicly visible any
more?  It seems to me the POC was for the public, and it'll
still be there on the parent block.  But why does 
utilization info still have to be publicly visible?
What good does that do? Would there be any problems if 
ARIN's whois only had direct assignments/allocations?

Who needs to see utilization info?
----------------------------------
The registry.

Sometimes an ISP needs to see a net record in order
to route the net for the customer (for example multihomed
customers), but a routing registry would be better for
this.

Blacklisters and anti-spam unsolicited mail generators.
No comment.  

in-addr.arpa
This isn't really a reassignment issue, it's a domain.
Take the APNIC model for example, they've separated
the domain from the net record, as it should be.
in-addr.arpa is a domain record, domain and nameservers
are what's needed.

Question:
Why is the swip cutoff at /29?  Has anyone had to deal
with savvy customers coming in repeatedly for /30s?

Regards,

Einar Bohlin, IP Analyst
IP Team - Ashburn Virginia - MCI/UUNET
Phone: 703 886-7362 (VNET 806-7362)
email: einar.bohlin at mci.com