Last call is over. Please respin (I see the most recent version dated January 2009).
thanks, Ross -----Original Message----- From: JP Vasseur [mailto:jvass...@cisco.com] Sent: 28 April 2009 01:37 To: Ross Callon Cc: Francis Dupont; General Area Review Team; JP Vasseur; Jean-Louis Le Roux; y.ikej...@ntt.com Subject: Re: review of draft-ietf-pce-monitoring-04.txt Ah yes, I thought the IETF LC was ended. Will respin right after that. Thanks Ross. JP. On Apr 25, 2009, at 7:10 AM, Ross Callon wrote: > 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:jvass...@cisco.com] > Sent: 24 April 2009 02:05 > To: Francis Dupont; Ross Callon > Cc: General Area Review Team; JP Vasseur; Jean-Louis Le Roux; > y.ikej...@ntt.com > Subject: Re: review of draft-ietf-pce-monitoring-04.txt > > Many Thanks Francis. > > Ross, do you want me to address those comments and respin ? > > Thanks. > > JP. > > On Apr 23, 2009, at 11:46 PM, Francis Dupont wrote: > >> 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
