No, 7.1.0.x is not slated to receive a patch for this issue, at present.  I believe 7.0.2.x and 7.2.0.x are slated to receive a fix in a future maintenance release.  I can't speak to why 7.1.0.x was omitted.

Hmm, this is a problem. EOPS for 7.1.0.x has not even been announced yet but you are refusing to patch it ? 

https://support.emc.com/docu45445_Isilon-Product-Availability.pdf

i am rasing a stink about this with my sales team. By refusing to patch the 7.1.0.x version you are effectively saying you not supporting that version ?

While I don't have control over patch releases, I have begun a discussion with a colleague who's in the know to try to find out why 7.1.0.x isn't on the list.  Please stay tuned...

Thank you Bernie

fresh of the press, the latest copy of "EMC Software Release and End of Service Life Notifications".  Does anyone else think it's a problem that Isilon refuses to support their product ?

of course this is a problem. It may be a strategy to force the customers to switch on a more widely spreaded codebranch so they can focus on this.

Since the bugs I report i.e. for 7.0.2 get fixed in other code-branches (7.1.1) I stopped to expect patches / MRs for my codeversions...

from my point of view 7.1.0 is like a stepchild. it's there but it's not really welcome

that is not going to fly, if Isilon releases a version of software they are on the hook to support it until it meets their EOPS date.

What scares me more is seeing six code branches being offered as GA at the same time, with four target codes.

While one might argue that "choice" is good, a bit more focus should help producing better code with present resources...

Support for A.B.c.* can also mean: MINOR(!) update to A.B.d.* if I am not mistaken here.

Just my 2 cents

-- Peter

Let me clarify some of the conversation that has been happening on this thread - I work within the Product Management team on EMC Isilon.

As a direct answer to the original question, you should work with support to request a 7.1.0.x patch for the specific vulnerability. We make calls on doing patches based on a bunch of circumstances (severity of the issue, ability to patch - sometimes a vulnerability cannot be patched, broadness of applicability etc). We fully support 7.1.0.x. For this specific instance, just the timing of the issue was such that it didn't allow us to patch 7.1.0.x releases and there isnt a set date for the patch.

Now going to a more general discussion so that there is clarity around how we think about releases. In Isilon parlance, let's understand what major and minor releases are. If we number a release 'a.b.c.d', for us, a major code family is a.b, and a minor code family is a.b.c. As an example, 7.1 is a major code release family and 7.1.0 or 7.1.1 are minor code release families within the 7.1 major families. Our general policy (and there are always exceptions as I described above) is that when a minor family reaches target code status, it succeeds all prior minor families. We continue to make changes and fixes to the target code branch. In general (and every customer has their set of constraints), we encourage customers to upgrade to the latest target code.

There are two rationales for doing this:

1. To enable customers to take advantage of the fixes we continually make

2. Efficiency from an engineering standpoint

So, when the prior posting says that 7.1.0 is not being fixed, that is an incomplete statement. We continue to make fixes on the 7.1 major release branch and specifically within the 7.1.1 minor code branch now that the latter has attained target code status. Of course, as I described earlier, you _always_ have the ability to request patches on a supported code branch through support.

Do let me know if there are follow on questions or concerns that I can help address. Thank you for being an EMC Isilon customer.

Regards

Ashish Palekar

T: @logicalblock

B: http://logicalblock.wordpress.com