Subject: RE: [imss]

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 19 Sep 2006 08:33:11 +0300

Keith,

OK with me by now. The only issue I am not 100% comfortable yet is the
syntax of the reason code objects, but I would say that we discussed
this enough for this stage. Later reviews with the MIB doctors and IESG
will prove if the current proposal holds water from the point of view of
operability and extensibility. 

Dan

> -----Original Message-----
> From: Keith McCloghrie [mailto:[email-masked]] 
> Sent: Tuesday, September 19, 2006 4:59 AM
> To: Romascanu, Dan (Dan)
> Cc: Keith McCloghrie; [email-masked]; [email-masked]
> Subject: 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/imss