RE: iSCSI: Naming and Discovery Team Formed

["Douglas Otis" <dotis@sanlight.net>]

David,

Your concerns about hyper-text management schemes are shared.  Inventing
naming servers supporting hyper-text management is a poor investment.
Ignoring authentication, the WG is ignoring an area where focus would be
productive.  Why wait for failure in a race down the wrong path before views
are expressed?  How would you determine a sound solution?  If A then B
followed by C may all be logical extensions of the other to justify the
endeavor.  If A is wrong, should you concern yourself with B or C?

Doug

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