[ppml] A comprehensive discussion of whois and public data.

[william(at)elan.net]

There are a lot of good points that you make here but a number of things I 
dont agree with either. More comments are inline but briefly:

1. I don't agree that reassignment information should not be listed at all.
   Taking from your example we do have record of subdomain.domain.com, with
   name of the subdomain, list of deligated nameservers that support it, etc.
   Additionally I have not seen any evidence that audit of arin efficiency
   is not possible or has not been done based on available records. If 
   anything the opposite is true and its been done either on the specific 
   cases or overall as kind-of statistical thing but making such audits 
   just completed impossible is a bad thing.
2. Your document/post is not very direct on the aspects about private and 
   piblic information. These are very complex issues as can be seen from 
   many laws regarding this on both state and federal levels where some 
   laws specify rights of people to obtain the information and others 
   rights to privacy to medical records and such. 
3. I generally agree that lots of existing arin policies need to be rewritten
   including ones dealing with reassignment data and whois. I publicly and 
   privately said as much (last time no more then month ago to another 
   member of AC) and that will basicly absolute some of the existing 
   proposals. That is however a very big task that may take years time 
   and until it is done we're better off discussing existing proposals as 
   they can close certain holes in existing system and improve it. And 
   generally this is hardly the only part of ARIN policy that needs to be 
   partially reworked. 
4. In my opionion the rewrite should not be done as way to "REPEAL" 
   aspects of certain policies in making way for compromise. Instead it 
   should be done to simply create better organized clearer text and 
   definitions and should be be based primarily (or even completely) on 
   the policies already passed so as to absolute them with better version
   text but not to replace the with something entirely different in the 
   meaning.

On Mon, 12 Apr 2004, Leo Bicknell wrote:

> $Author: bicknell $ - $Date: 2004/04/12 17:12:20 $ - $Revision: 1.6 $
> 
> I've been doing a lot of research into WHOIS and the various proposals
> that have been made.  A history will be published in the next issue
> of the ARIN newsletter.  Drawing on that history and all of the
> current debates I see a light at the end of the tunnel.  It is my
> personal opinion that much of the challenge individuals and their
> proposals face is the lack of an overall plan.  A proposed change
> may be good for one group, but without updating the other apects
> of policy it may have disasterous implications for other groups.

Lets not overplay this. On too many occasions negotiators try to create an 
acceptable compromise agreement by having one side sacrifice something to 
get something else, the problem is that while it maybe enough to pass the 
agreement needed at that point, it actually leaves hidden rifts which grow 
wider in the future and eventually may spell complete disaster (majority of
wars have been fought because of these rifts grown from previous compromise
agreements).
 
> Fortunately I don't see most of the proposals and desires as all
> that incompatable.  While I'm sure my ideas will not make everyone
> happy, I think there might be a compromise position hidden in the
> details.

Continuing on my case above, I'd like to point out that situation is such 
that if you try to introduce points in this "compromise" that every party 
does not like, the proposal will fail miserably. Unlike cases with some 
political situations where compromise agreement is a MUST for future
for both sides, we do not have such with ARIN as we already have a policy 
and process to amend it and if we are to do complete rewrite it is not to 
be a compromise but either a clarification of existing policy or something 
much much better. It would be worth decision to try to introduce something 
that would be unpopular (or require sacrificies) from all sides when 
existing policy system does not have this problem.

> To that end, this is a very long, but I hope comprehensive look at
> the situation.  This is not a proposal, and is not in the proposal
> process at this point.  Indeed, for many reasons I don't know how
> to make it a proposal right now.  To make sense this document
> contains several proposals, and repeals several existing proposals,
> and that all must happen as a package or not at all to make sense.
> The current policy process is not friendly to these sort of multi-part
> proposals, indeed they are often shot down due to a minor flaw in
> a single part. 
Hrm... This is actually more of an issue with how ARIN process works in 
general. But I really see nothing in there to defy that possibly larger 
proposals will be shutdown even faster then smaller ones. If anything, 
one flow on one side of it may well shutdown it down as well. In fact, I 
think we have seen this exact thing with last IPv6 proposal.

> Rather, for now I would like to see if the various
> parties do see this as a sort of acceptable middle ground.  Please
> think on this before responding.  I attempted to look at the problem
> individuals were trying to solve, not their proposed solution.
> While I may not have solved your problem your way, I hope that I
> have solved it in a way you can accept.
> 
> Note, this is NOT a current proposal.  It is NOT on the agenda for 
> Vancouver.  I post this now to get feedback, and so I can talk to 
> people at Vancouver about these ideas.  
If you want to have a BoF about it, this can be done and I'll actively
participate as I think will many others (this can be either done as part 
or right after ARIN's proposal's BOF or at separate time after the main 
sessions of the meeting). And in the future we can continue discussion on 
this list. Note that I'd be against having AC continue discussions of this 
on its own - I view role AC as more of editor when community calls for
it but not as an author - this process of authoring the proposals should 
be an open one done on this list (preferably) with members of AC
participating just like everybody else.
 
> Enough intro, to the meat of the matter...
> 
> There is a lack of consensus on the purpose of the "Whois" database.
> Indeed, it has lead a schizophrenic existence.  Starting as the
> Internet White Pages, moving to the single point of all Domain/IP/ASN
> Info (at InterNIC) to today when "whois" properly is no more than
> a protocol to get at various databases, one of which is run by ARIN.
> 
> Indeed, let's start with this most basic fact.  It's not the "Whois"
> database.  It's a database of ARIN public information that's available
> via the WHOIS protocol, also available via a web interface
> (http://ws.arin.net/cgi-bin/whois.pl), and in bulk form via FTP
> (http://www.arin.net/library/agreements/bulkwhois.pdf).  This is a gross
> overloading of terms.  I'll start with a new term:
> 
>       ARIN PUBLIC INFORMATION DATABASE
> 
>       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.
So far so good. 

Of course, the problem is that above avoids the main issue - we as a 
membership still need to decide what is andshould be public information
include what should be required to be public information.

> There is a corresponding database that also needs to be defined.  ARIN
> collects other information in the course of business that do not get
> published.  Examples include Network Maps from companies
Hey, I personally want to see it all get published! Why should I be 
looking at the Darth Vader's image instead of a network map :)

> their credit
> card information for billing, and internal contacts not listed in the
> public database.  I'll give that a definition as well.
> 
>       ARIN CONFIDENTIAL INFORMATION DATABASE
> 
>       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.
Again as general statement definition this works fine. Same problem with 
having to decide about what exactly falls under this definition.

> {Note, a privacy policy needs to be defined for ACID, but I believe that
>  is outside the scope of this particular document as it focuses on the
>  public information.}

This I disagree with. We can not and should not proceed with redefinition 
of whois/data information unless we're willing at the same time to work 
on the private/public issues of that information. That is not to say that 
I completely disagree with you - as I recently wrote to somebody else at 
AC, we need to clear current confusion with policies and clearly separate
and define what data is private and what should be public. But these are 
just better grouping issues as part of the overall system.

> Now that we have precise terms for the groups of data, a statement
> can be made about how that data should be published:
> 
>       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.
> 
>       All data provided shall be subject to an AUP.  The AUP shall
>       be written by ARIN staff/legal and posted on the ARIN website.
>       ARIN may require a signed copy of the AUP before providing
>       bulk data.

Ok here we have text from my Whois AUP proposal. Obviously I agree :)
And in reality like your defitions this is not as much for an "compromise"
point. I've not seen anybody that disagreed with above in any serious way.

> So far the definitions have been easy, now the harder parts.  What
> goes in the public database, and what uses of that information are
> supported.  I'll tackle the latter item first, as it impacts what
> goes in the database.
> 
> Clearly the first use of this data is to support ARIN's business
> of allocating numbers.  ARIN must collect data to implement the
> address allocation policies as outlined by the community.  ARIN
> then creates data as various items are issued to the ARIN user base.

Yes, clearly the data that is being gathered is specific to the
resources under ARIN's managements - i.e. ip blocks, ASNs and how
they are supposed to be used and by who.

> The second use of data is nearly as important though, and that is
> one of community verification.  The community uses the APID, and
> other sources, to verify that entities are using the resources they
> are supposed to be using.  Since there is no "police force" this
> sort of community policing is absolutely required.  Note that today
> in the case of RWHOIS the community may have to query a server run
> by someone other than ARIN to get some information.

In my view nothing wrong with that as long as that entity is acting 
responsibly and providing access as ARIN would have done. In reality
it does not matter if organization submitted a swip and data is now served 
by ARIN or if organization serves data directly. Its still same data
and same rules should apply.
  
> Community verification has two aspects to it.  First, the community
> may want a third party to provide some verification that resources
> have been allocated.  Second the community may want to verify that
> ARIN is doing its job properly.  Unfortunately there is a problem
> with the second use.  ARIN may use information in the ACID database
> (including but not limited to network maps, business plans, and
> customer network information) during the course of business.  Since
> these items are not available in the APID it would be impossible
> for someone to audit ARIN's track record based on the APID alone.

Disagree. Its quite possible to audit based on public information - we're 
not talking about exact audit of each and every detail - this takes 
tremendous resources and human but appoximation of arin activity and
audit based on statistics with overal numbers being in favor of ARIN or 
against it are quite possible if all the allocations are in the database.

> Due to the fact that it would be impossible to audit ARIN based on
> the APID data, and due to the fact that I know of no attempts to ever
> audit ARIN (or any other RIR based on that data) it would seem that
> item is of low importance.  

See above on why this is not true. As a partial example I've done research 
on efficiency of RIR allocations with data published at
 http://www.completewhois.com/statistics/rir_ratios.htm
This would not have been possible if it were not for available of data in 
ARIN database. At the end of January I also wrote script that examined 
ARIN database in bulk including swips and tried to follow what percentage 
of space has been swiped in which /8 blocks. I intend to come back to this 
in the future when some additional necessary tools are ready and when I 
can run this continuesly for certain period of time and see how it changes 
for new blocks or blocks that are extended as opposed to old blocks as 
well as compare this to similar "PA - provider assigned" data from RIPE 
and APNIC databases. You can view this work as partial audit even if its 
been done as more of a research kind of way. But the point is its quite 
possibly to do audits with public data - there is no necessity to have 
100% of every detail just overall picture is enough.

> Indeed, were an audit to be necessary
> an outside party would most likely have to come in with NDA access
> to the ACID database for it to be properly performed.

An outside agency full audit would only be necessary if we have enough 
data that something is wrong. More then likely such doubts may happen as
a result of some partial audit done based on public information that 
reveals problems. 
 
> The third use of data is in statistics gathering.  First order
> statistics (how much of resource X is in use, how fast is it being
> used) are necessary for the community to determine policies for
> distributing resources, and to determine when resource pools are
> exhausted and new solutions must be found.  The second order
> statistics are generally used by third party research firms who
> perform some level of data mining on the APID to produce statics
> like the relative uses in different geographic areas, market segments,
> and other groupings that don't directly show up in the APID.
> 
> The fourth use of data is as a contact database.  For operational
> and abuse reasons it may be necessary to find a contact e-mail
> address, phone number, or mailing address for the person or entity
> who has been assigned space.  The question that arises with contact
> information is what level of information is required, however that
> will be addressed with what information goes into the APID, not
> with the general categories of data.

Of all use of ARIN data -  this is the MOST IMPORTANT ONE.

> In addition to the supported uses, there are some uses that are
> expressly prohibited:
> 
> Contact information from the APID should not be used to send
> unsolicited commercial e-mail, postal mail, or via any other method
> of delivery advertising a product or service should be prohibited.
Agree. 

> No information from the APID should be used to violate any state,
> federal, or local law.

Lets be carefull about "any". There are so many laws... 

In my view the overall data should not violate laws as they are defined in 
the county where ARIN is registered. And any specific data should in 
addition to that not violate any possibly stronger local laws in the 
community where the person or organization who/that submitted data to 
ARIN operates.

> This leaves a potentially huge grey area of uses of the APID that
> are not on the supported or prohibited list.  All of these uses
> should be allowed, but ARIN makes no assurances that the data
> in the APID will be fit for any of those purposes, or that the
> data in the APID may be changed at a later time in a way which
> may have adverse affects on these unsupported applications.  Any
> users who have a new application they feel should be supported
> need to have that application approved by the membership to be
> added to the supported application list to ensure it will be
> considered with future proposals.

I'll reserve my option on this point, though I think ARIN should not
have to review every new application for its data - if something is wrong 
it will be brought to its attention.

> Finally, to offer the above in proposal form:
> 
>       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.
>
>       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.
The above (both supported and prohibited parts) is basicly what I included 
as guidance points in rewrite of Whois AUP proposal as something that ARIN 
Council should futher work on to create an actual text. See below about it
  
>       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.

I'm not sure I agree with giving this much power.

>  Users of applications not listed who are concerned
>       that they are supported should introduce a proposal to add
>       their application to the supported list.

Again I'm not sure its good idea.
 
> Now, last but not least, since we know what are the supported uses
> of the APID we can look at what information is required to be in the
> APID to support each point.  Clearly the data set that needs to be
> supported in total is the union of all of the individual data sets.
> 
> Supported use #1 - No data needs to be listed in the APID to support
>   ARIN's implementation of policies.  All data could be listed in the
>   ACID for these purposes.
I do not see why implementation of policies is purely an confidential 
matter. In fact public verification as from #2 seems to apply here.
 
> Supported use #2 - For community verification all resources managed
>   by ARIN need to be listed, along with contact information.  A
>   mechanism should be supplied to allow the delegation by resource
>   holders for subsets of the resource where desired by the holder.
>   For the purposes of verification delegation of subsets is completely
>   optional.

I disagree. The deligation is not optional but mandatory for proper audit 
of ARIN's activities as well for other uses too.

> Supported use #3 - Statistics are one of the biggest problems.  First
>   order statistics are generally published by ARIN outside of the APID
>   or ACID, and there is little need for that data to be replicated by
>   outside parties.  Of more interest in second order data.  In order
>   to get the most useful second order statistics the groups gathering
>   that data would like the largest amount of information present in
>   the database.  Aside from the ARIN membership using some of the
>   statistics presented from third parties, there has been no consensus
>   to date on ARIN funding or making available specific data for those
>   uses.
> 
>   As a result, while statistics should be a supported use, they should
>   not that this time influence what is, or is not in the APID.
That there has been no consencus on ARIN's sponsoring certain projects, 
does not mean there is not a niche for those statistical projects or that 
there are no commercial interest in such statistical data.
 
>   ARIN may want to develop a program such that under NDA and other
>   controls approved organizations can access portions of the ACID
>   database in order to get additional data.
If we do not require certain data to be made available, it just will not be.
Limiting to NDA will also limit who is willing to actually do these kinds 
of statistical or other research which is not good for community. We 
should focus on existing bulk whois agreement instead.
 
> Supported use #4 - For use as a contact database, all resources
>   managed by ARIN need to be listed, along with contact information.
>   In addition, policies and procedures need to be in place to keep
>   that contact information up to date.
Ok good so far.

>  Realizing that contact information
>   is a management burden, ARIN should support the minimum set of data
>   that allows for generally accepted methods of communication.
Or, come on, - this is just an excuse not to list contact data for actual 
user, which is a BIG plus during investigations of any kind of abuse 
activities. As far as burden, its on whoever submitted data to ARIN and 
they should be required as a matter of policy to keep data up to date
and have verification and reporting mechanisms when its not (ARIN may 
possibly facilitate in such conversation).

>   To that end, ARIN shall list e-mail, phone, and postal contacts
>   for all direct resource delegations, and have a procedure to
>   periodically verify that information.  The contact must verify
>   that they are responsible for the resource in question, and that
>   the contacts listed are the correct ones for dealing with any
>   issues resulting from the use of that resource.  A mechanism
>   should be supplied to allow for the delegation of a subset of a
>   resource along with contact information.  Delegated contact
>   information shall be verified using the same procedure as direct
>   delegations.  These subdelegation should be marked as able to
>   be further sub-delegated or not.

This is what is already being done as ARIN alredy has record indicating if 
the organization can act as ISP and futher subdeligate or not.
 
> A sticky point in e-mail, but much more so in some of the public
> policy meetings is that there is not agreement on the valid uses
> for APID data.  One one end, some want APID to revert back to it's
> earlier behavior of being a sort of white pages for the Internet.
> The opposite view is that only the highest level of information
> should be in the database, and that any further information should
> be sought from the organization listed in the database.
> 
> The first thing to do is look for precedent.  While the initial
> database was all encompassing, as early as 1994 that started to
> change in policy (and possibly a bit earlier in practice).  An
> interesting case study here is the similar-but-different case of
> DNS names.  If "harvard.edu" delegates "cs.harvard.edu" to the CS
> Department for use there is no requirement DNS Registrars be notified.

No, but there is a record of actual subdeligation. It includes at the very 
minimum actual subdeligation name and also list of dns servers that 
service the subdomain. What you're proposing that that exist subdomains 
that there be no public records on tht existance of these subdomains at 
all in amy public records.

> There is no protocol requirement to put contact information (or
> anything besides basic nameserver IP's) in the protocol.  There is
> the ability in the protocol (via RP records, and TXT records) to
> list that information.  However, if that information is not listed
> and you want to know something about "cs.harvard.edu" you must back
> up one level in the tree to "harvard.edu", contact them and hope
> they will pass you along to the right people.
> 
> Perhaps more interesting from a practical point of view is that a
> smaller amount of valid contact information is generally much more
> useful than a larger set of invalid data. 

Its a lot better to know when data has been verified and is valid.
This does not mean the rest of the data that has not been verified
is not interesting from practical point of view.

> In addition, there is a
> cost to maintaining valid data, in that ARIN must expend resources
> keeping the data set up to date.  All of these point to a minimal,
> but highly verified and accurate data set as being the cheapest
> solution that also provides the highest probability of getting a
> valid contact.

ARIN should verify contacts for organizations it directly deals with.
Verification of the rest of data should be on the hands of these 
"1st level" organizations with ARIN getting involved as last point
and only if organization is not doing anything about it and in that case 
it itself may fact same "punishment" as if it were directly trying not to 
maintain proper records.
 
> As a last point on this subject, there are cases where the entity
> that has been given use of a resource, and the person who should
> be listed as a contact for a resource are different.  For instance,
> managed services companies often allocate resources for their
> customers, but are tasked with answering all external queries about
> those resources, and either answering them directly for their client
> or forwarding them to their client as appropriate.  The system
> adopted should support these situations, has having the proper
> contact in these cases is far more likely to lead to useful information
> than having the actual user of the space listed.
No you're wrong as you're mixing things up. One is direct human or robot 
contact which may well be the ISP and not actual end-user and helps 
facilitate immediate resolution. The other is tracking down the abusers, 
stopping it when ISP is not being responsive (want to know how much space 
they have been deligated), etc. Both parts of data (contact and registrant 
information) are usefull and important.

> Finally, this leads to the policy of what should be in the APID:
> 
>      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
>            originally delegated by ARIN.
I agree with requiring to be listed only contacts that are verifiable
and are willing to be contacted. I disagree about not listing registrant 
at all or the amount of space they have been deligated.
 
>      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.
Agreed.
 
> To comment on the implementation.  I suspect SWIP as it exists today
> would remain, simply having a two flags added to the template.
> "Make public", and "allow downstream to SWIP".   Both would default
> to no, making all information appear only in the ACID. 
No, no, no. If anything "make public" should be default. Allow to SWIP
should become yes if certain contact is added to that SWIP that has 
such responsibility.

> Sites using rwhois could choose to restrict access to their rwhois 
> server to ARIN staff netblocks only if they do not whish to make their 
> information public.
I have to say that currently rwhois is not such a gree protocol for doing 
restrictions on who can view only one subset of data. Most who run rwhois
have all its data public and if it is not enough for ARIN when its making 
decision on additional allocation to that organization, then they provide 
in different form additional information to ARIN. There are also couple 
organizations that run rwhois server completely private, supposedely only 
for ARIN's access.

> Last but not least, some teeth are needed.  Without them companies
> could simply not comply with the policies.  As such a mechanism
> is needed to punish those who do not comply.
> 
> There are two ways ARIN may find non-compliance.  First, ARIN may be
> unable to verify contact information during the verification process.
> In this case the resource should be put in a suspended state, and
> the parent for that record should be contacted. 
Agreed.

> In the event there is no response for repeated attempts after the 
> resource has been suspended the resource shall be revoked.
Be carefull  with saying that. Are you willing for ARIN to revoke legacy 
allocations? Or allocations made prior to these new rules where 
organization did not agree to them? 

> The second method is that ARIN may be notified that someone is
> unable to contact an entity.  The entity reporting the problem must
> show proof of attempting to make contact via two different methods.
> ARIN should then follow the standard contact verification procedure
> to verify the contact, and if verified seek explanation as to why
> there was no response.
> 
> ARIN may set a threshold after which repeated reports by third
> parties will result in suspension, even if verification succeeds.
> ARIN may also set a threshold after which it can ignore notices
> from those sending incomplete reports, or reporting organizations
> which can document responses.

These are all details that can be worked out later on. I'm actually not 
100% certain if these details should be part of the policy or operating
setup that ARIN adapts but we can talk about it more. 
 
> The proposal:
> 
>      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.

I would change this to having first resource marked as INVALID. 

>      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.

And after resource is marked is INVALID and organization does not 
reestablish resource validity within certain period of time, ARIN should 
have an option to not renew the resource at its next billing annivessary. 
Possibly this is pretty simular to how Leo imagines the process above 
anyway.

My opinion is that we should have this all discussed as part of
discussions on current POC Verification proposal.

>      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 occured, and the responce from the resource
>      holder.  Offenders who fail to repond to third parties more
>      than 4 times per month for three months may have their resources
>      reclaimed at the discression of ARIN staff.

Also should be discussed as possible details for POC Verification.
 
>      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.

If this is done without resource holder having agreed to new policies as 
part of the service agreement they have signed when they got the resource, 
then attempts to completely revoke the resource may well lead to court.
Opinion of ARIN's legal council should be asked before we proceed on 
anything similar to above in ARIN policy process.

> The proposals listed above overlap with some other proposals already
> passed and in the process.  They are enumerated below, along with
> the reasons they should be abandoned or repealed.
> 
> * 2002-3 - Residential Customer Privacy.
> 
>   This policy should be repealed, as under my proposal there is no
>   requirement to list residental customers at all.  These policies
>   do not conflict, but do not make much sense together.

It should be "REPEALED", it should be ABSOLUTED by rewrite of policy that 
focuses on PUBLIC & PRIVATE information.
 
> * 2002-4 - Bulk Copies of ARIN's whois
> 
>   This policy should be repealed, as under my proposal there is a
>   definition of when an AUP is needed.  These two policies potentially
>   conflict.

2003-9 will ABSOLUTE this policy anyway.
 
> * 2002-8 - Privatizing POC Information
> 
>   This policy should be repeaed.  Under my proposal a company may
>   make available contacts that are only listed in the ACID.  My
>   proposal is also flexable in that ARIN staff can allow many more
>   contacts than are on the existing template into the ACID as necessary
>   without them appering in the APID.  Indeed, I expect ARIN staff to
>   encourage users (via new forms and methods) to list role accounts in
>   the APID, while providing individuals for the ACID, which should
>   make some interactions much easier for the ARIN staff.

Same as 2002-3, this should be ABSOLUTED by new PUBLIC/PRIVATE information
policy that defines what kind of information is REQUIRED to be public.

> * 2003-9 - Whois Acceptable Use Policy (AUP)
> 
>   This policy should be abandoned.  My proposal requires an AUP as this
>   proposal does, but leaves it up to ARIN staff and legal to both write
>   the policy and keep it up to date.  ARIN staff may want to use this
>   proposal as a template.

As members of AC should already be aware (including Leo), I proposed 
exactly that to AC already - that instead of providing exact text of AUP 
that its main points be included as guide for ARIN legal council to 
create actual legal document. I intend to proceed in this direction and 
still awaiting comments from AC on this point as well as comments from 
ARIN legal council, especially on if he is willing and able to present a 
draft version of the AUP right after presention of the proposal. Time is 
short however, if I do not receive comments by end of Wednesday, I'll 
have no choice but to request update of proposal text on my own (so it 
would be ready for public policy meeting) and present this new version on 
the public policy meeting.

> * 2003-16 POC Verification
> 
>   This policy should be abandoned.  My proposal includes POC
>   verification,  and allows ARIN staff to define the procedure and
>   publish it on the ARIN web site.  ARIN staff may want to use this
>   proposal as a template.

Again, I see no reason why the policy should be abandoned. We should try 
to work on POC verificion mechanism now and if anything try to implement 
it and see how it works and what can be improved in it. This would help in 
the future general policy rewrite but its a good on its own and can 
easily be integrated with future rewrite.

> * 2003-5 Distributed Information Server Use Requirements
> 
>   This policy should be MODIFIED.  This proposal covers many items,
>   most of which are covered in my proposal, however there is one
>   important item which is not.  This policy requires rwhois servers
>   to be available 24x7 to the public.  This is an important proposal,
>   and should continue on that point alone.  If an entity is going
>   to publish information via rwhois they must take commercially
>   reasonable actions to make it available 24x7.  Adding that
>   requirement to my proposals would put it in the wrong place.

Same as with 2003-9 and 2003-16, it works on specific issues and
when doing overall rewrite of the policy it is also replaced by new 
whois/database policy and becomes part of it. Neither one should be 
MODIFIED or ABANDONED. They should all be ABSOLUTED by new better
rewrite of policy texts.

---
William Leibzon
Elan Networks
william at elan.net