Re: הנדון: RE: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt>(All

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
<alessandro(_dot_)dalessandro(_at_)telecomitalia(_dot_)it> 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:daedulus(_at_)btconnect(_dot_)com]
> Inviato: mercoledì 14 marzo 2012 11:56
> A: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Ross Callon
> Cc: ietf(_at_)ietf(_dot_)org
> 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)" 
> <nurit(_dot_)sprecher(_at_)nsn(_dot_)com>
> To: "Andrew G. Malis" <agmalis(_at_)gmail(_dot_)com>; "ext Ross Callon"
> <rcallon(_at_)juniper(_dot_)net>
> Cc: <ietf(_at_)ietf(_dot_)org>
> 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)
> עותק: ietf(_at_)ietf(_dot_)org
> נושא: 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: ietf-bounces(_at_)ietf(_dot_)org 
> [mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Andrew G. Malis
> Sent: Monday, March 05, 2012 6:54 PM
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Cc: ietf(_at_)ietf(_dot_)org
> 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(_dot_)sprecher(_at_)nsn(_dot_)com> 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(_at_)ietf(_dot_)org [mailto:ietf-announce-
> > > bounces(_at_)ietf(_dot_)org] 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(_at_)ietf(_dot_)org mailing lists by 2012-03-21. Exceptionally, 
> > > comments
> > > may
> > be
> >
> > > sent to iesg(_at_)ietf(_dot_)org 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(_at_)ietf(_dot_)org
> > > https://www.ietf.org/mailman/listinfo/ietf-announce
> >
> >
> > _______________________________________________
> >
> > mpls mailing list
> >
> > mpls(_at_)ietf(_dot_)org
> >
> > https://www.ietf.org/mailman/listinfo/mpls
> >
> > _______________________________________________
> >
> > Ietf mailing list
> >
> > Ietf(_at_)ietf(_dot_)org
> >
> > https://www.ietf.org/mailman/listinfo/ietf
> >
> > _______________________________________________
> >
> > Ietf mailing list
> >
> > Ietf(_at_)ietf(_dot_)org
> >
> > https://www.ietf.org/mailman/listinfo/ietf
> >
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf(_at_)ietf(_dot_)org
> > https://www.ietf.org/mailman/listinfo/ietf
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf
>
>
>
> --------------------------------------------------------------------------------
>
>
> > _______________________________________________
> > Ietf mailing list
> > Ietf(_at_)ietf(_dot_)org
> > 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.