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

From: Michelle Cotton <[email-masked]>
Date: Mon, 5 Oct 2015 18:38:19 +0000

Hello!

Thank you for the response.

1. We¹ll put the registration procedures in the registry per your guidance
below.
2. The question is regarding draft-ietf-opsawg-hmac-sha-2-usm-snmp.  It
appears that a registration was made and confirmed by the authors in the
wrong registry.  They would like it corrected into the registry that you
just confirmed the registration procedures.   The outstanding question is
³When we remove assignment 235, should we list the value as "Unassigned," or
does it need to be listed as "Deprecated"?
I hope that clarifies.

Thank you,

Michelle

From:  Benoit Claise <[email-masked]>
Date:  Thursday, October 1, 2015 at 12:56 AM
To:  joel jaeggli <[email-masked]>, Dave Thaler <[email-masked]>,
Michelle Cotton <[email-masked]>, Amanda Baber
<[email-masked]>, "MIB Doctors (E-mail)" <[email-masked]>
Subject:  Re: [MIB-DOCTORS] Registration procedures for SMI SNMPv2
snmpModules Codes

Dear all,

Let's go back to Michelle's questions:
> 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
> 
> It currently says ³Not Defined².
> 
> If a request was being made in a Proposed Standard would that be
> sufficient?
As Dave Thaler convinced us/me, I believe the procedure could be: ³IETF
Review² as defined in RFC 5226.
So to answer the second question "If a request was being made in a Proposed
Standard would that be sufficient?", the answer would be yes.

Now, to the implicit question: should we use
iso.org.dod.internet.snmpv2.snmpModules or mib-2 for registration, let me
ask a question to Michelle. Is there an actual registration request or are
you trying to complete your IANA database?
If the former, which MIB module?
If the latter, is there a way to tell ³do not use; use mib-2² ... assuming
that this is the consensus of this group.

Regards, Benoit
> On Wed, Sep 30, 2015 at 05:06:03PM -0700, joel jaeggli wrote:
>> On 9/30/15 1:20 PM, Dave Thaler wrote:
>>> 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
>> 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.
>> 
> 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
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 Oct 2015 20:52:24 +0200

So here is what I understand:

  IANA allocated mib-2.235 to snmpUsmHmacSha2MIB (SNMP-USM-HMAC-SHA2-MIB)
  defined in draft-ietf-opsawg-hmac-sha-2-usm-snmp but the I-D requests
  to register snmpUsmHmacSha2MIB below SNMPv2.snmpModules, which some of
  us happen to recall is something we gave up a while ago. Despite
  formalities, I think the real question is whether we have a policy to
  continue to use org.dod.internet.snmpV2.snmpModules (and if so in
  which situations) or whether we have a policy that we retire
  org.dod.internet.snmpV2.snmpModules for all new assignments and
  snmpUsmHmacSha2MIB simply gets registered under mib-2.235.

I am just trying to assemble the story-line from the bits and pieces.

/js

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

-- 
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: Michelle Cotton <[email-masked]>
Date: Mon, 5 Oct 2015 20:39:15 +0000

We registered the mib-2 as that is what was described in the Last Call
comments and the authors confirmed it.
Recently we received a message saying that it should have been under
1.3.6.1.6.3 (SMI SNMPv2 snmpModules Codes) and this was stated in the
document, but it was mistaken for the mib-2 tree.  Ideally it would have
been nice for the authors to have noticed this during last call and tell
IANA that the actions we described were incorrect.

Based on previous messages, the registrations procedures that are
currently “Not Defined” can now be changed to IETF Review.
What is being requested is to remove the mib-2 assignment and correctly
make it in the snmpModules.  Our outstanding question was if we just
remove the mib-2 or do we mark it as deprecated.  The RFC has not been
published yet so we can correctly put the right assignment in the document.

I’m not aware of any issue with using the 1.3.6.1.6.3 branch.  So if there
is, please let us know what to do in this situation and future requests
for assignment in that branch.

