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
