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

From: "Black, David" <[email-masked]>
Date: Sat, 14 Sep 2013 01:13:49 -0400

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:[email-masked]]
> Sent: Wednesday, September 11, 2013 5:11 PM
> To: Black, David; Tom Talpey; [email-masked]
> 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:[email-masked]]
> > Sent: Friday, September 06, 2013 6:31 PM
> > To: Sharp, Robert O; Tom Talpey; [email-masked]
> > 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: [email-masked] [mailto:[email-masked]] On Behalf
> > > Of Sharp, Robert O
> > > Sent: Thursday, September 05, 2013 5:23 PM
> > > To: Tom Talpey; [email-masked]
> > > 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
> > >

---

From: "Sharp, Robert O" <[email-masked]>
Date: Mon, 16 Sep 2013 20:03:22 +0000

Hi David,

Back to Reserved it is.

Thanks,
Bob

> Sent: Saturday, September 14, 2013 12:14 AM
> Subject: Unassigned vs. Reserved in rdmap-ext draft
> 
> Bob,
> 
> > > > [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?
> 
> > > > [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
> > > > From: [email-masked] [mailto:[email-masked]] On
> > > > Behalf Of Sharp, Robert O