[ppml] Policy Proposal 2005-2: Directory Services Overhaul
Howard, W. Lee
L.Howard at stanleyassociates.com
Fri Apr 15 15:11:59 EDT 2005
> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On
> Behalf Of Azinger, Marla
> Sent: Friday, April 15, 2005 12:54 PM
> To: Glenn Wiltse; Member Services
> Cc: ppml at arin.net
> Subject: RE: [ppml] Policy Proposal 2005-2: Directory
> Services Overhaul
>
>
> 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.
I'm sure there will be a legal review. Isn't that part of the
IRPEP? Ah, I see Leo's post now.
> 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?
If different jurisdiction have different requirements, we'll
have a hard time with that. US law enforcement is pushing for
mandatory publishing (according to NPR's Morning Edition), but
Canadian law pushes toward anonymity. We're back to needing
legal advice.
>
> 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.
I don't see anything about choice. Nothing here overrides the
SWIP requirements. The Public database is the current WhoIs;
the Confidential database is billing information.
> 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.
In that case, the large ISP has made a business decision to
be the first line of response for their customers. Many ISPs
have determined that most of their customers are not equipped
to handle abuse calls, and therefore offer response as a
value-added service.
However, there are some refinements I think are needed. . .
I agree that the terms "suspended" and "reclaimed" are not
clearly defined. ARIN's enforcement powers are roughly
limited to a) removing WHOIS records, b) removing IN-ADDR
records, C) removing IRR records.
Section 3.3.1 isn't as tightly worded as it needs to be.
The APID should be available to users who agree to ARIN's
AUP, not just completing the form. Also, let's not limit
the format; if it makes more sense to use DVD-ROM, Blu-Ray
or cuneiform on clay tablets to publish the data, and if
the requestor is willing to pay for the cost of the CD-RW,
laser, or pallet trucks, that's between staff and the
requestor.
Could the requirements in 3.3.1.1 be in numberic order?
(#3 is self-referential, to section 3.3.1, out of order
with #2 which refers to #3 and #4 which refers to #2.
Yes, that sentence was intentional.)
We should not throw out old section 3.4, RE: Routing Registry.
3.5 could be a little tougher. . . ARIN should take every
reasonable precaution to prevent unauthorized access to the
ACID. Frankly, the industry standard for security isn't
what it should be.
I do support this policy in substance, but it could use a
round of editing.
Lee
>
>
> 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!
> >
> >
> >
>
More information about the ARIN-PPML
mailing list