Need some opinions on what data to list

[Kris Deugau]

[Please keep this on-list - it may help someone else later!]

William Leibzon wrote:
> Yes. The policy just says that /29 is smallest ip blocks that ISPs need 
> to report and that reporting choices are SWIP and rwhois.

> I don't think people will complain if you report smaller then /29.
> But you don't have to if its too much extra work.

Ah, OK, so it's a distinction between MUST/SHOULD and MAY (in the RFC 
sense).

Simple enough to choose;  just tweak a single SQL condition in the 
export script.  <g>

> You're required to report customer name and address

OK...

 > (except in case of
> residential customers where you do not have to report and can substitute
> "private residence - customer xyz" if customer asked you not to; this is
> similar to not having your phone number listed in white pages).

Mmh.  All residentials are pretty much dynamically-assigned single IPs 
from pools sized /27 to /24 or so;  even for the static-assignment pools 
we'll just list the pool as "Static PPPoE IPs" or "Static cable IPs".  I 
don't know if there are even very many residential customers on static 
IPs, much less residential customers with subnet assignments of any kind.

> There should also be at least one contact for person/role with working 
> email/phone visible. Such contact can be your own NOC contact or can be 
> customer contact or both. There can be multiple contacts, for example
> many report separate noc and abuse.

There have been mixed opinions on exactly what we should list.  I've got 
a number of templates that should give us some flexibility.

> In that case reporting how to contact their IT services department seems 
> like a must.

*nod*  That's what I had thought;  now to find out where to extract that 
data from.  :/

> BTW - It would also be nice if you report date of when the data (i.e. 
> customer info & contact info) was last changed as well as date when
> your database as whole was last updated.

Already tracked on the netblocks themselves (and listed in the current 
export process);  not quite sure about customer data.  I should probably 
trim off the fractions of a second stored by the database engine though. 
  <g>

-kgd