Subject: Re: JMP> OID Assignment for an Informational RFC MIB

From: [email-masked] (Ira Mcdonald x10962)
Date: Tue, 23 Sep 1997 15:33:27 PDT

Copies To:  [email-masked], [email-masked]

Hi Ron,                                      Tuesday (23 September 1997)

Unfortunately, IETF SMIv2 (RFC 1902, see excerpt below) is very clear
that BOTH the 'mgmt' and 'experimental' arcs are RESERVED, to Internet
standards track RFCs and experiemental RFCs developed by chartered IETF
working groups, respectively.  The 'enterprises' arc under 'private' is
the only acceptable place for an 'Informational RFC'.  Under the IETF
Printer MIB arc is also clearly illegal (since the PWG Job Mon MIB is
NOT a chartered IETF working group).

This is why (speaking SOLELY as an individual) I have reservations about
the 'Informational RFC' approach (although I agree with Harry Lewis when
he says "it's a standard if all of us printer vendors implement it").

I know this sounds dumb, but why don't we ask the IESG to charter the
JMP working group as a separate project (ie, NOT as a subtask of the
Printer MIB, which they are clearly not buying into)?

Regards,
- Ira McDonald
  906-494-2434

----------------------------- [RFC 1902] -------------------------------

Network Working Group                               SNMPv2 Working Group
Request for Comments: 1902                                       J. Case
Obsoletes: 1442                                      SNMP Research, Inc.
Category: Standards Track                                  K. McCloghrie
                                                     Cisco Systems, Inc.
                                                                 M. Rose
                                            Dover Beach Consulting, Inc.
                                                           S. Waldbusser
                                          International Network Services
                                                            January 1996

                  Structure of Management Information
                          for Version 2 of the
              Simple Network Management Protocol (SNMPv2)

[...excerpt]
4.  Naming Hierarchy

   The root of the subtree administered by the Internet Assigned Numbers
   Authority (IANA) for the Internet is:

     internet       OBJECT IDENTIFIER ::= { iso 3 6 1 }

   That is, the Internet subtree of OBJECT IDENTIFIERs starts with the
   prefix:

     1.3.6.1.

   Several branches underneath this subtree are used for network
   management:

     mgmt           OBJECT IDENTIFIER ::= { internet 2 }
     experimental   OBJECT IDENTIFIER ::= { internet 3 }
     private        OBJECT IDENTIFIER ::= { internet 4 }
     enterprises    OBJECT IDENTIFIER ::= { private 1 }

   However, the SMI does not prohibit the definition of objects in other
   portions of the object tree.

   The mgmt(2) subtree is used to identify "standard" objects.

   The experimental(3) subtree is used to identify objects being
   designed by working groups of the IETF.  If an information module
   produced by a working group becomes a "standard" information module,
   then at the very beginning of its entry onto the Internet standards
   track, the objects are moved under the mgmt(2) subtree.

   The private(4) subtree is used to identify objects defined
   unilaterally.  The enterprises(1) subtree beneath private is used,
   among other things, to permit providers of networking subsystems to
   register models of their products.
----------------------------- [RFC 1902] -------------------------------

>Date: Mon, 22 Sep 1997 19:27:37 PDT
>From: Ron Bergman <[email-masked]>
>To: [email-masked]
>Cc: [email-masked]
>Subject: JMP> OID Assignment for an Informational RFC MIB
>
>Chris,
>
>In a recent discussion regarding the submission of the Job Monitoring MIB
>as a Informational RFC, the question was raised as to the OID branch that
>will be assigned to the MIB.  I mistakely believed that I could answer
>this question by looking at some existing Informational RFCs.  It appears
>that no MIB documents in this category exist.
>
>We would certainly like to have the Job Monitoring MIB to have an OID in
>the mgmt.mib subtree rather than the experimental or the private subtree.
>Since it is likely that the Job MIB will be the first document to be
>accepted as an Information MIB, what is the position of the IESG as to the
>assignment of the base OID?
>
>If this number is in the mgmt.mib subtree, it would certainly resolve most
>of our fears as to submitting the MIB as an Informational RFC.  If the
>experimental or private subtree must be used, we will certain push harder
>for this MIB to be a Standards Track document.
>
>The other possibility discussed was adding the Job MIB as a subtree to the
>Printer MIB.  This is functionally not desirable, but would be proposed if
>it becomes the only alternative.
>
>Any help you can provide on this matter would be greatly appreciated.
>
>    Ron Bergman
>    Dataproducts Corp.

---

From: Ron Bergman <[email-masked]>
Date: Tue, 23 Sep 1997 19:01:28 -0700 (Pacific Daylight Time)

Ira,

Thanks for the update!  You certainly have clarified the situation and I
do agree with you regarding the Informational RFC approach.

Chris,

What is the possibility of requesting a working group charter for the Job
Monitoring MIB as a project separate from the Printer MIB?

	Ron

---

From: Chris Wellens <[email-masked]>
Date: Wed, 24 Sep 1997 01:56:10 -0700 (PDT)

> Monitoring MIB as a project separate from the Printer MIB?

Zero.  One of Harald A.'s last messages (to either this list or
the pmp list) explained that the IETF only wants to charter working
groups where they (Area Directors and above) have expertise to bring 
to the party.  The way the process is set up, the higher you are
in the organization, the more work you have to do.  So, Fred
Baker, Chair of the IETF, actually has to read every single RFC.
It is a bit of an odd process, because it is reverse delegation
of work, in a way.  Obviously, then, the goal would be to
restrict the number of working groups and be highly selective in
what is chartered.  Since printers and issues with printers do
not represent core-Internet protocols or technology, there is a
disincentive to include them.  

Given the above and given the fact that the Printer MIB was
already chartered as a working group, Lloyd and I figured that
the only possible way to get the Job MIB chartered was to add it
to the Printer MIB.  It actually did get approved by our
previous Area Director, but then for some reason when the
transition took place, the Job MIB request for charter was 
re-reviewed, and then rejected.

I have some calls in about the rationale behind the IANA
assignments as put forth in RFC 1902.  I hope to have some
answers by a week from today.