Subject: [CCAMP] DPPM draft updated

From: "Weiqiang Sun" <[email-masked]>
Date: Thu, 9 Jul 2009 17:04:52 +0800

Hello Lou and CCAMP,

We have updated the dppm draft (draft-ietf-ccamp-lsp-dppm) according to the LC comments and the off-the-list dicussions between Lou and the authors.
A new version is now available at: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-06.txt
Many thanks to Lou for the comments and help.

The comments and our changes are summarized below. Please let us know if you have further comments/concerns.

==========[LC comments]===========
-As the draft is listed as a "Standards Track" document it needs to
   include some formal conformance language.  For a minimal example, see
   RFC2681's usage of RFC2119 language.  I think your choices are either
   make this document Informational or add the conformance language.

[Changes]
We have added formal language at the points where we think applicable. 

==========[LC comments]===========
- As always, please cleanup any idnits identified issues.

[Changes]
All nits have been resolved.

==========[LC comments]===========
- In general it seems to me that for the performance metrics to be
   complete and fully useful a metric that quantifies data path
   availability relative to connection request and establishment is
   required.  In section 15 you do say:
   ...
   But I really don't think this is sufficient, and feel that data path
   metric parameters and related methodologies needs to be added to
   each of metrics/test cases.  If you'd like to indicate that
   these are OPTIONAL metric parameters, that is fine with me.
   But, IMO, the document is incomplete without them.  I have
   heard from others that they agree with this point too.  (I can
   try to get them to speak up publicly if this turns out to be
   necessary.)

[Changes] 
We have composed another draft and added a reference in this document.
(draft-sun-ccamp-dpm-00.txt)
The draft has been posted on the list and will be presented in Stockholm.

==========[LC comments]===========
- In the tests you treat all failures as an "undefined" result.  It
   seems to me that it would be more useful to identify and track
   (i.e., count) specific types of errors rather than just define
   all errors as "undefined" metrics.

[Changes]
We removed section "13. Discussion for unsuccessful setup/release cases"
in the original text and added a sub-section in section 14:
"14.4.  Failure statistics of Metric"
And also, in the metrics definition sections, we also added a referencing paragraph:
Eg.,
   The undefined value of this metric indicates an event of Single Uni-
   directional LSP Setup Failure, and would be used to report a count or
   an percentage of Single Uni-directional LSP Setup failures.  See
   section Section 14.4 for definitions of LSP setup/release failures.

==========[LC comments]===========
- The document should be run through a spell checker, there are
   a number of spelling errors.

[Changes]
A considerable number of spelling errors have been corrected :)

Thanks and best regards,
-authors