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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 4 Sep 2006 11:48:32 +0200

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.

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

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

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

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

- 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
  }
 
Bert

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

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 4 Sep 2006 14:27:19 +0200

Inline

> -----Original Message-----
> From: Keith McCloghrie [mailto:[email-masked]]
> Sent: Monday, September 04, 2006 13:54
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [imss] WG last call: draft-ietf-imss-fc-rscn-mib-00.txt
> 
> 
> 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.
> 

Mmm.. I had not even considered that. That is, that the "persistent info"
can manually (or possibly by some other means, like CLI, NETCONF,
what have you) be changed. I guess such is always the case, in that
if we declare (in a MIB module) that data MUST be persistent/nonVolatile,
that some admin can come in and whipe out (or change) the file 
(or nonVolatile memory) that contains the "persistent data" 
and it is gone. This is true for all MIB modules we have defined, 
even for those that have a StorageType object inclued in a row.

What I had in mind was, that an implementation can decide to NOT save any
data (that has been changed via an SNMP-SET) in non-volatile memory. 
The desription clause does leave that open to any implementer.

I know this same sort of discussion has happened in other WGs.
And I would rather see a "must" than a "should" in the text.
But I am not gonna loose sleep if you keep it as is.

> I'll let Claudio and David speak to this.
> 

Would be good

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

But if they have it all say a few milliseconds apart, then several
hundred could get generated in 1 second?

The Transport ADs always worry about these aspects of notifications,
so to defuse any concern (valid in my view) they may have, I suggest
we think of some words to address those concerns.

> Now fixed in the source of all three drafts.
> 

thanks ;-)

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

OK. Might be good to state so in the DESCRIPTION clause of the object?
So that it is easier to see what sort of info is in there?
Up to you. I am happy to know that there is no special security concern.

> Right.  I've fixed this in my source.
> 
Ack

Bert
> Thanks,
> Keith.