Document: draft-ietf-midcom-semantics-07
Reviewer: Spencer Dawkins
Date: February 3, 2004

There's a minor editing pass waiting ("This memo suggests a
semantics for the MIDCOM protocol" in the second paragraph, so I quit reading
for typos), but I ignored this in my review below.

Basics - "This draft is on the right track but has open issues,
described in the review".

The real challenge for the authors was trying to abstract principles
from the middleboxes that are deployed today, and they did this
pretty
well.

I have some notes below, but 2.1.6 and 2.2.4 are the only ones that
seem significant, from an architecture standpoint.

Spencer

Architecture, Interoperability - 2.1.6 Middlebox Capabilities - I'd
like to see more thought given to "type of the middlebox". In
particular, what matters is capabilities, not device categories.
What I see deployed today is a seemingly-endless variety of transparent
middleboxes. If faced with a list of "things that the box does", a
client could base actions on the items on the list that it
recognizes.
If faced with a type-of-middlebox = Flatula, the client has no idea
what to do next, even if a Flatula middlebox provides many
capabilities that the client does know about because they are also
provided by other types of middleboxes. I'm not saying showstopper,
but I expect this would lessen deployability down the road (new type
of middlebox, but widely deployed clients don't support it for a
year). This complexity ripples (see 2.3.2, where the type of
middlebox
affects the IP addresses that are reserved).

Mystery - 2.2.1 - Shows a "MIDCOM protocol version" parameter - is
this in addition to any version number on the specific protocol used
to provide MIDCOM communication?

Robustness - 2.2.4 - Is the intention here to minimize state on the
middlebox? Tearing down sessions when a connection is interrupted
seems to beg for keep-alives. If I understand correctly, the MIDCOM
connection is experiencing the problem, but the "end-to-end"
connection supported by MIDCOM may be idle - why tear it down, if
you could put things back together before the end-to-end connection
becomes active?

Nit - 2.3.5 - The TCP "first packet" has SYN set, and ACK not set.
Meta-sigh - why are port numbers part of the transport header? I
understand that MIDCOM needs to talk about port numbers, but
awareness
of transport protocols seems to make deploying SCTP, DCCP, etc. more
difficult...