Document: Media Control Channel Framework (CFW) Call Flow Examples
draft-ietf-mediactrl-call-flows-13
(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?
Informational.
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
introduction.
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
packages.
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
implementation."
(http://www.ietf.org/proceedings/73/minutes/mediactrl.htm)
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
scenarios.
Personnel:
Who is the Document Shepherd? Who is the Responsible Area
Director?
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
schemas.
(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
why?
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
document.
(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
years.
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
years.
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 http://www.ietf.org/tools/idnits/ 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?
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?
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.
No.
(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.