RE: Editorial comment about draft-ietf-ccamp-lsp-dppm-00.txt

["Weiqiang Sun" <sunwq@sjtu.edu.cn>]

Hi Adrian,

Many thanks for the thorough comments. We will get them fixed one by one and
post it again.

Best regards,

Weiqiang

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk] 
Sent: Wednesday, April 09, 2008 4:08 AM
To: sunwq@sjtu.edu.cn
Cc: ccamp@ops.ietf.org
Subject: Editorial comment about draft-ietf-ccamp-lsp-dppm-00.txt

Hi,

Here are some editorial comments for your draft. These changes will help 
your draft through the IETF process and will make it easier to review for 
others.

Cheers,
Adrian

===
Document header

s/ccamp/Network Working Group/
(This is for obscure historic reasons :-)

===
Author list

You need to reduce to a list of no more than four authors listed on the
front page. Others can continue to be listed in the section at the end
of the draft. There are two ways to handle this:
1. If some of the authros are doing most of the work, keep them on the
   front page, but remove the others.
2. If one or two people are editing the work done by the rest of the
   team, leave them on the frint page and mark them as "(Editor)".

===
Document title

s/Dynamical/Dynamic/

===
Abstract

s/for the future data transmission/for future data transmission/
s/The GMPLS/GMPLS/
s/cooperate/operate/
s/in metro area/in metro areas/

===

1.  Introduction
s/cooperate/operate/
s/This draft intends to define/This document defines/
s/The metrics defined in this draft/The metrics defined in this document/

===
1.  Introduction

   For example, an new object can be added to
   the GMPLS TE STD MIB [RFC4802] such that the current and past control
   plane performance can be monitored through network management
   systems.  The extension of TE-MIB to support the metrics defined is
   out the scope of this document.
I think that technically you cannot add objects to a defined MIB module,
but you can define extensions to a MIB module to contain new objects.

===
2.  Conventions Used in This Document

I don't think you need this text as you do not use any of the formal
language.

===
3.  Overview of Performance Metrics

I would like to see a little more introduction to what we are going to
get in sections 4 to 8, and then 9 through 12. in other words, an
overview of what is coming later so that I can navigate the rest of the
document a little more easily.

===
4.  A Singleton Definition for single unidirectional LSP Setup Delay

Can you make all section headings use captials. For example,

4.  A Singleton Definition for Single Unidirectional LSP Setup Delay

===
14.  Discussion
s/But in the draft/But in this document/

===
15.  Security Considerations

This section is a little thin!

Could the information you propose to collect be used to facilitate
attacks? For example by identifying weak spots in the network.

Could the collection of information impact the operation of the
network? If this is the case, requesting that performance behavior
is monitored and reported could be used to attack the network.

===
You are missing an IANA section.

This can simply say...

X. IANA Considerations

   This document makes no requests for IANA action.

===
17.  Normative References

[RFC2119]
You might not need this any more if you delete Section 2.

[RFC2330] This is an Informational RFC. If you can, you should make
it an Informative Reference. This is not absolutely required - if you
believe it really is normative (i.e., your document cannot be read
without reference to this RFC) then it is OK to keep it as a
Normative Reference.