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

From: "Roni Even (A)" <[email-masked]>
Date: Sun, 22 Sep 2019 12:28:34 +0000

Hi Victor,
Can you please address the comments from Barry in order to progress the document
Roni

From: Barry Leiba [mailto:[email-masked]]
Sent: Thursday, September 12, 2019 7:03 AM
To: [email-masked]
Cc: [email-masked]
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

---

From: <[email-masked]>
Date: Mon, 23 Sep 2019 08:13:39 -0400

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-masked]> 
Sent: Sunday, September 22, 2019 8:29 AM
To: Barry Leiba <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: AD review of draft-ietf-payload-tsvcis-01

Hi Victor,

Roni

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

— Section 1.1 —

— Section 2 —

“endpoints”

— Section 3.1 —

— Section 3.2 —

NEW

END

— Section 3.3 —

— Section 4.1 —

— Section 9 —

— 

Barry

---

From: <[email-masked]>
Date: Mon, 23 Sep 2019 08:13:39 -0400

Hi Roni,

Victor

Hi Victor,

Roni

— Section 1.1 —

— Section 2 —

“endpoints”

— Section 3.1 —

— Section 3.2 —

NEW

END

— Section 3.3 —

— Section 4.1 —

— Section 9 —

— 

Barry

---

From: "Roni Even (A)" <[email-masked]>
Date: Mon, 23 Sep 2019 12:59:39 +0000

Hi Victor ,
For the moment it will be god just to respond to Barry,
The document is in IETF Last Calll which will end on the 25th
There may be more comments since it will be reviewed by GenART, security and operation. So I think that update next week is better
Roni Even
AVTcore (Payload) co chair

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, September 23, 2019 3:14 PM
To: Roni Even (A); 'Barry Leiba'; [email-masked]
Cc: [email-masked]; [email-masked]; 'Victor Demjanenko, Ph.D.'; 'Dave Satterlee (Vocal)'; 'John Punaro'
Subject: RE: AD review of draft-ietf-payload-tsvcis-01

Hi Roni,

Victor

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

Hi Victor,

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

— Section 1.1 —

— Section 2 —

“endpoints”

— Section 3.1 —

— Section 3.2 —

NEW

END

— Section 3.3 —

— Section 4.1 —

— Section 9 —

—
Barry

---

From: <[email-masked]>
Date: Tue, 24 Sep 2019 09:57:24 -0400

Hi Barry,

Thanks for the comments.  I will be updated the document shortly.  I can agree with almost all of your recommended changes except probably the one grammatical suggestion you feel strongest about; comprised of vs. comprising.   The “comprised of” is from my patent lawyer friends.  “Comprising” does not read right as this represents an action or presence where the intention is lack thereof.

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

   frame MAY be used periodically by an endpoint to indicate

   connectivity by an otherwise idle receiver.”

Maybe a slight revision would be better:

“A TSVCIS RTP packet without coder and comfort noise

   frames MAY be used periodically by an endpoint to indicate

   connectivity by an otherwise idle receiver.”

Again thanks for the comments.  I expect to have the updated draft ready in a couple of days. 

Victor

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

— Section 1..1 —

— Section 2 —

“endpoints”

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 —

— Section 3..2 —

NEW

END

— Section 3..3 —

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.....”

— Section 4..1 —

— Section 9 —

— 

Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 24 Sep 2019 11:26:12 -0400

Hi, Victor,

>    connectivity by an otherwise idle receiver.”

Yes, that is a perfect solution; thanks.

> Again thanks for the comments.  I expect to have the updated draft ready in a couple of days.

Excellent; I'll watch for it.  If you can get it in by this Thursday,
the document can be on the IESG telechat next Thursday, 3 Oct.

Barry