Subject: Re: snmpconf Comments on the BCP

From: Andy Bierman <[email-masked]>
Date: Sat, 06 Oct 2001 13:19:52 -0700

At 03:18 PM 9/28/2001 -0700, David T. Perkins wrote:
>HI,

First I read draft-ietf-snmpconf-bcp-06.txt.
Then I read Dave's comments on -05.

I have to agree with Dave on many points, especially the general comments.
I think it would be difficult (at best) for a non-expert to easily 
understand how
to better design or implement any component of an SNMP-based management system,
after reading this BCP.

I think sections 2 and 3 should be rewritten to improve clarity and focus.
There are many pearls of wisdom buried in way too much text. There
are obscure examples, 'dangling examples' that are unexplained, and
unanswered questions raised throughout these sections.  However,
these 2 sections have a lot of potential value to the reader, and
also contain the kind of info that actually belongs in a BCP.

Section 4 could also use some major edits for clarity and focus.
There seems to be a lot of text about MIB design in some sections,
and there is no mention of get-next processing, multi-phase
set PDU processing, multi-PDU set handling or counter caching issues
(for starters).  Section 4.5 is not really true.  The order of the varbinds
in the PDU is not important to agents.  It's not mentioned in the I-D,
but the presence (or absence) of related object instances in the same PDU,
and the presence of partial and/or multiple instances of related
objects in the same PDU, is quite important to the agent.

Section 5 seems reasonable, but I'm not an SNMP application developer.
There are many aspects of NMS design not mentioned at all.  The
BCPs for set processing (5.3) focus on transfer efficiency and do not even
mention the impact the varbinds present (or not present) in the Set PDU
have on agent complexity.  This section could say that applications should
avoid use createAndWait if at all possible and always include all related
object instances in the same PDU. NMS developers should be aware that
agents may limit the number of related instances created in the same PDU
(as well as overall).

Section 6 starts with a procedural model that is hard to understand in the
current table format. It should be rewritten as simple paragraphs for clarity.
The DOCSIS access control example (6.4) seems like overkill to make
the point that SNMPv3 security mechanisms should be used.
There should be a lot of BCPs related to VACM and USM that could be
added by experts in those areas.  I think security deployment is the
most important and relevant BCP topic this document addresses,
but there's nothing about how to deploy SNMPv3 security.

Sections 7, 8, and 9 are tightly coupled to the PM MIB and
do not really represent BCPs.  The I think these sections should be
moved from the BCP to the PM (or other) document. Section 1
talks about how this document represents a decade of experience.
That is hardly the case with the concepts and PM-MIB specific
examples described in these sections.   There could be some
applicable BCP nuggets in here,  but they are buried in a lot
of descriptive text about the PM MIB.  It's not clear to me what BCP
the entire Heating and Air Conditioning MIB example is conveying.

I think this document needs significant changes.
The -06 version is not ready for RFC publication as a BCP.

Andy

>The following URL points to comments on the -05 version
>of the BCP. I believe that most are still appropriate,
>except some of the grammar, spellings, etc are cleaned
>up in the -06 version. However, I haven't read it,
>and don't plan to.
>
>   http://www.snmpinfo.com/ftp/temp/comments-05.pdf
>
>And it is OK (and encouraged for the document to be
>copied to the SNMPCONF repository).
>
>The bottom line on the document for me is that it needs
>extensive work before it is approapriate to be published.
>It is troubling that the WG chairs and authors would
>even consider forwarding the document for publication
>in its current state.
>
>I hope that the document is rewritten because there
>is a need for it.
>
>
>Regards,
>/david t. perkins

---

From: "Wayne F. Tackabury" <[email-masked]>
Date: Mon, 08 Oct 2001 13:37:53 -0400

Hi Andy...

I'll have more questions for you later to help clarify for me the correct 
amount of new content to address some of your points, but I want to make 
one note right now, perhaps if nothing else to ease your mind we're 
thinking the same way on this :).  You have a recurring concern that the 
BCP is in its current form too linked to the PM MIB and architecture, and 
as we've reflected on this, we think you're correct.

The position that I personally am striving for on this is that there 
certainly shouldn't be any direct linkage.  The notion that "policy" as a 
means of specifying defaults for the application to a potentially broad 
number of instances, seems to me to be general enough to warrant discussion 
on as a design consideration for MIBs and management applications.  This 
shouldn't *imply* PM, and I think we've currently (in the draft we're 
working on) whittled the mention of PM to two simple mentions as an example 
of an end-to-end architecture reflecting this principle (along with a 
mention of PM as being a work-in-progress as of this writing).  The HVAC 
MIB should simply reflect this, without any particular applicability for 
PM.  Point being "policy" should not imply PM at all necessarily.

Now, clearly, we need to look at the HVAC MIB some more to make sure it 
reflects this.  And, I could come up with a number of more specific points 
to clarify my arguments that this broader notion of policy applicability is 
compelling.  However, as stated here, does this sound like a reasonable 
position to you to be putting forth in the BCP?

Thanks for your comments and attention to the draft!

Regards,
Wayne

---

From: Jon Saperia <[email-masked]>
Date: Mon, 08 Oct 2001 13:54:58 -0400

Andy, just so you know, my thoughts are consistent with what Wayne has
below.  We have been working on the BCP edits as they came in over the
past month and will continue according to the plan. One point about
Waynes comments on policy. Routers we all know about support this
feature today via a cli to some degree. That is they have 'defaults'
that can be applied to many instances - but you know that.

/jon

> Thanks for your comments and attention to the draft!

Thanks,
/jon
--

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 08 Oct 2001 15:01:44 -0700

>that can be applied to many instances - but you know that.

I agree that there are BCPs mixed into sections 7-9, and they should
be captured in this draft.

I just noticed there isn't really much mention of RowStatus in section 4.
Views and BCPs have changed radically over time. We used to insist
at cisco that developers support createAndWait and notInService fully.
In the last 2 years we have reversed this policy. Implementations that
only allow the values createAndGo and destroy to be set are now the norm.

BTW, I think it is appropriate that this document is in WG Last Call.
Once the WG Chair decides to start Last Call for an I-D, it is standard
operating procedure for every subsequent revision of the I-D to immediately
enter WG Last Call upon publication.  As for the claim that the document
entered WG Last Call too soon -- this decision is entirely up to Chair(s).
In this case, the document editors had finished collecting input
and making edits, and the decision to start WG Last Call was a matter
of procedure.  As for the claim that the WG Chairs should be replaced --
this is absurd and counter-productive.

Andy

---

From: Michael MacFaden <[email-masked]>
Date: Mon, 8 Oct 2001 17:55:23 -0700

On Sat, Oct 06, 2001 at 01:19:52PM -0700, Andy Bierman wrote:
> Section 4.5 is not really true.  The order of the varbinds
>in the PDU is not important to agents.  

This BCP is pretty short so I'll enclose it here:

  4.5.  Order of varbinds in a SET PDU 
 
  When a given SET PDU contains multiple varbinds, agents conforming to 
  the SNMP should be able to process the varbinds in any given order. 
 
  In practice, it is often preferable that management applications send 
  the varbinds in the order they are defined in the MIB module. 

My experience writing mgmt apps w/sets against various 
SNMP agents has been just the opposite.  

If requested, I will post evidence to show various 
products that don't support out of order varbinds. 

Regards,
Mike

---

From: "Andrew Smith" <[email-masked]>
Date: Mon, 8 Oct 2001 20:01:44 -0700

There's no reason to believe, from the standards or from specific MIBs, that
any particular ordering of varbinds could be preferred (other than evidence
to back Mike's claim there are agents that do care, of course!). But such
mis-implementations should not be endorsed with any language that suggests
this is a "best" practice from an IETF point-of-view. If the best (or only!)
way to manage specific implementations/products uses a certain varbind
ordering then that is not a matter for IETF.

I'd suggest we have to delete the second paragraph quoted by Mike and change
the "should" in the first paragraph to a "must" (I assume lowercase is OK
here - this is not a normative document).

If people want to go further than this, replace the second paragraph with:

"In practice, some non-conformant agents may not correctly accept SETs with
certain orderings of varbinds: this document cannot recommend any best
practices for management of such agents."

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Michael MacFaden
Sent: Monday, October 08, 2001 5:55 PM
To: [email-masked]
Subject: Re: snmpconf Comments on the BCP

Regards,
Mike