RE: Questions about draft-betts-itu-oam-ach-code-point

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.f.Huang@xxxxxxxxxxxxxxxxxxxx] 
Sent: Wednesday, December 21, 2011 1:29 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Huub helvoort; Russ Housley; Malcolm.BETTS@xxxxxxxxxx; ietf-bounces@xxxxxxxx; draft-betts-itu-oam-ach-code-point@xxxxxxxxxxxxxx; ietf@xxxxxxxx; mpls@xxxxxxxx; adrian@xxxxxxxxxxxx
Subject: Re: Questions 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.sprecher@xxxxxxx> 写道:

	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@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of ext Huub helvoort
	Sent: Wednesday, December 21, 2011 12:51 PM
	To: Russ Housley; Malcolm.BETTS@xxxxxxxxxx
	Cc: ietf-bounces@xxxxxxxx; adrian@xxxxxxxxxxxx; draft-betts-itu-oam-ach-code-point@xxxxxxxxxxxxxx; ietf@xxxxxxxx; mpls@xxxxxxxx
	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.BETTS@xxxxxxxxxx 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 probably 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@xxxxxxxxxxxx> 
Sent by: ietf-bounces@xxxxxxxx 

09/12/2011 05:49 AM 

Please respond to
adrian@xxxxxxxxxxxx

To

<draft-betts-itu-oam-ach-code-point@xxxxxxxxxxxxxx>, "'Huub helvoort'" <huub.van.helvoort@xxxxxxxxxx> 

cc

mpls@xxxxxxxx, ietf@xxxxxxxx 

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
	network. 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 point 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@xxxxxxxx
	https://www.ietf.org/mailman/listinfo/ietf <https://www.ietf.org/mailman/listinfo/ietf> 
	
	
	_______________________________________________
	Ietf mailing list
	Ietf@xxxxxxxx
	https://www.ietf.org/mailman/listinfo/ietf

	 

	_______________________________________________
	Ietf mailing list
	Ietf@xxxxxxxx
	https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]