Re: iSCSI: DLB's Last Call T15 comment

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

This is NOT and issue with me.  But it is my job as purveyor of the
compromise, to make sure that we did not quickly change the agreement with
out discussion.  Those that care, to leave the text as is, should speak up.

.
.
.
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>@ece.cmu.edu on 07/09/2002 05:28:16 PM

Sent by:    owner-ips@ece.cmu.edu


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



Let me make one more comment on this topic, and I'd let others comment.

Eventhough John's note describes a target's ability to do portal group
(re)configuration
a "problem", I beg to differ.  I'd in fact claim that this functionality in
some form must
be present in every target to initially get it up and running.

At any rate, it appears that John is certainly acknowledging that returning
TargetPortalGroupTag
key always is required for at least certain classes of configurable
targets.  If that's the case, and given
that making code changes is a non-issue now (with all the other recent
changes in text negotiation),
it escapes me why it's not preferable to simply return one additional key
always in Login Response.
This makes the code on either end simpler, and the spec certainly simpler.
--
Mallikarjun

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

----- Original Message -----
From: "John Hufferd" <hufferd@us.ibm.com>
To: "Mallikarjun C." <cbm@rose.hp.com>
Cc: <Black_David@emc.com>; <ips@ece.cmu.edu>
Sent: Tuesday, July 09, 2002 11:23 AM
Subject: Re: iSCSI: DLB's Last Call T15 comment


>
> 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
> > ---------------------------------------------------
> >
>
>
>
>
>
>