Keyboard Shortcuts
Thread View
j
: Next unread messagek
: Previous unread messagej a
: Jump to all threadsj l
: Jump to MailingList overview

Hi Terence,
On 24/03/2009 6:03, "Terence Zhang Yinghao" zhangyinghao@cnnic.cn wrote:
I've been trying to think through examples of unofficial markets for things that are not allowed. Most of them seem to have higher prices than you would see in a regulated, official market. Can you explain why you think people would be willing to charge a lower price for something that was not allowed, rather than charging a premium?
I have similar question in mind, why people will pay a premium for addresses while they can get it from RIR through allocation process?
One example that springs to mind is single-homed organisations that want a small portable assignment. They don't appear to qualify under the current IPv4 policy but might well decide that buying an assignment assures them of IPv4 space in the years to come and removes the ongoing cost of renumbering every time they change ISP.
You seem to have ignored the NIR's and the RIR's role in this. Do you not have confidence in NIR's and RIR's abilities to correctly evaluate requests that have been inflated?
I respect your experience in IP resources allocation and management, and I also believe our hostmasters are perfectly capable.
I'm glad to hear that both the NIR's and RIR's staff will not have problems correctly evaluating inflated IPv4 requests. It is good to know that on reflection this risk is not a real concern.
Kind regards,
Leo Vegoda

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.

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
Activity Summary
- 5279 days inactive
- 5279 days old
- sig-policy@lists.apnic.net
- 3 participants
- 2 comments