Document: RFC 3989 as Proposed Standard
Reviewer: Sharon Chisholm
Review Date:  Tuesday 1/16/2007 8:55 AM CST
IESG Telechat Date: 1/11/2007

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.
".