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(_at_)cisco(_dot_)com> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf