Subject: RE: P1394> units and logical units definition

From: [email-masked]
Date: Tue, 17 Mar 1998 11:17:24 -0800

______________________________ Reply Separator _________________________________
Subject: RE: P1394> units and logical units definition
Author:  Non-HP-rturner ([email-masked]) at HP-Roseville,mimegw3
Date:    3/16/98 9:20 PM

> I thought we had a pretty firm idea on the handling of logical units.
     
     From the discussion it still seems hazy to me.
     
     I think a detailed picture matching services to Unit Directories to 
     LUNs might help.
     
> Does this discussion require clarification of the current profile 
> document, for full understanding?
     
     Absolutely.
     
> Also, is there need for a teleconference on this or any other subject 
> prior to the next face-to-face meeting?
     
     Would be nice, schedule could be tight.
     How about 3/19 at 4:00PM?
     
     3/20 could be bad for folks in Japan.
     3/23 is due date for the next rev of the spec.
     
Randy

---

From: Atsushi_Nakamura <[email-masked]>
Date: Wed, 18 Mar 1998 10:17:31 +0900

It would help to convince me (and probably others)
that we are going the right way, 
and that everybodyis in synch. if we can :

1. Confirm that the current usage of SBP-2 unit(directory)s and 
   LUNs are consistant with the idea ("with the spirit")of units
   and LUNs defined in the SBP-2 spec. 

>Note that SBP-2's concept of a printer certainly does not match
>well with our devices.  Disks are easily modeled.  Scanners are
>fairly easily modeled.  Printers definitely are not.

   As Greg mentioned, printers are modeled differently(more complex)
   from disks, and I think we are starting to define a new usage 
   of SBP-2 units and LUNs in the current printer profile 0.1d that are 
   different from other SBP-2 devices.
   (where 1 (printer) function is comprised of multiple units
    of the same transport protocol (PWG profile over SBP-2) within
    1 node, and a combination of specific LUNs across these differnt
    units need to work simultaneously to achieve the (printer) function.)

  Greg (Shue)'s explanation about an example of a printer model
  by considering logical units as a service (the cuurent profile0.1d) made
  sense within itself, but the question whether that usage is the 
  intended usage or not has not been answered. There also is the issue
  on how to match up the LUNs

Eric says;
>Even if each of those models is allowed by SBP-2, I think
>the first one (a single unit with multiple LUNs) is both more
>in the spirit of SBP-2 and more in the spirit of 1394.  

  The above comment increased the magnitude of my concern.     
  I think this is a question of how the SBP-2 people intended 
  units and LUNs to be used, so confirmation with (or a comment from)
  a SBP-2 expert would help.

2. Confirm that the current usage of units(and LUNs) are consistant
   and "in spirit" with 1394 and 1212 (and other protocols aside from 
   SBP-2.)
   Same as above, other protocols(such as AVC/FCP, DPP/Thin,
   Conf.camera spec. ) achieve the functionality within one "1212"unit.
   (Services are MUXed within the transport and above)      
   The current profile will be the first of it's kind to achieve a 
   functionality by using differnt LUNS across different "1212" units so
   there is a possiblity that the 1394 PC printer may look "odd"
   in the 1394 world.

3. Confirm within PWG that this is the way to go.
   As I mentioned, the discussion about desires for mutiple
   independent channels within 1 LUN is still continuing, so I also agree with
   Alan that this is still hazy.

4. Lastly, 

>      I think a detailed picture matching services to Unit Directories to 

I agree with this idea.
Modelling a printer application may be out of the scope of the profile,
but I think an example of a what a "basic" printer should look like 
will help understanding (even within PWG to keep everyone in synch !)

>      How about 3/19 at 4:00PM?
I won't make this, but please go ahead if this schedule is reasonable
for everyone else.
I also apologize for not being able to contribute face-to face.

Ats

>      3/23 is due date for the next rev of the spec.

-----------------------------------------
Atsushi Nakamura
-----------------------------------------

BJ Technology Development 22,
Canon Inc.

53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211

tel:+81-3-44-733-6111(ext.5593)
    +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):[email-masked]
email(2):[email-masked]
-----------------------------------------