Subject: FW: 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

From: Rui Costa <[email-masked]>
Date: Thu, 22 Mar 2012 14:42:34 +0000

I fail to understand the issue under discussion.	

Can't imagine IEEE denying to grant Ethertype 0x86DD. If, however, from absurd that had happened, would the world stop or would we take the same information from the IP header version field?	

Regards,	
Rui	

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: quarta-feira, 21 de Março de 2012 15:30
To: D'Alessandro Alessandro Gerardo
Cc: [email-masked]
Subject: 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

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: quarta-feira, 21 de Março de 2012 07:42
To: [email-masked]; [email-masked]
Subject: RE: Last Call: <draft-betts-itu-oam-ach-code-point-03.txt> (Allocationof an Associated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC

Hello,
I still expect the author of draft-betts to answer my question...
	"Maybe you could clarify how the text in your draft can be improved to protect the use of the code point from future extensions beyond the purpose of the code point allocation?"
I am a bit disappointed to see that the author simply does not respond to the questions and proposed modifications he got on the list. 
If we want to productively move forward, it would be good to have the author responding to the questions and proposals. 
Best regards,
Nurit

----- Original Message -----
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "Andrew G. Malis" <[email-masked]>; "ext Ross Callon"
<[email-masked]>
Cc: <[email-masked]>
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-masked]
נושא: 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-masked] [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Monday, March 05, 2012 6:54 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]
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-masked]> 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-masked] [mailto:ietf-announce-
>
>> [email-masked]] 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-masked] mailing lists by 2012-03-21. Exceptionally, comments
>> may
>
> be
>
>> sent to [email-masked] 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-masked]
>
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>
>
>
> _______________________________________________
>
> mpls mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/mpls
>
> _______________________________________________
>
> Ietf mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/ietf
>
> _______________________________________________
>
> Ietf mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/ietf
>
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

--------------------------------------------------------------------------------

> _______________________________________________
> Ietf mailing list
> [email-masked]
> 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.

---

From: Alia Atlas <[email-masked]>
Date: Thu, 22 Mar 2012 17:07:33 -0400

Rui,

Perhaps more familiarity with the related history over the last
several years would help?  I can recommend the MPLS list archives.
Otherwise, I find this remarkably disingenuous.

This is a case of a second solution that was clearly rejected by the
MPLS working group (despite in-person histrionics causing the ADs to
have to threaten to close down the WG meeting).  Then the solution was
taken to the ITU study group - where it could also not get enough
traction for their normal process.  It is still not approved as a
recommendation.

To imply that the IETF should simply trust the allocated ACH code
point to not be abused both seems optimistic and sets a dreadful
precedent.

Making an allocation available for an approved recommendation version
is a tolerable way of reducing the deliberate use of an experimental
value.   Handing the keys over for any conceivable use, or even just
the uses in the OAM RFC that have been adequately met by IETF
WG-consensus based technology, does not seem appropriate.

Alia

---

From: "t.petch" <[email-masked]>
Date: Fri, 23 Mar 2012 10:58:04 +0100

----- Original Message -----
From: "Alia Atlas" <[email-masked]>
To: "Rui Costa" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 22, 2012 10:07 PM

Rui,

<tp>
Alia

Were the roles reversed and the second solution be a product of the IETF that
the IETF were trying to get more widely approved, would the IETF allocate a code
point?

