Definitions of Managed Objects for Middlebox Communication
RFC 5190

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

Magnus Westerlund (was Discuss, Yes) Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2006-10-26)
No email
send info
The security considerations section could point
out that there is no need to ensure that the
transactions affect only the owner's IP address.
This is because MIDCOM is mostly targeted for
SIP servers and other similar entities, not client

I am curious about the current state of the WG
and the plans for implementing this. Are there
any implementations ongoing? Which one of the
multiple solutions that exist in this space
actually are being used?

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Brian Carpenter) No Objection

(Lisa Dusseault) No Objection

(Bill Fenner) No Objection

Comment (2006-10-25 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The references to RFC 3303, RFC 3304 and RFC 3989 are downrefs (see RFC 3967).

(Ted Hardie) No Objection

(Sam Hartman) (was Discuss) No Objection

(Russ Housley) No Objection

Comment (2006-10-24 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  From the SecDir Review by Radia Perlman:

  I see no security problems with this document, and commend the
  authors for the very thorough security considerations section.

(Cullen Jennings) No Objection

Comment (2006-10-26 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
On the call, I would like to talk about existing implementations, expected future implementations, what we will do with future midcom protocols that are actually in use, and if we might want to do anything about this.

(David Kessens) No Objection

(Chris Newman) No Objection

(Jon Peterson) No Objection

(Tim Polk) (was Discuss) No Objection

(Dan Romascanu) (was Discuss, No Objection) No Objection

Comment (2007-11-19)
No email
send info
Version 10 includes a couple of new edits which I suggest to re-visit:

1. in page 9 all terminology was changed from SNMP manager to MIDCOM client with the exception of the last instance. 

'If this is not possible, then the SNMP manager has to perform additional SNMP get transactions as long as necessary to receive all of the reply parameters.' 

I suggest to use here 'SNMP manager (MIDCOM client)' for consistency. 

2. in section 5 and in the DESCRIPTION clause of the MIB module 'three braches of managed objects' was replaced by 'three kinds of managed objects'. I do not know why this change was made, but I kind of do not like it, as it fails to convey the fact that the MIB module is structured in sub-groups or branches on these line. I would suggest to default back to the previous terms, or make clear that every 'kind' has one single root node each under midcomObjects.

(Mark Townsley) No Objection

(David Ward) No Objection

(Lars Eggert) Recuse