RE: Last Call: Modern Global Standards Paradigm

2012-08-11 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
I support the IETF and IAB chairs signing the document, Nurit -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Adrian Farrel Sent: Saturday, August 11, 2012 12:38 AM To: 'IETF'; 'IAB'; 'IETF-Announce' Subject: RE: Last Call: Modern Global

RE: So, where to repeat? (was: Re: management granularity)

2012-08-09 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Istanbul, Dubai, and similar places will not allow all of us in the community to participate in the meetings -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Munich) Sent: Thursday, August 09, 2012 11:20 PM To: ext

RE: So, where to repeat? (was:Re: management granularity)

2012-08-08 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
+1 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Yoav Nir Sent: Wednesday, August 08, 2012 9:07 PM To: Geoff Mulligan Cc: Carsten Bormann; ietf@ietf.org Subject: Re: So, where to repeat? (was:Re: management granularity) Mileage varies.

RE: So, where to repeat? (was: Re: management granularity)

2012-08-07 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Why the survey should limit it to the last five meetings... In the long history we experienced additional good places So maybe the survey should be more open and let each list his 3-5 favorable places based on the experience from earlier meetings? Best regards, Nurit -Original

RE: So, where to repeat? (was:Re: management granularity)

2012-08-06 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Oslo? -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Daniele Ceccarelli Sent: Monday, August 06, 2012 3:24 PM To: Andrew Sullivan; ietf@ietf.org Subject: RE: So, where to repeat? (was:Re: management granularity) Dublin panned? I thought it

RE: So, where to repeat? (was:Re: management granularity)

2012-08-06 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
When you are not close (time), flight cost may become higher in the priority (over hotem) Flying to Vancouver for me for example is the most expensive tripeven though the city is amazing and the host was wonderful! -Original Message- From: ietf-boun...@ietf.org

FW: I-D Action: draft-sprecher-mpls-tp-oam-considerations-03.txt

2012-04-30 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Hi, Please note the new version of draft-sprecher-mpls-tp-oam-consideration (03) that was just submitted. In this version we attempted to satisfy the Last Call comments we got. Diffs can be used to see the changes from version 01

RE: Last Call: draft-ietf-mpls-tp-oam-analysis-08.txt (AnOverviewoftheOAM Tool Set for MPLS based Transport Networks) toInformational RFC

2012-03-25 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
(AnOverviewoftheOAM Tool Set for MPLS based Transport Networks) toInformational RFC Hallo Nurit, I will *not* change my mind. So it is useless to continue this thread. Just make the changes I requested. Regards, Huub. == On 23-03-12 08:11, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote: Huub hi

RE: Last Call: draft-ietf-mpls-tp-oam-analysis-08.txt (An Overviewofthe OAM Tool Set for MPLS based Transport Networks) toInformational RFC

2012-03-23 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Huub hi, The document went through two WG last calls...it is a pity you did not use the opportunity to provide your useful comment then. I am surprised that it took you almost two years and seven revisions of the document before you actually realized you are not happy with the way we acknowledged

RE: Last Call: draft-ietf-mpls-tp-oam-analysis-08.txt (An Overviewof the OAM Tool Set for MPLS based Transport Networks) toInformational RFC

2012-03-22 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Huub hi, Thanks for your comments to IESG... We can easily remove your name from the acknowledgement section. We put you there upon your request! I am sorry that I am going to share on the list a private mail from you to me but I can see no other choice with the mail you have just sent to the

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

2012-03-21 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
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

RE: Last Call:draft-betts-itu-oam-ach-code-point-03.txt(Allocationofan Associated Channel Code Point for Use by ITU-T EthernetbasedOAM) to Informational RFC

