Hi,
I support to allocate a codepoint to G.8113.1.
Best ragards,
Satoshi
Hi,
On 03/21/2012 09:20 AM, Satoshi UENO wrote:
Hi,
I support to allocate a codepoint to G.8113.1.
Good for you. But just so you and other folks posting
similar mails know, this mail won't be helpful for me
as an AD when it comes to evaluating this topic, since
I've no clue as to the
I support the allocation of an ACH codepoint to G.8113.1, not precluding the
ITU-T to progress refinements to the protocol following its own process.
As indicated by Russ, this approach creates a situation where G.8113.1
succeeded or fails based on the ITU-T members actions, with no finger
Hello,
I continue my support for the codepoint allocation
I agree with Russ's statement in
https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=933k2=62185tid=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
+1
Original Message
From: Rui Costa rco...@ptinovacao.pt
Sent: zaterdag 17 maart 2012 12:00:56 +
To: ietf@ietf.org ietf@ietf.org
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
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
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
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
On Mar 1, 2012, at 6:04 PM, John C Klensin wrote:
--On Thursday, March 01, 2012 18:39 + Stewart Bryant
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
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,
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
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
--On Thursday, March 01, 2012 13:02 -0500 Russ Housley
hous...@vigilsec.com 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
On 01/03/2012 18:28, John C Klensin wrote:
--On Thursday, March 01, 2012 13:02 -0500 Russ Housley
hous...@vigilsec.com 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
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
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
--On Thursday, March 01, 2012 18:39 + Stewart Bryant
stbry...@cisco.com wrote:
...
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
PWE3 WG
Please see the note further down the thread requesting that
any discussion take place on ietf@ietf.org
Stewart
On 27/02/2012 14:27, Stewart Bryant wrote:
My understanding is that the Recommendation called up by
this draft proposes this as a new OAM be used for PWs.
I do not think
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
19 matches
Mail list logo
