Ross, i am afraid that you missed the point. There will not be a final version since as written in draft-betts, all ITU recommendations are subject to revisions, and the code point will also be used for future revisions of the document. New messages/protocols can be defined in future revisions of the recommendation and they will use the same code point that is allocated for the first version. This is a real issue. Regards, Nurit -----הודעה מקורית----- מאת: ext Ross Callon נשלח: 13/03/2012, 19:27 אל: Andrew G. Malis; Sprecher, Nurit (NSN - IL/Hod HaSharon) עותק: ietf@xxxxxxxx נושא: RE: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC I agree that the allocation of a code point should be to a specific version of 8113.1, and specifically should be to the final version that is approved by the ITU-T (assuming that a final version of 8113.1 will be approved by the ITU-T). This would imply that draft-betts-itu-oam-ach-code-point should contain a normative reference to the final approved version of 8113.1. Given normal IETF processes, this implies that the final RFC resulting from draft-betts-itu-oam-ach-code-point could be published as soon as the final version of 8113.1 is approved (with the understanding that there will be a small normal delay between "approved" and "published" which gives time for coordination). Given that the final version of 8113.1 might need to reference the RFC resulting from draft-betts-itu-oam-ach-code-point, a bit of cooperation might be needed between editorial staff at the ITU and RFC editorial staff, but I don't see why this should be a problem (I am sure that they all have access to email). Ross -----Original Message----- From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Andrew G. Malis Sent: Monday, March 05, 2012 6:54 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc: ietf@xxxxxxxx Subject: Re: Last Call: <draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC 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
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf