RE: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Dave, could you be more precise about what you think the utility of this document is in this particular situation. I mean, what will its effect be in the current situation. What will change after this document has been published. It seems everybody believes the situation will be resolved once this document receives its RFC number. I cannot see that. Could you give me more detail? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of David Allan I Sent: Donnerstag, 6. Oktober 2011 01:05 To: ietf@ietf.org; m...@ietf.org Subject: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam- considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC I think it is unfortunate that we are in a situation where such a document has utility. But ultimately it does. Therefore I support the publication of draft-sprecher... D MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the two solutions problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
While it is not perfect, I too support publication... W On Oct 5, 2011, at 7:11 PM, David Sinicrope wrote: I concur with Dave's comment and support publication of the draft. Dave On Oct 5, 2011, at 7:06 PM, David Allan I david.i.al...@ericsson.com wrote: I think it is unfortunate that we are in a situation where such a document has utility. But ultimately it does. Therefore I support the publication of draft-sprecher... D MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the two solutions problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Hi all, I concur with both parts of Dave's message :-( and support publication of the draft. I have an editorial/factual comment regarding Section 4.2 of the draft. Let's begin with the fact that SAToP (i.e. RFC 4553) is not a Draft Standard, it is a Proposed Standard RFC. Further, I am not sure that the relationship between SAToP and other TDM PW modes - CESoPSN (RFC 5086) and TDMoIP (RFC 5087) - is correctly described in Section 4.2 of the draft. At least neither RFC 5086 not RFC 5087 contain any explicit statements about SAToP as the MUST to implement protocol. My 2c, Sasha From: mpls-boun...@ietf.org [mpls-boun...@ietf.org] On Behalf Of David Allan I [david.i.al...@ericsson.com] Sent: Thursday, October 06, 2011 1:05 AM To: ietf@ietf.org; m...@ietf.org Subject: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC I think it is unfortunate that we are in a situation where such a document has utility. But ultimately it does. Therefore I support the publication of draft-sprecher... D MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the two solutions problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
IMO it is a statement of principle going forward. As such it does not fix or make go away the current situation, but it would be an IETF consensus position on a way forward. And I agree with that position. Lots of folks do proprietary deployments, squat on code points etc. That cannot be fixed either, but I do not believe in rewarding it. Dave -Original Message- From: Rolf Winter [mailto:rolf.win...@neclab.eu] Sent: Friday, October 07, 2011 6:39 AM To: David Allan I; ietf@ietf.org; m...@ietf.org Subject: RE: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC Dave, could you be more precise about what you think the utility of this document is in this particular situation. I mean, what will its effect be in the current situation. What will change after this document has been published. It seems everybody believes the situation will be resolved once this document receives its RFC number. I cannot see that. Could you give me more detail? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of David Allan I Sent: Donnerstag, 6. Oktober 2011 01:05 To: ietf@ietf.org; m...@ietf.org Subject: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam- considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC I think it is unfortunate that we are in a situation where such a document has utility. But ultimately it does. Therefore I support the publication of draft-sprecher... D MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the two solutions problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
IMO it is a statement of principle going forward. As such it does not fix or make go away the current situation, but it would be an IETF consensus position on a way forward. And I agree with that position. Lots of folks do proprietary deployments, squat on code points etc. That cannot be fixed either, but I do not believe in rewarding it. or aiding or abetting it. +1 randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
As do I -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of David Sinicrope Sent: Wednesday, October 05, 2011 7:11 PM To: David Allan I Cc: m...@ietf.org; ietf@ietf.org Subject: Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam- considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC I concur with Dave's comment and support publication of the draft. Dave On Oct 5, 2011, at 7:06 PM, David Allan I david.i.al...@ericsson.com wrote: I think it is unfortunate that we are in a situation where such a document has utility. But ultimately it does. Therefore I support the publication of draft-sprecher... D MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the two solutions problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Yes/support Regards, Jeff MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the two solutions problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: major unresolved technical concerns Alessandro Please can I suggest that you write an internet draft detailing these major unresolved technical concerns so that we can all understand them. Such a draft needs to be technical, and describe the actions that the network operator is unable to perform, or the fault cases that they are unable to diagnose using the OAM defined in the IETF RFCs, or late stage WG drafts. Alternatively if you are referring to a bug in the MPLS-TP OAM protocols, you need to tell the community what it is. I believe that this request has been made a number of times, in various forums, and, as far as I know, no document has yet been produced. An argument of the form you must standardize what I want will not fly. What is needed is a very clear technical definition of the issue(s). When we have the major unresolved technical concerns on the table, we will be in a position to determine the best disposition of those issues. Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Alessandro, Stewart and all, I concur with Stewart: please write a draft detailing your major technical concerns. I'd like to add a quote from Malcolm's presentation at the IETF meeting in Prague: Differences between the solution approved by the IETF and its ITU-T sponsored alternatives - Sasha are close to invisible at the level of the requirements in RFC5860. Just to remind you that RFC 5680 is the MPLS-TP OAM requirements document. Malcolm has also said: Many of the issues only become apparent when the protocol and equipment behavior isexplored but, AFAIK, these issues have never been explicitly brought for the consideration. My 2c, Sasha -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, October 05, 2011 12:24 PM To: D'Alessandro Alessandro Gerardo Cc: ietf@ietf.org; m...@ietf.org Subject: Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam- considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: major unresolved technical concerns Alessandro Please can I suggest that you write an internet draft detailing these major unresolved technical concerns so that we can all understand them. Such a draft needs to be technical, and describe the actions that the network operator is unable to perform, or the fault cases that they are unable to diagnose using the OAM defined in the IETF RFCs, or late stage WG drafts. Alternatively if you are referring to a bug in the MPLS-TP OAM protocols, you need to tell the community what it is. I believe that this request has been made a number of times, in various forums, and, as far as I know, no document has yet been produced. An argument of the form you must standardize what I want will not fly. What is needed is a very clear technical definition of the issue(s). When we have the major unresolved technical concerns on the table, we will be in a position to determine the best disposition of those issues. Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
回复： [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Dear all, So many multiple solution cases just show the way that the world and technology works. Killing a solution roughly brings more damage to the industry. Section 3.6 discusses the elements of the choice of solutions. Current application and deployment should be considered. In China Mobile, more than 330,000 PTN box are/will based on G.8113.1. TDM PW gives a good example. G.8113.1 based OAM is relative simple and mature and widely deployed and should be the standard. Best regards, Han Li --- 11年10月5日，周三, D'Alessandro Alessandro Gerardo alessandro.dalessan...@telecomitalia.it 写道： 发件人: D'Alessandro Alessandro Gerardo alessandro.dalessan...@telecomitalia.it 主题: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC 收件人: adr...@olddog.co.uk adr...@olddog.co.uk, m...@ietf.org m...@ietf.org, ietf@ietf.org ietf@ietf.org 日期: 2011年10月5日,周三,下午5:38 Dear all, I do not support. Basically I think it is superfluous dedicate an RFC to state it is better having one standard instead of two ones or many... for sure the lower are the variants the better is for the industry (one is the ideal). When two or more standards or de-facto standards exist it is because the problem they solve is not exactly the same, the way they solve the problem is optimized for different environments/boundary conditions (more efficient, more effective, etc). Therefore a single solution does not necessarily meet the different market requirements. It is fundamental to enter into the problem's details before making consideration about the best way to proceed (one solution, two solutions, multiple solutions) whilst the document clearly declares it does not want to make any technical evaluations. After more than three years of debates within the IETF and major unresolved technical concerns risen from some transport operators, the existence of this draft is by itself the sure sign that MPLS-TP OAM is a case where a single solution has not be found to meet all the different market requirements. Otherwise, why are we still discussing about it? Therefore we must be realistic and the lessons learned from the past should guide our decisions: if a solution cannot be found for satisfying all the requirements it is better to have two standards and let the market decide how to exploit them. Are we really sure the cost(many) / benefit (none) analysis done in section 7.5 is realistic? Best regards, Alessandro -- Telecom Italia Alessandro 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: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] Per conto di Adrian Farrel Inviato: lunedì 26 settembre 2011 23:58 A: m...@ietf.org Oggetto: [mpls] FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the two solutions problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: 26 September 2011 20:43 To: IETF-Announce Subject: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' draft-sprecher-mpls-tp-oam-considerations-01.txt as an Informational
R: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Dear Stewart, Many thanks for your answer that anyway I do not believe addresses the root concern I have on the proposed draft. I would avoid bringing technical discussions into this thread because it is a declared intent of the draft in the object to NOT touch such aspects. I'm therefore going to answer you on a different thread. Best regards, Alessandro -- Telecom Italia Alessandro 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: Stewart Bryant [mailto:stbry...@cisco.com] Inviato: mercoledì 5 ottobre 2011 12:24 A: D'Alessandro Alessandro Gerardo Cc: adr...@olddog.co.uk; m...@ietf.org; ietf@ietf.org Oggetto: Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: major unresolved technical concerns Alessandro Please can I suggest that you write an internet draft detailing these major unresolved technical concerns so that we can all understand them. Such a draft needs to be technical, and describe the actions that the network operator is unable to perform, or the fault cases that they are unable to diagnose using the OAM defined in the IETF RFCs, or late stage WG drafts. Alternatively if you are referring to a bug in the MPLS-TP OAM protocols, you need to tell the community what it is. I believe that this request has been made a number of times, in various forums, and, as far as I know, no document has yet been produced. An argument of the form you must standardize what I want will not fly. What is needed is a very clear technical definition of the issue(s). When we have the major unresolved technical concerns on the table, we will be in a position to determine the best disposition of those issues. Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
I concur with Dave's comment and support publication of the draft. Dave On Oct 5, 2011, at 7:06 PM, David Allan I david.i.al...@ericsson.com wrote: I think it is unfortunate that we are in a situation where such a document has utility. But ultimately it does. Therefore I support the publication of draft-sprecher... D MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the two solutions problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
