> >> "This memo defines an Experimental Protocol for the Internet > >> community. It does not specify an Internet standard of any kind." > > Put another way, an Experimental RFC is no more an IETF standard than a > > conference or journal publication. Someone has done something that is > > perceived to be of enough interest to the community to publish as an > > RFC, but it is manifestly *not* an IETF standard of any kind. > The IETF might view it this way. Large parts of the (standardization) world > does not. One example in my field of work is FLUTE, and the surrounding > infrastructure of frameworks and FEC codes. To the best of my recollection, > these specifications were originally issued as Experimental RFCs, for > reasons of congestion control worries. (They are also heavily encumbered, > but that was not really an issue according to my recollection.) The > Experimental status did not stop 3GPP and other SDOs to normatively > reference them, and treat them just like any other IETF RFC. OK, let's try a little thought experiment. Suppose 3GPP or some other SDO really wants to build on some work slated for publication as an experimental or informational RFC, but for whatever reason that publication was blocked. Do you seriously think this would stop them? Of course it wouldn't! They'll simply get the rights from the author(s) - who in all liklihood will be happy to grant them - and arrange to publish the specification themselves and cut the IETF out of the process entirely. If you want a specific example of where this has happened, consider P-IMAP. Publication of this as an RFC was blocked in the IETF due to the LEMONADE WG doing work in the area, but that didn't stop another SDO from taking it and publishing it as their own standard. > Note that 3GPP could NOT do that with a journal publication... Sure they could. They can either get permission to republish the journal article or, if that's not possible, they can simply write their own independent specification of the protocol or whatever. Face it: The existence of an expermental RFC to reference is at most a small convenience for other SDOs hell-bent on standardizing something the IETF is reluctant or unwilling to put on the standards track. The lack of that expermental RFC isn't going to stop them if they really want that standard. In fact I can give anecdotes where the publication of a document as experimental with an IESG warning acted as a deterrent to adoption. Before SPF came out as an experimental specification we received a fair number of requests for support. After it came out and people were able to make an informed decision, we saw both fewer requests as well as a couple of people reevaluating their earlier requests in light of the added information that was now available. > I could name more examples, > both when it comes to referencing SDOs and referenced RFC types (including > normative references to at least Historic, Obsolete, Informational). And I can name other examples where RFC publication was blocked but standardization occurred elsewhere nevertheless. We really need to get over ourselves here. We may like to think we're the gatekeepers against standardization of bad stuff, but we're not. There are simply too many SDOs churning out specifciations these days. In fact it is precisely because we've tried to set ourselves up in many cases as the final arbiters of what's "good for the net", resorting on occasion to sleazy process tricks to try and stall or prevent publication of stuff that offends the delicate olfactory apparatus of someone currently in power, that we find ourselves increasingly routed around as a blockage to what's perceived as forward progress. Ned _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf