Subject: [MEDIACTRL] Re: Shepherd writeup for draft-ietf-mediactrl-requirements-01.txt

From: Spencer Dawkins <[email-masked]>
Date: Tue, 15 Jan 2008 10:27:49 -0600

Hi, Jon,

We're writing to request publication for
draft-ietf-mediactrl-requirements-03.txt as an Informational RFC.

Version 01 of this draft was previously submitted for publication. We 
believe that 03 addresses the issues you identified in AD Evaluation (thanks 
for your guidance here).

The shepherd writeup follows - it has been slightly updated for -03, with 
additional text in section (1.e), we used the current nits checker for -03, 
etc.

Thanks,

Spencer

(This writeup uses the template dated February 1, 2007)

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

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl