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

["Adrian Farrel" <adrian@olddog.co.uk>]

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.