Document:
Media Resource Control Protocol Version 2 (MRCPv2)
draft-ietf-speechsc-mrcpv2-19
(Standards Track)

(1.a) Who is the Document Shepherd for this document? Has the
           Document Shepherd personally reviewed this version of the
           document and, in particular, does he or she believe this
           version is ready for forwarding to the IESG for publication?

Eric Burger is the document shepherd. I have personally reviewed this  
version of the document. This doeucment is ready for forwarding to the  
IESG for publication.

     (1.b) Has the document had adequate review both from key WG members
           and from key non-WG members? Does the Document Shepherd have
           any concerns about the depth or breadth of the reviews that
           have been performed?

The document has had reviews by key WG members, as well as expert  
review from GENART (Vijay Gurbani), applications (Ted Hardie), RAI  
(Paul Kyzivat), and security (Vijay Gurbani), areas.

     (1.c) Does the Document Shepherd have concerns that the document
           needs more review from a particular or broader perspective,
           e.g., security, operational complexity, someone familiar with
           AAA, internationalization or XML?

Reviews listed above, as well as IANA, URL, and MIME types review. The  
document incorporates and addresses all suggestions from Vijay, Ted,  
Paul, and other IESG members.

     (1.d) Does the Document Shepherd have any specific concerns or
           issues 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. Has an IPR disclosure related to this document
           been filed? If so, please include a reference to the
           disclosure and summarize the WG discussion and conclusion on
           this issue.

Some people unfamiliar with the history of MRCPv2 may question the use  
of SIP for locating speech servers, asking why we do not use RTSP,  
BEEP, or the MEDIACTRL Framework.  RFC 4313, Speech Services Control  
Requirements, not surprisingly, enumerates the protocol requirements  
for MRCP.  Some of these requirements include server location and  
avoiding layer violations.  SIP and RTSP meet the server location  
requirements.  However, the original MRCP experience demonstrated  
severe protocol layering problems with RTSP.  Thus, the industry  
demonstrated RTSP is not appropriate for use as a MRCPv2 location or  
substrate protocol. With respect to MEDIACTRL, MRCPv2 pre-dates the  
effort by almost four years.  In fact, the basis of the MEDIACTRL  
Framework is, in fact, MRCPv2.  At this time, given the years of  
implementation experience with MRCPv2, the industry is unlikely to  
accept major changes to the MRCPv2 protocol, unless there are clear  
benefits to those changes.

There was some discussion about whether MRCPv2 should fully specify  
SRTP key exchange for SIP. Consensus in the work group and with the  
individual who brought that up (Vijay Gurbani) was to leave that to a  
SIP-related work group.

Another issue is MRCPv2 uses set-cookie (RFC 2109) and set-cookie2  
(RFC 2965).  RFC 2965 obsoletes RFC 2109, but does not define set- 
cookie. After three years of implementation experience, the work group  
prefers to go with a DOWNREF to RFC 2109 rather than change all extant  
implementations.

     (1.e) 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?

There is strong consensus with no dissent whatsoever in the work group  
to publish. In addition, there are literally dozens of client, server,  
open source and API implementations available.

     (1.f) 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
           entered into the ID Tracker.)

None.

     (1.g) Has the Document Shepherd personally verified that the
           document satisfies all ID nits? (See
           http://www.ietf.org/ID-Checklist.html and
           http://tools.ietf.org/tools/idnits/). Boilerplate checks are
           not enough; this check needs to be thorough. Has the document
           met all formal review criteria it needs to, such as the MIB
           Doctor, media type and URI type reviews?

Checked with ID nits 2.11.11. There are warnings about what idnits  
thinks is a FQDN but is really a reverse-order parameter registry  
(com.example.mumble).

     (1.h) Has the document split its references into normative and
           informative? 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
           strategy for their completion? Are there normative references
           that are downward references, as described in [RFC3967]? If
           so, list these downward references to support the Area
           Director in the Last Call procedure for them [RFC3967].

The document identifies normative versus informative documents. All  
normative references are RFCs. One DOWNREF is to RFC 2109 (see above).  
Another nominal DOWNREF is to RFC 2483; that reference is to the text/ 
uri-list definition. MRCPv2 uses the same definition of text/uri-list  
as found in the IANA media types registry. We could make this  
reference Informative or be silent on the reference, as the MRCPv2  
reference is to the IANA registry. However, the work group believes it  
to be useful to have a pointer to the definition of text/uri-list for  
implementers to follow.

     (1.i) Has the Document Shepherd verified that the document IANA
           consideration section exists and is consistent with the body
           of the document? If the document specifies protocol
           extensions, are reservations requested in appropriate IANA
           registries? Are the IANA registries clearly identified? If
           the document creates a new registry, does it define the
           proposed initial contents of the registry and an allocation
           procedure for future registrations? Does it suggest a
           reasonable name for the new registry? See [RFC5226]. If the
           document describes an Expert Review process has Shepherd
           conferred with the Responsible Area Director so that the IESG
           can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section meets the above requirements.

     (1.j) Has the Document Shepherd verified that sections of the
           document that are written in a formal language, such as XML
           code, BNF rules, MIB definitions, etc., validate correctly in
           an automated checker?

Yes. ABNF checked with Bill Fenner’s tool. XML checked with XMLmind.

     (1.k) 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
The MRCPv2 protocol allows client hosts to control media service  
resources such as speech synthesizers, recognizers, verifiers and  
identifiers residing in servers on the network.  MRCPv2 is not a  
"stand-alone" protocol - it relies on a session management protocol  
such as the Session Initiation Protocol (SIP) to establish the MRCPv2  
control session between the client and the server, and for rendezvous  
and capability discovery.  It also depends on SIP and SDP to establish  
the media sessions and associated parameters between the media source  
or sink and the media server.  Once this is done, the MRCPv2 protocol  
exchange operates over the control session established above, allowing  
the client to control the media processing resources on the speech  
resource server.


           Working Group Summary
Nothing out of the ordinary happened in the WG to note.

           Document Quality
There are over 20 interoperable implementations of clients, servers,  
open source, and APIs based on this document.