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

Re: snmpconf BCP re: policy layering

wft>Greetings all...


wft>-- We have had well over a year of this document being pored over without 
wft>this need for fundamental refinement.  Mind you, we've discussed this 
wft>taxonomy a lot, so it's not like people just never bothered to read that 
wft>far into the thing.  People smarter than myself like Joel Halpern, R. E. 
wft>Bob Moore, Jeff Case, and Dan Romanescu, who probably will forget more 
wft>about reference modelling in a bad week than I'll ever know, haven't 
wft>advanced or chimed in on this need for greater sophistication/complication 
wft>(although if you folks have just been watching this constructive debate and 
wft>avoiding comment, now's your time to jump in :).

first, thanks for the compliment

i have participated in behind-the-scenes conversations on this topic for
about a year but haven't said much, if anything, on this list about it

i guess i take your cue to jump in 

wft>-- I will advance (upon request :), how I think boring this out to be "two 
wft>dimensions" does in fact create a number of awkward "undefined" squares in 
wft>the matrix.  Briefly, I don't know what it means to have that which is 
wft>service-level-specific-without-regard-to-underlying-refinements *but* 
wft>instance specific, vs. that which is not.  And I wouldn't know as I sit 
wft>here now how to write text into the BCP to describe that.

i am not necessarily asking that you put out the extra effort to advance 
anything but i am unable to think of any examples where there are
"undefined" squares in the matrix unless both the instance independent
square AND the instance dependent square would both be undefined

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

:-) you get gold stars for remembering and acting on my request to 
disambiguate the steves ... i think they *_are)_* instance dependent
and i think your solution is better than calling them steve.1 and steve.2 :-)

thanks for doing that

wft>his argument he has made, this is the reason I don't see needing to uncork 
wft>this now to introduce this new ingredient.  With my name on the masthead, 
wft>though, I'm not an ideal source of refutation of the argument, and I'd 
wft>appreciate any other commentary on this which has been silently festering 
wft>so we can figure out how to deal with this one way or another and advance 
wft>this puppy.

this silent festerer generally agrees with joel, i.e., i think that
steve (w.) is headed in the right direction and that this is worth doing:

joel wrote:

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

yeah, what he (joel and/or steve w) said

(although i still don't know what odd dead boxes there might be [but i am
not trying to encourage a lengthy discussion of "old dead boxes" or
"undefined squares"])

best regards,