<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Muonics, Inc. &#187; News</title>
	<atom:link href="http://www.muonics.com/blog/category/news/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.muonics.com/blog</link>
	<description>News, articles, and information about Muonics products and network management.</description>
	<lastBuildDate>Tue, 02 Feb 2010 09:40:35 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>MIB Smithy SDK 4.0 Released</title>
		<link>http://www.muonics.com/blog/177/mib-smithy-sdk-4-0-released/</link>
		<comments>http://www.muonics.com/blog/177/mib-smithy-sdk-4-0-released/#comments</comments>
		<pubDate>Mon, 01 Feb 2010 11:38:40 +0000</pubDate>
		<dc:creator>Michael Kirkham</dc:creator>
				<category><![CDATA[Announcements]]></category>
		<category><![CDATA[MIB Smithy SDK]]></category>
		<category><![CDATA[ipv6]]></category>
		<category><![CDATA[snmp]]></category>
		<category><![CDATA[mibsmithysdk]]></category>
		<category><![CDATA[tcl]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=177</guid>
		<description><![CDATA[MIB Smithy SDK 4.0 is released at long last! This is a major release composed of significant architecture changes, new features, and assorted bug fixes. High level changes include IPv6 support, a new license key format that supports licensing based on user name (as an alternative to host-based licensing), many new validation rules and error [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://www.muonics.com/Products/MIBSmithySDK/">MIB Smithy SDK</a> 4.0 is released at long last! This is a major release composed of significant architecture changes, new features, and assorted bug fixes. High level changes include IPv6 support, a new license key format that supports licensing based on user name (as an alternative to host-based licensing), many new validation rules and error level adjustments, and better integration with Tcl&#8217;s own support for binary data, and platform changes.</p>
<p>As of 4.0, some older platform versions are no longer officially supported, but newer versions are:</p>
<table>
<tr>
<th>Platform</th>
<th>MIB Smithy SDK 3.4</th>
<th>MIB Smithy SDK 4.0+</th>
</tr>
<tr>
<td>Solaris SPARC</td>
<td>2.7+</td>
<td>10+</td>
</tr>
<tr>
<td>Linux x86</td>
<td>Red Hat 7.3/compatible</td>
<td>Fedora Core 7/compatible</td>
</tr>
<tr>
<td>Linux x86_64</td>
<td>none</td>
<td>Fedora Core 7/compatible</td>
</tr>
<tr>
<td>FreeBSD x86</td>
<td>4.3/compatible</td>
<td>6.2/compatible</td>
</tr>
<tr>
<td>Windows</td>
<td>no change</td>
<td>no change</td>
</tr>
<tr>
<td>Mac OS X</td>
<td>no change</td>
<td>no change</td>
</tr>
</table>
<p>This is not to say definitively that the SDK will not work with the older platforms, however, as it&#8217;s likely just a matter of having the appropriate dependencies installed (e.g. libstdc++). Rather, these are the platforms the releases are built on, and the older platforms have been (or will soon be) retired, so we won&#8217;t be able to guarantee support that far back anymore.</p>
<p>Some changes still need to be made to the web site to support Linux x86_64 and user-based licensing, and I&#8217;ll get to work on those right away. In the mean time, if you are interested in either of these, please contact support and we&#8217;ll get you squared away.</p>
<p>If you haven&#8217;t already, and you&#8217;re currently using an older version of the SDK, be sure to read my other post about <a href="http://www.muonics.com/blog/167/a-sneek-peek-at-mib-smithy-sdk-4-0/">potential compatibility issues posed by the binary data changes</a>.</p>
<h3>Changes in MIB Smithy SDK 4.0:</h3>
<p>As always, your feedback is important in determining changes and fixes that will be made in coming releases. If you have questions or comments, please don&#8217;t hesitate to contact us. The following changes have been made in this release:</p>
<p><strong>1359: New options for formatting OCTET STRINGs</strong></p>
<p>A new -strformat option was added to [smilib format] to enhance support for formatting OCTET STRINGs (now treated as byte arrays via APIs). The default, configurable for the database, is &#8220;1x:&#8221; for colon-delimited hex format.</p>
<p>[smilib format] also now allows specifying a type in lieu of record name or OID, e.g.:</p>
<p>% smilib format &#8220;OCTET STRING&#8221; foo<br />
66:6f:6f</p>
<p><strong>1658: Return indexparts for strings as byte arrays</strong></p>
<p>[smilib get -indexparts] will no longer return a custom hex format for OCTET STRING and BITS index data, but will instead return raw binary (via Tcl_NewByteArrayObj) to make it easier to work with data at the script level. Use [smilib format] to format data for display, which will use return a hex format in lieu of DISPLAY-HINT.</p>
<p><strong>362: Add Linux x86_64 platform support</strong></p>
<p>The Linux platform with x86_64 architecture is now supported.</p>
<p><strong>1836: Validation for COPS-PR-SPPI&#8217;s OBJECT-TYPE STATUS</strong></p>
<p>Validation rules were added for COPS-PR-SPPI&#8217;s OBJECT-TYPE STATUS field. Previously, values that are not allowed by COPS-PR-SPPI were not reported as errors the way values disallowed by other versions were.</p>
<p><strong>2160: Support multiple Host IDs in license key</strong></p>
<p>Certain users in the past have needed to swap license key files depending on which host they&#8217;re using. With the new license key format, we can provide these users with a single unified key if switching to user-based licensing is not appropriate for their needs.</p>
<p><strong>1707: Check for circular indexing dependencies</strong></p>
<p>Validation rules were added to recursively check through INDEX, AUGMENTS, EXTENDS, PIB-INDEX, and UNIQUENESS relationships to detect loops and improper table normalization (such as A EXTENDS B, B EXTENDS A; or A AUGMENTS B, but B&#8217;s INDEX lists columns from A).</p>
<p><strong>2161: Add support for username-based licensing</strong></p>
<p>A new license key format has been implemented that allows for licensing based on username, rather than on Host ID. Where host-based licenses allow any user on a specific host, username-based licenses allow a specific named user on any host. Existing users who purchased prior to this feature being available can request their license to be permanently converted to a username-based license at no charge provided their support contract is current.</p>
<p><strong>776: Relaxed rule for column syntax vs. row definition</strong></p>
<p>It is now a warning, rather than an error, for a column&#8217;s type in the SEQUENCE definition and the column&#8217;s OBJECT-TYPE to be different, provided the SEQUENCE uses the proper base type.</p>
<p><strong>699: Normalized filename properties</strong></p>
<p>The -filename property for SMI databases and file records is now normalized automatically when set to make its value invariant if the current directory is changed in the Tcl shell (or script) after assignment.</p>
<p><strong>1849: Message clarifications</strong></p>
<p>Many warning and error messages from the parser and validator were reworded (some slightly, some more) for clarification.</p>
<p><strong>1850: Auto-correct swapped subrange endpoints and doublets</strong></p>
<p>When validating size/range specs, swapped and duplicate endpoints in subranges are now automatically corrected after reporting the error. e.g., (3..2|5..5) becomes (2..3|5).</p>
<p><strong>304: Add IPv6 Support</strong></p>
<p>Communicating with SNMP agents over IPv6 is now supported. (Note: nmtrapd protocol doesn&#8217;t currently have a way to indicate an IPv6 source address for traps that aren&#8217;t received directly by the SDK, but there&#8217;s a plan in place to address this limitation.)</p>
<p><strong>1840: Clarify SMI version in error/warning messages</strong></p>
<p>Improved module SMI version detection for application of version-specific rules when imports are missing and changed most validation-stage messages to include the proper version string. (For example, COPS-PR-SPPI inherits most of its rules from SMIv2. Most of these messages previously mentioned SMIv2 even for PIB modules, but will now say COPS-PR-SPPI.)</p>
<p><strong>1837: Disallow non-attributes in COPS-PR-SPPI&#8217;s OBJECT-GROUP</strong></p>
<p>A validation rule was added to generate an error if an OBJECT-TYPE listed in a COPS-PR-SPPI OBJECT-GROUP is not an attribute OBJECT-TYPE.</p>
<p><strong>1895: Setting SMI database options at creation time</strong></p>
<p>The [smilib new] command, when used to create a new SMI database, can now accept options for setting the database properties the same way [snmplib new] can. Previously this required a separate [smilib set] call to set database properties, except when creating records in the database.</p>
<p><strong>1115: Allow named ports, in addition to numeric</strong></p>
<p>TCP ports for sending or receiving SNMP messages can now be specified by service name, rather than just numeric (e.g. &#8220;snmp&#8221; for port 161, if such a named entry is present in /etc/services).</p>
<p><strong>2185: INDEX/related lookup enhancements</strong></p>
<p>Added -extendsdecl, -pibindexdecl, -uniquedecl options to smilib get/set commands for OBJECT-TYPEs to function like -indexdecl and -augmentsdecl in returning the value directly defined in the record, while the old -extends and -pibindex options will return the value from the associated row.</p>
<p>The -index, -pibindex, -pibreferences, etc. options now trace AUGMENTS and EXTENDS to find the values inherited from augmented tables, rather than only looking one node up/down to find the row.</p>
<p>Also added -row and -table properties to return the record for the row or table OBJECT-TYPE associated with the specified OBJECT-TYPE (which could itself be a row, table, or column).</p>
<p><strong>1153: XMLSMI: relax parsing of unrecognized elements</strong></p>
<p>The XML parser now only generates a warning and treats as a successful parse (rather than an error and failed parse) when encountering tags that aren&#8217;t recognized. This should allow new tags to be added down the road, but still allow the file to load into versions back to 4.0.</p>
<p><strong>2184: Correct multiple INDEX/AUGMENTS/etc. at parse time</strong></p>
<p>The SMI parser previously recovered from having too many or out-of-order INDEX, AUGMENTS, etc. clauses by preserving them all and erroring at validation time, despite only having one legal value, which complicated validation and usage.  Instead of preserving them all, the parser now reports the extras as an error only at parse time and discards them, but still supports (and reports) recovery from ordering issues.</p>
<p><strong>1234: Provide socket errors as strings rather than numbers</strong></p>
<p>In a few cases, socket-related errors were provided just as an error number. They should all now give a more meaningful error message. Some of the existing messages have been further clarified.</p>
<p><strong>1871: Add checks for STATUS consistency</strong></p>
<p>Validation rules were added for checking consistency between related records and dependencies. An error or warning may be issued depending on the type of relation and difference (for example, it&#8217;s an error for a row and table to be different, but a warning for a &#8220;current&#8221; OBJECT-TYPE to use a &#8220;deprecated&#8221; TEXTUAL-CONVENTION).</p>
<p><strong>1830: VARIATIONs with DEFVAL and ACCESS not-implemented, accessible-for-notify</strong></p>
<p>A validation rule was added to issue a warning for a VARIATION having both a DEFVAL and ACCESS &#8216;not-implemented&#8217; or &#8216;accessible-for-notify&#8217; (the DEFVAL is superfluous).</p>
<p><strong>1702: Check for scalar objects with MAX-ACCESS not-accessible</strong></p>
<p>A validation rule was added to produce an error for a scalar SMIv2 OBJECT-TYPE having MAX-ACCESS &#8216;not-accessible&#8217;. If the object&#8217;s value is only available via notification, it should have MAX-ACCESS &#8216;accessible-for-notify&#8217;.</p>
<p><strong>1835: OBJECT-TYPEs not in OBJECT-GROUPs in SMIv2, COPS-PR-SPPI</strong></p>
<p>It is now an error, rather than a warning, for OBJECT-TYPEs and NOTIFICATION-TYPEs to not be a member of any OBJECT-GROUP or NOTIFICATION-GROUP when they otherwise must be.</p>
<p><strong>1834: Auto-correct missing &#8216;Z&#8217; suffix in ExtUTCTime values</strong></p>
<p>The validator now automatically corrects a missing &#8216;Z&#8217; suffix in LAST-UPDATED and REVISION timestamps after reporting the issue.</p>
<p><strong>1831: Use of type names (rather than objects) as INDEXes</strong></p>
<p>It is now an error, rather than a warning, for SMIv2 and COPS-PR-SPPI OBJECT-TYPE to use INDEX values pointing to type names rather than object names. For RFC-1212, it&#8217;s now a forward-compatibility warning.</p>
<p><strong>1742: Additional validation for read-create</strong></p>
<p>A validation rule was added to disallow any column from having access &#8220;read-write&#8221; if any column in the same table has access &#8220;read-create&#8221;, per RFC 2578 section 7.3.</p>
<p><strong>1833: Restrictions on MANDATORY-GROUPS and GROUPs</strong></p>
<p>It&#8217;s now an error for MODULE-COMPLIANCE&#8217;s MANDATORY-GROUPS or GROUP clauses to reference anything other than an OBJECT-GROUP or NOTIFICATION-GROUP. Previously they allowed any OID value, like AGENT-CAPABILITIES&#8217; INCLUDES allows specifying SMIv1 branches, but the text of RFC 2576 that allows this (in section 2.3) applies only to AGENT-CAPABILITIES.</p>
<p><strong>1841: Disallow empty binary/hex strings as enum values</strong></p>
<p>Hex/binary strings as enumeration values are not explicitly legal (or illegal) in SMI, but the SDK supports them (with warning) just in case.  However, it makes no sense for something that should be an integer to have no bits, so a validation rule was added to produce a warning specifically for empty hex/binary enumerations and integral DEFVALs.</p>
<p><strong>1842: Do not error for ASN.1 types in plain ASN.1 modules</strong></p>
<p>Towards support for plain ASN.1 modules, error levels for validation rules regarding the use of ASN.1 types not supported by SMI or COPS-PR-SPPI were changed. If the module is clearly intended to be a MIB or PIB module, an error is produced. If nothing is imported from SMI or COPS-PR-SPPI base modules, it&#8217;s assumed to be plain ASN.1 and no error or warning about the type is produced.</p>
<p><strong>1838: Improved parser recovery for enumerated types</strong></p>
<p>Enumerated types are now parseable with empty braces or no braces/enumerations, including BITS (where the legal syntax requires at least one bit to be defined and braced). This is mainly to allow incomplete MIB definitions to be saved and still reloaded in the MIB Smithy editor.</p>
<p><strong>1660: Misleading error when SDK falls back to direct trap port binding</strong></p>
<p>The failure messages from attempts to bind to port 162 before connecting to nmtrapd via Tcl_OpenCommandChannel were left in the interpreter result despite connection succeeding a TCL_OK result being returned. The message could mislead users (at least in the interactive shell) into thinking the [snmplib bind] command failed when it didn&#8217;t.</p>
<p><strong>375: Return OCTET STRINGs as binary</strong></p>
<p>SNMP session APIs no longer automatically encode/decode binary OCTET STRING data to/from hex format, but instead return and accept Tcl&#8217;s native binary format and conventions (e.g., byte array objects, [binary] command, and &#8220;\x&#8221; to specify hex-encoded data in scripts).</p>
<p>This change is intended to simplify scripted use of and prevent APIs from interpreting values as hex encoded when they are intended to be taken as literal.<br />
It affects variable bindings, session properties (such as community strings and passwords), and callback parameters alike.</p>
<p>Use the [smilib format] command to format values for display to a user. You can specify &#8220;OCTET STRING&#8221; to format values that aren&#8217;t associated with a varbind, such as the SNMPv3 Engine ID passed to request callbacks.</p>
<p><strong>1718: ExtUTCTime validation wrong after 2038</strong></p>
<p>ExtUTCTime validation (e.g. LAST-UPDATED and REVISION timestamps) is now Y2K38 compliant, no longer based on Unix epoch.</p>
<p><strong>2209: Wrong keywords for usm privKeyChange -privproto option</strong></p>
<p>The [snmplib usm privKeyChange] command&#8217;s -privproto option was expecting auth protocol keywords rather than priv protocol keywords. Consequently, one could not override the privacy protocol for the session without error.</p>
<p><strong>1832: Warning for duplicate INDEXes</strong></p>
<p>It is now a warning, rather than an error, for an OBJECT-TYPE&#8217;s INDEX to list the same object multiple times. SMIv2 discourages it, but it is not forbidden.</p>
<p><strong>1726: False &#8220;recursive loop&#8221; error with conformance groups</strong></p>
<p>A GROUP clause in MODULE-COMPLIANCE pointing to a non-group with missing dependencies could previously generate a &#8220;OBJECT IDENTIFER value assigned&#8230;is defined as a recursive loop&#8221; error due to the way OIDs were indexed in the old architecture. In the new architecture, along with forbidding non-groups, this is no longer an issue.</p>
<p><strong>1705: Using EXPORTS in SMIv2 modules should be an error</strong></p>
<p>It is now an error for an SMIv2 or COPS-PR-SPPI module to use the ASN.1 module&#8217;s EXPORTS clause. Previously it was a warning because the MIB Smithy editor automatically excluded it upon saving, but since it&#8217;s forbidden it should be an error for standalone validation.</p>
<p><strong>1428: [smilib new] doesn&#8217;t allow some set options</strong></p>
<p>The set of record properties supported by [smilib new] and [smilib set] had gotten out of sync, so some properties of some record types could not be set at creation time. They should be back in sync now, allowing all properties to be set at record creation time.</p>
<h3>Addendum</h3>
<p>The following additional cases were also fixed in 4.0 but didn&#8217;t make it into the release notes (they&#8217;d been dual-committed for 4.0 and a possible 3.4.9, but there was no 3.4.9 release):</p>
<p><strong>1815: Additional validation for first two subidentifiers</strong></p>
<p>ASN.1 places limits on the range of the first two subidentifiers of an OID. Validation previously did not check both values in some cases, depending on the form used to define the OID. Out-of-range values should now be reported as an error regardless of form.</p>
<p><strong>1782: Disallow hyphens in COPS-PR-SPPI enum/bit labels</strong></p>
<p>A warning will now be produced for enumeration and bit labels containing hyphens in COPS-PR-SPPI, as with 3.4.8, which added such warnings to record names.</p>
<p><strong>1779: DEFVAL identifier list not fully validated versus named bits</strong></p>
<p>When using the identifier list form for DEFVAL (used for named bits), the identifiers were not properly checked against the defined bit names to see if they exist.</p>
<p><strong>1802: Validation for single-valued size/range refinements</strong></p>
<p>Validation for size and range refinements was failing to detect and report a value as being out of the base size or range if it was only a single value (rather than a sub-range) in the refinement.</p>
<p><strong>1786: Hex/Binary enumeration order checking incorrect</strong></p>
<p>When using hex or binary values for enumeration and bit values, a false error was reported regarding the order due to treating the value as a hex or binary representation of a string rather than an integer.</p>
<p><strong>1809: Warning to start enums at 1 should not trigger when 1 is refined away</strong></p>
<p>A warning to start enumerations at 1 will no longer be generated for a record that refines the value away (such as a TEXTUAL-CONVENTION that starts at 1, but the OBJECT-TYPE using it refining it away).</p>
<p><strong>1808: Overlapping sizes/ranges should be an error</strong></p>
<p>There was a bug in the rule for detecting overlapping size and range lists that prevented the overlap from being detected in some cases. These will now be reported as an error as they should be.</p>
<p><strong>1810: Duplicate enum values in hex/binary not detected</strong></p>
<p>Duplicate enumeration values were not previously reported as an error if one or both of the values were in hex or binary string format (which is not explicitly legal or illegal in SMI).</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/177/mib-smithy-sdk-4-0-released/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MIB Smithy 4.1.5, SDK 3.4.8, MIB Views 1.4.4 Releases</title>
		<link>http://www.muonics.com/blog/156/mib-smithy-415-sdk-348-and-mib-views-144/</link>
		<comments>http://www.muonics.com/blog/156/mib-smithy-415-sdk-348-and-mib-views-144/#comments</comments>
		<pubDate>Tue, 28 Jul 2009 04:03:04 +0000</pubDate>
		<dc:creator>Michael Kirkham</dc:creator>
				<category><![CDATA[Announcements]]></category>
		<category><![CDATA[MIB Smithy]]></category>
		<category><![CDATA[MIB Smithy SDK]]></category>
		<category><![CDATA[MIB Views]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=156</guid>
		<description><![CDATA[We&#8217;re now in the final stretches of automating regression tests for our MIB parsing and validation code in preparation for releasing the 4.0 branch of the SDK, with better than 3/4 of the test automation done. After the latest round of several hundred tests and analyzing the current results, we identified some more areas for [...]]]></description>
			<content:encoded><![CDATA[<p>We&#8217;re now in the final stretches of automating regression tests for our MIB parsing and validation code in preparation for releasing the 4.0 branch of the SDK, with better than 3/4 of the test automation done. After the latest round of several hundred tests and analyzing the current results, we identified some more areas for improvement in the validation code we felt were appropriate to release in the current stable branch. These include eliminating redundant messages, clarifying other messages, correcting some false errors, some error level adjustments, and some additional rules. The changes below are incorporated into the latest releases for MIB Smithy, MIB Smithy SDK, and MIB Views.<strong></strong></p>
<p><strong>1735: INDEX and AUGMENTS forbidden with RFC1155-SMI, RFC1065-SMI</strong></p>
<p>It is now an error, rather than a warning, for an OBJECT-TYPE to have an INDEX or AUGMENTS clause when imported from RFC1065-SMI or RFC1155-SMI.</p>
<p><strong>1760: TEXTUAL-CONVENTIONs must not derive from other TEXTUAL-CONVENTIONs</strong></p>
<p>It is now an error, rather than a warning, for SMIv2 modules to define TEXTUAL-CONVENTIONs derived from other TEXTUAL-CONVENTIONs. This is also now an error for COPS-PR-SPPI modules, which previously gave no warning.</p>
<p><strong>1747: Additional validation for variant access levels</strong></p>
<p>PIB-MIN-ACCESS is now checked to ensure its values are allowed by COPS-PR-SPPI.  MODULE-COMPLIANCE&#8217;s PIB-MIN-ACCESS and MIN-ACCESS, and AGENT-CAPABILITIES ACCESS, are now checked to ensure their values are within bounds of the referenced object&#8217;s (or PRC&#8217;s) MAX-ACCESS or ACCESS value.</p>
<p><strong>1761: Improved version-specific validation with missing IMPORTS</strong></p>
<p>Previously, when a macro (such as OBJECT-TYPE) was not imported as required, certain version-specific validation checks (such as allowed STATUS values) were suppressed, giving only an error about the missing import. Now, the version may be assumed based on other imports that are present, allowing further checks to be performed.</p>
<p><strong>1733: Suppress bit zero warning when no bits are defined</strong></p>
<p>A redundant warning regarding starting BITS at zero when also erroring about needing at least one bit to be defined.</p>
<p><strong>1738: Clarify access keywords in error messages</strong></p>
<p>Validator messages should use the proper access keyword (ACCESS, MAX-ACCESS, PIB-ACCESS, MIN-ACCESS, PIB-MIN-ACCESS) depending on the record type and version (SMIv1, SMIv2, COPS-PR-SPPI) of the record. In some cases, they simply said &#8220;ACCESS&#8221;.<strong></strong></p>
<p><strong>1701: False errors and changes to BITS DEFVAL validation</strong></p>
<p>The algorithm for checking set bits in hex/binary DEFVALs versus BITS named bit values was not correct, leading to errors for valid DEFVALs. Also, an integer is no longer allowed for DEFVAL with BITS type, and undefined bits may no longer be set in the DEFVAL (previously these were warnings).<strong></strong></p>
<p><strong>1720: Disallow hyphens in COPS-PR-SPPI identifiers</strong></p>
<p>As with SMIv2 modules, which COPS-PR-SPPI derives from, a warning is now produced for identifiers with hyphens in PIB modules.<strong></strong></p>
<p><strong>1717: Wrong range given in INSTALL-ERRORS message</strong></p>
<p>INSTALL-ERRORS was being checked versus the correct allowed range of 1..65535, but the error message indicated 0..65536 was allowed.</p>
<p><strong>1689: False subordinate OID warnings for conformance records</strong></p>
<p>Conformance sub-records were not properly ignored when checking relative structure of the OID tree, causing false errors/warnings to be produced (nothing should be considered relative to these records as they&#8217;re purely an implementation detail, not truly separate from the conformance statement).</p>
<p><strong>1682: Value Assignment values missing from error messages</strong></p>
<p>Error messages regarding ASN.1 Value Assignment values not matching the type were giving an empty string for the value rather than the actual value. (Note: only ASN.1 Value Assignments of type OBJECT IDENTIFIER are allowed in MIB and PIB modules; this validation is part of plain ASN.1 support.)</p>
<p><strong>1685: False warning for starting bit zero when using BITS-derived type</strong></p>
<p>A warning message was produced for OBJECT-TYPEs with SYNTAX referencing a TEXTUAL-CONVENTION of type BITS indicating that bits should start at zero even when the TEXTUAL-CONVENTION itself started at bit zero.</p>
<p><strong>1684: Missing error for invalid PIB-REFERENCES</strong></p>
<p>An incorrect function argument was suppressing the error message for PIB-REFERENCES pointing somewhere other than a PRC (row) OBJECT-TYPE.<strong></strong></p>
<p><strong>1759: REVISIONs not sorted properly by XML parser</strong></p>
<p>MODULE-COMPLIANCE REVISIONs are normally sorted when assigned or parsed from normal SMI syntax (with parse-time warning in the latter case), and therefore not checked during validation. They were not sorted properly by the XML parser, however, leaving them out of order with no indication. They are now sorted at parse time from XML as well.</p>
<p><strong>1716: Severity of Value Assignments in SMIv2/SPPI</strong></p>
<p>It&#8217;s now an error, rather than a warning, to use ASN.1 Value Assignments other than of type OBJECT IDENTIFIER in SMIv2 and COPS-PR-SPPI modules. It remains a warning for SMIv1 modules, but is now suppressed entirely for modules that aren&#8217;t SMI or SPPI (just ASN.1).</p>
<p><strong>1736: Redundant messages for Counter with bad ACCESS</strong></p>
<p>Use of Counter, Counter32, or Counter64 syntax and ACCESS, MAX-ACCESS, or MIN-ACCESS value unknown to the SMI version now produces one error message for the unknown value, rather than a second for the value being disallowed with counter types.</p>
<p><strong>1729: PIB-INDEX may use attributes of other PRCs</strong></p>
<p>An error message was produced if PIB-INDEX referenced an attribute of another PRC (table) rather than an attribute of the same PRC. As this is explicitly allowed by RFC 3159 section 7.5, this check has been removed.</p>
<p><strong>1731: OID in module header forbidden in SMIv2</strong></p>
<p>It&#8217;s now an error, rather than a warning, to assign an OID to a module in the module in SMIv2 or COPS-PR-SPPI modules (which use MODULE-IDENTITY instead).  It remains a warning in SMIv1 and is now suppresed for modules that are neither SMI or SPPI (just ASN.1).</p>
<p><strong>1728: OBJECT-IDENTITY and Assignment with same OID should be a warning</strong></p>
<p>It is now a warning, rather than an error, when an OBJECT-IDENTITY statement and OID Value Assignment have the same OID, as it is with an OID Value Assignment and other macros having the same OID.</p>
<p><strong>1727: Missing error for INDEX with negative enumerations</strong></p>
<p>An intended warning for an INDEX pointing to an object with possible negative enumerations was not being produced.</p>
<p><strong>1725: Superfluous auxilliary INDEX warnings</strong></p>
<p>The warning for a table using only columns from other tables for indices is no longer generated when already indicating an error because the INDEX clause is not allowed (e.g. on a scalar OBJECT-TYPE).</p>
<p><strong>1711: Undefined symbols should always error if known to be undefined</strong></p>
<p>Dependency check &#8220;failed&#8221; errors and &#8220;skipped&#8221; warnings are now more consistent in behavior: e.g., a check is &#8220;skipped&#8221; with a warning if cross-checking can&#8217;t be performed because a module isn&#8217;t loaded, while an error is produced if it is loaded but the symbol imported from is not defined.<strong></strong></p>
<p><strong>1710: Mixing SMI and COPS-PR-SPPI base types/macros</strong></p>
<p>It&#8217;s now an error, rather than a warning, to import both SMI and COPS-PR-SPPI base types and macros within the same module (note: importing MIB OIDs and TEXTUAL-CONVENTIONs in PIB modules is allowed, provided the underlying base type is the supported by the SPPI).</p>
<p><strong>1690: Wrong format indicated in DEFVAL type/value mismatch errors</strong></p>
<p>When comparing the form of DEFVAL values to an object&#8217;s SYNTAX, the wrong keyword for the form of the value was specified in some errors pertaining to hex and binary. The wording of DEFVAL type/value related messages is also now more consistent.<strong></strong></p>
<p><strong>1686: Redundant hex/binary length errors</strong></p>
<p>When validating hex and binary DEFVALs, redundant errors were produced for some types when they were both not of the required length for that type and not the right multiple of digits. There was some inconsistency in whether or not they were checked for capitalization, and the wording of hex/binary related messages was also clarified.</p>
<p><strong>1683: UNIQUENESS value missing from message</strong></p>
<p>A warning message regarding UNIQUENESS values was showing an empty string for the value rather than indicating the actual value warned about.<strong></strong></p>
<p><strong>1708: SMI base modules should not require MODULE-IDENTITY</strong></p>
<p>On the off chance you load SNMPv2-CONF into the SDK and validate it, despite not defining anything other than macros, it will no longer error about needing a MODULE-IDENTITY statement (as with other SMI/COPS base modules).</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/156/mib-smithy-415-sdk-348-and-mib-views-144/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Authorize.Net Down Due to Data Center Fire [Updated]</title>
		<link>http://www.muonics.com/blog/152/authorizenet-down-due-to-data-center-fire/</link>
		<comments>http://www.muonics.com/blog/152/authorizenet-down-due-to-data-center-fire/#comments</comments>
		<pubDate>Fri, 03 Jul 2009 16:26:59 +0000</pubDate>
		<dc:creator>Muonics, Inc.</dc:creator>
				<category><![CDATA[Notices]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=152</guid>
		<description><![CDATA[Word has come to us by way of The Internet Patrol that Authorize.Net is down due to a fire at their Seattle data center. As we use Authorize.Net as our merchant card services provider, this means that we are likely unable to process online orders using credit cards at this time. We can, of course, [...]]]></description>
			<content:encoded><![CDATA[<p>Word has come to us by way of <a href="http://www.theinternetpatrol.com/data-center-fire-sends-authorize-down/">The Internet Patrol</a> that <a href="http://www.authorize.net/">Authorize.Net</a> is down due to a fire at their Seattle data center. As we use Authorize.Net as our merchant card services provider, this means that we are likely unable to process online orders using credit cards at this time. We can, of course, still accept purchase orders in the mean time. We&#8217;ll update this post when we hear that Authorize.Net services have been restored or if we have any additional news.</p>
<p>UPDATE: Authorize.net says they&#8217;re back up (at least the interface we use). Orders placed through our web site should proceed normally.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/152/authorizenet-down-due-to-data-center-fire/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MIB Smithy 4.1.4 Release</title>
		<link>http://www.muonics.com/blog/150/mib-smithy-414-release/</link>
		<comments>http://www.muonics.com/blog/150/mib-smithy-414-release/#comments</comments>
		<pubDate>Wed, 01 Jul 2009 13:13:46 +0000</pubDate>
		<dc:creator>Muonics, Inc.</dc:creator>
				<category><![CDATA[Announcements]]></category>
		<category><![CDATA[MIB Smithy]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=150</guid>
		<description><![CDATA[MIB Smithy 4.1.4 is now available for download. This release fixes the following bugs in the workspaces for AGENT-CAPABILITIES SUPPORTS and MODULE-COMPLIANCE MODULE clauses:
1668: Error editing AGENT-CAPABILITIES modules
A &#8216;can&#8217;t read &#8220;window(groups)&#8221;: no such element in array&#8217; error would occur when opening the workspace for AGENT-CAPABILITIES modules.
1670: Some combobox lists not updated with record name change
Some [...]]]></description>
			<content:encoded><![CDATA[<p>MIB Smithy 4.1.4 is now available for download. This release fixes the following bugs in the workspaces for AGENT-CAPABILITIES SUPPORTS and MODULE-COMPLIANCE MODULE clauses:</p>
<p><strong>1668: Error editing AGENT-CAPABILITIES modules</strong></p>
<p>A &#8216;can&#8217;t read &#8220;window(groups)&#8221;: no such element in array&#8217; error would occur when opening the workspace for AGENT-CAPABILITIES modules.</p>
<p><strong>1670: Some combobox lists not updated with record name change</strong></p>
<p>Some comboboxes for selecting available records in a module to be added as a group or variation in AGENT-CAPABILITIES and MODULE-COMPLIANCE statements were not being automatically repopulated when the name of the module (referenced by the SUPPORTS or MODULE clause) was changed, instead requiring the workspace to be reopened or reverted to get an updated list.</p>
<p><strong>1669: Combobox for VARIATION, GROUP clauses populated from wrong module</strong></p>
<p>Some comboboxes for selecting available records in a module to be added as a group or variation in AGENT-CAPABILITIES and MODULE-COMPLIANCE statements were being populated from the module in which the conformance statement was defined, rather from than the module referenced by the statement&#8217;s SUPPORTS or MODULE clause.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/150/mib-smithy-414-release/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Muonics on Facebook</title>
		<link>http://www.muonics.com/blog/147/muonics-on-facebook/</link>
		<comments>http://www.muonics.com/blog/147/muonics-on-facebook/#comments</comments>
		<pubDate>Mon, 08 Jun 2009 19:31:39 +0000</pubDate>
		<dc:creator>Muonics, Inc.</dc:creator>
				<category><![CDATA[Announcements]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=147</guid>
		<description><![CDATA[Muonics now has a presence on Facebook! If you&#8217;re a Facebook user, please consider becoming a fan of the page(s) that interest you. You can show your support for Muonics and our products and subscribe to news and articles as an alternative to subscribing directly to the Muonics blog.
You can find separate fan pages for [...]]]></description>
			<content:encoded><![CDATA[<p>Muonics now has a presence on <a href="http://www.facebook.com/">Facebook</a>! If you&#8217;re a Facebook user, please consider becoming a fan of the page(s) that interest you. You can show your support for Muonics and our <a href="http://www.muonics.com/Products/">products</a> and subscribe to news and articles as an alternative to subscribing directly to the Muonics blog.</p>
<p>You can find separate fan pages for <a href="http://www.facebook.com/pages/MIB-Smithy/114452305548">MIB Smithy,</a> <a href="http://www.facebook.com/pages/MIB-Smithy-SDK/115217180238">MIB Smithy SDK,</a> and <a href="http://www.facebook.com/pages/MIB-Views/88893213431">MIB Views</a> if you&#8217;d like to receive updates and join the community just for those products, or the <a href="http://www.facebook.com/pages/Muonics-Inc/90082806694">Muonics, Inc.</a> page with a consolidated view of them all and other more general features.</p>
<p>They&#8217;ve just been set up today so there might not be a lot there yet, but we do hope you&#8217;ll join us.</p>
<p>[Editor's Note: In theory, this blog post should also serve as a test to verify the RSS-to-Wall automation is working. :)]</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/147/muonics-on-facebook/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MIB Smithy 4.1.3, SDK 3.4.7, MIB Views 1.4.3 Releases</title>
		<link>http://www.muonics.com/blog/141/mib-smithy-413-sdk-347-mib-views-143-releases/</link>
		<comments>http://www.muonics.com/blog/141/mib-smithy-413-sdk-347-mib-views-143-releases/#comments</comments>
		<pubDate>Thu, 05 Mar 2009 02:16:37 +0000</pubDate>
		<dc:creator>Michael Kirkham</dc:creator>
				<category><![CDATA[Announcements]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=141</guid>
		<description><![CDATA[I guess I jumped the gun a little bit in stating that the previous releases would likely be the last based on the MIB Smithy SDK 3.4 branch, prior to releasing SDK 4.0. The main reason for the previous releases was to fix case 1406 (circular type references cause crash), which was discovered while creating [...]]]></description>
			<content:encoded><![CDATA[<p>I guess I jumped the gun a little bit in stating that the <a href="http://www.muonics.com/blog/131/mib-smithy-412-sdk-346-mib-views-142-releases/">previous releases</a> would likely be the last based on the MIB Smithy SDK 3.4 branch, prior to releasing SDK 4.0. The main reason for the previous releases was to fix case 1406 (circular type references cause crash), which was discovered while <a href="http://www.muonics.com/blog/137/an-ironic-argument-for-using-mib-smithy/">creating regression tests</a> for SDK 4.0. I&#8217;d not yet finished all the regression tests for SYNTAX validation, so it slipped by that the fix for case 1406 also caused some SYNTAX validation steps to be bypassed (shame on me).</p>
<p>The problem was discovered while finishing those regression tests, and this release restores the bypassed validation steps. While I was at it, I thought I&#8217;d back-port fixes for a few other validation bugs also uncovered while preparing the regression tests.</p>
<h3>Changes in these releases:</h3>
<p><strong>1478: Fix for case 1406 caused some syntax checks to be bypassed</strong></p>
<p>The fix for case 1406, which resolved an issue with circular type references, inadvertently blocked base type resolution in some cases, causing some syntax-related checks to be bypassed.</p>
<p><strong>1479: Special cases for ExtUTCTime, ObjectName, and NotificationName</strong></p>
<p>Errors regarding the disallowed importing of ExtUTCTime, ObjectName, and NotificationName (internal to SNMPv2-SMI) are now suppressed when validating the COPS-PR-SPPI or SNMPv2-CONF base modules.</p>
<p><strong>1480: MODULE-IDENTITY required in PIB modules</strong></p>
<p>As with SMIv2, an error message will now be produced for COPS-PR-SPPI (PIB) modules lacking a MODULE-IDENTITY statement.</p>
<p><strong>1481: MAX-ACCESS read-write not allowed for Counter types</strong></p>
<p>SMIv2 requires Counter32 and Counter64 OBJECT-TYPEs to have MAX-ACCESS read-only or accessible-for-notify. The error message indicated this properly, but the actual check was instead allowing read-only or read-write.</p>
<p><strong>1483: Inverted check for SMIv2 INDEX object accessibility</strong></p>
<p>A warning intended to be produced for INDEX OBJECT-TYPEs with MAX-ACCESS other than not-accessible was instead produced for every version except SMIv2. This has been corrected, and it will also now be suppressed for indexes from other tables.<br />
<strong><br />
1484: Duplicate warning message for empty PRODUCT-RELEASE field</strong></p>
<p>Two separate warnings were being produced for an empty PRODUCT-RELEASE field in AGENT-CAPABILITIES validation. The duplicate warning has been removed.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/141/mib-smithy-413-sdk-347-mib-views-143-releases/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>MIB Smithy 4.1.2, SDK 3.4.6, MIB Views 1.4.2 Releases</title>
		<link>http://www.muonics.com/blog/131/mib-smithy-412-sdk-346-mib-views-142-releases/</link>
		<comments>http://www.muonics.com/blog/131/mib-smithy-412-sdk-346-mib-views-142-releases/#comments</comments>
		<pubDate>Sun, 15 Feb 2009 09:58:31 +0000</pubDate>
		<dc:creator>Michael Kirkham</dc:creator>
				<category><![CDATA[Announcements]]></category>
		<category><![CDATA[MIB Smithy]]></category>
		<category><![CDATA[MIB Smithy SDK]]></category>
		<category><![CDATA[MIB Views]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=131</guid>
		<description><![CDATA[MIB Smithy 4.1.2, MIB Smithy SDK 3.4.6, and MIB Views 1.4.2 are now available for download, with essentially the same bug fixes in each. These will most likely be the last releases based on the SDK 3.4 development branch, as we&#8217;re finally getting close to having the SDK 4.0 development branch in a releasable state. [...]]]></description>
			<content:encoded><![CDATA[<p>MIB Smithy 4.1.2, MIB Smithy SDK 3.4.6, and MIB Views 1.4.2 are now available for download, with essentially the same bug fixes in each. These will most likely be the last releases based on the SDK 3.4 development branch, as we&#8217;re finally getting close to having the SDK 4.0 development branch in a releasable state. Since it&#8217;s taken an unusually long time to release 4.0 branch and there are some potential compatibility issues you&#8217;ll need to be aware of, as well as new features affecting all three of these products, I&#8217;ll talk a bit more about it in a post to follow shortly.</p>
<h3>Changes affecting MIB Smithy, MIB Smithy SDK, and MIB Views:</h3>
<p><strong>305: Host ID not matched when interface is disconnected</strong></p>
<p>Windows interfaces that were disconnected were not recognized by the license manager, requiring laptop users to have to swap license keys depending on whether they were on wired or wireless. This is is no longer necessary, as the interfaces are seen whether connected or not.</p>
<p><strong>727: Clarify &#8220;trailing hyphens will be stripped&#8221; error</strong></p>
<p>The parser message produced for identifiers with illegal trailing hyphens was stripping the hyphen in the error message (indicating the corrected identifier was invalid) yet not automatically correcting the error as it should.</p>
<p><strong>1368: Windows: IPv6-only interface Host IDs not available</strong></p>
<p>Windows interfaces configured to support only IPv6 could not previously be used for licenses keys, but can now.</p>
<p><strong>1406: Circular type references cause crash</strong></p>
<p>A type definition derived from another type definition, which is derived from the first type definition, would lead to a crash due to infinite recursion. (Note: TEXTUAL- CONVENTIONs cannot legally derive from other TEXTUAL-CONVENTIONs.)</p>
<h3>Additional changes affecting MIB Smithy SDK:</h3>
<p><strong>312: Changing IPs with SNMPv3 loses auth/priv state</strong></p>
<p>Changing the target IP address of an existing SNMPv3 auth/priv session without also setting the auth/priv password did not sufficiently prepare the session to localize keys with the next request, causing the session to switch to no-auth/no-priv.</p>
<p><strong>1354: Timeout of Tnm-style async requests causes error with future request</strong></p>
<p>Upon timeout of a Tnm-style async request, the callback was being invoked using non- Tnm style arguments, which would typically cause an error, when it should not be invoked at all.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/131/mib-smithy-412-sdk-346-mib-views-142-releases/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MIB Smithy 4.1.1 and SDK 3.4.5 Release</title>
		<link>http://www.muonics.com/blog/128/mib-smithy-411-and-sdk-345-release/</link>
		<comments>http://www.muonics.com/blog/128/mib-smithy-411-and-sdk-345-release/#comments</comments>
		<pubDate>Wed, 12 Nov 2008 20:03:49 +0000</pubDate>
		<dc:creator>Muonics, Inc.</dc:creator>
				<category><![CDATA[Announcements]]></category>
		<category><![CDATA[MIB Smithy]]></category>
		<category><![CDATA[MIB Smithy SDK]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=128</guid>
		<description><![CDATA[MIB Smithy 4.1.1 and MIB Smithy SDK 3.4.5 are now available.  The majority of these changes parallel those of MIB Views 1.4.1, plus a number of bug fixes for the XML-SMI parser uncovered while putting together a full regression test suite for it.
Changes affecting MIB Smithy
482: Updated Tcl/Tk version
The Tcl/Tk base for MIB Views [...]]]></description>
			<content:encoded><![CDATA[<p>MIB Smithy 4.1.1 and MIB Smithy SDK 3.4.5 are now available.  The majority of these changes parallel those of <a href="http://www.muonics.com/Products/MIBViews/">MIB Views</a> 1.4.1, plus a number of bug fixes for the XML-SMI parser uncovered while putting together a full regression test suite for it.</p>
<h3>Changes affecting MIB Smithy</h3>
<p><strong>482: Updated Tcl/Tk version</strong></p>
<p>The Tcl/Tk base for MIB Views was upgraded to 8.4.19.  Among other things, this fixes a crash at startup on later versions of Mac OS X.</p>
<p><strong>606: Application icons for Unix</strong></p>
<p>Full-color application icons have been added to Unix platforms, replacing the old monochrome bitmaps.</p>
<p><strong>1272: TreeView: lexicographic errors can cause loop</strong></p>
<p>In certain circumstances, an agent returning lexicographically incorrect responses to get-next requests could cause branch expansion to loop until a user requested stop, and duplicate branches could be displayed.  More protections against lexicographic errors were added to prevent this.</p>
<h3>Changes affecting MIB Smithy and MIB Smithy SDK</h3>
<p><strong>1130: XMLSMI: some binary strings not formatted correctly</strong></p>
<p>In some cases, using the &#8216;bstring&#8217; integer format attribute would result in the binary value not being quoted/suffixed properly (e.g. &#8216;B&#8217;00001011 instead of &#8216;00001011&#8242;B).</p>
<p><strong>1133: XMLSMI: capability variation parse error</strong></p>
<p>A &#8220;variation element unexpected or unrecognized&#8221; error would occur due to attempting to parse the wrong element when parsing AGENT-CAPABILITIES variations.</p>
<p><strong>1159: XMLSMI: piberrors should be parsed as enum list</strong></p>
<p>The piberrors element was being parsed as a value reference, rather than an enumeration list.  This was fixed previously for the SMI parser and in the schema and database APIs, but not in the XML parser.</p>
<p><strong>1124: XMLSMI: oid child element doesn&#8217;t work in some places</strong></p>
<p>Using the oid element to define a defval or index with an OID value rather than an identifier or with importsfrom to disambiguate imported modules resulted in a parse error.</p>
<p><strong>1137: XMLSMI: wrong size/range using min or max attribute only</strong></p>
<p>When using the size or range element with only the min or max attribute, the other was defaulting to 0 rather than defaulting to the same value.</p>
<p><strong>1138: XMLSMI: syntax tag element&#8217;s &#8216;implicit&#8217; attribute not preserved</strong></p>
<p>The implicit attribute of the syntax tag element was not being checked or preserved by the XML parser.  This would generally only affect SMI base modules represented as XML, not MIB/PIB modules.</p>
<p><strong>1146: XMLSMI: text wrapping issues on load</strong></p>
<p>Newlines were being collapsed in places they shouldn&#8217;t when parsing MixedText fields like description, resulting in (for example) &lt;pre&gt; not being preformatted.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/128/mib-smithy-411-and-sdk-345-release/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MIB Views 1.4.1 Release</title>
		<link>http://www.muonics.com/blog/124/mib-views-141-release/</link>
		<comments>http://www.muonics.com/blog/124/mib-views-141-release/#comments</comments>
		<pubDate>Tue, 11 Nov 2008 21:40:29 +0000</pubDate>
		<dc:creator>Muonics, Inc.</dc:creator>
				<category><![CDATA[Announcements]]></category>
		<category><![CDATA[MIB Views]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=124</guid>
		<description><![CDATA[MIB Views version 1.4.1 is now available with the following changes:
483: Updated Tcl/Tk version
The Tcl/Tk base for MIB Views was upgraded to 8.4.19. Among other things, this fixes a crash at startup on later versions of Mac OS X.
605: Application icons for Unix
Full-color application icons have been added to Unix platforms, replacing the old monochrome [...]]]></description>
			<content:encoded><![CDATA[<p>MIB Views version 1.4.1 is now available with the following changes:</p>
<p><strong>483: Updated Tcl/Tk version</strong></p>
<p>The Tcl/Tk base for MIB Views was upgraded to 8.4.19. Among other things, this fixes a crash at startup on later versions of Mac OS X.</p>
<p><strong>605: Application icons for Unix</strong></p>
<p>Full-color application icons have been added to Unix platforms, replacing the old monochrome bitmaps.</p>
<p><strong>1271: TreeView: lexicographic errors can cause loop</strong></p>
<p>In certain circumstances, an agent returning lexicographically incorrect responses to get-next requests could cause branch expansion to loop until a user requested stop, and duplicate branches could be displayed. More protections against lexicographic errors were added to prevent this.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/124/mib-views-141-release/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Discounts for Educational Use</title>
		<link>http://www.muonics.com/blog/117/discounts-for-educational-use/</link>
		<comments>http://www.muonics.com/blog/117/discounts-for-educational-use/#comments</comments>
		<pubDate>Sat, 13 Sep 2008 13:35:23 +0000</pubDate>
		<dc:creator>Michael Kirkham</dc:creator>
				<category><![CDATA[Announcements]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=117</guid>
		<description><![CDATA[We often have students and staff of educational institutions interested in using our software, either for educational purposes, thesis projects, or general use on the institution&#8217;s network. Did you know we offer discounts to schools and for educational use? Probably not, because it wasn&#8217;t mentioned anywhere, but we&#8217;ve always been happy to provide such discounts [...]]]></description>
			<content:encoded><![CDATA[<p>We often have students and staff of educational institutions interested in using our software, either for educational purposes, thesis projects, or general use on the institution&#8217;s network. Did you know we offer discounts to schools and for educational use? Probably not, because it wasn&#8217;t mentioned anywhere, but we&#8217;ve always been happy to provide such discounts upon request.</p>
<p>Now, we&#8217;re making it more official: if you&#8217;re a student, faculty, or staff of a US educational institution, you can obtain licenses for our software at a 50 to 100% discount (that&#8217;s <strong>free</strong>) depending on qualifications. For details, see <a href="http://www.muonics.com/Products/howtobuy.php#ed">Discounts for Educational Use</a> on the <a href="http://www.muonics.com/Products/howtobuy.php">How to Buy</a> page.</p>
<p>These discounts are available on all of our current products.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/117/discounts-for-educational-use/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
