Suresh, Many thanks for your review. I can ask the RFC ediitor to do a TOC. The obsoleted-by is a good idea, as is dropping the MAY NOT. I'll re-run idnits to catch the long lines and pages.
Cheers, Andy ----- Original Message ----- From: Suresh Krishnan <[EMAIL PROTECTED]> To: Malis, Andrew G. (Andy); [EMAIL PROTECTED] <[EMAIL PROTECTED]>; [EMAIL PROTECTED] <[EMAIL PROTECTED]>; [EMAIL PROTECTED] <[EMAIL PROTECTED]>; [EMAIL PROTECTED] <[EMAIL PROTECTED]>; [email protected] <[email protected]> Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Sent: Wed Oct 24 00:00:41 2007 Subject: Gen-ART review of draft-malis-sonet-ces-mpls-09.txt I am the assigned Gen-ART reviewer for draft-malis-sonet-ces-mpls-09.txt For background on Gen-ART, please see the FAQ at <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. Summary: This draft is almost ready for publication, but I have some comments. Meta-question ============= Does this need a <Obsoleted by:RFC4842> note? Feels weird for me to ask since this will have a later RFC number :-) Minor ===== * No ToC. It would be really nice to have a table of contents for this document as it is a bit long. Feel free to ignore this if you feel it is OK this way. * Section 5.4.2 "As discussed in section 6.2, a CEM de-packetizer MAY or MAY NOT support re-ordering of mis-ordered packets. " The term MAY NOT is not defined in RFC2119 and hence does not have any predefined meaning. From my reading of this sentence, I did not understand what the draft was trying to convey. And section 6.2 does not contain any such discussion either. From my personal experience, when I had to use "may or may not" frm plain english I would translate it into a MAY. Editorial ========= There are a couple of long lines (72+ chars) and a few long pages (58+ lines). Please fix these. Cheers Suresh
_______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
