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
imssietf.org
https://w
ww1.ietf.org/mailman/listinfo/imss