Subject: snmpconf Changes to bcp -06 draft suggested (lengthy)

From: "Wayne F. Tackabury" <[email-masked]>
Date: Mon, 01 Oct 2001 16:09:10 -0400

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

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

Next paragraph:
         ...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 [5]) 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
Section 2.2.

Page 5:

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

Page 7:

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.

Page 8:

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

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

Combine first two paragraphs of Sec. 3.1.  (Current) third paragraph of
3.1, start with "However, it is important to...".

Page 9:

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

Changes of term 'object' to 'object type' variously throughout 3.2.

Page 10:

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

Page 11:

First sentence changes to: Such objects *can* cause all pending
transactions...

Usage of MIB *instance* inserted variously into 3.3.3.

Page 12:

End sentence at 'To make this process simple and efficient' with a colon,
and space before numbered list.

Space between paragaphs surrounding hrSWInstalledLastUpdateTime citation.

Page 13:

Paragraph after ifTableLastChange citation, last sentence change from
"so caching will work" to "so the caching procedure can maintain
synchronization".

Paragraph after next, change to:

*When doing so, it is optimal practice to8 use an inform instead of a trap
notification..."

Next paragraph, change start to

*However*, the use of notification *events* to communicate...

More qualifications of 'object' term.

Page 14:

Paragraph which begins "Associative indexing", change 'say' -> ', for
example, '.

More qualification of 'object instance'.

Page 15:

First paragraph, parenthesize end, i.e., "...Page 41 (the section on Host
Group indexing)."

Page 17:

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

Section 3.3.6, change header to "Conceptual Table *Row* Modification
Practices".

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.

Page 18:

Sec. 3.4.1, third paragraph, "protocol expansion" -> "semantic expansion'.

Page 20:

Sec. 3.7, objects -> object types.

Page 21:

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

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

Page 23:

First full text paragraph--lose 'which' at end of final sentence ('RFC
2579 states...').

Final sentence of 3.8: 'Lastly' -> 'Finally'.

Page 25:

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?

Page 28:

Sec 3.11.1: reference problem already noted with generation of huge object
instance data returns.

Page 31:

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.

Page 33:

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

Page 34:

Sec. 5.2--the beginning is tending to drift from management application
relevance here.  An opening sentence to frame it in that relevance?

Page 35:

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

Sec 5.3 -> Sec. 5.2.1
Sec. 5.4 -> 5.2.1.1

A few word changes elsewhere.

Page 36:

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

Page 39:

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.

Page 40:

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
structure/teble entry.

Page 41:

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.

Page 42:

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

Page 43:

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

Page 45:

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

Page 46:

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.

Page 57:

Error in MODULE-COMPLIANCE, should reference 'bldgHVACObjectsGroup' in
the GROUP clause.

--------

Wayne F. Tackabury              Internet: [email-masked]
Gold Wire Technology            Phone: (781) 398-8819
411 Waverley Oaks Rd., Ste 304
Waltham, MA  02452             Cell: (617) 699-6156