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

From: Ross Callon <[email-masked]>
Date: Thu, 28 May 2009 15:47:25 -0400

Last call is over. Please respin (I see the most recent version dated
January 2009). 

thanks, Ross

-----Original Message-----
From: JP Vasseur [mailto:[email-masked]] 
Sent: 28 April 2009 01:37
To: Ross Callon
Cc: Francis Dupont; General Area Review Team; JP Vasseur; Jean-Louis Le
Roux; [email-masked]
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:[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.
>
> 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
>>
>> [email-masked]
>>
>