2012-03-20 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
. Nurit -Original Message- From: ext t.petch [mailto:daedu...@btconnect.com] Sent: Tuesday, March 20, 2012 10:15 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbry...@cisco.com Cc: ietf@ietf.org Subject: Re: Last Call:draft-betts-itu-oam-ach-code-point-03.txt(Allocationofan Associated

RE: Last Call:draft-betts-itu-oam-ach-code-point-03.txt(Allocationofan Associated Channel Code Point for Use by ITU-T EthernetbasedOAM) to Informational RFC

2012-03-18 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Tom, Did Huub and Malcolm represent the ITU in their assessments? I guess other ITU members have different view on this! Best regards, Nurit -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext t.petch Sent: Friday, March 16, 2012 5:06 PM To:

RE: Last Call: draft-betts-itu-oam-ach-code-point-03.txt(Allocationof anAssociated Channel Code Point for Use byITU-T Ethernet based OAM) toInformational RFC

2012-03-14 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Jian hello, I would warmly recommend you not to mention the collaboration on MPLS-TP. According to the collaborative agreement between the organziations we were supposed to see a single solution developed in the IETF using the IETF processess... The developmenet of an alternative solution in the

RE: הנדון: RE: Last Call:draft-betts-itu-oam-ach-code-point-03.txt(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC

2012-03-14 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
future extensions beyond the purpose of the code point allocation? Best regards, Nurit מאת: ietf-boun...@ietf.org בשם Sprecher, Nurit (NSN - IL/Hod HaSharon) נשלח: ג 13/03/2012 20:09 אל: Andrew G. Malis; ext Ross Callon עותק לידיעה: ietf@ietf.org נושא: הנדון: RE

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

2012-03-14 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
refinements to G.8113.1 such that it could satisfy all the functional requirements defined in RFC 5860. -? ??- ???: ext Ross Callon : 13/03/2012, 19:27 ??: Andrew G. Malis; Sprecher, Nurit (NSN - IL/Hod HaSharon) : ietf@ietf.org : RE: Last Call:draft-betts-itu-oam-ach-code

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

2012-03-14 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
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: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Loa Andersson Sent: Monday, March 12,

הנדון: 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

2012-03-13 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
of the recommendation and they will use the same code point that is allocated for the first version. This is a real issue. Regards, Nurit -הודעה מקורית- מאת: ext Ross Callon נשלח: 13/03/2012, 19:27 אל: Andrew G. Malis; Sprecher, Nurit (NSN - IL/Hod HaSharon) עותק: ietf@ietf.org נושא: RE

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

2012-03-03 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:ietf-boun...@ietf.org] On Behalf Of Russ Housley Sent: Thursday, March 01, 2012 3:52 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc: IETF 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

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

2012-03-01 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Great! -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Kyung-Yeop Hong (hongk) Sent: Thursday, March 01, 2012 5:14 PM To: ietf@ietf.org Subject: Re: Last Call: draft-betts-itu-oam-ach-code-point-03.txt(Allocation of an Associated Channel Code

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

2012-03-01 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
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

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

2012-03-01 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
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.

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

2012-03-01 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Hi Russ, I am not K.Y., but to me it seems at the moment as a very theoretical question. If the G.8113.1 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

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

2012-03-01 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Russ, Independently of that point, draft-betts in its current version has many issues Many clarifications are needed before it can be consideredplease see my mail for the details. Best regards, Nurit -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On

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

2012-03-01 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
be defined in future versions of G.8113.1. Best regards, Nurit --- -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: Thursday, March 01, 2012 8:07 PM To: ext Russ Housley; Loa Andersson Cc: ietf@ietf.org

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

2012-03-01 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
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.

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

2012-03-01 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Russ, I propose to simply re-discuss it when and IFF G.8113.1 is mature and approved... Best regards, Nurit -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Russ Housley Sent: Thursday, March 01, 2012 9:12 PM To: IETF Subject: Re: Last

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

2012-01-12 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Hi, I fully agree with John and Tom. G.8113.1 intends to provide an OAM solution for MPLS-TP networks and the discussion on your draft completely belongs in the MPLS WG and also in the PWE3 WG. Two more points: * Malcolm, you say that that the requested code point is not limited to

RE: New Liaison Statement, LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN)

2012-01-11 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Support -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Scott Mansfield Sent: א 08 ינואר 2012 15:53 To: ietf@ietf.org; m...@ietf.org; p...@ietf.org; cc...@ietf.org Cc: swal...@cisco.com; stbry...@cisco.com; adr...@olddog.co.uk;

RE: [CCAMP] New Liaison Statement, LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance mechanism for MPLS-TP in PacketTransport Network (PTN)

2012-01-09 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
When saying support, I mean of course that I fully support the proposal of Scott! -Original Message- From: ccamp-boun...@ietf.org [mailto:ccamp-boun...@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: ב 09 ינואר 2012 19:20 To: ext Scott Mansfield; ietf@ietf.org; m

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

2011-12-21 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
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-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Huub helvoort Sent: Wednesday,

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

2011-12-21 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
and judge it… Best regards, Nurit From: ext HUANG Feng F [mailto:feng.f.hu...@alcatel-sbell.com.cn] Sent: Wednesday, December 21, 2011 1:29 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc: ext Huub helvoort; Russ Housley; malcolm.be...@zte.com.cn; ietf-boun...@ietf.org; draft-betts-itu-oam-ach

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

2011-12-21 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
HUANG Feng F [mailto:feng.f.hu...@alcatel-sbell.com.cn] Sent: Wednesday, December 21, 2011 1:59 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc: ext Huub helvoort; Russ Housley; malcolm.be...@zte.com.cn; ietf-boun...@ietf.org; draft-betts-itu-oam-ach-code-po...@tools.ietf.org; ietf@ietf.org; m

RE: Request to publish draft-betts-itu-oam-ach-code-point-01.txt

2011-12-03 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Hi, I fully support Stewart! G.8113.1 proposes a OAM solution for MPLS-TP networks. It uses the MPLS EtherType (when transmitted inband and getting the same treatment as the data traffic). The document is built on G.8110.1 (MPLS-TP architecture) which refers to G.8110 (MPLS architecture), and

RE: Request to publish draft-betts-itu-oam-ach-code-point-01.txt

2011-12-03 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
note that the proposed solution is the same as draft-bhh-mpls-tp-oam-y1731-07 that was discussed in the MPLS WG. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: Saturday, December 03, 2011 6:07 PM

RE: Request to publish draft-betts-itu-oam-ach-code-point-01.txt

2011-12-03 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbry...@cisco.com; Adrian Farrel Cc: iesg; ietf Subject: Re: Request to publish draft-betts-itu-oam-ach-code-point-01.txt - Original Message - From: Sprecher, Nurit (NSN - IL/Hod HaSharon) nurit.sprec...@nsn.com To: stbry...@cisco.com; Adrian

RE: Requirement to go to meetings

2011-10-23 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Both Minneapolis and Phoenix have huge conference facilities, are easy to go to, and can get cheap off-season discount For whom? For me it is much cheaper and easier to go to Europe:-( From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Ping Pan Sent: Sunday,

RE: Requirement to go to meetings

2011-10-23 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
AND DC. ALso places where you need an extra hop to get there. /Loa On 2011-10-23 09:43, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote: Both Minneapolis and Phoenix have huge conference facilities, are easy to go to, and can get cheap off-season discount For whom? For me it is much cheaper

RE: ITU-T Beijing meeting [Was: Re: Last Call:draft-sprecher-mpls-tp-oam-considerations-01.txt(The Reasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC]

2011-10-10 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Huub, You say The liaison informs the IETF that on September 16 recommendation G.8113.2 was consented in a WP3 plenary meeting. In both the Beijing Q10 expert meeting where the consent was proposed and the WP3 plenary meeting where the consent took place, there were no objections. My

RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt(Proactive Connectivity Verification, Continuity Check and Remote Defectindication for MPLS Transport Profile) to Proposed Standard

2011-07-14 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Rui, I kindly propose not to refer in this context to the Feb2011 WP3 and SG15 plenary meetings Very unfortunately, it was far away from being a technical discussion.or technical poll. Therefore it cannot be a reference to any argument in this context. Regards, Nurit -Original

RE: [mpls] LastCall: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard

2011-07-08 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Hi, Just to make it clear, this is not a discussion on the requirements. I would like to encourage this kind of discussion but in the right context. The CC-CV-RDI draft aims to satisfy the OAM requirements which are specified in RFC 5860. One of the requirements there is to provide a tool for CC

RE: [mpls] R: Re: LastCall: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard

2011-07-07 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Erminio, I do not think the history is relevant for this specific discussion... Also I find it inappropriate to give statements with no justifications behind. You say: the solution in this draft is useless for many MPLS-TP deployments.. in order to seriously consider your comment, you have to

RE: [mpls] R: Re: LastCall: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard

2011-07-07 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Erminio, I do not think the history is relevant for this specific discussion... Also I find it inappropriate to give statements with no justifications behind. You say: the solution in this draft is useless for many MPLS-TP deployments.. in order to seriously consider your comment, you have to

RE: Has anyone found a hotel for Quebec City that isn't exorbitant?

2011-06-20 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Same in my case! -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Thomas Nadeau Sent: Monday, June 20, 2011 8:26 PM To: John E Drake Cc: Henk Uijterwaal; ietf@ietf.org Subject: Re: Has anyone found a hotel for Quebec City that isn't

RE: My comments to the press about OAM for MPLS

2011-03-07 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
regards, Nurit -Original Message- From: ext Worley, Dale R (Dale) [mailto:dwor...@avaya.com] Sent: Monday, March 07, 2011 5:10 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Huub van Helvoort; Brian E Carpenter Cc: IETF Subject: RE: My comments to the press about OAM for MPLS Given

RE: My comments to the press about OAM for MPLS

2011-03-05 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
The IETF MPLS-TP design team has successfully achieved its objectives. The main requirements work were published and the two subsidiary requirements documents (NM and OAM) were close to publication. The core work on the frameworks and solutions has started and were progressing. It was just

RE: My comments to the press about OAM for MPLS

2011-03-03 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Huub, Good that you mention that you were part of the design team! That is correct. You were also part of the team that worked in the face-to-face MEAD team meeting in Stockholm, July 2009, on the design and the technical direction for OAM in MPLS-TP. You were part of the team that presented the

Re: IAB/IESG Joint Design Session on Forwarding Plane Operations, A dministration and Maintenance

2010-08-26 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Hi, I am NOT happy with the new date and would like to ask to keep the original proposed date. Best regards, Nurit --- הודעה מקורית --- מאת: ext Marshall Eubanks t...@americafree.tv נושא: Re: IAB/IESG Joint Design Session on Forwarding Plane Operations,Administration and Maintenance תאריך: 26

RE: [mpls] Last Call: draft-ietf-mpls-tp-survive-fwk (MultiprotocolLabel Switching Transport Profile Survivability Framework)to Informational RFC

2010-05-06 Thread Sprecher, Nurit (NSN - IL/Hod HaSharon)
Dear Eve, Thanks for your review. I think you are actually right. We cannot say that the protocol is (already) defined. But we should indicate that such a protocol should be defined as part of the work on linear protection. We will fix the text accordingly. Best regards, Nurit From: