[arin-ppml] ARIN-prop-172 Additional definition for NRPM Section 2 - Legacy Resources

[Kevin Kargel]

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> Sent: Monday, June 18, 2012 8:33 PM
> To: Jimmy Hess
> Cc: John Curran; arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN-prop-172 Additional definition for NRPM
> Section 2 - Legacy Resources
> 
> 
> On Jun 18, 2012, at 6:08 PM, Jimmy Hess wrote:
> 
> > On 6/18/12, John Curran <jcurran at arin.net> wrote:
> >> ARIN is the Internet number registry for the region and ARIN
> >> policies apply to all number resources in the ARIN registry.
> >
> > I would suggest something like, er:
> >
> > 4.6.7    All ARIN listed resources are subject to Number resource
> policies
> >    Number policies apply equally to all resources in the ARIN
> > registry, including legacy
> >    allocations made by previous registries which are placed under
> > administration of ARIN.
> >
> >    ARIN requires a signed RSA for all resources listed in the ARIN
> > number registry,
> >    and also as a requirement for the privilege of transferring,
> > reassigning, or reallocating any number resource..
> >
> >    ARIN will list legacy allocations and resources not compliant with
> > the signed RSA requirement in the ARIN WHOIS directory,
> >    only on a best-effort basis, and may label such entries as
> > Non-Compliant  or Non-Validated Resource.
> >
> >    ARIN will accept contact information update requests for
> > non-compliant resources that ARIN is able to verify,
> >    and maintain WHOIS listings for non-compliant resources until such
> > time as the registration is
> >    removed, revoked, or brought into compliance, or ARIN is shown
> > proof that listed WHOIS information
> >    is inaccurate,  invalid, not a responsive contact, not the right
> > contact,  or a new attempt
> >    by the non-compliant resource holder to transfer, repurpose, or
> > delegate any portion of the resource has been attempted, without
> > contacting ARIN to request approval.
> >
> >
> >    ARIN may remove assignments of non-compliant number resources upon
> > finding evidence that the resource is abandoned or unused
> >    for a period of 3 months or longer, if there is no signed RSA, and
> > after reasonable efforts
> >    to contact a resource holder have been attempted and failed,  or
> > if contact is made, and a
> >    resource holder fails to sign the RSA within 30 days.
> 
> As much as I like this, I think that it goes a little too far and creates
> an unnecessary legal burden for ARIN.
> 
> If you deleted everything after the last or in the lst sentence, I would
> support as written.
> 
> I recommend submitting to policy as a proposal template. Let me know if
> you'd like assistance filling out the template.
> 
> Owen
> 
> _______________________________________________

[kjk] I have to agree with Owen, this is the first and closest suggestion
for legacy resource management that I could support.

It does ping on one of my policy pet peeves though.  "May" operations in the
absence of an under-riding "May Not" are really a no-op.  If there is
nothing in policy preventing ARIN from doing something then there is no need
to write specific policy allowing ARIN to do it.  
"May" is functional only if it modifies a stricter control, such as a "Will"
or "Will not" or "Must" or even "May not".
I understand the desire to do future-proofing, but it makes for more tangled
policy.  
This *may* be due to too much Boolean thinking on my part.  lol

I like your idea, and I also like the idea suggested by Mr. Buhrmaster of
requiring agreement escalation on transfers, i.e. no-contract resource
transfer would require LRSA at minimum, and LRSA transfer would require RSA.
This makes sense to me.  

I look forward to seeing these as policy proposals.  

Kevin


  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4935 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20120619/40b621c0/attachment.bin>