[ppml] Policy Proposal 2005-2: Directory Services Overhaul

[Azinger, Marla]

In addition to Glenn's concerns and the two I wrote below I can not support this proposal as written.

More Concerns:

1.  I feel it would be best for us to get a definative answer on Privacy Laws and what should and should not be made public accesible information.  Along with a definition of what "public Accessible" really entails. 

This proposal doesn't require you to publish anything publically so hypothetically it could never be at odds with any privacy law.  However, the burden moves back to the ISP to insure that they are in compliance with the law with respect to their customers.  This might be hard for ISP's that span the US and more.

Should'nt we make a policy that applies the same to everyone?  

This proposal provides "choice".  But is that really a healthy policy?  Giving someone the choice would create division between companies that make information "secure" and companies that don't.  This could create an unfair market advantage.  

If we were to choose a policy that enforces security I would hope that it still requires publication but that the publication is secured.  Not information horded away to keep it secure.  I'm not sure if this is possible...but it is another way of doing security that should be reviewed.  I'm sure there are many other ways of securing information that can be reviewed as well.  We should give it the diligence it requires and review as many different ways possible that we can keep information secure.  We shouldn't just approve the first solution at hand which is to "hide the information from everyone".


2.  Nothing is perfect.  If someone doesnt want to take the path of contacting the downstream provider first because they dont trust that the information is correct...then so be it.  No one is stopping them from going straight to the uppstream provider first.  With current policy...the CHOICE YOU HAVE is to choose which contact info you want to pursue.  Why should we take this choice away?  LIke I said, nothing is perfect and there will be invalid emails here and there, but its not hurting anyone having them in the system.

If we move this proposal forward and change what "CHOICE" people have to make then here's what happens:

If you don't publish this information then your company will end up answering all first line abuse complaints.  Which is ok if you are a big company and have at least 5 people working for your abuse team.  However, if you are a small company and you can only have 1 person on your abuse team then they are going to need to publish this information so that their customers can respond themselves to first line abuse complaints.

If it becomes a choice to publish information or not.....then the small companies that have to publish this information in order to keep the headcount cost down within their abuse team ...will end up facing the loss of customers to the bigger companies that can afford to not publish this information and have large headcount in the abuse team.  

Bad data is worse than no data doesn't hold here.  Why would someone publish bad data when they want their customers to be answering to first line abuse complaints?

In my opinion the worst kind of bad data I see is when I got to search who a /24 is assigned to and the only record on hand is that of the large ISP and not who is actually claiming to be using it.


Marla Azinger
Electric Lightwave




-----Original Message-----
From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Glenn
Wiltse
Sent: Friday, April 15, 2005 7:34 AM
To: Member Services
Cc: ppml at arin.net
Subject: Re: [ppml] Policy Proposal 2005-2: Directory Services Overhaul


   I've got ALOT of concerns about this proposal. More then I do with
2005-3.  Ed Lewis rasied several good points that I too am concerned about
relating to this proposal. Many of these terms such as SUSPEND, reclaim,
offenders, or even non-responsive, don't seem to be defined very well if
at all. The problems I have with this proposal are too numerous to go into
in every detail right now.

 Let me just ask about 'reclaim' a resource... Does that mean if a
ISP should assign a /24 to a customer, and that customer should commit
these 'offenses', do you then reclaim a whole /14 or larger resorce that
the /24 is part of?

 Aside from these concerns... If ARIN staff don't have time to track down
'lame delegation' offenders... how are they ever going to tackle this job
being proposed here? This is potentialy a HUGE amount of work for ARIN and
for ISPs with large amounts of re-assignment information. I think this is
way too agressive of a aproach.

  I will not support this proposal as written.

Glenn Wiltse

On Wed, 9 Mar 2005, Member Services wrote:

