Subject: RE: [ipcdn] NCS Sig MIB draft 5 - PktcRingCadence constraints

From: "Eugene Nechamkin" <[email-masked]>
Date: Wed, 1 Sep 2004 12:18:15 -0700

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. 
 
Eugene.

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Beacham Gordon-CGB005
Sent: Wednesday, September 01, 2004 9:46 AM
To: [email-masked]'
Subject: [ipcdn] NCS Sig MIB draft 5 - PktcRingCadence constraints

The following issue has been raised on PktcRingCadence during MIB Dr.
review. Any comments on whether we need to introduce MUST requirements
to enforce the constraints noted below? Thanks.
 
Gordon
 
>From Randy:
 
>12) PktcRingCadence: are implementations required to enforce any
constraints on the values of a) the bit count field, b) >the repeatable
field, c) the 3 on-off transition limit, d) values for bits beyond the
bit count, e) an octet-string length other >than the minimum required to
encode whatever length is specified in the bit count field?
_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Sep 2004 21:38:20 -0700

Hi -

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

> 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