Subject: RE: [imss]

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 18 Sep 2006 23:01:11 +0300

Keith,

There is a lot of good stuff in your answer and proposals that are
acceptable for me. 

I have only three comments in-line. 

Dan

> -----Original Message-----
> From: Keith McCloghrie [mailto:[email-masked]] 
> Sent: Monday, September 18, 2006 10:10 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [imss]
> 
> Thanks for the comments.  My responses below.
> 
> Keith.
> ---------------------------------
> 
>
> >  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'? 
- what happens if a write operation is attempted on t11FLockRowStatus
while  t11FLockInitiatorType ='cli' or 'ssb'?

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

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

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

Dan

_______________________________________________
imss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/imss