Subject: Re: [MIB-DOCTORS] Registration procedures for SMI SNMPv2 snmpModules Codes

From: Benoit Claise <[email-masked]>
Date: Mon, 14 Sep 2015 12:23:52 +0200

Hi Michelle,
> Hello Benoit,
>
> We are trying to figure out the registration procedures for the 
> following registry:
> SMI SNMPv2 snmpModules Codes
> iso.org.dod.internet.snmpv2.snmpModules (1.3.6.1.6.3)
> Found at: http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml
I could not find any.
>
> It currently says “Not Defined”.
>
> If a request was being made in a Proposed Standard would that be 
> sufficient?
I would say so, like for example in RFC 3414.

Including the mib-doctors for a definitive answer.

Regards, Benoit
>
> Looking forward to any feedback.
>
> Thanks,
>
> Michelle
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Sep 2015 13:08:14 +0200

> Including the mib-doctors for a definitive answer.

This branch has been used to register MIB modules that deal with the
SNMP protocol itself. One funny thing is that most of them belong to
SNMPv3 while the path has 'snmpv2' as a descriptor. And yes, we also
registered SNMPv3 specific MIB modules simply under mib-2, see for
example RFC 5953. Perhaps the rule that we by default use mib-2 has
overwritten the rule of using snmpModules at that time. I managed to
find an email from David Harrington (posted on December 02, 2009 to
the ISMS WG list) where he wrote that all new modules go to mib-2.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: David Harrington <[email-masked]>
Date: Mon, 14 Sep 2015 12:17:40 -0400

Hi,

If a reference is needed for the creation of snmpModules, I found it specified in rfc1442.
At the time of SNMPv2, we thought we should have a separate subtree for SNMP administrative modules.
Obviously that thinking changed by the time of ISMS.

As I recall, during the ISMS WG timeframe, we decided that assigning subtrees for subsequent assignment by WGs had became problematic.
I think Bert was still AD at the time, and there were some "questionable practices” being done by WGs with their own subtrees.
I seem to recall Diameter being the protocol that had questionable practices  but I could be remembering wrong.
MPLS had its own subtree that was not problematic, as I recall.
So I think we decided everything should simply go under mib-2, and be subject to IANA review rules for mib-2.

It’s been a while since I’ve had to deal with determining the appropriate IANA rules to apply.
I’d favor something for the snmpv2 subtree that says “do not use; use mib-2”.
Did we do something official for the mpls and diameter subtree, to move subsequent assignments under mib-2?

David Harrington
[email-masked]

On Sep 14, 2015, at 7:08 AM, Juergen Schoenwaelder <[email-masked]> wrote:

> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: Michelle Cotton <[email-masked]>
Date: Wed, 30 Sep 2015 14:34:04 +0000

MIB Doctors,

Any feedback on this?

Please respond as soon as possible.

Thank you,

Michelle

From:  Benoit Claise <[email-masked]>
Date:  Monday, September 14, 2015 at 3:23 AM
To:  Michelle Cotton <[email-masked]>
Cc:  Amanda Baber <[email-masked]>, "MIB Doctors (E-mail)"
<[email-masked]>, Benoit Claise <[email-masked]>
Subject:  Re: Registration procedures for SMI SNMPv2 snmpModules Codes

Hi Michelle,
> Hello Benoit,
> 
> We are trying to figure out the registration procedures for the following
> registry:
I could not find any.
> 
> It currently says ³Not Defined².
> 
> If a request was being made in a Proposed Standard would that be sufficient?

Regards, Benoit

---

From: Dave Thaler <[email-masked]>
Date: Wed, 30 Sep 2015 20:20:03 +0000

In my opinion, since the allocation policy was never explicitly defined that I know of,
I think it would probably default to "IETF Review" as defined in RFC 5226.

Certainly a standards track RFC meets that criteria, but I wouldn't hold it to
"Standards Action" but rather "IETF Review" (which also allows for other types of
IETF RFCs, not just Proposed Standards).

Dave

From: MIB-DOCTORS [mailto:[email-masked]] On Behalf Of Michelle Cotton
Sent: Wednesday, September 30, 2015 7:34 AM
To: Benoit Claise <[email-masked]>
Cc: Amanda Baber <[email-masked]>; MIB Doctors (E-mail) <[email-masked]>
Subject: Re: [MIB-DOCTORS] Registration procedures for SMI SNMPv2 snmpModules Codes

MIB Doctors,

Any feedback on this?

Thank you,

Michelle

From: Benoit Claise <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 14, 2015 at 3:23 AM
To: Michelle Cotton <[email-masked]<mailto:[email-masked]>>
Cc: Amanda Baber <[email-masked]<mailto:[email-masked]>>, "MIB Doctors (E-mail)" <[email-masked]<mailto:[email-masked]>>, Benoit Claise <[email-masked]<mailto:[email-masked]>>
Subject: Re: Registration procedures for SMI SNMPv2 snmpModules Codes

Hi Michelle,
Hello Benoit,

We are trying to figure out the registration procedures for the following registry:
SMI SNMPv2 snmpModules Codes
iso.org.dod.internet.snmpv2.snmpModules (1.3.6.1.6.3)
Found at: http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml
I could not find any.

It currently says "Not Defined".

Regards, Benoit

Thanks,

Michelle

---

From: joel jaeggli <[email-masked]>
Date: Wed, 30 Sep 2015 17:06:03 -0700

On 9/30/15 1:20 PM, Dave Thaler wrote:
> I think it would probably default to “IETF Review” as defined in RFC 5226.
>
> Certainly a standards track RFC meets that criteria, but I wouldn’t hold
> it to “Standards Action” but rather “IETF Review” (which also allows for other
> types of

yeah don't unless you think standards track rfc's are the vehcicle
though which these resources should be registered. imho that's a a
needlessly high bar, that makes things like experimentation that much
harder.

my .02

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Oct 2015 08:28:38 +0200

> needlessly high bar, that makes things like experimentation that much

We may be moving from the concrete to the abstract. We discussed
before that snmpModules was once used for SNMP core modules but ISMS
already moved away from using this branch and instead registered SNMP
core modules below mib-2. I very much doubt we need this specific
branch for experimentation or something like that.

/js