I don't want to repeat myself unduly, but I believe that
the IETF is institutionally incapable of taking this type
of approach, for exactly the same reasons that's it's quite
good at doing protocol design. I think that the organisations
that do emphasise business cases and deployment have a record
of being (a) narrowly focussed on a single technology and
(b) not doing particularly good protocol design. (Pick your
own example...) It isn't simply a matter of skill sets - it's
something much deeper in the nature of the organisation.
That being said, I think it would be excellent for one of
our criteria for chartering new work to be deployability,
including economic deployability. That isn't explicit in
section 2.1. of RFC 2418, unfortunately.
Given the way things work in the IETF, I think a document
discussing what design features make a protocol economically
deployable would be very valuable. There are some hints
of this in RFC 3439, but not much.
Brian
On 2007-12-28 03:13, Spencer Dawkins wrote:
Re: Deployment CasesPhil,
I think I kinda do see what Brian's point is. I don't think it should be a
conversation-ender, but Brian is pointing out an issue that we need to work
through...
As an organization of individuals developing protocol specifications - that's
who we are, and that's what we do - we don't even have a natural way to
interact with operators, except to invite them to participate as individuals.
That has not worked particularly well for a long time.
(as an aside: We need one, and from time to time we have made intentional
efforts to interact with operators on a specific topic (most recently, Dave
Meyer and friends doing the NOG tour to talk about, and listen to concerns
about, SHIM6 and IPv6 multihoming), but the point is that interaction with
operators doesn't happen as business-as-usual.)
I think Brian is saying the same thing about economic/financial analysis - I agree with
your statement ("we need to go find someone who does" have expertise in this
area), but the devil is in at least a couple of details:
o who do we talk to, and
o what does that conversation look like?
You suggested two sources of input, university economics departments and F500
economics departments. It's worth noting that who we ask will shape what we
hear back - visualize this type of discussion for peer-to-peer SIP. Do we ask
Columbia.edu? ISPs? PTTs? Vonage? Skype? military? public safety? None of these
are a priori WRONG...
But I don't see us getting one answer back, reading it, and accepting it without asking
questions. What's the forum for "rough consensus" about deployment incentives?
Who actually asks for input? When? Do we hope the people we ask will attend
IETF meetings so we can discuss with them? attend IESG telechats specifically
about new work? or something else?
Who analyses what we hear back? This would almost certainly involve changes to
the IETF leadership and/or structure, because the position descriptions for IAB
and IESG don't say anything about expertise in this area. Again, this isn't
beyond imagination, we just can't ignore it.
While I would not suggest adoption of IEEE processes without thought, it's worth being aware that IEEE 802
uses "five criteria" in evaluating new work (sample for IEEE 802.21 at
http://www.ieee802.org/21/802_21_5Criteria.doc), and some of the criteria, "Broad market potential"
and "economic feasibility", seem to touch on what we're talking aout here.
Is this, broadly speaking, what you are thinking about, for IETF?
Thanks,
Spencer
I don't see the point you are trying to make here.
If we need some expertise and don't feel we have it in the ietf we go find
someone who does. We have the ability to tap into any of the top universities
economics departments and this stuff is surely understood somewhere in the
fortune 500 companies here.
We are in the business of communication, of collaboration. If we can't do
either shame on us.
What is worse, to think we are expert economists or that because we are not
economists the whole field must be irrelevant? I don't think we need to go too
deep here, just thinking in terms of deployment as the challenge is a start.
As for defining marketting as bending of facts. There are two processes that
can be thought of as marketting. Shifting product is really a form of sales. I
am talking about the processes you go through to determine whether your product
meets a genuine market need. Fudging such a study is self deception and only
leads to tears.
I always thought that the point of engineering was that you define yourself
by the ends you are seeking to achieve, not a particular skill set. If you need
a skill you seek to acquire it.
------------------------------------------------------------------------
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf