Subject: [Gen-art] review of draft-ietf-pce-monitoring-04.txt

From: Francis Dupont <[email-masked]>
Date: Thu, 23 Apr 2009 23:46:30 +0200

I have been selected as the General Area Review Team (Gen-ART) 
reviewer for this draft (for background on Gen-ART, please see 
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). 

Please resolve these comments along with any other Last Call comments 
you may receive. 

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..,)

Regards

[email-masked]

---

From: JP Vasseur <[email-masked]>
Date: Fri, 24 Apr 2009 08:04:45 +0200

Many Thanks Francis.

Ross, do you want me to address those comments and respin ?

Thanks.

JP.

---

From: Ross Callon <[email-masked]>
Date: Sat, 25 Apr 2009 01:10:27 -0400

You need to wait for the IETF last call to end before respinning. Once
the IETF last call ends, then yes please respin. 

Thanks, Ross

-----Original Message-----
From: JP Vasseur [mailto:[email-masked]] 
Sent: 24 April 2009 02:05
To: Francis Dupont; Ross Callon
Cc: General Area Review Team; JP Vasseur; Jean-Louis Le Roux;
[email-masked]
Subject: Re: review of draft-ietf-pce-monitoring-04.txt

Many Thanks Francis.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 28 Apr 2009 07:37:09 +0200

Ah yes, I thought the IETF LC was ended. Will respin right after that.

Thanks Ross.

JP.