From internet-drafts@ietf.org Mon Aug 20 01:19:20 2012 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9367C21F86AF; Mon, 20 Aug 2012 01:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxaimQUDniPI; Mon, 20 Aug 2012 01:19:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB49B21F862A; Mon, 20 Aug 2012 01:19:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120820081919.20742.47926.idtracker@ietfa.amsl.com> Date: Mon, 20 Aug 2012 01:19:19 -0700 Cc: mediactrl@ietf.org Subject: [MEDIACTRL] I-D Action: draft-ietf-mediactrl-mrb-14.txt X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 08:19:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Media Server Control Working Group of the= IETF. Title : Media Resource Brokering Author(s) : Chris Boulton Lorenzo Miniero Gary Munson Filename : draft-ietf-mediactrl-mrb-14.txt Pages : 143 Date : 2012-08-20 Abstract: 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. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with 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 Servers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mediactrl-mrb-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mediactrl-mrb-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rjsparks@nostrum.com Mon Aug 20 09:08:01 2012 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BF521F84F7 for ; Mon, 20 Aug 2012 09:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+RAfrovzf-Q for ; Mon, 20 Aug 2012 09:08:00 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D74921F84EC for ; Mon, 20 Aug 2012 09:08:00 -0700 (PDT) Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7KG7w58099311 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 20 Aug 2012 11:07:59 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <503260DE.1080401@nostrum.com> Date: Mon, 20 Aug 2012 11:07:58 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mediactrl@ietf.org References: <50325FBC.1090806@nostrum.com> In-Reply-To: <50325FBC.1090806@nostrum.com> X-Forwarded-Message-Id: <50325FBC.1090806@nostrum.com> Content-Type: multipart/alternative; boundary="------------080501070101020402000407" Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: [MEDIACTRL] Update of AD review of draft-ietf-mediactrl-mrb (for -14) X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 16:08:01 -0000 This is a multi-part message in MIME format. --------------080501070101020402000407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Has the updated schema been validated? (Who did the work there - it's worth giving them credit in the writeup). The placement of the new text in 5.2.2.1 introduces a small problem. The sentence that follows it ("The following additional steps") could be read to only apply if the INVITE was offerless. I suggest breaking that last sentence off the paragraph into a paragraph of its own that starts the list. These comments from my review of -12 do not appear to have been handled. Apologies if I'm missing where they were discussed: > The phrase "compliant with the specification in the related IANA > registry (e.g., "msc-ivr/1.0"), for which the <...> applies" occurs > throughout the document. It is not precise. Which related IANA > registry? I think you are trying to say "as it appears in 'Control > Packages' subregistry of the 'IANA Media Control Channel Framework > Parameters' registry. Since this occurs so often, it might be worth > figuring out a way to present this using a reference. This was adjusted in many, but not all places it occurred in the document. It still occurs in 5.2.5.1.1.2 for example. Was that on purpose? > > Section 5.1.3.1 - Please clarify the scope of uniqueness of id. > Is it the intent that these only be unique within the scope of a given > MS, MRB pair? Or is there a need for it to be unique across all the > subscriptions concurrent in a given deployment? > > Section 5.1.3.1's description of confuses what the MRB is > asking for vs what the MS gave it. > This may be a structural problem - this section is about requests, and > its description of is written from a request > point of view, but is reused by responses in 5.1.5. > This section should be clear that this is just the duration the MRB is > asking for, and that the MS may provide a different value, and if it > does, that's what to use to determine when to "subscribe again". It's > also only implicit right now that if a success response doesn't say > anything about the duration of the subscription, the duration is what > was requested (or at least that's how I'm reading the document). > Please make that clearer. (Editorial question: Why is the discussion > of this request and response separated by the (really long) discussion > of the notification?) This got handled for the similar questions I asked about 5.1.4.1, but these two don't seem to be addressed? > In section 5.1.4.14, what does it mean to "support" these kinds of > tone? Can you provide pointers to help explain how this will be used? Was this discussed? And finally - I am still very nervous about the inclusion of a civic address with no discussion of the potential security ramifications of exposing that address or of using that address as part of computation (which the newly added text says an element may do). The security considerations section should at least call out that there is risk here. RjS --------------080501070101020402000407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Has the updated schema been validated? (Who did the work there - it's worth giving them credit in the writeup).

The placement of the new text in 5.2.2.1 introduces a small problem. The sentence that follows it ("The following additional steps") could be read to only apply if the INVITE was offerless. I suggest breaking that last sentence off the paragraph into a paragraph of its own that starts the list.

These comments from my review of -12 do not appear to have been handled. Apologies if I'm missing where they were discussed:

The phrase "compliant with the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the <...> applies" occurs throughout the document. It is not precise. Which related IANA registry? I think you are trying to say "as it appears in 'Control Packages' subregistry of the 'IANA Media Control Channel Framework Parameters' registry. Since this occurs so often, it might be worth figuring out a way to present this using a reference.
This was adjusted in many, but not all places it occurred in the document.  It still occurs in 5.2.5.1.1.2 for example. Was that on purpose?


Section 5.1.3.1 - Please clarify the scope of uniqueness of id.
Is it the intent that these only be unique within the scope of a given MS, MRB pair? Or is there a need for it to be unique across all the subscriptions concurrent in a given deployment?

Section 5.1.3.1's description of <expires> confuses what the MRB is asking for vs what the MS gave it.
This may be a structural problem - this section is about requests, and its description of <subscription> is written from a request
point of view, but <subscription> is reused by responses in 5.1.5.  This section should be clear that this is just the duration the MRB is asking for, and that the MS may provide a different value, and if it does, that's what to use to determine when to "subscribe again". It's also only implicit right now that if a success response doesn't say anything about the duration of the subscription, the duration is what was requested (or at least that's how I'm reading the document). Please make that clearer. (Editorial question: Why is the discussion of this request and response separated by the (really long) discussion of the notification?)
This got handled for the similar questions I asked about 5.1.4.1, but these two don't seem to be addressed?

In section 5.1.4.14, what does it mean to "support" these kinds of tone? Can you provide pointers to help explain how this will be used?
Was this discussed?

And finally - I am still very nervous about the inclusion of a civic address with no discussion of the potential security ramifications of exposing that address or of using that address as part of computation (which the newly added text says an element may do). The security considerations section should at least call out that there is risk here.

RjS


--------------080501070101020402000407-- From dworley@avaya.com Fri Aug 24 09:09:37 2012 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C651921F861A for ; Fri, 24 Aug 2012 09:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.305 X-Spam-Level: X-Spam-Status: No, score=-103.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CZPg2GYVSma for ; Fri, 24 Aug 2012 09:09:37 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3C71121F860E for ; Fri, 24 Aug 2012 09:09:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0KAEumN1DGmAcF/2dsb2JhbABFuWEEA3uBB4InEihRARUpQicEEwgah2uYBYQjnSGLIoYXYAObU4oWgn+BRQ X-IronPort-AV: E=Sophos;i="4.77,820,1336363200"; d="scan'208";a="363675877" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 Aug 2012 12:05:00 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Aug 2012 12:03:49 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 24 Aug 2012 12:09:35 -0400 From: "Worley, Dale R (Dale)" To: "mediactrl@ietf.org" Date: Fri, 24 Aug 2012 12:09:34 -0400 Thread-Topic: Change in my e-mail address Thread-Index: AQHNghLa1b0J+WGWOk2F0dmz8RI45w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MEDIACTRL] Change in my e-mail address X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 16:09:37 -0000 Due to a change in my employment, my e-mail address is now: worley@ariadne.com please update your address books for any discussions of the draft that you want to include me in. Thanks, Dale=