--On Thursday, March 01, 2012 18:39 +0000 Stewart Bryant <stbryant@xxxxxxxxx> wrote: >... >> FWIW, this seems entirely appropriate to me. If we do it this >> way, I think it is important to note --for the benefit of >> those more historically involved with the ITU and others-- >> that we routinely block our own documents on normative >> references to work that is still in progress and, usually, do >> not do related code point allocations until the blocking >> referenced documents are ready. Once the present I-D is >> judged to be sufficiently ready, this approach would >> therefore be IETF approval and a formal guarantee to the ITU >> that a code point will be allocated if an when G.8113.1 is >> approved and published, but not assignment of that code point >> until the referenced base document is finished. >> >> Completely normal procedurally. >... > To be clear John our normal requirement would be that the > technical community achieved consensus that the base document > was ready. I have never seen ITU-T consensus on the contents > of G.8113.1 at any meeting that I have observed. What in your > view is the criteria for determining that G.8113.1 has > achieved consensus? Stewart, I don't think so. Let me suggest that there are two entirely separate issues here and that talking about "technical community consensus" obscures both of them. (1) Whether, given the JWT and other agreements, the ITU has any business developing G.8113.x at all, or whether they should be simply submitting ideas to the IETF for consideration. Many of us think that, under that agreement, the G.8113 activity is inappropriate. But the ITU has obviously decided otherwise and we have no enforcement capability to prevent them from doing so (whether we should or should not is pretty much irrelevant at this point, at least IMO). Whether the "technical community" has achieved consensus is not relevant either, the only thing that matters is whether G.8113.1 is, or will be, fully approved by the ITU under ITU procedures. (2) Whether it is reasonable or appropriate for the IETF to use our responsibility for code point assignments and consequent relationship with IANA to try to keep protocols that are not consistent with our design judgment and aesthetics --no matter how grounded in experience and good engineering-- off the Internet. That is the "Internet gatekeeper" function about which, as you know, I've expressed concern in other contexts. I think the answer has got to be "we can, should, and always will exercise quality control on stable specifications and normative references but, unless we can justify being sure of our own infallibility, we cannot and should not try to prevent another body from deploying a specification on the Internet by using our control of the registration model". Telling people why we think their ideas are sub-optimal is fine, as is identifying any risks we see in appropriate and visible places, but telling another group what they can't do because the IETF doesn't like the idea isn't. And I think that distinction is entirely consistent with Russ's suggestion. best, john _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf