Re: [Gen-art] review of draft-ietf-mpls-ldp-dod-08.txt

[Jari Arkko <[e-mail]>]

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 <[e-mail]> 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 -> [phone]
> * 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
> 
> [e-mail]
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art