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 > >
- [MEDIACTRL] Update of AD review of draft-ietf-med… Robert Sparks
- Re: [MEDIACTRL] Update of AD review of draft-ietf… Robert Sparks
- Re: [MEDIACTRL] Update of AD review of draft-ietf… Lorenzo Miniero
- Re: [MEDIACTRL] Update of AD review of draft-ietf… Robert Sparks
- Re: [MEDIACTRL] Update of AD review of draft-ietf… Lorenzo Miniero