[MEDIACTRL] Document Shepherd Writeup for draft-ietf-mediactrl-mrb-12.

"Worley, Dale R (Dale)" <dworley@avaya.com> Mon, 27 February 2012 21:45 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0065521E801A for <mediactrl@ietfa.amsl.com>; Mon, 27 Feb 2012 13:45:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.436
X-Spam-Status: No, score=-103.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id gtCqS6axspps for <mediactrl@ietfa.amsl.com>; Mon, 27 Feb 2012 13:45:56 -0800 (PST)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com []) by ietfa.amsl.com (Postfix) with ESMTP id CFE1821E800C for <mediactrl@ietf.org>; Mon, 27 Feb 2012 13:45:55 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.73,493,1325480400"; d="scan'208";a="293676800"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Feb 2012 16:45:53 -0500
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Feb 2012 16:38:51 -0500
Received: from DC-US1MBEX4.global.avaya.com ([]) by DC-US1HCEX3.global.avaya.com ([]) with mapi; Mon, 27 Feb 2012 16:45:52 -0500
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "mediactrl@ietf.org" <mediactrl@ietf.org>
Date: Mon, 27 Feb 2012 16:45:05 -0500
Thread-Topic: Document Shepherd Writeup for draft-ietf-mediactrl-mrb-12.
Thread-Index: AQHM9ZksbInd6Bmr0E6ZiBkwuozlMw==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A090D@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [MEDIACTRL] Document Shepherd Writeup for draft-ietf-mediactrl-mrb-12.
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Feb 2012 21:45:58 -0000

This version [of the document writeup form] is dated September 17,

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

The document shepherd is Dale Worley (a co-chair of Mediactrl).

In my opinion, the revision -12 is ready 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?  

I believe the document has had adequate review.  People in the WG and
representatives of major application server and media server vendors
have contributed to and reviewed this document in meetings, mailing
lists and extra MediaCtrl sessions.  At least one vendor has built an
MRB to this specification.

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

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.

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

I have no such concerns.

Specifically regarding IPR:

AT&T has filed 3 IPR disclosures regarding the predecessor draft,
draft-boulton-mediactrl-mrb: ID # 897, ID # 898, and ID # 899.  AT&T
is listed as offering RAND licensing terms.

The 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 solilcitation and no further discussion of the
IPR issues on any IETF mailing list, suggesting that no controversy
ensued.  I would expect that any implementors who worried that the IPR
would be burdensome would have spoken up.

Neither of the chairs at the time (Eric Burger and Spencer Dawkins),
nor two of the three authors (Chris Boulton and Lorenzo Miniero) work
for AT&T, so there seems to be no reason to suspect undue influence of
AT&T to promote its commercial interests.  (The third author, Gary
Munson, does work for AT&T.)

The WGLC of 7 Feb 2012 specifically mentioned the IPR disclosures, to
provide a last opportunity for implementors to express any concerns
over the IPR situation.  No objections were raised regarding IPR.

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

A WGLC was given on the -02 version on 15 Dec 2009.  It received no
responses.  A final WGLC on the -12 version was given on 7 Feb 2012.
It received no responses either.

  (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 I can find any record of.

  (1.g) Has the Document Shepherd personally verified that the 
        document satisfies all ID nits? (See the Internet-Drafts Checklist 
        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? 

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

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

Yes -- the nits tool (http://tools.ietf.org/tools/idnits/) is happy
with the draft.

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


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

Yes.  One author (Lorenzo Miniero) checked the schemas using Eclipse
and XML Spy, and validated the examples using a JAXB-based tool.

  (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

    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.  A need exists for
    intelligent, application level media service selection based on
    non-static signalling properties, especially in 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

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 implemention
    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


    Dale Worley is the document's shepherd.
    Robert Sparks is the responsible AD.