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

[ma.yuxia@xxxxxxxxxx]

Hi all,

I agree with Russ and support the allocation
of an ACH codepoint to G.8113.1.

Yuxia


ietf-bounces@xxxxxxxx 写于 2012-03-02 07:52:04:

> Nurit:
> 
> Some people are using the lack of a code point as the reason that
> the cannot support the ITU-T document.  My approach tells the
ITU-T 
> that a code point is available to them IFF they are able to reach
> consensus.  The removes IETF from the discussion.  This
creates a 
> situation where G.8113.1 succeeded or fails based on the ITU-T 
> members actions, with no finger pointing at the IETF.  This is
> completely a Layer 9 consideration, and it has noting to do with the
> technical content of the document.
> 
> Russ
> 
> 
> On Mar 1, 2012, at 2:33 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon)
wrote:
> 
> > Russ, 
> > I propose to simply re-discuss it when and IFF G.8113.1 is mature
and
> > approved...
> > Best regards,
> > Nurit
> > 
> > 
> > -----Original Message-----
> > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On
Behalf Of
> > ext Russ Housley
> > Sent: Thursday, March 01, 2012 9:12 PM
> > To: IETF
> > Subject: Re: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt>
> > (Allocation of anAssociated Channel Code Point for Use by ITU-T
Ethernet
> > basedOAM) to Informational RFC
> > 
> >>>> Right now, there is no ITU-T approved document to
reference.
> >>>> I am certainly not an expert on ITU-T process, but
my
> >>>> understanding is that earliest that we could see
an approved
> >>>> G.8113.1 is December 2012.  My point is that
we don't want to
> >>>> assign a code point until the ITU-T approves their
document.
> >>>> However, if we are willing to assign a code point
to G.8113.1
> >>>> once it is approved, then this would be an approach
where the
> >>>> code point assignment would block on the approval
of the
> >>>> normative reference.
> >>>> 
> >>>> I like this approach from the political point of
view.  With
> >>>> this approach the IETF tells the ITU-T that if and
only if
> >>>> they are able to achieve consensus on G.8113.1, then
a code
> >>>> point will be assigned.
> >>> 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?
> > 
> > 
> > This is not an IETF problem, and I do not think that the IETF
ought to
> > be discussing the internal workings of the ITU-T process.  The
point is
> > to come up with a mechanism that allows the code point to be
assigned if
> > and only if the ITU-T does come to a consensus by whatever means
is
> > allowed by their own process.
> > 
> > Russ
> > _______________________________________________
> > Ietf mailing list
> > Ietf@xxxxxxxx
> > https://www.ietf.org/mailman/listinfo/ietf
> 
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
>