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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf