[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
  Web www.spinics.net

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

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


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 Annoucements]     [IETF Obscurity Interest]     [IETF]     [IP Storage]     [Yosemite News]     [Linux]     [Pilates]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]

Add to Google