Skip to main content

RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec
draft-ietf-payload-tsvcis-05

Yes

(Barry Leiba)

No Objection

(Alvaro Retana)
(Deborah Brungard)

Note: This ballot was opened for revision 02 and is now closed.

Roman Danyliw
No Objection
Comment (2019-10-01 for -03) Sent
Section 2.  Per “In most IP-based network deployments, standard link encryption methods (SRTP , VPNs, FIPS 140 link encryptors or Type 1 Ethernet encryptors) would be used to secure the RTP speech contents.”, the inclusion of STRP in this list of “link encryption” methods was surprising.  The other methods typically provide a service agnostic tunnel but STRP is application specific (and doesn’t protect a link).

Section 8, Per “Applications SHOULD use one or more appropriate strong security mechanisms”, what exactly is the “SHOULD” requiring?
Warren Kumari
No Objection
Comment (2019-10-03 for -03) Not sent
Like Éric, this is far outside my area of expertise, so I'm balloting "NoObj" in the "I read the protocol action, and I trust the sponsoring AD so have no problem and / or this is outside my area of expertise." sense of the term.
Éric Vyncke
No Objection
Comment (2019-10-01 for -03) Sent
Thank you for the work put into this document. It is far from my area of expertise, so, I have reviewed only parts of it and my comments below may be non relevant.

Regards,

-éric

== COMMENTS ==

-- Section 2.3 --
C.1) "The assignment of an RTP payload type for this new packet format is outside the scope of this document and will not be specified here", possibly outside of my expertise area, but, why not requesting a payload type in this document? And I see no other documents related to TSVCIS in the AVTCORE WG that could do it. It also appears to contradict sections 4 and 7.

-- Section 3.1 --
C.2) Probably worth explaining why CODC is sometime "not available" ? Is this not always present as hinted in the text below? If so, then what about using "not present" ?

== NITS ==

-- Section 3 --
N.1) in "the timestamp is, as always, that", could perhaps replace "as always" by "as specified in XYZ"
Barry Leiba Former IESG member
Yes
Yes (for -02) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (2019-10-01 for -03) Sent
Thanks for the work the authors and working group put into this document.
I have a handful of comments of varying importance.

---------------------------------------------------------------------------

§2:

>  At the RTP transport layer, only the
>  speech coder related bits need to be considered and are conveyed in

Nit "...speech-coder-related bits..."

>  Depending on the bandwidth available
>  (and FEC requirements), a varying number of TSVCIS specific speech

Nit: "...TSVCIS-specific..."

---------------------------------------------------------------------------

§2:

>  Byte packing of TSVCIS speech data into packed parameters is
>  processed as per the following example:
>
>     Three-bit field: bits A, B, and C (A is MSB, C is LSB)
>     Five-bit field: bits D, E, F, G, and H (D is MSB, H is LSB)
>
>          MSB                                              LSB
>           0      1      2      3      4      5      6      7
>       +------+------+------+------+------+------+------+------+
>       |   H  |   G  |   F  |   E  |   D  |   C  |   B  |   A  |
>       +------+------+------+------+------+------+------+------+
>
>  This packing method places the three-bit field "first" in the lowest
>  bits followed by the next five-bit field.  Parameters may be split
>  between octets with the most significant bits in the earlier octet.

I've read over this example several times and I still can't make sense
of how I might go about implementing the intended packing. I can kind
of make out an implication that there are some TSVCIS parameters that
I'm supposed to... bit reverse into a byte? I think? But then we get
to the notion of "earlier" octets, with MSB (which one? TSVCIS or
RTP?) bits appearing in these "earlier" octets, and I'm at a near
complete loss. Once I get into concrete examples (e.g., Figure 2),
parameter MSBs appear to be in what I think most people would term "later"
bytes rather than "earlier" bytes.

This explanation really needs clarification, as I suspect that
readers will have several conflicting interpretations of what
this is supposed to mean.

---------------------------------------------------------------------------

§4.1:

>     tcmax: specifies the TSVCIS maximum value for TC supported or
>        desired ranging from 1 to 255.  If "tcmax" is not present, a
>        default value of 35 is used.
>
>        [EDITOR NOTE - the value of 35 is suggested based on a
>        preferred 8kbps TSVCIS coder bitrate.]

It's unclear to me whether this EDITOR NOTE is intended to be
left in the final document. It doesn't appear to be a note for
the RFC Editor (as it's not actionable from an editing perspective),
but neither does it look like the kind of thing that typically appears
in a published RFC. Please either remove this text, or make sure the intended
disposition of this text is clearly indicated.
Alissa Cooper Former IESG member
No Objection
No Objection (2019-10-02 for -03) Sent
s/Department of Defense/US Department of Defense/
Alvaro Retana Former IESG member
No Objection
No Objection (for -03) Not sent

                            
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2020-04-10) Sent
Thank you for addressing my Discuss points!
Deborah Brungard Former IESG member
No Objection
No Objection (for -03) Not sent

                            
Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection (2019-10-29 for -04) Sent
Thanks for addressing the discusses and comments. 

I leave this comment, as something that could have been more explicit about decoding, however one skilled in the art will figure it out. 

	A. Section 3.3:
	   TSVCIS coder frames in a single RTP packet MAY be of different coder
   bitrates.  With the exception for the variable length TSVCIS
   parameter frames, the coder rate bits in the trailing byte identify
   the contents and length as per Table 1.
	
	If I understand this correctly in an RTP payload that contain mulyiplr bit-rate frames the safest way of decoding this payload is to work from the end of the payload towards the start identifying a frame at a time. Then after having figured out how many frames actually are present, one can calculate the timestamp value for each frame.