Subject: [payload] AD review of draft-ietf-payload-tsvcis-01

From: Barry Leiba <[email-masked]>
Date: Thu, 12 Sep 2019 00:03:15 -0400

Please accept my abject apology for having not handled this sooner: it got
lost, first in the AD transition and then in my own mess.  I’ve reviewed it
now and will be processing it without further delay.

I have mostly editorial comments, which you can handle along with any other
last-call comments and include in a revised draft that you post after last
call ends in two weeks.  I will initiate last call right after I send this
review.

— Section 1.1 —

Please switch to the new BCP 14 boilerplate (see RFC 8174) and add a
normative reference to RFC 8174.

— Section 2 —

   Further, it is desirable to support the highest voice

   quality between endpoint which is only possible without the overhead

“endpoints”

   Any unfilled bits in the last octet SHOULD be filled with zero.

I suggest that things are more robust if this is MUST, so recipients can
rely on the behaviour.  What would a reason be not to comply?  (And
similarly for the SHOULD in Section 3.1.2.)

— Section 3.1 —

   here for all three MELPe rates [RFC8130] which with its

   recommendations now regarded as requirements.

I think the word “which” needs to be removed.

— Section 3.2 —

   The second to last trailing

   byte MUST contain the parameter count (TC) in octets and MAY

   represent any value from one to 255.

I don’t think this is correct use of MAY: you can’t just pick any value in
the range.  You have to use the correct parameter count.  So:

NEW

   The second to last trailing

   byte MUST contain the parameter count (TC) in octets (a value

   between 1 and 255, inclusive).

END

— Section 3.3 —

   A TSVCIS RTP packet MAY consist of zero or more TSVCIS coder frames

   (each consisting of MELPe and TSVCIS coder data) followed by zero or

   one MELPe comfort noise frame.

Is there anything else it can consist of?  This seems a very odd use of
MAY, and I think you really just want to say that “a TSVCIS RTP packet
consists of....”

   A TSVCIS RTP packet comprised of no coder frame and no comfort noise

A total nit that happens to be a pet peeve of mine (I have quite the
menagerie): “comprising”, please, not “comprised of”.

— Section 4.1 —

You cite RFC 6838, but you’re still using an older template.  Please update
this to match the template in 6838, and please put a reference to the
TSVCIS spec in the “Published Specification” field.

— Section 9 —

Please remove Section 9 now, rather than waiting for the RFC Editor to do
it.

—
Barry