MIME-Version: 1.0
References: <157007038502.8860.1558861534319247512.idtracker@ietfa.amsl.com>
 <001601d57af9$405efcf0$c11cf6d0$@vocal.com>
 <6E58094ECC8D8344914996DAD28F1CCD23D79BC0@DGGEMM506-MBX.china.huawei.com>
 <034a01d58a73$f4d3a1c0$de7ae540$@vocal.com>
 <037e01d58a92$72287510$56795f30$@vocal.com>
In-Reply-To: <037e01d58a92$72287510$56795f30$@vocal.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Tue, 29 Oct 2019 14:26:09 -0400
Message-ID: <CALaySJLSkZnC_jsQtk+Ybq03RWYJeujdeft+zGsv9uZ5wjcwCg@mail.gmail.com>
To: victor.demjanenko@vocal.com
Cc: "Roni Even (A)" <roni.even@huawei.com>, Benjamin Kaduk <kaduk@mit.edu>,
 The IESG <iesg@ietf.org>, 
 Catherine Meadows <catherine.meadows@nrl.navy.mil>,
 IETF SecDir <secdir@ietf.org>, 
 draft-ietf-payload-tsvcis@ietf.org, Ali Begen <ali.begen@networked.media>, 
 avtcore-chairs@ietf.org, avt@ietf.org, 
 "Dave Satterlee (Vocal)" <Dave.Satterlee@vocal.com>,
 IETF discussion list <ietf@ietf.org>, 
 draft-ietf-payload-tsvcis.all@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/wu0kMy_ZYFZJfBeVOoNsPHYCohM>
Subject: Re: [AVTCORE] Benjamin Kaduk's Discuss on
 draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT)
Precedence: list

Ben, does the -04 version address everything?

Barry

On Thu, Oct 24, 2019 at 1:42 PM <victor.demjanenko@vocal.com> wrote:
>
> I forgot to address security comments in one email.  The changes are:
>
> Section 8, second paragraph - Suggested edit by reviewer
>
> (was)
>    This RTP payload format and the TSVCIS decoder do not exhibit any
>    significant non-uniformity in the receiver-side computational
>    complexity for packet processing and thus are unlikely to pose a
>    denial-of-service threat due to the receipt of pathological data.
>    Additionally, the RTP payload format does not contain any active
>    content.
>
> (now)
>    This RTP payload format and the TSVCIS decoder, to the best of our
>    knowledge, do not exhibit any significant non-uniformity in the
>    receiver-side computational complexity for packet processing and thus
>    are unlikely to pose a denial-of-service threat due to the receipt of
>    pathological data. Additionally, the RTP payload format does not
>    contain any active content.
>
>
> Section 8, third paragraph - Suggested edit by reviewer
>
> (was)
>    Please see the security considerations discussed in [RFC6562]
>    regarding VAD and its effect on bitrates.
>
> (now)
>    Please see the security considerations discussed in [RFC6562]
>    regarding Voice Activity Detect (VAD) and its effect on bitrates.
>
> Victor
>
> -----Original Message-----
> From: victor.demjanenko@vocal.com <victor.demjanenko@vocal.com>
> Sent: Thursday, October 24, 2019 10:05 AM
> To: 'Roni Even (A)' <roni.even@huawei.com>; 'Benjamin Kaduk' <kaduk@mit.e=
du>; 'The IESG' <iesg@ietf.org>
> Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' <ali.begen@networked.=
media>; avtcore-chairs@ietf.org; avt@ietf.org; 'Dave Satterlee (Vocal)' <Da=
ve.Satterlee@vocal.com>
> Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (w=
ith DISCUSS and COMMENT)
>
> Hi Everyone,
>
> First we want to thank everyone for their review and comments for this dr=
aft RFC.  We believe we reviewed all the comments and suggestions and incor=
porated them adequately in the next draft (04).  We'd like to send out this=
 list of exact changes in case anyone has additional comments or thinks the=
 clarifications are inadequate.  We would be most happy to address concerns=
 before publishing draft 04 tomorrow.
>
> With so many emails from a half dozen or more reviewers, we apologize tha=
t we cannot address each sender individually.  We hope this detail is suffi=
cient for everyone.
>
> Again, many thanks to all.
>
> Victor & Dave
>
> -------------------------------------------------------------------------=
---------------------
>
> Section 1.1 - Suggested reference to RFC 8088 added.
>
> (was)
>    Best current practices for writing an RTP payload format
>    specification were followed [RFC2736].
>
> (now)
>    Best current practices for writing an RTP payload format
>    specification were followed [RFC2736] [RFC8088].
>
>
> Section 2, paragraphs 3 and 4 - Suggested edits by reviewers
>
> (was)
>    In addition to the augmented speech data, the TSVCIS specification
>    identifies which speech coder and framing bits are to be encrypted,
>    and how they are protected by forward error correction (FEC)
>    techniques (using block codes).  At the RTP transport layer, only the
>    speech coder related bits need to be considered and are conveyed in
>    unencrypted form.  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.  Further, it is desirable to support the highest voice
>    quality between endpoints which is only possible without the overhead
>    of FEC.
>
>    TSVCIS augmented speech data is derived from the signal processing
>    and data already performed by the MELPe speech coder.  For the
>    purposes of this specification, only the general parameter nature of
>    TSVCIS will be characterized.  Depending on the bandwidth available
>    (and FEC requirements), a varying number of TSVCIS specific speech
>    coder parameters need to be transported.  These are first byte-packed
>    and then conveyed from encoder to decoder.
>
> (now)
>    In addition to the augmented speech data, the TSVCIS specification
>    identifies which speech coder and framing bits are to be encrypted,
>    and how they are protected by forward error correction (FEC)
>    techniques (using block codes).  At the RTP transport layer, only the
>    speech-coder-related bits need to be considered and are conveyed in
>    unencrypted form.  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.
>
>    TSVCIS augmented speech data is derived from the signal processing
>    and data already performed by the MELPe speech coder.  For the
>    purposes of this specification, only the general parameter nature of
>    TSVCIS will be characterized.  Depending on the bandwidth available
>    (and FEC requirements), a varying number of TSVCIS-specific speech
>    coder parameters need to be transported.  These are first byte-packed
>    and then conveyed from encoder to decoder.
>
>
> Section 3, last sentence paragraph 3 - Suggested edit by reviewer
>
> (was)
>    When more than one codec data frame is
>    present in a single RTP packet, the timestamp is, as always, that of
>    the oldest data frame represented in the RTP packet.
>
> (now)
>    When more than one codec data frame is
>    present in a single RTP packet, the timestamp specified is that of
>    the oldest data frame represented in the RTP packet.
>
>
> Section 3.1, last paragraph - Clarified permission for MELP 600 end-to-en=
d framing bit
>
> (was)
>    It should be noted that CODB for both the 2400 and 600 bps modes MAY
>    deviate from the values in Table 1 when bit 55 is used as an end-to-
>    end framing bit.  Frame decoding would remain distinct as CODA being
>    zero on its own would indicate a 7-byte frame for either rate and the
>    use of 600 bps speech coding could be deduced from the RTP timestamp
>    (and anticipated by the SDP negotiations).
>
> (now)
>    It should be noted that CODB for MELPe 600 bps mode MAY deviate from
>    the value in Table 1 when bit 55 is used as an end-to-end framing
>    bit. Frame decoding would remain distinct as CODA being zero on its
>    own would indicate a 7-byte frame for either 2400 or 600 bps rate and
>    the use of 600 bps speech coding could be deduced from the RTP
>    timestamp (and anticipated by the SDP negotiations).
>
>
> Section 3.2, first paragraph - Clarifications requested by reviewers
>
> (was)
>    The TSVCIS augmented speech data as packed parameters MUST be placed
>    immediately after a corresponding MELPe 2400 bps payload in the same
>    RTP packet.  The packed parameters are counted in octets (TC).  In
>    the preferred placement, shown in Figure 6, a single trailing octet
>    SHALL be appended to include a two-bit rate code, CODA and CODB,
>    (both bits set to one) and a six-bit modified count (MTC).  The
>    special modified count value of all ones (representing a MTC value of
>    63) SHALL NOT be used for this format as it is used as the indicator
>    for the alternate packing format shown next.  In a standard
>    implementation, the TSVCIS speech coder uses a minimum of 15 octets
>    for parameters in octet packed form.  The modified count (MTC) MUST
>    be reduced by 15 from the full octet count (TC).  Computed MTC =3D TC-
>    15.  This accommodates a maximum of 77 parameter octets (maximum
>    value of MTC is 62, 77 is the sum of 62+15).
>
> (now)
>    The TSVCIS augmented speech data as packed parameters MUST be placed
>    immediately after a corresponding MELPe 2400 bps payload in the same
>    RTP packet.  The packed parameters are counted in octets (TC).  The
>    preferred placement SHOULD be used for TSVCIS payloads with TC less
>    than or equal to 77 octets, is shown in Figure 6.  In the preferred
>    placement, a single trailing octet SHALL be appended to include a
>    two-bit rate code, CODA and CODB, (both bits set to one) and a six-
>    bit modified count (MTC).  The special modified count value of all
>    ones (representing a MTC value of 63) SHALL NOT be used for this
>    format as it is used as the indicator for the alternate packing
>    format shown next.  In a standard implementation, the TSVCIS speech
>    coder uses a minimum of 15 octets for parameters in octet packed
>    form.  The modified count (MTC) MUST be reduced by 15 from the full
>    octet count (TC).  Computed MTC =3D TC-15.  This accommodates a maximu=
m
>    of 77 parameter octets (maximum value of MTC is 62, 77 is the sum of
>    62+15).
>
>
> Section 3.3, first paragraph - Suggested edit by reviewer
>
> (was)
>    A TSVCIS RTP packet consists of zero or more TSVCIS coder frames
>    (each consisting of MELPe and TSVCIS coder data) followed by zero or
>    one MELPe comfort noise frame.  The presence of a comfort noise frame
>    can be determined by its rate code bits in its last octet.
>
> (now)
>    A TSVCIS RTP packet payload consists of zero or more consecutive
>    TSVCIS coder frames (each consisting of MELPe 2400 and TSVCIS coder
>    data), with the oldest frame first, followed by zero or one MELPe
>    comfort noise frame.  The presence of a comfort noise frame can be
>    determined by its rate code bits in its last octet.
>
>
> Section 3.3, fourth paragraph - Clarification requested by reviewers
>
> (was)
>    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.
>
> (now)
>    TSVCIS coder frames in a single RTP packet MAY have varying TSVCIS
>    parameter octet counts.  Its packed parameter octet count (length) is
>    indicated in the trailing byte(s).  All MELPe frames in a single RTP
>    packet MUST be of the same coder bitrate.  For all MELPe coder
>    frames, the coder rate bits in the trailing byte identify the
>    contents and length as per Table 1.
>
>
> Section 4.1 - Editor note removed
>
>
> Section 4.1 - Change controller is now
>
> (now)
>    Change controller: IETF, contact <avt@ietf.org>
>
>
> Section 5, first paragraph - Suggested edits by reviewers
>
> (was)
>    A primary application of TSVCIS is for radio communications of voice
>    conversations, and discontinuous transmissions are normal.  When
>    TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may
>    cease and resume frequently.  RTP synchronization source (SSRC)
>    sequence number gaps indicate lost packets to be filled by PLC, while
>    abrupt loss of RTP packets indicates intended discontinuous
>    transmissions.
>
> (now)
>    A primary application of TSVCIS is for radio communications of voice
>    conversations, and discontinuous transmissions are normal.  When
>    TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may
>    cease and resume frequently.  RTP synchronization source (SSRC)
>    sequence number gaps indicate lost packets to be filled by Packet
>    Loss Concealment (PLC), while abrupt loss of RTP packets indicates
>    intended discontinuous transmissions.  Resumption of voice
>    transmission SHOULD be indicated by the RTP marker bit (M) set to 1.
>
>
> Section 10 - Added reference
>
> (added)
>    [RFC8088]  Westerlund, M., "How to Write an RTP Payload Format",
>               RFC 8088, DOI 10.17487/RFC8088, May 2017,
>               <http://www.rfc-editor.org/info/rfc8088>.
>
> -------------------------------------------------------------------------=
------------------------
>
>
> -----Original Message-----
> From: Roni Even (A) <roni.even@huawei.com>
> Sent: Sunday, October 6, 2019 2:09 AM
> To: victor.demjanenko@vocal.com; 'Benjamin Kaduk' <kaduk@mit.edu>; 'The I=
ESG' <iesg@ietf.org>
> Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' <ali.begen@networked.=
media>; avtcore-chairs@ietf.org; avt@ietf.org; 'Dave Satterlee (Vocal)' <Da=
ve.Satterlee@vocal.com>
> Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (w=
ith DISCUSS and COMMENT)
>
> Hi,
> About the reference to TSVCIS.
> The RTP payload is about how to encapsulate the payload in an RTP packet.=
 The objective is to define how an RTP stack can insert the tsvcis frames a=
nd  extract the tsvcis frames from the RTP packet. Typically it is not requ=
ired to understand the payload structure in order to be able to perform the=
 encapsulation.
> This is why the reference to the payload is Informational and we did not =
require to have it publically available.  If there is a need to understand =
the payload itself for the encapsulating than we need more information in t=
he RTP payload specification and a publically available normative reference=
. I think this is not the case here
>
> Roni Even
>
> AVTCore co-chair (ex Payload)
>
> -----Original Message-----
> From: victor.demjanenko@vocal.com [mailto:victor.demjanenko@vocal.com]
> Sent: Saturday, October 05, 2019 12:18 AM
> To: 'Benjamin Kaduk'; 'The IESG'
> Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen'; avtcore-chairs@ietf.=
org; avt@ietf.org; 'Victor Demjanenko, Ph.D.'; 'Dave Satterlee (Vocal)'
> Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (w=
ith DISCUSS and COMMENT)
>
> Everyone,
>
> Thanks for the comments.  I think I mis-understood the ambiguity with res=
pect to to changing rates within a RTP packet.  That was not plan.  An RTP =
packet must have MELP speech frames of the same rate.  What is possible is =
that the amount of augmented TSVCIS speech data may vary from one speech fr=
ame to the next.  This allows for a dynamic VDR as suggested by the NRL pap=
er.  So an RTP packet may have varying TSVCIS data but must always have MEL=
Pe 2400 data.
>
> Again backwards parsing is necessary but the timestamp uniformly incremen=
ts 22.5msec per combined MELP/TSVCIS speech frame.
>
> The NRL is a good public reference on the VDR aspects.  The actual TSVCIS=
 spec we had was FOUO so we could not replicate its detail.  (I believe a l=
ater spec is public or at least partially public.  I am trying to get this.=
)  The opaque data is pretty obvious with the TSVCIS spec in hand.
>
> We will address the issues/concerns raised next week.  Other business had=
 priority.
>
> Thank you and enjoy the weekend.
>
> Regards,
>
> Victor & Dave
>
> -----Original Message-----
> From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
> Sent: Wednesday, October 2, 2019 10:40 PM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen <ali.begen@networked.me=
dia>; avtcore-chairs@ietf.org; ali.begen@networked.media; avt@ietf.org
> Subject: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with =
DISCUSS and COMMENT)
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-payload-tsvcis-03: Discuss
>
> When responding, please keep the subject line intact and reply to all ema=
il addresses included in the To and CC lines. (Feel free to cut this introd=
uctory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I support Magnus' point about the time-ordering of adjacent frames in a p=
acket.
>
> Additionally, I am not sure that there's quite enough here to be interope=
rably implementable.  Specifically, we seem to be lacking a description of =
how an encoder or decoder knows which TSVCIS parameters, and in what order,=
 to byte-pack or unpack, respectively.  One might surmise that there is a c=
anonical listing in [TSVCIS], but this document does not say that, and furt=
hermore [TSVCIS] is only listed as an informative reference.  (I couldn't g=
et my hands on my copy, at least on short notice.)  If we limited ourselves=
 to treating the TSVCIS parameters as an entirely opaque blob (codec, conve=
y these N octets to the peer with the appropriate one- or two-byte trailer =
for payload type identification and framing), that would be interoperably i=
mplementable, since the black-box bits are up to some other codec to interp=
ret.
>
> In a similar vein, we mention but do not completely specify the potential=
 for using CODB as an end-to-end framing bit, in Section 3.1 (see Comment),=
 which is not interoperably implementable without further details.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Where is [TSVCIS] available?
>
> Is [NRLVDR] the same as
> https://apps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ?  A URL in the ref=
erences would be helpful.
>
> Is additional TSVCIS data only present after 2400bps MELPe and the first =
thing to get dropped under bandwidth pressure?  The abstract and introducti=
on imply this by calling out MELPe 2400 bps speech parameters explicitly, b=
ut Section 3 says that TSVCIS augments standard 600, 1200, and 2400 bps MEL=
P frames.
>
> It's helpful that Section 3.3 gives some general guidance for decoding th=
is payload type ("[t]he way to determine the number of TSVCIS/MELPe frames =
is to identify each frame type and length"), but I think some generic consi=
derations would be very helpful to the reader much earlier, along the lines=
 of "MELPe and TSVCIS data payloads are decoded from the end, using the COD=
A and CODB (and, if necessary, CODC and others) bits to determine the type =
of payload.  For MELPe payloads the type also indicates the payload length,=
 whereas for TSVCIS data an additional length field is present, in one of t=
wo possible formats.  A TSVCIS coder frame consists of a MELPe data payload=
 followed by zero or one TSVCIS data payload; after the TSVCIS payload's pr=
esence/length is determined, then the preceding MELPe payload can be determ=
ined and decoded.  Per Section 3.3, multiple TSVCIS frames can be present i=
n a single RTP packet."  This (or something like it) would also serve to cl=
arify the role of the COD* bits, which is otherwise only implicitly introdu=
ced.
>
> Section 1.1
>
> RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for some reason=
 an Informational document and not part of BCP 36?!).
>
> Section 2
>
>    In addition to the augmented speech data, the TSVCIS specification
>    identifies which speech coder and framing bits are to be encrypted,
>    and how they are protected by forward error correction (FEC)
>    techniques (using block codes).  At the RTP transport layer, only the
>    speech coder related bits need to be considered and are conveyed in
>    unencrypted form.  In most IP-based network deployments, standard
>
> Am I reading this correctly that this text is just summarizing what's in =
the TSVCIS spec in terms of what needs to be in unencrypted form, so the "o=
nly the speech coder related bits[...]" is not new information from this do=
cument?  I'm not sure I agree with the conclusion, regardless -- won't the =
(MELPe) speech coder bits be enough to convey the semantic content of the a=
udio stream, something that one might desire to keep confidential?
>
>    link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type
>    1 Ethernet encryptors) would be used to secure the RTP speech
>    contents.  Further, it is desirable to support the highest voice
>    quality between endpoints which is only possible without the overhead
>    of FEC.
>
> I think I'm missing a step in how this conclusion was reached.
>
>    TSVCIS will be characterized.  Depending on the bandwidth available
>    (and FEC requirements), a varying number of TSVCIS specific speech
>    coder parameters need to be transported.  These are first byte-packed
>    and then conveyed from encoder to decoder.
>
> Per the Discuss point, how do I know which parameters need to be transpor=
ted, and in what order?
>
>    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.
>    Any unfilled bits in the last octet MUST be filled with zero.
>
> I agree with Adam that this is very unclear.  A is the MSB of the three-b=
it field but the LSB of the octet overall?
> We probably need an example of splitting a parameter across octets as wel=
l, to get the bit ordering right.
>
> Section 3.1
>
>    It should be noted that CODB for both the 2400 and 600 bps modes MAY
>    deviate from the values in Table 1 when bit 55 is used as an end-to-
>    end framing bit.  Frame decoding would remain distinct as CODA being
>
> Where is the use of CODB as an end-to-end framing bit defined?  If we're =
going to provide neither a complete description of how to do it nor a refer=
ence to a better description, we probably shouldn't mention it at all.
>
> Section 3.2
>
>    RTP packet.  The packed parameters are counted in octets (TC).  In
>    the preferred placement, shown in Figure 6, a single trailing octet
>    SHALL be appended to include a two-bit rate code, CODA and CODB,
>
> I'd consider saying something about this being the preferred format
> ("placement") due to its shorter length than the alternative, and say tha=
t it "SHOULD be used for TSVCIS payloads with TC less than or equal to 77 o=
ctetes".
>
> Section 3.3
>
> When a longer packetization interval is used, is that indicated by signal=
ing or RTP timestamps or otherwise?
>
>    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.
>
> Maybe also note that the penultimate octet gives the length there?
>
>    Information describing the number of frames contained in an RTP
>    packet is not transmitted as part of the RTP payload.  The way to
>    determine the number of TSVCIS/MELPe frames is to identify each frame
>    type and length thereby counting the total number of octets within
>    the RTP packet.
>
> terminology nit: if a frame is the combination of MELPe and TSVCIS payloa=
d data units then there are two layres of decoding to get a length for the =
frame, since we have to get the TSVCIS length and then the MELPe length.
>
> Section 4.2
>
>    Parameter "ptime" cannot be used for the purpose of specifying the
>
> nit: missing article ("The parameter")
>
>    will be impossible to distinguish which mode is about to be used
>    (e.g., when ptime=3D68, it would be impossible to distinguish if the
>    packet is carrying one frame of 67.5 ms or three frames of 22.5 ms).
>
> So how is the operating mode determined, then?
> (I think this is the same question I asked above)
>
> Section 4.4
>
>    For example, if offerer bitrates are "2400,600" and answer bitrates
>    are "600,2400", the initial bitrate is 600.  If other bitrates are
>    provided by the answerer, any common bitrate between the offer and
>    answer MAY be used at any time in the future.  Activation of these
>    other common bitrates is beyond the scope of this document.
>
> It seems important to specify whether this requires a new O/A exchange or=
 can be done "spontaneously" by just encoding different frame types.
> (It seems like the latter is possible, on first glance, and this is impli=
ed by Section 3.3's discussion of mixing them in a single packet.)
>
> Section 5
>
> Please expand PLC at first use (not second).
>
> Section 6
>
> I don't understand the PLC usage.  Is the idea that a receiver, on seeing=
 an SSRC gap, constructs fictitious PLC frames to "fill the gap"
> and passes the resulting stream to the decoder?
>
> Section 8
>
>    and important considerations in [RFC7201].  Applications SHOULD use
>    one or more appropriate strong security mechanisms.  The rest of this
>    section discusses the security-impacting properties of the payload
>    format itself.
>
> I thought we described TSVCIS itself (much earlier in the document) as re=
quiring encryption for some data; wouldn't that translate to a "MUST"
> here and not a "SHOULD"?
>
>
>