Telechat Review of draft-ietf-mpls-ldp-dod-09
review-ietf-mpls-ldp-dod-09-genart-telechat-dupont-2013-08-15-00
| Request | Review of | draft-ietf-mpls-ldp-dod |
|---|---|---|
| Requested rev. | no specific revision (document currently at 09) | |
| Type | Telechat Review | |
| Team | General Area Review Team (Gen-ART) (genart) | |
| Deadline | 2013-08-13 | |
| Requested | 2013-07-29 | |
| Authors | Thomas Beckhaus, Bruno Decraene, Kishore Tiruveedhula, Maciek Konstantynowicz, Luca Martini | |
| Draft last updated | 2013-08-15 | |
| Completed reviews |
Genart Last Call review of -08 by Francis Dupont
(diff)
Genart Telechat review of -09 by Francis Dupont Secdir Last Call review of -08 by Stephen Kent (diff) Secdir Telechat review of -09 by Stephen Kent |
|
| Assignment | Reviewer | Francis Dupont |
| State | Completed | |
| Review | review-ietf-mpls-ldp-dod-09-genart-telechat-dupont-2013-08-15 | |
| Reviewed rev. | 09 | |
| Review result | Ready | |
| Review completed: | 2013-08-15 |
Review
review-ietf-mpls-ldp-dod-09-genart-telechat-dupont-2013-08-15
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 Francis.Dupont at fdupont.fr