[MMUSIC] Comments on draft-ietf-mmusic-img-req-03.txt

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 09 March 2004 08:23 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14063 for <mmusic-archive@odin.ietf.org>; Tue, 9 Mar 2004 03:23:46 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0cWD-0000Fs-LT for mmusic-archive@odin.ietf.org; Tue, 09 Mar 2004 03:23:17 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i298NH0A000974 for mmusic-archive@odin.ietf.org; Tue, 9 Mar 2004 03:23:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0cWD-0000Fd-EN for mmusic-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 03:23:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14008 for <mmusic-web-archive@ietf.org>; Tue, 9 Mar 2004 03:23:15 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0cWB-0002Ra-00 for mmusic-web-archive@ietf.org; Tue, 09 Mar 2004 03:23:15 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0cVD-0002GV-00 for mmusic-web-archive@ietf.org; Tue, 09 Mar 2004 03:22:16 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0cUB-00020M-00 for mmusic-web-archive@ietf.org; Tue, 09 Mar 2004 03:21:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0cU2-00087P-4O; Tue, 09 Mar 2004 03:21:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0cTU-00082P-KM for mmusic@optimus.ietf.org; Tue, 09 Mar 2004 03:20:28 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13869 for <mmusic@ietf.org>; Tue, 9 Mar 2004 03:20:27 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0cTS-0001xC-00 for mmusic@ietf.org; Tue, 09 Mar 2004 03:20:26 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0cST-0001nJ-00 for mmusic@ietf.org; Tue, 09 Mar 2004 03:19:25 -0500
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1B0cRh-0001dh-00 for mmusic@ietf.org; Tue, 09 Mar 2004 03:18:37 -0500
Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i298IbYG027924 for <mmusic@ietf.org>; Tue, 9 Mar 2004 09:18:37 +0100 (MET)
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Mar 2004 09:18:36 +0100
Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.102]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYF9TVN8; Tue, 9 Mar 2004 09:18:36 +0100
Message-ID: <404C03EF.4010404@ericsson.com>
Date: Mon, 08 Mar 2004 06:26:07 +0100
X-Sybari-Trust: 34c7ca80 2c4885b5 39802fef 00000138
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: sv, en-us, en
MIME-Version: 1.0
To: "mmusic (E-mail)" <mmusic@ietf.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Mar 2004 08:18:36.0957 (UTC) FILETIME=[1EEE5CD0:01C405AF]
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] Comments on draft-ietf-mmusic-img-req-03.txt
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi,

I a have some comments to this document that currently are in WG last call.

1. Section 2: The capitalized words MUST SHOULD, etc. used in this 
specification may not always be appropriate. This is due to that the 
definitions are more intended for technical specifications and putting 
requirements on implementations. It might be consider better if the 
document defines the words.

2. Section 5.2.1: Req DEL-1: I see some problems with writing a MUST in 
this context. I agree that scalability is desirable and is a clear 
design goal of any solution. The problem lays in the measuring of 
scalability. Absolute measurements of scalability is hard to establish. 
Also in certain environments one might not be able to create good 
scalability due to other factors in the system, for example extremely 
limited bandwidth. Thus I would suggest that this is reformulated into 
something that is more a statement of intention.

3. Section 5.4.1: Last paragraph: I think that the intermittent 
connectivity actually should be formulated into a requirement:

REQ: "The IMG system SHOULD allow for low cost uptodate/consistency checks."

4. Section 5.5, Req DES-4: "IMG metadata MUST be structured such that it 
is possible to deliver only part of an IMG sender's (and the global) 
complete IMG metadata knowledge."

I think this is SHOULD rather than a MUST. The reason is for example 
that some may want to use already established metadata formats that does 
not fulfil the requirements. Should they not be allowed to use IMG due 
to that facT?

5. The security requirements: Have you had any review of these, and 
there possibility to be fulfilled? I think it would be stupid to require 
security that is not possible to fulfil, how much it still is desirable. 
And if a piece of security is required lacks solution, should we then 
shelf IMG?

6. IPR and Copyright statement. Needs to be updated using RFC 3667 and 
3668. Also please provide a heading for the IPR section.

7. Also as this document is intended for informative, you can't have 
normative references.

Cheers

Magnus


-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com



This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic