Subject: snmpconf taxonomy discussion(s) - suggested resolution

From: David Partain <[email-masked]>
Date: Fri, 17 Aug 2001 17:08:17 +0200

Greetings,

Over the last few months, there has been long discussions
about two particular issues:  the taxonomy discussion in the
BCP and the pointer to it in the policy MIB document.  A few
things have become plain to me during this discussion:

 - I suspect that there is a very small number of people who
   understand what the taxonomy issue is all about.

 - The "camps" (for lack of a better term) are not any closer to
   reaching agreement on the taxonomy now than they were at the
   beginning of the discussion.

 - No one else is about to jump into the middle.

 - There is significant work being put into something which is,
   in the end, and example of how to talk about policy.  As such
   I am having a difficult time seeing that it warrants this
   level of attention or contention.

As I think this is true, I would strongly recommend that we:

 - Remove the taxonomy section from the BCP entirely.

 - Remove references to the BCP taxonomy section in the PM
   document.

This will enable us to move the BCP forward by removing the
single most contentious issue as well as close some PM issues
that remain.  And, I believe, we don't really lose anything
other than an example.

I strongly believe we are spinning our wheels on this issue
and want to move on.

I know that Jon agrees with this suggestion and would very
much like the working group's opinion.

Cheers,

David Partain

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 17 Aug 2001 11:53:27 -0400

I agree.

---

From: Steve Waldbusser <[email-masked]>
Date: Fri, 17 Aug 2001 09:31:58 -0700

I agree.

Steve

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 17 Aug 2001 12:31:58 -0700

HI,

If the taxonomy is removed, the resulting document, is not a BCP and 
needs much work. I work closely
with one of the co-authors (Mike MacFaden) and have pointed out to him
many problem areas. He agrees that there are problems. He is vacationing
this week and should be back on Monday. We can discuss an action plan
when he returns.

On the SNMP Policy issue, I've been reading all that I can about policy.
(It's not too entertaining (sorry Bob Moore, Andrea, etc), so it is taking
a long time to get through.) I believe that it is very important to
take the existing documents and provide an SNMP-based interpretation
of them. For example, just yesterday the ID 
"draft-ietf-policy-qos-device-info-model-05.txt" was announced. It
and the other policy documents are based on an "LDAP-view" of
specifying policy for QoS. However, an SNMP-based interpretation 
and translation can be easily made of this document and others
(of course it would take some time because the document 
is 80+ pages long, and the others are also big documents). 

The documents to be recast in an SNMP-based approach include:
  RFC 3060 - Policy Core Information Model
  ID "draft-ietf-policy-pcim-ext-02.txt" - Policy Core
     Information Model Extensions
  ID "draft-ietf-policy-terminology-04.txt" - Policy Terminology
  ID "draft-ietf-policy-qos-info-model-03.txt" - Policy Framework
     QoS Information Model
  ID "draft-ietf-policy-qos-device-info-model-05.txt" - Information
     Model for Describing network Device QoS Datapath Mechanisms
  and maybe some others...
  
Regards,
/david t. perkins

>much like the working group's opinion.

Regards,
/david t. perkins

---

From: "Wayne F. Tackabury" <[email-masked]>
Date: Fri, 17 Aug 2001 17:24:44 -0400

Hi David...

At 12:31 PM 8/17/2001 -0700, David T. Perkins wrote:
>needs much work.

Hmmmm....do you mean that the inclusion of the taxonomy in and of itself is 
the crux of making it suitable in your opinion?  Your next statement makes 
me wonder if you're trying to identify broader concerns you have (but that 
doesn't jibe with how I parse your prior statement :).

>  I work closely

Unless he's changed his mind since last week, he's in favor of excising the 
taxonomy section given where we're at now.

>of them.

Well, a very strong objection has been raised to the limited degree to 
which the taxonomy attempted to do just that, which is one of the major 
reasons we're chucking it.  There is not a great degree of experience we 
can speak of in policy-based-configuration-using SNMP (the qos device and 
network information model documents do not, to the best of my knowlege, 
describe a shipping implementation of anything in commercial use, but a 
proposed pcim-consistent information architecture with qos as its primary 
domain of current applicability).  So, said objection-holders would say, 
how can a discussion of policy here be a "best current practice"?  Based on 
extensive discussions I've had with Mike McF. in the preparation of this 
document, I believe he was struggling with that very view himself.

