[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf BCP re: policy layering

Wayne and others,

While it's certainly a reasonable interpretation, and
operationally the only one you can make, in this case
silence on my part did not equal assent.  Instead, it
represented focusing on getting my own two Policy
drafts out by the deadline.

I don't know if it will advance the discussion or not,
but after this round of notes, I'm looking at the issue
in a slightly different light.  Before, I found myself
totally agreeing with Steve W.: *of course* class-level
information, of whatever level of abstraction and
standardization, is orthogonal to instance-level
information.  Now, though, it appears to me that we've
been talking about two very different things in
discussing the taxonomy.

To come at this in a roundabout way, I'll start with an
example from my SNA days.  (I'm sure there's something
equivalent in the IP world - I'm just not as familiar
with it.)  For a number of SNA configuration parameters,
it's possible to have node-level defaults, with port-
level overrides, and then link-level overrides of
either the node-level or port-level values.  Using some
convenient numbers, suppose we have an SNA node with
16 ports, where each port supports 4 links.  Now suppose
you have the following link configuration parameters
specified for a node:

   Node defaults:         C1
   Port-1 overrides:      C2
   Link-1.1 overrides:    C3
   Link-1.2 overrides:    C4
   Link-2.1 overrides:    C5
   Link-3.1 overrides:    C5,

where the links are identified as Link-<portNumber>.n.

Now, one way of looking at instances is that this node
has 64 link instances, with the following configurations:

    1 with C3 (Link-1.1)
    1 with C4 (Link-1.2)
    2 with C2 (Link-1.3 and Link 1.4)
    2 with C5 (Link-2.1 and Link 3.1)
   58 with C1 (all the rest)
   64 in all, which is what you *had* to have, because
there are 64 links in the box.  This is how Steve W. is
looking at the instances.

The other way of looking at instances is in terms of the
configuration (we might say Policy now) specifications:
node-level versus port-level versus *instance*-level.
In this case there are 4 instance-level specifications,
along with two higher-level ones.  This isn't quite
Jon's taxonomy, where it's levels of abstraction rather
than scope of applicability that work their way down,
in one dimension, to the instance level.  But I wonder
if there's been some element of this case that has bled
over into Jon's taxonomy?

When I started writing this, I wasn't sure where I was
going to come out.  It appears that I've come out
arguing for Steve W.'s two-dimensional taxonomy after
all, on the basis that Jon's version derives from a
confusion between two different one-dimensional
progressions: narrowing scope versus narrowing

Now, did any of this make any sense, and did it help?
I'm pretty sure I've gotten Steve W.'s version right.
But I'm not at all sure that I've captured what Jon
was saying.


Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group

"Wayne F. Tackabury" <wayne@goldwiretech.com>@snmp.com on 07/19/2001
03:27:11 PM

Please respond to snmpconf@snmp.com

Sent by:  owner-snmpconf@snmp.com

To:   snmpconf@snmp.com
Subject:  Re: snmpconf BCP re: policy layering

Greetings all...

I'm wondering where we are at on this issue, as the discussion on it

to die except for a lively discussion between myself, Steve (W.), and Jon.

To briefly summarize, Steve (W.) had a concern that the taxonomy as

presented in the most recent versions of the BCP lacked sufficient

sophistication, or rather, had an error in its relative

one-dimensionality.  Specfically, where the taxonomy listed the notions of

specificity at levels (from most general to least general): a)

service-level-specific, b) domain-specific, c) mechanism-specific, d)

implementation-specific, and e) instance-specific, Steve did not find that

a particularly meaningful abstraction without one significant change.

change is to take a) through d) above, and draw them into two categories,

being that content which is instance specific and that which is

instance-independent.  Steve (W.), I'm trying to be objective here, please

correct me if my summary of your point is inaccurate as presented.

For my own purposes, while I'll stipulate it's *possible* for me to

my mental model to adjust to this core redefinition or refinement, I don't

find it particularly useful or necessary.  I think it creates a

number of "dead spots" in the model matrix (to coin a phrase), and any

problems this "fixes" can be accommodated by relaxing any inferred or

explicit rules in how one interprets the model.  Let history record that

for just this once, I'm arguing the case for simplicity :), particularly

the face of where we stand now with the Best Current Practices draft and

moving it forward.

Now, I had a lengthy and illuminating one-on-one conversation with Steve

week before last on this topic and at the very least, I do understand one

reason he sees the world as defined by this taxonomy differently than I

Let me start with that difference in the Steve (W.) perspective from my

own.  To the extent one appreciates working deployment of practices before

one advances them to the iesg :), we have actually come to use the terms

the taxonomy *including* the instance-specific notion here at Gold Wire

the particular purpose for which I see this entire taxonomy as being most

directly pertinent.  That is, to describe the scope of policy content and

operational impact upon application of that policy.  To understand the

