Subject: Re: snmpconf BCP re: policy layering

From: "Wayne F. Tackabury" <[email-masked]>
Date: Thu, 19 Jul 2001 15:27:11 -0400

Greetings all...

I'm wondering where we are at on this issue, as the discussion on it seemed 
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.  That 
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 contort 
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 significant 
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 in 
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 do.

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 in 
the taxonomy *including* the instance-specific notion here at Gold Wire for 
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 enterprise 
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 on 
my OSPF backbone area.  That is overriding my prior scope with values which 
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 for 
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 
prescribes.

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 it, 
long before I read or started my dubious editing contributions on the BCP.

I said earlier that I understand a difference in perspective between myself 
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 other 
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 not 
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 found 
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 reasons 
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 and 
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.  I 
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 of 
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 this.

Regards,
Wayne

--------

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 19 Jul 2001 17:13:22 -0400

Actually Wayne, I have spoken up on the list before.
In fact, while the early proposal was to treat "instance" as a completely 
orthogonal  dimension, the current proposal is more to make it separate but 
not necessarily universally applicable.  part of the point is that while 
making it universally applicable makes for odd dead boxes, the current 
approach does not allow for any combinations at all.
     I think that you actually highlighted why this separation is useful in 
your discussion.  It is very helpful for comprehensibility if the end MIB 
objects actually fit into the framework.  Leaving them completely out (as 
you suggest you did) leaves out the piece that an SNMP orient reader is 
going to need.
     Yours,
Joel M. Halpern

At 03:27 PM 7/19/01 -0400, you wrote:

>Greetings all...
>
>I'm wondering where we are at on this issue, as the discussion on it 
>seemed to die except for a lively discussion between myself, Steve (W.), 
>and Jon.
>
>a particularly meaningful abstraction without one significant 
>change.  That 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 
>contort 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 
>significant 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 in the face of where we stand now with the Best Current 
>Practices draft and moving it forward.
>
>one advances them to the iesg :), we have actually come to use the terms 
>in the taxonomy *including* the instance-specific notion here at Gold Wire 
>for 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 
>neighbor-hello-intervals and link metrics for OSPF for my entire 
>enterprise 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 on my OSPF backbone area.  That is overriding my prior scope 
>with values which are specific to an *instance* of the protocol--a 
>specific interface.  Hence, we have simply refined the specification to 
>that instance-level containment.
>
>that I've effectively "skipped" a level there, and did so intentionally 
>for 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 prescribes.
>
>policy-specificity-taxonomy from the very first time I even heard about 
>it, long before I read or started my dubious editing contributions on the BCP.
>
>I said earlier that I understand a difference in perspective between 
>myself 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 other 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.
>
>end-to-end circuit setup based upon QoS parameters, for example).  It's 
>not the *MIB Objects* (which act as parameters or output bindings to the 
>policy defined?  The answer, without failure in my experience, can be 
>found 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 
>reasons I find this need to expand the taxonomy at this time less than 
>compelling:
>
>(although if you folks have just been watching this constructive debate 
>and avoiding comment, now's your time to jump in :).
>
>own potential bolted-row-column to bolted-row-column interface 
>concerns.  I 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 
>of 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.
>

---

From: Steve Waldbusser <[email-masked]>
Date: Thu, 19 Jul 2001 20:29:54 -0700

Hi Wayne,

  I think your brief summary captures my concerns well.

Later, you said:

> this example.

Actually, I am completely comfortable with this.

I was puzzled when early on you expressed concern about the "dead-spots"
in the model, yet later you applauded the OSI model for allowing you to
skip layers. Aren't OSI's Session and Presentation layers "dead-spots"?

WRT policy modeling, I believe that there are 8 distinct categories into
which an object or operation could be placed. For each category, you can
find examples of things that fit in that category. If you took away any
of these categories, from time to time you would encounter something for
which no proper category applied. The point is that each is necessary.
For example in the text I submitted, I used "get ifInErrors.7" as an
example of a "domain-specific and instance-specific" operation. There is
no category in the BCP model that can contain operations like that.

Now that doesn't mean that every technology will have a component to go
into each box. For example, if you broke apart OSPF, maybe you would
only find things to place in 5 boxes. That doesn't mean the other 3
boxes aren't valuable to the taxonomy (just as you might not always use
OSI's Presentation and Session layers. In fact you applaud that you are
allowed to skip them. I notice that you aren't calling for them to be
eliminated because you personally haven't used them lately).

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

I like to apply the model to both MIB objects AND management operations.
You'll hear me talk a lot about MIB objects simply because they make
very useful examples. For example, the MIB2 examples I've used are a
common frame of reference because we are very familiar with their
semantics. All of this works for management operations as well even if
they are compound operations on many MIB objects or perhaps they don't
use SNMP at all.

Steve