what John said with one caveat - ITU-T consensus to modify an IETF protocol rather than bringing requirements to the IETF should not escape the gatekeeper function Scott On Mar 1, 2012, at 6:04 PM, John C Klensin wrote: > > > --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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf