On 23 Jun 2010, at 08:45 , Eliot Lear wrote:
And now as to your specifics, you have placed a lot of weight on one
example, seemingly extrapolating from it, the Joint Interoperability
Test Command. I have no experience working with them, and defer to
yours. However, when you say,
Again, you setup an incorrect strawman, and then knock it down.
In the quote (below), I also mentioned the "various IPv6
Profile documents around the world", which you ignore,
apparently in order to incorrectly characterise my note
as using a single example. There are a number of cases
where a large customer's requirements (in RFPs or Tender
opportunities) have driven feature priorities. The TIC
and JITC are merely examples. Numerous other examples
exist, including a large bank in central Europe and
several ISPs.
As examples, the JITC and TIC requirements pay a great
deal of attention to whether some technology is past PS.
Various IPv6 Profile documents around the world also pay
much attention to whether a particular specification is
past PS.
It leads to the following questions:
* Would the vendors have implemented the functionality ANYWAY?
Specifically, would other RFPs have already driven vendors in this
direction? Can you cite a counter example, where that was not the
case?
Yes.
There are certainly numerous cases where vendor implementation
timing and new feature prioritisation were directly impacted
by a profile document cited in some RFP, and where that profile
document's contents were directly impacted by whether a
particular technology was at Proposed Standard or some more
advanced stage in the IETF processes.
The most obvious examples come from the various IPv6 Profiles
around the world. There are some number of these in Japan,
in Europe, in the USA, and in other countries.
Various examples also exist outside the IPv6 Profile universe,
including but not limited to large customers (e.g. the JITC and TIC).
* Is the defense industry at all representative of the broader
market? My own experience leads to an answer of, “barely at all”,
and this has been assuredly the case with the Internet where a
huge portion has run on on PS, Internet-Drafts, and proprietary
standards, and not waited for advancement. Examples have included
BGP, MPLS-VPNs, HTTP, SSL, and Netflow, just to name a few.
I provided non-defense examples in both my original note
(which examples you have ignored for some reason) and also
in my response above.
The IETF already has a tendency to be very vendor-focused &
vendor-driven. It is best, however, if the IETF keeps the
interests of both communities balanced (rather than tilting
towards commercial vendors).
While this is a perhaps laudable idea, someone has to do the work to get
specifications to the next standards level. The whole point of my
questions is to determine what motivations that someone might have for
actually performing that work.
I was quite detailed on that front, although you seem to have
selectively ignored that part of my note.
There's no need to be rude or snarky with me, even if you disagree.
I wasn't rude, and can't find "snarky" in the OED.
You are looking at this from the angle of the customers, and that's
perfectly reasonable. I'm looking at it from the developers' point of
view, and from the supply side of your equation.
I've been both customer/user/operator and vendor/implementer
at various points in time. So I look at it from both points
of view, and my earlier note included discussion of both
vendor advantages and user/operator/customer advantages.
It seems quite odd that you seem to have ignored my note
so selectively.
B) whether that signal has a feedback loop to implementers/
vendors that still works.
The answer to this is also clearly YES. Technologies that
appear in RFPs or Tender Requirements have a stronger
business case for vendors/implementers, hence are more
likely to be widely implemented.
Certainly so, but I don't understand how you made the leap of logic from
your question to your answer. Do we have situations, for instance,
where a proposed standard is compared to a draft standard, or a draft
standard is compared to a full standard, and one is chosen over the
other?
Yes, we do.
If so, are they the norm, and are they likely to drive
implementation?
Such decisions in various IPv6 Profiles around the world,
in large customer requirements documents around the world
(e.g. JITC, TIC) regularly have driven implementation priorities
and new feature timetables in the past.
Folks at many vendors have experienced this. I witnessed
it at every vendor I've ever worked for. It isn't a surprise
that a business case would drive these things NOR is it
a surprise that standards status would drive an RFP
(and hence drive the business case).
Also, if all this gets you is interoperability, but
doesn't actually solve your problem, is THAT a good thing for the
customer? IMHO this was precisely the case for SNMPv3.
We disagree about SNMPv3 as an example.
By its very definition, "interoperability" is always solving
a problem. In my experience, having been both implementer
and consumer/operator/user, it solves a problem both for
implementers/vendors and also for users/operators/customers.
Is there any reason for a developer to believe that the day after
a "mature" standard is announced, a new Internet Draft won't
in some way obsolete that work?
By definition, Internet-Drafts cannot obsolete any
standards-track document while they remain Internet-Drafts
I think you misunderstand what I mean by "obsolete". I don't mean
"obsolete" in the sense that you see it in the RFC directory, but
whether a new idea will overtake what has just been standardized.
As time goes to infinity, the entire Internet is likely to be
replaced. So that's the wrong question (again).
The right question is about speed that a new technology will
supercede an older one. The IETF has extensive experience
that it takes a substantial time for nearly anything to move
to even Proposed Standard.
While we believe that the time required between innovation and
a suitable Proposed Standard will diminish with the new 2-track
scheme [A], the long-standing requirements for openness and
due process in the IETF standards process combine with more
recent practices (e.g. Area reviews) to ensure that a technology
won't be replaced instantly.
I'll grant you it's almost impossible to calculate,
but perhaps history can be of some use. That analysis should be done.
To be frank, those sentences appear to just be trying to stall
and divert discussion.
Question #3: What does such a signal say to the IETF?
It is a positive feedback loop, indicating that work is
stable and interoperable. It also says that gratuitous
changes are very unlikely to happen. By contrast,
technologies at Proposed Standard very frequently have
substantial changes, often re-cycling back to PS with
those major changes.
Where do we see cases where gratuitous changes take place at Proposed?
Those happen pretty frequently. You yourself have complained
about several changes, from time to time, in the past.
Further, the new approach will have the effect of making
it easier to publish technologies at Proposed Standard,
which would be good all around.
Why do you come to this conclusion, given that PS isn't changing?
[A]
The public statement by the IETF Chair to the ietf discussion list,
here (1st paragraph from Russ):
<http://www.ietf.org/mail-archive/web/ietf/current/msg62019.html>
and also text within draft-housley-two-maturity-levels.
Question #4: Is there a market advantage gained by an implementer
working to advance a specification's maturity?
Again, wrong question.
Why? Keeping in mind we're looking at reasons
for people to do the work.
Its the wrong question because it ignores the presence
of users/customers/operators.
That noted, the answer is clearly Yes. Early implementers who show
interoperability are well positioned to win RFPs that require a
technology that has moved beyond Proposed Standard, while trailing
implementers often end up unqualified to bid/tender due to the
absence of such a feature.
Again, there seems to be a leap of logic here that somehow because a
specification has attained draft or full standard will cause work to be
done that wasn't done before. Those are facts not in evidence.
Actually they are quite evident to folks within the product
development/feature prioritisation functions at most equipment
vendors. I've outlined them before, but I'll try repeating
a currently common sequence of events here:
- Technology shows interoperability and moves beyond
Proposed Standard RFC.
- RFC beyond Proposed Standard increases user/customer/operator
confidence that a technology is interoperable,
stable, and does not lock them into a single vendor.
- Operator/user/customer becomes MUCH more likely
to include that technology as a "MUST implement"
in their RFPs or Tender opportunities.
- RFP requirements increase the business case
for vendors to implement that particular feature
- Business case pressures drive feature prioritisation
and implementation resourcing at vendors
- Result is that technologies specified in RFCs
beyond Proposed Standard have more value to both
vendors and users/operators/customers, and so are
both more likely to be implemented and also more
likely to be widely deployed.
Might ossification of a standard retard innovation
by discouraging extensions or changes?
This is wildly less likely under 2-track than it already
is today, partly because it will be much easier for a
sensible revision to move to Proposed Standard.
I don't understand what you're saying.
Are you arguing that recycling back down to proposed will be easier?
It relates to the reference [A] above.
The current challenges of publishing any innovation as
a Proposed Standard RFC should diminish with Russ's proposal.
Yours,
Ran
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf