Re: [imss] WG last call: draft-ietf-imss-fc-rscn-mib-00.txt

[Keith McCloghrie <[e-mail]>]

> None of the below are fatal issues in my view (except for the
> missing comma, but that is easy to fix).
> 
> Some comments/questions:
> 
> - I see various objects like this one:
> 
>   t11FcRscnIlsRejectNotifyEnable OBJECT-TYPE
>     SYNTAX       TruthValue
>     MAX-ACCESS   read-write
>     STATUS       current
>     DESCRIPTION
>            "This object specifies if a t11FcRscnIlsRejectReqNotify
>            notification should be generated when this switch
>            rejects an SW_RSCN on this fabric.
> 
>            Values written to this object should be retained
>            over agent reboots."
>     DEFVAL { false }
>     ::= { t11FcRscnNotifyControlEntry 1 }
> 
>   Do we all think that "should be retained over agent reboots" is
>   good (and deterministic) enough? It is a lowercase should, and so 
>   any implementation that does not keep this over a reboot seems
>   still compliant. In other words, I have no deterministic way
>   at an NMS to figure out if this is persistent or not.
 
Some systems store this type of information in an ASCII-formatted
"configuration file" which they keep in non-volatile memory, but also
have the capability for the file to be reloaded at boot time.  One of
the reasons why such configuration files have typically (until recently)
been formatted in ASCII is so that they can be edited by an administrator
to change the parameters prior to the device dowloading it (but
presumably, the same can now be done with XML-formatted files and
XML-based editors.)  In such a situation, you are correct that there is
no deterministic way for the agent to tell an NMS whether the parameter
was persistent.

> - I also see a number of times a REFERENCE aka:
> 
>     REFERENCE
>            "ANSI INCITS xxx-200n, Fibre Channel - Link Services
>            (FC-LS), Rev 1.2, June 2005, tables 38 & 43.
> 
>   which I supposed is referenced by:
> 
>    [FC-LS]
>      "Fibre Channel - Link Services (FC-LS)", ANSI INCITS xxx-200n, Rev
>      1.2, http://www.t11.org/t11/stat.nsf/upnum/1620-d, June 2005.
> 
>   do we habve any idea when the   xxx-200n can be filled out?
>   it seems to me that this is a normative reference, no? 
>   so we need a stable doc to look at I think.
 
I'll let Claudio and David speak to this.

> - W.r.t. the notifications, I wonder if we (ever) run a risk that
>   an agent would send so many a to cuase congestion.
>   We do not seem to have a mechanism to control the amount of
>   notifications that can be sent/generated per second/minute/xx
>   Do we need one? If not, should we add some text to the DESCRIPTION
>   clauses of the NOTIFICATIOn-TYPE definitions to explain why an
>   agent would never generate more than x per second/minute/xxx?
 
It is hard to quantify them as "x per second/minute/xxx" but at most,
they would have a similar frequency to linkUp/linkDown.  Nevertheless,
one mechanism was added to reduce the number of notifications in a
specific situation; in particular, the t11ZsFabricIndex object was
defined with the additional value of 4096, such that it could be
included in this t11ZsMergeFailureNotify as described in the
notification's DESCRIPTION:

           If multiple Virtual Fabrics are configured on an
           interface, and all have a Zone merge failure
           at the same time, then just one notification is
           generated and t11ZsFabricIndex has the value 4096."

> - A real nit:
>   In the security considerations section:
>     Even if the network itself is secure (for example by using IPSec),
>   s/IPSec/IPsec/.
>   A while ago, this text was also in error in the security template
>   on the ops.ietf.org website. That has been fixed now as well.
 
Now fixed in the source of all three drafts.

> - Can the content of t11FcRscnRejectedRequestString have any specific 
>   sensitive of secret content? If so, then maybe we should elaborate
>   on that a bit in the security considerations. If not, then fine.
 
It's a list of port numbers of affected ports and/or an error code, and
in some cases the name and state of such ports.  So, no, I don't think
it has any specific secret content.

> - For completenes, here is a SMICng error that I reported ealier
> 
>    C:\bwijnen\smicng\work>smicng T11-FC-RSCN-MIB.inc
>    E: f(T11-FC-RSCN-MIB.mi2), (198,5) Missing comma between 
>    sequence items> 
>    *** 1 error and 0 warnings in parsing
> 
>   The missing comma should be fixed. It is in this table:
>   T11FcRscnStatsEntry ::= SEQUENCE {
>      t11FcRscnInScrs                    Counter32,
>      t11FcRscnInRscns                   Counter32,
>      t11FcRscnOutRscns                  Counter32,
>      t11FcRscnInSwRscns                 Counter32,
>      t11FcRscnOutSwRscns                Counter32,
>      t11FcRscnScrRejects                Counter32,
>      t11FcRscnRscnRejects               Counter32,
>      t11FcRscnSwRscnRejects             Counter32
>      t11FcRscnInUnspecifiedRscns        Counter32,
>      t11FcRscnOutUnspecifiedRscns       Counter32,
>      t11FcRscnInChangedAttribRscns      Counter32,
>      t11FcRscnOutChangedAttribRscns     Counter32,
>      t11FcRscnInChangedServiceRscns     Counter32,
>      t11FcRscnOutChangedServiceRscns    Counter32,
>      t11FcRscnInChangedSwitchRscns      Counter32,
>      t11FcRscnOutChangedSwitchRscns     Counter32,
>      t11FcRscnInRemovedRscns            Counter32,
>      t11FcRscnOutRemovedRscns           Counter32
>   }
  
Right.  I've fixed this in my source.

Thanks,
Keith.

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