Re: [Gen-art] review of draft-ietf-pce-monitoring-04.txt
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, 0x + 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
Re: [Gen-art] review of draft-ietf-pce-monitoring-04.txt
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, 0x + 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 -
Re: [Gen-art] 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, 0x + 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
Re: [Gen-art] review of draft-ietf-pce-monitoring-04.txt
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, 0x + 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
[Gen-art] review of draft-ietf-pce-monitoring-04.txt
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, 0x + 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
