Subject: Re: [storm] MPA Draft - Review

From: <[email-masked]>
Date: Sun, 3 Apr 2011 10:34:35 -0400

Looks good to me.

Thanks,
--David

From: arkady kanevsky [mailto:[email-masked]]
Sent: Saturday, April 02, 2011 9:36 PM
To: Hemal Shah
Cc: Black, David; [email-masked]
Subject: Re: [storm] MPA Draft - Review

All,
updated version 04 is attached.

Hemal,
Thanks for catching it.
I had fixed the first issue. I had added reference to FPDU in the FULPDU definition for the second.

David,
Please, check to see that you comments are addressed.

Steve and Robert,
please, check that you comment is fixed correctly.

Once I get positive feedback from all of you, I will submit the version.

Thanks,
Arkady
On Thu, Mar 31, 2011 at 2:43 PM, Hemal Shah <[email-masked]<mailto:[email-masked]>> wrote:
I have some comments on -03 draft:

 1.  In section 10, it is written that "Enhanced MPA Initiator and Responder:  If a responder receives an enhanced MPA message, it MUST respond with an unenhanced MPA message." I think it should be written that the responder must respond with an enhanced MPA message. It appears like a typo to me.
 2.  I find the use of FULPDU confusing in this draft. RFC5044 does not define term FULPDU. RFC5044 uses term FPDU to refer to Framed Protocol Data Unit. I suggest that we use term FPDU instead of FULPDU in the draft.

Hemal

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, March 31, 2011 7:48 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [storm] MPA Draft - Review
Importance: High

The -03 version of the MPA draft has addressed all of the issues from my review, and .  Unfortunately, I need some minor edits for clarity before I can send this on to our AD with a publication request.  Would the authors please submit a -04 version with the following two changes quickly.

Section 9 (end)

OLD

   The peer-to-peer negotiation for the RTR message follows the
   following order:

   Initiator -->: Sets Control Flags it is capable to send for RTR

   Responder <--: Sets Control Flags it is capable to receive for RTR

   Initiator -->: The first message send MUST be a negotiated RTR

NEW

   The peer-to-peer negotiation for the RTR message follows the
   following order:

   Initiator -->: Sets Control Flags to indicate Initiator-supported forms of RTR

   Responder <--: Sets Control Flags to indicate Responder-supported forms of RTR

   Initiator -->: If at least one form of RTR is supported by both Initiator and
        Responder, then the first message sent MUST be an RTR using a form supported
        by both the Initiator and Responder.

Section 10

OLD
      In
      this case initiator CAN attempt to establish RDMA connection using
      unenhanced MPA protocol as defined in [RFC5044] and let ULP deal
      with ORD and IRD, and peer-to-peer negotiations.

NEW

      In
      this case initiator MAY attempt to establish RDMA connection using
------------------------->^^^
      unenhanced MPA protocol as defined in [RFC5044] if this protocol is
        compatible with the application, and let ULP deal with ORD and IRD,
      and peer-to-peer negotiations.

