Here you are, the new revision addressing all Gen-art review comments has been posted.

Many Thanks.

JP.

On May 28, 2009, at 9:47 PM, Ross Callon wrote:

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

Reply via email to