The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2004-Mar> msg00104



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Comments about draft-ietf-mpls-oam-requirements-02.txt

  • From: "Thomas D. Nadeau" <tnadeau@cisco.com>
  • Date: Tue, 23 Mar 2004 12:00:15 -0500
  • Cc: <bwijnen@lucent.com>, <swallow@cisco.com>, <loa@pi.se>, <fenner@research.att.com>, <zinin@psg.com>, <mmorrow@cisco.com>, <dallan@nortelnetworks.com>, <satoru@ft.solteria.net>
  • Importance: Normal
  • Organization: Cisco Systems

Title: Message
 
    HI Dan,
 
    Thanks for reviewing.  I will take your comments into account
when I do edits to the draft this week.
 
    --Tom
 
 
-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Sunday, March 21, 2004 12:06 AM
To: mpls@uu.net
Cc: bwijnen@lucent.com; swallow@cisco.com; loa@pi.se; fenner@research.att.com; zinin@psg.com; tnadeau@cisco.com; mmorrow@cisco.com; dallan@nortelnetworks.com; satoru@ft.solteria.net
Subject: Comments about draft-ietf-mpls-oam-requirements-02.txt

Bert asked me to have a look and send any relevant comments concerning draft-ietf-mpls-oam-requirements-02.txt.

I think that in general lines the document meets its goals. There are however still issues that impact the document quality and  need to be corrected before the document is further advanced.

Content-related comments:

1. The phrase in the Introduction - 'This memo does not, in its draft form, specify a standard' what is this supposed to mean? No I-D is a standard, but after approval will this be an Informational RFC? (not a 'standard'. In any case this phrase should be out.

2. The document uses as references several expired Internet-Drafts. This is not acceptable, and the references should be either updated, or eliminated. By the time the document will be approved as RFC, all these references also need to be RFCs, otherwise the document will be hold until normative dependencies are being resolved.

3. Section 3.1 - examples of positive and negative false results of ICMP need to be provided in a clear manner.

4. Should not the document say something about relationship with OAM at other layers, and with the work being done in the ITU, and MEF?

5. Section 3.3 is quite unclear. There is no requirement here, but a list of functions, some of them not very clear as well. For example what means 'data/control plane OAM capabilities of the LSR' and why is this part of the path characterization?

6. Are 'Error detection and recovery' OAM functions, or rather functions enabled by OAM?

7. I think that the security consideration section should include considerations related to authentication of nodes on the path, as well as about possible denial of service attacks by generation of OAM traffic

8. As the Security section mentions privacy concerns, should not the requirements mention explicitly that the option of protecting the traffic by using encryption is REQUIRED?



Editorial comments:

1. The I-D nits recommends to avoid using references in the Abstract section

2. Also in the Abstract - the acronyms VPN, SLA, and ATM are not explained, and MPLS has an occurrence before it is detailed

3. References must be split into normative and informative sections

4. There are two sections numbered as Sections 3

5. As this is a requirements document, use of key-words, and reference to RFC 2119 would be appropriate.

6. Section 3.1, paragraph 4 - broken syntax

7. The formatting of the document needs to be improved. For example, spacing between paragraphs is not consistent.





If you want to include me in further discussions, please address directly the mails to me. I have un-subscribed from the mpls wg list a while ago.

Regards,

Dan