Copies To: jmp at pwg.org, chrisw at iwl.com
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 <rbergma at dpc.com>
>To: chrisw at iwl.com>Cc: jmp at pwg.org>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.