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-14 Thread Rolf Winter
Having thought about this for some time, I think I concur with Russ' reasoning and the allocation should be made. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org

RE: Last Call draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

2011-10-13 Thread Rolf Winter
How does the IETF put a big red warning sign on a document produced by another standards body? http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-07. Actual coloring of course is impossible. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in

RE: Last Call draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

2011-10-11 Thread Rolf Winter
Hi, This is good input and made me realize what I disliked in the document which made me oppose to its publication. People (rightfully) pressed on the significance of the document to be about a general principle - one solution to any given problem. The IETF, _without_ external help, has a

RE: Last Call draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

2011-10-11 Thread Rolf Winter
Ross, See inline. This is not actually correct. The IETF has a very long history of pushing back on multiple redundant solutions to the same problem. There are a great many cases of ADs, working group chairs, and others pushing quite hard to prevent multiple solutions when one would work

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

2011-10-07 Thread Rolf Winter
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

RE: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

2011-10-05 Thread Rolf Winter
Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: Loa Andersson [mailto:l...@pi.nu] Sent: Mittwoch, 5. Oktober 2011 12:48 To: ietf@ietf.org; Rolf Winter Subject: Re: Last Call: draft-sprecher-mpls-tp-oam-considerations- 01.txt

RE: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

2011-10-05 Thread Rolf Winter
use of our time. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: Loa Andersson [mailto:l...@pi.nu] Sent: Mittwoch, 5. Oktober 2011 13:51 To: Rolf Winter Cc: ietf@ietf.org Subject

RE: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

2011-10-05 Thread Rolf Winter
of the statements that caused dispute on the list. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Rolf Winter Sent

RE: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

2011-10-04 Thread Rolf Winter
Hi, I think Brian makes an excellent point here. RFC 1958 already contains exactly the same basic message (just with far less (unnecessary) words). I don't think we need this document as it doesn't really add anything to what RFC 1958 says. I'll provide a more detailed review later. Best,

RE: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLS On-demand Connectivity Verification and Route Tracing) to Proposed Standard

2011-08-18 Thread Rolf Winter
Hi, I have made this comment before, I just want to make sure it is not lost. This draft is proposing a way to specify the length of sub-TLVs that is inconsistent with RFC 4379. I believe it would be better to align this with 4379 as the draft is updating it and I see no technical reason why

tsv-dir review of draft-ietf-pwe3-fat-pw-06

2011-05-19 Thread Rolf Winter
Hello, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any

tsv-dir review of draft-ietf-netconf-4741bis-07

2011-02-04 Thread Rolf Winter
Hi, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any

tsv-dir review of draft-baker-ietf-core-11

2011-01-03 Thread Rolf Winter
Hi, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any