From internet-drafts@ietf.org Fri Oct 5 08:22:05 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 2740A21F86AF; Fri, 5 Oct 2012 08:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 wVFEL13fbS0t; Fri, 5 Oct 2012 08:22:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CFC21F844D; Fri, 5 Oct 2012 08:22:04 -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.34 Message-ID: <20121005152204.32215.45811.idtracker@ietfa.amsl.com> Date: Fri, 05 Oct 2012 08:22:04 -0700 Cc: mediactrl@ietf.org Subject: [MEDIACTRL] I-D Action: draft-ietf-mediactrl-mrb-15.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: Fri, 05 Oct 2012 15:22:05 -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-15.txt Pages : 143 Date : 2012-10-05 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-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mediactrl-mrb-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rjsparks@nostrum.com Mon Oct 8 12:53:14 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 5F7291F041C; Mon, 8 Oct 2012 12:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 M557pgF8DQln; Mon, 8 Oct 2012 12:53:13 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3573821F87C0; Mon, 8 Oct 2012 12:53:12 -0700 (PDT) Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q98JrCDM000689 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 8 Oct 2012 14:53:12 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <50732F28.5000309@nostrum.com> Date: Mon, 08 Oct 2012 14:53:12 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: ietf-types@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: mediactrl@ietf.org Subject: [MEDIACTRL] Updated review requested for the registration of types application/mrb-publish+xml and application/mrb-consumer+xml 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, 08 Oct 2012 19:53:14 -0000 IETF-types reviewers: Following up on Please review the updated registration details at and The To: line in each block will be updated after IETF-LC. Thanks, RjS From iesg-secretary@ietf.org Mon Oct 8 13:22:02 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 1E6541F0C42; Mon, 8 Oct 2012 13:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 p4+atrDYZ0qg; Mon, 8 Oct 2012 13:22:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3A321F8811; Mon, 8 Oct 2012 13:22:01 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121008202201.23249.81705.idtracker@ietfa.amsl.com> Date: Mon, 08 Oct 2012 13:22:01 -0700 Cc: mediactrl@ietf.org Subject: [MEDIACTRL] Last Call: (Media Resource Brokering) to Proposed Standard X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 20:22:02 -0000 The IESG has received a request from the Media Server Control WG (mediactrl) to consider the following document: - 'Media Resource Brokering' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-10-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1876/ From rjsparks@nostrum.com Tue Oct 23 13:47:58 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 4949011E80DC for ; Tue, 23 Oct 2012 13:47:58 -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 uy2Wf3iv6nR3 for ; Tue, 23 Oct 2012 13:47:57 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4789F11E80AE for ; Tue, 23 Oct 2012 13:47:57 -0700 (PDT) Received: from unnumerable.local (pool-173-57-93-208.dllstx.fios.verizon.net [173.57.93.208]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9NKlt9N042495 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 23 Oct 2012 15:47:56 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <5087027B.8090008@nostrum.com> Date: Tue, 23 Oct 2012 15:47:55 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mediactrl@ietf.org, draft-ietf-mediactrl-mrb@tools.ietf.org References: <50325FBC.1090806@nostrum.com> <503260DE.1080401@nostrum.com> In-Reply-To: <503260DE.1080401@nostrum.com> Content-Type: multipart/alternative; boundary="------------060501030802010700080900" Received-SPF: pass (nostrum.com: 173.57.93.208 is authenticated by a trusted mechanism) Subject: Re: [MEDIACTRL] Update of AD review of draft-ietf-mediactrl-mrb (for -14) (and now for -15) 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: Tue, 23 Oct 2012 20:47:58 -0000 This is a multi-part message in MIME format. --------------060501030802010700080900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Editors - IETF LC finished for this document. Looking through the history, I'm not seeing a response to _this_ message, and the questions here all apply to -15 still. I would like a revised ID addressing at least the IANA question. RjS On 8/20/12 11:07 AM, Robert Sparks wrote: > 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? So, this is also in 5.2.5.1.2.3. 5.2.5.1.2.4. 5.2.5.1.3.3. 5.2.5.1.3.4. 5.2.5.1.3.5. 5.1.5.12. 5.1.5.15. 5.1.5.17. > >> >> 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, (should be 5.1.5.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 > > --------------060501030802010700080900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Editors -

IETF LC finished for this document.

Looking through the history, I'm not seeing a response to _this_ message, and the questions here all apply to -15 still.

I would like a revised ID addressing at least the IANA question.

RjS

On 8/20/12 11:07 AM, Robert Sparks wrote:
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?
So, this is also in
5.2.5.1.2.3.
5.2.5.1.2.4.
5.2.5.1.3.3.
5.2.5.1.3.4. 
5.2.5.1.3.5.
5.1.5.12.
5.1.5.15.
5.1.5.17.


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,
(should be 5.1.5.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



--------------060501030802010700080900-- From lorenzo@meetecho.com Mon Oct 29 09:07:40 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 2F45D21F855F for ; Mon, 29 Oct 2012 09:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.881 X-Spam-Level: * X-Spam-Status: No, score=1.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 Y5mJVrEuTCAn for ; Mon, 29 Oct 2012 09:07:39 -0700 (PDT) Received: from smtpdg10.aruba.it (smtpdg10.aruba.it [62.149.158.240]) by ietfa.amsl.com (Postfix) with ESMTP id BC79D21F8731 for ; Mon, 29 Oct 2012 09:07:32 -0700 (PDT) Received: from rainpc ([82.59.116.200]) by smtpcmd04.ad.aruba.it with bizsmtp id H47P1k0044KVjVN0147R8n; Mon, 29 Oct 2012 17:07:28 +0100 Date: Mon, 29 Oct 2012 17:07:22 +0100 From: Lorenzo Miniero To: Robert Sparks Message-ID: <20121029170722.24fc909b@rainpc> In-Reply-To: <5087027B.8090008@nostrum.com> References: <50325FBC.1090806@nostrum.com> <503260DE.1080401@nostrum.com> <5087027B.8090008@nostrum.com> Organization: Meetecho X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: draft-ietf-mediactrl-mrb@tools.ietf.org, mediactrl@ietf.org Subject: Re: [MEDIACTRL] Update of AD review of draft-ietf-mediactrl-mrb (for -14) (and now for -15) 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, 29 Oct 2012 16:07:40 -0000 Dear Robert et. all, actually I did reply to that message, the day after that. I'm pasting the reply inline here, hoping it did actually address your concerns. To summarize, there actually still are a couple of things to fix: 1. you're right about the IANA question, we did a search&replace for all the parts where the issue occurred (in the v13) but not for all of them, and then forgot to complete the job. We'll fix this in the new version. 2. We also forgot to add the civicAddress thing to the Security Considerations. We added text in the elements description to specify its optional and implementation specific usage, but it still needs to be clarified in the Security section. We'll fix this in the new version as well. Considering the Internet Draft Cut-off, do we need to actually publish the draft, or due to its current state should we proceed in a different way for it? Thanks, Lorenzo -------- Original Message -------- Subject: Re: MRB Proposed Text Date: Tue, 21 Aug 2012 12:04:11 +0200 From: Lorenzo Miniero Organisation: Meetecho To: Robert Sparks CC: Eric Burger , Worley Dale , Boulton Chris Hi Robert, please see inline, On Mon, 20 Aug 2012 11:03:08 -0500 Robert Sparks wrote: > I _would_ like an updated writeup using the new template. Please provide > a link to my AD review of (-12) > in the archives in the review section of that writeup. > > The only thing that might be WGLC is the change to the schema in, for > example, 5.1.4.21. (The addition > of the keying-mechanism element). It's ok with me to make sure that gets > reviewed in IETF LC instead of waiting for an additional WGLC. > > Has the updated schema been validated? (Who did the work there - it's > worth giving them credit in the writeup). > I validated the schema after each change, since I also needed to update the call flows accordingly. > 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. > > There are a few things from my original AD review that I'm not finding a > response on list or in the document to. Apologies if we resolved them > some other way - if so, help me find a record of that to point to. Most > of them are things that won't hold the document up, (the IANA should get > fixed before IETF LC though), but they all should be addressed before we > get to the IESG. > > They are: > > > 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? > Probably something that survived the search&replace hunt. > > > > 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? > Quoting my old mail from the 9th of July: "I moved mrbresponse right after mrbrequest, so the indexes of the related sections changed. I don't have the doc and diff in front of me right now (they're at my lab and I'm at home right now) but I should have clarified that. I'll check if I forgot to add the text I wanted to put in there: some text was already in place to address this, so it was a minor revision anyway." What you're looking for should be explained at the end of 5.1.3.1, where we explain the element behaviour. > > 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? > I remember discussing this, but I'm not finding the resolution on the > list or here. > I did answer about this, providing 3-4 links from the ML that showed when this was asked for/discussed in the ML, and how it was presented. Unfortunately my mail provider sucks and I lost all my sent mail, so I'll try and dig the ML again for the links. In case the mail didn't get lost, though, you should have it in some of my older replies anyway (I guess 9-10th of July, since that's when I published v13). > 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. > You're right, we planned to add some text about that but I guess this slipped through when we worked on the doc. We'll add some text in the security considerations to clarify this. By the way, that old mail with links to the ML also had information on when and why this civic was introduced (which if I recall correctly is one of the other points you made at the time). Lorenzo > RjS > > > On 8/20/12 9:11 AM, Eric Burger wrote: > > Dale: Think we need another WGLC? I doubt it. What do you think? > > Presuming not, do we need another shepherd writeup? > > > > RJS: Thoughts? > > > > On Aug 20, 2012, at 4:20 AM, Chris Boulton wrote: > > > >> http://www.ietf.org/id/draft-ietf-mediactrl-mrb-14.txt > >> > >> Chris. > >> > >> > >> On 17/08/2012 15:01, Eric Burger wrote: > >>> It's only 130 pages. Let's be done with it. > >>> > >>> On Aug 16, 2012, at 5:32 AM, Chris Boulton wrote: > >>> > >>>> All, > >>>> > >>>> Find attached version -14 which I have scrubbed and added the > >>>> missing text. Shall I just go ahead and submit? Also checked with > >>>> IDNits. > >>>> > >>>> Thanks. > >>>> > >>>> Chris. > >>>> > >>>> > >>>> On 30/07/2012 11:26, Eric Burger wrote: > >>>>> Lovely. > >>>>> > >>>>> On Jul 29, 2012, at 11:36 PM, Chris Boulton wrote: > >>>>> > >>>>>> Take two: > >>>>>> > >>>>>> The media resource request information, as defined by the > >>>>>> element fromSection 11 , is carried in a SIP > >>>>>> INVITE request. The INVITE request will be constructed as it would > >>>>>> have been to connect to a media server, as defined by the Media > >>>>>> Control Channel Framework [RFC6230 ]. It should be noted that this > >>>>>> specification does not exclude the use of an offer-less INVITE as > >>>>>> defined in section [ref] of [ref]. Using offer-less INVITE messages > >>>>>> to an MRB can potentially cause confusion when applying resource selection > >>>>>> algorithms and an MRB, like any other SIP device, can choose to reject with > >>>>>> a 4xx response. For an offer-less INVITE to be treated appropriately, > >>>>>> additional contextual information would need to be provided > >>>>>> with the request which is out of the scope for this document. The > >>>>>> following additional steps MUST be followed when using the Consumer interface: > >>>>>> If this is OK I will move on to my final review. > >>>>>> > >>>>>> Thanks. > >>>>>> > >>>>>> Chris. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 27/07/2012 14:30, Eric Burger wrote: > >>>>>>> Since any SIP device can choose to reject an offerless INVITE, > >>>>>>> why not say so and remind the reader the MRB is not special. > >>>>>>> Return a 4xx and be done with it. > >>>>>>> > >>>>>>> -- > >>>>>>> Sent from my mobile device. Thanks be to lemonade! > >>>>>>> http://www.standardstrack.com/ietf/lemonade/ > >>>>>>> > >>>>>>> > >>>>>>> -----Original message----- > >>>>>>> > >>>>>>> *From: *Chris Boulton * > >>>>>>> To: *lorenzo@meetecho.com, rjsparks@nostrum.com, > >>>>>>> dworley@avaya.com, Eric Burger * > >>>>>>> Sent: *Fri, Jul 27, 2012 11:39:34 GMT+00:00* > >>>>>>> Subject: *MRB Proposed Text > >>>>>>> > >>>>>>> All, > >>>>>>> > >>>>>>> Proposed additional text to section 5.2.2.1 as discussed on the list: > >>>>>>> > >>>>>>> > >>>>>>> The media resource request information, as defined by the > >>>>>>> element fromSection 11 , is carried in a SIP > >>>>>>> INVITE request. The INVITE request will be constructed as it would > >>>>>>> have been to connect to a media server, as defined by the Media > >>>>>>> Control Channel Framework [RFC6230 ]. It should be noted that this > >>>>>>> specification does not exclude the use of an offer-less INVITE as > >>>>>>> defined in section [ref] of [ref]. Using offer-less INVITE messages > >>>>>>> to an MRB is likely to cause confusion when applying resource selection > >>>>>>> algorithms. Additional contextual information would need to be provided > >>>>>>> with the request which is out of the scope for this document. An MRB > >>>>>>> has the option to reject an offer-less INVITE if it does not feel it has > >>>>>>> the appropriate level of information to process the request. The > >>>>>>> following additional steps MUST be followed when using the Consumer interface: > >>>>>>> > >>>>>>> Comments please? > >>>>>>> > >>>>>>> Once this is done I will do a final scrub and text edit. > >>>>>>> Hopefully aim for the middle of next week for submission. > >>>>>>> > >>>>>>> Thanks. > >>>>>>> > >>>>>>> Chris. > >>>>>>> > >>>>>> > >> > >> -- > >> Chris Boulton > >> CTO & Co-founder > >> NS-Technologies > >> m: +44.7876.476681 > > > On Tue, 23 Oct 2012 15:47:55 -0500 Robert Sparks wrote: > Editors - > > IETF LC finished for this document. > > Looking through the history, I'm not seeing a response to _this_ > message, and the questions here all apply to -15 still. > > I would like a revised ID addressing at least the IANA question. > > RjS > > On 8/20/12 11:07 AM, Robert Sparks wrote: > > 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? > So, this is also in > > 5.2.5.1.2.3. > 5.2.5.1.2.4. > 5.2.5.1.3.3. > 5.2.5.1.3.4. > 5.2.5.1.3.5. > 5.1.5.12. > 5.1.5.15. > 5.1.5.17. > > > > >> > >> 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, > (should be 5.1.5.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 > > > > > -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From rjsparks@nostrum.com Mon Oct 29 10:47:12 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 E81A521F86F3 for ; Mon, 29 Oct 2012 10:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ptxoFdMDb+Nv for ; Mon, 29 Oct 2012 10:47:12 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 659DE21F86EA for ; Mon, 29 Oct 2012 10:47:12 -0700 (PDT) Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q9THlBJX060599 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 29 Oct 2012 12:47:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <508EC11F.6060304@nostrum.com> Date: Mon, 29 Oct 2012 12:47:11 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Lorenzo Miniero References: <50325FBC.1090806@nostrum.com> <503260DE.1080401@nostrum.com> <5087027B.8090008@nostrum.com> <20121029170722.24fc909b@rainpc> In-Reply-To: <20121029170722.24fc909b@rainpc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: draft-ietf-mediactrl-mrb@tools.ietf.org, mediactrl@ietf.org Subject: Re: [MEDIACTRL] Update of AD review of draft-ietf-mediactrl-mrb (for -14) (and now for -15) 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, 29 Oct 2012 17:47:13 -0000 On 10/29/12 11:07 AM, Lorenzo Miniero wrote: > Dear Robert et. all, > > actually I did reply to that message, the day after that. I'm pasting the reply inline here, hoping it did actually address your concerns. > > To summarize, there actually still are a couple of things to fix: > > 1. you're right about the IANA question, we did a search&replace for all the parts where the issue occurred (in the v13) but not for all of them, and then forgot to complete the job. We'll fix this in the new version. > > 2. We also forgot to add the civicAddress thing to the Security Considerations. We added text in the elements description to specify its optional and implementation specific usage, but it still needs to be clarified in the Security section. We'll fix this in the new version as well. > > > Considering the Internet Draft Cut-off, do we need to actually publish the draft, or due to its current state should we proceed in a different way for it? If you have a draft ready this week, mail the txt and xml to me, copying iesg-secretary@ietf.org, asking for manual posting. I'll approve it, and the secretariat will put it into the repository. If you don't have it quite ready, the automated submission tools will open back up next Monday and you can submit the way you have in the past. RjS From lorenzo@meetecho.com Mon Oct 29 10:52:06 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 B757121F8727 for ; Mon, 29 Oct 2012 10:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.581 X-Spam-Level: X-Spam-Status: No, score=0.581 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 z1TkW-huGsSU for ; Mon, 29 Oct 2012 10:52:06 -0700 (PDT) Received: from smtpdg7.aruba.it (smtpdg7.aruba.it [62.149.158.237]) by ietfa.amsl.com (Postfix) with ESMTP id 87F7721F8731 for ; Mon, 29 Oct 2012 10:52:05 -0700 (PDT) Received: from rainpc ([82.59.116.200]) by smtpcmd03.ad.aruba.it with bizsmtp id H5ry1k00v4KVjVN015ryHy; Mon, 29 Oct 2012 18:52:03 +0100 Date: Mon, 29 Oct 2012 18:51:58 +0100 From: Lorenzo Miniero To: Robert Sparks Message-ID: <20121029185158.0f5fb3cb@rainpc> In-Reply-To: <508EC11F.6060304@nostrum.com> References: <50325FBC.1090806@nostrum.com> <503260DE.1080401@nostrum.com> <5087027B.8090008@nostrum.com> <20121029170722.24fc909b@rainpc> <508EC11F.6060304@nostrum.com> Organization: Meetecho X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: draft-ietf-mediactrl-mrb@tools.ietf.org, mediactrl@ietf.org Subject: Re: [MEDIACTRL] Update of AD review of draft-ietf-mediactrl-mrb (for -14) (and now for -15) 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, 29 Oct 2012 17:52:06 -0000 On Mon, 29 Oct 2012 12:47:11 -0500 Robert Sparks wrote: > On 10/29/12 11:07 AM, Lorenzo Miniero wrote: > > Dear Robert et. all, > > > > actually I did reply to that message, the day after that. I'm pasting the reply inline here, hoping it did actually address your concerns. > > > > To summarize, there actually still are a couple of things to fix: > > > > 1. you're right about the IANA question, we did a search&replace for all the parts where the issue occurred (in the v13) but not for all of them, and then forgot to complete the job. We'll fix this in the new version. > > > > 2. We also forgot to add the civicAddress thing to the Security Considerations. We added text in the elements description to specify its optional and implementation specific usage, but it still needs to be clarified in the Security section. We'll fix this in the new version as well. > > > > > > Considering the Internet Draft Cut-off, do we need to actually publish the draft, or due to its current state should we proceed in a different way for it? > > If you have a draft ready this week, mail the txt and xml to me, copying > iesg-secretary@ietf.org, asking for manual posting. I'll approve it, and > the secretariat will put it into the repository. > > If you don't have it quite ready, the automated submission tools will > open back up next Monday and you can submit the way you have in the past. > > RjS Ok, I'll work on it in the next few days. Thanks, Lorenzo -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com