RE: [secdir] Review of draft-levin-mmusic-xml-media-control-12
"Even, Roni" <roni.even@polycom.co.il> Mon, 21 January 2008 08:04 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 1JGrdn-0003w4-1T; Mon, 21 Jan 2008 03:04:23 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGrdj-0003nc-0o; Mon, 21 Jan 2008 03:04:19 -0500
Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGrdh-0005Ly-QU; Mon, 21 Jan 2008 03:04:18 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 21 Jan 2008 10:04:29 +0200
Message-ID: <144ED8561CE90C41A3E5908EDECE315C054228C2@IsrExch01.israel.polycom.com>
In-Reply-To: <E30895F8BA39B6439F5F1AAA1DBBFB524710A73424@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [secdir] Review of draft-levin-mmusic-xml-media-control-12
Thread-Index: AchY515yWI8fuONgSJWQpJdEcKRIqgDGSqFw
From: "Even, Roni" <roni.even@polycom.co.il>
To: Larry Zhu <lzhu@windows.microsoft.com>, Orit Levin <oritl@microsoft.com>, pierre@radvision.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: af2aae76ea468dc53420d9ba52ca6045
Cc: mmusic-request@ietf.org, secdir@mit.edu, ietf@ietf.org, iesg@ietf.org
Subject: RE: [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="===============0526881701=="
Errors-To: ietf-bounces@ietf.org
Larry, Thanks for you comments See inline Roni Even ________________________________ From: Larry Zhu [mailto:lzhu@windows.microsoft.com] Sent: Thursday, January 17, 2008 11:12 AM To: Orit Levin; Even, Roni; pierre@radvision.com Cc: secdir@mit.edu; ietf@ietf.org; iesg@ietf.org; mmusic-request@ietf.org Subject: [secdir] Review of draft-levin-mmusic-xml-media-control-12 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". [RE:] I agree that SHOULD would reflect more the previous sentence since it explains that this method is only for backward compatibility. 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. [RE:] I can take it out. I agree that this is not important 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 ...". [RE:] The full sentence mandates that before sending a full frame the sender MUST validate the congestion situation and allowed bandwidth. Note that the use case is for application reasons and not for packet loss. 4. Section 5, "the UAC that sent...", please expand "UAC" on first use. [RE:] Will do 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. [RE:] I think this is a redundant sentence since in previous versions of the draft we had another primitive in the schema. 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. [RE:] If SIP INFO is used to carry the fast update this opening of TLS channel is defined in SIP. I can change "to secure the signaling using TLS" to "to secure the signaling using TLS as explained in [5]" 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. [RE:] Maybe I can change "This document does not introduce new security considerations beyond those covered in [3]." To "Security considerations of [3] and [5] apply here.". Best regards, --larry
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf