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
francis.dup...@fdupont.fr
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
