<?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.</title>
	<atom:link href="http://www.muonics.com/blog/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>Thu, 03 Jun 2010 12:05:52 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>MIB Smithy 4.3 and MIB Smithy SDK 4.2 Released</title>
		<link>http://www.muonics.com/blog/221/mib-smithy-4-3-and-mib-smithy-sdk-4-2-released/</link>
		<comments>http://www.muonics.com/blog/221/mib-smithy-4-3-and-mib-smithy-sdk-4-2-released/#comments</comments>
		<pubDate>Thu, 03 Jun 2010 12:05:52 +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[mibsmithy]]></category>
		<category><![CDATA[mibsmithysdk]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[snmp]]></category>
		<category><![CDATA[tcl]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=221</guid>
		<description><![CDATA[MIB Smithy version 4.3 and MIB Smithy SDK version 4.2 are now available for download.
This release of MIB Smithy incorporates enhancements from the MIB Smithy SDK 4.1 and 4.2 releases and the MIB Views 1.6 release to add AES encryption support to SNMPv3 and several other usability enhancements to the SNMP tools built in to [...]]]></description>
			<content:encoded><![CDATA[<p><a href="/Products/MIBSmithy/">MIB Smithy</a> version 4.3 and <a href="/Products/MIBSmithySDK/">MIB Smithy SDK</a> version 4.2 are now available for download.</p>
<p>This release of MIB Smithy incorporates enhancements from the <a href="/blog/211/mib-smithy-sdk-4-1-released-snmpv3-aes-support-added/">MIB Smithy SDK 4.1</a> and 4.2 releases and the <a href="/216/mib-views-1-6-released-snmpv3-aes-support-added/">MIB Views 1.6</a> release to add AES encryption support to SNMPv3 and several other usability enhancements to the SNMP tools built in to the MIB editor such as masking of agent passwords and improved handling of enumerated values for display. In addition, window size and position are saved and restored between sessions and behavior on multiple display setups is improved (similar changes will be made to MIB Views in a coming release).</p>
<p>In addition to these changes from MIB Smithy SDK 4.1 and MIB Views 1.6, the following changes are in this release:</p>
<p><strong>346: Add tdom to build and distribution</strong></p>
<p>Tcl&#8217;s <a href="www.tdom.org">tdom</a> package is now built in to MIB Smithy for XML and XSL processing. Professional Edition users can begin taking advantage of it immediately; additional XML features are in the works for both Professional and Standard.</p>
<p><strong>359: Save/restore window geometry across sessions</strong></p>
<p>MIB Smithy now saves and restores its window location and size between launches, rather than always opening to a fixed size/location relative to the screen size.</p>
<p><strong>2710: wrong # args error importing mosy files</strong></p>
<p>A &#8220;wrong # args&#8221; error could occur when importing mosy .defs files to reconstruct MIB module specifications from when reconstructing table definitions.</p>
<p><strong>2459: Default window size on Windows with multiple displays</strong></p>
<p>The default window size for MIB Smithy, when no previous session size is available, is no longer based relative to the desktop size. Previously this would make the window span multiple displays (particularly ridiculous on a triple display setup).</p>
<p><strong>2714: [smilib format] using both OID and Syntax</strong></p>
<p>You can now specify both an OID and syntax with the value given to the [<a href="/Docs/MIBSmithy/DevGuide/snmplib-format.php">smilib format</a>] command, rather than having to choose one or the other. This way you can specify all three values from a received varbind and get the specific formatting (e.g. via DISPLAY-HINT) if the OID is known, or default formatting for the ASN.1 data type (e.g. hex for OCTET STRING) if it is unknown, with one command.</p>
<div id="_mcePaste" style="overflow: hidden; position: absolute; left: -10000px; top: 85px; width: 1px; height: 1px;">/Docs/MIBSmithy/DevGuide/snmplib-format.php</div>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/221/mib-smithy-4-3-and-mib-smithy-sdk-4-2-released/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MIB Views 1.6 Released: SNMPv3 AES Support Added</title>
		<link>http://www.muonics.com/blog/216/mib-views-1-6-released-snmpv3-aes-support-added/</link>
		<comments>http://www.muonics.com/blog/216/mib-views-1-6-released-snmpv3-aes-support-added/#comments</comments>
		<pubDate>Thu, 03 Jun 2010 03:53:41 +0000</pubDate>
		<dc:creator>Michael Kirkham</dc:creator>
				<category><![CDATA[Announcements]]></category>
		<category><![CDATA[MIB Views]]></category>
		<category><![CDATA[mibviews]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[snmp]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=216</guid>
		<description><![CDATA[MIB Views 1.6 incorporates the following changes from MIB Smithy SDK 4.1, plus other changes to add AES support and several usability enhancements:
266: Add AES support to SNMPv3/USM
SNMPv3 and USM support now includes encryption using AES with 128-bit keys and Cipher Feedback Mode (RFC 3826). The privacy protocol is available under the name &#8220;AES128/CFB&#8221;.
2514: Add [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://www.muonics.com/Products/MIBViews/">MIB Views</a> 1.6 incorporates the following changes from <a href="http://www.muonics.com/Products/MIBSmithySDK/">MIB Smithy SDK</a> 4.1, plus other changes to add AES support and several usability enhancements:</p>
<p><strong>266: Add AES support to SNMPv3/USM</strong></p>
<p>SNMPv3 and USM support now includes encryption using AES with 128-bit keys and Cipher Feedback Mode (RFC 3826). The privacy protocol is available under the name &#8220;AES128/CFB&#8221;.</p>
<p><strong>2514: Add User Name to license message/dialog</strong></p>
<p>The license dialog will now display your user name as the software sees it, to aid in generating user-based license keys.</p>
<p><strong>2490: CBC-DES privacy protocol renamed to DES/CBC</strong></p>
<p>The privacy protocol name &#8220;CBC-DES&#8221; was renamed to &#8220;DES/CBC&#8221; to align with &#8220;AES128/CFB&#8221; and better emphasize the encryption algorithm over the mode.</p>
<p><strong>2515: Assertion failure validating undefined AUGMENTS</strong></p>
<p>The application could terminate unexpectedly during MIB validation with an assertion failure when an AUGMENTS reference could not be resolved.</p>
<p><strong>2550: Case insensitive matching for user-based licenses</strong></p>
<p>User names are no longer case sensitive in the license keys, so a license should work despite differences in capitalization.</p>
<p><strong>391: Table View: show subids for unparseable instance identifiers</strong></p>
<p>The Table View now shows an extra column containing instance subidentifiers for a row if the index values can&#8217;t be parsed (either because of MIB errors or invalid instances), rather than empty index columns.</p>
<p><strong>519: Add sorting to file list in Add/Remove MIBs dialog</strong></p>
<p>The list of files in the Add/Remove MIBs dialog can now be sorted by clicking on the column header.</p>
<p><strong>1302: Mask SNMP auth/priv password fields</strong></p>
<p>The Agent Settings dialog now has a checkbox that can enable or disable masking of SNMPv3 auth/priv passwords in the dialog, which were previously always visible. Masking is now enabled by default.</p>
<p><strong>916: Add event number column to trap watch</strong></p>
<p>The Trap Watch tool has a new column giving a sequential notification number (starting at 1, and reset to 1 when the log is cleared).</p>
<p><strong>895: Limits on timeout/retries in Agent Settings dialog</strong></p>
<p>Entering very large values for timeout and retries in the Agent Settings dialog could result in an error or the calculated total time appearing negative.</p>
<p><strong>2516: Enum labels not shown when defined in the OBJECT-TYPE</strong></p>
<p>Enumerated OBJECT-TYPE values were shown only as an integer if the enumerations were defined directly in the OBJECT-TYPE (rather than through a TEXTUAL-CONVENTION). Both the label and number are now printed regardless of how they&#8217;re defined.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/216/mib-views-1-6-released-snmpv3-aes-support-added/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MIB Smithy SDK 4.1 Released: SNMPv3 AES Support Added</title>
		<link>http://www.muonics.com/blog/211/mib-smithy-sdk-4-1-released-snmpv3-aes-support-added/</link>
		<comments>http://www.muonics.com/blog/211/mib-smithy-sdk-4-1-released-snmpv3-aes-support-added/#comments</comments>
		<pubDate>Thu, 06 May 2010 17:08:22 +0000</pubDate>
		<dc:creator>Michael Kirkham</dc:creator>
				<category><![CDATA[Announcements]]></category>
		<category><![CDATA[MIB Smithy SDK]]></category>
		<category><![CDATA[mibsmithysdk]]></category>
		<category><![CDATA[snmp]]></category>
		<category><![CDATA[tcl]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=211</guid>
		<description><![CDATA[The following changes are available in in MIB Smithy SDK 4.1:
266: Add AES support to SNMPv3/USM
SNMPv3 and USM support now includes encryption using AES with 128-bit keys and Cipher Feedback Mode (RFC 3826). The privacy protocol is available under the name &#8220;AES128/CFB&#8221;.
2514: Add User Name to license message/dialog
The license dialog will now display your user [...]]]></description>
			<content:encoded><![CDATA[<p>The following changes are available in in <a href="http://www.muonics.com/Products/MIBSmithySDK/">MIB Smithy SDK</a> 4.1:</p>
<p><strong>266: Add AES support to SNMPv3/USM</strong></p>
<p>SNMPv3 and USM support now includes encryption using AES with 128-bit keys and Cipher Feedback Mode (<a href="http://www.muonics.com/rfc/rfc3826.php">RFC 3826</a>). The privacy protocol is available under the name &#8220;AES128/CFB&#8221;.</p>
<p><strong>2514: Add User Name to license message/dialog</strong></p>
<p>The license dialog will now display your user name as the software sees it, to aid in generating user-based license keys.</p>
<p><strong>2490: CBC-DES privacy protocol renamed to DES/CBC</strong></p>
<p>The privacy protocol name &#8220;CBC-DES&#8221; was renamed to &#8220;DES/CBC&#8221; to align with &#8220;AES128/CFB&#8221; and better emphasize the encryption algorithm over the mode (particularly as a GUI selection). &#8220;CBC-DES&#8221; remains for backwards compatibility. &#8220;DES&#8221; was previously available as shorthand, but this option was removed since it will automatically match &#8220;DES/CBC&#8221;.</p>
<p><strong>2515: Assertion failure validating undefined AUGMENTS</strong></p>
<p>The SDK could terminate unexpectedly during validation with an assertion failure when an AUGMENTS reference could not be resolved.</p>
<p><strong>2550: Case insensitive matching for user-based licenses</strong></p>
<p>User names are no longer case sensitive in the license keys, so a license should work despite differences in capitalization.</p>
<p><strong>2489: Correction to tnm $session info security results</strong></p>
<p>The Tnm wrapper &#8220;$session info security&#8221; should return a list of supported security levels/protocols. However, it was including md5/des when it shouldn&#8217;t (i.e., in the demo where DES is unsupported), and wasn&#8217;t including sha/des when it should.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/211/mib-smithy-sdk-4-1-released-snmpv3-aes-support-added/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MIB Smithy SDK for Application Developers</title>
		<link>http://www.muonics.com/blog/206/mib-smithy-sdk-for-application-developers/</link>
		<comments>http://www.muonics.com/blog/206/mib-smithy-sdk-for-application-developers/#comments</comments>
		<pubDate>Mon, 08 Mar 2010 20:19:46 +0000</pubDate>
		<dc:creator>Michael Kirkham</dc:creator>
				<category><![CDATA[Announcements]]></category>
		<category><![CDATA[MIB Smithy SDK]]></category>
		<category><![CDATA[snmp]]></category>
		<category><![CDATA[mibsmithysdk]]></category>
		<category><![CDATA[tcl/tk]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=206</guid>
		<description><![CDATA[Wanted to use MIB Smithy SDK to develop Tcl/Tk based SNMP applications you can distribute to your customers but User-Based and Host-Based Licensing made that infeasible? There&#8217;s an option for that now with the MIB Smithy SDK Developer License (or MIB Smithy SDK &#8220;Embedded Edition&#8221;).
MIB Smithy SDK Embedded provides all the same features as a [...]]]></description>
			<content:encoded><![CDATA[<p>Wanted to use <a href="/Products/MIBSmithySDK/">MIB Smithy SDK</a> to develop Tcl/Tk based SNMP applications you can distribute to your customers but User-Based and Host-Based Licensing made that infeasible? There&#8217;s an option for that now with the MIB Smithy SDK Developer License (or MIB Smithy SDK &#8220;Embedded Edition&#8221;).</p>
<p>MIB Smithy SDK Embedded provides all the same <a href="/Products/MIBSmithySDK/#features">features</a> as a regular license for MIB Smithy SDK, but is a special build and Developer License Agreement. Each Developer License grants a single developer a royalty-free license to embed the SDK and distribute it as an integral component of the developer&#8217;s applications, and includes a Single User or Single Host License for the normal SDK to use for development and internal use.</p>
<p>When you <a href="/Products/#pid100202">purchase online</a> or by purchase order, a license and download permissions for both will be added to your account. The Developer License Redistributables available from the <a href="/Downloads/">Downloads</a> page contains only the files necessary for redistribution so you don&#8217;t have the overhead of downloading MIB modules and documentation bundled with the SDK twice.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/206/mib-smithy-sdk-for-application-developers/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>User-Based Licensing Now Online</title>
		<link>http://www.muonics.com/blog/200/user-based-licensing-now-online/</link>
		<comments>http://www.muonics.com/blog/200/user-based-licensing-now-online/#comments</comments>
		<pubDate>Mon, 08 Mar 2010 19:49:58 +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>
		<category><![CDATA[mibsmithy]]></category>
		<category><![CDATA[mibsmithysdk]]></category>
		<category><![CDATA[mibviews]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=200</guid>
		<description><![CDATA[As previously (but quietly) announced, User-Based Licensing was introduced in MIB Smithy SDK 4.0, and subsequently in MIB Smithy 4.2 and MIB Views 1.5. Earlier versions of these products supported only Host-Based Licensing.
Host-Based Licensing permits any user to use the software on a single specified computer, provided it&#8217;s used by only one person at a [...]]]></description>
			<content:encoded><![CDATA[<p>As <a href="/blog/177/mib-smithy-sdk-4-0-released/">previously (but quietly) announced</a>, User-Based Licensing was introduced in <a href="/Products/MIBSmithySDK/">MIB Smithy SDK</a> 4.0, and subsequently in <a href="/Products/MIBSmithy/">MIB Smithy</a> 4.2 and <a href="/Products/MIBViews/">MIB Views</a> 1.5. Earlier versions of these products supported only Host-Based Licensing.</p>
<p>Host-Based Licensing permits any user to use the software on a single specified computer, provided it&#8217;s used by only one person at a time. This scheme is useful in multi-user environments where use is less frequent, as licenses can be shared in this manner, with the trade-off being limits on how often the license can be transferred to another computer.</p>
<p>User-Based Licensing, on the other hand, permits a single specified user to use the software on any computer, provided it&#8217;s used on only one computer at a time. This scheme is useful in environments where a user uses multiple computers or changes computers frequently (such as on a desktop and laptop), with the trade-off being that each user needs their own license.</p>
<p>The User-Based Licensing feature was implemented in these releases, but until now the systems on the web site weren&#8217;t set up to handle it. From now on, when initially configuring their license key, new customers can choose whether to designate it as a User-Based or Host-Based License, and whether to use the old license key format (compatible with all versions) or new license key format (compatible with these versions and later) for Host-Based Licenses. The new format includes a couple of freely editable plaintext fields (usually filled in with the product name and serial number) that make it easier for customers with multiple license keys to distinguish them from one another, and gets rid of those BEGIN/END lines people often don&#8217;t realize are required parts of the old key format.</p>
<p>Customers who initially purchased their license prior to December 31, 2010 (through end of this year) who are using Host-Based Licenses can elect to permanently convert their keys to User-Based Licenses, provided their support is current, and can now do so online by following link at the bottom of the License Detail page, accessible via serial number link at <a href="/User/licenses.php">Manage Licenses</a>. This future cutoff date was chosen to allow for transition time, as some current MIB Smithy SDK users may want to switch to User-Based Licenses, and may wish to acquire additional licenses, but need time to port their scripts or hardware from SDK <a href="/167/a-sneek-peek-at-mib-smithy-sdk-4-0/">3.x to 4.x API and Platform Changes</a>.</p>
<p>After conversion to a User-Based License, you&#8217;ll be permitted to continue to use your old Host-Based license key as necessary for migration and script porting, but it may no longer be shared (it must be used only by the newly assigned user) and no further Host ID transfers will be permitted.</p>
<p>The new format looks approximately like this, with the two fields in ||&#8217;s editable in any way that helps you keep track of your licenses (except by inserting | characters):</p>
<pre>|MIB Smithy Professional - Windows|XXXXXX-XXXXXX-XXXXXX|dcPkYQW
hJeSOYzDPDYvWprYQoaQd9zsoDihw25qLweMriJBDksDQbRuwbHfdprYfIKQdQQ
YjY42AzazjkeNn30s8ygPiOOChK2UveIM4BWNmF2Vg=lyma9fS60Ah9k0JZ02ja</pre>
<p>If you&#8217;d like to convert your license to the new format, but stay with Host-Based Licensing, please contact support. As with conversion to User-Based, your support must be current (it&#8217;s only supported by the above versions of the software).</p>
<p>P.S. No, that&#8217;s not a valid license key, so don&#8217;t even try. :)</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/200/user-based-licensing-now-online/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MIB Smithy 4.2 and MIB Views 1.5 Released</title>
		<link>http://www.muonics.com/blog/197/mib-smithy-4-2-and-mib-views-1-5-released/</link>
		<comments>http://www.muonics.com/blog/197/mib-smithy-4-2-and-mib-views-1-5-released/#comments</comments>
		<pubDate>Sat, 06 Mar 2010 02:09:27 +0000</pubDate>
		<dc:creator>Michael Kirkham</dc:creator>
				<category><![CDATA[Announcements]]></category>
		<category><![CDATA[MIB Smithy]]></category>
		<category><![CDATA[MIB Views]]></category>
		<category><![CDATA[ipv6]]></category>
		<category><![CDATA[mibsmithy]]></category>
		<category><![CDATA[mibviews]]></category>
		<category><![CDATA[snmp]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=197</guid>
		<description><![CDATA[MIB Smithy 4.2 and MIB Views 1.5 are now available. These releases are based on MIB Smithy SDK 4.0, adding IPv6 support, Linux x86_64 support, a username-based licensing option, and many MIB compiler improvements (a full list can be found in the MIB Smithy SDK 4.0 Release Announcement, which also describes changes to supported platforms [...]]]></description>
			<content:encoded><![CDATA[<p><a href="/Products/MIBSmithy/">MIB Smithy</a> 4.2 and <a href="/Products/MIBViews/">MIB Views</a> 1.5 are now available. These releases are based on <a href="/Products/MIBSmithySDK/">MIB Smithy SDK</a> 4.0, adding IPv6 support, Linux x86_64 support, a username-based licensing option, and many MIB compiler improvements (a full list can be found in the <a href="/blog/177/mib-smithy-sdk-4-0-released/">MIB Smithy SDK 4.0 Release Announcement</a>, which also describes changes to supported platforms that apply to these releases as well).</p>
<p>The format used specify OCTET STRING values in hex in the SNMP Query Tool and Agent Settings dialog has changed, in keeping with SDK 4.0&#8217;s changes to binary data handling. Instead of prefixing the value with 0x, as in <code>0x:12:ab:cd</code>, you surround the value in single quotes, as in <code>'12:ab:cd'</code>. However, you can now suppress conversion from hex, treating the value as a literal string (with quotes) by surrounding the value in another pair of single quotes, as in <code>''12:ab:cd''</code>. Essentially, any string value with surrounding single quotes will have one set of quotes stripped off; if, after stripping, the value looks like colon-delimited hex (without quotes), hex conversion will occur.</p>
<p>Although these releases don&#8217;t do much beyond what SDK 4.0 brings, it&#8217;s still a significant milestone. Now that MIB Smithy and MIB Views are up to the new SDK version, the holds on new features are lifted, so I can get back to tackling my sizable wish list for these products. First, though, I&#8217;ll be working on getting the web site updated to support generating the new username-based license keys and providing access to the Linux x86_64 platform (x86_64 won&#8217;t be treated as a unique platform from x86 as far as purchasing and license keys are concerned, but it is a different build/distribution, and the systems aren&#8217;t set up yet to handle two different files for a single platform+version).</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/197/mib-smithy-4-2-and-mib-views-1-5-released/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MIB Smithy SDK 4.0.2 Released</title>
		<link>http://www.muonics.com/blog/193/mib-smithy-sdk-4-0-2-released/</link>
		<comments>http://www.muonics.com/blog/193/mib-smithy-sdk-4-0-2-released/#comments</comments>
		<pubDate>Thu, 04 Mar 2010 06:59:28 +0000</pubDate>
		<dc:creator>Michael Kirkham</dc:creator>
				<category><![CDATA[Announcements]]></category>
		<category><![CDATA[MIB Smithy SDK]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=193</guid>
		<description><![CDATA[This release fixes a minor bug that was introduced in 4.0 that I discovered while getting MIB Smithy ported to the 4.0 SDK, in an API primarily used by MIB Smithy to list the topmost nodes in a module within the Project Tree. It also has one minor new feature to simplify the porting of [...]]]></description>
			<content:encoded><![CDATA[<p>This release fixes a minor bug that was introduced in 4.0 that I discovered while getting <a href="/Products/MIBSmithy/">MIB Smithy</a> ported to the 4.0 SDK, in an API primarily used by MIB Smithy to list the topmost nodes in a module within the Project Tree. It also has one minor new feature to simplify the porting of MIB Smithy and <a href="/Products/MIBViews/">MIB Views</a>. MIB Smithy 4.2 and MIB Views 1.5, based on SDK 4.0, will be available as soon as a few remaining build issues are resolved.</p>
<p>Changes in this release:</p>
<p><strong>2453: smilib get -rootnodes returning no results</strong></p>
<p>The smilib get -rootnodes property for modules was inadvertently broken in SDK 4.0&#8217;s rearchitecture such that orphaned records (those with missing or undefined dependencies) were no longer returned in the result.</p>
<p><strong>2458: Add smilib get -format option for OBJECT-TYPEs</strong></p>
<p>smilib get -format can now be used on OBJECT-TYPEs to return the DISPLAY-HINT for the TEXTUAL-CONVENTION referenced by the OBJECT-TYPE&#8217;s SYNTAX. This saves the step of having to first look up the SYNTAX.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/193/mib-smithy-sdk-4-0-2-released/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MIB Smithy SDK 4.0.1 Released</title>
		<link>http://www.muonics.com/blog/189/mib-smithy-sdk-4-0-1-released/</link>
		<comments>http://www.muonics.com/blog/189/mib-smithy-sdk-4-0-1-released/#comments</comments>
		<pubDate>Thu, 25 Feb 2010 10:02:16 +0000</pubDate>
		<dc:creator>Michael Kirkham</dc:creator>
				<category><![CDATA[Announcements]]></category>
		<category><![CDATA[MIB Smithy SDK]]></category>
		<category><![CDATA[mibsmithysdk]]></category>
		<category><![CDATA[snmp]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=189</guid>
		<description><![CDATA[This release fixes a couple of assertion failures that could occur in some of the new validation rules introduced in the 4.0 release and some licensing issues with Windows, and introduces a new edition of the SDK available for general release soon.
2419: New SDK edition for application developers
A new SDK edition (the MIB Smithy SDK [...]]]></description>
			<content:encoded><![CDATA[<p>This release fixes a couple of assertion failures that could occur in some of the new validation rules introduced <a href="http://www.muonics.com/blog/177/mib-smithy-sdk-4-0-released/">in the 4.0 release</a> and some licensing issues with Windows, and introduces a new edition of the SDK available for general release soon.</p>
<p><strong>2419: New SDK edition for application developers</strong></p>
<p>A new SDK edition (the MIB Smithy SDK Developer License) was implemented to accommodate developers who which to use the SDK to develop distributable applications.</p>
<p><strong>2412: Error upon redisplaying license dialog</strong></p>
<p>Upon adding a license key to the license dialog that was not accepted, the dialog should be redisplayed. A bug was introduced in 4.0 that cause an &#8220;unknown command name&#8221; error instead.</p>
<p><strong>2421: Demo license key crashes on Windows</strong></p>
<p>An issue was identified in the new licensing engine for 4.0 that could cause the SDK to crash when given an evaluation license key on Windows.</p>
<p><strong>2282: Assertion failure checking for duplicate members</strong></p>
<p>The SDK could abort during validation with an assertion failure when checking for duplicate members (such as OBJECTS in OBJECT-GROUP) if multiple members were undefined.</p>
<p><strong>2407: Assertion failure validating orphaned read-write OBJECT-TYPE</strong></p>
<p>The SDK could abort during validation with an assertion failure when checking for a mix of read-write and read-create columnar objects when the OBJECT-TYPE&#8217;s OID was not fully defined or known.</p>
<p><strong>2409: License key location on Windows Vista/Windows 7</strong></p>
<p>On Windows Vista and Windows 7, the license dialog could fail write license keys to the correct location due to changes in structure and permissions of %ALLUSERSPROFILE%. The default location is now based on %APPDATA%, which is user-specific and more appropriate for user-based licenses.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/189/mib-smithy-sdk-4-0-1-released/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<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>1</slash:comments>
		</item>
		<item>
		<title>One Last Case Before MIB Smithy SDK 4.0</title>
		<link>http://www.muonics.com/blog/172/one-last-case-before-mib-smithy-sdk-4-0/</link>
		<comments>http://www.muonics.com/blog/172/one-last-case-before-mib-smithy-sdk-4-0/#comments</comments>
		<pubDate>Wed, 27 Jan 2010 10:47:06 +0000</pubDate>
		<dc:creator>Michael Kirkham</dc:creator>
				<category><![CDATA[MIB Smithy SDK]]></category>
		<category><![CDATA[mibsmithysdk]]></category>
		<category><![CDATA[snmp]]></category>
		<category><![CDATA[tcl]]></category>

		<guid isPermaLink="false">http://www.muonics.com/blog/?p=172</guid>
		<description><![CDATA[I&#8217;m happy to report that I&#8217;m working on the last open case assigned for the MIB Smithy SDK 4.0 release. This last case is for a certain set of new MIB and PIB validation rules that I think should be added, although it&#8217;s in an area the standards are silent on (like so many other [...]]]></description>
			<content:encoded><![CDATA[<p>I&#8217;m happy to report that I&#8217;m working on the last open case assigned for the <a href="http://www.muonics.com/Products/MIBSmithySDK/">MIB Smithy SDK</a> 4.0 release. This last case is for a certain set of new MIB and PIB validation rules that I think should be added, although it&#8217;s in an area the standards are silent on (like so many other areas of the SMI).</p>
<p>The other good news is on the platform front: I acquired a replacement for the dead Solaris box and spent the last couple days getting it set up with Solaris 10 (SPARC) plus the necessary build tools and libraries, and spent some time with Linux x86_64 while I mulled over this final case. After a few minor tweaks to build rules and such, the 4.0 code is now building and passing all 2143 regression tests on all targeted platforms (<em>including</em> Linux x86_64, so I can now say with certainty that it will be supported going forward).</p>
<p>It&#8217;s a little tricky to implement and write tests for the new validation rules I have planned for in the final case, and likely rare to come across. I&#8217;m not entirely settled on the approach I&#8217;ve taken (hence the mulling), so I may punt it to the next release if it would otherwise push the release beyond Monday.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.muonics.com/blog/172/one-last-case-before-mib-smithy-sdk-4-0/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
