Re: [Gen-art] Gen-art LC review of draft-ietf-ippm-lmap-path-05

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Elwyn,

Thanks for your review and comments. We have adopted changes to 
address them all.  The diff attached illustrates the changes 
to the draft so far.

regards,
Al (for co-authors)

> -----Original Message-----
> From: Elwyn Davies [mailto:[e-mail]]
> Sent: Wednesday, August 20, 2014 1:06 PM
> To: General area reviewing team; draft-ietf-ippm-lmap-
> [e-mail]
> Subject: Gen-art LC review of draft-ietf-ippm-lmap-path-05
> 
> 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/
> 
>