[Gen-art] Generate Review of RFC 3989 as Proposed Standard
"Sharon Chisholm" <schishol@nortel.com> Tue, 16 January 2007 14:54 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6phz-0001JC-0l; Tue, 16 Jan 2007 09:54:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6phx-0001J6-LV for gen-art@ietf.org; Tue, 16 Jan 2007 09:54:41 -0500
Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6phw-0004sD-9e for gen-art@ietf.org; Tue, 16 Jan 2007 09:54:41 -0500
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l0GEkwO25471; Tue, 16 Jan 2007 09:46:58 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 16 Jan 2007 09:54:36 -0500
Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40CF09AB5@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Generate Review of RFC 3989 as Proposed Standard
Thread-Index: Acc5fj2JdN6mzF8jSGyS4T56XPlc7w==
From: Sharon Chisholm <schishol@nortel.com>
To: gen-art@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: mshore@cisco.com, stiemerling@netlab.nec.de, magnus.westerlund@ericsson.com, Tom-PT Taylor <taylor@nortel.com>
Subject: [Gen-art] Generate Review of RFC 3989 as Proposed Standard
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>http://www.alves trand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: Middlebox Communications (MIDCOM) Protocol Semantic Summary: This document is ready for publication/advancement, but has the following nits that should be resolved. Comments --------- There is a lot of text in the document and I will confess I skipped over some of it. I'm already late on the review and the document seems reasonable (it has already been published), so I figured it was best just to send what I had. I did note the following, where issue 5 is the one that identifies something introduced by becoming a normative document. 1. I didn't find where it was explained the reasoning behind being able to send a request that reserves stuff on neither side of the middlebox. It would seem a waste of processing. 2. In section 2.1.1 it says "Asynchronous transactions allowing the middlebox to change state without a request by an agent." but it would seem that asynchronous transactions would allow for the reporting of the change of state but not be able to trigger it. Or are we saying that the asynchronous transaction does not originate from the agent but triggers the state change? 3. In section 2.1.6 it says that capabilities include "Optional interface-specific policy rule support: not supported or supported" but it wasn't clear to be whether this was the advertisement of specific optional capabilities or whether it was a simple yes or no that some optional capabilities were supported. 4. In section 2.1.7, I was confused as to whether the parameter identifying the requesting agent were specified or not. At first it says they are but then it says 'Although, they are not necessarily passed explicitly as parameters of the MIDCOM protocol, they might be provided by the underlying (secure) transport protocol being used." Are they only sent if they can't be sent via the underlying layers, because if so that seems like a layering issue. The protocol should be independent. In general, this section wasn't clear to me on this issue. 5. In section 2.1.8 and at least one other place (section 3, first paragraph) in the document it says something along the lines of "However, an actual implementation of a middlebox may support only a subset of these transactions." which I think is trying to say that people shouldn't assume the middlebox supports everything but in the context of a normative document may get misinterpreted to indicate that the middlebox MUST NOT support everything. 6. Does the noauth state consume any resources. If so, doesn't this leave the box vulnerable to attack? (section 2.2.5) 7. In section 2.3.4, it indicates "If the state or lifetime change was requested explicitly by a request message, then the middlebox notifies the requesting agent by returning the corresponding reply." Is this instead or in addition to the asynchronous message? 8. In section 2.3.6, it wasn't obvious to me how I was support to indicate a port range of lets say 200-205. The text says "A single policy rule P containing a port range value greater than one is equivalent to a set of policy rules containing a number n of policies P_1, P_2, ..., P_n where n equals the value of the port range parameter. ". Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
- [Gen-art] Generate Review of RFC 3989 as Proposed… Sharon Chisholm
- [Gen-art] RE: Generate Review of RFC 3989 as Prop… Sharon Chisholm
- [Gen-art] Re: Generate Review of RFC 3989 as Prop… Juergen Quittek
- [Gen-art] Re: Generate Review of RFC 3989 as Prop… Martin Stiemerling
- Re: [Gen-art] Re: Generate Review of RFC 3989 as … Brian E Carpenter
- Re: [Gen-art] Re: Generate Review of RFC 3989 as … Juergen Quittek
- Re: [Gen-art] Re: Generate Review of RFC 3989 as … Magnus Westerlund
- [Gen-art] Re: Generate Review of RFC 3989 as Prop… Juergen Quittek