fwd ppml: ARIN asking about SWIP procedures

Thu Jan 4 17:27:18 UTC 2001

I thought folks in this forum might be interested in possibly
replying to the matter in this note from ppml, and got the author's
permission to forward it to this list. I'm trying to set the
Mail-Followup-To header on this note to the ppml at arin.net list, not
sure if I'm getting it right, but I think it would be appropriate if
any replies were directed to the ppml list, as that's what ARIN is
watching for this solicitation of public comment.

----- Forwarded message from ginny listman <ginny at arin.net> -----

From: ginny listman <ginny at arin.net>
Subject: Just to clarify
Date: Thu, 4 Jan 2001 08:20:07 -0500 (EST)
To: ppml at arin.net

Hi, my name is Ginny Listman.  As of early December, I am the new Director
of Engineering here at ARIN.  In a meeting yesterday, to discuss database
changes, the following policy issue came up.

Apparently, there have been some upstream ISPs that have assigned some
networks via SWIP, where later the downstream comes back saying it should
have been an allocation, ie they want a maintainer id so they can
assign/allocate further on down.

In most cases, RSG has been granting the downstream's wish, creating the
maintainer id, allowing them to further assign/allocate.

Many times, it is just a minor error in the SWIP template, and shouldn't
be a big deal.  However, would there ever be a situation where the
upstream would not want the downstream to be assigning/allocating?  Should
ARIN be responsible for notifying the upstream?  We have be processing
these request because we do not want to delay the downstream's business.
Do we need a written policy to define how we should be processing such a
request?

----- End forwarded message -----

I believe this matter is on-topic for nanog; if I'm mistaken my
apologies, and please do let me know. Note that this forwarding to
nanog is my fault and not the fault of the original author.

-Bennett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20010104/3bb397bf/attachment.sig>