authorizing changes in the new registration database

[Cathy Murphy]

On Tue, 21 Aug 2001, Shane Kerr wrote:

> [ Warning: long, strange trip follows. ]

My favorite kind. Say hello to Hari for me. :)

[ Warning: an equally long, though less eloquent, response. ]

After trying to formulate a coherent response to your philosophical
musings (which raised some intriguing technical issues), I decided
to postpone that discussion and, for now, respond to your comments 
to our specific questions.

> > Question 1 - Who should be authorized to create an organization record
> >              for a reallocation or reassignment?
> > 
> > Option A: The upstream ISP creates an organization record on behalf of
> >           the organization receiving a reallocation or reassignment.
> > Option B: The customer organization creates its own organization record.
> > Option C: Either the customer or the upstream ISP may create the 
> >           record. [2]
> 
> Option C makes sense to me, IFF there is a mechanism for the upstream
> ISP to be notified of changes to the organization record, with the
> contents of the original record.  This will allow ISP's some degree of
> certainty that the information will not be changed without their notice,

Notification is possible, but let's consider: one of the benefits of
allowing a downstream customer organization to create and maintain its own
org record is to accommodate the multi-homed customer. If the customer
record is being used on registrations from different providers, the
logical action would be to notify all upstream providers about the change.

I question whether this is something we really want to do. Either the
upstream ISP controls the downstream's org info, or it doesn't. Does the
notification really provide any value to the upstream provider? 

> and if they don't like the new information that they can create a new
> organization with the necessary info.

Yikes! This is exactly what we are trying to discourage. While this might
be necessary, it leads to the situation we face today:  two, three ... 
ten records for a single entity, all with slightly different company names
and addresses. The only reason to permit option B in the first place is to
reduce the likelihood of this happening. 

In this case, I worry that the change notification might actually lead to
more org records being created than if we just say from the start that
multi-homed downstream customers are going to have as many org records as
they have upstream providers.

> > Question 2 - When should this organization record be created?
> > 
> > Option A: The record should be created before the reallocation or
> >           reassignment is made via a separate "Organization Template."
> 
> One potential problem with option A is cruft building in up in the
> database.  If random folks (like me!) on the Internet can create
> organization records without having received any allocations, then
> you're going to have people doing this.  Even if it restricted to
> members only, you're still going to see unreferenced records due to
> mistakes, confusion, or other problems.

We considered this, but we plan on having functionality in place that will
track if and when these records become "resource-less".  After "N" number
of days of remaining resource-less, a record would be automatically
deleted. Yes, some useless records are going to get created and they might
reside in the database (and get displayed in Whois) for a little while,
but they will not become permanent cruft. This is the same situation we
are likely to have with POC's.

When deciding to suggest this, we balanced the potential for garbage-in
data collection against the ease of making the registration. If we
implement this, and we find it is being abused more than it has proven
useful, we can always disable the functionality. It is definitely a
concern we'll need to monitor over the long term.

The question at this point remains: is it something we should even try,
given these concerns? 

> > Question 3 - Should the customer organization record be permitted to
> >              have the POC of their upstream ISP or must the POC be
> >              from their own organization?
> > 
> > Option A: The POC is the upstream ISP. The upstream ISP
> >           would have control over reassignment data since the
> >           customer organization would not be able to update its
> >           own organization data. 
> > 
> > Option B: The customer organization must have their own POC. If they
> >           directly apply for address space in the future, ARIN will be
> >           able to identify how they have managed space in the
> >           past. ARIN can maintain a more accurate database and reduce
> >           duplicate responses to a whois query for a common name.
> > 
> > Option C: The customer organization may have their own POC, but the
> >           upstream ISP might alternately specify its own POC for the
> >           reallocation.
> 
> Is each allocation not going to have its own POC, independent of any
> organizational POC?  

No, quite the reverse. [We probably should have been more specific in our
POC terminology while explaining this.] Each allocation may have a
technical POC, which will allow them to do things like provide
reassignment information. However, an organization's administrative POC is
normally a superset of the technical POC's authority.  Question 3 relates
to this administrative POC on the downstream customer. Must it be
different from the upstream, or may the upstream maintain administrative
control of the org info, even though it might be turning over
administrative control of the allocation to the downstream customer? 

> This would allow an ISP to specify either their
> organizational POC, their downstream's POC, or even a different POC,
> while still allowing the downstream to update its organization
> information in all cases.

I believe that this is what we were trying to get at in Option C. In this
case, the admin POC on customer organizations does not represent a
superset of authority. Rather, authority would be limited to updating
organization information only.

> 
> Shane
> 

Hope this clarifies things a bit. 

Cathy