Re: [imss]

Thanks for the comments.  My responses below.

Keith.
---------------------------------

> draft-ietf-imss-fc-rscn-mib-00.txt
> 
> 1. smilint complains about: 
> 
> mibs/T11-FC-RSCN-MIB:217: [1] {internal-other} parse error, unexpected
> LOWERCASE_IDENTIFIER, expecting '}' or ','
> mibs/T11-FC-RSCN-MIB:227: [5] {internal-flushing} warning: flushing
> recent incorrect declaration, see previous error(s)
> mibs/T11-FC-RSCN-MIB:170: [2] {type-unknown} unknown type
> `T11FcRscnStatsEntry'
> 
> All seem due to a missing comma in 
> 
> t11FcRscnSwRscnRejects             Counter32

Yes, we had already caught this.

>  2. 
>    Note that an interface's ifIndex value must be unique within an SNMP
>    context, irrespective of how many Fibre Channel management instances
>    (see below) and how many Fibre Channel switches are instrumented
>    within that SNMP context.
> 
> What do we exactly mean by 'SNMP context' ? I believe that the meaning
> is of a management domain modeled by SMIv2 MIBs or fiber channel
> management instance, not necessarily SNMP-related.

No, we mean exactly what is specified in RFC 3411, section 3.3.1.

> draft-ietf-imss-fc-fcs-mib-00.txt got it better, 'SNMP context' is only
> an example there. 

RSCN is missing a couple of common edits which were done for FCS & ZS,
i.e., both FCS & ZS have just the one reference to an SNMP context:

   "... for example within the same SNMP context ([RFC3411] section 3.3.1)."

In contrast, RSCN has two references to an SNMP context:

1. The same one as FCS & RSCN, except that it is missing the edit which
   inserted "for example".
2. The one in the paragraph you quote above.  This paragraph was written
   for a previous Fibre Channel MIB which IMPORT-ed ifIndex for use in
   INDEX clauses alongside index-ing objects for Fibre Channel
   management instances and Fibre Channel switches.  The intent of the
   paragraph is to clarify that an ifIndex value must be unique within
   an SNMP context even if that means it must be unique across multiple
   Fibre Channel management instances and across multiple Fibre Channel
   switches.  However, the paragraph is not needed in any of the FCS,
   RSCN or ZS MIBs because none of them have ifIndex in any INDEX
   clause.  This paragraph has already been deleted from the FCS & RSCN
   MIB documents.

So, there are two missing edits in the RSCN MIB document:
- insert "for example"
- deleted extraneous paragraph.

> 3. The Security Considerations section does not really provide an
> explanation about the hazards in intentionally or unintentionally
> misconfiguring the read-write objects (probably suppressing information,
> or flooding the network with undesired notifications) 

These notifications can't occur so often, and so I won't say "flooding".
But it's easy to add a sentence to say: 

   The object to enable/disable the notifications would, if
   misconfigured, either generate unwanted notifications or suppress
   wanted notifications.

While I think it's redundant, it doesn't do any harm.  So, I will add it.

> draft-ietf-imss-fc-fcs-mib-00.txt
> 
> 1. smilints returns 3 warnings: 
> 
> T11-FC-FABRIC-CONFIG-SERVER-MIB:773: [5] {index-element-not-accessible}
> warning: exactly one index element of row `t11FcsPortListEntry' must be
> accessible

This is a bug in smilint.  t11FcsPortListTable has only one columnar
object: t11FcsPortListIndex, and it is read-only.

> mibs/T11-FC-FABRIC-CONFIG-SERVER-MIB:80: [5] {type-without-format}
> warning: type `T11ListIndex' has no format specification
> mibs/T11-FC-FABRIC-CONFIG-SERVER-MIB:90: [5] {type-without-format}
> warning: type `T11ListIndexPointer' has no format specification

For both of these, RFC 2579 says:

   The DISPLAY-HINT clause, which need not be present, ...

and RFC 4181 says:

   The DISPLAY-HINT clause is used [...]  Its presence is optional.

> 2. Some of the read-write objects have no DEFVAL defined -
> t11FcsFabricDiscoveryRangeLow, t11FcsFabricDiscoveryRangeHigh,
> t11FcsFabricDiscoveryStart

RFC 2578 says:

   The DEFVAL clause, which need not be present, ...

The only change to this in RFC 4181 is a situation where DEFVAL MUST NOT
be used. 

>  draft-ietf-imss-fc-zs-mib-00.txt
> 
> 1. I was expecting the Security Considerations section of this document
> to include more details about the security issues related to the
> read-write objects in the MIB modules. While it is true that intentional
> or unintentional misconfiguration can lead to some kind of connectivity
> problems there are however differences in the level of threats generated
> by attacking fabric controls and generation of notifications. These need
> to be separately articulated IMO. 

So, how about I add:

 - the suppression of notifications (e.g., of unauthorized operations), and
 - the disruption of network operations due to the generation of unwanted
   notifications,

to the list of potential consequences ??

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

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

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

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

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