[arin-ppml] Policy Proposal: whois POC e-mail cleanup

Owen DeLong owen at delong.com
Thu Aug 21 11:30:53 EDT 2008


>
> add section 3.6 titled "Reliability of Whois information"
>
> 3.6.1  ARIN will use an automated system that once a year will attempt
> to e-mail all separate e-mail addresses in the directory. (including
> abuse addresses)  At it's discretion, ARIN will attempt to contact by
> regular mail or phone all POC entries that have invalid e-mail  
> addresses
> (i.e. e-mail addresses that bounce mail sent to them) and give them  
> a 3
> month deadline for correction of their mail address.  The automated
> system will not use a mail cluster or other mail transmission software
> that is incompatible with commonly available anti-spam technologies,
> such as greylisting.
>
The first problem I see is a small wordsmithing nit..

The way this is worded, it gives ARIN discretion to regular mail or  
phone
ALL POCs with invalid email adresses or none.  I would suggest this
be changed to ANY instead of ALL so that ARIN has case-by-case
discretion rather than all-or-none.

The second problem is this declares invalid only those addresses
which result in a bounce back.  What about addresses which are
a black hole? Is a POC valid so long as some server accepts
mail for it, regardless of whether anyone sees or acts on that
email? This doesn't seem particularly meaningful.

OTOH, black-hole detection is difficult unless you are going to
require the POC to take some responsive action.

> LIR POC's that fail to respond to paper mails or telephone calls will
> have Their e-mail address replaced with "REFUSED RESPONSE" in the
> directory. Non-legacy POCs will be requested to remedy the situation  
> by
> their next billing date.  At it's discretion and considering the  
> size or
> number of complaints about an organization, ARIN may require the
> organization to supply accurate contact information in it's directory
> entry as a condition of accepting payment from the organization for
> registration renewals.
>
As I understand it, the LIR term in the NRPM applies only to those
holding IPv6 Delegations. Those with IPv4 resources and those
with IPv6 end user assignments would not be covered by the
above paragraph as I understand the terms.

Further, I don't see selective enforcement codified in policy as
a good thing. Either all organizations should be required to
provide valid contact information or they should not.  The
organizations that ARIN staff chooses to pick on at any given
time is a very poor way to construct policy IMHO.

> POCs belonging to blocks reassigned by LIRs who fail to respond will  
> be
> replaced by the POC of the reassigning LIR.
>
I think this should be carefully considered.  How does this action
distinguish itself from effectively deleting the whois record  
altogether?
I would rather see the stale information with a flag on it than a new
record that is indistinguishable from the LIR using this block for its
own internal purposes.

> The automated e-mails will have a text string titled "ARIN Automated  
> POC
> e-mail test" identifying them so that automated trouble ticket systems
> can be programmed to automatically delete the mail messages instead of
> replying to them.
>
If the automated system deletes the message instead of replying,  
wouldn't
this trigger ARIN treating the POC as invalid? Oh, wait, you treat
black holes as valid, so, I guess not.  However, if you fix the black
hole loophole above, then, this paragraph needs fixing too.

> Other standard mailing list practices will be followed by ARIN to  
> insure
> the absence of e-mail loops, etc.
>
I think that ARIN staff is capable of using judgment here to act  
according
to BCP rather than needing this in the NRPM.

> 3.6.1  ARIN will supply a report to the community, updated monthly,  
> that
> lists the percentage of "REFUSED RESPONSE" POCs, the percentage of  
> POCs
> that accept e-mails, and the percentage of POC addresses that have not
> responded but have not yet been notified by paper mail or telephone.
>
I have mixed emotions on this requirement. I'm not sure what the benefit
of publishing these anonymized statistics is.

Owen




More information about the ARIN-PPML mailing list