Francis: thank you for your detailed review! Based on this review I have decided to ballot a No-Objection position.
Authors: However, there are some editorial issues that Francis raises here, and I can not find an e-mail where you would respond to them? Has there been a response and/or have the comments been taken into account in a newer version? I tried to look at the diffs, but there are quite many changes, so I wanted to check that you have seen these and acted on those that you believe need to be acted upon. Jari On Jun 3, 2013, at 12:40 PM, Francis Dupont <[email protected]> wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-mpls-ldp-dod-08.txt > Reviewer: Francis Dupont > Review Date: 20130527 > IETF LC End Date: 20130527 > IESG Telechat date: unknown > > Summary: Ready > > Major issues: None > > Minor issues: None > > Nits/editorial comments: > (Note most of them should be handled by the RFC Editor) > > - "Requirement Language" section page 1 is not in the body > > - the requirement keywords are not used everywhere in the document, > if I understand well there is a normative part. BTW the question > stands too about the Security Considerations. > > - ToC page 2 and 8 page 31: Acknowledgements -> Acknowledgments > > - I have some problems with the abbrevs, I suggest: > * refer to the RFC Editor list to know if an abbrev is well known or not, > in the second case consider to introduce it > * IMHO all not well known abbrev required to understand the text or used > more than once must be introduced at the first use > * another way is to refer to a terminology RFC > > - 2 pages 4 and 5: figure 1 should be on one page (BTW this is a good > example of something which could be handled by the RFC Editor) > > - same figure problems for figures 2 > > - 2.1 page 8: examples of the abbrev issue with ECMP, LAG and FEC. > > - 4.1 page 19: i.e. -> i.e., > > - 4.3.2 page 23: [RFC5036] (section A.1.1, page# 100) -> > ([RFC5036] section A.1.1, page 100) ?? > > - 4.4 page 23 and 5 page 25: the title should not be at the last line > > - 4.4 page 24, 7 page 28 and 7.1.2 page 29: e.g. -> e.g., > > - 5 is a normative part so uses KEYWORDS (IMHO this should be explained, > for instance in the Requirement Language section if it is moved to > a more standard position) > > - 5 page 26: the Queue Request Type is TBD but is 0x0971 in the schema? > > - 6.1 page 27: I suggest to add a reference for RFC5036 > (i.e., RFC5036 -> [RFC5036] as it is in other positions) > > - 7: I have no problem at all (:-) with using KEYWORDS in Security > Considerations! > > - 7 page 28: are considered as -> are applied as ? > > - 7.2 page 30 (about keywords): for instance 'should NOT' -> > 'SHOULD NOT' and keep the MAY in 5. > > - 7.3 page 30: a more questionable 'may' > > - 7.4 page 31: two should's which should be IMHO 'SHOULD' > > - Authors' Addresses page 32: another paging (?) issue > > - Authors' Addresses page 33: some issues: > * French ZIP codes are in front (but is it possible to change from > the XML? I don't know so if you find a simple way to fix it please > both fix it and explain it to me) > * ITU TS E.123 requires no optional part in the middle of a phone > number, i.e., 1-(978)-589-8861 -> +1-978-589-8861 > * no ZIP code for London? BTW grep finds 'FELTHAM TW14 8HA' > (Cisco's communication department should know the canonical > address. BTW in my company we had to agree about the canonical > company name... :-) > > Regards > > [email protected] > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
