On Mon, Apr 18, 2011 at 6:46 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote:
> Procedural issue: > The companies interested in this work have already showed interest > in other companion specification so the argument of having to point > developers to multiple documents is completely without merit. I'm sorry that my first post to this list will be about IETF etiquette, but this claim begs rebuttal. First, in the IETF representation is not by company, as it is in many other SDOs, but by individual. Second, publishing Standards Track RFCs is by IETF Consensus, the entire IETF not just the Working Group, so such issues are clearly not without merit. There are times when separating issues into multiple documents is simply a matter of organizing the workflow of the Working Group. Other times it's a matter of attempting to push on with a majority view, without establishing rough consensus. It's the latter that is to be avoided. It's also important to realize that the documents produced are not simply for the consumption of those active in their creation. They need to be well crafted and well organized for those who simply wish to adopt and implement the protocol(s) they describe. Leaving out important aspects, that will potentially impact multi-vendor interoperability is almost always a bad choice. > I would also point out that given the extensibility model we have adopted. > the authors of the proposed text could easily register the two parameters > without the need to build the same level of WG consensus. Publishing a > separate document is the only guaranteed method of getting the two > parameters to be officially registered (no RFC is required, just a > specification > published somewhere which can be anywhere). Sorry, but IMHO this sounds a bit dismissive. > The claim that "removing is a breaking issue" is patently wrong. >From what I've read in this thread, I can't support that notion. If interoperable implementations can't be crafted without *some* resolution to this issue, it indeed seems like a "breaking issue" to me. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
