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
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
Re: [Gen-art] Gen-art review of draft-ietf-ccamp-pc-and-sc-reqs-06.txt
It seems pretty clear that the comment actually refers to the Conventions used in this document section. Ross -Original Message- From: Adrian Farrel [mailto:adr...@olddog.co.uk] Sent: 27 January 2009 17:55 To: Ross Callon; Gonzalo Camarillo Cc: gen-art@ietf.org; ccamp-cha...@tools.ietf.org; draft-ietf-ccamp-pc-and-sc-r...@tools.ietf.org Subject: Re: Gen-art review of draft-ietf-ccamp-pc-and-sc-reqs-06.txt Sure. Whatever. Actually I am completely baffled by this comment as the terminology section in this I-D is Section 2. We are talking about the same I-D aren't we? draft-ietf-ccamp-pc-and-sc-reqs-06.txt All I see after the Abstract is a section with RFC 2119 language. Maybe this should be toned differently for a requirements draft, but I find it useful and helpful to use 2119 language in requirements documents. As to the placement of 2119 boilerplate we should observe that the RFC Editor will always position this where he thinks it appropriate in an RFC and this has nothing to do with whether the document is ready for publication. Sometimes, it is true, this is immediately after the Introduction, and sometimes it is immediately after the Abstract. See http://www.rfc-editor.org/rfc/rfc5316.txt and http://www.rfc-editor.org/authors/rfc5440.txt for examples of each. Thanks, Adrian PS In case there should be any doubt, I really do appreciate the work done by the GenArt review team to improve the quality of our RFCs. - Original Message - From: Ross Callon rcal...@juniper.net To: Gonzalo Camarillo gonzalo.camari...@ericsson.com Cc: gen-art@ietf.org; ccamp-cha...@tools.ietf.org; draft-ietf-ccamp-pc-and-sc-r...@tools.ietf.org Sent: Tuesday, January 27, 2009 8:17 PM Subject: RE: Gen-art review of draft-ietf-ccamp-pc-and-sc-reqs-06.txt I proposed to the authors to put in an RFC editor's note to cover your comment. If all are fine with this, then we should be ready to put this on an IESG telechat. Thanks, Ross -Original Message- From: Gonzalo Camarillo [mailto:gonzalo.camari...@ericsson.com] Sent: 27 January 2009 04:31 To: draft-ietf-ccamp-pc-and-sc-r...@tools.ietf.org Cc: Ross Callon; gen-art@ietf.org; ccamp-cha...@tools.ietf.org Subject: Gen-art review of draft-ietf-ccamp-pc-and-sc-reqs-06.txt Hi, 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. Draft: draft-ietf-ccamp-pc-and-sc-reqs-06.txt Reviewer: Gonzalo Camarillo gonzalo.camari...@ericsson.com Review Date: 27 January 2009 Summary: This draft is ready for publication as an Informational RFC. Comments: The Terminology Section is not usually appended to the Abstract. It is usually placed after the Introduction as a regular section. Thanks, Gonzalo ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART Last Call review of draft-dasgupta-ccamp-path-comp-analysis-02
I added an RFC editor's note to cover these editorial points. Thanks, Ross -Original Message- From: Spencer Dawkins [mailto:spen...@wonderhamster.org] Sent: 25 November 2008 16:34 To: suk...@ece.drexel.edu; j...@ece.drexel.edu; j...@cisco.com Cc: General Area Review Team; Ross Callon; Adrian Farrel; Deborah Brungard Subject: Gen-ART Last Call review of draft-dasgupta-ccamp-path-comp-analysis-02 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-dasgupta-ccamp-path-comp-analysis-02 Reviewer: Spencer Dawkins Review Date: 2008-11-25 IETF LC End Date: 2008-12-14 IESG Telechat date: (not known) Summary: This draft is ready for publication as an Informational RFC. Comments: You can drop the 2119 boilerplate text (because you don't use it). There are some nits (I noticed s/Virutal/Virtual/ and s/Eventhough/Even though/) for the editor. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-ietf-isis-wg-extlsp-03.txt
I agree that these changes are all minor enough that any one of these could be handled by an RFC editor's note. The issue that I have is that there are a lot of them, and this document hasn't gone in front of the IESG yet. Thus there are very likely to be additional updates needed to deal with in order to resolve IESG comments. It gets quite confusing to keep a long RFC editor's note up to date while making additional changes to the document. Thus I think that it would be less confusing to update the document with these changes, and then I can put the document on the IESG agenda soon after the IETF meeting. Thanks, Ross -Original Message- From: Danny McPherson [mailto:[EMAIL PROTECTED] Sent: 11 November 2008 00:32 To: Brian E Carpenter; Les Ginsberg (ginsberg) Cc: General Area Review Team; Ross Callon; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Gen-ART LC review of draft-ietf-isis-wg-extlsp-03.txt OK, a summary of discussion takeaways is below. Unless there are objections, I believe all of these can be resolved by the RFC Editor actions and would prefer that over issuing an -04 revision. Anyone have issues with this? If I missed (or mis-captured) any comments please let me know as well. Brian and Gen-ART team, thanks much for your diligence and usual careful review! -danny --- Request that this document obsoletes RFC 3786. - Expand Virtual IS in S4.2.2 to Virtual System with (Virtual IS) following in parentheses. - Replace IS-Alias in S4.4 text with IS Alias ID - s/[ISO 10589]/[IS-IS] - s/[IS- IS]/[IS-IS]/ - s/[RFC 2119]/[BCP14]/ - S 4.4: s/RFC 3784/[RFC 5305]/ S 4.5: s/RFC 3784/[RFC 5305]/ - S 4.5: s/RFC 4205/[RFC 5307]/ - Remove reference [BCP9] Remove reference [BCP26] Remove reference [BCP79] - Update reference with: [M-IS-IS] Pryzgienda, T., Shen, N., and Sheth, N., Multi Topology (MT) Routing in IS-IS, RC 5120, February 2008. - Replace: [RFC 3784] Smit, H. and T. Li, Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE), RFC 3784, June 2004. With: [RFC 5305] Smit, H. and T. Li, IS-IS Extensions for Traffic Engineering, RFC 5305, October 2008. - Replace: [RFC 4205] Kompella, K. and Rehkter, Y., Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 4205, October 2005. With: [RFC 5307] Kompella, K. and Rehkter, Y., IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), RFC 5307, October 2008. - Move from Normative to Informative Reference: [RFC 3786] Hermelin, A., Previdi, S. and Shand, M., Extending the Number of Intermediate to Intermediate (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit, RFC 3786, May 2004. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-art review of draft-ietf-manet-packetbb-14
Appendix A: Is this normative? If not should it use RFC 2119 language? Appendix B: Is this normative? If not should it use RFC 2119 language? In particular... Elwyn; First of all, thanks for another very through and well-done review. I just have one comment with regard to the use of RFC2119 language in appendices. I agree that it is important that the document be very clear whether the appendices are normative or not. To me this seems particularly important wrt Appendix A, which looks to me like it might be normative. Appendix B (of the version -15) starts off stating: This appendix describes the intended usage of message header fields including their content and use. Alternative uses of this specification are permitted. Which seems to indicate that alternate uses are okay, so it sort of looks like appendix B is non-normative (but it would be good to make this clear). The IESG has on more than one occasion discussed the issue of RFC2119 Language in informational and experimental RFCs. The result is clear: RFC2119 language is permitted in informational and experimental RFCs. Thus, if the RFC says you MUST do X, then this is interpreted in the context of the status of the RFC: If an experimental RFC specifying the foobar protocol says MUST do X, then you must do X if you want to conform with the experimental foobar protocol, but you don't have to conform to the foobar protocol. I don't recall having discussions regarding the use of RFC2119 language in informational appendices. However, I would expect that we would use the same approach: If the appendix is non-normative, then you don't have to implement nor conform to whatever is in the appendix in order to conform to the main protocol. However, if you want to say that you conform to the appendix, then you MUST do those things that are listed as MUST. Thus at least my interpretation of the discussions that we have had in the IESG suggests that since RFC2119 language is permitted in informational documents, it most likely should also be permitted in informational appendices. Thanks, Ross ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: Gen-ART review of draft-ietf-ccamp-gmpls-segment-recovery-03
I think that I should enter an RFC editor's note to correct this. Ross At 06:05 PM 10/20/2006 -0400, Lou Berger wrote: Pasi, Good catch. Section 9.4., Secondary Record Route Object should have suggested 199. Lou At 04:55 AM 10/20/2006, [EMAIL PROTECTED] 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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ccamp-gmpls-segment-recovery-03 Reviewer: Pasi Eronen Review Date: 2006-10-20 IESG Telechat date: 2006-10-26 Summary: This draft is ready for publication as a Proposed Standard RFC. Comments: I reviewed version -02 of this document during IETF Last Call, and my comments have been addressed in version -03. There is one minor nit (but IANA/RFC editor will take care of it): sections 9.3 and 9.4 suggest the same value (198) forthe SECONDARY_EXPLICIT_ROUTE and SECONDARY_RECORD_ROUTE objects. Best regards, Pasi ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
