Orbit

Andy,

Thanks for this posting. It has given me something to think about with regards to prop-050 and to other agreements/contracts I've been working on for long periods of time.

I agree that the primary cause of the delay in these sorts of things is fear. But, are we not in a new hi-tech world where there are many who are constantly looking for ways to abuse the system.

Email spammers, address hijackers and others are far too prevalent these days to just do a quick "she'll be right mate" policy for something as serious as Address Transfers. As desperation sets in when addresses start to run short, every scam we've thought of, and many we've not yet thought of will be tried and tested upon us.

Prop-071 gives a fair ability to APNIC to reject transfers - but considering how easy it is to lie to APNIC already to obtain resources I am not exactly sure that this will do much .

Prop-072 provides for far far too many problems where short-sightedness can cripple a member "I transfer a /24 today thinking I don't need it and need a /19 tomorrow because of a large unexpected growth in business". This can also be easy bypassed by creating a new member and justifying the resources. If the member can legitimately justify resources, but are blocked by Prop-072, I would see this as a basis for restraint of trade arguments.

The only thing 072 might accomplish is scaring anyone thinking about transfers to not do it based on the restrictions of 2 years... which if it works, turns the entire 050 into a pointless policy designed as a deterrent rather than a functional policy.

I will repeat, I am not against 050, I am just wanting to see it functional with appropriate safeguards.

-- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve@eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve -- NOC, NOC, who's there?

Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced.

-----Original Message----- From: sig-policy-bounces@lists.apnic.net [mailto:sig-policy- bounces@lists.apnic.net] On Behalf Of Andy Linton Sent: Thursday, 9 April 2009 1:33 PM To: sig-policy@apnic.net Subject: Re: [sig-policy] Prop 050(072) comments

I've been doing some work on an Service Level Agreement I'm involved in and came across an article called Establishing Service Level Agreements by Naomi Karten at http://www.nkarten.com/sla.html

In it was a section called Avoiding the "Just-in-Case" Syndrome which seemed relevant to our discussions here on getting the small details of this policy document sorted out. I've quoted part of here as it may help us focus on what we need to do.

I'd still like to see us proceed with what we've already got consensus on and trust the hostmasters at APNIC to "do the right thing".

Regards, andy

---

http://www.nkarten.com/sla.html#avoidjic

Avoiding the "Just-in-Case" Syndrome

In a company I visited to present a seminar on establishing service level agreements, Jeremy, a fellow in the class, told me about his intense frustration in attempting to finalize an SLA with an internal customer.

"How long have you been working on it?" I asked him, thinking he'd say three months, or perhaps six or even eight or nine months. "Oh, about two years," he responded.

Two years?

A penchant for detail-mania

The problem, Jeremy explained, is that every time they got close to declaring the agreement done, someone came up with another detail that needed attention. This back-to-the-drawing-board mindset led to more meetings, more discussions, more mumbling and grumbling, and more opportunity to find yet another detail that needed attention. Needless to say, a service level agreement still being nitpicked after two years stands a good change of never being completed.

In my experience, the driving factor in this type of situation is usually a fear on the part of one or both parties that they will be trapped forever with whatever terms and conditions end up in the agreement. Therefore, before declaring it complete, they'd better anticipate and document every conceivable situation that might ever arise. We'd better be prepared just in case, they tell themselves.

All these just-in-case details create a document that's so bogged down with minutiae that managing it becomes impossible (assuming it's actually completed and implemented). Furthermore, the presence of so much detail fosters a sense of distrust that leads each party to relentlessly watch for departures by the other from what they agreed to.

•          sig-policy:  APNIC SIG on resource management policy
  

---

sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy