Re: Last Call: <draft-betts-itu-oam-ach-code-point-03.txt> (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]