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

Re: snmpconf Comments on the BCP



At 01:54 PM 10/8/2001 -0400, Jon Saperia wrote:
>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.

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.

>/jon


Andy


> > 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
> >
> >
>
>Thanks,
>/jon
>--
>
>Jon Saperia                  saperia@jdscons.com
>                              Phone: 617-744-1079
>                              Fax:   617-249-0874
>                              http://www.jdscons.com/