Re: iSCSI: Naming and Discovery Team Formed

[David Robinson <David.Robinson@EBay.Sun.COM>]

Doug,
You have made some points I agree with as well as some I disagree
with.  Over the course of the naming dicussion we have had some
interesting perspectives, in fact I believe my comments were
not far from yours with respect to URLs.  But ignoring all that,
the purpose of the design team is to take all of the often
unfocused discussions and put it into a single document that
can cause a focused discussion. Those with specific issues can
lobby to get the draft changed, those with major issues can
propose a counter draft with the same level of detail.

In my opinion the slow progress in this WG is the lack of specific
details that focus productive discussions. General theoretical
arguments end up like religion and politics, interesting but
generally lacking in concensus.

So lets have the team produce the draft and if it fails to
answer your concerns you can bring back up your issues with
specific directed comments.

	-David

Douglas Otis wrote:
> 
> David,
> 
> The nature of the questioning was in respect to general architecture.  It is
> very easy to get lost in the tremendous detail required in any of these
> tasks.  Many times the answer is framed by the question, or in the case of
> task management, the list of tasks.  It would appear this architecture is
> driven by HTTP idiosyncrasies without examining unique properties of SCSI
> transport.  In doing so, there is now hyper-text management requests which
> call for special name servers.  Question the first step in what appears to
> be a series of mis-steps.  The outcome is a parallel world of proposals
> vaguely similar to existing standards.  This WG should be developing a
> transport that leverages off of these existing standards without
> adulteration.  Re-engineering systems with new standard proposal after new
> standard proposal without even a revision indication?  There should be
> enough structure within this effort to allow alternative solutions and
> repairs.  Anointment to team status does not preclude discussion by the
> peanut gallery.  As John made the list, he and not the team would know the
> answer to the delay in considering authentication.
> 
> Doug
> 
> > Doug,
> > Maybe I missed something along the way, but is it not the purpose
> > of the N&D team to ask and answer the types of questions you raised
> > and to produce a draft to address them?
> >
> > The WG has to provide an answer to the problem of N&D, even if the
> > answer is determined to have already been answered by an another group,
> > we still need to have a draft to explain the decision.
> >
> > To get to an RFC we need a draft, to get a draft we need to have a
> > proposal to discuss, to have a proposal we need to have a team to
> > propose one, John has announced the formation of a team. So what is
> > your point?
> >
> >       -David
> >
> > Douglas Otis wrote:
> > >
> > > John,
> > >
> > > With your technical hat on, if speed is important why re-invent existing
> > > protocols?  Authentication will access a database external to
> > the transport
> > > and devices which will easily provide required addressing.  The
> > SCSI name
> > > server effort is to include text strings within transport management
> > > requests.  This is based on an assumption text is a universal standard
> > > whereas numbers change, i.e. DNS with respect to IP for HTTP.
> > Is there a
> > > general assumption SCSI will operate in an open and
> > unauthenticated manner
> > > similar to HTTP?  Will there be established a consortium for registering
> > > SCSI names?  As authentication is essential to SCSI access, could you
> > > provide a technical reason for this naming effort?
> > >
> > > SCSI standards groups provide unique numbers rather than text strings to
> > > locate media.  The user is the universal standard with respect to
> > > authentication and SCSI unique numbers associated with the user
> > at the time
> > > of authentication defines a numeric path.  A schema within LDAP
> > can provide
> > > these associations and not compromise security as would management text
> > > strings.  Even if the internal network was IB, a number or
> > perhaps several
> > > is always suitable.  What are the problems being solved by this naming
> > > effort?  Why is authentication not being considered first?
> > >
> > > Doug
> > >
> > > > With my TC Hat on:
> > > > I am announcing the formation of a Naming and Discovery Team.
> >  The team
> > > > members are:
> > > >
> > > > Jack Harwood, Joe Czap, Kaladhar Voruganti, Howard Hall, Mark
> > > > Bakke, Joshua
> > > > Tseng, V.Sairam, Yaron Klein, Lawrence J. Lamers,  &Jim Hafner.
> > > >
> > > > Kaladhar Voruganti will be the Editor, and Lead for the first Draft.
> > > >
> > > > We are all looking forward to their effort, and hope they can do some
> > > > speedy work.
> > > >
> > > > Hat off.
> > > >
> > > > .
> > > > .
> > > > .
> > > > John L. Hufferd
> > > > Senior Technical Staff Member (STSM)
> > > > IBM/SSG San Jose Ca
> > > > (408) 256-0403, Tie: 276-0403
> > > > Internet address: hufferd@us.ibm.com
> > > >
> >