Re: NCS Sig MIB draft 5 - PktcRingCadence constraints

Hi -

> From: "Eugene Nechamkin" <[email protected]>
> To: "Beacham Gordon-CGB005" <[email protected]>; <[email protected]>
> Sent: Wednesday, September 01, 2004 12:18 PM
> Subject: RE: [ipcdn] NCS Sig MIB draft 5 - PktcRingCadence constraints
>

>
> The "inforcement" of the PktcRingCadence TC is supposed to be provided
> by the fact that an EMTA will try to interpret the MIB Object's value in
> the SNMP SET in accordance with the rules of the TC. If the value cannot
> be interpreted correctly, the SNMP error flag should be raised and
> returned in the SNMP SET response message. This is a general SNMP
> protocol approach applicable to any MIB Object, and I don't see anything
> "special" in PktcRingCadence TC in this respect to be able to agree with
> the dedicated "inforcement" statement.
....

So the intent is that implementations MUST perform
the following checks:
    - the first two bytes MUST represent a value between 1 and 264;
      any other values MUST be rejected.
    - the bit count field needs to be consistent with the
      OCTET STRING's length.  If there are unused octets,
      the set MUST be rejected.  Likewise, if the length implied
      by the bit count field is greater than the OCTET STRING's
      length, the set MUST be rejected.
    - the value of the repeatable field MUST be 0x00 or 0x80
    - If there are more than three on-to-off transitions, the set MUST
      be rejected.  (So 01010101 would be legal, but 10101010 would
      not, right?)

This still begs the question of what value should be in the "unused"
bits.  Ignored by receiver?  What value SHOULD they be set to
by the sender?  Are they required to be the same on a GET as they were
on the SET?

Randy