Media Server Control Protocol Requirements
draft-ietf-mediactrl-requirements-04

[Ballot comment]
in

' REQ-MCP-32 -  The MS shall be able to inform the AS about its status
      during an active session.'

It would be useful to be more specific what status information is required to be conveyed between a MS and an AS

PROTO Write-up

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

Spencer Dawkins (MEDIACTRL Co-chair) is document shepherd, has personally
reviewed this version of the document, and believes it is ready to forward
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?

This draft (and previous versions of the draft) have been well-discussed by
key WG members on the MEDIACTRL mailing list, and two WG participants
provided solicited reviews to the MEDIACTRL mailing list.

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

The document shepherd expects that the General Area Review Team would review
this document, but no additional review is required.

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

The document shepherd does not have specific concerns or issues with this
document.

The document shepherd does not believe any IPR disclosures are applicable to
this requirements draft.

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

The working group has discussed earlier versions of this draft on the
mailing list. The WGLC for version 00 was very quiet on the mailing list,
and discussion of this draft at the IETF 69 MEDIACTRL meeting did not raise
issues.

Draft-01 was previously submitted for publication. Draft-03 addresses the
issues raised during AD Evaluation.

Between draft-01 and draft-03, MEDIACTRL discussed isolation between
multiple applications, and requirements for this isolation have been added
to draft-03.

The shepherd believes there is WG consensus behind this document.

(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 that the shepherd is aware of. It's worth noting that design teams are
referring to this draft for requirements on protocol proposals (what we
would have hoped for).

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

From automated checking (idnits 2.05.03), no ID nits found.

From ID-Checklist Revision 1.7, no nits found.

There are no additional formal review criteria that are applicable to this
document.

(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 has split references.

[mediactrl-fw] is an informative reference dependency on an existing ID (for
a sample decomposition).

[xcon-framework] is an informative reference dependency on an existing ID
(for terminology).

(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 [RFC2434]. 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?

There are no IANA actions required for this requirements draft.

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

No sections of this requirements draft are written in a formal language.

(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

This document specifies requirements for a media server control protocol
(MCP) that enables an application server to use a media server. It
addresses the aspects of announcements, interactive voice response (IVR),
and conferencing media services.

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 working group combined two fairly mature drafts, and there was very
little controversy about the resulting draft, either on the mailing list or
in MEDIACTRL IETF meetings.

The only WGLC topic discussed on the MEDIACTRL mailing list is whether the
requirements should also explicitly mention considerations resulting from
inserting an SBC/B2BUA into the path between Application Server (AS) and
Media Server (MS). The working group co-chairs agree that core MEDIACTRL
requirements should not be held up while we work out the complex details of
SBC interaction, and we agree that there is rough consensus in the working
group to defer these considerations until we need to support this mode of
operation.

Document Quality
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?

The working group did its job.

Jon Peterson reviewed this draft for the IESG.

PROTO Write-up

> (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?
>
> Spencer Dawkins (MEDIACTRL Co-chair) is document shepherd,
> has personally
> reviewed this version of the document, and believes it is
> ready to forward
> 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?
>
> This draft (and previous versions of the draft) have been
> well-discussed by
> key WG members on the MEDIACTRL mailing list, and two WG participants
> provided solicited reviews to the MEDIACTRL mailing list.
>
> (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?
>
> The document shepherd expects that the General Area Review
> Team would review
> this document, but no additional review is required.
>
> (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.
>
> The document shepherd does not have specific concerns or
> issues with this
> document.
>
> The document shepherd does not believe any IPR disclosures
> are applicable to
> this requirements draft.
>
> (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?
>
> The working group has discussed earlier versions of this draft on the
> mailing list. The WGLC for version 00 was very quiet on the
> mailing list,
> and discussion of this draft at the IETF 69 MEDIACTRL meeting
> did not raise
> issues.
>
> The shepherd believes there is WG consensus behind this document.
>
> (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 that the shepherd is aware of. It's worth noting that
> design teams are
> referring to this draft for requirements on protocol
> proposals (what we
> would have hoped for).
>
> (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?
>
> From automated checking (idnits 2.04.16), no ID nits found.
>
> From ID-Checklist Revision 1.7, no nits found.
>
> There are no additional formal review criteria that are
> applicable to this
> document.
>
> (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 has split references.
>
> [mediactrl-fw] is an informative reference dependency on an
> existing ID (for
> a sample decomposition).
>
> [xcon-framework] is an informative reference dependency on an
> existing ID
> (for terminology).
>
> (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
> [RFC2434]. 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?
>
> There are no IANA actions required for this requirements draft.
>
> (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?
>
> No sections of this requirements draft are written in a
> formal language.
>
> (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
>
> This document specifies requirements for a media server
> control protocol
> (MCP) that enables an application server to use a media server. It
> addresses the aspects of announcements, interactive voice
> response (IVR),
> and conferencing media services.
>
> 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 working group combined two fairly mature drafts, and
> there was very
> little controversy about the resulting draft, either on the
> mailing list or
> in MEDIACTRL IETF meetings.
>
> The only recent topic discussed on the MEDIACTRL mailing list
> is whether the
> requirements should also explicitly mention considerations
> resulting from
> inserting an SBC/B2BUA into the path between Application
> Server (AS) and
> Media Server (MS). The working group co-chairs agree that
> core MEDIACTRL
> requirements should not be held up while we work out the
> complex details of
> SBC interaction, and we agree that there is rough consensus
> in the working
> group to defer these considerations until we need to support
> this mode of
> operation.
>
> Document Quality
> 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?
>
> The working group did its job.
>
> Jon Peterson reviewed this draft for the IESG.
>