<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle27
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D"> >>For 1, why not just fail IO with CHECK_CONDITION NOT_READY FORMAT_IN_PROGRESS<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">That is my precise proposal </span>
<span style="font-family:Wingdings;color:#1F497D">J</span><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"> >> For 2, can you just use IoInvalidateDeviceRelations() after the format and allow PNP to re-enumerate the bus and all devices?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">The Storport miniport should confine itself to using Storport APIs. Also, that API is designed for usage by bus drivers such as PCI.SYS, the Windows PCI bus driver. The Windows NVMe Storport miniport is not
a bus driver. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Judy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Speer, Kenny [mailto:Kenny.Speer@netapp.com]
<br>
<b>Sent:</b> Tuesday, January 07, 2014 9:21 PM<br>
<b>To:</b> Judy Brock-SSI; Mayes, Barrett N; Neal Galbo (ngalbo); nvmewin@lists.openfabrics.org<br>
<b>Subject:</b> RE: Handling IO when Format NVM op is in progress<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">I’m not involved in this project yet, but am tracking it so forgive my ignorance.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">It seems to me you have two goals:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in"><span style="color:#1F497D">1.</span><span style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1F497D">
</span><span style="color:#1F497D">Fail IO that is sent during format (which it doesn’t seem that you’ve agreed on the method here) and you can’t control what an application may attempt<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in"><span style="color:#1F497D">2.</span><span style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1F497D">
</span><span style="color:#1F497D">Notify windows that the device geometry has changed<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">For 1, why not just fail IO with CHECK_CONDITION NOT_READY FORMAT_IN_PROGRESS<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">For 2, can you just use IoInvalidateDeviceRelations() after the format and allow PNP to re-enumerate the bus and all devices?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Alternatively, the idea of removing the device while it is inaccessible is not a bad idea and SCSI devices are transient in some scenarios (VSS use cases for instance).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Somebody mentioned READ_CAP_DATA_CHANGED not working in 2012, while off topic, I have not seen that issue in other enviornments.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> <a href="mailto:nvmewin-bounces@lists.openfabrics.org">
nvmewin-bounces@lists.openfabrics.org</a> [<a href="mailto:nvmewin-bounces@lists.openfabrics.org">mailto:nvmewin-bounces@lists.openfabrics.org</a>]
<b>On Behalf Of </b>Judy Brock-SSI<br>
<b>Sent:</b> Tuesday, January 7, 2014 8:48 PM<br>
<b>To:</b> Mayes, Barrett N; Neal Galbo (ngalbo); <a href="mailto:nvmewin@lists.openfabrics.org">
nvmewin@lists.openfabrics.org</a><br>
<b>Subject:</b> Re: [nvmewin] Handling IO when Format NVM op is in progress<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Hi Barrett,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">You make good points below. <o:p>
</o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"> >> If current code isn’t working as intended, it is a bug and should be fixed. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">It is – and it is partially in revisiting the work involved in fixing the current code that the discussion took the turn it did internally
</span><span style="font-family:Wingdings;color:#1F497D">J</span><span style="color:#1F497D">.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"> >> If there is a compelling reason to change the intended behavior, let’s discuss.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I think we’re all in agreement with the goal – to alert the upper layers to potential geometric changes, etc. It’s just a matter of the simplest way to get there. I think it would be good to rediscuss as we’ve
started to do here. We need to fix the code in any case so we may or may not come to the conclusion that the best way to do it is with the current design (as it was intended to work) or not.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Judy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Mayes, Barrett N [<a href="mailto:barrett.n.mayes@intel.com">mailto:barrett.n.mayes@intel.com</a>]
<br>
<b>Sent:</b> Tuesday, January 07, 2014 8:29 PM<br>
<b>To:</b> Judy Brock-SSI; Neal Galbo (ngalbo); <a href="mailto:nvmewin@lists.openfabrics.org">
nvmewin@lists.openfabrics.org</a><br>
<b>Subject:</b> RE: Handling IO when Format NVM op is in progress<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">There is no definition in NVMe spec or SCSI to NVMe translation reference doc that defines namespaces as either static or transient. I would argue they are transient because they can be created, destroyed, resized,
and have their physical properties changed. But I think it is fair to say it is undefined.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">There is no requirement in current specs for Format NVM command to not change the number of namespaces. Given namespace management in 1.0 and 1.1 is vendor specific, it’s conceivable a device might leverage
secure erase to reset namespaces to a default/factory config.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">In NVMe, the adapter/controller is the static object and management commands are directed towards the admin queue that is associated with that controller.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">If current code isn’t working as intended, it is a bug and should be fixed. If there is a compelling reason to change the intended behavior, let’s discuss.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Judy Brock-SSI [<a href="mailto:judy.brock@ssi.samsung.com">mailto:judy.brock@ssi.samsung.com</a>]
<br>
<b>Sent:</b> Tuesday, January 07, 2014 6:42 PM<br>
<b>To:</b> Neal Galbo (ngalbo); Mayes, Barrett N; <a href="mailto:nvmewin@lists.openfabrics.org">
nvmewin@lists.openfabrics.org</a><br>
<b>Subject:</b> RE: Handling IO when Format NVM op is in progress<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> >>In general, LU’s and LUN’s never disappear in SCSI; they are not transient. They are not dynamic. They are static. They either exist or they don’t. They don’t hide, once enumerated/attached/located. Unlike
namespaces.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Like SCSI LUNs, NVMe namespaces are also not transient and (I now submit, having reversed positions
</span><span style="font-family:Wingdings;color:#1F497D">J</span><span style="color:#1F497D">) that they should not hide either.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Format NVM command does not result in a different number of Namespaces then existed before the operation after it is finished. While namespaces can be formatted with different LBA Format than previously, they
are still static in terms of their existence/non-existence.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Additionally , the current code is not achieving what it intended to do since it does not actually hide any LUNS before launching the Format NVM op. That is it does not wait till the existing LUNs are “gone”
(ie until the miniport fails to report them in a subsequent inquiry) before it starts the operation. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Judy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Neal Galbo (ngalbo) [<a href="mailto:ngalbo@micron.com">mailto:ngalbo@micron.com</a>]
<br>
<b>Sent:</b> Tuesday, January 07, 2014 6:27 AM<br>
<b>To:</b> Mayes, Barrett N; Judy Brock-SSI; <a href="mailto:nvmewin@lists.openfabrics.org">
nvmewin@lists.openfabrics.org</a><br>
<b>Subject:</b> RE: Handling IO when Format NVM op is in progress<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">The conditions you describe would never happen with a SCSI device. In general, LU’s and LUN’s never disappear in SCSI; they are not transient. They are not dynamic. They are static. They either exist or they
don’t. They don’t hide, once enumerated/attached/located. Unlike namespaces.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">The media, backing storage or provisioning can change, but the LU would always be available for communication (commands). Other LU’s in the same device would not be affected either – they are independent entities
relative to each other.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">-Neal<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a href="mailto:nvmewin-bounces@lists.openfabrics.org">nvmewin-bounces@lists.openfabrics.org</a> [<a href="mailto:nvmewin-bounces@lists.openfabrics.org">mailto:nvmewin-bounces@lists.openfabrics.org</a>]
<b>On Behalf Of </b>Mayes, Barrett N<br>
<b>Sent:</b> Tuesday, January 07, 2014 12:15 AM<br>
<b>To:</b> Judy Brock-SSI; <a href="mailto:nvmewin@lists.openfabrics.org">nvmewin@lists.openfabrics.org</a><br>
<b>Subject:</b> Re: [nvmewin] Handling IO when Format NVM op is in progress<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">What problem do you want to solve by keeping the block device around during a format and allowing IO through so it can be failed with check condition?
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Namespace not ready can’t generically be translated to SCSI check condition/not ready/Format In Progress. The driver would need to know that a format command is outstanding so it could translate that correctly
(for 1.0-based device support) since the namespace could be not ready for reasons other than a format in progress. If the driver already has to know a format is in progress, it could just fail commands without sending it to the device (so no need for the
new failure code). But if that’s the case, why _<i>not</i>_ hide the LUN until the format is complete. By hiding the LUN and bringing it back when the format is complete, you don’t have to worry about handling IO and you also take care of the re-enumeration
that has to happen when the format is complete (in the case of changing the LBA Format).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">-Barrett<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> <a href="mailto:nvmewin-bounces@lists.openfabrics.org">
nvmewin-bounces@lists.openfabrics.org</a> [<a href="mailto:nvmewin-bounces@lists.openfabrics.org">mailto:nvmewin-bounces@lists.openfabrics.org</a>]
<b>On Behalf Of </b>Judy Brock-SSI<br>
<b>Sent:</b> Monday, January 06, 2014 8:09 PM<br>
<b>To:</b> <a href="mailto:nvmewin@lists.openfabrics.org">nvmewin@lists.openfabrics.org</a><br>
<b>Subject:</b> [nvmewin] Handling IO when Format NVM op is in progress<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">All,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Many months ago, I initiated a thread (see attached) in which I argued that there were some holes in the current implementation of Format NVM ioctl passthru and in which I advocated for, among other things, the addition of logic to make
sure pseudo-SCSI bus re-enumeration had fully taken place in the driver (such that Storport was notified that no “luns” were present) before the actual Format NVM op was launched.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I intuitively understand – and up to this point have unquestioningly agreed with – the basic assumption that the reason the namespaces must be removed/ “luns” disappeared prior to formatting is because “<span style="font-size:10.0pt;color:#1F497D">we
cannot format a namespace while the OS is aware of its presence and could be potentially sending I/O to a stale namespace config (i.e. changing LBA/sector size).</span>” (excerpt from attached thread).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The question has recently arisen in internal discussion however as to whether or not we really have to do this. It was pointed out that SCSI devices (real ones) are capable of receiving IO commands while SCSI format commands are in process.
They will return the following error:<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> SCSI status = Check condition, sense code = NOT READY (0x2), additional sense code = LUN NOT READY (0x4), additional sense code qualifier = FORMAT IN PROGRESS (0x4)<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Why then, instead of removing namespaces/luns, can our Windows driver not return the same error status a real SCSI drive would return in such a situation? One would assume that upper layers of the storage stack have plenty years of experience
in knowing what to do when it sees that error. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As a point of comparison, there is no standard I am aware of which specifies that Storport miniports which support real SCSI devices, if they happen to provide a proprietary pass-thru to allow a SCSI format command to go through to a device,
must cause all LUNS to appear offline prior to formatting,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">One could even argue (and they have!) that these IO commands could even be allowed to go through to the NVMe device itself (as in the real SCSI case); NVMe 1.1 Technical Proposal 005 has defined a new format-in-progress status code that
NVMe firmware will be able to return at some point in the future, current firmware could easily return NAMESPACE_NOT_READY and driver could translate to the above SCSI sense data, etc.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So … here I stand, devil’s advocate hat in hand, hoping to find out:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in">a)<span style="font-size:7.0pt;font-family:"Times New Roman","serif"">
</span> what the “back story” is on how this decision was ultimately made (the attached thread said a lot of discussion took place on the subject)<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in">b)<span style="font-size:7.0pt;font-family:"Times New Roman","serif"">
</span> whether or not the diametrically-opposed alternative I am discussing above was thoroughly considered and if so, why it was rejected<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in">c)<span style="font-size:7.0pt;font-family:"Times New Roman","serif"">
</span> whether the topic bears reconsidering at this point.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks in advance for your collective consideration,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Judy<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>