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

From: "Kyung-Yeop Hong (hongk)" <[email-masked]>
Date: Thu, 1 Mar 2012 09:14:01 -0600

No/do not support.

One of the issues with G.8113.1 in LS370 is its stability and maturity.
That was one of the reasons why it was not approved. 

The Ethernet based OAM protocol documented in the LS370 version is
intended to be deployed for MPLS networks. I think the IETF has a duty
to ensure that a solution is stable and works for MPLS networks before
the code point allocation. A number of concerns with the deployment of
this proposed protocol raised in
draft-spercher-mpls-tp-oam-considerations are critical to the Internet
and must be taken into consideration in this Last Call. 

KY

> -----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

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 1 Mar 2012 16:14:59 +0100

Great!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Kyung-Yeop Hong (hongk)
Sent: Thursday, March 01, 2012 5:14 PM
To: [email-masked]
Subject: Re: Last Call:
<draft-betts-itu-oam-ach-code-point-03.txt>(Allocation of an Associated
Channel Code Point for Use byITU-T Ethernet based OAM) to Informational
RFC

No/do not support.

KY

(Allocation of
an
consider
be

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 1 Mar 2012 16:20:34 +0100

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

> From: [email-masked]
<mailto:[email-masked]>  [mailto:ietf-announce-

> [email-masked] <mailto:[email-masked]> ] On Behalf Of The IESG

(Allocation of

an

consider

> [email-masked] <mailto:[email-masked]>  mailing lists by 2012-03-21.
Exceptionally, comments may

be

> sent to [email-masked] <mailto:[email-masked]>  instead. In either case,
please retain the

> http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/
<http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/> 

> http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/
<http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/> 

> [email-masked] <mailto:[email-masked]> 

> https://www.ietf.org/mailman/listinfo/ietf-announce
<https://www.ietf.org/mailman/listinfo/ietf-announce> 

mpls mailing list

[email-masked] <mailto:[email-masked]> 

https://www.ietf.org/mailman/listinfo/mpls
<https://www.ietf.org/mailman/listinfo/mpls> 

Ietf mailing list

[email-masked] <mailto:[email-masked]> 

https://www.ietf.org/mailman/listinfo/ietf
<https://www.ietf.org/mailman/listinfo/ietf> 

Ietf mailing list

[email-masked] <mailto:[email-masked]> 

https://www.ietf.org/mailman/listinfo/ietf
<https://www.ietf.org/mailman/listinfo/ietf>

---

From: Russ Housley <[email-masked]>
Date: Thu, 1 Mar 2012 11:06:00 -0500

KY:

Would you support the assignment to an approved G.8113.1?  That is, if the document contained a normative reference to the approved G.8113.1, then the document that makes the code point allocations would sit in the RFC Editor queue until the ITU-T reaches consensus and approves G.8113.1.

Russ

---

From: Loa Andersson <[email-masked]>
Date: Thu, 01 Mar 2012 17:42:51 +0100

Russ,

I'm not KY, but I feel that your question is a bit loaded.

Certainly if the document is reviewed and approved by the IETF/IESG
it would be no problem to support the assignment of a ACh Type.

But I can't see that approval by some other instance actually carry
the same merit - so exactly what do u mean by "approved G.8113.1"?

/Loa

On 2012-03-01 17:06, Russ Housley wrote:
>>> Subject: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt>
>> (Allocation of
>> an

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 1 Mar 2012 18:22:42 +0100

Hi Russ,
I am not K.Y., but to me it seems at the moment as a very theoretical
question.
If the document is stable and approved, we can re-issue an IETF LC for a
better version of draft-betts that resolves my and others' comments that
I sent earlier today and the IETF can make the decision then. 
At the moment, I cannot support the publication of draft-bett, for the
reasons please see my mail that was sent earlier today to the IETF list.
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Russ Housley
Sent: Thursday, March 01, 2012 6:06 PM
To: Kyung-Yeop Hong (hongk)
Cc: [email-masked]
Subject: Re: Last Call:
<draft-betts-itu-oam-ach-code-point-03.txt>(Allocation of an Associated
Channel Code Point for Use byITU-T Ethernet based OAM) to Informational
RFC

KY:

Would you support the assignment to an approved G.8113.1?  That is, if
the document contained a normative reference to the approved G.8113.1,
then the document that makes the code point allocations would sit in the
RFC Editor queue until the ITU-T reaches consensus and approves
G.8113.1.

Russ

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 1 Mar 2012 18:25:27 +0100

Hi Russ,
If the G.8113.1 document is stable and approved, we can re-issue an IETF
LC for a

-----Original Message-----

KY:

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 1 Mar 2012 13:02:02 -0500

Loa:

Right now, there is no ITU-T approved document to reference.   I am certainly not an expert on ITU-T process, but my understanding is that earliest that we could see an approved G.8113.1 is December 2012.  My point is that we don't want to assign a code point until the ITU-T approves their document.  However, if we are willing to assign a code point to G.8113.1 once it is approved, then this would be an approach where the code point assignment would block on the approval of the normative reference.

I like this approach from the political point of view.  With this approach the IETF tells the ITU-T that if and only if they are able to achieve consensus on G.8113.1, then a code point will be assigned.

Russ

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 1 Mar 2012 19:06:59 +0100

Russ,
Independently of that point, draft-betts in its current version has many
issues....
Many clarifications are needed before it can be considered....please see
my mail for the details.
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Russ Housley
Sent: Thursday, March 01, 2012 8:02 PM
To: Loa Andersson
Cc: [email-masked]
Subject: Re: Last Call:
<draft-betts-itu-oam-ach-code-point-03.txt>(Allocation of an Associated
Channel Code Point for Use byITU-T Ethernet based OAM) to Informational
RFC

Loa:

Right now, there is no ITU-T approved document to reference.   I am
certainly not an expert on ITU-T process, but my understanding is that
earliest that we could see an approved G.8113.1 is December 2012.  My
point is that we don't want to assign a code point until the ITU-T
approves their document.  However, if we are willing to assign a code
point to G.8113.1 once it is approved, then this would be an approach
where the code point assignment would block on the approval of the
normative reference.

I like this approach from the political point of view.  With this
approach the IETF tells the ITU-T that if and only if they are able to
achieve consensus on G.8113.1, then a code point will be assigned.

Russ

On Mar 1, 2012, at 11:42 AM, Loa Andersson wrote:

>> Would you support the assignment to an approved G.8113.1?  That is,
if the document contained a normative reference to the approved
G.8113.1, then the document that makes the code point allocations would
sit in the RFC Editor queue until the ITU-T reaches consensus and
approves G.8113.1.

---

From: John C Klensin <[email-masked]>
Date: Thu, 01 Mar 2012 13:28:44 -0500

--On Thursday, March 01, 2012 13:02 -0500 Russ Housley
<[email-masked]> wrote:

> Loa:
> 
> Right now, there is no ITU-T approved document to reference.
> I am certainly not an expert on ITU-T process, but my
> understanding is that earliest that we could see an approved
> G.8113.1 is December 2012.  My point is that we don't want to
> assign a code point until the ITU-T approves their document.
> However, if we are willing to assign a code point to G.8113.1
> once it is approved, then this would be an approach where the
> code point assignment would block on the approval of the
> normative reference.
> 
> I like this approach from the political point of view.  With
> this approach the IETF tells the ITU-T that if and only if
> they are able to achieve consensus on G.8113.1, then a code
> point will be assigned.

FWIW, this seems entirely appropriate to me.  If we do it this
way, I think it is important to note --for the benefit of those
more historically involved with the ITU and others-- that we
routinely block our own documents on normative references to
work that is still in progress and, usually, do not do related
code point allocations until the blocking referenced documents
are ready.  Once the present I-D is judged to be sufficiently
ready, this approach would therefore be IETF approval and a
formal guarantee to the ITU that a code point will be allocated
if an when G.8113.1 is approved and published, but not
assignment of that code point until the referenced base document
is finished.  

Completely normal procedurally.
 
   john

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 1 Mar 2012 19:34:01 +0100

To make sure that my concerns are not missed, I attach them:

--
Hi,

*	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. 

Best regards,
Nurit
---

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Thursday, March 01, 2012 8:07 PM
To: ext Russ Housley; Loa Andersson
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

Russ,

-----Original Message-----

Loa:

Russ

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 1 Mar 2012 19:38:58 +0100

Draft-betts asks a code point for a document which is not mature and not
agreed yet. Usually we do not issue last call for a document in such a
condition!
And in addition, draft-betts has many issues that must be resolved
first. 
For example it must be clear for what the code point is requested.
Draft-betts indicates that G.8113.1 is subjected to revisions...they may
add more messages to G.8113.1 that will be hidden behind the code point,
etc.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext John C Klensin
Sent: Thursday, March 01, 2012 8:29 PM
To: Russ Housley; Loa Andersson
Cc: [email-masked]
Subject: Re: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt>
(Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet
basedOAM) to Informational RFC

 
   john

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 01 Mar 2012 18:39:14 +0000

> Completely normal procedurally.
To be clear John our normal requirement would be that the
technical community achieved consensus that the base document
was ready. I have never seen ITU-T consensus on the contents
of G.8113.1 at any meeting that I have observed. What in your
view is the criteria for determining that  G.8113.1 has achieved
consensus?

Stewart

---

From: "Kyung-Yeop Hong (hongk)" <[email-masked]>
Date: Thu, 1 Mar 2012 12:47:25 -0600

Russ,

The LS370 version of G.8113.1 has been sent to the ITU-T Nov 2012
meeting (a.k.a. WTSA) for further discussion. At this point, no one can
tell if it will be approved. As the level of stability and maturity of
G.8113.1 will not be changed between now and Nov, the opinions made by
ITU-T members at the last meeting concerning its stability would not be
changed. So the concerns expressed in this Last Call relating to the
LS370 version will remain even if G.8113.1 is approved at the ITU-T Nov
meeting.

Thanks,
KY

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Thursday, March 01, 2012 11:06 AM
To: Kyung-Yeop Hong (hongk)
Cc: [email-masked]
Subject: Re: 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

KY:

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 1 Mar 2012 14:11:49 -0500

> view is the criteria for determining that  G.8113.1 has achieved

This is not an IETF problem, and I do not think that the IETF ought to be discussing the internal workings of the ITU-T process.  The point is to come up with a mechanism that allows the code point to be assigned if and only if the ITU-T does come to a consensus by whatever means is allowed by their own process.

Russ

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 1 Mar 2012 20:33:49 +0100

Russ, 
I propose to simply re-discuss it when and IFF G.8113.1 is mature and
approved...
Best regards,
Nurit

-----Original Message-----
Sent: Thursday, March 01, 2012 9:12 PM
To: IETF

> view is the criteria for determining that  G.8113.1 has achieved

This is not an IETF problem, and I do not think that the IETF ought to
be discussing the internal workings of the ITU-T process.  The point is
to come up with a mechanism that allows the code point to be assigned if
and only if the ITU-T does come to a consensus by whatever means is
allowed by their own process.

Russ

---

From: John C Klensin <[email-masked]>
Date: Thu, 01 Mar 2012 18:04:58 -0500

--On Thursday, March 01, 2012 18:39 +0000 Stewart Bryant
<[email-masked]> wrote:

>...
>> way, I think it is important to note --for the benefit of
>> those more historically involved with the ITU and others--
>> that we routinely block our own documents on normative
>> references to work that is still in progress and, usually, do
>> not do related code point allocations until the blocking
>> referenced documents are ready.  Once the present I-D is
>> judged to be sufficiently ready, this approach would
>> therefore be IETF approval and a formal guarantee to the ITU
>> that a code point will be allocated if an when G.8113.1 is
>> approved and published, but not assignment of that code point
>> until the referenced base document is finished.
>> 
>...
> view is the criteria for determining that  G.8113.1 has
> achieved consensus?

Stewart, 

I don't think so.  

Let me suggest that there are two entirely separate issues here
and that talking about "technical community consensus" obscures
both of them.

(1) Whether, given the JWT and other agreements, the ITU has any
business developing G.8113.x at all, or whether they should be
simply submitting ideas to the IETF for consideration.  Many of
us think that, under that agreement, the G.8113 activity is
inappropriate.  But the ITU has obviously decided otherwise and
we have no enforcement capability to prevent them from doing so
(whether we should or should not is pretty much irrelevant at
this point, at least IMO).  Whether the "technical community"
has achieved consensus is not relevant either, the only thing
that matters is whether G.8113.1 is, or will be, fully approved
by the ITU under ITU procedures.

(2) Whether it is reasonable or appropriate for the IETF to use
our responsibility for code point assignments and consequent
relationship with IANA to try to keep protocols that are not
consistent with our design judgment and aesthetics --no matter
how grounded in experience and good engineering-- off the
Internet.  That is the "Internet gatekeeper" function about
which, as you know, I've expressed concern in other contexts.  I
think the answer has got to be "we can, should, and always will
exercise quality control on stable specifications and normative
references but, unless we can justify being sure of our own
infallibility, we cannot and should not try to prevent another
body from deploying a specification on the Internet by using our
control of the registration model".   Telling people why we
think their ideas are sub-optimal is fine, as is identifying any
risks we see in appropriate and visible places, but telling
another group what they can't do because the IETF doesn't like
the idea isn't.

And I think that distinction is entirely consistent with Russ's
suggestion.

best,
   john

---

From: Russ Housley <[email-masked]>
Date: Thu, 1 Mar 2012 18:52:04 -0500

Nurit:

Some people are using the lack of a code point as the reason that the cannot support the ITU-T document.  My approach tells the ITU-T that a code point is available to them IFF they are able to reach consensus.  The removes IETF from the discussion.  This creates a situation where G.8113.1 succeeded or fails based on the ITU-T members actions, with no finger pointing at the IETF.  This is completely a Layer 9 consideration, and it has noting to do with the technical content of the document.

Russ

---

From: John C Klensin <[email-masked]>
Date: Thu, 01 Mar 2012 19:14:26 -0500

--On Thursday, March 01, 2012 19:38 +0100 "Sprecher, Nurit (NSN
- IL/Hod HaSharon)" <[email-masked]> wrote:

> Draft-betts asks a code point for a document which is not
> mature and not agreed yet. Usually we do not issue last call
> for a document in such a condition!

Actually, we do that fairly regularly.   Have a look at the RFC
Editor queue, see how many documents have a status that includes
"MISSREF", and you will get an idea of how many recent ones
there are.   Of course, for that analogy to hold, draft-betts
itself must be complete and competent.  But a forward normative
reference is not a problem: it just goes into the RFC Editor
queue and, normally, IANA doesn't start doing any assignments on
the basis of such documents until the problems/ references are
resolved and the RFC Editor is editing.

> And in addition, draft-betts has many issues that must be
> resolved first. 
> For example it must be clear for what the code point is
> requested. Draft-betts indicates that G.8113.1 is subjected to
> revisions...they may add more messages to G.8113.1 that will
> be hidden behind the code point, etc.  

IMO, that should not be part of the IETF's problem.  It is part
of the forward reference.  As far as I can tell, Russ is not
suggesting actually allocating a code point until (and unless)
G.8113.1 is formally approved and hence complete and "hiding"
nothing.

     john

---

From: "Scott O. Bradner" <[email-masked]>
Date: Thu, 1 Mar 2012 18:15:59 -0500

what John said with one caveat - ITU-T consensus to modify an IETF protocol rather than
bringing requirements to the IETF should not escape the gatekeeper function

Scott

---

From: John E Drake <[email-masked]>
Date: Sat, 3 Mar 2012 09:58:06 -0800

Hi,

I agree with the proposal that Russ Housley made, below, but before even provisionally granting G.8113.1 a code point by placing draft-betts in the RFC editor's queue until G.8113.1 is approved, I would like to understand whether there is a reasonable chance for it to be approved at WTSA next fall.

Draft-betts was already in the IETF approval process at the time that G.8113.1 was disapproved, so I don't see why lack of a code point was given as a reason for its disapproval.

It is my understanding that it is very unusual to send a document to WTSA for approval, so would the authors please indicate the other issues causing G.8113.1 to be disapproved and the plan by which the ITU will address these issues?

Thanks,

John 

> Russ Housley
> Sent: Thursday, March 01, 2012 3:52 PM
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Cc: IETF
> (Allocation of anAssociated Channel Code Point for Use by ITU-T
> Ethernet basedOAM) to Informational RFC
> 
> Nurit:
> 
> Some people are using the lack of a code point as the reason that the
> cannot support the ITU-T document.  My approach tells the ITU-T that a
> code point is available to them IFF they are able to reach consensus.
> The removes IETF from the discussion.  This creates a situation where
> G.8113.1 succeeded or fails based on the ITU-T members actions, with no
> finger pointing at the IETF.  This is completely a Layer 9
> consideration, and it has noting to do with the technical content of
> the document.
> 
> Russ
> 
>

---

From: Russ Housley <[email-masked]>
Date: Sat, 3 Mar 2012 13:11:26 -0500

John:

If G.8113.1 never gets approved, then draft-betts- will sit in the RFC Editor queue until someone acknowledges this situation.

I do not want anyone to use the IETF as a reason for or against achieving consensus in the ITU-T.  Such consensus is left completely to ITU-T member states and sector members.

Russ

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sat, 3 Mar 2012 19:50:16 +0100

Russ hi,
I think many concerns were raised on draft-betts itself, so I think we
should first look at these comments....
Concerning G.8113.1, as mentioned before as it was disapproved, it is
clear that there was no consensus. It will be good to understand what
are the issues...the code point was not the main issue, as indicated by
John.
Best regards,
Nurit
 
P.S. Concerning the chances of the document to be approved in WTSA,
please note that I do not think the members of WTSA have the technical
expertise to discuss the technical aspects of the document, and I
believe they would like to encourage SG15 to stick with the ITU's
culture of negotiation and consensus-building and have technical
standards developed by the industry members based on consensus. The
logical step would be to send the document back to SG15 to resolve the
issues and get consensus. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Russ Housley
Sent: Saturday, March 03, 2012 8:11 PM
To: John E Drake
Cc: IETF
Subject: Re: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt>
(Allocationof an Associated Channel Code Point for Use by ITU-T
EthernetbasedOAM) to Informational RFC

John:

If G.8113.1 never gets approved, then draft-betts- will sit in the RFC
Editor queue until someone acknowledges this situation.

I do not want anyone to use the IETF as a reason for or against
achieving consensus in the ITU-T.  Such consensus is left completely to
ITU-T member states and sector members.

Russ

On Mar 3, 2012, at 12:58 PM, John E Drake wrote:

> Hi,
> 
> I agree with the proposal that Russ Housley made, below, but before
even provisionally granting G.8113.1 a code point by placing draft-betts
in the RFC editor's queue until G.8113.1 is approved, I would like to
understand whether there is a reasonable chance for it to be approved at
WTSA next fall.
> 
> Draft-betts was already in the IETF approval process at the time that
G.8113.1 was disapproved, so I don't see why lack of a code point was
given as a reason for its disapproval.
> 
> It is my understanding that it is very unusual to send a document to
WTSA for approval, so would the authors please indicate the other issues
causing G.8113.1 to be disapproved and the plan by which the ITU will
address these issues?
>>> to come up with a mechanism that allows the code point to be
assigned
>> if

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 5 Mar 2012 15:54:05 -0800

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:
> •        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.
>
> 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.
>
>
>
> point at all, but specifically not for unknown usage that may be defined in
> future versions of G.8113.1.
>
>
>
> Best regards,
>
> Nurit
>
>
>
>
>
>
>

---

From: "t.petch" <[email-masked]>
Date: Tue, 6 Mar 2012 11:31:31 +0100

I am finding myself with some unfamiliar bedfellows on this issue, but yes, it
should be approved - see inline.

Tom Petch

----- Original Message -----
From: "John C Klensin" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 02, 2012 12:04 AM
Subject: Re: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt> (Allocation
of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to
Informational RFC

 <snip>

> another group what they can't do because the IETF doesn't like

We claim ownership of the name space on behalf of all parties, all SDOs
governments, NGOs, anyone and anything, and this gives us a special
responsibility to exercise that wisely.  We should beware of imposing
our ideas of correctness of any kind on another SDO - that is up to
 them to decide, not us.

Of course, one open technical solution to a problem is best but the RFC
Series is suitable cluttered with instances of the IETF failing to achieve
that so any argument based on those grounds is hypocritical.

A stable, approved reference is ideal, but we have been told of the
widespread deployment of this approach using an experimental
code point so the running code very much exists.   If that is camping
on something that it would be better if it were not, then that is
something to fix, and something we can fix.

There is no reason not to approve the allocation of a code point
and furthermore, I believe we should do it now, to facilitate the migration
of the existing boxes to an approved solution.  If that leaves another
SDO with an incompatability between what is working and what
their documents say, well, the IETF has been there too; not a
good place to be, but it is up to the SDO to resolve that, not
the IETF.

Tom Petch

---

From: Eliot Lear <[email-masked]>
Date: Tue, 06 Mar 2012 12:46:55 +0100

Hi,

I speak now as an individual and in no other capacity with no other hats on.

> our ideas of correctness of any kind on another SDO - that is up to

Our responsibility is to ourselves first and foremost, and to see that
our process is followed.  That process exists to, amongst other things,
insure safe use and interoperable use of our own protocols.

Here the process for approval of a codepoint calls for IETF review. 
That is this.  IETF Review is defined as follows in RFC-5226:

            IETF Review - (Formerly called "IETF Consensus" in
            [IANA-CONSIDERATIONS]) New values are assigned only through
            RFCs that have been shepherded through the IESG as AD-
            Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
            intention is that the document and proposed assignment will
            be reviewed by the IESG and appropriate IETF WGs (or
            experts, if suitable working groups no longer exist) to
            ensure that the proposed assignment will not negatively
            impact interoperability or otherwise extend IETF protocols
            in an inappropriate or damaging manner.

In addition, we have spoken on what it means for other SDOs to request
code points in RFC-4775 Section 3.2, which says, in part:

   Experience shows that the importance of this is often underestimated
   during extension design; designers sometimes assume that a new
   codepoint is theirs for the asking, or even simply for the taking.
   This is hazardous; it is far too likely that someone just taking a
   protocol value will find that the same value will later be formally
   assigned to another function, thus guaranteeing an interoperability
   problem.

Our processes direct us to consider a codepoint assignment in this

> There is no reason not to approve the allocation of a code point

The purpose of this review is to determine whether or not there is
reason *not* to approve.  Others disagree with you.

Eliot

---

From: "t.petch" <[email-masked]>
Date: Tue, 6 Mar 2012 16:25:24 +0100

----- Original Message -----
From: "Eliot Lear" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "John C Klensin" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 06, 2012 12:46 PM

> insure safe use and interoperable use of our own protocols.

Which, Eliot, is where we part company.  Given the interest in and uptake
of MPLS outside the original definition, we have a wider responsibility,
as we have in, say, managing the IP address or domain name space.  As
with the last two, if we do not consider the needs of all parties, and not just
ourselves, we may lose our influence in these matters.  Yes we must follow our
processes but in the interests of a wider community than just ourselves.

Tom Petch

---

From: Loa Andersson <[email-masked]>
Date: Mon, 12 Mar 2012 09:31:43 +0100

All,

I've been asked to clarify thee comments in this mail, I done
so by proposing new text to draft-betts-.

I hope this helps.

Title
=====

Comment: We want to assign a Associated Channel Type. The registry
that it  will be assigned from is "Pseudowire Associated Channel
Types"; however RFC 5586, makes the Channel Types generic and I
think the title should be changed as follows:

OLD:
Allocation of an Associated Channel Code Point for Use by ITU-T
Ethernet based OAM

NEW:
Allocation of an Generic Associated Channel Type for ITU-T
MPLS-TP OAM

Note: Neither MPLS-TP or OAM are in the RFC Editors list of wellknown
acronyms, therfore the title probably should be:

NEW:
Allocation of an Generic Associated Channel Type for ITU-T
MPLS Transport Profile Operation, Maintenance and Administration.

Introduction - first paragraph
==============================

In the first paragraph of the introduction, there seems to be an
oddity in the description of the role of the ietf-tp-oam-analysis
document.  Instead of:

OLD
"tools defined by the IETF [I-D.ietf-mpls-tp-oam-analysis], that
are intended to meet the OAM functional requirements defined in
[RFC5860]."

NEW:
"tools described by the IETF [I-D.ietf-mpls-tp-oam-analysis], which
are used to meet the OAM functional requirements defined
in [RFC5860]."

Intrduction - second paragraph
==============================

The next paragraph in describing G.8113.1, stumbles over the current
vs anticipated future state of G.8113.1 and its relationship to
its antecedents.  I'm a bit un-certain about the correct terminology,
but I think the following change would improve the document.

OLD:

The ITU-T has documented, in draft new Recommendation [G.8113.1], the
use of Ethernet based OAM mechanisms, originally defined in [Y.1731],
carried in the MPLS Generic Associated Channel (G-ACh). This approach
requires the allocation of an ACH Type from the registry of ACH types
maintained by IANA in order that the messages that will be described
in [G.8113.1] can be identified by an implementation.

NEW:

"The ITU-T has Draft Recommendation [G.8113.1] documented MPLS OAM
which as of this writing is undergoing the ITU-T Traditional
Approval Process (TAP). This Recommendation builds upon Ethernet
OAM as documented in [Y.1731]. The messages in [G.8113.1] are defined
to be carried in a new Associated Channel Type in the MPLS Generaic
  Associated Channel (G-Ach).  In order to carry these messages in an
interoperable fashion, an Associated Channel Type from the IANA
maintained registry "Pseudowire Associated Channel Types is to be
used."

Note there are confusion around some of the Associated Channel
acronyms that are refledted in this document.

ACh is Associated Channel
ACH is Associated Chamnnel Header
G-ACh is Generic Associated Channel

"ACH Type" is not used anywhere in IETF documents; we talk about
Associated Channel Type or Generic Associated Channel Type
(G-ACh Type).

Introduction - third paragraph
==============================

In the third paragraph, there seems to be an unnecessary reference
to experimental types.  When asking for a code point for a standard,
it is not helped to bring up experimental code space.  Can we remove
the text reading:

OLD:
"without continuing to resorting to the use of an experimental
ACH Type,"

NEW
-

Section 2 - first paragraph
===========================

In section 2, the first sentence refers to Ethernet based OAM
messages. As far as I know, the messages in G.8113.1 are either
MPLS-TP OAM messages, or they are simply the OAM messages defined
in G.8113.1.  The simplest path to clarity would seem to be to
replace "Ethernet based OAM messages" in that sentence with
"messages".

The second sentence of that paragraph does not seem to say anything
we need to say.  Can we remove it?

OLD:

    The code point allocated by this document is intended to be used only
    for Ethernet based OAM messages, defined in the ITU-T Recommendation
    [G.8113.1], carried in the G-ACh . 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.

NEW:

    The code point allocated by this document is intended to be used
    only for OAM messages, defined in the ITU-T Recommendation
    [G.8113.1], carried in the G-ACh . Other message types should not
    be carried behind this Associated Channel Type.

Section 2 - second paragraph
============================

A matter of some clarity, can we change this paragrap like this:

OLD:
    This code point may be used on any transport construct that uses
    the G-ACh, e.g., MPLS-TP Sections, MPLS-TP LSPs or PWs.

NEW:

    The Generic Associated Channel Type assigned by this
    document may be used on any transport construct that uses the
    G-ACh, e.g., MPLS-TP Sections, MPLS-TP LSPs or PWs as specified
    by G.8113.1.

Section 2 - third paragraph
===========================

With regard to revisions, which is what I think the third paragraph
is about, I am not clear what you are trying to say.  A code point
allocation must point to a stable referent.  If the desired referent
changes, then process needs to be followed to make sure that the IANA
is updated in accordance with IETF procedures.  Hence, I am left to
the conclusion that the third paragraph is actually asking for
something we can not do.  Can we remove that?

OLD:
    All ITU-T Recommendations are subject to revisions. Therefore, the
    code point allocated by this document may be used for future versions
    of [G.8113.1].

NEW:
    -

On 2012-02-27 14:51, Loa Andersson wrote:
> All,
>
> I agree with Stewart, while shortage of code points might be a reason
> to think twice before allocating one, "abundance" in itself is never
> a reason to allocate code points.
>
> I'm way less inclined to approve of this draft in the condition it
> is now. Actually I believe that we should think very careful before
> approving it at all.
>
> /Loa
>
> On 2012-02-27 14:01, Stewart Bryant wrote:
>>
>> Daniel
>>
>> Shortage of ACh types was never an issue.
>>
>> The issue issue is the concerns articulated in
>> draft-sprecher-mpls-tp-oam-considerations
>>
>> Stewart
>>
>>
>> On 23/02/2012 10:35, Daniel Cohn wrote:
>>> Support - as there is no foreseen shortage in ACH types, I don't see a
>>> reason why this code point should not be allocated to an ITU developed
>>> protocol that is already deployed in the field.
>>>
>>> DC
>>>
>>> pwe3 mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/pwe3

--

---

From: Ross Callon <[email-masked]>
Date: Tue, 13 Mar 2012 14:26:41 -0400

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: [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

Cheers,
Andy

On Thu, Mar 1, 2012 at 7:20 AM, Sprecher, Nurit (NSN - IL/Hod
HaSharon) <[email-masked]> wrote:
> .        It is indicated that the channel is intended to be used to carry
> .        It is not clear what the maturity status of G.8113.1 is. It seems
> .        I find a contradiction in the draft. In one place it is mentioned:

---

From: Rolf Winter <[email-masked]>
Date: Wed, 14 Mar 2012 11:38:22 +0000

Having thought about this for some time, I think I concur with Russ' reasoning and the allocation should be made. 

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> Sent: Freitag, 2. März 2012 00:52
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of ext Russ Housley
> understanding
> >>>> is that earliest that we could see an approved
> >>>> However, if we are willing to assign a code point to G.8113.1 once
> >>>> it is approved, then this would be an approach where the code
> point
> >>>> assignment would block on the approval of the normative reference.
> >>>>
> >>>> approach the IETF tells the ITU-T that if and only if they are
> able
> >>>> to achieve consensus on G.8113.1, then a code point will be
> >>>> assigned.
> >>> FWIW, this seems entirely appropriate to me.  If we do it this way,
> >>> I think it is important to note --for the benefit of those more
> >>> historically involved with the ITU and others-- that we routinely
> >>> block our own documents on normative references to work that is
> >>> still in progress and, usually, do not do related code point
> >>> allocations until the blocking referenced documents are ready.
> Once
> >>> the present I-D is judged to be sufficiently ready, this approach
> >>> would therefore be IETF approval and a formal guarantee to the ITU
> >>> that a code point will be allocated if an when G.8113.1 is approved
> >>> and published, but not assignment of that code point until the
> >>> referenced base document is finished.
> >>>
> >> To be clear John our normal requirement would be that the technical
> >> community achieved consensus that the base document was ready. I
> have
> >> never seen ITU-T consensus on the contents of G.8113.1 at any
> meeting
> >> that I have observed. What in your view is the criteria for
> >> determining that  G.8113.1 has achieved consensus?
> >
> >
> > be discussing the internal workings of the ITU-T process.  The point
> > is to come up with a mechanism that allows the code point to be
> > assigned if and only if the ITU-T does come to a consensus by
> whatever
> > means is allowed by their own process.
> >
> > Russ

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 14 Mar 2012 23:42:42 +0100

Loa hi,
I think your proposal is productive and provides a good basis to
progress. 
Please see some comments inline (<Nurit>...\<Nurit>).
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Loa Andersson
Sent: Monday, March 12, 2012 10:32 AM
To: [email-masked]
Subject: Re: [PWE3] FW: Last
Call:<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof an
Associated Channel Code Point for Use byITU-T Ethernet based OAM)to
Informational RFC

All,

I hope this helps.

Title
=====

OLD:

NEW:

NEW:

OLD

NEW:

<Nurit> should we say "described and referred by..."? \<Nurit>
<Nurit> should we say "...that satisfies the OAM functional requirements
defined in [RFC586]"?

OLD:

NEW:

OLD:

NEW
-

OLD:

only
    [RFC5860]. Other message types should not be carried behind this
code
    point.

NEW:

<Nurit> here we should be clearer about which OAM messages we refer to.
It should be clear that these are the only ones that satisfy the
requirements of RFC 5860. I want to make sure that messages of
protection mechanisms are not included and are not hidden by the
allocated codepoint. \<Nurit>

OLD:

NEW:

OLD:
    All ITU-T Recommendations are subject to revisions. Therefore, the
    code point allocated by this document may be used for future
versions
    of [G.8113.1].

NEW:
    -

--

---

From: [email-masked]
Date: Thu, 15 Mar 2012 11:13:01 +0800

Hi all,

I agree with Russ and support the allocation of an ACH codepoint to 
G.8113.1.

Yuxia

[email-masked] 写于 2012-03-02 07:52:04:

> Nurit:
> 
> Some people are using the lack of a code point as the reason that 
> the cannot support the ITU-T document.  My approach tells the ITU-T 
> that a code point is available to them IFF they are able to reach 
> consensus.  The removes IETF from the discussion.  This creates a 
> situation where G.8113.1 succeeded or fails based on the ITU-T 
> members actions, with no finger pointing at the IETF.  This is 
> completely a Layer 9 consideration, and it has noting to do with the
> technical content of the document.
> 
> Russ
> 
> 
Of
> > (Allocation of anAssociated Channel Code Point for Use by ITU-T 
Ethernet
> > be discussing the internal workings of the ITU-T process.  The point 
is

---

From: Rui Costa <[email-masked]>
Date: Sat, 17 Mar 2012 12:00:56 +0000

Hello,	

I support the allocation of an ACH codepoint to G.8113.1, not precluding the ITU-T to progress refinements. Ergo, i support this draft and proposal http://www.ietf.org/mail-archive/web/ietf/current/msg72191.html.	

IMHO, the status quo analysis expressed in both http://www.ietf.org/mail-archive/web/ietf/current/msg72188.html and http://www.ietf.org/mail-archive/web/ietf/current/msg72273.html is accurate.	

Regards,	
Rui	

-------- Original Message --------
From: The IESG <[email-masked]>
Sent: Wed, 22 Feb 2012 07:12:52 -0800
To: IETF-Announce <[email-masked]>
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

---

From: Maarten vissers <[email-masked]>
Date: Mon, 19 Mar 2012 10:55:31 +0000

+1

-------- Original Message --------
From: Rui Costa <[email-masked]>
Sent: zaterdag 17 maart 2012 12:00:56 +0000
To: [email-masked] <[email-masked]>
Subject: RE: Last Call: <draft-betts-itu-oam-ach-code-point-03.txt> 

Hello,	

I support the allocation of an ACH codepoint to G.8113.1, not precluding 
the ITU-T to progress refinements. Ergo, i support this draft and 
proposal http://www.ietf.org/mail-archive/web/ietf/current/msg72191.html

IMHO, the status quo analysis expressed in both 
http://www.ietf.org/mail-archive/web/ietf/current/msg72188.html and 
http://www.ietf.org/mail-archive/web/ietf/current/msg72273.html is 
accurate.	

Regards,	
Rui	
=========================================================

-------- Original Message --------
From: The IESG <[email-masked]>
Sent: Wed, 22 Feb 2012 07:12:52 -0800
To: IETF-Announce <[email-masked]>
Subject: Last Call: <draft-betts-itu-oam-ach-code-point-03.txt> 

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

be sent to [email-masked] instead. In either case, please retain the 

Abstract

IETF mailing list
[email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Mon, 19 Mar 2012 18:53:24 +0100

Maarten,

please be aware of what u asking for - you won't have a
"an ACH codepoint to G.8113.1".

First, what is requested is an "Associated Channel Type"
and it will be assigned to the RFC resulting from draft-betts-.
I will not do my tutorial on Associated Channel acronyms,
but it could do it if needed, but some other venue.

Assigning the Associated Channel Type is what I see that
a solid majority want to happen!
This is not an attempt to end-run the consensus call by the AD,
just my personal read of the situation.

The first remaining caveat is the draft-betts is too poorly written
and need to be improve, suggestions has been sent to this mailing
list, I take it that people who send mails to this list saying
that they support Russ' proposal also implicitly support these
improvements.

The second caveat is that an ITU-T Recommendation is not stable
according to the criteria we normally apply to RFCs.

We are solving this by generating a RFC from draft-betts-.
I believe that the way out here is to "update" "RFC draft-betts-"
every time ITU-T rev G.8113.1. That way we will have our stable
reference pointing to the right version of G.8113.1.

I'd like to hear from the process people on this, but not as part
of this last call.

/Loa

On 2012-03-19 11:55, Maarten vissers wrote:
> From: Rui Costa<[email-masked]>
> To: [email-masked]<[email-masked]>
> Subject: RE: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt>
> From: The IESG<[email-masked]>
> To: IETF-Announce<[email-masked]>

--

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 21 Mar 2012 00:19:15 +0100

Hello,

I continue my support for the codepoint allocation

I agree with Russ's statement in
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=62185&tid=1331648664
"Some people are using the lack of a code point as the reason that
  the cannot support the ITU-T document. My approach tells the ITU-T
  that a code point is available to them IFF they are able to reach
  consensus. The removes IETF from the discussion. This creates a
  situation where G.8113.1 succeeded or fails based on the ITU-T
  members actions, with no finger pointing at the IETF. This is
  completely a Layer 9 consideration, and it has noting to do with
  the technical content of the document. "

The codepoint allocation should allow the ITU-T to make refinements
to G.8113.1 such that it can satisfy the functional requirements defined 
in RFC 5860.

Regards, Huub.

===================================================================
On 22-02-12 16:12, The IESG wrote:
> [email-masked] mailing lists by 2012-03-21. Exceptionally, comments may be

-- 
*****************************************************************
                          我爱外点一七三一

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 21 Mar 2012 08:41:58 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of ext Huub van Helvoort
Sent: Wednesday, March 21, 2012 1:19 AM
To: [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,

Regards, Huub.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 21 Mar 2012 12:06:24 +0100

Tom,

I've let this sit a while, but wanted to respond on the following point:

On 3/6/12 4:25 PM, t.petch wrote:
> -ur responsibility is to ourselves first and foremost, and to see that
> as we have in, say, managing the IP address or domain name space.

If our process is broken, we should change it.  Our processes should
take into account that which *we* can control.  Making the best
recommendations for the use of our protocols on the Internet addresses
your point about the "wider community".  The IETF exists to serve that
wider community, but when others attempt to use our works in a way that
might harm our work, we equally have a responsibility to hold a line.  I
am NOT saying that in this instance, by the way, G.8113.1 harms IETF
work if a proper code point is assigned.  It would harm our work if a
code point was simply expropriated.

>   As

Were this really true, then we must reject this request because of the
likelihood of fragmented solutions that do not interoperate.  Is that
what you are arguing?

Eliot

---

From: "Zhenlong Cui" <[email-masked]>
Date: Wed, 21 Mar 2012 20:19:33 +0900

I support the allocation of an ACH code point to G.8113.1, and I agree with Russ's comment.

In addition, to avoid the same argument after the ITU-T's decision, I suggest we should clearly conclude that a code point be
available if ITU-T will make consensus on G.8113.1, during this last call.
This conclusion should be immediately informed to ITU-T.

Best regards,
zhenlong

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: Friday, March 02, 2012 8:52 AM
> Subject: Re: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt> (Allocationof anAssociated Channel Code Point for Use
> by ITU-T EthernetbasedOAM) to Informational RFC
> 
> Nurit:
> 
> Some people are using the lack of a code point as the reason that the cannot support the ITU-T document.  My approach tells
> the ITU-T that a code point is available to them IFF they are able to reach consensus.  The removes IETF from the discussion.
> This creates a situation where G.8113.1 succeeded or fails based on the ITU-T members actions, with no finger pointing at
> the IETF.  This is completely a Layer 9 consideration, and it has noting to do with the technical content of the document.
> 
> Russ
> 
>

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Wed, 21 Mar 2012 15:15:24 +0100

I support the draft.
Multi-vendor interoperable implementations of the protocol the draft  is asking for the allocation of a code point  has been already tested and deployed and therefore I agree with Mr. Petch when he says  we should approve it now to facilitate the migration of the existing boxes to an approved solution.

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-masked]]
Inviato: martedì 6 marzo 2012 11:32
A: John C Klensin; [email-masked]
Cc: [email-masked]
Oggetto: Re: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt> (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC

I am finding myself with some unfamiliar bedfellows on this issue, but yes, it should be approved - see inline.

Tom Petch

----- Original Message -----
From: "John C Klensin" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 02, 2012 12:04 AM
Subject: Re: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt> (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC

 <snip>

> (2) Whether it is reasonable or appropriate for the IETF to use our
> responsibility for code point assignments and consequent relationship
> with IANA to try to keep protocols that are not consistent with our
> design judgment and aesthetics --no matter how grounded in experience
> and good engineering-- off the Internet.  That is the "Internet
> gatekeeper" function about which, as you know, I've expressed concern
> in other contexts.  I think the answer has got to be "we can, should,
> and always will exercise quality control on stable specifications and
> normative references but, unless we can justify being sure of our own
> infallibility, we cannot and should not try to prevent another body
> from deploying a specification on the Internet by using our
> think their ideas are sub-optimal is fine, as is identifying any risks
> we see in appropriate and visible places, but telling another group
> what they can't do because the IETF doesn't like the idea isn't.

We claim ownership of the name space on behalf of all parties, all SDOs governments, NGOs, anyone and anything, and this gives us a special responsibility to exercise that wisely.  We should beware of imposing our ideas of correctness of any kind on another SDO - that is up to  them to decide, not us.

Of course, one open technical solution to a problem is best but the RFC Series is suitable cluttered with instances of the IETF failing to achieve that so any argument based on those grounds is hypocritical.

A stable, approved reference is ideal, but we have been told of the widespread deployment of this approach using an experimental
code point so the running code very much exists.   If that is camping
on something that it would be better if it were not, then that is something to fix, and something we can fix.

There is no reason not to approve the allocation of a code point and furthermore, I believe we should do it now, to facilitate the migration of the existing boxes to an approved solution.  If that leaves another SDO with an incompatability between what is working and what their documents say, well, the IETF has been there too; not a good place to be, but it is up to the SDO to resolve that, not the IETF.

Tom Petch

> And I think that distinction is entirely consistent with Russ's

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.

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: [email-masked]
Date: Wed, 21 Mar 2012 15:33:03 -0500

Loa,

Thank you for your comments and suggestions, please see in line below.

Regards,

Malcolm

[email-masked] wrote on 12/03/2012 04:31:43 AM:

> Loa Andersson <[email-masked]> 
> Sent by: [email-masked]
> 
> 12/03/2012 04:31 AM
> 
> To
> 
> [email-masked]
> 
> cc
> 
> Subject
> 
> Re: [PWE3] FW: Last Call: <draft-betts-itu-oam-ach-code-
> point-03.txt>(Allocation of an Associated Channel Code Point for Use
> byITU-T Ethernet based OAM) to Informational RFC
> 
> All,
> 

MB: No objection to this change

> Introduction - first paragraph

MB: No objection to this change

> Intrduction - second paragraph

MB: Since the draft will not be published as an RFC until after G.8113.1 
is approved we can directly reference the approved Recommendation and I 
suggest that we modify paragraph to:

ITU-T Recommendation [G.8113.1] documents MPLS OAM. This Recommendation 
builds upon Ethernet OAM as documented in [Y.1731]. The messages in 
[G.8113.1] are defined to be carried in a new Associated Channel Type in 
the MPLS Generaic Associated Channel (G-Ach).  In order to carry these 
messages in an interoperable fashion, an Associated Channel Type from the 
IANA maintained registry "Pseudowire Associated Channel Types is to be 
used."

> Associated Channel Type or Generic Associated Channel Type

MB: Thank you, I will fix this.

> Introduction - third paragraph

MB: I do not agree with the deletion of this text, these existing 
deployments, and the desire to migrate to an allocated code point, are 
part of the rational for requesting the code point.

only
code
>     be carried behind this Associated Channel Type.

MB: I do not agree with this proposed change. Other comments request that 
the restriction on the applicability of the code point is strengthened so 
I propose the following:

The code point allocated by this document should only be used for OAM 
messages, defined in the ITU-T Recommendation [G.8113.1], carried in the 
G-ACh. The messages and procedures carried behind this code point, are 
restricted to only those that the address the OAM functional requirements 
defined in [RFC5860]. Other message types should not be carried behind 
this code point.

> Section 2 - second paragraph

MB: No objection to this change.

versions
> NEW:

MB: I do not agree with the removal of this text:

The intention of this statement is to bring to the attention of the IETF 
the normal practice in the ITU of developing amendments to Recommendations 
to fully meet the functional requirements (e.g. adding pro-active loss 
measurement).  Normally any reference to ITU-T Rec G.8113.1 will 
automatically be directed to the current version (including any 
amendments). 

Only those interfaces that support G.8113.1 OAM will act on these OAM 
messages, any interface that does not support this G-ACh type will discard 
these OAM messages as defined in RFC5586.

Restricting the application of the code point to a specific version of 
Recommendation G.8113.1 would require the ITU to deviate from its normal 
process for enhancing Recommendations and would put the IETF back into the 
discussion for approval.

>---------------snip

---

From: Yoshinori Koike <[email-masked]>
Date: Thu, 22 Mar 2012 06:04:43 +0900

Yes/Support.

I also support the following comment from Mr.Tom Petch.

"There is no reason not to approve the allocation of a code point
and furthermore, I believe we should do it now, to facilitate the 
migration of the existing boxes to an approved solution."

It is very difficult for me to find the reason that a Generic Associated 
Channel Type for ITU-T MPLS-TP OAM cannot be allocated, considering the 
following points.

-Request from ITU-T(LS370 - Current status of Recommendation ITU-T 
G.8113.1/Y.1372.1, Operations, Administration and Maintenance mechanism 
for MPLS-TP in Packet Transport Network (PTN)) which I think reflects a 
strong demand for G.8113.1 in transport networks which sustain Internet 
all over the world.
-Necessity to continue cooperation and collaboration with ITU-T
-Expected difficulties to progress G.8113.1 OAM protocol based on Rough 
Consensus in IETF

IMHO, this is the case that the IETF leverages standards that are 
defined and maintained by other organizations; we continue to work with 
those organizations on their standards and do not attempt to take them over.

Best regards,

Yoshinori

(Allocation of
an
consider
be

-- 
Yoshinori Koike
[email-masked]

---

From: Thomas Walsh <[email-masked]>
Date: Wed, 21 Mar 2012 20:37:26 -0400

I don’t see a problem with the  IETF process. We should however understand why the ITU-T process failed to reach a consensus or approval.

Draft-betts states  “A number of experts in the IETF do not consider that the development or deployment of a second protocol solution within the same architectural problem space is necessary or advisable”.  This statement from draft-betts isn’t why ITU-T SG 15 failed to approve G.8113.1.  Consensus or approval in ITU-T is decided only by sector members and member states.

The referenced liaison in draft-betts mentions “One of the issues that prevented the approval in SG 15 was the lack of an ACh code point to support this Recommendation.”   One of the reasons?  I read that to mean there were other reasons as well.

IETF could ask SG 15, via liaison,  for more information as to the “other reasons” why the  ITU-T process failed to achieve to achieve a consensus around G.8113.1.

SG 15, admitting they failed in their process to reach approval on G.8113.1, states in the referenced liaison  “Unfortunately the Study Group could not approve this Recommendation so it was forwarded to the WTSA (20-29 November 2012) for approval.”

WTSA is different from SG 15.  I don’t know what will happen there, and whether approval will result.  As of now, consensus/approval was not achieved within the ITU-T process.

My view is IETF should wait at least until there is an approved Recommendation.

Tom Walsh

---

From: Loa Andersson <[email-masked]>
Date: Fri, 23 Mar 2012 10:44:47 +0100

Malcolm,

good that we are making some progress!

On the experimental code point
------------------------------

I doesn't seem appropriate to call out the fact that some commercial
products has been using an experimental code point in production
setting!

On the remain (key) disagreements
---------------------------------

I will let other people comment for now.

/Loa

On 2012-03-21 21:33, [email-masked] wrote:
> messages in an interoperable fashion, an Associated Channel Type from
> the IANA maintained registry "Pseudowire Associated Channel Types is to
> be used."
>
>
>  >
> MB: I do not agree with this proposed change. Other comments request
> that the restriction on the applicability of the code point is
> strengthened so I propose the following:
>
> restricted to only those that the address the OAM functional
> requirements defined in [RFC5860]. Other message types should not be
> carried behind this code point.
>
>
>  >
> the normal practice in the ITU of developing amendments to
> Recommendations to fully meet the functional requirements (e.g. adding
> pro-active loss measurement). Normally any reference to ITU-T Rec
> G.8113.1 will automatically be directed to the current version
> (including any amendments).
>
> messages, any interface that does not support this G-ACh type will
> discard these OAM messages as defined in RFC5586.
>
> process for enhancing Recommendations and would put the IETF back into
> the discussion for approval.
>
>
>
>  >---------------snip
>
>
>  >

--

---

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

Loa

The one point that jumps out at me is the proposed text
"Other message types should not be carried behind this code point."
or should that be
"Other message types SHOULD NOT be carried behind this code point."
which, in IETF-Land, is a bit different.

I prefer the latter.

Tom Petch

----- Original Message -----
From: "Loa Andersson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 23, 2012 10:44 AM
Subject: Re: [PWE3] FW: LastCall:
<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof an Associated Channel
Code Point for Use byITU-T Ethernet basedOAM) to Informational RFC

---

From: "t.petch" <[email-masked]>
Date: Fri, 23 Mar 2012 11:30:19 +0100

----- Original Message -----
From: "Eliot Lear" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 21, 2012 12:06 PM
> code point was simply expropriated.

<tp>
Yes I agree.

> likelihood of fragmented solutions that do not interoperate.  Is that

Disagree here.  Where multiple solutions exist, then interoperability costs
more.  Ask anyone implementing ... well anything with IP in it, say, and
currently, they will be expected to have both IPv4 and IPv6, a dual stack in
some sense of the word, and the cost of this ripples up the stack to whereever
IP addresses cease to be visible, which is a long way up.

Ditto SNMP where there are three different flavours that a stack will support,
in many if not most cases.  And so on and so forth.

So having two different packet formats for the same OAM function is a pain and
will cost; but as long as the protocols are properly defined, as I believe they
are here, then the coexistence will have a cost but will not stop
interoperability, in the same way as we have IPv6 and IPv4 and a lot of
associated options, dual stack, gateway, encapsulation ......

Tom Petch

---

From: [email-masked]
Date: Fri, 23 Mar 2012 10:39:20 -0500

Tom,

I have no objections to using the RFC 2119 key words, I am not sure if 
that is appropriate in an informational track document, I expect that our 
AD will provide some guidance.

Regards,

Malcolm

"t.petch" <[email-masked]> 
23/03/2012 05:50 AM

To
"Loa Andersson" <[email-masked]>, <[email-masked]>
cc
<[email-masked]>
Subject
Re: [PWE3] FW: LastCall: 
<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof        an 
Associated Channel Code Point for Use byITU-T Ethernet  basedOAM)       to 
Informational RFC

Loa

I prefer the latter.

Tom Petch

----- Original Message -----
From: "Loa Andersson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 23, 2012 10:44 AM
Subject: Re: [PWE3] FW: LastCall:
Channel

only
code
versions

---

From: Ross Callon <[email-masked]>
Date: Fri, 23 Mar 2012 11:45:52 -0400

A current AD might take precedence over a past one, but back when I was on the IESG we twice had discussions of the use of RFC2119 keywords in informational track documents. Both times we fortunately came to the same conclusion - that it is fine to use RFC2119 keywords in informational (or experimental) RFCs.

Ross

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, March 23, 2012 11:39 AM
To: t.petch
Cc: [email-masked]
Subject: Re: [PWE3] FW: LastCall: <draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof an Associated Channel Code Point for Use byITU-T Ethernet basedOAM) to Informational RFC

Tom,

I have no objections to using the RFC 2119 key words, I am not sure if that is appropriate in an informational track document, I expect that our AD will provide some guidance.

Regards,

Malcolm

23/03/2012 05:50 AM

To

cc

<[email-masked]>

Subject

Re: [PWE3] FW: LastCall:        <draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof        an Associated Channel Code Point for Use byITU-T Ethernet        basedOAM)        to Informational RFC

Loa

I prefer the latter.

Tom Petch