Considering that the need for this code point is a result of the ITU not fully complying with the IETF agreement, I cannot agree that we should simply allocate a code point for whatever the ITU wants to do in the future.
It seems the best of the options to allocate a code point (much better than squatting) - but tie it to a stable reference. If the ITU can't provide a stable reference, then perhaps an RFC is the best way. There are lots of folks with opinions on the best procedure, but I certainly don't support the idea of not restricting the usage to what is clearly defined. Alia On Wed, Mar 21, 2012 at 11:04 AM, D'Alessandro Alessandro Gerardo <[email protected]> wrote: > Dear all, > Wrt draft-betts, I believe it is appropriate to allocate a code point for the > referenced specification without any restriction about the possibility to > evolve messages/protocols when compatibility is preserved. It is not only > unnecessary but it does not help in improving the relationship between the > two SDOs. > > Best regards, > Alessandro > ------------------------------------------------------------------ > Telecom Italia > Alessandro Gerardo D'Alessandro > Transport Innovation > Via Reiss Romoli, 274 - 10148 Torino > phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07 > > > -----Messaggio originale----- > Da: t.petch [mailto:[email protected]] > Inviato: mercoledì 14 marzo 2012 11:56 > A: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Ross Callon > Cc: [email protected] > Oggetto: Re: הנדון: 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 > > ----- Original Message ----- > From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email protected]> > To: "Andrew G. Malis" <[email protected]>; "ext Ross Callon" > <[email protected]> > Cc: <[email protected]> > Sent: Tuesday, March 13, 2012 8:09 PM > 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 > > > 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) > עותק: [email protected] > נושא: 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, > > <tp> > Why? > > I can understand a new code point being required if there is a new and > backwards incompatible format for the messages, but if the messages are > extended in a forwards compatible manner, adding new TLV for example, or a > new format of IF_ID, then why should we burn a new code point? > > Would you say that we should have a dozen different port numbers for HTTP to > reflect its evolution over time? If not, why not? > > Demanding that the ITU-T come back to us for a new round of negotiation when > it is technically unnecessary seems to be placing an unnecessary barrier > between the two SDOs. > > Tom Petch > > 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: [email protected] [mailto:[email protected]] On Behalf Of > Andrew G. Malis > Sent: Monday, March 05, 2012 6:54 PM > To: Sprecher, Nurit (NSN - IL/Hod HaSharon) > Cc: [email protected] > 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) <[email protected]> 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: [email protected] [mailto:ietf-announce- >> >>> [email protected]] 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 >> >>> [email protected] mailing lists by 2012-03-21. Exceptionally, comments >>> may >> >> be >> >>> sent to [email protected] 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 >> >>> [email protected] >> >>> https://www.ietf.org/mailman/listinfo/ietf-announce >> >> >> >> _______________________________________________ >> >> mpls mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> >> Ietf mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/ietf >> >> _______________________________________________ >> >> Ietf mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/ietf >> >> >> _______________________________________________ >> Ietf mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ietf >> > _______________________________________________ > Ietf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf > > > > -------------------------------------------------------------------------------- > > >> _______________________________________________ >> Ietf mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ietf >> > > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora > abbiate ricevuto questo documento per errore siete cortesemente pregati di > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privileged > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the intended > recipient, please delete this message and any attachments and advise the > sender by return e-mail, Thanks. >
