As mentioned, I proposed you listen to the record…it will help you refreshing
your memory!
You may want to listen also to Final and U.K….and I propose you listen again
also to what U.S said…
There was also a note on the huge effort to find a compromise that did not work
out….:-(
From: ext HUANG Feng F
[mailto:Feng(_dot_)f(_dot_)Huang(_at_)alcatel-sbell(_dot_)com(_dot_)cn]
Sent: Wednesday, December 21, 2011 1:59 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Huub helvoort; Russ Housley;
Malcolm(_dot_)BETTS(_at_)zte(_dot_)com(_dot_)cn;
ietf-bounces(_at_)ietf(_dot_)org;
draft-betts-itu-oam-ach-code-point(_at_)tools(_dot_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org; mpls(_at_)ietf(_dot_)org;
adrian(_at_)olddog(_dot_)co(_dot_)uk
Subject: Re: Questions about draft-betts-itu-oam-ach-code-point
Nurit,
Yes, you can memory the record, US stated because of lacking of ACH code
point, they don't support it, other 3 states support US as same position. So
the origin is lack of ACH code point. The liaison recorded the ITU-T status
too.
Best Regard
Feng Huang
OPD, Alcatel Lucent Shanghai Bell
86-21-50554550-5515
在 2011-12-21,19:32,"Sprecher, Nurit (NSN - IL/Hod HaSharon)"
<nurit(_dot_)sprecher(_at_)nsn(_dot_)com> 写道:
Feng,
I do not care about the liaison…the liaison was not sent by the member
states…
I care about the reasons that member states gave when they opposed
G.8113.1. The main reason was "lack of consensus"….
But I propose that everyone that have TIES access listen to the audio
of the meeting and judge it…
Best regards,
Nurit
From: ext HUANG Feng F
[mailto:Feng(_dot_)f(_dot_)Huang(_at_)alcatel-sbell(_dot_)com(_dot_)cn]
Sent: Wednesday, December 21, 2011 1:29 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Huub helvoort; Russ Housley;
Malcolm(_dot_)BETTS(_at_)zte(_dot_)com(_dot_)cn;
ietf-bounces(_at_)ietf(_dot_)org;
draft-betts-itu-oam-ach-code-point(_at_)tools(_dot_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org; mpls(_at_)ietf(_dot_)org;
adrian(_at_)olddog(_dot_)co(_dot_)uk
Subject: Re: Questi! ons about draft-betts-itu-oam-ach-code-point!
Nurit,
You left Plenary too early and when it was not closed, ITU has
decided to send a Liasion to IETF on this issue the draft of G.8113.1 is
stable, the only reason is lack of Ach code point, you can see liaison from
ITU-T.
Best Regard
Feng Huang
OPD, Alcatel Lucent Shanghai Bell
86-21-50554550-5515
在 2011-12-21,19:00,"Sprecher, Nurit (NSN - IL/Hod HaSharon)"
<nurit(_dot_)sprecher(_at_)nsn(_dot_)com> 写道:
Huub hi,
I was in the closing plenary, and I heard different reasons for
not approving G.8113.1.
The main argument that I heard was because of lack of
consensus. !
Best regards,
Nurit
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of ext Huub helvoort
Sent: Wedn! esday, December 21, 2011 12:51 PM
To: Russ Housley;
Malcolm(_dot_)BETTS(_at_)zte(_dot_)com(_dot_)cn
Cc: ietf-bounces(_at_)ietf(_dot_)org;
adrian(_at_)olddog(_dot_)co(_dot_)uk;
draft-betts-itu-oam-ach-code-point(_at_)tools(_dot_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org; mpls(_at_)ietf(_dot_)org
Subject: RE: Questions about draft-betts-itu-oam-ach-code-point
Hello Russ,
You wrote:
> My understanding is that there is not a stable agreed
G.8113.1 document to reference.
> Is my understanding incorrect?
Your understanding is partially incorrect:
The draft recommendation G.8113.1 is stable, there have been no
major technical
changes since it was sent to the IETF (when it still had the
draft name G.tpoam)
attache to liaison: https://datatracker.ietf.org/liaison/983/
This is also the status I reported when we did discuss this
during IETF82 in Taipei.
G.8113.1 could not be approved because of the technical reason
that there is
no ACh codepoint assigned.
Best regards, Huub.
======
On Dec 20, 2011, at 11:09 AM,
Malcolm(_dot_)BETTS(_at_)zte(_dot_)com(_dot_)cn wrote:
Hi Adrian,
Thank you for finding time to respond to this request. As !
you know I was attending the same 2 week SG 15 meeting and was! probabl y at
least as busy as you given my official role in the meeting.
I will update draft-betts-itu-oam-ach-code-point early in the
new year based on the results of SG 15 the ended last Friday and your
comments. I will also discussan update of the shepherd write up with Huub.
Regards,
Malcolm
"Adrian Farrel" <adrian(_at_)olddog(_dot_)co(_dot_)uk>
Sent by: ietf-bounces(_at_)ietf(_dot_)org
09/12/2011 05:49 AM
Please respond to
adrian(_at_)olddog(_dot_)co(_dot_)uk
To
<draft-betts-itu-oam-ach-code-point(_at_)tools(_dot_)ietf(_dot_)org>, "'Huub
helvoort'" <huub(_dot_)van(_dot_)helvoort(_at_)huawei(_dot_)com>
cc
mpls(_at_)ietf(_dot_)org, ietf(_at_)ietf(_dot_)org
Subject
Questions about draft-betts-itu-oam-ach-code-point
Hi Malcolm and Huub,
I have squeezed a little time from the current ITU-T meeting to
look at your
draft and write-up. I have also read the email threads on the
IETF discussion
list and the MPLS list. Sorry that this has taken me a week to
process, but your
publication request came at pretty much the worst possible time
for getting me
to do this task.
I don't like proliferating threads across multiple mailing
lists. On the other
hand it is difficult to ensure that all the constituencies are
present, so I am
perpetuating the cross-posting.
My review of the document...
1. idnits (http://www.ietf.org/tools/idnits/
<http://www.ietf.org/tools/idnits/> ) shows a couple of nits. I think
only one of these is real (the spurious space in a citation).
The other nits are
spurious caused by citations wrapping across lines. Could you
please keep a note
of the nit so that you can fix it the next time the draft is
respun or so it can!
be captured in an RFC Editor Note at a later stage (you don't
have to post a new
revision to address this now unless you really want to).
2. This document requests a code point from a registry that
contains code points
that are used equally for MPLS LSPs and pseudowires. I can't
tell from the I-D
whether it is your intention that your code point would also be
applicable in
both cases. What is your intention? Is this "obvious" from
G.8113.1 or does it
need to be clarified?
My review of the write-up and discussions...
3. There seems to be quite a feeling on the mailing lists that
this document
should be run through the MPLS working group. The write-up
makes a case for
progressing it as AD ! sponsored. As far as I can see, the main
assertions to
answer are as follows. Do you have a view on these points
before I make a
decision on what to do?
a. This is a proposal to use an MPLS code point and so is part
of MPLS by
definition.
b. The type of network being managed by the OAM described in
G.8113.1 is an MPLS
netw ork. Therefore, this is clearly relevant to the MPLS
working .
Do you object to this going through the MPLS on principle, or
were you just
hoping to save the WG the work? If the latter, and if the WG
wants to look at
the draft, the easiest approach seems to be to redirect the
work to the working
group.
4. G.8113.1 is clearly important to understanding to which the
code poin! t is
being put. Thus, an available and stable copy of group.
G.8113.1 will be key to
the last call review of you I-D. Can you make a stable copy
available (for
example, through liaison)? How does the editing work currently
in progress in
the SG15 meeting affect that availability?
5. Can you clarify for me why the suggested value has been
suggested. This will!
help guide IANA who would normally do their allocation in a
"tidy" way.
Looking forward to your reply.
Thanks,
Adrian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
<https://www.ietf.org/mailman/listinfo/ietf>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________Ietf mailing list
Ietf@ietf! .org <mailto:Ietf(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf