From michaelo at arin.net  Fri Aug 10 14:12:59 2001
From: michaelo at arin.net (Michael O'Neill)
Date: Fri, 10 Aug 2001 14:12:59 -0400 (EDT)
Subject: authorizing changes in the new registration database
Message-ID: <200108101812.OAA06455@ops.arin.net>


Hello!

During the design of ARIN's new registration database, ARIN staff has
identified some issues with respect to authorizing changes to the
database. We've outlined our concerns below and are requesting any
comments from the community.

In the new database schema, every network registration including
reassignment and reallocation registrations (i.e. SWIPs) will be
associated with an organization record that contains the name and
address of the organization holding the IP space or AS registration.

In the current database, the upstream organization is the only entity
with the authority to add/modify/delete reassigment information.

Building a more reliable, maintainable, and modular system, however,
requires a new division of authorization.  Under this separation of
maintenance responsibility, downstream customers organizations that
have reallocations or reassignments would be authorized to:

  * add/change/remove POCs associated with the downstream customer
  * add/change/remove a public comment about the downstream customer
  * change the mailing address of an downstream customer

but would not be authorized to:

  * return IP resources such as networks
  * update any network attributes including the network name, in-addr
      nameserver, comments, or further reassignment data, unless
      otherwise authorized as discussed below [1]

This raises these questions for comment:

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]

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."
Option B: The record should be created at the same time that the 
          reallocation or reassignment is made via an expanded 
          "Reassignment Template" that includes the organization
          information. 
Option C: The Organization may either be created using the "Organization
          Template" [A] or via the "Reassignment Template" [B].


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.

NOTES

[1] In January, there was discussion on ARIN's Database Working 
    Group mailing list regarding changing an Assigned network to 
    an Allocated network.  The result was that only the upstream 
    has this authority, and ARIN has been enforcing this since 
    that decision. We envision no change to this policy. Please
    see the mailing list archives for further details.
    http://www.arin.net/mailinglists/ppml/0152.html

[2] Before drafting the new database schema, the
    http://www.arin.net/mailinglists/dbwg/0110.html mailing list
    archives discussed these issues on a preliminary basis. Support
    was shown at the April PPM for Option C


Michael J. O'Neill
ARIN Engineering

==============================================================
email                              michaelo at arin.net
==============================================================


From shane at time-travellers.org  Mon Aug 20 19:45:02 2001
From: shane at time-travellers.org (Shane Kerr)
Date: Tue, 21 Aug 2001 01:45:02 +0200
Subject: authorizing changes in the new registration database
In-Reply-To: <200108101812.OAA06455@ops.arin.net>; from michaelo@arin.net at 2001-08-10 14:12:59 -0400
References: <200108101812.OAA06455@ops.arin.net>
Message-ID: <20010821014458.A8697@mars.lab.time-travellers.org>

[ Warning: long, strange trip follows. ]

On 2001-08-10 14:12:59 -0400, Michael O'Neill wrote:
> 
> During the design of ARIN's new registration database, ARIN staff has
> identified some issues with respect to authorizing changes to the
> database. We've outlined our concerns below and are requesting any
> comments from the community.
> 
> In the new database schema, every network registration including
> reassignment and reallocation registrations (i.e. SWIPs) will be
> associated with an organization record that contains the name and
> address of the organization holding the IP space or AS registration.
> 
> In the current database, the upstream organization is the only entity
> with the authority to add/modify/delete reassigment information.
> 
> Building a more reliable, maintainable, and modular system, however,
> requires a new division of authorization.  Under this separation of
> maintenance responsibility, downstream customers organizations that
> have reallocations or reassignments would be authorized to:
> 
>   * add/change/remove POCs associated with the downstream customer
>   * add/change/remove a public comment about the downstream customer
>   * change the mailing address of an downstream customer
> 
> but would not be authorized to:
> 
>   * return IP resources such as networks
>   * update any network attributes including the network name, in-addr
>       nameserver, comments, or further reassignment data, unless
>       otherwise authorized as discussed below [1]

Before addressing any specific questions you raise, I'd like to wax
philosophical for a bit about the ARIN database in general, with the
help of my friend Hari:

Me: "So, I've been thinking about the point of the records in the ARIN
     database."

Hari: "And I thought I had no life."

Me: "Anyway, I was wondering what the point of all that information,
     contact and otherwise, is."

Hari: "Obviously so you can figure out who's using what IP numbers."

Me: "Okay, so when you say 'you can figure out', who exactly are you
     talking about?  Who cares who's using what IP numbers?"

Hari: "Well, for starters the person who's computer is hooked up to the
       Internet!  Not to mention that person's ISP...."

Me: "Ah, but the ISP gets that information from ARIN directly.  They
     don't need to look it up.  And the person running the computer gets
     the information from the ISP, so they don't need to look it up
     either."

Hari: "True, true.  Hmmm... how about the peers of the ISP?  If the
       peers are responsible then they may check ARIN's database to
       verify that the space is really allocated to that ISP!"

Me: "Good point.  I wonder if that ever happens in the real world?  But
     why would you need a public database for that?"

Hari: "As opposed to..."

