Telechat Review of draft-ietf-mpls-ldp-dod-09
review-ietf-mpls-ldp-dod-09-genart-telechat-dupont-2013-08-15-00

• Status
• Email expansions
• History

• Versions
• 00

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