Re: [imss]

Dan,

> > >  draft-ietf-imss-fc-zs-mib-00.txt
> > > 
> > > 2. It is not clear to me how t11FLockTable entries work in 
> > the case of 
> > > a non SNMP lock creation. How is a new row protected so 
> > that it will 
> > > not be manipulated by CLI while in SNMP creation and the 
> > other way? If 
> > > there are some assumptions about a common underCreation state, they 
> > > need to be clearly articulated.
> > 
> > FC-GS-5 specifies how locks are created on receipt of an SSB, 
> > To avoid a conflict, the MIB needed to define how a lock can 
> > be created via SNMP, such that SNMP-management could modify 
> > the Zone Database without interference from the in-band 
> > management protocol, and vice-versa.  While defining a 
> > mechanism for SNMP, it seemed like a good idea to allow for 
> > locks by the CLI.
> > 
> > A row in the table for the CLI works in the same way as a row 
> > in the table for the in-band management protocol, i.e., if a 
> > row in the t11FLockTable is created by SNMP, its value of 
> > t11FLockInitiatorType = 'snmp'.  If a row has its value of 
> > t11FLockInitiatorType ='cli' or 'ssb', then it cannot be 
> > deleted by SNMP.  So, there are no "assumptions about a 
> > common underCreation state".
> 
> OK, I understand this better now, although it's not easy reading for
> somebody not familiar with T11.  Two questions though:
> 
> - is it that 'it cannot be deleted by SNMP' or 'it cannot be deleted or
> modified by SNMP'? 

You're right -- I should change the words in t11FLockRowStatus's
DESCRIPTION to say "modified or deleted".

> - what happens if a write operation is attempted on t11FLockRowStatus
> while t11FLockInitiatorType ='cli' or 'ssb'?

An instance of t11FLockRowStatus *can* be deleted/modified under other
circumstances, but not while the value of t11FLockInitiatorType in the
same row has the value 'cli' or 'ssb'.

So, it would be more precise for the DESCRIPTION to say:

           A row of this table can be modified or deleted via this
           object only when the row's value of t11FLockInitiatorType
           is 'snmp'."

> > > 3. I do not have the T11 reference at hand, but I wonder 
> > why objects 
> > > like t11FLockRejectReasonCodeExp have a SYNTAX of OCTET 
> > STRING. In any 
> > > case, I would suggest a DISPLAY-HINT clause for these.
> >  
> > t11FLockRejectReasonCodeExp is a 1-byte hexadecimal value, 
> > with an ASCII string associated which each assigned value to 
> > indicate its meaning.
> > So, if the list were stable, this would be an enumerated INTEGER.
> > However, new reason codes get defined periodically, and it's 
> > unlikely that this WG will get re-chartered frequently enough 
> > to keep the enumerated values listed in the MIB uptodate.  
> > Nor do we want to impose a burden on IANA to assign new 
> > values, when new values are already being assigned in T11 and 
> > documented in T11 specifications.  Instead, the object has 
> > been defined an an "OCTET STRING (SIZE(1))" with a REFERENCE 
> > clause which points to the most recent spec for assigned values.
> > 
> > So, I think that if anything is missing here, it's that there 
> > is no explicit indication in this MIB that values which will 
> > not yet assigned but will be assigned in future revisions of 
> > the Fibre Channel spec will then be valid in this object.  
> > Would you like me to append to the REFERENCE clause, something like:
> > 
> >          ... or its successor"
> 
> Obviously there is a slight interoperability problem here, and I am not
> sure that the IESG would like such a solution. Where does someone need
> to look to see what is the more recent successor? Would not the overhead
> of an IANA maintained TC be justified for such a case? 

No, I don't believe so.  A user who can't find the latest T11 spec, is
not going to know what a new reason code means anyway.  This is the
equivalent of an Internet user who can't find the latest RFC.  With the
current definition, IANA is not involved.  Getting IANA involved is not
only extra overhead, but it also increases the need for coordination,
and consequently, it increases the chance of a screw-up in the
coordination of changes between multiple organizations.

The way that it is defined at present is simple, and that's good :-).

> > In regard to a DISPLAY-HINT, there are two possible ways to 
> > display a value of this object: either as a hex value, or as 
> > the relevant ASCII string from the T11 spec.  My preference 
> > is for the ASCII string, but there's no way to express that 
> > in a DISPLAY-HINT, and a DISPLAY-HINT is optional.  Do you 
> > want me to add some text to the DESCRIPTION clause to explain this ??
> 
> One more reason to use a TC. 

I see the opposite, i.e., the fact that a DISPLAY-HINT is not rich
enough to express the desired hint is one more reason not to use a TC.

> > > 4. In T11ZoningName, what does 'letter' mean - ASCII only or 
> > > internationalized as in SnmpAdminString?
> >  
> > The REFERENCE clause points to section 6.4.8.1 of FC-GS-5, 
> > and section 6.4.8.1.2 says:
> > 
> >    The Name Value field shall contain the ASCII characters 
> > that specify
> >    the name, not including any required fill bytes. Names shall adhere
> >    to the following rules:
> >     ...
> >     c) The first character of a given name shall be a letter. A letter
> >     is defined as either an upper case (A-Z) character or a lower case
> >     (a-z) character; and
> >     ...
> 
> Can we copy this text here? I believe that it's better to be redundant
> then use such a common noun as 'letter' and assume that the writer of a
> future application will read the reference. 

The only information in the text I quoted, that's not already in the
DESCRIPTION is the fact that it is an ASCII letter.  So, yes, I'll
change "letter" to "ASCII letter" and then it will no longer be a
common noun.

Keith.

_______________________________________________
imss mailing list
imss@ietf.org
https://www1.ietf.org/mailman/listinfo/imss