Comments embedded below...
Akihiro Shimura
On Fri, 3 Dec 1999 01:07:23 EST
PJohansson@aol.com wrote:
> In a message dated 99-11-25 10:15:33 EST, shimura@pure.cpdc.canon.co.jp
> writes:
>
> <<I agree that utility of the current "function" definition has been lost,
> and the definition should be removed.>>
>
> The easiest part of the problem, upon which I think we all agree...
>
> <<Though I agree to remove the definition, I think replacing the "function"
> with the "unit architecture" is too restrictive because definition of the
> "unit architecture" seems to imply that function (or a set of services)
> resides only in the target.>>
>
> <<One of the original intent for the "function" would be to define a set of
> services provided over single login by a device (either initiator or target).
> In this sense, there will be no difference between "function" on the
> initiator and "function" on the target because PPDT provides symmetric
> transport service, though current definition only supports the "function"
> resided in the target.>>
>
> An insightful observation, which unfortunately opens a Pandora's box of
> connected problems. I agree that this needs to be resolved; for example,
> "logical unit" is used in many places where reference to an initiator would
> be equally appropriate.
As far as I was aware of, the places "logical unit" seemed to be
used inadequately were only in the definitions of the "management
service" (Page 6 and 12).
This was one of the reasons why I removed the definition. Another
reason was that the definition seemed to be explaining a behavior
rather than defining a term, and I thought it would be
straightforward to explain it in "4.3 Connection management". (Sorry
for not saying earlier.)
> Would "peer unit" be a useful technical term? A peer unit would be either an
> initiator or a logical unit. I'm very open to other suggestions, too.
I thought, from the perspective of transport definition, the "peer
unit" would only be necessary to indicate that one queue zero
(control queue) is allocated per login, and that queue field value
is unique among a login. I felt it would be easy to describe these
things without a new term like "peer unit" in place of "function".
(It would be beyond the scope of the transport that a certain set of
services constitutes certain functionality.)
> <<I've created a text for removal of the "function" definition and symmetric
> description at places referring the "function". Please find attached
> document(RMFUNCr01.pdf).>>
>
> I think it's a step in the right direction, but I have some problems with the
> details. The more I look at the issues, the more the seem embedded in the
> current draft. Some of them are substantive, not just editorial. For example,
> has the working group made a considered decision about how a PPDT initiator
> is identified from configuration ROM? Or just pushed it off as a low priority
> matter because most are concentrating on implementations that aren't so
> symmetric? I think we can resolve this in Los Angeles, perhaps with some
> reflector discussion before hand.
I proposed to define an Unit directory for the PPDT initiator at
previous meeting with the intention of solving this kind of
asymmetry in the accessibility to the services, though it was mainly
discussed in the context of how to find login request capability.
-- Akihiro Shimura (shimura@pure.cpdc.canon.co.jp) Office Imaging Products Development Center 3 CANON INC.