[apps-discuss] APPSDIR review of draft-ietf-mediactrl-mrb-12

Claudio Allocchio <Claudio.Allocchio@garr.it> Sun, 11 March 2012 10:05 UTC

Return-Path: <Claudio.Allocchio@garr.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6589621F866D for <apps-discuss@ietfa.amsl.com>; Sun, 11 Mar 2012 03:05:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.407
X-Spam-Level:
X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=1.192, BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkhCe5BkZZjB for <apps-discuss@ietfa.amsl.com>; Sun, 11 Mar 2012 03:05:27 -0700 (PDT)
Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF9721F8667 for <apps-discuss@ietf.org>; Sun, 11 Mar 2012 03:04:53 -0700 (PDT)
Received: from mac-allocchio3.garrtest.units.it (mac-allocchio3.garrtest.units.it [140.105.201.3] (may be forged)) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q2BA4mU0078979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Mar 2012 11:04:49 +0100 (CET)
X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q2BA4mU0078979
DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=iY6/492PLoOtCGZwx92o0J+pQMSaYzcS5I8Me2CBc2wvDSfpWNyWXOGtz9qdzGQKC xiM/i+G5yBl3U159z8a2twiecNITA4T8dT/clneuoteFYx5QpGIvVEW4lNbjFfcwkgq d9spFpfnYfh253S8t0nSoXOj+IMtE/AzYU6WepU=
Date: Sun, 11 Mar 2012 11:04:48 +0100
From: Claudio Allocchio <Claudio.Allocchio@garr.it>
X-X-Sender: claudio@mac-allocchio3.local
To: apps-discuss@ietf.org, draft-ietf-mediactrl-mrb.all@tools.ietf.org
Message-ID: <alpine.OSX.2.02.1203091404140.7425@mac-allocchio3.elettra.trieste.it>
User-Agent: Alpine 2.02 (OSX 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Subject: [apps-discuss] APPSDIR review of draft-ietf-mediactrl-mrb-12
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Mar 2012 10:05:28 -0000

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments you 
may receive. Please wait for direction from your document shepherd or AD 
before posting a new version of the draft.

Document: draft-ietf-mediactrl-mrb-12
Title: Media Resource Brokering
Reviewer: Claudio Allocchio, GARR
Review Date: March 11th 2012
IETF Last Call Date: n/a  (if there was and I miss it, then CC IESG list!)
IESG Telechat Date: n/a

Summary:

This document is well detailed, and is almaost ready for publication as a 
Proposed Standard. However there are some general considerations to deal 
with, and some small additions before this can be done. See below for 
details.

In general, this document is a complex collection of tutorial like 
(architecture description) sections, general dicussions sections, and 
detailed element definition and examples. For sure the letter "S" (simple) 
does not belong to it :-) I guess the WG already discussed about the 
chance of splitting at lest the tutorial and specification sections, and 
it pro and cons in doing this. If not, then have at least some thoughts.

Major Issues:

The only major issue I identified is about the use of security features 
while communicating between the various elements defined in the 
architecture: for example when in 12. Security Consideration it states
"In the case of the HTTP use, any binding using the Consumer interface 
MUST be capable of being transacted over TLS" it only states the 
capability MUST be there (the same for SIP etc.) but it does not make it 
compulsory (ok, I agree it can be too strong) nor it gives guidance or 
suggestions on why the capability SHOLD be used. Given we are dealing with 
locating Media Contents, breaking into the communication among elements 
can give very precious information for looking to illegally getting 
media contents. At least a guidance, and description of the problem should 
be added and will fix my concern.

Minor Issues:

In section 5.2 you should maybe add a small discussion about differences 
using HTTP and SIP as Consumer interface (pro and cons).

Having Examples as a (long) Section 9 seems to break away the Security and 
IANA consdierations from the rest of the document body. Have you 
considered moving the examples below after Security and IANA 
Considertations? Or as an Appendix? (maybe the above should be considered 
an editorial Nit!).

Nits:

where is NS0tecnologies located ? there is no street address. (authors' 
addresses).

Best Regards!

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio@garr.it
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca