Middlebox Communication (MIDCOM) Protocol Semantics
RFC 5189

Note: This ballot was opened for revision 02 and is now closed.

Magnus Westerlund Yes

(Jari Arkko) No Objection

Comment (2007-06-07 for -)
No email
send info
A review from Christian Vogt:

Internet draft draft-ietf-midcom-rfc3989-bis-00.txt defines the
semantics of a set of transactions for use in middlebox signaling
protocols.  Overall, the document is in a good shape, and it looks like
it could be published soon.

One point that needs improvement, however, is the description and
differentiation of the various transaction types.  There is no place in
the document where all definitions are precisely defined.

The introduction says that there were two types of transactions and
names them "request-reply" and "asynchronous".

The Terminology section lists four types of transactions (Or is it not
transaction /types/, but something else?) -- request, configuration,
monitoring, and asynchronous transactions.

Then, as part of the transaction template definition in section 1.2,
only three transaction types are left, namely, configuration,
monitoring, and asynchronous.  What about request (or "request-reply")

Section 2.1.1, Protocol Transactions, still misses request transactions,
but comes up with a fifth transaction type:  convenience transactions.

And to make things even more challenging to understand, section 2.1.3
finally introduces transaction "groups", which seems to be a means of
differentiating transactions that is orthogonal to "types".

To sum things up, the draft would clearly benefit from one precise and
complete definition of all possible types of transactions, including how
and why they are grouped.  This should appear at /one/ prominent
position early on in the document.  Note that a good definition of the
transaction types is crucial given that the document is all about

(Ross Callon) No Objection

(Lars Eggert) No Objection

(Russ Housley) (was Discuss) No Objection

(Chris Newman) No Objection

Comment (2007-06-07 for -)
No email
send info
This is a reluctant "no objection".  If this actually defined a usable
protocol rather than abstract semantics, I'd be quite concerned with the
authentication model.

(Jon Peterson) No Objection

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

(Sam Hartman) Abstain

Comment (2007-06-05 for -)
No email
send info
I cannot support the authentication model in this draft.  It seems
like it is at the wrong layer and it is kind of broken.  I think
ignoring my objections is better than spending the time to fix.

(Cullen Jennings) No Record

Comment (2007-05-31 for -)
No email
send info
This version resolved my discuss on previous version of RFC3989