<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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/"
		>
<channel>
	<title>Comments on: Which IOS release should I use?</title>
	<atom:link href="http://blogs.nil.com/blog/2008/07/04/which-ios-release-should-i-use/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.nil.com/blog/2008/07/04/which-ios-release-should-i-use/</link>
	<description>The Official NIL Blog</description>
	<lastBuildDate>Wed, 07 Jul 2010 12:33:01 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: SeanW</title>
		<link>http://blogs.nil.com/blog/2008/07/04/which-ios-release-should-i-use/comment-page-1/#comment-6</link>
		<dc:creator>SeanW</dc:creator>
		<pubDate>Sat, 12 Jul 2008 15:27:13 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.nil.com/?p=212#comment-6</guid>
		<description>Some questions come to mind after I read this.

- If reliability is the primary concern, why are we using the Internet?  The reliability of the Internet is likely going to be an order of magnitude less than that of a randomly chosen IOS release.  The delta in reliability between this release and the release you choose after intensive investigation is going to be even smaller still.

- Is &quot;well, we haven&#039;t seen any problems with it&quot; a good way of choosing an IOS?  If that&#039;s the litmus test, then why not call TAC for advice (who should be more in tune with known problems) and use the bug tracker to look for defects in the release? Coupled with smoke testing in the lab, this would seem to provide the same level of assurance as the partner&#039;s recommendation, and at zero cost.  The assumption here is that you and your team have the capability to do the work, which should be the case if the architect in question has reached the level of architect in a large financial institution.

Cisco Press published (a long time ago) a book on network reliability calculations which really puts this stuff in perspective.  I wish I still had it so I could mention the title.

Thanks for all the descriptions of the various plans and designations that Cisco has for IOS releases.

Sean</description>
		<content:encoded><![CDATA[<p>Some questions come to mind after I read this.</p>
<p>- If reliability is the primary concern, why are we using the Internet?  The reliability of the Internet is likely going to be an order of magnitude less than that of a randomly chosen IOS release.  The delta in reliability between this release and the release you choose after intensive investigation is going to be even smaller still.</p>
<p>- Is &#8220;well, we haven&#8217;t seen any problems with it&#8221; a good way of choosing an IOS?  If that&#8217;s the litmus test, then why not call TAC for advice (who should be more in tune with known problems) and use the bug tracker to look for defects in the release? Coupled with smoke testing in the lab, this would seem to provide the same level of assurance as the partner&#8217;s recommendation, and at zero cost.  The assumption here is that you and your team have the capability to do the work, which should be the case if the architect in question has reached the level of architect in a large financial institution.</p>
<p>Cisco Press published (a long time ago) a book on network reliability calculations which really puts this stuff in perspective.  I wish I still had it so I could mention the title.</p>
<p>Thanks for all the descriptions of the various plans and designations that Cisco has for IOS releases.</p>
<p>Sean</p>
]]></content:encoded>
	</item>
</channel>
</rss>

