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

Robert Sparks <rjsparks@nostrum.com> Tue, 23 October 2012 20:47 UTC

Return-Path: <rjsparks@nostrum.com>
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 <mediactrl@ietfa.amsl.com>; 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 <mediactrl@ietfa.amsl.com>; 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 <mediactrl@ietf.org>; 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 <rjsparks@nostrum.com>
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 <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: 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.

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