I would like to support Nurit's comments below. In particular, in the past the ITU-T has expanded upon or changed the usage of IETF codepoint allocations, in some cases incompatibly with its original usage or definition. In the future, all codepoint allocations to the ITU-T should be tied to one specific, dated revision of their specification only. This is similar to the ITU-T's own processes, such as section 2.2.1 of Rec. A.5, which requires a version number and/or date for referenced outside documents in ITU-T recommendations. Cheers, Andy On Thu, Mar 1, 2012 at 7:20 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) <nurit.sprecher@xxxxxxx> wrote: > Hi, > > > > I cannot support the publication of the document in its current version. > > > > I have the following concerns: > > > > • It is indicated that the channel is intended to be used to carry > Ethernet based OAM messages. It is not clear why there is a need for ACH. > PWs can be used to transmit Ethernet OAM. > > If the intention is to use the channel for OAM messages for operating > MPLS-TP based networks, the IETF *already* defined a solution for MPLS-TP > OAM and I expect to see first a technical *justification* why a second > solution is needed. In addition, I would expect to see *references to the > arguments* raised in draft-sprecher-mpls-tp-oam-considerations. > > > > • It is not clear what the maturity status of G.8113.1 is. It seems > that the document was not approved by SG15 and the discussion was deferred > to WTSA. This indicates that there is *no consensus* for the approval of > G.8113.1. A code point should not be allocated before a consensus/decision > is reached in the ITU-T and before the document is mature and approved. I do > not think it is appropriate to allocate a code point and try to force a > resolution in the ITU-T. > > > > • I find a contradiction in the draft. In one place it is mentioned: > "These Ethernet based OAM messages and procedures, address the OAM > functional requirements defined in [RFC5860]. Other message types should not > be carried behind this code point." In another place it is mentioned: "all > ITU-T Recommendations are subject to revision. Therefore, the code point > allocated by this document may be used for future versions of [G.8113.1].". > The last statement opens the door for the definition of additional messages > in G.8113.1 in the following versions, for example, for APS (supporting > linear or ring protection mechanisms) and by this creates two solutions for > other mechanisms as well. > > > > The use of the code point can go much beyond its original purpose and it > will hide other messages....a code point should not be allocated at this > point at all, but specifically not for unknown usage that may be defined in > future versions of G.8113.1. > > > > Best regards, > > Nurit > > > > > > > >> -----Original Message----- > >> From: ietf-announce-bounces@xxxxxxxx [mailto:ietf-announce- > >> bounces@xxxxxxxx] On Behalf Of The IESG > >> Sent: 22 February 2012 15:13 > >> To: IETF-Announce > >> Subject: 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 > >> > >> > >> The IESG has received a request from an individual submitter to > > consider > >> the following document: > >> - 'Allocation of an Associated Channel Code Point for Use by ITU-T > >> Ethernet based OAM' > >> <draft-betts-itu-oam-ach-code-point-03.txt> as an Informational RFC > >> > >> The IESG plans to make a decision in the next few weeks, and solicits > >> final comments on this action. Please send substantive comments to the > >> ietf@xxxxxxxx mailing lists by 2012-03-21. Exceptionally, comments may > > be > >> sent to iesg@xxxxxxxx instead. In either case, please retain the > >> beginning of the Subject line to allow automated sorting. > >> > >> Abstract > >> > >> This document assigns an Associated Channel Type code point for > >> carrying Ethernet based Operations, Administration, and Management > >> messages in the MPLS Generic Associated Channel (G-ACh). > >> > >> The file can be obtained via > >> http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ > >> > >> IESG discussion can be tracked via > >> http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ > >> > >> > >> No IPR declarations have been submitted directly on this I-D. > >> _______________________________________________ > >> IETF-Announce mailing list > >> IETF-Announce@xxxxxxxx > >> https://www.ietf.org/mailman/listinfo/ietf-announce > > > > _______________________________________________ > > mpls mailing list > > mpls@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > Ietf mailing list > > Ietf@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > > Ietf mailing list > > Ietf@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf