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

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
I support Magnus' point about the time-ordering of adjacent frames in a packet.

Additionally, I am not sure that there's quite enough here to be interoperably
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
canonical listing in [TSVCIS], but this document does not say that, and
furthermore [TSVCIS] is only listed as an informative reference.  (I
couldn't get 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, convey these N octets to the peer with the
appropriate one- or two-byte trailer for payload type identification and
framing), that would be interoperably implementable, since the black-box
bits are up to some other codec to interpret.

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.

[Ballot comment]
Where is [TSVCIS] available?

Is [NRLVDR] the same as
https://apps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ?  A URL in the
references 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
introduction imply this by calling out MELPe 2400 bps speech parameters
explicitly, but Section 3 says that TSVCIS augments standard 600, 1200,
and 2400 bps MELP frames.

It's helpful that Section 3.3 gives some general guidance for decoding
this 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 considerations 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 CODA 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 two 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 presence/length is determined,
then the preceding MELPe payload can be determined and decoded.  Per
Section 3.3, multiple TSVCIS frames can be present in a single RTP
packet."  This (or something like it) would also serve to clarify the
role of the COD* bits, which is otherwise only implicitly introduced.

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
"only the speech coder related bits[...]" is not new information from
this document?  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 audio 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
transported, 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-bit field but the LSB of the octet overall?
We probably need an example of splitting a parameter across octets as
well, 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
reference 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
that it "SHOULD be used for TSVCIS payloads with TC less than or equal
to 77 octetes".

Section 3.3

When a longer packetization interval is used, is that indicated by
signaling 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
payload 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=68, 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
implied 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
requiring encryption for some data; wouldn't that translate to a "MUST"
here and not a "SHOULD"?

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot comment]
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"

[Ballot discuss]
1. Section 3.3:
  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.

I am missing a quite important word in this paragraph. Because I assume that the frame actually are required to be consecuitive frames in time order from oldest to newest?

2. Section 4.1:
  Change controller: IETF Payload working group delegated from the
      IESG.

IESG should we adjust this immediately to say IETF, although this is the currently recommended text in RFC 8088. Or are we only adjusting the working group?

[Ballot comment]
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.

B. Section 4.4:
  In the Offer/Answer model [RFC3264], "bitrate" is a bidirectional
  parameter.  Both sides MUST use a common "bitrate" value or values.
  The offer contains the bitrates supported by the offerer, listed in
  its preferred order.  The answerer MAY agree to any bitrate by
  listing the bitrate first in the answerer response.  Additionally,
  the answerer MAY indicate any secondary bitrate or bitrates that it
  supports.  The initial bitrate used by both parties SHALL be the
  first bitrate specified in the answerer response.

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.

I am a bit surprised to see bit-rate as  bidirectional parameter here. In most use cases where RTP opperates each direction can simply express what they accept, and the media sender towards that receiver will simply provide what the receiver part has declared as acceptable. Can you please provide to me a bit more motivation why the use of bidirectional is needed?

C. Section 3 and 5: Marker bit definition.
The usage of the M bit
  SHOULD be as specified in the applicable RTP profile -- for example,
  [RFC3551], where [RFC3551] specifies that if the sender does not
  suppress silence (i.e., sends a frame on every frame interval), the
  M bit will always be zero.

Section 5:
  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.

I would have expected this format that is clearer on its usage of DTX that it would talk about that marker bit will be = 1 after each DTX period when one no longer transmitts comfort noise only.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-payload-tsvcis-01. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the audio registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

a new registration is to be made as follows:

Name: TSVCIS
Tem plate: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Second, in the RTP Payload Format Media Types registry on the Real-Time Transport Protocol (RTP) Parameters registry page located at:

https://www.iana.org/assignments/rtp-parameters/

a new registration will be made as follows:

Media Type: audio
Subtype: TSVCIS
Clock Rate (Hz):
Channels:
Reference: [ RFC-to-be ]

IANA Question --> What are the entries for Clock Rate and Channels for this new registration?

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-09-25):

From: The IESG
To: IETF-Announce
CC: Ali Begen , payload-chairs@ietf.org, payload@ietf.org, barryleiba@gmail.com, draft-ietf-payload-tsvcis@ietf.org, ali.begen@networked.media
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (RTP Payload Format for TSVCIS Codec) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Payloads WG
(payload) to consider the following document: - 'RTP Payload Format for
TSVCIS Codec'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-09-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes the RTP payload format for the Tactical
  Secure Voice Cryptographic Interoperability Specification (TSVCIS)
  speech coder.  TSVCIS is a scalable narrowband voice coder supporting
  varying encoder data rates and fallbacks.  It is implemented as an
  augmentation to the Mixed Excitation Linear Prediction Enhanced
  (MELPe) speech coder by conveying additional speech coder parameters
  for enhancing voice quality.  TSVCIS augmented speech data is
  processed in conjunction with its temporal matched MELP 2400 speech
  data.  The RTP packetization of TSVCIS and MELPe speech coder data is
  described in detail.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document will be a standard track RFC. This document defines the RTP payload format for the TSVCIS codec. The document type is indicated on the title page.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  This document describes the RTP payload format for the Tactical
  Secure Voice Cryptographic Interoperability Specification (TSVCIS)
  speech coder.  TSVCIS is a scalable narrowband voice coder supporting
  varying encoder data rates and fallbacks.  It is implemented as an
  augmentation to the Mixed Excitation Linear Prediction Enhanced
  (MELPe) speech coder by conveying additional speech coder parameters
  for enhancing voice quality. TSVCIS augmented speech data is
  processed in conjunction with its temporal matched MELP 2400 speech
  data.  The RTP packetization of TSVCIS and MELPe speech coder data is
  described in detail.

Working Group Summary:
Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

The document was discussed on the mailing list. The open issues were addressed and there are no open issues, there was consensus on the content of the document.

Document Quality:
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

According to the authors, there are at least three or four implementations of the TSVCIS codec. Authors  have implemented the RTP payload for this speech codec. The authors anticipate that the parties using the MELP payload RFC 8130, will be moving in this
direction as TSVCIS is an enhanced MELP speech codec.

A request for a media type review was sent to media-types mailing list on Feb. 12, 2019.

Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?
Ali C. Begen is the Document Shepherd.
The responsible AD is Ben Campbell.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd reviewed the document in previous and current versions and found it ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

N/A.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed.  If not, explain why?

Yes, the authors confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG understands the document and agrees with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No issues.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

No need for such reviews.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

None.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

IANA section is OK.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No  new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

No need for such reviews.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document will be a standard track RFC. This document defines the RTP payload format for the TSVCIS codec. The document type is indicated on the title page.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  This document describes the RTP payload format for the Tactical
  Secure Voice Cryptographic Interoperability Specification (TSVCIS)
  speech coder.  TSVCIS is a scalable narrowband voice coder supporting
  varying encoder data rates and fallbacks.  It is implemented as an
  augmentation to the Mixed Excitation Linear Prediction Enhanced
  (MELPe) speech coder by conveying additional speech coder parameters
  for enhancing voice quality. TSVCIS augmented speech data is
  processed in conjunction with its temporal matched MELP 2400 speech
  data.  The RTP packetization of TSVCIS and MELPe speech coder data is
  described in detail.

Working Group Summary:
Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

The document was discussed on the mailing list. The open issues were addressed and there are no open issues, there was consensus on the content of the document.

Document Quality:
Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

According to the authors, there are at least three or four implementations of the TSVCIS codec. Authors  have implemented the RTP payload for this speech codec. The authors anticipate that the parties using the MELP payload RFC 8130, will be moving in this
direction as TSVCIS is an enhanced MELP speech codec.

A request for a media type review was sent to media-types mailing list on Feb. 12, 2019.

Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?
Ali C. Begen is the Document Shepherd.
The responsible AD is Ben Campbell.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd reviewed the document in previous and current versions and found it ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

N/A.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed.  If not, explain why?

Yes, the authors confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG understands the document and agrees with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No issues.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

No need for such reviews.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

None.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

IANA section is OK.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No  new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

No need for such reviews.