significance, imagine a policy-based configuration manager which is *not*

resident on a single managed element but on a server system which

transcends many managed elements and nodes (up to the point of the

snmpconf/pm-based architecture, I think this describes most

implementations).  So, I may have a policy that describes

neighbor-hello-intervals and link metrics for OSPF for my entire

as a default.  That is scope specific to a  mechanism (OSPF), under the

auspices of a greater domain (Intra-Gateway routing).  Now, I may have a

lower hello interval and higher link metric defined for those interfaces

my OSPF backbone area.  That is overriding my prior scope with values

are specific to an *instance* of the protocol--a specific

interface.  Hence, we have simply refined the specification to that

instance-level containment.

Now, if you buy this example, what Steve (W.) may get excited about :) is

that I've effectively "skipped" a level there, and did so intentionally

this example.  Specifically, there is nothing refined in an intermediate

"implementation-specific" way--I'm assuming that, e.g., the integers I use

for intervals and metrics will be portable between IOS and JunOS, I

suppose.  What I specifically see, however, is that there is nothing to

*preclude* the idea of a level of policy containment specificity being

"hopped" or "bypassed" in the spiral-of-specificity which the taxonomy


There is a lot of precedent for this.  The grandpappy of all taxonomies,

the OSI Reference Model, for all of its warts and bruises, does have

significant parallels (in specifying an application-level entity, how many

times do I completely bypass the presentation or session layers in

describing the instance architecture in OSI terms?).  For whatever reason,

I've been assuming this same capability was present in the

policy-specificity-taxonomy from the very first time I even heard about

long before I read or started my dubious editing contributions on the BCP.

I said earlier that I understand a difference in perspective between

and Steve (W.)--briefly, I now understand he wants the same taxonomy to

pertain to the very *MIB objects* acting as parameters to policy.  In

words (and he can explain this better than I), that ifInOctets is a rather

broad notion whose values are meaningless outside of the context of a

specific instance.

I have never tried to make this connection, perhaps just because I've been

living so long in policy-based configuration environments that are only

partially (if at all) SNMP based, and as I said earlier, those which

transcend the single managed element (consider *anything* needing to do

end-to-end circuit setup based upon QoS parameters, for example).  It's

the *MIB Objects* (which act as parameters or output bindings to the

policies) that I believe the taxonomy covers, however, it's the content of

the *policy* itself...in the network engineering sense, how broadly is a

policy defined?  The answer, without failure in my experience, can be

in one discrete value, or rather path of values to be formalized, from the

enumerated levels of the taxonomy.

Briefly, here's a few more practical and perhaps utterly subjective

I find this need to expand the taxonomy at this time less than compelling:

-- I personally have never needed to draw this to be such a "two

dimensional" distinction otherwise.  I warned you I'd be subjective. :)

-- We have had well over a year of this document being pored over without

this need for fundamental refinement.  Mind you, we've discussed this

taxonomy a lot, so it's not like people just never bothered to read that

far into the thing.  People smarter than myself like Joel Halpern, R. E.

Bob Moore, Jeff Case, and Dan Romanescu, who probably will forget more

about reference modelling in a bad week than I'll ever know, haven't

advanced or chimed in on this need for greater sophistication/complication

(although if you folks have just been watching this constructive debate

avoiding comment, now's your time to jump in :).

-- I will advance (upon request :), how I think boring this out to be "two

dimensions" does in fact create a number of awkward "undefined" squares in

the matrix.  Briefly, I don't know what it means to have that which is

service-level-specific-without-regard-to-underlying-refinements *but*

instance specific, vs. that which is not.  And I wouldn't know as I sit

here now how to write text into the BCP to describe that.

-- When in times of trouble, I draw on precedent.  My best precedent here,

the OSI (work with me on this one, OK? :), only had one legitimate case

that I recall for network functionality which truly "transcended" all of

the layers of the model, and whose absence really hurt the model.  As most

people here know, that was the network management "layer" which really

needed to be a bolt-on  column in the whole reference model and with its

own potential bolted-row-column to bolted-row-column interface concerns.

don't see anything in this instance-specific thing which bodes a similarly

profound resonance through the model.

Anyways, with all respect to Steve (W.) and the constructive advancement

his argument he has made, this is the reason I don't see needing to uncork

this now to introduce this new ingredient.  With my name on the masthead,

though, I'm not an ideal source of refutation of the argument, and I'd

appreciate any other commentary on this which has been silently festering

so we can figure out how to deal with this one way or another and advance

this puppy.

Sorry for the length of this, but it's hard to subdivide my arguments on




Wayne F. Tackabury              Internet: wayne@goldwiretech.com

Gold Wire Technology            Phone: (781) 398-8819

411 Waverley Oaks Rd., Ste 304

Waltham, MA  02452             Cell: (617) 699-6156