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
On Tue, 23 Sep 1997, Ira Mcdonald x10962 wrote:
> Copies To: jmp@pwg.org, chrisw@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@dpc.com>
> >To: chrisw@iwl.com
> >Cc: jmp@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.
>