[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Editorial comment about draft-ietf-ccamp-lsp-dppm-00.txt
Many thanks for the thorough comments. We will get them fixed one by one and
post it again.
From: Adrian Farrel [mailto:firstname.lastname@example.org]
Sent: Wednesday, April 09, 2008 4:08 AM
Subject: Editorial comment about draft-ietf-ccamp-lsp-dppm-00.txt
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
s/ccamp/Network Working Group/
(This is for obscure historic reasons :-)
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)".
s/for the future data transmission/for future data transmission/
s/in metro area/in metro areas/
s/This draft intends to define/This document defines/
s/The metrics defined in this draft/The metrics defined in this document/
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
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
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
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