What I'm going to do for the name server extension for FCP-2

[Jeff Stai]

* From the T10 Reflector (t10 at t10.org), posted by:
* Jeff Stai <j_stai at qlc.com>
*

Bob - The notes I took from the discussion
differ from your proposal:

- New 255-byte "FC-4 Descriptor" Object.

- Register and Query would be based on FC-4 TYPE Object,
which is a 32-bit map.

- Register request contains:
	- Port Identifier Object
	- FC-4 TYPE Object
	- FC-4 Descriptor Object, corresponding to first bit 
	set in FC-4 TYPE Object
	- FC-4 Descriptor Object, corresponding to second bit 
	set in FC-4 TYPE Object
	- etc.

- Query request contains:
	- Port Identifier Object
	- FC-4 TYPE Object

- Query response contains:
	- FC-4 Descriptor Object, corresponding to first bit 
	set in FC-4 TYPE Object
	- FC-4 Descriptor Object, corresponding to second bit 
	set in FC-4 TYPE Object
	- etc.

- The point I heard was that this form allows all FC-4s
to be registered and queried at once. I heard strong support 
for this!

- The new FC-4 Descriptor Object is NOT returned by Get All Next.

- The four bit flag field is a separate item and
does not change from what is defined in rev 6.0.
Some folks were going to come back with a way to
register those bits.

Bob - I don't necessarily disagree with your proposal
(except for some minor details easily corrected I bet).

But your proposal contains some elements that I distinctly
recall were objected to during the discussion. And I came
away believing what I said (above) is what was agreed to.

Hopefully those with opinions will now weigh in and
correct one of us... - js


> -----Original Message-----
> From: Bob Snively [mailto:Bob.Snively at EBay.Sun.COM]
> Sent: Wednesday, December 15, 1999 12:39 PM
> To: fc at network.com; t10 at t10.org
> Subject: What I'm going to do for the name server extension for FCP-2
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Bob Snively <Bob.Snively at EBay.Sun.COM>
> *
> 
> Is there anything I have missed here?  
> 
> New rev of T10/99-325r2:
> 
> "The result of the December meeting discussion is that Jeff Stai will
> define in FC-GS-3 a type specific name server port object. 
> FCP-2 will define
> that name server object as a control header, containing "Target" and
> "Initiator" bits and the SCSI INQUIRY command data for targets. An
> additional proposal may be forthcoming on this question."
> 
> 
> Jeff,  
> 
> I would propose that the payload of the type specific object 
> request should 
> include:
> 
> 	Type (in case there are more than one types for that 
> port) (1 byte)
> 	Port identifier						
>    (3 bytes)
> 	
> I would propose that the payload of the type specific object response
> should include, by anology with the symbolic port name:
> 
> 	Type specific object Length (m)				
>     (1 byte)
> 	Type specific flags 					
>     (3 bytes)
> 	Type specific object					
>     (m bytes)
> 	Reserved 						
> (255-m bytes)
> 
> The field would be a constant length of 260 bytes.
> 
> For FCP-2, the type specific flags would include bits for:
> 
> 	"permanent initiator"
> 	"temporary initiator"
> 	"target"
> 	
> The type specific object would be the LUN 0 INQUIRY data, truncated to
> 255 bytes if required.
> 
> Requests for a type not supported would return a CT_RJT (which may not
> be defined yet).
> 
> Requests for a supported type where the information was not 
> available would
> return a type specific object length of 0 in the 260 byte response.
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org