[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: snmpTagList from RFC 3413
Thanks for the response,
I guess your examples are fine. Let me place a detailed example to
clarify the issue
The idea is to use a tag list to define a priority list rather than
define a table to list the rules priorities for a policy decision.
Supposed A via protocol X communicate its capabilities of a zzz feature
to B
Based on that list, B decides that A shall use one of those capabilities
based on policy P
Solution a)
zzzCapabilities
SYNTAX BITS { a(0), b(1), c(2), d(3)}
zzzCapabilities
SYNTAX SnmpTagList or,
zzzCapabilities
SYNTAX ZzzPolicyTagTC -- a space separated tag list --
A reports a,b,c as supported capabilities
The policy in B place the preferred zzz value as one of a, c,or b
(preferred order)
Policy in B:
zzzPolicy.0 = "c a d"
you are right pointing that in SMI the agent is not aware of
BITS/enumerations labels. And the solution above imply that you need to
define a implementation code to map labels and capability bit positions
I am just looking for a place where the object description can guide the
implementer by reusing some sort of defined terms like the
BITS/Enumeration labels.
What I can interpret from your comments is that SMI is restrictive and
probably the preferred option is the classical approach as indicated
below:
Or,
From the functionality perspective would be valid to define a TC that
mimics SnmpTargetList space separated items for the purpose of
zzzPolicy ?
Solution b)
zzzPolicyTable
INDEX { zzzPolicyIdx }
SEQUENCE { zzzPolicyIdx Unsigned32,
zzzPolicyValue Unsigned32,
zzzPolicyStatus RowStatus
}
With values:
zzzPolicyValue.1 = 2
zzzPolicyValue.2 = 0
zzzPolicyValue.3 = 3
zzzPolicyStatus.1 = 'active'
zzzPolicyStatus.2 = 'active'
zzzPolicyStatus.3 = 'active'
-----Original Message-----
From: David T. Perkins [mailto:dperkins@dsperkins.com]
Sent: Thursday, February 23, 2006 6:09 PM
To: Eduardo Cardona
Cc: ietfmibs@ops.ietf.org
Subject: Re: snmpTagList from RFC 3413
HI,
I wish I could help. I don't understand what you are looking for.
However, it appears to me that you have misinterpreted the
usage for TCs SnmpTagValue and SnmpTagList. Here is an example...
In RFC 3413, the table snmpNotifyTable has column snmpNotifyTag
(which has data type SnmpTagValue). The value (which is a "tag")
is used to select zero, one, or more rows in table snmpTargetTable
where one of the tags in the value of column snmpTargetAddrTagList
match the value.
Note that the "labels" for enum values and bits in a bit string
are typically NOT available in an agent implementation.
It seems like you just want to do a test of specific capabilities,
and, if so, you could define two MIB objects. The first would
be a bit string where each bit indicated a capability.
If you wanted to select for a single capability, then
the second would be an unsigned integer (which would be the index
of the bit). If you wanted to select multiple, then
the second would also be a bit string with the bits
on indicating the capabilities. If you wanted to select
based on specific capabilities present and absent, then
you need three objects, and the second would specify
the bits (it would be a bit string), and the third
would indicate the value of each selected bit (it
would be a bit string). This should be familure coding
pattern.
On Thu, 23 Feb 2006, Eduardo Cardona wrote:
> Hi,
>
> RFC 3413 defines the snmpTagList and requires pointers to a table for
> each of its tags
>
> I am wondering if snmpTagList is allowed to be use in a different in a
> context where there is no lookup in a table entries but could be
mapped
> as labels of other e.g. BITS constructs (like capabilities) or other
> defined enumeration values of an object compliance by the agent
>
> In case of a 'nope', are any other TC available for those cases? or
even
> more important, is this a valid usage of SMI ?
>
> One example would be to have user defined sorted policy
> - Lazy about building a short table for just minimal information to
list
> and
>
> zzzZZZ OBJECT-TYPE
> BITS {
> a(1),
> b(2),
> c(3),
> d(4)
> }
> DESCRIPTION
> "Capabilities..."
>
> zzzZZZPriority OBJECT-TYPE
> SYNTAX SnmpTagList
>
> DESCRIPTION
> "Defines the priority to validate X against the values defined in
> zzzZZZ objecBITs to ...
> The tags in the list matches the enumerated values, unknown tag values
> are ignored.
> ...
>"
Regards,
/david t. perkins