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

Hi Roni,

 

I sure will.  I’ve been catching up after being gone so it will take a few days.  I can now also add a little more detail based on a more recent TSVCIS specification.  Nothing proposed will change.

 

Victor

 

From: Roni Even (A) <[email protected]> 
Sent: Sunday, September 22, 2019 8:29 AM
To: Barry Leiba <[email protected]>; [email protected]
Cc: [email protected]; [email protected]
Subject: RE: AD review of draft-ietf-payload-tsvcis-01

 

Hi Victor,

Can you please address the comments from Barry in order to progress the document

Roni

 

From: Barry Leiba [mailto:[email protected]] 
Sent: Thursday, September 12, 2019 7:03 AM
To: [email protected] <mailto:[email protected]> 
Cc: [email protected] <mailto:[email protected]> 
Subject: AD review of draft-ietf-payload-tsvcis-01

 

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

_______________________________________________
Audio/Video Transport Core Maintenance
[email protected]
https://www.ietf.org/mailman/listinfo/avt