Shepherd writeup

Document:  Media Control Channel Framework (CFW) Call Flow Examples

	(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 is the proper type, as the document doesn't define any new
protocol/framework/architecture, but rather shows examples of the
usage of existing protocols (especially RFCs 5239, 5567, 6230, 6231,
6505, 6917, i.e., the "media control" protocols) by means of state and
sequence diagrams and message contents.

The "Informational" status is indicated on the title page header.

	(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:

	Relevant content can frequently be found in the abstract
	and/or introduction of the document. If not, this may be an
	indication that there are deficiencies in the abstract or

This document presents a series of MEDIACTRL-related call flows,
presenting client/server state diagrams, message sequence diagrams,
and message contents. It is a reference for the whole MEDIACTRL
specification for implementers and protocol researchers alike, and all
the flows are modeled from an implementation of the framework and its
	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?

Several participants in the WG have advocated a call flows document.
The advocates included Jon Peterson, who was the AD at the time the
Mediactrl WG was chartered.

	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?

Lorenzo Miniero reports that interoperability tests were carried out
at IETF73 (Minneapolis, Nov 2008) with implementations from HP (OCMP)
and Dialogic testing scenarios illustrated by this document.  The
minutes report other companies that were planning an implementation at
the time: "Stephan notes that implementation is be planned on
Broadsoft for the spring. Alan notes that Ditech is also planning an

As an examples document, the document does not specify any protocol.
All the contained examples were produced by running the scenarios
using an existing implementation of the MEDIACTRL specification by the
authors themselves. A thorough review was done by Dale Worley, who
helped tackle some relevant inconsistencies in the presented


	Who is the Document Shepherd? Who is the Responsible Area

The Document Shepherd is Dale Worley. The Responsible Area Director is
Richard Barnes.

	(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 (Dale Worley) reviewed the document.  The
Shepherd identified a number of possible improvements to the document,
including:  adding definitions to the glossary for the benefit of
people not familiar with the Media Control effort, discussing the
additional configuration needs to obtain benefit from "IUMM mode"
operation, removing from the examples the
draft-boulton-mmusic-sdp-control-package-attribute extension (which
was used in the implementation but has not progressed to
standardization), and clarifying definition of the "gain" parameter.
All of these issues were completely resolved.

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

The Document Shepherd is satisfied with the review; the document
should be easily comprehensible to a first-time reader of the relevant
RFCs, and useful to any implementer of the RFCs.

	(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.

As there's no new protocol being specified, there is no need for
specialized review: the specification RFCs (framework, packages, MRB)
all have been through those processes, and the call flows document
just applies what those documents specify. The XML message contents
themselves have been automatically validated against the respective

	(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.

The Document Shepherd has no concerns regarding technical content.
The English usage may need some cleaning up, as all the authors are
non-native English speakers, but the Shepherd believes those needs are
within the capabilities of the RFC Editor.

	(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

Yes, all four authors have confirmed compliance with BCPs 78 and 79.

Of course, these confirmations are for any IPR that is revealed
draft-ietf-mediactrl-call-flows itself, and not for revelations in the
documents that it references (especially RFCs 6230, 6231, 6505, 6917,
and 5239), which define the protocols which are illustrated in this

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

None have been filed referencing this document.

Regarding the RFCs which could be considered to be illustrated by the
contents of draft-ietf-mediactrl-call-flows, that is, RFCs 6230, 6231,
6505, 6917, and 5239, there are IPR disclosures filed regarding RFC
6917.  These disclosures have been well-known to the WG for several

There is another draft, draft-boulton-mediactrl-mrb-location-function,
on related subject matter, regarding which an IPR disclosure has been
made.  This disclosure has been well-known to the WG for several

There is an expired draft, draft-sisalem-mediactrl-mrbctrl, on related
subject matter, regarding which an IPR disclosure has been made.  A
chair (Eric Burger) has contacted the claimant (Tekelec), and Tekelec
has declined to file an IPR disclosure on this patent regarding RFC
6917 (or regarding this document).  This disclosure has been
well-known to the WG for several years.

	(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?

Several active participants in the WG have advocated the addition of
such a call flows document to the milestones, and no one was opposed
to it. The only concern was expressed by one of the WG chairs who
feared protocol implementers would make use of the call flows document
rather than the standards as the basis of an implementation, and thus
the document was reviewed to ensure it contained no usages which are
not the current best practices.

	(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.)

None that the chairs or Shepherd are aware of.

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

The warnings found by the ID-Nits tool are:

1. == Missing Reference: 'AS1' is mentioned on line 7071, but not defined

This is due to a descriptive phrase "join UAC&conf[AS1])" in which
"conf[...]" is syntax, not a reference.

2. -- Found something which looks like a code comment

This warning points to the uses of the XML element <h248-code>, which
are correct relative to the relevant XML schema.

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

The document specifies no new protocol or extension, so such a review
was not needed.

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


	(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

All normative references are RFCs.

(In the -12 version, there was a reference to an individual draft
(draft-boulton-mmusic-sdp-control-package-attribute) whose progress
toward standardization is currently unclear.  The reference (and the
use of the attribute which it specifies) were removed in the latest
version (-13) of the document.)

	(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.


(In the -12 version, there were two normative references that are not
standards track:  RFC2606 (Reserved Top Level DNS Names) is a BCP, and
RFC3725 (BCPs for Third Party Call Control (3pcc) in SIP) is a BCP.
Both were changed to informative references in the latest (-13)
version of the document.)

	(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, this document is just informational.

	(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).

The document specifies no new protocol or extension, so there is no
IANA Considerations section.

	(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.

The document specifies no new protocol or extension, so there is no
IANA Considerations section.

	(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.

According to the authors, all of the examples come from a real
implementation (with the use of the
draft-boulton-mmusic-sdp-control-package-attribute extension removed).
In addition, all XML in the examples has been validated using a tool
the authors themselves wrote for the purpose, which extracts XML
content from the draft and validates it using the related XSD schema
from the original specifications.