I have a concern about requiring Message_Response for this
functionality.
Upon the reception of the request message, the initiator will respond
like following;
a) I don't understand the message,
b) I understand, but I won't do because ...,
c) I understand, and I will try.
(d) Silently ignores)
Apparently, "c)" can be replaced by the login request itself, though
these are not exactly the same because the lack of the resource may
prevent the initiator from issuing a login request in the case "c)".
I suppose that the information that distinguishes "a)" and "b)" (or
variants of "b)") will be almost useless for the target.
For example, even if the target knows the reason "a)", the target will
not be able to distinguish between the following two cases;
a-1) No driver that handles this message is installed in the system,
a-2) The driver that handles this message is eventually unloaded.
In the case "a-1)", retrying request will not succeed until the driver
is installed.
On the other hand, in the case "a-2)", retrying request may succeed
when the reloading of the driver is completed.
Thus, this information will not help target's retry strategy.
In the case "b)", the only useful response would be "Don't retry
anymore" kind of response, but this kind of response will not usually
be expected to happen from the fact that the target is already
configured to request a login. I think that implementation specific
retry-timeout strategy will be enough even in this case as far as the
implementation is good bus citizen.
Any suggestions?
Akihiro Shimura
On Thu, 29 Jul 1999 18:00:01 -0700
ALAN_BERKEMA@HP-Roseville-om2.om.hp.com wrote:
>
> ----------------------------------------------------------------
> Greg (& other PWG lurkers),
>
> Thanks for the comments.
>
> I have updated the proposal with most of your comments (see attached).
>
> I did not quite get number 5 & 6 so I did not include those.
>
> Overall it still needs some work.
>
> regards,
> Alan
>
>
> ______________________________ Reply Separator _________________________________
> Subject: RE: P1394> Login Request Proposal
> Author: Non-HP-gleclair (gleclair@agentz.com) at HP-Roseville,mimegw3
> Date: 7/23/99 9:41 AM
>
>
> Alan,
>
> A couple of comments:
> 1. The version field in the message will require a unique 'Sub-ID' from the PWG
> pool.
> In discussion with some folks, I understand we're to use a sub-ID for one purpos
> e only.
>
> 2. Should we include some more detailed information about which function in a de
> vice
> sent the request for a login?
>
> - For device with more than one Unit Directory, the message
> should include Unit_Unique_ID.
>
> - We need to require a Unit_Unique_ID to Config ROM for devices with more
> than one unit directory that wants to use this mechanism (Msg Rq/Rsp).
>
> 3. What are the return codes for a login request?
> Timeout for response is a question of whether the other node supports Ms
> g Rq/Rsp
> Valid responses are one of OK | REJECTED | WAITING
>
> 4. Would seem to be a good thing to indicate which devices support this feature?
> - Via feature directory in ROM?
> - or via part of SBP-2 login request / reply?
>
> 5. Discovery would seem to be another issue. I think the key point we need to id
> entify is
> the addressing requirements.
> - The registers are at fixed addresses
> - The node address can change based on topology, etc.
> - The EUI -64 will be the absolute address we can use
> - A Unit_Unique_ID will tell us the detailed addressing info on more com
> plex nodes.
> - Should we include BUS # Info?
>
> 6. Address info must be available. What methods are we specifying for defining t
> his info
> - Command set
> - Vendor specific manner (i.e. Manual entry)
>
> 7. One last thing in terms of the message payload:
> - Will the message always be the same length?
> - 1212r defines MSG Req/Resp to handle 64 bytes
> - If our message is less, should we include a byte count in the header?
>
> Cheers,
> Greg LeClair
>
>
>
>
> -----Original Message-----
> From: ALAN_BERKEMA@HP-Roseville-om2.om.hp.com [SMTP:ALAN_BERKEMA@HP-Roseville-
> om2.om.hp.com]
> Sent: Wednesday, July 21, 1999 10:19 AM
> To: p1394@pwg.org
> Subject: P1394> Login Request Proposal
>
> Please see the attached proposal for the "Login into me" proposal.
>
> Feel free to discuss this on the reflector before the next PWG
> meeting.
>
> There is time to modify and/or enhance this before 8/2/99 (2 week
> rule).
>
> It would be nice to finalize this in Alasaka.
>
> Thanks,
> Alan
>
> << File: msg_rrp.pdf >>
>
-- Akihiro Shimura (shimura@pure.cpdc.canon.co.jp) Office Imaging Products Development Center 3 CANON INC.