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
> LUNs might help.
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 !)
> Would be nice, schedule could be tight.
> 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
At 11:17 98/03/17 -0800, ALAN_BERKEMA at hp-roseville-om2.om.hp.com wrote:
> > 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
>
-----------------------------------------
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):Atsushi_Nakamura at cbj.canon.co.jp
email(2):atsnaka at bsd.canon.co.jp
-----------------------------------------