Thanks,

Michelle

On 10/5/15, 11:52 AM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

>> > Found at: 
>>http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml
>> >

---

From: Benoit Claise <[email-masked]>
Date: Tue, 6 Oct 2015 14:16:26 +0200

Michelle,

> 1.3.6.1.6.3 (SMI SNMPv2 snmpModules Codes) 
There is some confusion.
The advice from the MIB doctors is: don't use the snmpv2 subtree but use
mib-2
So if you have requested mib-2.235, it seems that you have done the
right thing.

Regards, Benoit

> and this was stated in the

---

From: David Harrington <[email-masked]>
Date: Tue, 6 Oct 2015 09:52:30 -0400

+1

David Harrington
[email-masked]
603-828-1401

> On Oct 6, 2015, at 8:16 AM, Benoit Claise <[email-masked]> wrote:
> 
> Michelle,
> 
>>>> Thank you foMichelle,

---

From: Michelle Cotton <[email-masked]>
Date: Tue, 6 Oct 2015 14:24:32 +0000

OK, I’ll go ahead and tell the authors this.
I’ll let you know if we get any push-back.

Should we be marking the snmpv2 snmpModules Codes as no longer accepting
assignments?

Thank you,

Michelle

---

From: Benoit Claise <[email-masked]>
Date: Tue, 6 Oct 2015 17:23:48 +0200

> Should we be marking the snmpv2 snmpModules Codes as no longer accepting
yes please.

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Oct 2015 07:55:47 +0200

I am surprised that RFC 7630 now uses

   ::= { snmpModules 235 }

and I guess this went really wrong now: the mib-2 number got used to
register below snmpModules...

/js

---

From: Benoit Claise <[email-masked]>
Date: Thu, 15 Oct 2015 08:23:29 +0200

Yes, that went really wrong now!
It should have been mib-2.235 and it's now snmpModules.235 Michelle, 
what now?
[including the rfc-editor]

Regards, Benoit

---

From: Michelle Cotton <[email-masked]>
Date: Thu, 15 Oct 2015 14:03:02 +0000

I believe there were more text changes that needed to be made for that one
before publication.
An errata may be needed.  I’ll check today.

―Michelle

On 10/14/15, 11:23 PM, "Benoit Claise" <[email-masked]> wrote:

>>>>>> just confirmed the registration procedures.   The outstanding
>>>>>>question
>>>>>> is
>>>>>> iso.org.dod.internet.snmpv2.snmpModules or mib-2 for registration,
>>>>>>let
>>>>>> me
>>>>>> ask a question to Michelle. Is there an actual registration request
>>>>>>or
>>>>>> are
>>>>>>>>> Certainly a standards track RFC meets that criteria, but I
>>>>>>>>>wouldn¹t
>>>>>> hold

---

From: Benoit Claise <[email-masked]>
Date: Thu, 15 Oct 2015 18:00:27 +0200

Dear all, ietf-opsawg-hmac-sha-2-usm-snmp authors,

Ok, let me include everybody. So 
[email-masked] as well.

The facts:
- The MIB doctors advised not to publish MIB modules under snmpModules 
any longer. IANA updated the registry information. See 
http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-61
- RFC 7360 is published with a mistake. The MIB module should have been 
published under mib-2.235 (as advised by the MIB doctor) and the 
document mentions: snmpModules.235
- The IANA registry is actually correct. snmpUsmHmacSha2MIB is under 
mib-2.235
See http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml
- Solving this issue with an errata doesn't work: indeed MIB modules are 
extracted from RFC, and used within scripts.
- This is embarrassing. So let's fix this quickly. No point to waste 
time on finding the root cause of what happened

Discussing with Michelle (IANA) and the IESG today, we have no other 
choices than obsoleting this RFC and re-issuing a new one.
The way forward is to publish a new draft ASAP with the corrections, to 
have a one week IETF LC, and to publish the new RFC. At that point (and 
not before because we don't have a replacement RFC), we will obsolete 
RFC 7360.

Authors, can you push a new version ASAP.
OLD:

        REVISION    "201508130000Z"       -- 13 August 2015, midnight
        DESCRIPTION "Initial version, published asRFC 7630 <https://tools.ietf.org/html/rfc7630>"
    ::= { snmpModules 235 }

NEW:

        REVISION     ... new date
        DESCRIPTION "Initial version, published asRFC xxxx <https://tools.ietf.org/html/rfc7630>"
    ::= { mib-2 235 }

OLD:
              +--------------------+-------------------------+
              |     Descriptor     | OBJECT IDENTIFIER value |
              +--------------------+-------------------------+
              | snmpUsmHmacSha2MIB |   { snmpModules 235 }   |
              +--------------------+-------------------------+

NEW:
             +--------------------+-------------------------+
              |     Descriptor     | OBJECT IDENTIFIER value |
              +--------------------+-------------------------+
              | snmpUsmHmacSha2MIB |      { mib-2 235 }      |
              +--------------------+-------------------------+

OLD:

        IMPORTS
            MODULE-IDENTITY, OBJECT-IDENTITY,
        snmpModules             FROM SNMPv2-SMI          -- [RFC2578 <https://tools.ietf.org/html/rfc2578>]

NEW
        IMPORTS
            MODULE-IDENTITY, OBJECT-IDENTITY,
        mib-2                  FROM SNMPv2-SMI          -- [RFC2578 <https://tools.ietf.org/html/rfc2578>]

I believe that these are the only required changes

Regards, Benoit
>>>>>> 2. The question is regarding 
>>>>>> draft-ietf-opsawg-hmac-sha-2-usm-snmp.  It
>>>>>> iso.org.dod.internet.snmpv2.snmpModules or mib-2 for 
>>>>>> registration, let
>>>>>> me
>>>>>> ask a question to Michelle. Is there an actual registration 
>>>>>> request or
>>>>>> are

---

From: Johannes Merkle <[email-masked]>
Date: Thu, 15 Oct 2015 18:12:49 +0200

ok, I'll do so by today, but I need the latest XML source file, including the the last changes of RFC Editor. Can you
please provide these to me?

Johannes

Benoit Claise schrieb am 15.10.2015 um 18:00:
> Ok, let me include everybody. So [email-masked] as well.
> 
> The facts:
> - The MIB doctors advised not to publish MIB modules under snmpModules any longer. IANA updated the registry
> information. See http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-61
> - RFC 7360 is published with a mistake. The MIB module should have been published under mib-2.235 (as advised by the MIB
> doctor) and the document mentions: snmpModules.235
> - The IANA registry is actually correct. snmpUsmHmacSha2MIB is under mib-2.235
> - Solving this issue with an errata doesn't work: indeed MIB modules are extracted from RFC, and used within scripts.
> - This is embarrassing. So let's fix this quickly. No point to waste time on finding the root cause of what happened
> 
> Discussing with Michelle (IANA) and the IESG today, we have no other choices than obsoleting this RFC and re-issuing a
> new one.
> The way forward is to publish a new draft ASAP with the corrections, to have a one week IETF LC, and to publish the new
> RFC. At that point (and not before because we don't have a replacement RFC), we will obsolete RFC 7360.
> 
>        DESCRIPTION "Initial version, published as RFC 7630 <https://tools.ietf.org/html/rfc7630>"
>    ::= { snmpModules 235 }
> 
> NEW:
> 
>        REVISION     ... new date
>        DESCRIPTION "Initial version, published as RFC xxxx <https://tools.ietf.org/html/rfc7630>"
>    ::= { mib-2 235 }
> 
> OLD:
>> It should have been mib-2.235 and it's now snmpModules.235 Michelle, what now?

-- 
Mit freundlichen Grüßen,
Dr. Johannes Merkle
Principal
Division Innere Sicherheit
secunet Security Networks AG
Mergenthaler Allee 77
65760 Eschborn
Germany
Telefon +49 201 54 54-3091
Telefax +49 201 54 54-1325
Mobil   +49 175 2224439
[email-masked]
www.secunet.com

---

From: RFC Editor <[email-masked]>
Date: Thu, 15 Oct 2015 09:21:19 -0700

Hi Johannes,

The file is attached. 

Thanks,
RFC Editor/sg

On Thu, Oct 15, 2015 at 06:12:49PM +0200, Johannes Merkle wrote:
> >>>>> currently ???Not Defined??? can now be changed to IETF Review.
> >>>>> I???m not aware of any issue with using the 1.3.6.1.6.3 branch.  So if there
> >>>>>>> 1. We??ll put the registration procedures in the registry per your
> >>>>>>> guidance
> >>>>>>> below.
> >>>>>>> ??When we remove assignment 235, should we list the value as
> >>>>>>> "Unassigned," or
> >>>>>>>> It currently says ??Not Defined??.
> >>>>>>>>
> >>>>>>> As Dave Thaler convinced us/me, I believe the procedure could be: ??IETF
> >>>>>>> Review?? as defined in RFC 5226.
> >>>>>>> If the latter, is there a way to tell ??do not use; use mib-2?? ...
> >>>>>>> assuming
> >>>>>>>>>> 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
> Mit freundlichen Gr????en,
> Dr. Johannes Merkle
> Principal

---

From: RFC Editor <[email-masked]>
Date: Thu, 15 Oct 2015 09:22:51 -0700

Benoit,

While errata doesn't solve the problem, do you want one filed anyway
so that the issue is noted publicly somewhere? 

Thanks,
Sandy

On Thu, Oct 15, 2015 at 06:00:27PM +0200, Benoit Claise wrote:
> - The MIB doctors advised not to publish MIB modules under
> snmpModules any longer. IANA updated the registry information. See http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-61
> - RFC 7360 is published with a mistake. The MIB module should have
> been published under mib-2.235 (as advised by the MIB doctor) and
> the document mentions: snmpModules.235
> - Solving this issue with an errata doesn't work: indeed MIB modules
> are extracted from RFC, and used within scripts.
> The way forward is to publish a new draft ASAP with the corrections,
> to have a one week IETF LC, and to publish the new RFC. At that
> point (and not before because we don't have a replacement RFC), we
> will obsolete RFC 7360.
> 
> >>>>>>just confirmed the registration procedures.   The
> >>>>>>outstanding question
> >>>>>>is
> >>>>>>ask a question to Michelle. Is there an actual
> >>>>>>registration request or
> >>>>>>are

---

From: Johannes Merkle <[email-masked]>
Date: Thu, 15 Oct 2015 18:31:11 +0200

so, should I submit a new version of draft-ietf-opsawg-hmac-sha-2-usm-snmp? I am not sure, if this is possible, after
publication as RFC. Or shall I submit it under a new name, e.g. draft-ietf-opsawg-hmac-sha-2-usm-snmp-new?

Johannes

---

From: RFC Editor <[email-masked]>
Date: Thu, 15 Oct 2015 09:41:27 -0700

Hi Johannes,

Ideally, a new ID name would be used. 

Thanks,
RFC Editor/sg

---

From: Benoit Claise <[email-masked]>
Date: Thu, 15 Oct 2015 20:21:04 +0200

> so that the issue is noted publicly somewhere?
That would make sense.
Johannes, could you please file an errata. I'll accept it.

Regards, Benoit
> .

---

From: Benoit Claise <[email-masked]>
Date: Tue, 20 Oct 2015 09:02:41 +0200

Hi Johannes,

Thanks for the draft draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-00
Can you please file an errata on http://datatracker.ietf.org/doc/rfc7630/

Regards, Benoit