Re: [storm] Unassigned vs. Reserved in rdmap-ext draft

"Sharp, Robert O" <robert.o.sharp@intel.com> Mon, 16 September 2013 20:03 UTC

From: "Sharp, Robert O" <robert.o.sharp@intel.com>
To: "Black, David" <david.black@emc.com>, Tom Talpey <ttalpey@microsoft.com>, "storm@ietf.org" <storm@ietf.org>
Thread-Topic: Unassigned vs. Reserved in rdmap-ext draft
Thread-Index: Ac6w8/laSw0o3ma3RLCdlkF3uUN2ygCI7esg
Date: Mon, 16 Sep 2013 20:03:22 +0000
Message-ID: <2ABFA3E36CBB794685BFBA191CC1964952B3A6B1@FMSMSX105.amr.corp.intel.com>
References: <8D3D17ACE214DC429325B2B98F3AE712025DA1BD36@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712025DA1BD36@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [storm] Unassigned vs. Reserved in rdmap-ext draft
Precedence: list

Hi David,

Back to Reserved it is.

Thanks,
Bob

> -----Original Message-----
> From: Black, David [mailto:david.black@emc.com]
> Sent: Saturday, September 14, 2013 12:14 AM
> To: Sharp, Robert O; Tom Talpey; storm@ietf.org
> Subject: Unassigned vs. Reserved in rdmap-ext draft
> 
> Bob,
> 
> > > > > + Section 5.2.1 Atomic operation values
> > > > >
> > > > > >   ---------+-----------+----------+----------+---------+---------
> > > > > >   0011b    |           |
> > > > > >   to       | Reserved  |            Not Specified
> > > > > >   1111b    |           |
> > > > > >
> > > > > > ---------+-----------+----------------------------------------
> > > > > > -
> > > > >
> > > > > ... and
> > > > >
> > > > > >   4. At the Responder, when an invalid Atomic Operation Request
> > > > > >      Message is delivered to the Remote Peer's RDMAP layer, an error
> > > > > >      is surfaced.
> > > > >
> > > > > Are the "Reserved" fields invalid?
> > > > >
> > > >
> > > > [Authors] Yes, the reserved values are invalid.  Clarifying text
> > > > has been added.
> > >
> > > Unbeknownst to you, "Reserved" turns out to be a reserved word for
> > > IANA that has a meaning different from usage in other standards
> > > bodies (we hit this in working through IANA's comments on the
> > > iscsi-sam draft).  This is
> > not a
> > > problem in the new IANA Considerations text, but we probably ought
> > > to also expunge use of that word here.
> > >
> >
> > That is unfortunate.  We changed it to un-used in the rest of the doc
> > but don't like that much.  Also now it is different than RFC 5040.
> > Are you sure we want to change this?
> 
> Oops, you're right - go back to Reserved in the figure and body of draft, and
> just stick with Unassigned in the IANA Considerations.  Sorry for the detour
> ...
> 
> Thanks,
> --David
> 
> 
> > -----Original Message-----
> > From: Sharp, Robert O [mailto:robert.o.sharp@intel.com]
> > Sent: Wednesday, September 11, 2013 5:11 PM
> > To: Black, David; Tom Talpey; storm@ietf.org
> > Subject: RE: [storm] Review comments on draft-ietf-storm-rdmap-ext
> >
> > Hi David,
> >
> > Thanks again.  Responses below...
> >
> > Thanks,
> > Bob
> >
> > > -----Original Message-----
> > > From: Black, David [mailto:david.black@emc.com]
> > > Sent: Friday, September 06, 2013 6:31 PM
> > > To: Sharp, Robert O; Tom Talpey; storm@ietf.org
> > > Subject: RE: [storm] Review comments on draft-ietf-storm-rdmap-ext
> > >
> > > One more small item:
> > >
> > > > > + Section 5.2.1 Atomic operation values
> > > > >
> > > > > >   ---------+-----------+----------+----------+---------+---------
> > > > > >   0011b    |           |
> > > > > >   to       | Reserved  |            Not Specified
> > > > > >   1111b    |           |
> > > > > >
> > > > > > ---------+-----------+----------------------------------------
> > > > > > -
> > > > >
> > > > > ... and
> > > > >
> > > > > >   4. At the Responder, when an invalid Atomic Operation Request
> > > > > >      Message is delivered to the Remote Peer's RDMAP layer, an error
> > > > > >      is surfaced.
> > > > >
> > > > > Are the "Reserved" fields invalid?
> > > > >
> > > >
> > > > [Authors] Yes, the reserved values are invalid.  Clarifying text
> > > > has been added.
> > >
> > > Unbeknownst to you, "Reserved" turns out to be a reserved word for
> > > IANA that has a meaning different from usage in other standards
> > > bodies (we hit this in working through IANA's comments on the
> > > iscsi-sam draft).  This is
> > not a
> > > problem in the new IANA Considerations text, but we probably ought
> > > to also expunge use of that word here.
> > >
> >
> > That is unfortunate.  We changed it to un-used in the rest of the doc
> > but don't like that much.  Also now it is different than RFC 5040.
> > Are you sure we want to change this?
> >
> > > I suggest deleting the above table row in Figure 5, and making the
> > > following change to item 4 below the table:
> > >
> > > OLD
> > >    4. At the Responder, when an invalid Atomic Operation Request
> > >       Message with a reserved Atomic Operation Code is delivered to the
> > >       Remote Peer's RDMAP layer, an error MUST be surfaced.
> > > NEW
> > >    4. At the Responder, an error MUST be surfaced in response to delivery
> > >       to the Remote Peer's RDMAP layer of an Atomic Operation Request
> > >       Message with an Atomic Operation Code that the RNIC does not
> support.
> > >
> >
> > Good suggestion.
> >
> > > Thanks,
> > > --David
> > >
> > > > -----Original Message-----
> > > > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On
> > > > Behalf Of Sharp, Robert O
> > > > Sent: Thursday, September 05, 2013 5:23 PM
> > > > To: Tom Talpey; storm@ietf.org
> > > > Subject: Re: [storm] Review comments on draft-ietf-storm-rdmap-ext
> > > >
> > > > Hi Tom,
> > > >
> > > > Thanks for the comments!  The author's responses are embedded
> below...
> > > >
> > > > Thanks,
> > > > Bob
> > > >

[storm] Unassigned vs. Reserved in rdmap-ext draft Black, David
Re: [storm] Unassigned vs. Reserved in rdmap-ext … Sharp, Robert O