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

[Leo Bicknell]

In a message written on Fri, Apr 15, 2005 at 03:11:59PM -0400, Howard, W. Lee wrote:
> 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.  

I want to be clear about this, because this is an area of controversey
in the policy as proposed.

SWIP requires do not change.  You must submit SWIPs under the new
policy for the same items that you submit SWIPs now.  However, a
SWIP can be marked "publish" or "don't publish".  That is, you have
a choice to not have the SWIP show up in whois/bulkwhois/the web
query.  In that case verification does not apply to the record, and
the parent record would be the only thing that appears for a general
lookup.

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

Suspended is simply a flag.  "You passed this point."  I'm not sure
what more there is to define.  The policy states which steps need
to be taken to reach a suspended state, which is simply a flag in
the database, and the ability for the ARIN staff to proceed to the
next step.

Similarly "reclaim" to me is exactly what it says it is.  It's a
return to the pre-allocation state.  I would assume that includes
removing whois, in-addr.arpa mappings, and putting it back in the
available pool to be reallocated in the future.

But again, the individual steps are procedural, not policy.  The
ARIN staff would have to publish the procedure before any of these
steps could be done, so the exact enumeration would be available
prior to any enforcement.

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

You know, it wasn't my intention to have a closed list.  I realize
now that is not clear, as you are the first person to bring that
to my attention.  Rather, it was to have a list of methods that
would be required to be supported, but to allow staff to work out
other arrangements as appropriate.  Somehow I forgot to add that
before the proposal went in.  It's probably too late to add that
for this go round, but the policy as written is no worse in that respect
than the one we have today.


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

Ha.  I think that's a formatting change we can make at this point
(or rather, the AC could make if the policy passes) and does make
some sense.

> We should not throw out old section 3.4, RE: Routing Registry.

We don't.  If you look at the bottom it gets renumbered to 3.7, and
inserted verbatem.

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

When this was crafted, "industry standard" was seen as good enough.
My how times change quick. :)

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050415/3e36e12d/attachment.sig>