Subject: JMP> Re: Question about assigning OIDs for the Job Monitoring MIB

From: [email-masked]
Date: Thu, 15 May 1997 18:41:30 -0400 (EDT)

>Jeff,

hi tom, everybody

>Just to make sure that we are assigning our OIDs properly for the
>Job Monitoring MIB we have:
>...
>[snip]

what you sent me looks ok ... i didn't see anything out-of-the-ordinary

>NOTE: I had to add "G" to the jmJobState group arc name, since the first
>object (column) in the jmJobStateTable is also named jmJobState.

that looked pretty weird ... i suggest you at least put on a comment
that says "no, this is not a typo" or you will be creating a "frequently
asked question"

>Some of us were wondering whether we could eliminate an arc, since
>each of our groups is exactly one table, i.e., assign the table OID
>instead of a group OID at the .1.1 position?:

i suggest you not do this ... you have only one table in each clump now,
but you do not know what the future holds ... we added things to groups
in mib 2 after we got some experience ... maybe unlikely to happen to
smart guys like printer mib designers, and we have more experience now
that we had back then, but, for me, the engineering tradeoff between
the possibility that you will want to add to a group is pretty good, and
the savings you get by supressing an oid fragment are pretty small -- does
not seem like a good tradeoff in my book, but this is a judgement call
that could go either way

argue it until you get tired, then pick one ... i'd leave the extra level
in

>Suppose that we were to add trapping in a future revision.  Would we
>have a problem, since jobmonMIBConformace is already allocated as
>jobmonMIB.2.  Would we then add jobmonMIBNotifications as jobmonMIB.3?

you can either:
        move jobmonMIBConformance "over" one to .3 now and
        reserve jobmonMIB.2 for notifications

        or

        you can add jobmonMIBNotifications as jobmonMIB.3 later

both are syntactically correct
both are semantically correct
the former is somewhat preferred as more "look and feel" correct but
has momentum against it -- but, you have not yet published as an rfc,
so it is no big deal

i'd probably move it and put in the reserved for future use thing, but
this is not worth a major fight ... we are mainly into the real of taste
with this item

regards,
jdc