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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
