RE: SCSI MIB design team formation

["Elizabeth Rodriguez" <egrodriguez@lucent.com>]

Hello all,

We have received input from many individuals willing to help out on this
effort/design team.  

David, Keith and I will review the information we have received and
announce the team formation.  Target for this announcement will be on
Monday, Sept 17.

Thanks to all who have volunteered.

Elizabeth

-----Original Message-----
From: Elizabeth Rodriguez 
Sent: Monday, September 03, 2001 11:42 PM
To: ips@ece.cmu.edu
Cc: David Black (E-mail); Keith McCloghrie (E-mail);
sbhagat@tripace.com; rkroberts@aol.com
Subject: SCSI MIB design team formation


Hello all,

I believe that the IPS WG is now prepared to undertake the effort of
development of a SCSI MIB.
As mentioned below by Marjorie, while the iSCSI MIB design team is
willing to contribute to this development,
the effort needs to be undertaken by a different group of people.

T10 CAP is also willing to contribute, but the T10 organization will not
undertake the MIB development itself.
That will be a draft undertaken by the IPS working group.

We now have 2 individuals who are willing to undertake the SCSI MIB
development.
The first is Sanjeev Bhagat, of Tripace.
The second is Ron Roberts, of Adaptec.
Both are experienced in both SCSI and MIB work, and are willing to
undertake this effort.

Keith McCloghrie will assist this group in his capacity as MIB advisor.

Anyone else who is willing to contribute to this effort should contact
David or myself, by Sept 10.

Thanks,

Elizabeth Rodriguez & David Black

-----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1)
[mailto:marjorie_krueger@hp.com]
Sent: Wednesday, August 29, 2001 4:49 PM
To: 'Michele Hallak - Stamler'; mbakke@cisco.com
Cc: ips@ece.cmu.edu
Subject: iSCSI: state of a SCSI MIB (was RE: ISCSI: A propos MIB and
specially iSCSI MIB)


Regarding your question on the state of a SCSI MIB, we are looking for a
MIB
designer that is SCSI aware to head this effort, as Mark and I have too
many
other committments.  The iSCSI MIB design team will contribute to the
basis
for a SCSI MIB, but we are still looking for a leader in the SCSI MIB
effort.  We have taken this issue to the T10 CAP group to solicite help,
but
the MIB must ultimately be submitted as an IETF draft.  Hopefully, this
effort will take shape soon.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com 

> -----Original Message-----
> From: Michele Hallak - Stamler [mailto:michele@sanrad.com]
> Sent: Tuesday, August 28, 2001 9:20 AM
> To: mbakke@cisco.com
> Cc: ips@ece.cmu.edu
> Subject: RE: ISCSI: A propos MIB and specially iSCSI MIB
> 
> 
> Mark,
> Thanks a lot for your prompt answer...
> My comments are prefixed by MHS.
> Thanks again,
> 	Michele
> 
> > -----Original Message-----
> > From: Mark Bakke [mailto:mbakke@cisco.com]
> > Sent: Monday, August 27, 2001 3:47 PM
> > To: Michele Hallak - Stamler
> > Cc: ips@ece.cmu.edu
> > Subject: Re: ISCSI: A propos MIB and specially iSCSI MIB
> > 
> > 
> > Michele-
> > 
> > Thanks for the comments.  My comments are below.
> > 
> > --
> > Mark
> > 
> > Michele Hallak - Stamler wrote:
> > > 
> > > Since you are meeting at interim meetings on MIBs:
> > > 
> > > The following mail summarizes my suggestions concerning the
> > improvement
> > > of iSCSI MIB:
> > > 
> > > 1. New Textual Convention:
> > >  AuthenticationMethodTC  ::= TEXTUAL-CONVENTION
> > >     STATUS current
> > >     DESCRIPTION
> > >         "List of possible authentication methods."
> > >     SYNTAX INTEGER {
> > >                 none(1),
> > >                 crc32(2),
> > >                 crc64(3),
> > >                 md5(4),
> > >                 kerberosMd5(5),
> > >                 kerberosMd5des(6),
> > >                 kerberosMd5desHmark(7)
> > >         }
> > 
> > This is a text field in the current MIB; it will change to
> > an OID field in the next version, which acts a little like
> > your enumerated types, but is extensible without modifying
> > the MIB.  BTW, this is a set of two attributes called DataDigest
> > and HeaderDigest; AuthMethod is something completely different.
> > All of the digest methods will be removed from draft-08 with
> > the exception of "none" and "crc-32c".  With the new OID scheme;
> > values for these can be added to your enterprise MIB if you
> > choose to implement them.
> > 
> 	[MHS]  If it will be OIDs, it's fine with me. I was
> inconfortable with simple strings.
> > > 
> > > 2. Add RowStatus and Read-Write Access to the portals and to the
> > > authorized list of initiators.
> > 
> > Which attributes to write and which rows to delete are currently
> > under consideration.  We are looking for detailed input on this.
> > 
> > Please send the list of attributes you wish to write, and why
> > you wish to write them.
> 	[MHS]  Mainly, we would like to add the type of access for each
> initiator: read-only or read-write.
> 
> > > 3. Add RowStatus to iscsiTargetAttributesTable in order 
> to allow an
> > > administrator to create target and
> > > set the access of the fields:     iscsiTgtName  and 
> iscsiTgtAlias as
> > > read-create
> > 
> > It's not possible to create an iSCSI target without first creating
> > a SCSI target.  I don't think we will be ready to explore this until
> > we have made progress on a SCSI MIB.  If you have some ideas on how
> > a management station would make use of this (with both 
> MIBs) to create
> > new targets, please send them.
> > 
> 	[MHS]  After having made some clarifications, I understand what
> you mean now.
> 	What is the status of the SCSI MIB? Is there any work done on
> the matter? 
> 	And at which organization?
> 	For our management we need the ability to create targets. What
> is your suggestion?
> 	(Apart of private MIB)
> 	I think that anyway we can allow to create targets via iSCSI
> MIB; it is MAX-ACCESS and it
> 	will be the responsibility of the implementation to update SCSI
> modules about new targets.
> 	Your opinion?
> 
> 
> > > I hope that you'll aggree to make the change,
> > > 
> > >         Michele
> > 
> > -- 
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> 	[MHS]  
> 	Again Thanks a lot,
> 
> 	Michele Hallak-Stamler
> 	Sanrad Intelligent Storage
> 	michele@sanrad.com
> 	972-3-7674809
>