Issue155

Title opaque device_addr should be accompanied by layouttype4
Priority required Status editing
Superseder Nosy List dnoveck, mre, spencer.shepler
Assigned To spencer.shepler Topics stage0-req

Created on 2007-02-11.00:19:18 by spencer.shepler, last changed 2007-03-01.16:39:22 by mre.

Messages
msg530 (view) Author: mre Date: 2007-03-01.16:39:22
I checked changes for this into cvs.
msg509 (view) Author: spencer.shepler Date: 2007-02-11.16:17:43
Suggestion looks good;  Thanks Mike.
msg508 (view) Author: mre Date: 2007-02-11.16:15:06
--- "Spencer Shepler \"NFSv4.1 Issue Tracker\""
<issue-tracker@nfsv4-editor.org> wrote:

> 
> New submission from Spencer Shepler <spencer.shepler@gmail.com>:
> 
> There are responses that contain opaque device_addrs
> that are returned to the client without inband context
> of what layout type the device_addr represents.  This
> technically isn't a problem since the client knows
> the context from the original call.  However, to ease
> protocol "validation" by the client and the building
> of network trace tools like snoop and ethereal, it is
> best to include the laytouttype along with the
> device_addr.  This is a straightforward change and 
> the new structures would look something like this:
> 
> struct devlist_item4 {
> 	deviceid4		dli_id;
> 	layouttype4		dli_layout_type;	
> 	opaque			dli_device_addr<>;
> };

I prefer:

struct stordevice_addr {
  layouttype4		sda_layout_type;
  opaque                sda_addr_body; 
};

 struct devlist_item4 {
 	deviceid4		dli_id;
 	stordevice_addr         dli_addr;
 };

> 
> struct GETDEVICEINFO4resok {
> 	layouttype4		gdir_layout_type;	
> 	opaque			gdir_device_addr<>;
> };

struct GETDEVICEINFO4resok {
 	struct stordevice_addr  gdir_device_addr;	
};
msg507 (view) Author: mre Date: 2007-02-11.16:14:17
> struct devlist_item4 {
> 	deviceid4		dli_id;
> 	layouttype4		dli_layout_type;	
> 	opaque			dli_device_addr<>;
> };

I prefer:

struct stordevice_addr {
  layouttype4		sda_layout_type;
  opaque                sda_addr_body; 
};

 struct devlist_item4 {
 	deviceid4		dli_id;
 	stordevice_addr         dli_addr;
 };

> 
> struct GETDEVICEINFO4resok {
> 	layouttype4		gdir_layout_type;	
> 	opaque			gdir_device_addr<>;
> };

struct GETDEVICEINFO4resok {
 	struct stordevice_addr  gdir_device_addr;	
};
msg506 (view) Author: spencer.shepler Date: 2007-02-11.00:19:18
There are responses that contain opaque device_addrs
that are returned to the client without inband context
of what layout type the device_addr represents.  This
technically isn't a problem since the client knows
the context from the original call.  However, to ease
protocol "validation" by the client and the building
of network trace tools like snoop and ethereal, it is
best to include the laytouttype along with the
device_addr.  This is a straightforward change and 
the new structures would look something like this:

struct devlist_item4 {
	deviceid4		dli_id;
	layouttype4		dli_layout_type;	
	opaque			dli_device_addr<>;
};

struct GETDEVICEINFO4resok {
	layouttype4		gdir_layout_type;	
	opaque			gdir_device_addr<>;
};
History
Date User Action Args
2007-03-01 16:39:24mresetmessages: + msg530
2007-02-11 16:17:46spencer.sheplersetmessages: + msg509
2007-02-11 16:15:09mresetmessages: + msg508
2007-02-11 16:14:19mresetmessages: + msg507
2007-02-11 00:31:33dnovecksettopic: + stage0-req
2007-02-11 00:19:22spencer.sheplercreate