> >> "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 mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
