Subject: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review

From: Benoit Claise <[email-masked]>
Date: Wed, 02 Jan 2013 15:14:18 +0100

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)

---

From: Benoit Claise <[email-masked]>
Date: Wed, 02 Jan 2013 18:10:53 +0100

Ed,
>
> 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,
>
If nothing is changed in the MIB module, then you're right.
And the REVISION clause should be kept.

Regards, Benoit
>
> 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-masked]]
> *Sent:* Wednesday, January 02, 2013 16:14
> *To:* Edward Beili
> *Cc:* [email-masked]
> *Subject:* draft-ietf-opsawg-rfc5066bis-00.txt review
>
> Ed,
>

---

From: Edward Beili <[email-masked]>
Date: Wed, 2 Jan 2013 18:41:56 +0200

Benoit,

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-masked]]
Sent: Wednesday, January 02, 2013 16:14
To: Edward Beili
Cc: [email-masked]
Subject: draft-ietf-opsawg-rfc5066bis-00.txt review

Ed,

1.
OLD

   -- remove this note

       ::= { mib-2 166 }
NEW

   -- remove this note

       ::= { mib-2 XXXX }

Consequently, the IANA considerations section need to be changed/

7.  IANA Considerations

Editorial
1.
OLD

Abstract

Abstract

NEW

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 4 Jan 2013 23:44:33 -0500

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

[

 <http://www.iana.org/go/rfc1213> RFC1213][ <http://www.iana.org/go/rfc2578>
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

 <mailto:[email-masked]> [email-masked]

+1-603-828-1401

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Edward Beili
Sent: Wednesday, January 02, 2013 11:42 AM
To: Benoit Claise
Cc: [email-masked]
Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review

Benoit,

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.

Ed,

1.
OLD

       ::= { mib-2 166 }

NEW

       ::= { mib-2 XXXX }

7.  IANA Considerations

2.

Editorial
1.
OLD

Abstract

NEW

Abstract

2.
OLD

NEW

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 6 Jan 2013 09:09:56 +0000

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-masked] [mailto:[email-masked]] On Behalf Of ietfdbh
Sent: Saturday, January 05, 2013 6:45 AM
To: 'Edward Beili'; 'Benoit Claise'
Cc: [email-masked]
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-masked]<mailto:[email-masked]>
+1-603-828-1401
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Edward Beili
Sent: Wednesday, January 02, 2013 11:42 AM
To: Benoit Claise
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review

Benoit,

Regards,
-E.

From: Benoit Claise [mailto:[email-masked]]
Sent: Wednesday, January 02, 2013 16:14
To: Edward Beili
Cc: [email-masked]<mailto:[email-masked]>
Subject: draft-ietf-opsawg-rfc5066bis-00.txt review

Ed,

1.
OLD

   -- remove this note

       ::= { mib-2 166 }
NEW

   -- remove this note

       ::= { mib-2 XXXX }

7.  IANA Considerations

Editorial
1.
OLD

Abstract

Abstract

NEW

---

From: "ietfdbh" <[email-masked]>
Date: Sun, 6 Jan 2013 09:51:03 -0500

It does. Thank you.

David Harrington

+1-603-828-1401

From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Sunday, January 06, 2013 4:10 AM
To: ietfdbh; 'Edward Beili'; 'Benoit Claise'
Cc: [email-masked]
Subject: RE: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review

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. 

Regards,

Dan

ietfdbh

Hi,

Registration Procedures

RFC Required

Description

Reference

[

David Harrington

+1-603-828-1401

Benoit,

Regards,

-E.

Ed,

1.
OLD

       ::= { mib-2 166 }

NEW

       ::= { mib-2 XXXX }

7.  IANA Considerations

2.

Editorial
1.
OLD

Abstract

NEW

Abstract

2.
OLD

NEW