[secdir] Review of draft-levin-mmusic-xml-media-control-12

Larry Zhu <lzhu@windows.microsoft.com> Thu, 17 January 2008 09:14 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQp0-0006uC-KP; Thu, 17 Jan 2008 04:14:02 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQow-0006qU-3x; Thu, 17 Jan 2008 04:13:58 -0500
Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFQov-0006dV-LH; Thu, 17 Jan 2008 04:13:57 -0500
Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 17 Jan 2008 01:13:56 -0800
Received: from TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com (157.54.18.7) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.1.240.5; Thu, 17 Jan 2008 01:13:56 -0800
Received: from NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.188]) by TK5-EXMLT-W604.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.7]) with mapi; Thu, 17 Jan 2008 01:13:56 -0800
From: Larry Zhu <lzhu@windows.microsoft.com>
To: Orit Levin <oritl@microsoft.com>, "roni.even@polycom.co.il" <roni.even@polycom.co.il>, "pierre@radvision.com" <pierre@radvision.com>
Date: Thu, 17 Jan 2008 01:12:02 -0800
Thread-Topic: [secdir] Review of draft-levin-mmusic-xml-media-control-12
Thread-Index: AchY515yWI8fuONgSJWQpJdEcKRIqg==
Message-ID: <E30895F8BA39B6439F5F1AAA1DBBFB524710A73424@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1
Cc: "mmusic-request@ietf.org" <mmusic-request@ietf.org>, "secdir@mit.edu" <secdir@mit.edu>, "ietf@ietf.org" <ietf@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Subject: [secdir] Review of draft-levin-mmusic-xml-media-control-12
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1750349789=="
Errors-To: ietf-bounces@ietf.org

Hello,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Overall as an informational ID I believe the document is well written and it should be published as soon as possible.

I have the following non-blocking COMMENTS:

1. Section 2, inconsistent use of RFC2119 language, "shipping products and new products SHALL use ...", the preceding sentence seems to suggest it is a "SHOULD" not a "SHALL".

 2. Section 4, the inconsistently spelling of "in time" vs "in-time". Not being an expert in this field, it is not clear to me what the parenthesis actually adds.

 3. Section 4, (what I consider) incorrect use of RFC2119 language, "... MUST be validated by ...", I do not know what does the use of "MUST" imply here. Suggestion: it should be sufficient to drop the "MUST" keyword here, try "is validated ...".

4. Section 5, "the UAC that sent...", please expand "UAC" on first use.

5. section 7, unclear statement, "Note that this primitive is supported by all known implementations", it is not clear to me which primitive it refers to. Suggestion: quote a reference for the primitive in question.

6. section 10, overall this section could benefit from more details or references. For example, it is not clear how TLS can be applied to secure the signalling path. Also the last sentence seems to contradict with the rest of this section. The section in RFC2976 only explicitly mentions confidentiality. Suggestion: it might be sufficient to say the security considerations in RFC2976 apply here.

Best regards,

--larry



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