Middlebox Communication (MIDCOM) Protocol Semantics
draft-ietf-midcom-rfc3989-bis-02

[Ballot comment]
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")
transactions?

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

[Ballot comment]
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.

[Ballot discuss]
This is a "bis" document, but it does not indicate whethert it obsoletes
  or updates RFC 3989 in the title page header, abstract, or introduction.
  Please update all three parts of the document.

  Please add a section to summarize the changes since RFC 3989.

[Ballot comment]
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.

[Note]: 'This document is an draft update of the process of taking RFC 3989 to proposed standard. It inherits the state RFC3989 to proposed had. The ones that has reviewed it before should just copy their ballot position to this new ballot.' added by Yoshiko Chong

[Note]: 'This document is an draft update of the process of taking RFC 3989 to proposed standard. It inherits the state RFC3989 to proposed had.

The ones that has reviewed it before should just copy their ballot position to this new ballot.' added by Magnus Westerlund

[Note]: 'This document is an draft update of the process of taking RFC 3989 to proposed standard. It inherits the state RFC3989 to proposed had.' added by Magnus Westerlund