Thank you for the references for BITS. When this issue came up at the
meeting last week, the impact of this change was unknown. It now appears
that this is only a cosmetic change and I have no further objections.
I suggest that the subject be closed and the syntax remain as BITS.
Ron Bergman
Dataproducts Corp.
On Tue, 17 Nov 1998, Matt King wrote:
> Ron, All,
>
> I have complied into this not what seems to be applicable to this discussion
> of changes to hrPrinterDetectedErrorState.
>
> The included references are:
> 1) An excerpt from RFC1902 (SMIv2) relating to the BITS construct.
> 2) An excerpt from RFC1906 (Transport Mappings) relating to the BITS
> construct.
> 3) The definition of hrPrinterDetectedErrorState from RFC1514.
> 4) The definition of hrPrinterDetectedErrorState from the internet-draft.
>
> The things that would break existing implementations are:
> 1) If base ASN.1 type changed.
> 2) If bit-field positions changed.
> 3) If bit-field definitions changed.
> 4) If restrictions on use of base type were broken.
>
> As I see it, the proposed changed would not break existing implementations.
> 1) SNMPv2 transport mappings [rfc1906.txt], specifies that the BITS
> construct is encoded as an OCTET-STRING which matches the
> original definition of hrPrinterDetectedErrorState [rfc1514.txt].
> 2) SNMPv2 transport mappings [rfc1906.txt], specifies that Bit 0 is
> defined to be the MSB of the first octet which matches the
> original definition of hrPrinterDetectedErrorState [rfc1514.txt].
> 3) The new definition of hrPrinterDetectedErrorState [draft-krupczak-
> hostmibv2-01.txt] defines bits 0-7 to have identical meaning as the
> original definition of hrPrinterDetectedErrorState [rfc1514.txt].
> 4) The new definition of hrPrinterDetectedErrorState [draft-krupczak-
> hostmibv2-01.txt] extends the length of the OCTET-STRING to 2. The
> original definition of hrPrinterDetectedErrorState [rfc1514.txt]
> placed on constraints on the length of the OCTET-STRING.
>
> Matt King
> Lexmark International
>
> References:
>
> [rfc1902.txt]
> 7.1.4. The BITS construct
>
> The BITS construct represents an enumeration of named bits. This
> collection is assigned non-negative, contiguous values, starting at
> zero. Only those named-bits so enumerated may be present in a value.
> (Thus, enumerations must be assigned to consecutive bits; however,
> see Section 9 for refinements of an object with this syntax.)
>
> Although there is no SMI-specified limitation on the number of
> enumerations (and therefore on the length of a value), MIB designers
> should realize that there may be implementation and interoperability
> limitations for sizes in excess of 128 bits.
>
> Finally, a label for a named-number enumeration must consist of one
> or more letters or digits (no hyphens), up to a maximum of 64
> characters, and the initial character must be a lower-case letter.
> (However, labels longer than 32 characters are not recommended.)
>
> [rfc1906.txt]
> (3) When encoding an object whose syntax is described using the BITS
> construct, the value is encoded as an OCTET STRING, in which all
> the named bits in (the definition of) the bitstring, commencing
> with the first bit and proceeding to the last bit, are placed in
> bits 8 to 1 of the first octet, followed by bits 8 to 1 of each
> subsequent octet in turn, followed by as many bits as are needed of
> the final subsequent octet, commencing with bit 8. Remaining bits,
> if any, of the final octet are set to zero on generation and
> ignored on receipt.
>
> [rfc1514.txt]
> hrPrinterDetectedErrorState OBJECT-TYPE
> SYNTAX OCTET STRING
> ACCESS read-only
> STATUS mandatory
> DESCRIPTION
> "This object represents any error conditions
> detected by the printer. The error conditions are
> encoded as bits in an octet string, with the
> following definitions:
>
> Condition Bit # hrDeviceStatus
>
> lowPaper 0 warning(3)
> noPaper 1 down(5)
> lowToner 2 warning(3)
> noToner 3 down(5)
> doorOpen 4 down(5)
> jammed 5 down(5)
> offline 6 down(5)
> serviceRequested 7 warning(3)
>
> If multiple conditions are currently detected and
> the hrDeviceStatus would not otherwise be
> unknown(1) or testing(4), the hrDeviceStatus shall
> correspond to the worst state of those indicated,
> where down(5) is worse than warning(3) which is
> worse than running(2).
>
> Bits are numbered starting with the most
> significant bit of the first byte being bit 0, the
> least significant bit of the first byte being bit
> 7, the most significant bit of the second byte
> being bit 8, and so on. A one bit encodes that
> the condition was detected, while a zero bit
> encodes that the condition was not detected.
>
> This object is useful for alerting an operator to
> specific warning or error conditions that may
> occur, especially those requiring human
> intervention."
> ::= { hrPrinterEntry 2 }
>
> [draft-krupczak-hostmibv2-01.txt]
> hrPrinterDetectedErrorState OBJECT-TYPE
> -- SYNTAX BITS (0..128) {
> SYNTAX BITS {
> lowPaper(0),
> noPaper(1),
> lowToner(2),
> noToner(3),
> doorOpen(4),
> jammed(5),
> offline(6),
> serviceRequested(7),
>
> inputTrayMissing(8),
> outputTrayMissing(9),
> markerSupplyMissing(10),
> outputNearFull(11),
> outputFull(12),
> inputTrayEmpty(13),
> overduePreventMaint(14)
> }
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "This object represents any error conditions
> detected by the printer. The error conditions are
> encoded as bits in an octet string, with the
> following definitions:
>
> Condition Bit # hrDeviceStatus
>
> lowPaper 0 warning(3) or down(5)
> noPaper 1 warning(3) or down(5)
> lowToner 2 warning(3) or down(5)
> noToner 3 warning(3) or down(5)
> doorOpen 4 warning(3) or down(5)
> jammed 5 warning(3) or down(5)
> offline 6 warning(3) or down(5)
> serviceRequested 7 warning(3) or down(5)
>
> inputTrayMissing 8 warning(3) or down(5)
> outputTrayMissing 9 warning(3) or down(5)
> markerSupplyMissing 10 warning(3) or down(5)
> outputNearFull 11 warning(3) or down(5)
> outputFull 12 warning(3) or down(5)
> inputTrayEmpty 13 warning(3) or down(5)
> overduePreventMaint 14 warning(3) or down(5)
>
> If multiple conditions are currently detected and
> the hrDeviceStatus would not otherwise be
> unknown(1) or testing(4), the hrDeviceStatus shall
> correspond to the worst state of those indicated,
> where down(5) is worse than warning(3) which is
> worse than running(2).
>
> Bits are numbered starting with the most
> significant bit of the first byte being bit 0, the
> least significant bit of the first byte being bit
> 7, the most significant bit of the second byte
> being bit 8, and so on. A one bit encodes that
> the condition was detected, while a zero bit
> encodes that the condition was not detected.
>
> This object is useful for alerting an operator to
> specific warning or error conditions that may
> occur, especially those requiring human
> intervention.
>
> Because error bits 8 through 14 can indicate a printer
> that is still functioning, the corresponding
> (recommended) printer hrDeviceStatus can be either
> warning(3) or down(5).
>
> New bits may be defined by standards-track MIB modules
> but the maximum size of instances of this variable
> should be 128 octets."
> ::= { hrPrinterEntry 2 }
>
> On Tuesday, November 17, 1998 10:32 AM, Ron Bergman [SMTP:rbergma%dpc.com@interlock.lexmark.com] wrote:
> > So... Does the BITS encoding match the encoding in the previous draft?
> >
> > Where is the BITS encoding formally defined? I can't find it in RFC 1902.
> >
> > Ron Bergman
> > Dataproducts Corp.
> >
> >
> > On Mon, 16 Nov 1998, Michael Kirkham wrote:
> >
> > >
> > > BITS is encoded as OCTET STRING. They are not the same as the "Bit
> > > String" ASN.1 type. Rather, they are a way of formalizing the naming of
> > > and assignment of individual meaning to individual bits in an OCTET
> > > STRING. It essentially accomplishes the same task as giving bits names in
> > > the DESCRIPTION, but allows the names of bits to be used by management
> > > applications in the same way that names to enumerations can be (ie., via a
> > > compiled MIB file).
> > >
> > > I don't mean to argue for or against the change to BITS -- just to
> > > clarify. I don't think it should affect any code whatsoever given that it
> > > is totally transparent on the wire. That is, assuming the bit assignments
> > > are kept consistent in the change to BITS.
> > >
> > > [Note, however, the latest draft I have 11-02-98, which uses the BITS
> > > construct incorrectly: the bit names are still listed in the DESCRIPTION,
> > > rather than externally a la enums. I haven't paid close enough attention
> > > to know if there is a later draft.]
> > >
> > > On Mon, 16 Nov 1998, Ron Bergman wrote:
> > >
> > > > Bobby,
> > > >
> > > > I am also opposed to this change. I cannot find an exact definition of
> > > > BITS in SMIv2. But if it is the same as Bit String it is a very different
> > > > syntax from the current HR MIB (RFC 1514). Since this breaks all current
> > > > Printer MIB implementations, there cannot be any good reasons for this
> > > > change.
> > > >
> > > > Ron Bergman
> > > > Dataproducts Corp.
> > > >
> > > >
> > > > On Mon, 16 Nov 1998, Jay Martin wrote:
> > > >
> > > > > Bobby,
> > > > >
> > > > > Sorry for not catching this change sooner. We've been
> > > > > pretty swamped with voluminous drafts in the PWG over
> > > > > the past couple of years. Hopefully you can understand
> > > > > how such a change might have been missed.
> > > > >
> > > > > So, can you give us some kind of a response to our questions?
> > > > >
> > > > > ...jay
> > > > >
> > > > >
> > > > > Bobby Krupczak wrote:
> > > > > >
> > > > > > Hi!
> > > > > >
> > > > > > >This is not good for me, either. Can anyone explain
> > > > > > >why this was done? I can get behind this kind of change
> > > > > > >if someone can clearly delineate the positive aspects of
> > > > > > >using a Bit string as opposed to octetString.
> > > > > >
> > > > > > >Harry Lewis wrote:
> > > > > > >>
> > > > > > >> During discussion and review at the "MIB meeting" in Tucson (PWG), we noticed
> > > > > > >> (for the first time) that hrPrinterDetectedErrorState syntax was changed from
> > > > > > >> octetString to Bits!! I have determined that this will result in code changes
> > > > > > >> for us. We are, therefore OPPOSED to this change! Can someone state the reason
> > > > > > >> for this change? Is anyone adamantly opposed to leaving it as is?
> > > > > >
> > > > > > I love this response!!!! Ive been awaiting feedback from various
> > > > > > printer working group people for 6 months and only now that its gone
> > > > > > through 2 revisions and only now that Im working on the
> > > > > > interoperability report for the IETF that anyone objects.
> > > > > >
> > > > > > Harry Lewis, in particular, should have made these comments much much
> > > > > > earlier in the process.
> > > > > >
> > > > > > Bobby
> > > > >
> > > >
> > > >
> > >
> > > -----------------------------------------------------------------------
> > > --==--==- Michael Kirkham Senior Engineer InterWorking Labs, Inc.
> > > ==--==--= 4113 Scotts Valley Drive, Suite 200 Scotts Valley, CA 95066
> > > --==--==- mikek@iwl.com +1 831 430 3610 +1 831 430 9144 Fax
> > > -----------------------------------------------------------------------
> > >
> > >
> >
>