[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
snmpconf Changes to bcp -06 draft suggested (lengthy)
A few weeks ago, I had the opportunity to really sit down with the BCP and
give it a clean room read for the first time since probably last
February. There are a number of places I saw a rather compelling value for
certain changes, primarily for readability, focus, and smoothness.
What follows is an exacting list of those changes as I see them to
date. Note that while I *was* influenced on a certain points from informal
conversations with David Perkins, I intentionally did not read his list of
concerns about the BCP before i put this together (per agreement with
David). About 70% of the following *is* in some agreement with things
David raised (once I read his list of concerns). In all cases, I tried to
make the recommendation as specific as possible (i.e., it would have been
about 10 times easier to just revise the doc directly, but i wanted to call
these out. :)
These are also separate from prior -06 mods recommended by Mike MacFaden
and John Schnizlein which are already accepted in my running copy of the
I will actually follow up with the points where David and I differ based on
his list of concerns subsequently, just to get group discussion going on
those where applicable...
In cases where there are a variety of small
changes on a page which I don't think are in fact controversial, I'll
aggregate them in one comment (e.g., "Tighten up sentence structures
throughout section x.y").
Page 2: I've always been a bit uncomfortable with the generalizations
in these paragraphs, so to greater focus this, my *added text*
(indicated thusly) du jour are:
...the network elements are larger *and place more demands
on the systems managing them*.
...number and speed of interfaces. *For example, 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 them*.
...is a prerequisite to the successful deployment of the services
*which they are used to implement*.
The transition to the last sentence on page 2 seems awkward. Perhaps
include a sentence:
...public and private data networks with SNMP. *Somewhat
independent of the lessons learned about SNMP over this time,
practices in configuration management have evolved to facilitate
greater scalability and integrity of the management structure as a
whole.* Policy-based configuration management is a methodology....
(this somewhat focuses to address the concerns of John Schnizlein along
the lines of "how can you talk about SNMP policy based configuration
when it doesn't have a significant base of identifiable practice to
speak of" [paraphrasing]).
Page 3: The whole structure of Sec. 2.1 could use some work. One broad
possibility is to move everything but the first paragraph to the section
much later in the document on RowStatus usage. It's a bit odd more is
said about row status here than in that section.
So, regardless, this needs tightening. I'd rewrite the second two
paragraphs as follows (flowing through to p. 4)
MIB Module Design plays a significant role in how well SNMP
transaction integrity will work. The Structure of Management
Information Version 2 (SMIv2 -- RFC 2579 ) defines textual
conventions that help support the definition of transactional
boundaries for configuration actions. The RowStatus object, which
defines a standard object for the management of conceptual rows
in a table, is one example. When a RowStatus object is moved to
the 'active' state, the entire row is 'committed'.
Page 4: Then, keep the next two paragraphs (beginning "In a multi-table
scenario..."). Drop the final paragraph ("A well designed SNMP-based
management system...") as unneccessary and gratuitous.
A few transition elements and prepositional phrases for Point 1) under
Let's go back to my comments on the RowStatus discussion of pp. 2-3. I
could see moving that whole section to a Section 2.2.1 here, titled "An
Example: Row Status".
In Sec. 2.3, the more I read it, the more the word "debugging" seems out
of place here and highly ambiguous. Try a revised first sentence of
*Verification of expected behavior prior to the commitment
of change* is an integral part of the configuration process.
Last sentence of next-to-last paragaph on p. 5 suggested to change to:
Debugging *the unintended effects of* two sets of changes in
large systems is often more challenging than *a post-mortem
analysis on the effects of* a single set.
(because thusly refined 'debugging' makes sense in that context).
Some serious surgery on the last paragraph on p. 5 going forward. In
the first place, the dot3TestLoopback doesn't seem like a useful object
to be discussing here and is just confusing. The context up to this
point was discussing multi-element transationality, and this has no
relevance. I'd lose it, and tighten to the subsequent discussion of
ospfSpfRuns as follows:
Networks and devices under SNMP configuration readily
support this change management procedure since the SNMP
provides integrated monitoring, configuration and
diagnostic capabilities. *The key is the sequencing
of SNMP protocol operations to effect an integrated
change procedure like the one described above. This is
usually a well-bounded affair for changes within a single
network element or node. However,* there are times when
configuration of a network element can impact other elements...
(joining with the first full pararaph of p. 6).
More text to flesh out relevance of the example provided. Following
the citation of ospfSpfRuns, insert:
These are examples of object types whose monitoring subsequent
to a configuration change of related control object
instances provides a crucial verification determinant. After
a convergence (of 802.1d or OSPF Spanning Tree, respectively), a
successful change should nat bring about a perturbation of the
object instance values, relateive to those observed values seen
in the pre-configuration-change instance monitoring.
About five other small changes to this page to smooth awkwardness.
This is the first place where the use of the naked word 'object' rather
than explicit clarification of 'object type' or 'object instance' starts
standing out (yes, I was somewhat influenced to look at this from my first
phone conversation with Dave Perkins. :). I spent some time tooling
around other IESG-approved MIB documents, and I noticed that a lot of
times, the specific qualification of 'object type' or 'object instance'
is established, and then the use of the less exact reference 'object'
shows up in a subsequent sentence, having its context established. We
have a similar conundrum with the use of the inexact word 'MIB' as opposed
to the more qualified term 'MIB Module'. Since we spent a lot of energy
making sure we were language-correct on this latter point, there are a lot
of places in the following pages where the term 'object' will be replaced
with 'object type' or 'object instance' for clarity and technical
Revise first sentence as follows:
Well-considered MIB module designs are crucial for practical
configuration with SNMP. As we have just seen, MIB modules for
configuration can be very effective since they can expose
integrated diagnistic, monitorin, and fault object types.
MIB modules for configuration also scale when they expose
their notion of policy object types. Policy objects can represent
information at a higher level of abstraction than instance-
Combine first two paragraphs of Sec. 3.1. (Current) third paragraph of
3.1, start with "However, it is important to...".
Space between "over the past 8 years" paragraph and numbered list.
Start of 3.2 changes to: "Naming of MIB module and object types informally
Changes of term 'object' to 'object type' variously throughout 3.2.
Second full sentence on this page changes to: "First, for those that do
look at instances of MIB objects, names as seen through MIB browsers
or other command line tools completely convey the meaning of the
First sentence changes to: Such objects *can* cause all pending
Usage of MIB *instance* inserted variously into 3.3.3.
End sentence at 'To make this process simple and efficient' with a colon,
and space before numbered list.
Space between paragaphs surrounding hrSWInstalledLastUpdateTime citation.
Paragraph after ifTableLastChange citation, last sentence change from
"so caching will work" to "so the caching procedure can maintain
Paragraph after next, change to:
*When doing so, it is optimal practice to8 use an inform instead of a trap
Next paragraph, change start to
*However*, the use of notification *events* to communicate...
More qualifications of 'object' term.
Paragraph which begins "Associative indexing", change 'say' -> ', for
More qualification of 'object instance'.
First paragraph, parenthesize end, i.e., "...Page 41 (the section on Host
Add sentence to end of first paragraph:
...can be avoided via effective MIB *module* design. *In other
words, object types requireing this kind of transfer size should
be used judiciously, if at all.*
Next paragraph, need a referencce for REMOPS-MIB, with an excerpted
citation (I've tried to have a citation for any document referenced
Section 3.3.6, change header to "Conceptual Table *Row* Modification
Section 3.3.6, subpoint 2. Add sentence to end:
Where this restriction exists on an object, it should be made
clear in the DESCRIPTION clause as follows:
Section 3.4, there is another section on index design (I forget where
now) which should be cross-referenced.
Sec. 3.4.1, third paragraph, "protocol expansion" -> "semantic expansion'.
Sec. 3.7, objects -> object types.
After first full paragraph: Provide an example of how to assert that
persistent store has been committed.
End of 3.7 -- provide a citation from scheduling MIB to illustrate
Sec. 3.8: completely lose reference to IP version 4 routers reference (oh,
wait, that's already done in my running -07 draft from Mike's comments :).
First full text paragraph--lose 'which' at end of final sentence ('RFC
Final sentence of 3.8: 'Lastly' -> 'Finally'.
End of sec. 3.9, provide an example of how to detect the 'installed'
command. Hey, what does 'command' mean in this context anyways?
Sec 3.10.1: Lose the first sentence.
Page 26: Sec 3.10.2: provide an example of RFC 2573 usage in this regard.
Page 27: hrPrinterDetectedErrorState: how is it useful? This seems like
an object type somewhat unrelated, really, to 'error state'...this is
about how to determine the disposition of print jobs. Isn't there a
table-row-value-disposition type of object somewhere we could extract?
Sec 3.11.1: reference problem already noted with generation of huge object
instance data returns.
Point 2, '*The second ingerface is between* the agent and the instrumented
subsystem. And, at the end of this, some mention of what happens or can
be designed into an agent which knows the resident subsystem can't be
idemopotent in its acceptance and activation of the configuration.
Sec. 4.2, thir paragraph.--shouldn't an inform, where possible, reference
the source of the update to accomodate this point?
Sec. 4.3--I'm wondering whether this whole section shoudn't be in Sec. 3.
The primary points are about MIB module design, and the only mention of
'agent' refers to its ability to use a designed-in OwnerString.
Sec 4.6, add final sentence: "But, regardless of the approach, the return
of the read of such an object instance should be meaningful in the context
of the object type semantics".
Sec. 5.2--the beginning is tending to drift from management application
relevance here. An opening sentence to frame it in that relevance?
I think the subsequent sections should actually be subheaded under 5.2.
I think maybe they were once and we just screwed up in the NROFF header
Sec 5.3 -> Sec. 5.2.1
Sec. 5.4 -> 188.8.131.52
A few word changes elsewhere.
Before 'Notifications' section: Mention to pay attention to hints
and remedies provided in MIB modules if designed to conform to section 3.
Sec 5.5 -> 5.2.2
Sec 5.6 -> 5.2.3, and change title to 'Scalability of Data Retrieval'.
First paragraph, 'SNMP transactionality' -> 'techniques for
transactionality in SNMP'.
Section 6.2: Shouldn't this be in Section 4? Mea culpa, I'm the one that
put this here, I know.
Provide a reference (RFC 2669?) to the object cited. Also, this may be
technically inaccurate, since this MIB was designed fully aware of the
security abilities of SNMPv3 (it's in the 'Security Considerations'
section, I know). Perhaps a better way to present this object is to
provide a revised object type def. that more clearly references a VACM
Sec. 7: Last two sentences should be a in a separate paragraph.
Before section 7, there should be a short definition of policy as it
pertains to the following section. I don't think it should force the
reader to trudge off to the policy framework documents (although it can
reference them), so as to come up with a self-contained little two
sentences for the reader who asks 'what do you mean by policy?'. (I know
this may be an emo-politically charged suggestion :). *Then* section 7.1
should be able to pick up from there by saying, in essence, "We have just
explored the current focus of policy initiatives in the IETF and
elsewhere, and here is why they are important to configuration'. It makes
these sections flow better and have better background.
End of first paragraph "...values to the selected ports *as groups*."
Next paragraph should begin "To date, *this kind of large-scale*
configuration has been accomplished...".
Add sentence to final paragraph of Sec. 7.1: "But, other entity
management systems have been employing these kinds of techniques
end-to-end for some time, in some cases using SNMP, in some cases using
other encodings and transfer technologies."
The part of this section which looks like it wants to have its own section
header: "Changes to Configuration outside of the policy system"...I think,
should. :) I'd vote for
7.4.1 Configuration Activity Out-of-Band to Policy
It is essential to consider changes to configuration outside of the
policy system. A goal of SNMP-based policy management...
Sec. 7.5: Change title to "More About Notifications in a Policy System".
Sec 7.6, mention the notion of 'summary objects' as discussed in sec. 3,
here at the end.
Error in MODULE-COMPLIANCE, should reference 'bldgHVACObjectsGroup' in
the GROUP clause.
Wayne F. Tackabury Internet: email@example.com
Gold Wire Technology Phone: (781) 398-8819
411 Waverley Oaks Rd., Ste 304
Waltham, MA 02452 Cell: (617) 699-6156