Me: "If the point was really so ISP's could check up on either other,
     then ARIN could run a private database for them.  There can't be
     more than a few thousand, not nearly enough to generate more than a
     couple dozen queries a day."

Hari: "But what about the ISP's customers who want to peer on their
       own?  It doesn't sound like this can scale..."

Me: "That make sense - and I want to come back to that - but first
     there's one more user of the database to bring up.  As a
     hypothetical example, say someone was trying to connect to port 80
     of my mail server, which doesn't run a web server."

Hari: "That's crazy!  What are the chances of you ever seeing an HTTP
       packet for a computer not running a web server!?!?!"

Me: "I've heard it can happen.  Anyway, say you wanted to send a kind
     note to the ISP of the computer trying to connect to you, so they
     can help their customer...."

Hari: "Right.  I'd look them up in ARIN's database.  Well, unless they
       happened to be in Europe or Asia or something."

Me: "Let's be honest - you'd still look the IP up in ARIN's database
     first, right?  Do you know where each /8 is?  But more importantly,
     is everyone who needs this information an ARIN member?"

Hari: "No, of course not."

Me: "Or someone who has an allocation in the ARIN database?"

Hari: "Probably not..."

Me: "So we have two kinds of folks looking stuff up in the ARIN
     database.  And if I had to bet, I'd say at least 99% of all the
     folks using the allocation information are not ARIN members."

Hari: "I assume you'll be getting to the point sometime today?"

Me: "Almost there.  Now, assume for a minute that there are a lot of,
     shall we say, 'less informed', Internet users out there?"

Hari: "Less informed than you?  That's asking me to strech my
       imagination pretty far."

Me: "Ah-hem.  So these users see an e-mail that looks like it's coming
     from 3.1.33.7, but instead of realizing that it's a forged header,
     they send nasty mail to our friends at 3.0.0.0/8, asking them to
     please not send any more mails about Snow White."

Hari: "That would be pretty annoying.  For 3.0.0.0/8, I mean."

Me: "Indeed.  So if you don't want to peer, and you don't want to get
     bothered by clueless Internet users, then there's every reason for
     you to *not* want correct contact information in the database!"

Hari: "Holy Inconsistent IP Information, Bat Man!"

Me: "Getting back to the point about scaling.  We know the two kinds of
     people who want to get information out of the database ..."

Hari: "ISP's and end users."

Me: "... but we still need to investigate who puts the information in."

Hari: "First there's ARIN.  And then there's the ISP's.  And any
       customers of the ISP's."

Me: "Well, I'm not so sure about that third one, which is unfortunate
     because that's the most problematic."

Hari: "How so?"

Me: "If ARIN or one of ARIN's members puts incorrect information in,
     then ARIN can ask them to fix it, with the understanding that
     there's a little bit of both stick and carrot for them."

Hari: "Right - besides wanting to keep ARIN's information accurate to
       avoid probles with future allocations, they may need the
       information for peering.  But what about the ISP's downstreams?"

Me: "That's the problem.  They don't have either incentive to keep the
     information up to date - and as we've seen, they actually have
     incentive to put old or incorrect information in the database."

Hari: "Okay, that's a problem."

Me: "But having the ISP's update it doesn't scale, remember?  For users
     that want to keep their own information up to date, it's easier to
     go straight to ARIN."

Hari: "Hmm... yeah.  So what does this mean?"

Me: "It's a mess.  There are no easy answers."

Hari: "Can't we just let each ISP decide for themselves how to do it?"

Me: "Sure, but the basic incentives will still be there."

Hari: "This stuff is too hard.  I'm going to go take a nap."

At this point Hari left to my own devices....

> This raises these questions for comment:
> 
> 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,
and if they don't like the new information that they can create a new
organization with the necessary info.

> 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."
> Option B: The record should be created at the same time that the 
>           reallocation or reassignment is made via an expanded 
>           "Reassignment Template" that includes the organization
>           information. 
> Option C: The Organization may either be created using the "Organization
>           Template" [A] or via the "Reassignment Template" [B].

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.

Given this, option B makes more sense to me.

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

Shane


From huberman at gblx.net  Wed Aug 29 03:18:46 2001
From: huberman at gblx.net (David R Huberman)
Date: Wed, 29 Aug 2001 00:18:46 -0700 (MST)
Subject: authorizing changes in the new registration database
In-Reply-To: <200108101812.OAA06455@ops.arin.net>
Message-ID: <Pine.GSO.4.21.0108290007230.28731-100000@shell1.phx.gblx.net>

 
> 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! Isn't Option C one of the points of the new database - to
create flexibility?
 
> 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."
> Option B: The record should be created at the same time that the 
>           reallocation or reassignment is made via an expanded 
>           "Reassignment Template" that includes the organization
>           information. 
> Option C: The Organization may either be created using the "Organization
>           Template" [A] or via the "Reassignment Template" [B].

Yikes. 

I'm inclined towards Option B, but that's only personal
preference. Certainly Option A requires a bit more planning, but maybe
that would work for some organizations.

Option C.

> 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 C. There are circumstances under which the upstream may be
responsible for the reassigned networks.

/david