Last Call Review of draft-ietf-ippm-lmap-path-05

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
Draft last updated 2014-08-20
Completed reviews Genart Last Call review of -05 by Elwyn Davies (diff)
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)
Assignment Reviewer Elwyn Davies
State Completed
Review review-ietf-ippm-lmap-path-05-genart-lc-davies-2014-08-20
Reviewed rev. 05 (document currently at 07)
Review result Almost Ready
Review completed: 2014-08-20


I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


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) -

Almost ready for the IESG with a few minor nits.

Major issues:

Minor issues:

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




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.


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 


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