[MEDIACTRL] Update of AD review of draft-ietf-mediactrl-mrb (for -14)

Robert Sparks <rjsparks@nostrum.com> Mon, 20 August 2012 16:08 UTC

Return-Path: <rjsparks@nostrum.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 49BF521F84F7 for <mediactrl@ietfa.amsl.com>; 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-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id u+RAfrovzf-Q for <mediactrl@ietfa.amsl.com>; 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 <mediactrl@ietf.org>; Mon, 20 Aug 2012 09:08:00 -0700 (PDT)
Received: from unnumerable.local ([]) (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 <mediactrl@ietf.org>; 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 <rjsparks@nostrum.com>
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: 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 <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, 20 Aug 2012 16:08:01 -0000

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?

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