Last Call Review of draft-ietf-ippm-lmap-path-05
review-ietf-ippm-lmap-path-05-genart-lc-davies-2014-08-20-00

Request Review of draft-ietf-ippm-lmap-path
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-08-22
Requested 2014-08-11
Other Reviews Genart Telechat review of -05 by Elwyn Davies (diff)
Secdir Last Call review of -05 by David Harrington (diff)
Opsdir Telechat review of -05 by David Harrington (diff)
Review State Completed
Reviewer Elwyn Davies
Review review-ietf-ippm-lmap-path-05-genart-lc-davies-2014-08-20
Posted at http://www.ietf.org/mail-archive/web/gen-art/current/msg10517.html
Reviewed rev. 05 (document currently at 07)
Review result Almost Ready
Draft last updated 2014-08-20
Review completed: 2014-08-20

Review
review-ietf-ippm-lmap-path-05-genart-lc-davies-2014-08-20

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-ippm-lmap-path-05.txt
Reviewer: Elwyn Davies
Review Date: 20 August 2014
IETF LC End Date: 22 August 2014
IESG Telechat date: (if known) -

Summary:
Almost ready for the IESG with a few minor nits.

Major issues:
None

Minor issues:
None

Nits/editorial comments:
s1, para 2:



   This topic has been previously developed in section 5.1 of [RFC3432],
   and as part of the updated framework for composition and aggregation,
   section 4 of [RFC5835] (which may also figure in the LMAP work



                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^



   effort).



     ^^^^^^^


The bracketed phrase sounds as if it is a comment on work in progress: 


I think it needs a different version for the long term when this becomes 


an RFC - either (if this is to do with the development of this 


specification) it did or didn't figure - but it could be something that 


is relevant to implementation/usage of the specification - I can't tell 


(yet? or indeed after reading the full draft) - in which case it needs 


rephrasing appropriately.




s3.1:



A reference path is a serial combination of ... links, ...


A piece of extreme pedantry probably:  How would this apply to ECMP or 


Multi-Link Trunking connections where there is some parallelism in the link?






s3.3/s3.4 et seq:  Would it be better to use Dedicated Component and 


Shared Component (rather than ...ed component) to make it clear that the 


combination is the defined term?  Capitalization of these and other 


terms (Managed/Un-managed) etc should be consistent throughout.






s3.4/s4: I think Service Demarcation (Point) could be usefully treated 


as another piece of terminology definition and the current text in s4 


moved to s3 - and placed before s3.4 so that s3.4 then refers to the 


previous definition.






s4: Expand acronyms on first use please: "LTE UE" (in Service 


Demarcation) and "GRA GW" [The last two are currently  expanded in the 


caption of Figure 1 in s5].




s5, items 2C and 2D: s/from point/from the point/



s5, Notes, first bullet: s/Some use the terminology "on-net" and 


"off-net"/The terminology "on-net" and "off-net" is sometimes used/




s5, Notes, fourth bullet:



      the remote end of the connecting link is an equivalent point
      for some methods of measurement (To Be Specified Elsewhere).






Does the 'To Be Specified Elsewhere' mean that something has not yet 


been done that was intended to be done?  Maybe the RFC 5835 comment???






s5, Notes, last bullet: s/The GW of first transit/The GW of the first 


transit/




s7, bullet #1: s/The CPE is/The CPE consists of a/