Middlebox Communications (MIDCOM) Protocol Semantics
draft-ietf-midcom-semantics-08

Bottom of page 9 abbreviation/acronym conflict?:
   For notification messages, there exist three message types: the
   Session Termination Notification (STN) message type, the Policy Rule
   Event Notification (REN) message type and the Group Event
                      ^^^^^
   ... snip ..

   PEN   The Policy Rule Event Notification message contains the
  ^^^^^
         notification identifier, a policy rule identifier and the

later on in the text it seems that REN is used a few more times.

Need to use xxx.examle.com for exampls instead of mb.com and B@b.de.
  pn page 52 and following pages

Incorrect citation on page 63:
   Therefore, the UNSAF considerations of [RFC2424] do not apply
Should be RFC3424!
In fact, the text would read better as:
   Therefore, this document addresses the UNSAF considerations in
   [RFC3424] by proposing a longterm alternative solution.

---

Additional comments from MIB Doctor review

 1. Section 7, page 64
 
 OLD
 
  Therefore, the UNSAF considerations of [RFC2424] do not apply.
 
 NEW 
 
  Therefore, the UNSAF considerations of [RFC3424] do not apply.
 
 2. Section 4.2 refers specifically to SIP traversal, and the 
 example makes usage of SIP messages. I think that an 
 Informative reference to RFC 3261 could help.

The DISCUSS comment from -07 has been addressed - the "type of middlebox" field is now gone, replaced with a set of capabilities.
This clears my DISCUSS.

  Please change 'IPSEC' to 'IPsec' throughput the document.

  Section 5.3.3 states the need for authentication, but this is not sufficient.
  Integrity is needed in addition to authentication.  This is just as just a
  request for better documentation, as both TLS and IPsec provide integrity.

  Section 5.3.4: s/TLS or IPSEC encryption/TLS or IPsec protection/

Should SCTP support be mandated?  Put another way, is SCTP a first-class transport protocol that should be supported in all appropriate ways in IETF protcols?

The description of a group says that membership is the only attribute.  Surely lifetime is another attribute, since it's manipulable?

>                              abstraction that enables communcation

Run through spell

>    sending a reply message on the actual state transition, in latter
>    case the middlebox sends an unsolicited asynchronous notification

s/in latter/in the latter/

>    Request and reply messages contain an agent unique request identifier

s/agent unique/agent-unique/

>    middlebox.  If an optional transactions is implemented in the
s/transactions/transaction/

>    the last one is a asynchronous transaction initiated by the
s/a/an/