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

[Elwyn Davies <[e-mail]>]

Hi, Al (and co-authors).

Thanks for the response.

That all looks good to me.

Cheers,
Elwyn

On 27/08/14 00:01, MORTON, ALFRED C (AL) wrote:
> 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/
>>
>>
>