> 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
> ::= { 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://w
ww.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
imss ietf.org
https://w
ww1.ietf.org/mailman/listinfo/imss
|