Hi David, There is no change in the mib-2 subtree in what concerns the ifCapStackMIB Module Identity.
RFC 5066 defines two MIB modules. One (this one) continues to be maintained by the IETF. There is no need for a change. The other (EFM-CU-MIB) goes to the IEEE, and will be relocated with new names under the IEEE802 subtree. That document is now in Sponsor Ballot by the IEEE-SA. I hope this clarifies the issue. Regards, Dan From: [email protected] [mailto:[email protected]] On Behalf Of ietfdbh Sent: Saturday, January 05, 2013 6:45 AM To: 'Edward Beili'; 'Benoit Claise' Cc: [email protected] Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review Hi, I think the mib-2 subtree is an Internet-standard subtree, and requires an RFC to update: SMI Network Management MGMT Codes Internet-standard MIB Registration Procedures RFC Required Description iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1) Reference [ RFC1213<http://www.iana.org/go/rfc1213>][RFC2578<http://www.iana.org/go/rfc2578>] If IEEE802 modifies this MIB module that is under mib-2, specifically by adding new objects, ... is it planned that IEEE802 will do so under the current IANA-assigned subtree mib-2, for which IANA has the authority to make assignments, using RFCs? Or is it planned they will relocate the MIB module into the IEEE802 subtree, where IEEE802 has the authority to make assignments? See RFC4663, section 2.3 and section 3.2 for a previous discussion of this issue. David Harrington [email protected]<mailto:[email protected]> +1-603-828-1401 From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Edward Beili Sent: Wednesday, January 02, 2013 11:42 AM To: Benoit Claise Cc: [email protected]<mailto:[email protected]> Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review Benoit, Thank you for the comments. I'm not sure I understand the need to change the ifCapStackMIB MODULE-IDENTITY value. It has been allocated by IANA as { mib-2 166 } in RFC 5066. Since we did not change the name (or the content) it should stay with the same OID, similar say to MAU-MIB - the last version is defined in RFC 4836, where mauMod MODULE-IDENTITY is { mib-2 26 6 }, exactly the same as mauMod MODULE-IDENTITY in the RFCs it obsoleted, such as RFC 3636, RFC 2668 and RFC 2239. Regards, -E. From: Benoit Claise [mailto:[email protected]] Sent: Wednesday, January 02, 2013 16:14 To: Edward Beili Cc: [email protected]<mailto:[email protected]> Subject: draft-ietf-opsawg-rfc5066bis-00.txt review Ed, Here is my draft-ietf-opsawg-rfc5066bis-00.txt review 1. OLD -- EdNote: Replace XXXX with the actual RFC number & -- remove this note ::= { mib-2 166 } NEW -- EdNote: Replace XXXX with the actual RFC number & -- remove this note ::= { mib-2 XXXX } Consequently, the IANA considerations section need to be changed/ 7. IANA Considerations Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been allocated by IANA in the MIB-2 sub-tree. 2. I don't believe that you need the following REVISION REVISION "200711070000Z" -- November 07, 2007 DESCRIPTION "Initial version, published as RFC 5066." Editorial 1. OLD Abstract This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. NEW Abstract This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. 2. OLD In addition the Security Considerations section was updated to NEW In addition, the Security Considerations section was updated to Regards, Benoit (as a contributor)
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
