Document: draft-ietf-pce-monitoring-04.txt
Reviewer: Francis Dupont
Review Date: 2009-04-22
IETF LC End Date: 2009-04-27
IESG Telechat date: unknown

Summary: Not Ready

Major issues: none but some minor issues which should need another cycle.

Minor issues:
 - 1 page 5: as the PCReq/PCReq seem to come from nowhere in 3.1 page 8  IMHO it is the right place to introduce them, for instance (it should  be hard to be simpler) add after the first "path computation request"
 the comment "(PCReq message)". Perhaps this is not the right thing  but it should be clear from the introduction the document both specifies  new messages and new objects, and these new objects can be used in  PCReq/PCRep too.

 - 4.1 page 12: incompatible requirement "There SHOULD NOT be more
  than one instance of the MONITORING object" with PCRep syntax
  (<response-list>)

 - 4.1 page 13: even if MONITORING object has no optional TLV
  currently defined, the format of these TLVs must be specified.
  I propose the PCEP generic TLV format, RFC 5440 7.1.

 - 4.3 page 16: the variance of time is a squared time. I propose to
  switch to standard deviation (ecart type in French, the square root
  of the variance)

 - 8.6 page 23: CONGESTION object has no defined flag.
 (this is not editorial because of IANA review/processing)

Nits/editorial comments: 
 - Abstract page 2 is in one block, I suggest to insert a line break
  before "In PCE-based"

 - Requirements Language page 2 should be moved in the terminology section

 - ToC page 3 / 8.3 page 21: New Error-Type and Error-Values ->
  New Error-Values

 - ToC page 3 and 10 page 23: Acknowledgements -> Acknowledgments

 - 1 page 4: IGP -> Interior Gateway Protocol (IGP)

 - 1 page 4: troubeshooting -> troubleshooting

 - 1 page 4: more than one PCE is -> are?

 - 1 page 4: BRPC -> Backward Recursive PCE-based Computation (BRPC)

 - 1 page 5: bolean -> boolean

 - 1 page 5: By "In band" -> By "in band"

 - 1 page 5 and many other places: e.g. -> e.g.,

 - 3 page 6: PCEMonReq -> PCMonReq

 - 3 page 6: too many "in this document" (wording)

 - 3.1 page 8: insert a line break between:
      <svec-list>::=<SVEC>[<svec-list>]
      <request-list>::=<request>[<request-list>]

 - 3.1 page 8: Section 4.2.) -> Section 4.2)

 - 3.1 page 8: charaterize -> characterize

 - 3.1 page 9: PCMonreq -> PCMonReq

 - 3.2 page 11: <PROC-TIME> and <CONGESTION> are defined further (8.[56]).
  where <NO-PATH> is defined?

 - 4.1 page 13: choose between Monitoring-id-number and monitoring-id-number 

 - 4.1 page 13: "a wrap back to one" is unclear, 0xffffffff + 1 == 0, not 1.
  If the value zero is reserved this should be more explicit.

 - 4.3 page 15 1): Min, Average, Max and Variance -> minimum, maximum,
  average and variance

 - 4.2 page 15 2): Procesing-time -> Processing-time

 - 4.4 page 17: currently defined: -> currently defined.

 - 6 page 18: value="Reception of an unacceptable number of unknown
  PCEP message. -> value=5 "Reception of an unacceptable number of
  unrecognized PCEP message."
  (i.e., put the reason value and correct meaning with a closing ",
   BTW there are two occurrences to fix)

 - 6 page 19: in "the next hop PCE: such next-hop" choose between  next-hop and next hop (I prefer the second).

 - 6 page 19: extra "Upon receiving a PCMonRep message"

 - 6 page 19: carrries -> carries

 - 6 page 19: Multi-destination -> multi-destination

 - 8.2 page 20 (last line): are defined in this document. ->  are defined in this document:

 - 8.3 page 21: as it doesn't define new error-type(s) I propose:
  New Error-Type and Error-Values -> New Error-Values

 - 8.3 page 21: has been created -> was created?

 - 9 page 23: denail -> denial

 - 9 page 23: shapping -> shaping

 - 10 page 23: Acknowledgements -> Acknowledgments (IETF spelling)

 - 11 page 23-24: take the occasion to update references, for instance:
  I-D.ietf-pce-pcep -> RFC5440
  (this is usually done by the RFC Editor but as it seems you should
   publish a new/fixed version of the document..,)