(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?
"Proposed Standard" is the proper type because this RFC defines a new
protocol by which Media Request Brokers allocate work to Application
Servers.
(2) The IESG approval announcement includes a Document Announcement
Write-Up.
Technical Summary
The MediaCtrl work group in the IETF has proposed an architecture for
controlling media services. The Session Initiation Protocol (SIP) is
used as the signalling protocol which provides many inherent
capabilities for message routing. In addition to such signalling
properties, a need exists for intelligent, application level media
service selection based on non-static signalling properties. This is
especially true when considered in conjunction with deployment
architectures that include 1:M and M:N combinations of Application
Servers and Media Servers. This document introduces a Media Resource
Broker (MRB) entity which manages the availability of Media Servers
and the media resource demands of Application Servers. The document
includes potential deployment options for an MRB and appropriate
interfaces to Application Servers and Media Servers.
Working Group Summary
The working group consensus on this document is solid. Two
WGLCs were held, one after the initial consensus on the
document, and one after extensive review and implementation
experience dictated a number of small improvements to the
protocol and its description.
Document Quality
The protocol described in this document has been implemented
by several major vendors. The description has also been
carefully reviewed by someone not involved in its writing or
implementation.
Personnel
Dale Worley is the document's shepherd.
Robert Sparks is the responsible AD.
(3) Briefly describe the review of this document that was performed by
the Document Shepherd.
I believe the document has had adequate review to be ready for
publication. I have reviewed the entire document myself, leading to
corrections of dubious points.
I did have concerns that there were a number of editorial and
technical issues that should have been detected and corrected at a
stage before I wrote the first shepherd writeup. But correspondence
with Chris Boulton (an author) convinced me that the people who are
interested in this topic have reviewed the draft (and implemented it)
enough to ensure that these and any further undetected issues will not
be a practical impediment.
(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?
I have no such concerns.
The only plausible concern is that the protocol seems to be overly
complex, in that it allows several different modes of operation for
broadly similar actions. But the people involved in the draft are
involved in practical deployments, and I am sure that they have found
the various alternatives in the protocol are necessary in various
practical situations.
(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?
I have no such concerns.
(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.
I have received IPR confirmations from the three authors (Chris Boulton,
Lorenzo Miniero, and Gary Munson).
(8) Has an IPR disclosure been filed that references this document?
AT&T has filed 3 IPR disclosures regarding the predecessor draft,
draft-boulton-mediactrl-mrb: ID # 897, ID # 898, and ID # 899. In
those IPR disclosures, AT&T is listed as offering RAND licensing
terms.
Gary Munson (as an individual) has filed an IPR disclosure: ID # 1876.
This disclosure notes that the patent applications listed in the AT&T
disclosures have issued as US patents.
The AT&T IPR disclosures were submitted in 2007. The chairs solicited
feedback from the WG twice, in 2007 and 2008. There seems to have
been no response to the solicitation and no further discussion of the
IPR issues on any IETF mailing list, suggesting that no controversy
ensued. I believe that any implementers who would be worried that the
IPR would be burdensome would have spoken up.
The WGLC of 7 Feb 2012 specifically mentioned the IPR disclosures, to
provide a last opportunity for implementers to express any concerns
over the IPR situation. No objections were raised regarding IPR.
(9) How solid is the WG consensus behind this document?
A WGLC was given on the -02 version on 15 Dec 2009. It received no
responses. A second WGLC on the -12 version was given on 7 Feb 2012.
It received a handful of responses from people who had been working
directly on the draft. None of the responses directly endorsed the
draft; all proposed small improvements. There is no sign of any
dissent, although the base of support may be narrow. (However, it is
clear that the application area in question is commercially important,
and an open standard will be useful in the application of SIP.)
(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?
None that I can find any record of.
(11) Identify any ID nits the Document Shepherd has found in this
document.
I have reviewed the draft against "Checklist for Internet-Drafts (IDs)
submitted for RFC publication" and am satisfied that it meets the
requirements.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
"Registration of application/mrb-publish+xml and
application/mrb-consumer+xml" was sent to ietf-types on 19 Jan 2012.
Two responses were received from one person. The comments were minor
editorial matters which I believe do not require change to the draft.
(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?
There are no such references.
(15) Are there downward normative references references (see RFC
3967)?
There are no downward normative references.
(16) Will publication of this document change the status of any
existing RFCs?
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.
I have read through the IANA considerations section, and I confirm that
it conforms to all of these requirements.
(18) List any new IANA registries that require Expert Review for
future allocations.
This document creates no such registry.
(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.
One author (Lorenzo Miniero) checked the schemas using Eclipse and XML
Spy, and validated the examples using a JAXB-based tool.