RFC 3571
Framework Policy Information Base for Usage Feedback
Framework Policy Information Base for Usage Feedback 🎀
okay bestie, this is RFC 3571 💖 It's an Informational doc, which means it's here to inform, not an official Internet standard 🧚 It was written by D. Rawlins (MCI), A. Kulkarni (Intel), K. Chan (Nortel Networks), M. Bokaemper (Juniper Networks), and D. Dutt (Cisco), and it's dated August 2003 📅. The title block doesn't list any RFCs it obsoletes or updates, so it's totally standing on its own ✨
Status of this Memo
this memo gives info to the Internet community 🌸 It doesn't specify an Internet standard of any kind, and distribution of it is unlimited 💜
Copyright Notice
the copyright belongs to the Internet Society, and the official line is Copyright (C) The Internet Society (2003). All Rights Reserved. 🔒
Abstract
this doc describes a piece of the Policy Information Base (PIB) that controls policy usage collection and reporting on a device 📊
the provisioning classes in here let a Policy Decision Point (PDP) pick which policy objects should collect usage info, what info gets collected, and when it gets reported 🎯
also, this PIB needs other PIBs (defined elsewhere) to be there, because those are what actually provide the policy objects that usage info gets collected from 🫶
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. General Concepts . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Selection, Usage and Linkage Policies. . . . . . . . . . 3
2.2. Normal Operations. . . . . . . . . . . . . . . . . . . . 4
2.2.1. Connection Establishment and Initial
Configuration Request. . . . . . . . . . . . . . 4
2.2.2. Unsolicited Reports - Periodic Reporting . . . . 5
2.2.3. Unsolicited Reports - Reporting Conditions . . . 5
2.2.4. Solicited Reports. . . . . . . . . . . . . . . . 6
2.2.5. Resuming and Suspending Periodic Feedback
Reporting. . . . . . . . . . . . . . . . . . . . 6
2.2.6. Failover . . . . . . . . . . . . . . . . . . . . 6
2.3. Usage Policy and Under-specified Selection Criteria. . . 7
3. Summary of the Feedback Framework Policy Information Base. . . 8
3.1. SPPI ACCESS Clause Report-Only . . . . . . . . . . . . . 8
3.2. Usage32 and Usage64 Textual Conventions. . . . . . . . . 8
3.3. Feedback Groups and PRCs . . . . . . . . . . . . . . . . 9
3.3.1. Feedback Action. . . . . . . . . . . . . . . . . 9
3.3.2. Feedback Action List . . . . . . . . . . . . . . 10
3.3.3. Feedback Linkage Capability. . . . . . . . . . . 10
3.3.4. Feedback Linkage . . . . . . . . . . . . . . . . 10
3.3.5. Feedback Traffic Statistics Threshold. . . . . . 10
3.3.6. Feedback Traffic . . . . . . . . . . . . . . . . 10
3.3.7. Feedback Interface Traffic . . . . . . . . . . . 11
3.3.8. Feedback RoleCombo Filter Selection. . . . . . . 11
4. The Feedback Framework PIB Module. . . . . . . . . . . . . . . 11
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 31
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 32
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . 32
8.2. Informational References . . . . . . . . . . . . . . . . 33
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 351. Introduction ✨
so the Framework of Common Open Policy Service with Policy Provisioning (COPS-PR) Usage Feedback is the big-picture plan for monitoring policy usage and reporting it 🦋 This doc is the one that defines the specific PIB framework for policy usage feedback 💅
it defines the policy classes for monitoring and reporting usage feedback, plus the policy classes that control reporting intervals, suspension, resumption, and solicitation 🌈
Conventions Used in this Document
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🔑
2. General Concepts 💜
2.1. Selection, Usage and Linkage Policies
okay so there are three basic types of policies that decide what the PEP monitors, records, and reports 📋 They're the selection criteria policy, the usage policy, and the feedback report linkage policy 🔗
the selection criteria policy is installed by the PDP 🎯 It defines the conditions the PEP uses to monitor and record a usage policy. It may only be used for defining usage feedback selection criteria. BUT a more general case exists: a policy that's already around for policy enforcement can also be used to specify usage feedback selection criteria 🙈 An example is the frwkRoleCombo instance. It can be used in defining QoS enforcement policies, but it can also set the conditions for what usage to track, like counting the number of packets that match an interface capability set name and role combination 💖
the usage policy defines what attributes get recorded by the PEP 📊 These policies have an ACCESS clause of 'report-only'. Usually the usage policies count things tied to a specific action, like a packet getting dropped 💀 The feedback framework PIB defines two usage policy classes: frwkFeedbackTraffic and frwkFeedbackIfTraffic ✨ Usage PRCs can be generic (collecting basic statistics) or specific to one particular usage 🌸 The PDP decides which PRC(s) best suit(s) its requirements 👑 A PEP might support just one usage feedback PRC, in which case all the stats get gathered using instances of that PRC 😭 Or it might support multiple usage feedback PRCs, and then the PDP decides which PRC goes with which selection criterion 🧚
a usage feedback policy and a selection policy are tightly associated with each other 🫶 That's where the third policy comes in: the frwkFeedbackLinkTable. It's used to associate the selection and usage policies, or basically provide the linkage between them 🔗 It also specifies when to report the usage feedback ⏰ One frwkFeedbackLinkTable entry lets the same selection criteria instance get re-used for various usage feedback policies ♻️ And the table holds both the value of the selection criteria instance and the value of the usage feedback PRC 💅
----------------- ------------------ -----------------
| | | | | |
| Select Criteria | |Linkage Instance | |Usage Instance |
| | |-instance ID | |- instance ID |
| -instance ID |<--|-PRID of selection|--->|- PRID of Linkage|
| -conditions... | |-PRC of usage | |- counts... |
| | | | | |
----------------- ------------------ -----------------
Figure 1Figure 1 is a picture of how the selection criteria, linkage, and usage policies all connect 🦋
the PDP doesn't know the instance identifier of the usage feedback policy when it installs the selection criteria and feedback linkage policies 🙈 Instead, the usage feedback policy gets instantiated on the PEP when a feedback report linkage gets installed, and the PEP picks the instance identifier itself 🧚 The usage feedback policy class always has an attribute of type ReferenceId, which holds the instance value of the associated frwkFeedbackLinkTable instance (the one the PDP installed) 💜 An example is the attribute frwkFeedbackTrafficLinkRef 💖
2.2. Normal Operations
2.2.1. Connection Establishment and Initial Configuration Request
so the Accounting Timer object in the COPS Connection Accept message holds the minimum number of seconds allowed between reporting intervals, as described in [COPS] and [FEEDBACKFWK] ⏱️ That number becomes the basic unit of measurement for defining intervals for specific usage policies with the frwkFeedbackLinkInterval attribute 🎀
the PEP tells the PDP which selection criteria policy classes and usage policy classes it supports during the initial request for configuration data, using frwkPRCSupport instances [FR-PIB] 📣 The PEP also says whether it supports the frwkFeedbackLinkTable as well 🫶
the PDP answers that initial configuration request with a DECISION that installs policies 👑 The PDP can also set maximum reporting intervals for each usage policy, using the frwkFeedbackLinkInterval attribute in the frwkFeedbackLink class 🌈 It can set reporting thresholds too, by including an instance of a threshold class (for example frwkFeedbackTrafficThreshold) in the decision 💅
then the PEP monitors and records usage based on the conditions in its selection criteria policy 📊 It reports usage with a REPORT message on a regular basis, or it provides a REPORT whenever the PDP asks for one 🦋 The PDP asks for usage feedback using the frwkFeedbackActionIndicator attribute of the frwkFeedbackAction class 🔥
2.2.2. Unsolicited Reports - Periodic Reporting
okay so reporting can be periodic and unsolicited, meaning the PEP sends it without being asked 🌸 The intervals for these unsolicited reports are defined in the specific Linkage policies 📅 They're based on the number of seconds the PDP put in the ACCT Timer value ⏱️ The PDP can also say that the associated usage instance only goes into a periodic unsolicited report if the threshold is reached, and/or if the usage value has changed since the last reporting interval 🧚
now, there are times when the PEP has to send unsolicited feedback reports that don't line up with an interval boundary 😭 In those cases, the PEP MUST provide an unsolicited REPORT containing all the defined usage instances, right before it issues a Delete Request State, and also right before it de-activates a PIB instance context 💀🫶
(part 1 of 6 — more to come, bestie 💅🌈)
2.2.3. Unsolicited Reports - Reporting Conditions 🎀
okay so periodic unsolicited reports for individual usage feedback instances can get suppressed 🙈 by adding extra conditions to the frwkFeedbackLink instances. there are two conditions rn:
ChangeOnly: if this flag is set in thefrwkFeedbackLinkFlagsattribute, the usage instance only gets included in a periodic unsolicited report if its value changed since the last unsolicited report. no change, no report. minimalism, bestie 💅Threshold: if this flag is set in thefrwkFeedbackLinkFlagsattribute, the usage instance only gets included in a periodic unsolicited report if the threshold condition referenced in thefrwkLinkThresholdfield evaluates successfully for that usage instance ✨
you can combine both conditions in one frwkFeedbackLinkUsage object. if you do, both conditions need to succeed before the usage instance gets reported. it's a whole vibe check 🫶
unsolicited reports triggered by a Delete Request State or by the deactivation of a PIB instance are not subject to these conditions. all usage objects MUST be included in these cases 😭
2.2.4. Solicited Reports 🔥
the PDP MAY ask for policy usage feedback by sending an unsolicited Decision with the frwkFeedbackActionIndicator set to solicitReport'. the PEP is to provide a solicited REPORT feedback containing usage feedback. the PEP SHALL keep providing periodic feedback at the intervals set up when the client connection was accepted 🌸
the reporting conditions (ChangeOnly and Threshold) do not affect solicited reports. all requested usage instances MUST be included, no exceptions 👑
2.2.5. Resuming and Suspending Periodic Feedback Reporting 🦋
the PDP MAY suspend usage monitoring and tracking at the PEP by setting frwkFeedbackActionIndicator to 'suspendMonitoringAndReports'. the PEP MUST stop tracking usage information and MUST NOT issue any feedback reports. this one is a full pause, not me being dramatic 💀
the PDP MAY only suspend feedback reporting by setting the ActionIndicator to 'suspendReports'. the PEP MUST cease sending unsolicited reports, but it is to keep monitoring and tracking usage 👀
the PDP MAY resume the sending of feedback reports, and it MAY resume usage monitoring too, by setting the ActionIndicator to 'resume' 🧚
the PDP MAY suspend or resume all usage instances, or it MAY specify one or more instances to be suspended or resumed. the frwkFeedbackActionList attribute holds a tag identifier that points to a list of one or more frwkFeedbackActionList instances 🌈
the PDP MAY halt usage monitoring, tracking and reporting of usage policies by removing the associated Linkage entry. bye bye, usage policies 🫠
2.2.6. Failover 💜
if the connection between the PEP and PDP gets lost, the PEP keeps tracking usage information for as long as it keeps operating with the installed policy. once the locally installed policy at the PEP expires, the usage policy data expires with it 🥲
when the connection comes back and the PEP is still caching policy, the PDP tells the PEP that it MAY resume sending the COPS accounting type report messages. the PDP does this by issuing an unsolicited decision with the frwkFeedbackResumeIndicator set to 'resume'. the PEP SHOULD resume reporting at the next appropriate feedback interval, the one set up when the re-connection was accepted ✨
the PDP knows the request state Handle(s) and the supported PRCs either through the state synchronization mechanism, or because the PDP considers itself synchronized with the PEP once it reconnects. reunion arc complete 🫶
2.3. Usage Policy and Under-specified Selection Criteria 🧚
some of the usage policy objects created in the PEP with COPS-PR can be used by the PEP more than once. they basically act like templates for the objects the PEP creates. COPS-PR only has the identity (OID) of the object, and that identity is shared between all the assignments the PEP made. but it's really desirable to collect usage info for each derived object individually 🍓
this is achieved in the feedback framework PIB by distributing extra information that qualifies one specific assignment of an object, split between the selection criteria PRC and the feedback usage PRC 💖
a selection criteria PRC that refers to a shared object but has no qualifying info selects ALL of that object's assignments. a selection criteria PRC like that SHOULD be combined with a feedback usage PRC that includes everything needed to identify one specific assignment. that way, a single selection criteria policy can end up generating a bunch of feedback usage objects, one for each derived object 🌟
if the selection criteria PRC has all the required qualifying attributes for one specific assignment, it gets combined with a feedback usage PRC that only has the metrics you want and no extra attributes 🎀
Example:
a frwkRoleCombo instance can be used as a selection criteria, identifying a set of interfaces by their role combination and capability set. if you want per-interface traffic stats, the usage PRC has to include an extra attribute to qualify the specific interface. this can be done by linking the frwkFeedbackIfTraffic class with a frwkRoleCombo instance in a frwkFeedbackLink instance. the PEP creates multiple frwkFeedbackIfTraffic instances, one for each interface the frwkRoleCombo instance selects. the frwkFeedbackIfTraffic class has the frwkFeedbackIfTrafficIfIndex attribute, which lets the PDP tell each interface's counters apart when the PEP reports the frwkFeedbackIfTraffic instances 📊
if you only want traffic usage collected for one individual interface, use a selection criteria that qualifies that interface completely, like a frwkIfRoleCombo instance. in that case, you can link it to the usage class that has no additional qualifying attributes, which is frwkFeedbackTraffic 🙌
3. Summary of the Feedback Framework Policy Information Base 📚
3.1. SPPI ACCESS Clause Report-Only 🌸
the selection criteria and linkage policy classes follow the definitions in [SPPI]. this structure defines well-defined policy classes and their instances that live in a common, virtual repository [FR-PIB]. the extra PIB-ACCESS clause attribute of "report-only" marks the usage policy class that the PEP reports 🫶
3.2. Usage32 and Usage64 Textual Conventions 🔢
the SPPI doesn't support the Counter32/64 textual conventions (TC) from SNMP, so for feedback collection, this PIB defines two similar textual conventions: Usage32 and Usage64 💅
with 'Counter', only the difference between two samples usually carries info. but a single value of a 'Usage' attribute usually gives absolute info, since:
- its initial value is known (0)
- no wrap-around events SHOULD occur
- the time or event when the initial value was set SHOULD be available directly or indirectly from other objects
when 'Usage' attributes are defined in a PRC, the events that could reset the attribute to its initial value SHOULD be defined in the description, along with the mechanism that lets the PDP detect the time of the last reset 🕰️
no usual COPS activity SHOULD cause a Usage attribute to reset. if monitoring gets suspended ('suspendMonitoringAndReports' set in frwkFeedbackActionIndicator), 'Usage' attributes SHOULD keep their values and keep counting once monitoring resumes 🧠
3.3. Feedback Groups and PRCs 🍰
these policy classes are shared by account type reporting for various technologies, and they apply to ALL SUBJECT-CATEGORIES. they're split into three new groups: the Feedback Report Group, the Feedback Usage Group and the Feedback Selection Group 💕
the policy classes in the Feedback Report Group are:
- Feedback Action
- Feedback Action List
- Feedback Selection Usage Combination Capability
- Feedback Linkage
- Feedback Traffic Statistics Threshold
the policy classes in the Feedback Usage Group are:
- Feedback Traffic
- Feedback Interface Traffic
the policy class in the Feedback Selection Group is:
- Feedback RoleCombo Filter Selection
3.3.1. Feedback Action 🎬
the Feedback Action class holds the attributes that say what action the PEP takes on policy usage, monitoring and tracking. the PDP MAY suspend usage monitoring and periodic reporting, suspend periodic reporting only, resume usage and periodic reporting, or solicit immediate reporting. the action MAY affect all feedback policies, or it can be tied to one or more frwkFeedbackLink instances 🌷
the frwkFeedbackActionIndicator attribute defines the action. the frwkFeedbackActionPri attribute shows whether the action applies to all of the usage policies or to a list. the frwkFeedbackActionList attribute is the identifier of the list of Linkage policy instances the action applies to 📋
the PDP can ask the PEP for immediate usage feedback. the PEP SHALL respond with a solicited report containing the usage feedback 📣
the PDP can direct the resumption of usage monitoring and reporting on the defined intervals. for example, the PEP may have reconnected to a PDP and has cached usage policies. the PDP tells the PEP to resume usage tracking and monitoring and to send all the cached usage policy. the PEP SHALL respond at the next appropriate interval with an unsolicited report containing the usage feedback 🔁
the PDP can suspend usage monitoring. the PEP keeps the usage it has already monitored, but stops any further monitoring until the PDP directs it to resume in a later Decision ⏸️
the PDP can also suspend just the reporting of usage without interrupting monitoring and tracking. the PEP SHALL stop sending Report messages with usage feedback until the PDP directs it to resume. then the PEP starts reporting usage feedback again at the next interval 🌈
3.3.2. Feedback Action List 🗂️
this class defines sets of linkage instances that can be referred to from the frwkFeedbackActionList attribute 💜
3.3.3. Feedback Linkage Capability 🧩
this class defines the valid combinations of selection criteria PRC, usage PRC and threshold PRC that the PEP supports ✅
3.3.4. Feedback Linkage 🔗
this class links the selection criteria instance with the usage class. the table lets you reuse one selection criteria instance for multiple usage policies 🙌
the linkage table also lets you define a maximum reporting interval to use when issuing COPS accounting type reports for the usage instance. a value of 0 in this attribute indicates that the usage policy MUST be solicited 🫠
3.3.5. Feedback Traffic Statistics Threshold 📏
this class provides the threshold values for the attributes described in the traffic usage classes below 🎯
3.3.6. Feedback Traffic 🚦
this class includes the packet counts, the byte counts and a reference to the associated Linkage instance 💖
3.3.7. Feedback Interface Traffic ✨
okay so this one is basically the Feedback Traffic class's glow-up 💅 it's giving the same vibe, except it also gets an interface index, so you can tell exactly which interface the traffic is on 🦋 you'd use it with a selection criteria instance that matches an element assigned to multiple interfaces, and the interface field is what links each row of this table to that element's specific assignment. the way that makes sense to me 🫶
3.3.8. Feedback RoleCombo Filter Selection 🎀
this class is your selection criteria based on a role combination, a capability set, and a filter instance. bestie, that's three things doing teamwork 🧚
4. The Feedback Framework PIB Module 💜
this is the actual PIB module, so every line below is copied exactly, no edits, no cap 🙈
FRAMEWORK-FEEDBACK-PIB PIB-DEFINITIONS ::= BEGIN
IMPORTS
pib, Unsigned32, Unsigned64, Integer32,
MODULE-IDENTITY, OBJECT-TYPE, MODULE-COMPLIANCE, OBJECT-GROUP
FROM COPS-PR-SPPI
TruthValue, TEXTUAL-CONVENTION
FROM SNMPv2-TC
InstanceId, ReferenceId, Prid,
TagId, TagReferenceId
FROM COPS-PR-SPPI-TC
PrcIdentifierOid, PrcIdentifierOidOrZero
FROM FRAMEWORK-TC-PIB
frwkRoleComboEntry
FROM FRAMEWORK-PIB
InterfaceIndex
FROM IF-MIB;
frwkFeedbackPib MODULE-IDENTITY
SUBJECT-CATEGORIES { all }
LAST-UPDATED "200307140000Z" -- 14 July 2003
ORGANIZATION "IETF RAP WG"
CONTACT-INFO "IETF RAP WG
Email: rap@ops.ietf.org
Diana Rawlins
MCI
400 International Parkway
Richardson, Texas 75081
Phone: 972-729-4071
Email: Diana.Rawlins@mci.com
Amol Kulkarni
JF3-206
2111 NE 25th Ave
Hillsboro, Oregon 97124
Phone: 503-712-1168
Email: amol.kulkarni@intel.com
Kwok Ho Chan
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821 USA
Phone: 978-288-8175
Email: khchan@nortelnetworks.com
Martin Bokaemper
Juniper Networks
700 Silver Seven Road
Kanata, ON, K2V 1C3, Canada
Phone: 613-591-2735
Email: mbokaemper@juniper.net
Dinesh G Dutt
Cisco Systems, Inc.
170 Tasman Dr.
San Jose, CA 95134-1706
Phone: 408-527-0955
Email: ddutt@cisco.com"
DESCRIPTION
"The PIB module containing the base set of policy rule
classes that are required for support of all policy
usage monitoring, tracking and reporting policies.
Copyright (C) The Internet Society (2003). This version
of this PIB module is part of RFC 3571; see the RFC
itself for full legal notices."
REVISION "200307140000Z"
DESCRIPTION
"Initial version, published in RFC 3571."
::= { pib 5 }
--
-- Textual Conventions
--
Usage32 ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The Usage32 type represents a non-negative integer
which monotonically increases.
Usage32 initial value is 0 and the object-type using
Usage32 needs to specify when it is initialized.
The Usage32 type is intended to reflect the absolute
number of counted events, so that even a new PDP
after a COPS reconnect can use the value directly.
If there is the possibility that the maximum Usage32
value of 2^32-1 is exceeded during the lifetime
of the Usage32 object, the larger Usage64 type
should be used.
If conditions other than the reset of the COPS
subsystem exist that disrupt the monotonic
characteristics of Usage32, these conditions and a
method how to detect their presence should be
specified in the description of the object-type using
Usage32 or its enclosing object-types (e.g. the
Entry or Table object-type of the Usage32
object-type).
Whenever the monotonic increase of Usage32 is violated,
it should be reset to 0 and the fact that this occurred
should be indicated through an appropriate mechanism,
for example a corresponding object of type TimeStamp
or TimeAndDate."
SYNTAX Unsigned32
Usage64 ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The Usage64 type represents a non-negative integer
which monotonically increases.
Usage64 initial value is 0 and the object-type using
Usage64 needs to specify when it is initialized.
The Usage64 type is intended to reflect the absolute
number of counted events, so that even a new PDP
after a COPS reconnect can use the value directly.
The lifetime of the Usage64 object should be defined
in a way that ensures the maximum Usage64 value of
2^64-1 is never exceeded.
If conditions other than the reset of the COPS
subsystem exist that disrupt the monotonic
characteristics of Usage64, these conditions and a
method how to detect their presence should be
specified in the description of the object-type using
Usage64 or its enclosing object-types (e.g. the
Entry or Table object-type of the Usage64
object-type).
Whenever the monotonic increase of Usage64 is violated,
it should be reset to 0 and the fact that this occurred
should be indicated through an appropriate mechanism,
for example a corresponding object of type TimeStamp
or TimeAndDate."
SYNTAX Unsigned64
--
-- The feedback report group
--
frwkFeedbackGroupClasses
OBJECT IDENTIFIER ::= { frwkFeedbackPib 1 }
--
-- Feedback Action Table
--
frwkFeedbackActionTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkFeedbackActionEntry
PIB-ACCESS install
STATUS current
DESCRIPTION
"This class represents commands that the PDP sends to
suspend, resume or solicit collection or reporting of
usage data."
::= { frwkFeedbackGroupClasses 1}
frwkFeedbackActionEntry OBJECT-TYPE
SYNTAX FrwkFeedbackActionEntry
STATUS current
DESCRIPTION
"Each frwkFeedbackActionEntry represents a command from
the PDP. FrwkFeedbackActionIndicator specifies the
command itself while frwkFeedbackActionSpecificPri
indicates if all frwkFeedbackLink objects in the system
are affected by the command, or just the set that is
referenced by frwkFeedbackActionList."
PIB-INDEX { frwkFeedbackActionId}
::= { frwkFeedbackActionTable 1}
FrwkFeedbackActionEntry ::= SEQUENCE {
frwkFeedbackActionId InstanceId,
frwkFeedbackActionIndicator INTEGER,
frwkFeedbackActionSpecificPri TruthValue,
frwkFeedbackActionList TagReferenceId
}
frwkFeedbackActionId OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer index that uniquely identifies an
instance of the frwkFeedbackAction class."
::= { frwkFeedbackActionEntry 1}
frwkFeedbackActionIndicator OBJECT-TYPE
SYNTAX INTEGER {
suspendMonitoringAndReports(1),
suspendReports(2),
resume(3),
solicitReport(4)
}
STATUS current
DESCRIPTION
"The value indicates if the PEP is to send cached
usage policies via COPS accounting type report
messages.
The enumeration values are:
(1) suspendMonitoringAndReports
(2) suspendReports
(3) resume
(4) solicitReport "
::= { frwkFeedbackActionEntry 2 }
frwkFeedbackActionSpecificPri OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"A value of 0 indicates that the
frwkFeedbackActionList attribute should be ignored,
and the action applied to all policies. A value of
1 indicates that the action entry has a specific
list of policies to which it is to be applied."
::= { frwkFeedbackActionEntry 3}
frwkFeedbackActionList OBJECT-TYPE
SYNTAX TagReferenceId
PIB-TAG { frwkFeedbackActionListTag }
STATUS current
DESCRIPTION
"Identifies a group of frwkFeedbackLink instances
that this action should affect. The group is
identified through a tag reference in the
frwkFeedbackList class."
::= { frwkFeedbackActionEntry 4}
--
-- Feedback Action List Table
--
frwkFeedbackActionListTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkFeedbackActionListEntry
PIB-ACCESS install
STATUS current
DESCRIPTION
"This class defines groups of linkage instances.
Groups can be referenced by commands sent by the
PDP in a frwkFeedbackActionEntry -in this case the
command affects all linkage instances that are part
of the group.
A group can be referred to by its tag stored in
frwkFeedbackActionListTag."
::= { frwkFeedbackGroupClasses 2}
frwkFeedbackActionListEntry OBJECT-TYPE
SYNTAX FrwkFeedbackActionListEntry
STATUS current
DESCRIPTION
"Each instance associates a linkage instance with a
specific ActionListGroup."
PIB-INDEX {frwkFeedbackActionListId }
UNIQUENESS { frwkFeedbackActionListTag,
frwkFeedbackActionListRefID
}
::= { frwkFeedbackActionListTable 1}
FrwkFeedbackActionListEntry::= SEQUENCE {
frwkFeedbackActionListId InstanceId,
frwkFeedbackActionListTag TagId,
frwkFeedbackActionListRefID ReferenceId
}
frwkFeedbackActionListId OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"Arbitrary integer index that uniquely
identifies an instance of the class."
::= { frwkFeedbackActionListEntry 1 }Okay bestie, the PIB module is where things get extra structured 🎀 so I'm keeping every line of code exactly as it is. Let's go!
Feedback Action List's Tag and RefID are first up, and the RefID points at a frwkFeedbackLink instance so it can join the group 🦋
frwkFeedbackActionListTag OBJECT-TYPE
SYNTAX TagId
STATUS current
DESCRIPTION
"Identifies a group of linkage instances that can
be referenced from the Action class."
::= { frwkFeedbackActionListEntry 2 }
frwkFeedbackActionListRefID OBJECT-TYPE
SYNTAX ReferenceId
PIB-REFERENCES { frwkFeedbackLinkEntry }
STATUS current
DESCRIPTION
"A frwkFeedbackLink instance that is referred to
by this ReferenceId becomes part of the group,
that is identified by the
frwkFeedbackActionListTag."
::= { frwkFeedbackActionListEntry 3 }
--
-- The Feedback Link Capability Table
--
frwkFeedbackLinkCapsTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkFeedbackLinkCapsEntry
PIB-ACCESS notify
STATUS current
DESCRIPTION
"Instances of the frwkFeedbackLink class reference
instances of selection and threshold classes and a
usage class.
This class allows the PEP to communicate valid
combinations of these three classes to the PDP."
::= { frwkFeedbackGroupClasses 3}
frwkFeedbackLinkCapsEntry OBJECT-TYPE
SYNTAX FrwkFeedbackLinkCapsEntry
STATUS current
DESCRIPTION
"The attributes of this class identify valid
combinations of selection criteria, usage and
threshold classes for feedback."
PIB-INDEX { frwkFeedbackLinkCapsId }
UNIQUENESS {
frwkFeedbackLinkCapsSelection,
frwkFeedbackLinkCapsUsage,
frwkFeedbackLinkCapsThreshold
}
::= {frwkFeedbackLinkCapsTable 1}
FrwkFeedbackLinkCapsEntry ::= SEQUENCE {
frwkFeedbackLinkCapsId InstanceId,
frwkFeedbackLinkCapsSelection PrcIdentifierOid,
frwkFeedbackLinkCapsUsage PrcIdentifierOid,
frwkFeedbackLinkCapsThreshold PrcIdentifierOidOrZero
}
frwkFeedbackLinkCapsId OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer index that uniquely identifies an
instance of the frwkFeedbackLinkCaps class."
::= { frwkFeedbackLinkCapsEntry 1}
frwkFeedbackLinkCapsSelection OBJECT-TYPE
SYNTAX PrcIdentifierOid
STATUS current
DESCRIPTION
"The identifier of a class that is supported by the
device for feedback selection in combination with the
usage and threshold classes referenced in this
instance."
::= { frwkFeedbackLinkCapsEntry 2}
frwkFeedbackLinkCapsUsage OBJECT-TYPE
SYNTAX PrcIdentifierOid
STATUS current
DESCRIPTION
"The identifier of the usage class that is supported by
the PEP in combination with the selection and threshold
classes referenced in this instance."
::= { frwkFeedbackLinkCapsEntry 3}
frwkFeedbackLinkCapsThreshold OBJECT-TYPE
SYNTAX PrcIdentifierOidOrZero
STATUS current
DESCRIPTION
"The identifier of the threshold class that is
supported by the PEP in combination with the selection
and usage classes referenced in this instance.
0.0 is used if this combination does not allow a
threshold."
::= { frwkFeedbackLinkCapsEntry 4}The Link Caps table is the PEP telling the PDP which combos of selection, usage and threshold classes it can actually do, and that's giving honest communication 💅✨
--
-- The Feedback Report Linkage Table
--
frwkFeedbackLinkTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkFeedbackLinkEntry
PIB-ACCESS install
STATUS current
DESCRIPTION
"This class associates the selection criteria with the
usage policy. It also permits the defining of the max
interval used for reporting the usage instance."
::= { frwkFeedbackGroupClasses 4}
frwkFeedbackLinkEntry OBJECT-TYPE
SYNTAX FrwkFeedbackLinkEntry
STATUS current
DESCRIPTION
"This class associates the selection criteria with the
usage policy. It also permits the defining of the max
interval used for reporting the usage instance."
PIB-INDEX { frwkFeedbackLinkId }
UNIQUENESS {frwkFeedbackLinkSel,
frwkFeedbackLinkUsage }
::= {frwkFeedbackLinkTable 1}
FrwkFeedbackLinkEntry ::= SEQUENCE {
frwkFeedbackLinkId InstanceId,
frwkFeedbackLinkSel Prid,
frwkFeedbackLinkUsage PrcIdentifierOid,
frwkFeedbackLinkInterval Integer32,
frwkFeedbackLinkThreshold Prid,
frwkFeedbackLinkFlags BITS
}
frwkFeedbackLinkId OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer index that uniquely identifies an
instance of the frwkFeedbackLinkTable class."
::= { frwkFeedbackLinkEntry 1}
frwkFeedbackLinkSel OBJECT-TYPE
SYNTAX Prid
STATUS current
DESCRIPTION
"The PRID of the Policy Class instance as the monitoring
point, or the PRID of the selection criteria instance that
defines the conditions for monitoring, to be use by the
PEP for usage reporting."
::= { frwkFeedbackLinkEntry 2}
frwkFeedbackLinkUsage OBJECT-TYPE
SYNTAX PrcIdentifierOid
STATUS current
DESCRIPTION
"The identifier of the usage class that the PEP uses to
monitor, record and report."
::= { frwkFeedbackLinkEntry 3}
frwkFeedbackLinkInterval OBJECT-TYPE
SYNTAX Integer32
STATUS current
DESCRIPTION
"Maximum interval in units of the value of the
Accounting Timer specified by the PDP in the client
accept message. A frwkFeedbackLinkInterval of 1 is
equal to the value of the Accounting Timer. This value
must be 1 or greater. "
::= { frwkFeedbackLinkEntry 4}
frwkFeedbackLinkThreshold OBJECT-TYPE
SYNTAX Prid
STATUS current
DESCRIPTION
"The PRID of a threshold class instance. This instance
specifies the threshold values for the usage policy."
::= { frwkFeedbackLinkEntry 5}
frwkFeedbackLinkFlags OBJECT-TYPE
SYNTAX BITS {
periodic(0),
threshold(1),
changeOnly(2)
}
STATUS current
DESCRIPTION
"This value indicates the reporting basis of the usage
policy. The feed back may be generated on demand, on a
periodic basis regardless of a change in value from the
previous report, on a periodic basis if a change in
value has occurred, or the usage is reported when an
identified threshold value in the usage instance has
been reached.
If the 'periodic' flag is set, the PEP will provide
unsolicited reports at the rate specified in
frwkFeedbackLinkInterval.
If the 'periodic' flag is not set, reports will only be
generated when solicited by the PDP.
The 'threshold' and 'changeOnly' flags make the
periodic reports conditional - these flags only make
sense in combination with the 'periodic' flag."
::= { frwkFeedbackLinkEntry 6}The Flags object is where the reporting basis gets decided, and the periodic bit is the main character 👑 The 'threshold' and 'changeOnly' bits only make sense when 'periodic' is set, so don't skip that part, babe 🙈
--
-- The Threshold class that accompanies the above Usage PRCs
--
frwkFeedbackTrafficThresTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkFeedbackTrafficThresEntry
PIB-ACCESS install
STATUS current
DESCRIPTION
"This class defines the threshold attributes
corresponding to usage attributes specified in
frwkFeedbackTrafficTable, frwkFeedbackIfTrafficTable
and other similar usage classes.
The usage object is considered to match the threshold
condition if at least one of the packet or byte
threshold conditions match.
The byte and packet thresholds are considered to
match, if the threshold is present (not ASN1 NULL)
and the corresponding usage value exceeds the
threshold."
::= { frwkFeedbackGroupClasses 5}
frwkFeedbackTrafficThresEntry OBJECT-TYPE
SYNTAX FrwkFeedbackTrafficThresEntry
STATUS current
DESCRIPTION
"Defines the attributes to hold threshold values."
PIB-INDEX {frwkFeedbackTrafficThresId}
::= {frwkFeedbackTrafficThresTable 1}
FrwkFeedbackTrafficThresEntry ::= SEQUENCE {
frwkFeedbackTrafficThresId InstanceId,
frwkFeedbackTrafficThresPackets Unsigned64,
frwkFeedbackTrafficThresBytes Unsigned64
}
frwkFeedbackTrafficThresId OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"Arbitrary integer index that uniquely identifies
an instance of the class."
::= { frwkFeedbackTrafficThresEntry 1 }
frwkFeedbackTrafficThresPackets OBJECT-TYPE
SYNTAX Unsigned64
STATUS current
DESCRIPTION
"The threshold, in terms of packets, that must be
matched or exceeded to trigger a report in the
next reporting interval."
::= { frwkFeedbackTrafficThresEntry 2 }
frwkFeedbackTrafficThresBytes OBJECT-TYPE
SYNTAX Unsigned64
STATUS current
DESCRIPTION
"The threshold, in terms of bytes, that must be
exceeded to trigger a report in the next reporting
interval."
::= { frwkFeedbackTrafficThresEntry 3 }
--
-- All actual usage classes are in the separate
-- frwkFeedbackUsageClasses group
--
frwkFeedbackUsageClasses
OBJECT IDENTIFIER ::= { frwkFeedbackPib 2 }
--
-- The generic traffic (byte & packet count) usage class
--
frwkFeedbackTrafficTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkFeedbackTrafficEntry
PIB-ACCESS report-only
STATUS current
DESCRIPTION
"This class defines the usage attributes that the PEP
is to monitor for plain traffic handling elements
like filters. All packets and the bytes contained in
these packets are counted. It also contains the PRID
of the linkage instance associating the selection
criteria instance with the usage instance."
::= { frwkFeedbackUsageClasses 1}
frwkFeedbackTrafficEntry OBJECT-TYPE
SYNTAX FrwkFeedbackTrafficEntry
STATUS current
DESCRIPTION
"Defines the attributes the PEP is to monitor,
record and report."
PIB-INDEX {frwkFeedbackTrafficId}
UNIQUENESS { frwkFeedbackTrafficLinkRefID }
::= {frwkFeedbackTrafficTable 1}Threshold stuff is next, and the packet and byte checks are each their own little vibe ✨ The usage side of things is just getting started, so there's more where this came from 🌸
okay bestie, this is where the counting happens 🧚✨ the basic traffic class keeps tabs on packets and bytes, and every entry points back to a linkage policy instance
FrwkFeedbackTrafficEntry ::= SEQUENCE {
frwkFeedbackTrafficId InstanceId,
frwkFeedbackTrafficLinkRefID ReferenceId,
frwkFeedbackTrafficPacketCount Usage64,
frwkFeedbackTrafficByteCount Usage64
}
frwkFeedbackTrafficId OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"Arbitrary integer index that uniquely identifies
an instance of the class."
::= { frwkFeedbackTrafficEntry 1 }
frwkFeedbackTrafficLinkRefID OBJECT-TYPE
SYNTAX ReferenceId
PIB-REFERENCES { frwkFeedbackLinkEntry }
STATUS current
DESCRIPTION
"The ReferenceId of the Linkage policy instance used
to base this usage policy instance upon."
::= { frwkFeedbackTrafficEntry 2 }
frwkFeedbackTrafficPacketCount OBJECT-TYPE
SYNTAX Usage64
STATUS current
DESCRIPTION
"The count of packets handled by the associated
element. The initial value of 0 is set when the
frwkFeedbackTraffic instance is created, for example
triggered through the creation of a frwkFeedbackLink
instance."
::= {frwkFeedbackTrafficEntry 3}
frwkFeedbackTrafficByteCount OBJECT-TYPE
SYNTAX Usage64
STATUS current
DESCRIPTION
"The byte count of packets handled by the associated
element. The initial value of 0 is set when the
frwkFeedbackTraffic instance is created."
::= { frwkFeedbackTrafficEntry 4}the interface version is basically the same energy, but it also keeps track of an interface index 🦋 it's a usage class with a little extra sparkle, and it's report-only 💅
--
-- The traffic usage class, qualified for an interface
--
frwkFeedbackIfTrafficTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkFeedbackIfTrafficEntry
PIB-ACCESS report-only
STATUS current
DESCRIPTION
"A usage class similar to the basic Traffic class that
also contains a reference to an interface index. This
class should be used with an underspecified selection
criteria entry from the frwkRoleComboTable that matches
an element that can be assigned to multiple interface
indices. The interface field can be used to associate
the instances of this class with the specific element's
assignment."
::= { frwkFeedbackUsageClasses 2 }
frwkFeedbackIfTrafficEntry OBJECT-TYPE
SYNTAX FrwkFeedbackIfTrafficEntry
STATUS current
DESCRIPTION
"Defines the attributes the PEP is to monitor,
record and report."
PIB-INDEX {frwkFeedbackIfTrafficId}
UNIQUENESS { frwkFeedbackIfTrafficLinkRefID,
frwkFeedbackIfTrafficIfIndex }
::= {frwkFeedbackIfTrafficTable 1}
FrwkFeedbackIfTrafficEntry ::= SEQUENCE {
frwkFeedbackIfTrafficId InstanceId,
frwkFeedbackIfTrafficLinkRefID ReferenceId,
frwkFeedbackIfTrafficIfIndex InterfaceIndex,
frwkFeedbackIfTrafficPacketCount Usage64,
frwkFeedbackIfTrafficByteCount Usage64
}
frwkFeedbackIfTrafficId OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"Arbitrary integer index that uniquely identifies
an instance of the class."
::= { frwkFeedbackIfTrafficEntry 1 }
frwkFeedbackIfTrafficLinkRefID OBJECT-TYPE
SYNTAX ReferenceId
PIB-REFERENCES { frwkFeedbackLinkEntry }
STATUS current
DESCRIPTION
"The ReferenceId of the Linkage policy instance used
to base this usage policy instance upon."
::= { frwkFeedbackIfTrafficEntry 2 }
frwkFeedbackIfTrafficIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
STATUS current
DESCRIPTION
"The value of this attribute is the ifIndex which is
associated with the specified RoleCombination and
interface capability set name."
::= { frwkFeedbackIfTrafficEntry 3 }
frwkFeedbackIfTrafficPacketCount OBJECT-TYPE
SYNTAX Usage64
STATUS current
DESCRIPTION
"The count of packets handled by the associated
element. The initial value of 0 is set when the
frwkFeedbackIfTraffic instance is created."
::= { frwkFeedbackIfTrafficEntry 4 }
frwkFeedbackIfTrafficByteCount OBJECT-TYPE
SYNTAX Usage64
STATUS current
DESCRIPTION
"The byte count of packets handled by the associated
element. The initial value of 0 is set when the
frwkFeedbackIfTraffic instance is created."
::= { frwkFeedbackIfTrafficEntry 5 }next up, the selection classes get their own little group 🎀 they all live together under one roof, so you know exactly where to find them 🏠
--
-- All Selection classes are in the separate
-- FrwkFeedbackSelectionClasses group
--
frwkFeedbackSelectionClasses
OBJECT IDENTIFIER ::= { frwkFeedbackPib 3 }
--
-- The Role Combination Filter Selection Table
--
frwkFeedbackRoleFilterSelTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkFeedbackRoleFilterSelEntry
PIB-ACCESS install
STATUS current
DESCRIPTION
"A selection class that defines selection of objects
for monitoring based on the role combination,
capability set and a filter."
::= { frwkFeedbackSelectionClasses 1 }
frwkFeedbackRoleFilterSelEntry OBJECT-TYPE
SYNTAX FrwkFeedbackRoleFilterSelEntry
STATUS current
DESCRIPTION
"Each instance selects a filter on multiple interfaces
that share the same frwkRoleCombo instance."
PIB-INDEX { frwkFeedbackRoleFilterSelId}
UNIQUENESS { frwkFeedbackRoleFilterSelRCombo,
frwkFeedbackRoleFilterSelFilter
}
::= {frwkFeedbackRoleFilterSelTable 1}
FrwkFeedbackRoleFilterSelEntry ::= SEQUENCE {
frwkFeedbackRoleFilterSelId InstanceId,
frwkFeedbackRoleFilterSelRCombo ReferenceId,
frwkFeedbackRoleFilterSelFilter Prid
}
frwkFeedbackRoleFilterSelId OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"Arbitrary integer index that uniquely identifies
an instance of the class."
::= { frwkFeedbackRoleFilterSelEntry 1 }
frwkFeedbackRoleFilterSelRCombo OBJECT-TYPE
SYNTAX ReferenceId
PIB-REFERENCES { frwkRoleComboEntry }
STATUS current
DESCRIPTION
"The ReferenceId of the frwkRoleComboTable policy
instance used for selection."
::= { frwkFeedbackRoleFilterSelEntry 2 }
frwkFeedbackRoleFilterSelFilter OBJECT-TYPE
SYNTAX Prid
STATUS current
DESCRIPTION
"The identifier of a filter instance. Valid classes
are the subclasses of frwkBaseFilter:
- frwkIpFilter
- frwk802Filter
- frwkILabelFilter"
::= { frwkFeedbackRoleFilterSelEntry 3 }now the compliance section, which is the part that spells out what you need to implement 📋 it's giving checklist 💀
--
-- Compliance Section
--
frwkFeedbackPibConformance
OBJECT IDENTIFIER ::= { frwkFeedbackPib 4 }
frwkFeedbackPibCompliances
OBJECT IDENTIFIER ::= { frwkFeedbackPibConformance 1 }
frwkFeedbackPibGroups
OBJECT IDENTIFIER ::= { frwkFeedbackPibConformance 2 }
frwkFeedbackPibCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Describes the requirements for conformance to the feedback
framework PIB"
MODULE -- this module
MANDATORY-GROUPS { frwkFeedbackLinkCapsGroup,
frwkFeedbackLinkGroup,
frwkFeedbackActionGroup }
GROUP frwkFeedbackActionListGroup
DESCRIPTION
"The frwkFeedbackActionListGroup is mandatory if
actions on subsets linkEntries are to be
supported."
GROUP frwkFeedbackTrafficGroup
DESCRIPTION
"The frwkFeedbackTrafficGroup is mandatory if
monitoring of traffic data is to be supported."
GROUP frwkFeedbackTrafficThresGroup
DESCRIPTION
"The frwkFeedbackTrafficThresGroup is mandatory
if conditional reporting of traffic usage
thresholds is to be supported."
GROUP frwkFeedbackIfTrafficGroup
DESCRIPTION
"The frwkFeedbackIfTrafficGroup is mandatory if
per-interface usage collection of traffic data is
to be supported."
GROUP frwkFeedbackRoleFilterSelGroup
DESCRIPTION
"The frwkFeedbackRoleFilterSelGroup is mandatory
if monitoring of filters referenced through the
frwkRoleCombo class is to be supported."
::= { frwkFeedbackPibCompliances 1 }and last but not least, the object groups 👑 each one is a bundle of objects that go together, so it's like a playlist for the PIB 🎶
frwkFeedbackLinkCapsGroup OBJECT-GROUP
OBJECTS {
frwkFeedbackLinkCapsId,
frwkFeedbackLinkCapsSelection,
frwkFeedbackLinkCapsUsage,
frwkFeedbackLinkCapsThreshold }
STATUS current
DESCRIPTION
"Objects from the frwkFeedbackLinkCapsTable."
::= { frwkFeedbackPibGroups 1 }
frwkFeedbackLinkGroup OBJECT-GROUP
OBJECTS {
frwkFeedbackLinkId,
frwkFeedbackLinkSel,
frwkFeedbackLinkUsage,
frwkFeedbackLinkInterval,
frwkFeedbackLinkThreshold,
frwkFeedbackLinkFlags }
STATUS current
DESCRIPTION
"Objects from the frwkFeedbackLinkTable."
::= { frwkFeedbackPibGroups 2 }
frwkFeedbackActionGroup OBJECT-GROUP
OBJECTS {
frwkFeedbackActionId,
frwkFeedbackActionIndicator,
frwkFeedbackActionSpecificPri,
frwkFeedbackActionList }
STATUS current
DESCRIPTION
"Objects from the frwkFeedbackActionTable."
::= { frwkFeedbackPibGroups 3 }
frwkFeedbackActionListGroup OBJECT-GROUP
OBJECTS {
frwkFeedbackActionListId,
frwkFeedbackActionListTag,
frwkFeedbackActionListRefID }
STATUS current
DESCRIPTION
"Objects from the frwkFeedbackActionListTable."
::= { frwkFeedbackPibGroups 4 }
frwkFeedbackTrafficGroup OBJECT-GROUP
OBJECTS {
frwkFeedbackTrafficId,
frwkFeedbackTrafficLinkRefID,
frwkFeedbackTrafficPacketCount,
frwkFeedbackTrafficByteCount }
STATUS current
DESCRIPTION
"Objects from the frwkFeedbackTrafficTable."
::= { frwkFeedbackPibGroups 5 }
frwkFeedbackTrafficThresGroup OBJECT-GROUP
OBJECTS {
frwkFeedbackTrafficThresId,
frwkFeedbackTrafficThresPackets,
frwkFeedbackTrafficThresBytes }
STATUS current
DESCRIPTION
"Objects from the frwkFeedbackTrafficThresTable."
::= { frwkFeedbackPibGroups 6 } frwkFeedbackIfTrafficGroup OBJECT-GROUP
OBJECTS {
frwkFeedbackIfTrafficId,
frwkFeedbackIfTrafficLinkRefID,
frwkFeedbackIfTrafficIfIndex,
frwkFeedbackIfTrafficPacketCount,
frwkFeedbackIfTrafficByteCount }
STATUS current
DESCRIPTION
"Objects from the frwkFeedbackIfTrafficTable."
::= { frwkFeedbackPibGroups 7 }
frwkFeedbackRoleFilterSelGroup OBJECT-GROUP
OBJECTS {
frwkFeedbackRoleFilterSelId,
frwkFeedbackRoleFilterSelRCombo,
frwkFeedbackRoleFilterSelFilter }
STATUS current
DESCRIPTION
"Objects from the frwkFeedbackRoleFilterSelTable."
::= { frwkFeedbackPibGroups 8 }
ENDThat's the whole module wrapped up, bestie 🎀 Two more object groups to make the tables behave, and then we're on to the grown-up stuff. ✨
5. Security Considerations 🔐
Okay, security time, and I'm taking it seriously 💅 This PIB defines structured information that can be sensitive when it's carried over the COPS protocol [COPS-PR].
No passwords and no money amounts live in these classes, so it's not a secrets vault 🙈 But unauthorized access or changes to the information defined here could still mess with network operations, or reveal sensitive business or personal info. Not cute.
Here's the class-by-class breakdown:
frwkFeedbackLinkCaps: This one has the ACCESS clause'notify'. Reading it reveals the feedback collection capabilities of the COPS client, and malicious changes could wreck feedback operation by tricking the server into generating corrupt feedback configuration. 😭frwkFeedbackLinkTable,frwkFeedbackAction,frwkFeedbackActionList,frwkFeedbackTrafficThres,frwkFeedbackRoleFilterSel: These have the ACCESS clause'install'and let the COPS server control feedback collection and reporting on the client. Access exposes the client's configuration, and malicious changes could disrupt network or business operations and raise privacy issues. Main character energy for the wrong person is a no. 💀frwkFeedbackTraffic,frwkFeedbackIfTraffic: These have the ACCESS clause'report-only'and hold the usage information sent from the COPS client to the server. Unauthorized access may reveal detailed information about the network and its users, and malicious changes may affect network and business operations. 🦋
Security is a team sport, so please read this part: [COPS] and [COPS-PR] define mechanisms for securing COPS protocol communication, and implementations of COPS servers or clients supporting this PIB MUST follow the security guidelines specified there. 🫶
6. IANA Considerations 🌈
This document describes the frwkFeedbackPib Policy Information Base (PIB) module, which gets registered under the "pib" branch registered with IANA. IANA has assigned PIB number 5. ⭐
This PIB uses "all" in the SUBJECT-CATEGORY clause, so it applies to all COPS client types. No new COPS client type is requested for this PIB. Simple and iconic 👑
7. Acknowledgements 💜
The authors want to thank Dave Durham, Ravi Sahita, and Russell Fenger of Intel, plus John K. Gallant of WorldCom, for their contribution to this document. Thank you, queens 🧚
8. References 📚
8.1. Normative References
[COPS] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan,
R. and A. Sastry, "The COPS (Common Open Policy
Service) Protocol", RFC 2748, January 2000.
[COPS-PR] Chan, K., Seligson, J., Durham, D., Gai, S.,
McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar,
R. and A. Smith, "COPS Usage for Policy
Provisioning", RFC 3084, May 2001.
[IFMIB] McCloghrie, K. and F. Kastenholz, "The Interfaces
Group MIB", RFC 2863, June 2000.
[FR-PIB] Sahita, R., Hahn, S., Chan, K. and K. McCloghrie,
"Framework Policy Information Base", RFC 3318, March
2003.
[FEEDBACKFWK] Rawlins, D., Kulkarni, A., Bokaemper, M. and K. Chan,
"Framework for Policy Usage Feedback for Common Open
Policy Service with Policy Provisioning (COPS-PR)",
RFC 3483, March 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
J., Rose, M. and S. Waldbusser, "Structure of
Management Information Version 2 (SMIv2)", STD 58,
RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
J., Rose, M. and S. Waldbusser, "Textual Conventions
for SMIv2", STD 58, RFC 2579, April 1999.8.2. Informational References
[COPS-TLS], Walker, J., Kulkarni, A.,"COPS Over TLS", Work in
Progress.
[DIFFSERV-PIB] Chan, K., Sahita, R., Hahn, S. and K. McCloghrie,
"Differentiated Services Quality of Service Policy
Information Base", RFC 3317, March 2003.9. Authors' Addresses 🍓
Meet the squad who built this, bestie 🫶
Diana Rawlins
MCI
400 International Parkway
Richardson, Texas 75081
Phone: 972-729-4071
EMail: Diana.Rawlins@mci.com
Amol Kulkarni
JF3-206
2111 NE 25th Ave
Hillsboro, Oregon 97124
Phone: 503-712-1168
EMail: amol.kulkarni@intel.com
Kwok Ho Chan
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821 USA
Phone: 978-288-8175
EMail: khchan@nortelnetworks.com
Martin Bokaemper
Juniper Networks
700 Silver Seven Road
Kanata, ON, K2V 1C3, Canada
Phone: 613-591-2735
EMail: mbokaemper@juniper.net
Dinesh G Dutt
Cisco Systems, Inc.
170 Tasman Dr.
San Jose, CA 95134-1706
Phone: 408-527-0955
EMail: ddutt@cisco.com10. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you for reading all the way to the end, bestie 💖
📦 where this page comes from
- ietf: rfc3571 2003-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms