Subject: snmpconf to-do deadline today

From: David Partain <[email-masked]>
Date: Fri, 06 Apr 2001 08:46:04 +0200

Folklets,

Please recall that today is the deadline for submission of
issues that you think need to be addressed on the SNMPCONF
documents.  You do not need to have the solution complete,
but we do need to know that you want the change.

With kind regards,

--
David Partain                  [email-masked]
Ericsson Radio Systems AB      Tel:    +46 13 28 41 44
Research and Innovation        Fax:    +46 13 28 75 67
P.O. Box 1248
SE-581 12  Linköping, Sweden

---

From: Wes Hardaker <[email-masked]>
Date: 06 Apr 2001 17:05:14 -0700

>>>>> On Fri, 06 Apr 2001 08:46:04 +0200, David Partain <[email-masked]> said:

David> You do not need to have the solution complete, but we do need
David> to know that you want the change.

Hmm...  4:45pm on Friday.  Hope thats in time:

#1 Language versioning: I want it changed, but I'm not sure consensus
   has been reached yet.

#3: policy failure and fallback: I think it was agreed in the meeting
  that something must be done, but I haven't had time to write up a
  solution or to look at the problem (and I don't think Steve has
  either)

#4: code reuse: I think its a serious issue, but the factions seem to
  be split as to whether it should be dealt with or not (and the
  common consensus among those wanting it to be dealt with is that we
  should over-ride the previous decision about implementing
  functions).  Without reaching consensus, I suspect nothing can be
  done about this and cut-n-paste style coding is all that will be
  available in the way of re-use.

#5: script failure Notifications: I think it was agreed upon that
  something should be done, but neither Steve nor I have written up
  a concrete suggestion yet.

#8: hasn't been discussed but should be.

#17: security questions: discussion started, but not completed.

#25: pmPolicyCodeStatus: fixed I think, according to Steve I think.  I
  may be thinking about another issue swimming around in my head.

There are also a list of issues I posted before the conference that
Steve was "thinking about" still.  I'd prefer these not get dropped
until he or others have had the chance to think about them more.  

-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Steve Waldbusser <[email-masked]>
Date: Fri, 06 Apr 2001 21:04:41 -0700

Here's a dump of my list.

1. Add pmPolicyElementTypeFilter object to restrict a policy to run
   only on certain element types

2. Change form of pmElementTypeRegOIDPrefix so that the OID is
   specified up to the table.entry part.

3. Change the schedule table to use the semantics that PCIM uses

4. Add mechanism to clean up resources on RTE or call to die()

5. Provide for deletion of scratchpad variables

6. Need to specify storage type for scratchpad variables

7. Provide a way for an action to defer itself to the next lower
   precedence policy

8. Align with policy framework terminology wherever appropriate

9. Rework the role table index to make it simpler for systems that
   don't act as a mid-level manager. Using same technique, add
   context and addressing info to other auxiliary table that need it.

10. In snmp accessor functions, allow integer values to be specified
    in the form "descriptor(1)" so that the code can self-document
    enumeration values. The descriptor text is completely ignored by
    the function.

    We could go further and define the integer coercion rules so that
        ToInteger("descriptor(1)") == 1
    I still have a couple of unresolved issues here so I'm thinking a
    bit.

11. Have a consistent capitalization convention in naming accessor
    functions.

12. Add optional arguments to snmpsend to send to another context or
    to a remote system. Make this consistent across all snmp functions
    that require it.

13. Add optional context/addressing arguments to roleMatch() and
capMatch()

14. Specify overflow rules for integer arithmetic 

15. Bug: if/for/while must call ToBoolean on their expression

16. Specify that function arguments are coerced to the proper type

17. Specify that by default context and address default to that of the
    current element

18. Suggest that smarter implementations might want to rerun policies
    prior to maxLatency if a role changes

19. Note that agents are allowed to terminate a script that exceeds
    a local CPU or memory limitation.

20. Helper objects to help NMS failover?

21. Stuff from Partain's 3/6 email

22. add $* which is equal to $0.$1.$2 ... for as many subids as exist

23. Fix race condition problem with codeTable

24. Receive/send traps/notifications?

25. Possibly change who points to who between policy table and code
    table.

26. rationalize usage of character vs. octet in light of UTF8

27. More thinking about how policies clean up when no longer active.

28. Have policy re-execute on all elements if filter or action
    changes or if parameter is changed. Also clear the scratchpad for
    all PolicyElement or Policy execution contexts for this policy.
    If changing the code requires that I modify 6 code segments, take
    care to not re-execute 6 times.

29. Allow filters to do sets?

30. Should setvar() return an error code?

31. Add function to retrieve the context/address of this execution
    context.

32. Potentially rename pmElementTypeRegName

33. Define how the return value of the policyAction is
    treated. 0 could have cleanup() or defer() semantics.

Plus, treat as "on the table" stuff previously brought up by Wes, Bob,
David, and Bert. For David and Bert I am referring to a private email
from David and Bert's markup of a printed copy of the PM MIB, in my
posession. I know we're not being that lawyerly about this but I just
want to make it "official".

BCP

1. Not sure if we want the PBCM acronym.

2. Suggest renaming "policy objects" to "provisioning objects".

3. HVAC MIB needs a name that can be used to easily find templates
   across agents.

4. I think we need a number of changes to the model in Section 7 
   and Section 8: need to decouple instance-independence
   from implementation/mechanism/domain-independence.  Further, use of
   the phrase "xxx-specific" is confusing WRT dependend/independent.
   Also make sure that implementation guidance is consistent with
   current state of PM MIB. Also need to come to further agreement
   on what is a mechanism-specific MIB.

Steve

---

From: Steve Waldbusser <[email-masked]>
Date: Fri, 06 Apr 2001 21:23:08 -0700

> until he or others have had the chance to think about them more.

Don't worry, the stuff in your two messages is already safely on the
table.

Steve

---

From: David Partain <[email-masked]>
Date: Tue, 10 Apr 2001 15:01:17 +0200

Hi Steve (and WG),

Thank you for the mail with the issues.  I've added most of
them to the todo list (although the "Issue" part is blank
in some cases).  I do, though, want to ask some questions
about some of the items.  It may be that I'm just thick,
but I didn't get some of these and need your assistance.
Sorry for the length of this mail...

sw> 1. Add pmPolicyElementTypeFilter object to restrict a policy to run
sw>    only on certain element types

I recall that we spoke about this during meetings in
Minneapolis.  For the benefit of those who weren't there,
let me clarify what I believe this means.  Basically, we
want to be able to limit a particular policy to running
on elements of type "interface", or whatever it might be.
This is specifically about efficiency.  Did I get it right?

sw> 2. Change form of pmElementTypeRegOIDPrefix so that the OID is
sw>    specified up to the table.entry part.

I don't recall this discussion.  Can you help me to understand
why we want to do this?

sw> 10. In snmp accessor functions, allow integer values to be specified
sw>     in the form "descriptor(1)" so that the code can self-document
sw>     enumeration values. The descriptor text is completely ignored by
sw>     the function.
sw> 
sw>     We could go further and define the integer coercion rules so that
sw>         ToInteger("descriptor(1)") -- 1
sw>     I still have a couple of unresolved issues here so I'm thinking a
sw>     bit.

I think this needs to be grounded in a WG discussion before this
becomes part of the document.

Many moons ago, we made a decision not to include the ability
to use OBJECT DESCRIPTORs rather than OIDs for naming objects
that we are manipulating.  We did this because we didn't
want to force agent systems to have mappings between OIDs and
OBJECT DESCRIPTORs.  This item is trying to get around some
of the problem that we created by not having MIB information
available in the agent system.

I think that this suggestion is a beginning down that slippery
slope.  Does the working group want to go there?

sw> 13. Add optional context/addressing arguments to roleMatch() and
sw> capMatch()

I specifically do not think we need to have it in capMatch.
Any subordinate systems can register their capabilities in the
capabilitiesOverrideTable, which will mean that a capMatch()
will just work.  I don't think we should add addressing in
capMatch.

There is already an item on the list regarding "off-the-box"
operations which I believe covers this issue.

sw> 15. Bug: if/for/while must call ToBoolean on their expression

Can you please expand on this?  Is the bug that they must or that
they don't?

sw> 23. Fix race condition problem with codeTable
sw>
sw> 24. Receive/send traps/notifications?
sw>
sw> 25. Possibly change who points to who between policy table and code
sw>     table.
sw>
sw> 28. Have policy re-execute on all elements if filter or action
sw>     changes or if parameter is changed. Also clear the scratchpad for
sw>     all PolicyElement or Policy execution contexts for this policy.
sw>     If changing the code requires that I modify 6 code segments, take
sw>     care to not re-execute 6 times.
sw> 
sw> 29. Allow filters to do sets?
sw>
sw> 32. Potentially rename pmElementTypeRegName

For these six, can you please explain what the issue is?

sw> 30. Should setvar() return an error code?

What do you have in mind?  Would it be something like
error-status?

sw> 31. Add function to retrieve the context/address of this execution
sw>     context.

I continue to hope that we can minimize complexity of the policy
engine and fear the whole off-the-box thread.  Like the proxy
part of SNMPv3, I believe the off-the-box portion of the PM
Module work should be optional, since I don't believe most
will use it that way.  On the other hand, that doesn't mean
we shouldn't be rigorous in definition of how that works.

How do you envision this function being useful?

sw> Plus, treat as "on the table" stuff previously brought up by Wes, Bob,
sw> David, and Bert. For David and Bert I am referring to a private email
sw> from David

I have now forwarded that mail to the list so that everyone knows
what this is about.

sw> and Bert's markup of a printed copy of the PM MIB, in my
sw> posession. I know we're not being that lawyerly about this but I just
sw> want to make it "official".

Thanks.  Can you perhaps enumerate what Bert's after?

sw> BCP
sw> 
sw> 1. Not sure if we want the PBCM acronym.
sw> 
sw> 2. Suggest renaming "policy objects" to "provisioning objects".
sw>
sw> 3. HVAC MIB needs a name that can be used to easily find templates
sw>    across agents.

Perhaps you've sent something to the BCP authors explaining the
rationale for these suggestions.  Could you expound on the issues
that you aim to address with these three?

sw> 4. I think we need a number of changes to the model in Section 7
sw>    and Section 8: need to decouple instance-independence
sw>    from implementation/mechanism/domain-independence.  Further, use of
sw>    the phrase "xxx-specific" is confusing WRT dependend/independent.
sw>    Also make sure that implementation guidance is consistent with
sw>    current state of PM MIB. Also need to come to further agreement
sw>    on what is a mechanism-specific MIB.

The taxonomy is already #1 under the BCP.  Please make a
proposal for changes that we can talk about.

Again, thanks very much for the list.

Cheers,

dlp

---

From: Steve Waldbusser <[email-masked]>
Date: Tue, 10 Apr 2001 21:45:19 -0700

> Sorry for the length of this mail...

Sorry I didn't add more detail. Much of this was cut-and-paste from my
own todo list and I didn't have time to elaborate on them.

> This is specifically about efficiency.  Did I get it right?

Yes. I also had a couple of slides about this in Minneapolis.

> I don't recall this discussion.  Can you help me to understand

It simplifies the text and makes it easier to understand. Plus it
eliminates an algorithm that the manager would otherwise have to perform
to eliminate duplicate entries. This came out of an email-list
discussion in which we agreed that table.entry would be better.

> slope.  Does the working group want to go there?

I don't think it goes down the slippery slope because it still doesn't
force the agent to have mappings between OIDs and descriptors.

All it says is that rather than writing:
	setvar("ifAdminStatus.$0", 2, Integer);
you could also express it as:
	setvar("ifAdminStatus.$0", "down(2)", Integer);

Characters before the parenthesis will be discarded and the number
inside the parenthesis will be used directly (i.e. with no mapping).

The first proposal is real easy to accept because it just involves
changes to the accessor functions.

The second proposal is a bit harder. First of all it isn't fully baked
yet because there are some unresolved issues (maybe unresolvable).
Second, we should be more careful with changes to the language than the
accessor functions and the second proposal is more like a change to the
language. I'm not going to push the second part until I resolve my own
issues with it.
 
> operations which I believe covers this issue.

The part where capMatch() "just works" is when you ask for a capability
in your own context.

But if I'm going to do on-the-box operations to management objects in
another context (on the same box), then capMatch() needs to know which
context that is. And if I'm doing off-box operations I need the address
as well.

> Can you please expand on this?  Is the bug that they must or that

They don't currently, but they should.

> For these six, can you please explain what the issue is?

These descriptions are still pretty quick-and-dirty. I'll elaborate in
even more detail later as needed:

#23 is the security problem I mentioned in an email on 4/3 about Issue
#17, Security.

#24: should the accessor function library include functions to receive
traps and notifications and/or send traps and notifications?

#25: Upon further reflection, I'm withdrawing this one.

#28: If the filter code changes we need to discard all filter return
values for that policy because they might have changed due to the logic
changing (therefore we need to rerun the filter on all elements). If the
action changes we need to rerun the action because it might need to make
something different happen. We need to take care that if the manager is
making updates to more than one code segment, that we don't re-execute
on all elements for each segment that is updated. Maybe we take the
policy offline for a moment, update the segments, and then turn it back
online, and that's when it would update the filters/actions. Finally, if
code changes, the semantics of scratchpad variables might changed so
it's important to delete any existing scratchpad vars for that policy.

#29: I think the restriction that filters cannot do sets is unnecessary
and counterproductive. While it's certainly not the "role" of the filter
to do configuration (rather the filter's job is to make a decision).
sometimes, making a decision involves performing a set.

#32: pmElementTypeRegName: I don't want the reader to be confused that
this "Name" is used to identify or index the elementType, when it is
just meant to describe the element to humans. "Label", "Caption", or
"Description" would be more appropriate - probably "Description".

> What do you have in mind?  Would it be something like

Yes.

> we shouldn't be rigorous in definition of how that works.

I agree with the optional part and that we should, as much as possible,
make it modular to make it simpler for non-mid-level-manager
implementations (I used to say proxy, but it is really mid-level-manager
or MLM).

I know it is attractive to lump all the off-the-box stuff into the same
category, but as I described in my two messages on 4/5, they are really
two different categories and it's worth getting to know the differences
between them. Figuring out whether optionality is appropriate here is an
example of that.

First, note that scripts routinely need to know their "address" (the
address of "this element", or $0, $1, ...) to do their work. This is
true whether they are being run locally or remotely. Similarly, a script
may need to know the context or network address of the element it is
running on, even if it is running locally. In other words, it might need
that information to accomplish its task and will need that information
regardless of whether it happens to be running on the same system as the
element or on a different system.

> How do you envision this function being useful?

How about the following repeater policy filter:

  // only run this script on the first repeater in a stack: "repeater1"
  if (elementContext() == "repeater1")
    return 1;
  else
    return 0;

> Thanks.  Can you perhaps enumerate what Bert's after?

As near as I can tell, Bert is pursuing a complex evil plan that will
ultimately result in the installation of aliens into key positions of
power throughout the globe.

Oops, that was a different document. Nevermind!

Actually, Bert's markup points out areas where terms are used
inconsistently, wording suggestions, logical inconsistencies and
syntactical improvements.  I haven't seen any yet that are controversial
enough to warrant discussion but I'll bring them up if they crop up.

> sw> 1. Not sure if we want the PBCM acronym.

First I'm not sure that we need an acronym at all. But further, in what
way is the architecture focused on configuration? I think we've built a
policy-based management architecture and that was exactly what the
doctor ordered in order to make configuration management with SNMP more
practical. It's also useful for other things. So I'm not fond of the
acronym or the term.

> sw> 2. Suggest renaming "policy objects" to "provisioning objects".

I think that the objects in the HVAC MIB (as an example) don't have much
to do with policy but rather implement a MIB that allows for more
sensible provisioning practices. 

> sw> 3. HVAC MIB needs a name that can be used to easily find templates

I'll expand on this in another message.

> proposal for changes that we can talk about.

OK.

Steve

---

From: Jon Saperia <[email-masked]>
Date: Wed, 11 Apr 2001 08:29:22 -0400

David, rather than have a long message, I have included only the points

> slope.  Does the working group want to go there?

I have to agree. I was wanted to have OBJECT DESCRIPTORs but apparently
did not argue effectivly. My desire is to either really add them and get
value or not at all. I would not favor a half measure.

> operations which I believe covers this issue.

Very much agree. See additional comment below.

I like the optional proposal because I also do not think it will be used
much this way and that it will take a lot of time and make things more
complex. I would only want to undertake the work after the other items
have been completed on our to do list.

Thanks,
/jon
--

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