Re: [MEDIACTRL] Update of AD review of draft-ietf-mediactrl-mrb (for -14) (and now for -15)

Robert Sparks <> Tue, 23 October 2012 20:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4949011E80DC for <>; Tue, 23 Oct 2012 13:47:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uy2Wf3iv6nR3 for <>; Tue, 23 Oct 2012 13:47:57 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 4789F11E80AE for <>; Tue, 23 Oct 2012 13:47:57 -0700 (PDT)
Received: from unnumerable.local ( []) (authenticated bits=0) by (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
Message-ID: <>
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
References: <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------060501030802010700080900"
Received-SPF: pass ( 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-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

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.


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 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 for example. Was that on 
> purpose?
So, this is also in

>> Section - 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'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, but 
> these two don't seem to be addressed?
>> In section,
(should be
>> 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