SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: Naming and Discovery Team Formed



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


Home

Last updated: Tue Sep 04 01:06:35 2001
6315 messages in chronological order