Ordinarily, I'd write an RFC Editor Note for small changes like these, but they're sufficiently critical to interoperability that I'd prefer to have a new draft version that contains them.

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Wednesday, December 22, 2010 9:26 PM
> To: [email-masked]<mailto:[email-masked]>
> Cc: Black, David
> Subject: MPA Draft - Review
>
> WG Last Call on this draft has run its course:
>
>                  Enhanced RDMA Connection Establishment
>                   draft-ietf-storm-mpa-peer-connect-02
>
> I've done my review as a WG chair (and the person who will be shepherding this draft to the ADs and
> IESG):
>
> - This draft is on the right track, but has open issues.
> - Another version of the draft will be needed.
>
> Also, it would be greatly appreciated if a few people other than the authors could take a look at
> this draft.  We have a very good author team on this draft, whose expertise is beyond doubt, but
> more eyes on this draft would help.
>
> [1] My primary concern is that Section 9 on interoperability is inadequate:
>
>    An initiator SHOULD NOT use the Enhanced DDP Connection Establishment
>    formats or function codes when no enhanced functionality is desired.
>
>    A responder SHOULD continue to accept the unenhanced connection
>    requests.
>
> The good news is that the first sentence is ok.
> The bad news is that the second sentence has significant problems:
>        - It uses SHOULD instead of MUST.
>        - It doesn't lay out behavior for initiator and responder
>                Revision mixes.
> IETF interoperability requirements are usually expressed with MUST, including backwards
> compatibility.  If interop with unenhanced implementations is only a SHOULD, that will need a
> convincing explanation.
>
> There are 3 Initiator/Responder cases that need attention (New/Old, Old/New and New/New).  I think
> they lead to roughly the following:
>
> New/Old:
> - Explain error or failure that the New Initiator will see because the Old responder
>        doesn't support Revision 2 of the MPA protocol.
> - Explain what the Initiator does when it sees that error or failure.  The
>        easiest approach is to always retry with Revision 1, but that won't work
>        if the Initiator has to send an RTR (that's the "convincing explanation"
>        for why backwards compatibility is not always possible).  The result
>        might be two requirements:
>        - If the Initiator has data to send, it MUST retry with Revision 1.
>        - If the Initiator has no data to send, and hence has to send an RTR,
>                the connection setup fails, the TCP connection closes and that
>                failure MUST to be reported to the application.
>
> Old/New:
> - If a responder receives a Revision 1 message, it MUST respond with a Revision 1 message.
>
> New/New:
> - If a responder receives a Revision 2 message, it MUST respond with a Revision 2 message.
>
> I found a few other concerns:
>
> [B]In Section 7, we need to get the listing of all the SCTP function codes into one place.  Either
> repeat the definitions of codes 1-4 from RFC 5043, or create an IANA registry in Section 10 and list
> all 7 codes as its initial contents.
>
> [C] In Section 8, what happens if the responder sends an IRD or ORD value that's different from the
> corresponding initiator value?  Is the responder allowed to increase the value that was sent?  An
> important case to cover is that the initiator sends a valid value (e.g., 0x2000) but the responder
> returns the 0x3FFF value indicating that negotiation is not supported.  Also, what is the behavior
> of an IRD or ORD that is set to 0x0000?
>
> [D] In contrast, the Section 8 discussion of Control Flag functionality is in better shape.  It
> would be helpful to add a sentence or two indicating when the RTR occurs (Request ->, <- Reply, RTR
> ->), even though that is discussed earlier in the draft.  Also, it's necessary to state whether
> negotiation of RTR functionality commits the Initiator to using an RTR (e.g., suppose the initiator
> negotiates control flags to allow an RTR and instead sends an FULPDU with payload data after
> receiving the Reply - is that ok or is it an error?).
>
> [E] Nit: In the definition of Control Flag A: ULPDU -> FULPDU
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953<tel:%2B1%20%28508%29%20293-7953>             FAX: +1 (508) 293-7786<tel:%2B1%20%28508%29%20293-7786>
> [email-masked]<mailto:[email-masked]>        Mobile: +1 (978) 394-7754<tel:%2B1%20%28978%29%20394-7754>
> ----------------------------------------------------

_______________________________________________
storm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/storm

_______________________________________________
storm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/storm

--
Cheers,
Arkady Kanevsky

---

From: arkady kanevsky <[email-masked]>
Date: Sat, 2 Apr 2011 21:35:49 -0400

All,

Hemal,
Thanks for catching it.
I had fixed the first issue. I had added reference to FPDU in the FULPDU
definition for the second.

David,

Steve and Robert,

Thanks,
Arkady

On Thu, Mar 31, 2011 at 2:43 PM, Hemal Shah <[email-masked]> wrote:

>    1. In section 10, it is written that "Enhanced MPA Initiator and
>    Responder:  If a responder receives an enhanced MPA message, it MUST respond
>    with an unenhanced MPA message." I think it should be written that the
>    responder must respond with an enhanced MPA message. It appears like a typo
>    to me.
>    2. I find the use of FULPDU confusing in this draft. RFC5044 does not
>    define term FULPDU. RFC5044 uses term FPDU to refer to Framed Protocol Data
>    Unit. I suggest that we use term FPDU instead of FULPDU in the draft.
>
>
> Hemal
>
> From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of [email-masked]
> To: [email-masked]
> The -03 version of the MPA draft has addressed all of the issues from my
> review, and .  Unfortunately, I need some minor edits for clarity before I
> can send this on to our AD with a publication request.  Would the authors
> please submit a -04 version with the following two changes quickly.
>
> Section 9 (end)
>
> OLD
>
> Ordinarily, I'd write an RFC Editor Note for small changes like these, but
> they're sufficiently critical to interoperability that I'd prefer to have a
> new draft version that contains them.
>
> Thanks,
> --David
>
>
> > To: [email-masked]
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > [email-masked]        Mobile: +1 (978) 394-7754
> [email-masked]
> [email-masked]

-- 
Cheers,
Arkady Kanevsky

---

From: Steve Wise <[email-masked]>
Date: Sun, 03 Apr 2011 16:36:42 -0500

Hey Arkady,

It does seem like you did the section 9 changes Bob and I requested:

----
   Change the IRD definition on the request from "In request: the 
Initiator requested responder IRD for the
   connection." to "In request: the Initiator initial IRD setting for 
the connection."
----

Thanks,

Steve.

On 4/2/2011 8:35 PM, arkady kanevsky wrote:
>        1. In section 10, it is written that "Enhanced MPA Initiator
>           and Responder:  If a responder receives an enhanced MPA
>           message, it MUST respond with an unenhanced MPA message." I
>           think it should be written that the responder must respond
>           with an enhanced MPA message. It appears like a typo to me.
>        2. I find the use of FULPDU confusing in this draft. RFC5044
>           does not define term FULPDU. RFC5044 uses term FPDU to refer
>           to Framed Protocol Data Unit. I suggest that we use term
>           FPDU instead of FULPDU in the draft.
>
>     Hemal
>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] On Behalf Of [email-masked]
>     <mailto:[email-masked]>
>     To: [email-masked] <mailto:[email-masked]>
>     The -03 version of the MPA draft has addressed all of the issues
>     from my review, and .  Unfortunately, I need some minor edits for
>     clarity before I can send this on to our AD with a publication
>     request.  Would the authors please submit a -04 version with the
>     following two changes quickly.
>     Section 9 (end)
>     OLD
>     Ordinarily, I'd write an RFC Editor Note for small changes like
>     these, but they're sufficiently critical to interoperability that
>     I'd prefer to have a new draft version that contains them.
>     Thanks,
>     --David
>     > To: [email-masked] <mailto:[email-masked]>
>     > Cc: Black, David
>     > +1 (508) 293-7953 <tel:%2B1%20%28508%29%20293-7953>            
>     FAX: +1 (508) 293-7786 <tel:%2B1%20%28508%29%20293-7786>
>     > [email-masked] <mailto:[email-masked]>        Mobile:
>     +1 (978) 394-7754 <tel:%2B1%20%28978%29%20394-7754>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Steve Wise <[email-masked]>
Date: Sun, 03 Apr 2011 19:48:51 -0500

> It does seem like you did the section 9 changes Bob and I requested:

To clarify: please modify section 9 as I've shown below..

>>           does not define term FULPDU. RFC5044 uses term FPDU to
>>           refer to Framed Protocol Data Unit. I suggest that we use
>>           term FPDU instead of FULPDU in the draft.
>>
>>     Hemal

---

From: arkady kanevsky <[email-masked]>
Date: Mon, 4 Apr 2011 19:26:00 -0400

Steve and Bob,
I changed it to
"In request: the Initiator desired responder IRD
for the connection." as you asked.
I can change it to "initial" instead of "desired".
Arkady

On Sun, Apr 3, 2011 at 5:36 PM, Steve Wise <[email-masked]>wrote:

>   Change the IRD definition on the request from "In request: the Initiator
> requested responder IRD for the
>   connection." to "In request: the Initiator initial IRD setting for the
> connection."
> ----
>
> Thanks,
>
> Steve.
>
>
> storm mailing [email-masked]://www.ietf.org/mailman/listinfo/storm
>
>
>

-- 
Cheers,
Arkady Kanevsky

---

From: Steve Wise <[email-masked]>
Date: Mon, 04 Apr 2011 20:41:15 -0500

The key word to remove here is "responder".  The IRD in the MPA start 
request is the initiators desired IRD _of the initiator_.  Not the 
initiators desired _responder_ IRD.

If you want to change "desiired" to "initial" thats ok with me.  But the 
key is to get rid of the word "responder" in that sentence.

Steve.

On 4/4/2011 6:26 PM, arkady kanevsky wrote:
> On Sun, Apr 3, 2011 at 5:36 PM, Steve Wise 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hey Arkady,
>
>       connection." to "In request: the Initiator initial IRD setting
>     for the connection."
>     ----
>
>     Thanks,
>
>     Steve.
>
>
>>            1. In section 10, it is written that "Enhanced MPA
>>               Initiator and Responder:  If a responder receives an
>>               enhanced MPA message, it MUST respond with an
>>               unenhanced MPA message." I think it should be written
>>               that the responder must respond with an enhanced MPA
>>               message. It appears like a typo to me.
>>            2. I find the use of FULPDU confusing in this draft.
>>               RFC5044 does not define term FULPDU. RFC5044 uses term
>>               FPDU to refer to Framed Protocol Data Unit. I suggest
>>               that we use term FPDU instead of FULPDU in the draft.
>>
>>         Hemal
>>         [mailto:[email-masked]] On Behalf Of
>>         [email-masked] <mailto:[email-masked]>
>>         The -03 version of the MPA draft has addressed all of the
>>         issues from my review, and .  Unfortunately, I need some
>>         minor edits for clarity before I can send this on to our AD
>>         with a publication request.  Would the authors please submit
>>         a -04 version with the following two changes quickly.
>>         Section 9 (end)
>>         OLD
>>         Ordinarily, I'd write an RFC Editor Note for small changes
>>         like these, but they're sufficiently critical to
>>         interoperability that I'd prefer to have a new draft version
>>         that contains them.
>>         Thanks,
>>         --David
>>         > repeat the definitions of codes 1-4 from RFC 5043, or
>>         create an IANA registry in Section 10 and list
>>         > [C] In Section 8, what happens if the responder sends an
>>         IRD or ORD value that's different from the
>>         > would be helpful to add a sentence or two indicating when
>>         the RTR occurs (Request ->, <- Reply, RTR
>>         > negotiation of RTR functionality commits the Initiator to
>>         using an RTR (e.g., suppose the initiator
>>         > +1 (508) 293-7953
>>         <tel:%2B1%20%28508%29%20293-7953>             FAX: +1 (508)
>>         293-7786 <tel:%2B1%20%28508%29%20293-7786>
>>         > [email-masked] <mailto:[email-masked]>       
>>         Mobile: +1 (978) 394-7754 <tel:%2B1%20%28978%29%20394-7754>

---

From: "Sharp, Robert O" <[email-masked]>
Date: Tue, 5 Apr 2011 07:37:51 -0700

Looks good to me as well.

Thanks,
Bob

From: Steve Wise [mailto:[email-masked]]
Sent: Monday, April 04, 2011 9:19 PM
To: arkady kanevsky
Cc: Sharp, Robert O; [email-masked]
Subject: Re: [storm] MPA Draft - Review

Looks good.

Bob Sharp should ACK this too though.

Thanks,

Steve.

On 4/4/2011 8:50 PM, arkady kanevsky wrote:
Got it. Thanks Steve.
How about now?
Arkady
On Mon, Apr 4, 2011 at 9:41 PM, Steve Wise <[email-masked]<mailto:[email-masked]>> wrote:
The key word to remove here is "responder".  The IRD in the MPA start request is the initiators desired IRD _of the initiator_.  Not the initiators desired _responder_ IRD.

If you want to change "desiired" to "initial" thats ok with me.  But the key is to get rid of the word "responder" in that sentence.

Steve.

On Sun, Apr 3, 2011 at 5:36 PM, Steve Wise <[email-masked]<mailto:[email-masked]>> wrote:

Hey Arkady,

----

  Change the IRD definition on the request from "In request: the Initiator requested responder IRD for the
  connection." to "In request: the Initiator initial IRD setting for the connection."
----

Thanks,

Steve.

Hemal,
Thanks for catching it.

David,

Steve and Robert,

Thanks,
Arkady

Hemal

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, March 31, 2011 7:48 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [storm] MPA Draft - Review
Importance: High

Section 9 (end)

OLD

NEW

Section 10

OLD
      In

NEW

      In

Thanks,
--David

--
Cheers,
Arkady Kanevsky

storm mailing list

--
Cheers,
Arkady Kanevsky

--
Cheers,
Arkady Kanevsky

---

From: arkady kanevsky <[email-masked]>
Date: Mon, 4 Apr 2011 19:34:19 -0400

Steve and Bob,
Here is updated draft.
Thanks,
Arkady

On Mon, Apr 4, 2011 at 7:26 PM, arkady kanevsky
<[email-masked]>wrote:

>>> Ordinarily, I'd write an RFC Editor Note for small changes like these,
>>> but they're sufficiently critical to interoperability that I'd prefer to
>>> have a new draft version that contains them.
>>>
>>> Thanks,
>>> --David
>>>
>>>

-- 
Cheers,
Arkady Kanevsky

---

From: arkady kanevsky <[email-masked]>
Date: Mon, 4 Apr 2011 21:50:10 -0400

Got it. Thanks Steve.
How about now?
Arkady

-- 
Cheers,
Arkady Kanevsky

---

From: Steve Wise <[email-masked]>
Date: Mon, 04 Apr 2011 21:18:31 -0500

Looks good.

Thanks,

Steve.

On 4/4/2011 8:50 PM, arkady kanevsky wrote:
> Got it. Thanks Steve.
> How about now?
> Arkady
>
> On Mon, Apr 4, 2011 at 9:41 PM, Steve Wise 
>     The key word to remove here is "responder".  The IRD in the MPA
>     start request is the initiators desired IRD _of the initiator_. 
>     Not the initiators desired _responder_ IRD.
>
>     If you want to change "desiired" to "initial" thats ok with me. 
>     But the key is to get rid of the word "responder" in that sentence.
>
>     Steve.
>
>
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>         Hey Arkady,
>>
>>           Change the IRD definition on the request from "In request:
>>         the Initiator requested responder IRD for the
>>>         On Thu, Mar 31, 2011 at 2:43 PM, Hemal Shah
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>                   Initiator and Responder:  If a responder receives
>>>                   an enhanced MPA message, it MUST respond with an
>>>                   unenhanced MPA message." I think it should be
>>>                   written that the responder must respond with an
>>>                   enhanced MPA message. It appears like a typo to me.
>>>                   RFC5044 does not define term FULPDU. RFC5044 uses
>>>                   term FPDU to refer to Framed Protocol Data Unit. I
>>>                   suggest that we use term FPDU instead of FULPDU in
>>>                   the draft.
>>>
>>>             Hemal
>>>             The -03 version of the MPA draft has addressed all of
>>>             the issues from my review, and .  Unfortunately, I need
>>>             some minor edits for clarity before I can send this on
>>>             to our AD with a publication request.  Would the authors
>>>             Ordinarily, I'd write an RFC Editor Note for small
>>>             changes like these, but they're sufficiently critical to
>>>             interoperability that I'd prefer to have a new draft
>>>             version that contains them.
>>>             Thanks,
>>>             --David
>>>             > I've done my review as a WG chair (and the person who
>>>             will be shepherding this draft to the ADs and
>>>             > IESG):
>>>             >
>>>             > Also, it would be greatly appreciated if a few people
>>>             other than the authors could take a look at
>>>             > this draft.  We have a very good author team on this
>>>             draft, whose expertise is beyond doubt, but
>>>             > compatibility.  If interop with unenhanced
>>>             implementations is only a SHOULD, that will need a
>>>             > convincing explanation.
>>>             >
>>>             > There are 3 Initiator/Responder cases that need
>>>             attention (New/Old, Old/New and New/New).  I think
>>>             > [B]In Section 7, we need to get the listing of all the
>>>             SCTP function codes into one place.  Either
>>>             > [C] In Section 8, what happens if the responder sends
>>>             an IRD or ORD value that's different from the
>>>             > corresponding initiator value?  Is the responder
>>>             allowed to increase the value that was sent?  An
>>>             > important case to cover is that the initiator sends a
>>>             valid value (e.g., 0x2000) but the responder
>>>             > returns the 0x3FFF value indicating that negotiation
>>>             is not supported.  Also, what is the behavior
>>>             > [D] In contrast, the Section 8 discussion of Control
>>>             Flag functionality is in better shape.  It
>>>             > would be helpful to add a sentence or two indicating
>>>             when the RTR occurs (Request ->, <- Reply, RTR
>>>             > ->), even though that is discussed earlier in the
>>>             draft.  Also, it's necessary to state whether
>>>             > negotiation of RTR functionality commits the Initiator
>>>             to using an RTR (e.g., suppose the initiator
>>>             <tel:%2B1%20%28508%29%20293-7953>             FAX: +1
>>>             (508) 293-7786 <tel:%2B1%20%28508%29%20293-7786>
>>>             > [email-masked]
>>>             <mailto:[email-masked]>        Mobile: +1 (978)
>>>             394-7754 <tel:%2B1%20%28978%29%20394-7754>

---

From: arkady kanevsky <[email-masked]>
Date: Tue, 5 Apr 2011 20:40:41 -0400

Submitted!

On Tue, Apr 5, 2011 at 10:37 AM, Sharp, Robert O
<[email-masked]>wrote:

> *From:* Steve Wise [mailto:[email-masked]]
> *Sent:* Monday, April 04, 2011 9:19 PM
> *To:* arkady kanevsky
> *Cc:* Sharp, Robert O; [email-masked]
>
> *Subject:* Re: [storm] MPA Draft - Review
>
>
>
> Looks good.
>
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786<%2B1%20%28508%29%20293-7786>
>
> > [email-masked]        Mobile: +1 (978) 394-7754<%2B1%20%28978%29%20394-7754>
>

-- 
Cheers,
Arkady Kanevsky

---

From: <[email-masked]>
Date: Wed, 6 Apr 2011 13:04:27 -0400

As part of requesting RFC publication of the MPA peer connect draft, I need to provide answers to the following questions:

        Are there existing implementations of the protocol? Have a 
        significant number of vendors indicated their plan to 
        implement the specification?

WG members should feel free to send information directly to me if there's any reluctance to posting it to the mailing list.  I don't need to identify the vendors or projects who have implementations or plans to implement; information about the approximate number of implementations and/or plans is all that I plan to supply (this info will be part of the IETF document shepherd questionnaire, and hence my answers become public).

Thanks,
--David (storm WG co-chair)

---

From: arkady kanevsky <[email-masked]>
Date: Wed, 6 Apr 2011 19:26:32 -0400

Robert and Steve,
are the right people to provide answer to this question.
Thanks,
Arkady

On Wed, Apr 6, 2011 at 11:51 AM, <[email-masked]> wrote:

> As part of submitting this draft to our AD to request publication, I need
> to provide answers to the following questions:
>
>
>
> Please send info on implementations and/or plans to me directly if you
> don’t want to share on the list.  The questions need to be answered in terms
> of numbers of implementations – I do not need to identify specific vendors
> or projects who have implemented or plan to implement the enhancements.
>
>
>
> Thanks,
> --David
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *arkady kanevsky
> *Sent:* Tuesday, April 05, 2011 8:41 PM
> *To:* Sharp, Robert O
> *Cc:* [email-masked]
> On Tue, Apr 5, 2011 at 10:37 AM, Sharp, Robert O <[email-masked]>
> wrote:
>

-- 
Cheers,
Arkady Kanevsky