Middlebox Communications (MIDCOM) Protocol Semantics
draft-ietf-midcom-semantics-08
Yes
(Allison Mankin)
(Jon Peterson)
No Objection
(Alex Zinin)
(Bill Fenner)
(Margaret Cullen)
(Ned Freed)
(Ted Hardie)
Note: This ballot was opened for revision 08 and is now closed.
Allison Mankin Former IESG member
Yes
Yes
()
Unknown
Jon Peterson Former IESG member
Yes
Yes
()
Unknown
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
(2004-02-05)
Unknown
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.
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
(was Discuss)
No Objection
No Objection
(2004-06-17)
Unknown
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.
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Ned Freed Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2004-02-04)
Unknown
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/
Steven Bellovin Former IESG member
No Objection
No Objection
(2004-02-04)
Unknown
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?
Ted Hardie Former IESG member
No Objection
No Objection
()
Unknown
Thomas Narten Former IESG member
No Objection
No Objection
(2004-02-05)
Unknown
> 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/