> ARIN welcomes feedback and discussion about this policy proposal in the
> weeks leading to the ARIN Public Policy Meeting in Orlando, Florida,
> scheduled for April 18-20, 2005.
>
> The policy proposal text is below and can be found at
> http://www.arin.net/policy/2005_2.html.
>
> According to the ARIN Internet Resource Policy Evaluation Process the
> ARIN Advisory Council will evaluate policy proposals after the Public
> Policy Meeting. The feedback and discussion of policy proposals on the
> Public Policy Mailing List will be included in the AC's evaluation.
>
> Subscription information for the ARIN Public Policy Mailing List can be
> found at http://www.arin.net/mailing_lists/index.html.
>
> The ARIN Internet Resource Policy Evaluation Process can be found at
> http://www.arin.net/policy/ipep.html.
>
> ARIN's Policy Proposal Archive can be found at
> http://www.arin.net/policy/proposal_archive.html.
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ### * ###
>
>
> Policy Proposal 2005-2: Directory Services Overhaul
>
> Author: Leo Bicknell
>
> Policy term: permanent
>
> Policy statement:
>
> Replace all of section three with the following rewrite.
>
> 3 Directory Services
>
>    3.1 ARIN Directory Services Databases
>
>       The ARIN Public Information Database (APID) is a collection
>       of information created and collected by ARIN during the due
>       course of business which the ARIN membership has deemed public
>       information and decided to publish.
>
>       The ARIN Confidential Information Database (ACID) is a collection
>       of information created and collected by ARIN during the due course
>       of business which the ARIN membership has deemed is confidential
>       information that should be kept under a strict privacy policy.
>
>    3.2 Directory Information Made Public
>
>       ARIN shall publish verified contact information and the
>       resource(s) allocated (including identification for that
>       allocation, like date of allocation or other information
>       identified by ARIN) in the APID in the following cases:
>
>           - All resources delegated by ARIN.
>           - If allowed by the parent delegation, and requested by
>             the contact listed with the parent, a subdelegation of a
>             resource.
>
>       ARIN shall insure all contact information in the APID is
>       verified from time to time and is correct to the best of ARIN's
>       ability. ARIN staff shall maintain verification criteria and
>       post it on the ARIN web site.
>
>       3.2.1 Non-Responsive Contacts
>
>         If ARIN is unable to verify contact information via the normal
>         verification procedure ARIN shall attempt to notify the parent
>         of the resource to have the information updated. If there is
>         no parent, or if the data is not corrected in a reasonable
>         amount of time the resource shall be SUSPENDED.
>
>         Once the resource is suspended ARIN shall make one more request
>         of all contacts listed with the resource and the parent resource
>         (if available), and if no response is received in a reasonable
>         amount of time the resource shall be reclaimed.
>
>         Third parties may report the inability to make contact with a
>         party via information in the APID. In this case ARIN shall
>         attempt the contact verification procedure for that contact
>         immediately. If a response is received, ARIN should document
>         that a problem occurred, and the response from the resource
>         holder. Offenders who fail to respond to third parties more
>         than 4 times per month for three months may have their resources
>         reclaimed at the discretion of ARIN staff.
>
>         If a third party submits reports of the inability to make contact
>         that are subsequently disproven, ARIN may choose to ignore
>         reports from specific companies, people, e-mail addresses, or any
>         other classification means as appropriate.
>
>         The ARIN staff shall publish the time thresholds and procedural
>         details to implement this policy on the ARIN web site.
>
>         If a resource is reclaimed under no circumstances shall the
>         holder of that resource be entitled to a refund of any fees.
>
>    3.3 Data Distribution
>
>       3.3.1 Methods of Access
>
>         ARIN shall publish the APID in the following methods using
>         industry standard practices:
>
>             - Via the WHOIS protocol.
>             - Via a query form accessible via the HTTP protocol.
>             - Via FTP to users who complete the bulk data form.
>             - Via CDROM to users who complete the bulk data form.
>             - Via the RWHOIS protocol.
>
>       3.3.1.1 Outside Sources
>
>         ARIN may refer a query to a outside source (for instance via
>         RWHOIS or HTTP redirect). Outside sources must:
>
>         1 Have an AUP deemed compatible with the ARIN AUP by ARIN staff.
>         2 Meet the requirements in section 3.3.3.
>         3 Support the applications in section 3.3.1.
>         4 Prohibit the applications in section 3.3.2.
>
>       3.3.2 Acceptable Usage Policy
>
>         All data provided shall be subject to an AUP. The AUP shall
>         be written by ARIN staff and legal and posted on the ARIN
>         website. ARIN may require a signed copy of the AUP before
>         providing bulk data.
>
>       3.3.3 Requirements for Internet Accessible Services
>
>         For any method of access which is provided in real time via the
>         Internet the following requirements must be met:
>
>           * The distributed information service must be operational
>             24 hours a day, 7 days a week to both the general public
>             and ARIN staff. The service is allowed reasonable
>             downtime for server maintenance according to generally
>             accepted community standards.
>
>           * The distributed information service must allow public
>             access to reassignment information. The service may
>             restrict the number of queries allowed per time interval
>             from a host or subnet to defend against DDOS attacks,
>             remote mirroring attempts, and other nefarious acts.
>
>           * The distributed information service must return current
>             information.
>
>    3.4 Distribution of the ARIN Public Information Database
>
>        3.4.1 Supported Uses
>
>          ARIN shall make the APID available for the following uses
>          (supported uses):
>
>            1 ARIN's use in implementing ARIN policies and other
>              business.
>            2 Community verification, allowing members of the community
>              to confirm the proper users of the various resources ARIN
>              controls.
>            3 Statistic gathering by ARIN and third parties on resource
>              utilization.
>            4 As a contact database to facilitate communication with the
>              person or entity responsible for a particular resource.
>
>        3.4.2 Prohibited Uses
>
>          ARIN prohibits the use of the APID for the following uses:
>
>            1 Sending any unsolicited commercial correspondence
>              advertising a product or service to any address (physical or
>              electronic) listed in the APID.
>            2 Using data in the APID to facilitate violating any state,
>              federal, or local law.
>
>        3.4.3 Other Uses
>
>          ARIN shall allow all non-prohibited uses of the APID, however
>          unless those uses are listed as a supported use the data set
>          may be changed in such a way as to render them ineffective,
>          or they may be blocked outright as deemed necessary by ARIN
>          staff. Users of applications not listed who are concerned
>          that they are supported should introduce a proposal to add
>          their application to the supported list.
>
>    3.5 Distribution of the ARIN Confidential Information Database
>
>      ARIN Staff shall use industry standard procedures to prevent
>      the distribution of any data in the ARIN Confidential Information
>      Database.
>
>    3.6 Implementation Details
>
>      ARIN Staff shall document all implementation specific details for
>      directory services in a single document available on the web site.
>      The document must contain, but is not limited to:
>
>        - Database field definitions.
>        - Update procedures.
>        - Templates.
>        - Points of contact.
>        - Copies of the AUP.
>        - Verification procedures.
>
>    3.7 [Routing Registry] Copy Verbatim from the existing 3.4.
>
> Section 4.2.3.7.4: Replace with:
>
>    All reassignment information for current blocks shall be submitted to
>    ARIN prior to submitting a request for a new allocation.
>
> Section 4.2.3.7.6: Strike.
>
>     8. Rationale:
>
> Various proposals affecting directory services have come and gone in the
> last 5 years leaving the policy affecting directory services
> fragemented. Also during that time deployments and laws have changed.
> Several large DSL and cable providers now offer subnets to residential
> customers that may require them to be registered with ARIN. Several laws
> have been passed that may restrict the personal information that can be
> published. This proposal attempts to provide a unified policy that is
> easier to understand, and is updated to deal with these new issues.
>
> Timetable for implementation: 6-18 months, depending on staff
> impact.
>
>
>
> !DSPAM:422f689b17078253968004!
>
>
>