I think that it would.  We certainly have running code, widely deployed
(although my request on the MPLS list as to which manufacturers' boxes were
involved never did get answered:-(.

We have a rough consensus; not unanimity, and not enough of a consensus to
satisfy the processes of the ITU-T but I think enough to satisfy the
consensus-judgers of the IETF (as ever, we do not vote, a majority of e-mails
for one point of view may be discounted, it is the quality of the views
expressed that matters as much or more).

So applying the standards to which we work, I think this is another reason why
we should approve this I-D.

Tom Petch

</tp>

Alia

On Thu, Mar 22, 2012 at 10:42 AM, Rui Costa <[email-masked]> wrote:
> Can't imagine IEEE denying to grant Ethertype 0x86DD. If, however, from absurd
that had happened, would the world stop or would we take the same information
from the IP header version field?
> Subject: 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

---

From: Alia Atlas <[email-masked]>
Date: Fri, 23 Mar 2012 10:11:53 -0400

Tom,

Thank you for both judging consensus (the IESG's job) and instructing
me on how it is done in the IETF (quite useful to me as a WG chair).
Thanks also for cutting my email where I agreed that allocating a
code-point for this particular use was the most tolerable option (I
know the email thread had gotten long).

> WG-consensus based technology, does not seem appropriate.

There are 2 separate points on which discussion is occurring.

1)  Should an ACH code-point be allocated?
2)  If so, should it be
    (a) restricted to a particular approved version of the recommendation or
    (b) available for whatever the ITU wants or
    (c) slightly restricted to uses to meet the relevant OAM RFC?

On the second question, the IETF doesn't do 2b - but rather ties
allocations to published RFCs.  Option 2a matches both IETF process
and avoids setting a dreadful precedent.

Alia

---

From: Rui Costa <[email-masked]>
Date: Sun, 25 Mar 2012 12:11:48 +0100

"We certainly have running code, widely deployed (although my request on the MPLS list as to which manufacturers' boxes were involved never did get answered:-("	
Hope these help:	
http://tools.ietf.org/html/draft-fang-mpls-tp-oam-considerations	
http://www.eantc.com/fileadmin/eantc/downloads/events/2007-2010/CEWC09/EANTC-CEWC2009-WhitePaper-v1_2.pdf	

Regards,	
Rui

-----Original Message-----
From: t.petch [mailto:[email-masked]] 
Sent: sexta-feira, 23 de Março de 2012 09:58
To: Alia Atlas; Rui Costa
Cc: [email-masked]
Subject: Re: FW: LastCall:<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationofan Associated Channel Code Point for Use byITU-T Ethernetbased OAM) toInformational RFC

----- Original Message -----
From: "Alia Atlas" <[email-masked]>
To: "Rui Costa" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 22, 2012 10:07 PM

Rui,

Perhaps more familiarity with the related history over the last several years would help?  I can recommend the MPLS list archives.
Otherwise, I find this remarkably disingenuous.

This is a case of a second solution that was clearly rejected by the MPLS working group (despite in-person histrionics causing the ADs to have to threaten to close down the WG meeting).  Then the solution was taken to the ITU study group - where it could also not get enough traction for their normal process.  It is still not approved as a recommendation.

<tp>
Alia

Were the roles reversed and the second solution be a product of the IETF that the IETF were trying to get more widely approved, would the IETF allocate a code point?

I think that it would.  We certainly have running code, widely deployed (although my request on the MPLS list as to which manufacturers' boxes were involved never did get answered:-(.

We have a rough consensus; not unanimity, and not enough of a consensus to satisfy the processes of the ITU-T but I think enough to satisfy the consensus-judgers of the IETF (as ever, we do not vote, a majority of e-mails for one point of view may be discounted, it is the quality of the views expressed that matters as much or more).

So applying the standards to which we work, I think this is another reason why we should approve this I-D.

Tom Petch

</tp>
To imply that the IETF should simply trust the allocated ACH code point to not be abused both seems optimistic and sets a dreadful precedent.

Making an allocation available for an approved recommendation version is a tolerable way of reducing the deliberate use of an experimental
value.   Handing the keys over for any conceivable use, or even just
the uses in the OAM RFC that have been adequately met by IETF WG-consensus based technology, does not seem appropriate.

Alia

> Can't imagine IEEE denying to grant Ethertype 0x86DD. If, however, 
that had happened, would the world stop or would we take the same information from the IP header version field?
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Alia
Atlas