[ppml] Policy Proposal 2003-1: Human Point of Contact

[Mury]

Whoa,

What the heck are you talking about?  In no way, shape, or form did I
state that ARIN made this proposal, or did anything wrong.

I merely made an example everyone on this list is familiar with.  We are
talking about things to do with ARIN right?

I used the "fact" that ARIN is better served by a "role" account senario
to make a point that we are too.  Where is the harm in that?

BTW, are you also telling me that ARIN staff, AC, and BOD cannot submit
policy proposals?  Not that I think I suggested in any manner that they
have, but it would surprise me if they were not allowed to.

Mury


On Wed, 5 Mar 2003, Sweeting, John wrote:

> Just want to point out that these policy proposals are submitted to ARIN
> from the public that they serve; they are not proposed by ARIN or their
> staff so please refrain from comments that suggest otherwise. Thank you.
>
> > -----Original Message-----
> > From: Mury [mailto:mury at goldengate.net]
> > Sent: Wednesday, March 05, 2003 12:09 PM
> > To: McBurnett, Jim
> > Cc: Richard A Steenbergen; ppml at arin.net
> > Subject: RE: [ppml] Policy Proposal 2003-1: Human Point of Contact
> >
> >
> >
> > Just for the record when voting on this one, I echo these
> > sentiments.  I
> > sure can't put my name on everything and I don't see anyone
> > in my company
> > being willing or able to fullfill this request.
> >
> > As someone mentioned earlier, role accounts exist for a
> > reason.  We do an
> > excellent job of responding to any coorespondence this way.
> > To put this
> > task on a single person, even for a company our size, is
> > asking us to no
> > longer respond to people.
> >
> > Isn't it much like asking an ARIN employee to give out their email and
> > phone to handle all new requests for IPs?
> >
> > I would venture to guess that ARIN thinks they are doing a
> > much better job
> > with their automated process than routing everything through a single
> > employee.  Why would it be any different for us?
> >
> > If things really break down and you can't get a role account
> > to respond,
> > then there are conventional methods available to you.
> >
> > Mury
> >
> > On Tue, 4 Mar 2003, McBurnett, Jim wrote:
> >
> > > > That sounds like a volunteer to me... You're available 24/7 right?
> > > >
> > > > Let's get real here, that policy isn't just bad it's absurd.
> > > > Role accounts
> > >
> > > I remember a job I once had where when someone called and asked for
> > > Roger Williams, someone became Roger. HMMM-
> > > Should role accounts become no longer valid, I believe that
> > many will
> > > find their own Roger. Sad to say, but I do not want my name
> > plastered any
> > > more around the web than it already is.
> > >
> > >
> > > > exist for a reason, and 99% of the time it is to improve
> > > > communications.
> > > > I'd suggest that trying to solve the 1% of the cases
> > where people are
> > > > hiding behind roles by breaking the other 99% is not the
> > way to go.
> > > >
> > > > I'd also suggest that it is a fallacy to project what you consider
> > > > "reasonable" in your business onto others. For example,
> > who is the 1
> > > > person that you would recommend to handle all of UUNet's issues?
> > >
> > > Ah 1 person.. Sounds like Roger is in the bldg again...
> > > I think we can say Roger is a Role account, but only in fact not in
> > > Policy.
> > >
> > > This policy will never work.  If the one is a tech and
> > he/she will never
> > > be able to finish the task, if the one is in management and
> > he/she will just
> > > delegate, and hence the one is no longer a one....
> > >
> > > Either way, what happens when the one goes on vacation,
> > gets sick etc,
> > > change the address for 1 day?
> > >
> > > anyway I think this policy is a little bit too strict.
> > > and I can't foresee it working... nor it being enforceable..
> > > Is ARIN going to ask for a drivers license # for every
> > > new contact?
> > > I think this policy needs to meet another old friend, Davy Jones..
> > >
> > > Jim
> > >
> > > >
> > > > --
> > > > Richard A Steenbergen <ras at e-gerbil.net>
> > > > http://www.e-gerbil.net/ras
> > > > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41
> > > > 5ECA F8B1 2CBC)
> > > >
> > >
> >
>