Re: [Gen-art] Gen-art last call review of draft-ietf-mpls-psc-updates-03.txt (review type corrected).

[Eric Osborne <[e-mail]>]

Hi Elwyn-

  Thanks for the comments.  I'll make sure they're addressed before
publication.  I also have other comments but they're along the same
lines as yours, and those will be integrated too.



eric


On Fri, Apr 4, 2014 at 2:58 PM, Elwyn Davies <[e-mail]> wrote:
> (Sorry...  got the wrong review type in the subject line).
>
> 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-psc-updates-03.txt
> Reviewer: Elwyn Davies
> Review Date: 4 April 2014
> IETF LC End Date: 2014-04-09
> IESG Telechat date: (if known) -
>
> Summary:
> Almost ready.
>
> Major Issues:
>
> Minor Issues:
> General:
> As discussed during
> Last Call/IETF review of draft-ietf-mpls-tp-psc-itu, RFC 6378 is missing
> some details regarding
> - the on-the-wire format of messages
> - detection of and behaviour in the event of reception of malformed
> messages
> - behaviour in the event of receiving unknown TLV items
> - behaviour in the event or receiving unexpected TLV items in a
> particular mode.
>
> Specifics:
> On-the-wire format:
> - The encoding of the TLV Length field is not specified (unsigned binary
> integer in network bit order).
> - The encoding of the individual TLV length and Type fields in s2 should
> also be specified (unsigned binary integer in network bit order).
> - The value of TLV Length should be more precisely specified.  Suggest:
>   The TLV Length is the sum of the lengths of all TLVs in the message,
>   where the length of a TLV is the sum of the lengths of the three
>   TLV fields, i.e., the the length of the value field + 4.
>
> Malformed messages check:
> - Check values of fields prior to TLV Length are consistent with s4.2 of
> RFC 6378.
> - Check overall length of message matches value in TLV Length + 12.
> - Check Sum of lengths of TLVs matches value in TLV Length.
> - Check all TLV types received are recognized.
>
> Behaviour in the event of receiving a malformed message:
> - There has been discussion of appropriate behaviour on the MPLS mailing
> list.
>
> Behaviour in the event of receiving a well-formed but inappropriate TLV
> in a message:
> - This needs to be specified. (might be mode specific)
>
> Nits/Editorial Comments:
> General: s/i.e. /i.e., /g, s/e.g. /e.g., /g
>
> Abstract/s1: Make the count of changes consistent (four/five currently).
> Might be better just to say 'a number of changes' and leave the reader
> to count.
>
> s1: Since the number of items has grown to five and maybe six (depending
> on how the above changes are inserted), it would helpful to link the
> categorization to the actual section numbers.)
>
> s2: It would be good to have the conventional picture here - just grab
> the one from draft-mpls-tp-psc-itu.
>
> s2, Value field: Better to say that this has the number of octets
> specified in the length field rather than talking about multiples of 4
> again.  The discussion of padding seems superfluous.
>
> s4, next to last para: Should 'A remote No Request message SHALL be ignored' be
> 'A remote NR message SHALL be ignored' for consistency?
>
> s5,para 8: s/In both cases the request which was driving/In both cases the request that was driving/
>
> s6: It might be worth pointing out that extensions of PSC (like tp-psc-itu) may
> introcuce additional capabilities and state that it is up to these sepcifications to
> say how capability mismatch in this areas is/are handled.
>
>
>
>
>
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art
>