On Sun, 2009-11-08 at 00:31 +0100, Hutton, Andrew wrote: > Hi, > > I like the proposed new charter I think it makes it very clear what > the rules are for work items in BLISS. > > One question I have is should we need evidence of real running code > and interoperability before releasing BLISS drafts as RFC's. > > I don't think it would be good if the BLISS group was to analyse > existing implementations and then define a new but hopefully more > interoperable mechanism but then find that nobody implements it. > > Could we have something in the charter that requires real evidence of > interoperability before a draft can be released as an RFC or would > this be going to far ?
Well, BCP 9 (RFC 2026) already has descriptions of the place of running code in the standards track maturity levels. In the description of Proposed Standard: Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. and the next level leads with it: A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. There have been a lot of specifications published as RFCs out of the SIP related working groups without any running code - there are a number that have been RFCs for years that still don't have any running code that I know of, and many more that lack significant deployment. Far be it from me to argue that that is a good thing, but I don't think that the place to change the rules is in the charter of just one working group. Given that interoperability of features is the mission of BLISS, the ability to demonstrate it in real code is especially relevant, but I think it's also worth recognizing that in many (perhaps even most) cases BLISS features will face a difficult hurdle: the features in question are often essential, so most commercial implementations will already have pre-standard (and presumably not interoperable) implementations of the feature. Unless the new standard version has compelling advantages (and being "standard" probably won't be compelling), it may take some time to convince product managers that it is worth spending precious development resources to re-implement a feature they already have. While I argue that requiring running code shouldn't be a criterion in the charter, I do think that it should be a central part of the working group process. I've already had discussions with Robert about setting up testing/demonstration sessions at SIPit for BLISS-developed features. _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