On the other hand, I'm not sure the PCIM was an RFC at that point 
either...but based on discussions with him in London, I know Mike was an 
adherent for removing the section in the interests of focus and consensus.

Inasmuch as IETF-based SNMP policy configuration technologies are 
concerned, PM is it at this point in history.  Since the snmpconf pm draft 
is being advanced at the exact same time as the BCP, one can definitely 
argue (and they have, to me) that calling on it for experience of a "best 
current practice" is inflating the term more than a little.

Regards,
Wayne

P.S.: By the way, the reason I found the policy fwk documents 
excruciatingly difficult to get through was the lack of a roadmap--they 
require a quite recent understanding of diffserv, and the DMTF network 
information model deepthink documents are pretty required reading.  Even 
then it's difficult to find the right balance of essential theory and 
direct applicability in the policy wg docs as you read through them (I 
needed a cold shower after the PCIM).  The only way I found to overcome it 
was to do a complete loop of reading everything *twice*, and I'm still just 
conversant enough to be dangerous in nondiscriminating crowds. :)

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 17 Aug 2001 15:12:39 -0700

HI,

Sorry for mixing two issues together. Thanks Wayne F. Tackabury for
pointing this out.

1) I believe that there should be a "an SNMP-based framework for policy"
   document, which is informational. That is, don't just throwaway the
   taxonomy. However, use the existing policy documents are are LDAP
   based and convert them (doesn't need to be a one-for-one conversion)
   into documents that are SNMP-based.

2) Take the portion of the document that contains suggestions for
   creating and using configuration objects and create an
   informational document, and clean it up.    

Regards,
/david t. perkins

---

From: Jon Saperia <[email-masked]>
Date: Wed, 22 Aug 2001 19:20:52 -0400

>    informational document, and clean it up.    
I think we have a critical mass of information on the creation
management systems and mib objects (standard and private) to justify the
term bcp on the document under discussion. That is what you are left
with after we remove the taxonomy section.

Thanks,
/jon
--

Jon Saperia		     [email-masked]
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/

---

From: David Partain <[email-masked]>
Date: Mon, 27 Aug 2001 10:27:41 +0200

Hi all,

Regarding my suggestion to remove the taxonomy from the BCP
as well as references to it in the PM MIB, I believe that
everyone's had a chance to object and no one has.

The Gavel Bangs.  Done.  The editors understand the edits :-)

Cheers,

David & Jon

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 27 Aug 2001 10:18:36 -0700

HI,

I'm not sure what is really to happen...
There are comments as to what the resulting document
should be, and that does not appear to be addressed
by the announcement by the chair.

I suggest that that resulting document be an Informational
document or possibly even Experimental, with title
"Suggestions for Designing MIB Modules
to Allow Configuration Management via SNMP Operations".

The document is not a BCP, since it suggest approaches, many
of which are not used in MIB module design.

Regards,
/david t. perkins

---

From: Jon Saperia <[email-masked]>
Date: Mon, 27 Aug 2001 13:42:35 -0400

David, the working group had a discussion of whether to call this a BCP. in 
March. At that time we did not find a compelling reason to change it. Unless 
you can find some compelling reason that convinces the working group to the 
contrary we will issue it for last call as a BCP.

It reasonably falls into section 5 of RFC2026 which describes a BCP document. 
There are extant BCPs whose nature is how to apply a protocol or standard. 
That is what this is.

/jon

Thanks,
/jon
--

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 27 Aug 2001 11:55:53 -0700

HI,

Jon - would you summarize the pros and cons for BCP categorization.

At 01:42 PM 8/27/2001 -0400, you wrote:
>...

Regards,
/david t. perkins

---

From: Jon Saperia <[email-masked]>
Date: Mon, 27 Aug 2001 15:01:30 -0400

> Jon - would you summarize the pros and cons for BCP categorization.

I think I have. The document falls within the guidelines suggested by  2026. 
Can you make a compelling case why the document should not be a BCP?
/jon

Thanks,
/jon
--

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 27 Aug 2001 12:35:42 -0700

HI,

Jon - would you like to try again with content this time FROM THE
WG discussion. I'm not asking for YOUR OPINION (you have already
voiced it). I was asking for a summary of the WG opinion, which
is the ONLY THING that matters.

Regards,
/david t. perkins

---

From: Jon Saperia <[email-masked]>
Date: Mon, 27 Aug 2001 16:03:03 -0400

Cehck the archives.
/jon

Thanks,
/jon
--