patch to enhance range unions in smidump generated python & perl
The python & perl smidump modules (and possibly others) don't generate useful code for size/range constraint unions. For example, an object defined with syntax: SYNTAX OCTET STRING (SIZE (1|8)) will result in the following dumped python code:
"syntax" : { "type" : { "basetype" : "OctetString", "range" : { "min" : "1", "max" : "1" } "range" : { "min" : "8", "max" : "8" }, }, }
This isn't very useful, since the second assignment to the 'range' dictionary key blows away the first one.
I have written a patch for the python & perl dumpers to fix this problem. It creates a new key called 'ranges' which references a list of range dictionaries. To ensure backward compatibility, the last 'range' key/value pair is retained.
With this patch, the above syntax clause will now get dumped as:
"syntax" : { "type" : { "basetype" : "OctetString", "ranges" : [ { "min" : "1", "max" : "1" }, { "min" : "8", "max" : "8" }, ], "range" : { "min" : "8", "max" : "8" }, }, },
This allows knowledgeable apps to iterate through the 'ranges' list and properly deal with constraint unions, while older apps can still use the original, but possibly incorrect, 'range' key.
thanks, --randy
On Tue, Jul 11, 2006 at 02:21:17PM -0700, Randy Couey wrote:
[...]
I have written a patch for the python & perl dumpers to fix this problem. It creates a new key called 'ranges' which references a list of range dictionaries. To ensure backward compatibility, the last 'range' key/value pair is retained.
[...]
This allows knowledgeable apps to iterate through the 'ranges' list and properly deal with constraint unions, while older apps can still use the original, but possibly incorrect, 'range' key.
I have no clue how important it is to maintain bugward compatibility since I have no clue if anyone is using these output formats. On the other hand, if we do not provide the old range, apps might believe there is no range defined at all.
Another alternative could be to generate a range which is less strict, that is for [1:1] and [8:8] we could spit out [1:8] which might be better than generating just [8:8]. (Note that libsmi ensures that ranges are in ascending order if I recall correctly, regardless how things were defined in the MIB module.)
/js
[...]
I have no clue how important it is to maintain bugward compatibility since I have no clue if anyone is using these output formats. On the other hand, if we do not provide the old range, apps might believe there is no range defined at all.
The only app that I'm aware of that uses this is the libsmi2pysnmp utility from PySNMP (4.x), but I assume there are probably others.
Another alternative could be to generate a range which is less strict, that is for [1:1] and [8:8] we could spit out [1:8] which might be better than generating just [8:8]. (Note that libsmi ensures that ranges are in ascending order if I recall correctly, regardless how things were defined in the MIB module.)
That's very similar to how I had been "fixing" the problem previously. For the few clauses where it mattered, I was simply changing SIZE(x|y) to SIZE(x..y). This allowed smidump to create a single range as you described above.
Even though that solution gives better results than before, it's still not correct. I think the list of ranges that I proposed is the best solution, since there is no loss of information.
--randy
On Wed, Jul 12, 2006 at 07:27:47AM -0700, Randy Couey wrote:
Another alternative could be to generate a range which is less strict, that is for [1:1] and [8:8] we could spit out [1:8] which might be better than generating just [8:8]. (Note that libsmi ensures that ranges are in ascending order if I recall correctly, regardless how things were defined in the MIB module.)
That's very similar to how I had been "fixing" the problem previously. For the few clauses where it mattered, I was simply changing SIZE(x|y) to SIZE(x..y). This allowed smidump to create a single range as you described above.
Even though that solution gives better results than before, it's still not correct. I think the list of ranges that I proposed is the best solution, since there is no loss of information.
I might not have been very clear. What I meant is to do what you propose with the minor change that the legacy range element would be indicating the full range and not just the last range element.
/js
On Wed, Jul 12, 2006 at 05:34:41PM +0200, Juergen Schoenwaelder wrote:
On Wed, Jul 12, 2006 at 07:27:47AM -0700, Randy Couey wrote:
Another alternative could be to generate a range which is less strict, that is for [1:1] and [8:8] we could spit out [1:8] which might be better than generating just [8:8]. (Note that libsmi ensures that ranges are in ascending order if I recall correctly, regardless how things were defined in the MIB module.)
That's very similar to how I had been "fixing" the problem previously. For the few clauses where it mattered, I was simply changing SIZE(x|y) to SIZE(x..y). This allowed smidump to create a single range as you described above.
Even though that solution gives better results than before, it's still not correct. I think the list of ranges that I proposed is the best solution, since there is no loss of information.
I might not have been very clear. What I meant is to do what you propose with the minor change that the legacy range element would be indicating the full range and not just the last range element.
I have checked in the modified patch. Here is now what I get for DateAndTime (SNMPv2-TC) which is defined as (SIZE (8 | 11)):
"DateAndTime" : { "basetype" : "OctetString", "status" : "current", "ranges" : [ { "min" : "8", "max" : "8" }, { "min" : "11", "max" : "11" }, ], "range" : { "min" : "8", "max" : "11" },
Thanks for submitting the patch.
/js
On Thu, 2006-07-13 at 00:09 +0200, Juergen Schoenwaelder wrote:
[...]
I might not have been very clear. What I meant is to do what you propose with the minor change that the legacy range element would be indicating the full range and not just the last range element.
I agree - that sounds good. (I did indeed misinterpret what you said earlier)
I have checked in the modified patch. Here is now what I get for DateAndTime (SNMPv2-TC) which is defined as (SIZE (8 | 11)):
"DateAndTime" : { "basetype" : "OctetString", "status" : "current", "ranges" : [ { "min" : "8", "max" : "8" }, { "min" : "11", "max" : "11" }, ], "range" : { "min" : "8", "max" : "11" },Thanks for submitting the patch.
Thanks for accepting it!
The pysnmp maintainers have already accepted my patch for libsmi2pysnmp which utilizes this fix.
--randy
participants (2)
-
Juergen Schoenwaelder -
Randy Couey