Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0
Note: This ballot was opened for revision 07 and is now closed.
(Bert Wijnen) Yes
To answer Allison: That would me we have to open up editing of RFC2613. And the immediate result would be a quite sizeable effort to live up to all the lastest boilerplate, admin, IPR, split-in-references, etc etc type of bureaucratic work. The WG did consider that option and concluded against it. So my solution is: advance in grade AS IS.
(Brian Carpenter) No Objection
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Ted Hardie) No Objection
(Sam Hartman) No Objection
(Scott Hollenbeck) (was Discuss) No Objection
There are a few entries in the implementation report that list only one vendor's response: entPhysicalEntry.<N> | x | | | | N:1 | | | x | | N:M | | | x | | Apparently these are optional features that don't have an impact on interoperability.
(Russ Housley) No Objection
(David Kessens) No Objection
(Allison Mankin) No Objection
This can be settled by Bert/Dan to their own satisfaction; it does not have to come back to me: Could a Note to the RFC Editor specify that a risk in this MIB includes not just obtaining sensitive control information but actually controlling the port copy settings. This means opportunities for eavesdropping and hijacking. We expect MIB Security Considerations to describe more of the risks now than they did in 1999.