Re: iSCSI: DLB's Last Call T15 comment

["John Hufferd" <hufferd@us.ibm.com>]

The issue was that some of the folks in the group, did not even perceive
that their boxes would even have the problem that the statement was
designed to handle.  And they did not want to have to respond as specified
to get around a problem that did not exist.  Hence, they agreed after some
debate that IF a box had that problem then it SHOULD make that response.
They did not want MUST since they did not have the problem to begin with.
And the other folks did not want MAY, since they did not feel that if a box
had that problem, it was approprate for the box not to inform the
Initiator.

The debate issue about the "realness" of the problem seems to be still
valid (but I would hope that we do not go into that on this list).  The
point seemed to be around different design issues.

So the choice of SHOULD in my opinion was approprate, since it is not
needed if the problem does not exist in a specific implementation, and MAY
is much too weak if the box has the problem.


.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


"Mallikarjun C." <cbm@rose.hp.com> on 07/09/2002 11:00:20 AM

To:    <Black_David@emc.com>, John Hufferd/San Jose/IBM@IBMUS
cc:    <ips@ece.cmu.edu>
Subject:    Re: iSCSI: DLB's Last Call T15 comment



I was part of the team that deliberated on this issue and was a party
to the compromise text.  But let me state for the record that I (among
others) had precisely suggested what David is suggesting - make it
a MUST return always, it's simple to specify and implement.

The reasons offered primarily had to do with changing existing code.
Now with the changes in certain key names and the advent of C-bit
functionality (that require code changes anyway), this may be a good
time to consider making this simpler.  I see that Julian also is agreeable
to this change.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com

----- Original Message -----
From: <Black_David@emc.com>
To: <hufferd@us.ibm.com>
Cc: <ips@ece.cmu.edu>
Sent: Monday, July 08, 2002 11:39 PM
Subject: iSCSI: DLB's Last Call T15 comment


> John,
>
> [T.15] 4.3.1  Login Phase Start
>
>    The first Login Response PDU during the Login Phase from the iSCSI
>    target SHOULD return the TargetPortalGroupTag key that contains the
>    tag value of the iSCSI portal group servicing the Login Request PDU.
>    If the iSCSI target implementation supports altering the portal group
>    configuration (including adding, deleting, and swapping of portals in
>    a portal group), it MUST return the TargetPortalGroupTag key carry-
>    ing the tag value of the servicing portal group.
>
> Let's make returning this key a MUST in all cases - less text, simpler
> protocol, simpler code at the Initiator.
>
> > The item numbered T15, had a lot of discussions, especially in the
Naming
> > and Discovery Team, and the current wordage was the results of a
> > compromise, where a number of vendors did not have the issue, and
strongly
> > felt that it would be the wrong thing to do with their product.  So we
> > agreed that the SHOULD section would be the right answer for
> > every one.
>
> This sort of compromise leads to "MAY", not "SHOULD".  I
> suggest summarizing the NDT discussion to the list, as it's now an issue
> to be settled here.
>
> Thanks,
> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 249-6449            FAX: +1 (508) 497-8018
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>