[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
snmpconf Comments on BCP-09
Here are some comments on the -09 version of the BCP.
Note, the document has been much improved from the
-05 version that I last reviewed.
Comments on draft-ietf-snmpconf-bcp-09.txt
1) the draft is significantly improved over the last version that
I reviewed. Note that I did not previously review the
policy or MIB module.
2) several places in the document are two spaces where a single
space should be. Need to do a search, to find them and then
fix the source document.
3) In section 1.2, the document states that the scale of networks
has increased, but gives no examples. I suggest the following
Scale - Networks have more network elements, and the network
elements are larger and place more demands on the systems
managing them. For example, consider the typical number and
speed of interfaces in a modern core network element.
In 1990, a core router might have 4 network interfaces
with two being 1.5m bits/sec WAN interfaces and the
other two being 10m bits/sec LAN interfaces. In 2002,
a core route might have 128 1g bits/sec
LAN interfaces and 64 155m bits/set WAN interfaces.
A managed metropolitan area network switch can have a port
density much greater than the port density built into the
expectations of the management systems that predated it.
There are also many more interrelationships within and
between devices and device functions.
4) The start of the third paragraph, change
"Management Framework is used successfully" to
"Management Framework has been used successfully"
5) the definition of "policy-based management (in middle of the
second para before section 2) doesn't seem too different
from non-policy-based management. I suggest that at least
it be modified to include the phrase "rule-based", as
"...is a methodology where rule-based configuration
information is distributed..."
6a) In section 3.3.1, para 5, second sentence is somewhat confusing,
since it is telling you what is wrong, but not telling you
what is correct.
b) in point 2, the second sentence reads pretty awkwardly.
7) There are extra lines after section 3.3.2 section head before
the section text.
8) In section 3.3.2, second para, the first sentence should be
changed to the following:
Fate sharing of SNMP table data should be explicitly defined
where possible using the SMI index qualifier AUGMENTS.
9) section 3.4.2, last para, makes a point that DNS names used
as an index don't create a potential problem. However, unless
the DNS definitions have been changed, DNS names can be
upto 128 chars (and maybe international char sets make this
worse). A DNS name consisting of close to 128 octets used
as an index would mean that the instance could not be specified.
This has a higher probability of a problem when two DNS
names are used in the index.
10) section 3.7, this discussion about persistence is not clear,
and it does not reflect reality. That is, when and how
"running" configuration is written to persistent storage
is very dependent on the system. Writing a table with
a "StorageType" object does not change the storage model
implemented in a device. Note the setting the value to
"nonVolatile" does not mean that the row will be written
to persistent storage before the operation returns. Also,
a implementation may not allow different rows to have different
This section is important, but also different types of
implementations have different models for managing
persistence of configuration data. This needs to be made
11) Section 3.10.1, second sentence, the term "context" is used,
but this sentence does not mean "SNMP contexts". Instead,
of context, the phrase "SNMP parameters as found in
table snmpTargetParmsTable from RFC 2573" should be used.
12a) Section 3.10.2, first para, first sentence, change "informs"
b) Second para, first sentence, change "InformRequests" to
c) Third para should be removed since it is just nonsense.
d) Fourth para, first sentence, change "of TRAP or InformRequest
PDUs" to "notifications".
13) Section 3.11, second paragraph, use of term "incumbent"
is not correct here. Not sure what is the main issue being
addressed here. In general, a management application must
understand the semantics of configuration (that is, the
management app must know what is valid and what is not
valid configuration settings) and only request configuration
settings that are believed to be valid and will succeed,
since the actual failure can not be determined from the
protocol returned error code.
14) Section 3.11, 4th and 5th paras, these look like that
they need to be combined.
15) Section 3.11, last paragraph is completely nonsensical.
16) Section 3.12, last para, reference to RFC 2591 is not correct.
Note that RFC 2591 (section 6) is incorrect (or at least
misleading) in its description that implies that VACM
provides per user access control. VACM does not provide
per user, but instead provides per group granularity.
This makes a difference, and renders the last paragraph
in section 3.12 pretty bogus.
17) Section 3.13.1, fourth para that starts with
"These informational object types...". Change to
"Such informational object types...".
18) Section 3.13.1, first para after definition of PortList TC.
Change the last word of the sentence of the para from "reset"
19a) Section 3.13.2, para 4 implies that only the table
entLogicalTable from the Entity MIB (RFC 2737) can be
used to discover values of ContextNames. However, the
table vacmContextTable from MIB module
SNMP-VIEW-BASED-ACM-MIB (in RFC 2575) provides a list
of ContextName values via object vacmContextName.
While there is not a pointer to items such as
entLogicalType (found in entLogicalTable), a management app
can probe each context name value to determine objects
for the context name value.
b) Given an update to talk about table vacmContextTable,
point #2 is incorrect.
c) the first para following the two points is nonsense.
Taken at face value, both points are incorrect.
20a) Section 4.2. This topic has already been covered. It is
incorrectly in the "agent implementation" section, since
it has nothing to do with agent design.
b) in the third para, the phrase "an inform" should be
replaced by "a notification".
21) Section 5.1.3, first para, says that an agent should
have the capability of sending a notification "whenever
a configuration operation is attempted or completed."
The "attempted" should be dropped.
22) Section 6.2, second para, the phrase "access control"
should be dropped because "authorization" is already
specified, and the two are the same.
23a) Section 6.3 should be titled "Authentication Notifications"
instead of "Authentication Traps".
b) The term "trap" should be replaced by "notification" in
all places in the text in this section.
24) Section 6.3, last sentence, repeats often incorrect
security warning. That is, it says to turn off generation
of authenticationFailure notifications because a
community string can be obtained by sniffing the
notification (sent using SNMPv1 or SNMPv2c). However,
this is just silly. First, the community string in
a notification should be different than that used
in GETs/SETs/etc. Secondly, if traffic can be sniffed,
then when a manager does a GET/SET/etc, a community
string can be obtained from any successful operation.
Don't repeat urban legends.
25) Section 7.1, first para, the grammar is broken here.
26) Section 7 in whole seems too wordy for what it's saying.
27) Section 8 - example MIB. This MIB is an example of how
not to write a MIB module!
28) MIB module, the value of the LAST-UPDATED and REVISION
clauses don't match. There is at least one REVISION
clause that is missing (and possibly a second). There
needs to be a REVISION clause that specifies when the
module was created. And there may be a REVISION clause
missing for the last update.
29a) MIB module, TC HvacOperation. This TC to be consistent
with the descriptor in the MIB module maybe should have
been named BldgHvacOperation.
b) It is strange that there is not the enum value 'off(3)'.
And there might need to be a value of 'fanOnly(4)'.
30) MIB module, object bldgHVACTable. Yes this is a example
MIB module, but the text of the DESCRIPTION that
describes to the reader about what is being done
should be removed and moved to an ASN.1 comment.
This is similar to showing an example C program
that contains the line like:
The comment for the line SHOULD NOT be "/* increment i */",
but should tell why this is being done.
There are several conventions for specifying what information
is in the DESCRIPTION clauses for tables and rows. One
of the best is that the table contains the following
1) a general description of the table
2) a description of the relationship to the number of
rows in the table with physical or logical items.
3) a description of the relationship, if any, to
For rows, the DESCRIPTION contains the following
1) a simple description of the table, like
"A row in the table of ...."
2) a statement that specifies whether or not rows can
be created and/or deleted via direct operations
to the table, and if so, then name of RowStatus
object (or for pre-RowStatus tables, then a description
of what is needed for creation/deletion). For
example, the DESCRIPTION may contain text like
"Creation and deletion are allowed via SNMP
operations controled by object xxxRowStatus"
31) MIB module. There are formatting problems that result in
text of the DESCRIPTION clauses to not be indented
32a) MIB module, object bldgHVACCfgTemplatePtr. It is not clear
why RowPointer is used instead of Unsigned32 (cloning the
data type of the index). The DESCRIPTION text is not
clear in what it is trying to say.
b) last paragraph in DESCRIPTION seems bogus
33a) MIB module, object bldgHVACFanSpeed. This object assumes
that the speed can always be determined. It doesn't allow
for cases when it cannot.
b) The last sentence in the DESCRIPTION is redundant with
the UNITS clause.
34) MIB module, object bldgHVACCurrentTemp. The lower range
only 0 degrees celcius. So can't get below freezing?
This is not too realistic.
35) MIB module, object bldgHVACoolOrHeatMins. This is a counter,
but no discontinuity object specified! Not sure that this
is a useful object. It would be much more useful to have
a total coolMins, total heatMins, a startTime, and value
36) MIB module, object bldHVACOwner. This is completely BOGUS
and a perversion of the RMON's OwnerStrings.
37) MIB module, object bldHVACStatus. The RowStatus TC has
requirements of what must be specified in the DESCRIPTION
clause. These requirements are not met.
38) MIB module. Table and row for TemplateInfo. DESCRIPTION
clause need to be fixed.
39) MIB module. Object bldgHAVACCfgTemplateInfoId. Couldn't
figure why this is needed.
40) MIB module, Object bldgHVACCfgTemplateInfoOwner. DESCRIPTION
41) MIB module, Object bldgHVACCfgTemplateInfoStatus.
42) MIB module. Table and Row TemplateTable. Same problem with
43) MIB module. Object bldgHVACCfgTemplateTable. The DESCRIPTION
contains "", which is not allowed. A useful name is
needed for the reference, since once the MIB module
is extracted from the MIB module, then what "" refers
to will be lost.
44) MIB module. Objects bldgHVACCfgTemplateDesiredTemp,
bldgHVACCfgTemplateInfoPtr. When they can be modified
MUST be specified in the RowStatus object.
45) MIB module. Objects bldgHVACCfgTemplateOwner and
bldgHVACCfgTemplateStorage. Same comments as similar objects.
46) Section 8.2, first sentence. Change "sample" to "example".
-- that's all
/david t. perkins