[arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's
tedm at ipinc.net
Fri Mar 27 16:27:43 EDT 2009
Hi Heather, I didn't see the original posting from ARIN staff.
I believe they are mistaken in calling this an annual "reregistration"
and I further feel the term carries a negative connotation. This
is an annual verification. It is only a reregistration for people
who do not have valid POC data in WHOIS.
The valid POCs can be handled by automated e-mail systems with a
specific URL link in the mail sent to the POC. Network Solutions
already does this for ALL domain name holders in their registrar and
it's completely automated. ARIN staff can contact Network Solutions
and ask how they do it if they do not understand how to do this.
ARIN staff was also given discretion in chasing after the bogus POCs
because the policy does NOT specify penalties other than those
determined by ARIN staff. In short, if ARIN staff doesen't want to
work on this they simply don't designate anyone as an invalid POC.
In other words, ARIN staff is being given authority to manage
the work this proposal generates and how much work it generates.
Obviously, priority should be given to bogus POC data associated with
the LARGEST registered IPv4 blocks, when they get those cleared
away, they can work on the smaller ones.
The hijacking argument is utterly illogical. What makes an abandonded
block that has no POCs on it any more attractive than a "virgin" block
from the unassigned pool IANA just handed them? And when Ipv4 runout
happens then ALL free unassigned blocks (blocks returned to ARIN through
attrition) will be exactly the same status.
The policy did not refer to the bulk whois request. It states for
ARIN staff to make a report to the entire membership.
What is ARIN expecting when IPv4 runout happens? That they will conceal
from the memership the numbers and existence of abandonded IPv4 blocks
with no POCs on them? This would represent a policy shift from how
things are now - right now, we know the numbers of unassigned blocks.
There should be no restrictions on requesting a list of unassigned
blocks that were formerly occupied, vs unassigned blocks that were
never formerly occupied.
The only possible issue would be disclosing the list of "pending
unassigned" blocks to the public. The policy simply does not speak
to specifics for this, because it does not carry any requirement to
ARIN staff to disclose the detailed list of those. It only states to make a
report, period. If ARIN is concerned with hijacking on that list,
they are not required by this policy to publish anything more than
a summary report, and making the changes in WHOIS itself.
> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Heather Schiller
> Sent: Friday, March 27, 2009 6:21 AM
> To: Member Services
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2008-7: Identify
> Invalid WHOIS POC's
> Feedback on ARIN Staff Comments:
> 1) Hijacking - this is already a problem today. Providing a
> list of resources with stale records is essentially a list of
> resources at risk, which will allow providers to have
> something to check against before they route the block.
> 2) Workload - in many ways this is work that is already done
> when billing POC's go invalid. Arguably, ARIN should have
> been checking POC validity on a recurring basis from the beginning.
> 3) Bulk Whois Reference - ARIN has the operational details of
> going through the bulk whois process on
> https://www.arin.net/resources/request/bulkwhois.html which
> includes a requirement to sign an AUP. Other sections of
> existing policy do not include operational details or further
> requirements for the bulk whois process. The authors believe
> the process of signing the bulk whois agreement to be an
> operational process on the part of ARIN staff and not part of policy.
> 4) Threat of lawsuit - I understand council's comment to mean
> - if we properly announce and enforce it should be ok. I am
> also thinking, as long as ARIN has a (an operational) process
> to re-establish/validate the POC, that would help mitigate
> any problems, correct?
> 5) Resource Impact - Yes, it will take new development and
> time to get this process in place, however the potential
> benefit to the community is also significant.
> Member Services wrote:
> > ARIN Staff Assessment
> > 2008-7
> > Title: Identify Invalid WHOIS POC's (formerly known as WHOIS
> > Integrity Policy Proposal)
> > Revision Submitted: 07 March 2008
> > 2nd Revision Submitted: 12 Feb 2009
> > Date of Assessment: 24 Feb 2009
> > The assessment of this text includes comments from ARIN
> staff and the
> > ARIN General Counsel. It contains analysis of procedural,
> legal, and
> > resource concerns regarding the implementation of this text
> as it is
> > currently stated. Any changes to the language may
> necessitate further
> > analysis by staff and Counsel.
> > I. Understanding
> > ARIN staff understands that this will institute an annual
> > re-registration of all POCs registered in WHOIS. POCs who do not
> > respond within 60 days will be marked in the database as
> > and if staff deems them to be invalid for any reason, may
> remove them
> > from WHOIS. In addition, staff will maintain a list of all address
> > blocks with no valid POCs and will make this data available to any
> > organization using the bulk whois policy criteria.
> > II. Issues and Concerns
> > A. ARIN Staff Comments:
> > * Resource records marked as "unresponsive" or those
> with no POCs at
> > all could become the targets of hijackers who, in the
> past have
> > tended to look for address blocks that contain
> obsolete or stale data.
> > * An annual re-registration of all POCs (~223,000
> currently) will
> > likely result in a vast increase in workload,
> particularly with
> > the follow up work and research involved when a POC
> does not reply
> > within 60 days. This could result in a slow down in
> > response and processing times.
> > * This policy refers to the Bulk Whois policy rather
> than stating
> > the actual criteria under which an organization will
> be allowed to
> > request the list of all address blocks with no valid POCs. It
> > would be better policy text to state the specific criteria,
> > including the requirement to sign an AUP, within this
> policy itself.
> > B. ARIN General Counsel
> > * It is possible those delisted will threaten or file
> litigation to
> > be relisted. However, a properly promulgated policy
> does not pose
> > antirust or other legal concerns.
> > III. Resource Impact
> > The resource impact of implementing this policy is viewed as
> > significant. Barring any unforeseen resource requirements, it is
> > estimated that this policy could take up to 18 person
> months to fully
> > implement from the date of ratification of the policy by the ARIN
> > Board of Trustees. It may require the following:
> > * Staff training
> > * Development of new internal process and procedures and
> > modification to existing ones
> > * Creation of an automated system to track
> notifications, updates,
> > and current status of the POC notification. Provide
> allowances for
> > manual intervention and follow-up by staff.
> Engineering estimates
> > that it could take up to 18 person months for the creation and
> > implementation of this system. In addition, this could impact
> > ARIN's current project deployment schedule.
> > * Increased workload could result in the need for
> additional staff
> > Text assessed:
> > 2008-7: Identify Invalid WHOIS POC's (formally known as WHOIS
> > Integrity Policy Proposal)
> > Revised text is as follows:
> > During ARINs annual WHOIS POC validation, an e-mail will be sent to
> > every POC in the WHOIS database. Each POC will have a maximum of 60
> > days to respond with an affirmative that their WHOIS contact
> > information is correct and complete. Unresponsive POC email
> > shall be marked as such in the database. If ARIN staff
> deems a POC to
> > be completely and permanently abandoned or otherwise
> illegitimate, the
> > record shall be deleted. ARIN will maintain, and make readily
> > available to the community, a current list of
> address-blocks with no
> > valid POC; this data will be subject to the current bulk
> WHOIS policy.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed
> to the ARIN
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML