From owner-rap@ops.ietf.org Thu Dec 19 09:26:43 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16768 for ; Thu, 19 Dec 2002 09:26:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P1en-000B8W-00 for rap-data@psg.com; Thu, 19 Dec 2002 06:28:13 -0800 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #2) id 18P1ek-000B7G-00 for rap@ops.ietf.org; Thu, 19 Dec 2002 06:28:10 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gBJERbD08112 for ; Thu, 19 Dec 2002 09:27:37 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Dec 2002 15:27:32 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15583CF1C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Rap-wg (E-mail)" Subject: RE: AD review of draft-ietf-rap-feedback-fr-pib-04.txt Date: Thu, 19 Dec 2002 15:27:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-0.1 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Thanks for the revision. My comments inline below. Current real concerns: - Section 3.2 start off with new text stating that SNMP Counter32 and Counter64 are not supported by SPPI. What is this based on? I do not understand that statement at all. - And as I explain below in my answers/comments, I am not sure that your new definitions of Usage32/Usage64 make sense. Pls explain in relation to the above and to my comments inline below. Minor things - pls answer my questions inline below - In the Abstract, it is probably better to change This document describes a Policy Information Base (PIB) to control policy usage collection and reporting in a device. The provisioning classes specified here allow a Policy Decision Point (PDP) to select which policy objects should collect usage information, what information should be collected and when it should be reported. This PIB requires the presence of other PIBs (defined elsewhere) that provide the policy objects that usage information is collected from. into something aka: This document describes a portion of the Policy Information Base (PIB) to control policy usage collection and reporting in a device. The provisioning classes specified here allow a Policy Decision Point (PDP) to select which policy objects should collect usage information, what information should be collected and when it should be reported. This PIB module requires the presence of other PIB modules (defined elsewhere) that provide the policy objects that usage information is collected from. The idea being (similar as with the MIB), that there is only ONE PIB and several/multiple PIB Modules that together make up the PIB. Could I have a response to this review today? Do you think you can fix a new rev today, that would allow me to put it on IESG agenda for 27 Dec My original comments to rev 03: > > > the following draft to the IESG for consideration as a > > > standards track RFC: > > > http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-03.txt > > > > My main question is if we want to go through a similar process as we did > > for the earlier PIBs, or if the WG rather decides that this PIB can be > > also informational, just as the Framework PIB and the Diffserv PIB. > > > The discussion with WG chair and my co-AD leaves me at the position > that I will not consider the PIB for STDs track, but instead will > handle it for Informational, with the same concerns as reaised with > earlier PIBs. That situation has not changed. > That has not changed, so we'll go for Informational. > Further comments to this document: > > - mmm.. the module-identity is named: feedbackPolFrameworkPib > then all the rest of the PIB objects/classes/attrs are prefixed > with frwkFeedback. WOuld it no be best to keep the prefix of the > MIB module and the others the same. I see that is done. Thanks > - I am missing a REVISION clause in the MODULE-IDENTITY macro You have added that now. Thanks. But the LAST-UPDATED and the REVISION date/time need to be in sync. > - I do not think that labels for enumerations canstart with Uppercase > and have underscores Thanks for fixing > - In some cases I see in a description clause of a table or entry > "class", or sometimes "table" or sometimes "pri" or "prc"... > I would strongly recommend to stick to one term and use that. > We had similar problems back when we reviewed diffserv and framework > PIBs. Pls check with those and use same terminology. Thanks for tidying up. > - frwkFeedbackActionListEntry in desxription clause: > "This class identifies a set of linkage instances..." > mmm.. I guess the table defines a "set", but am entry is one > instance of the class, no? probably just language. thanks for better wording > - Not sure if it is me, but I do not understand the DESCRIPTION > clauses of frwkFeedbackActionListGroup and frwkFeedbackActionListRefID > How does that work? Can you be more elaborate so I can understand Mmm... I guess the WG members understand it... It's a tidbit better though. > - can you explain (in the description clause) how the seOID is used > for the selection process for object/attribute > frwkFeedbackSelUsageComboCapsSelection it is a bit better > - Is the example code in description clause of > frwkFeedbackTrafficThresholdTable actually C code or is it > pseudo code? And where do these fields that you are checking > come from ?? Is NULL a NULL ptr or the zero value? > Would be best to be clear on those questions. Thanks for better understandable text > - I see: > frwkFeedbackTrafficUsagePacketCount OBJECT-TYPE > SYNTAX Counter64 > STATUS current > > DESCRIPTION > "The count of packets handled by the associated > element during the reporting interval." > but a Counter64 has Counter64 semantics and has nothing to do with > an interval. See RFC2578 definition of Counter64. > - A bit later in the PIB you do so again, e.g. another occurance Mmm... I see that you now have defined two TCs Usage32 and Usage64 that look very much like a Counter32 or a Counter64, if not that, then they look very much like a ZeroBasedCounter32 (as defined in RMON MIB, RFC2021) and ZerobasedCounter64 (as defined in HNUM-TC, RFC2856) Is this wise? Anyway, your own TC says: Usage64 initial value is 0 and the object-type using Usage64 needs to specify when it is initialized. But when the TC is used, your object DESCRIPTION clauses do not specify when it is initialized!! May be it is implicit.. but would be good to specify > - I see no MODULE COMPLIANCE statement in the PIB !!?? Thanks for adding those > - the security considerations section does not prescribe which > of the possible security mechanisms MUST be supported. But > possibly is met by the specs RFC2748 and 3084. If you agree, then > you should instead say that that is the case and point to those > RFCs as normative references. > But the security section needs to list details about which classes > and or attributes are sensitive and why. Security ADs will look > for that. > Thanks for adding the new text. That I think helps a lot for the Sec ADs to approve too. > - and last but not least, sending this to SMILINT for a compile > check I get a very long list of errors and warnings. Probably > some are no problem.. but I see that quite a few are srious > problems. Please fix. SMILINT now compiles this PIB module clean. Great! > How can the WG have aggreed that this PIB doc is ready for > consideration as PS ?? > Oh well. > admin/bureaucratic/editorial/nits: > - there are so called Redmond characters (e.g. non-ascii) in th > text. Pls fix to plain ascii Seems fixed now, thanks > - RFC Editor does not want acronyms in title and/or abstract > See: http://www.rfc-editor.org/policy.html fixed thank you > - I think it is more commom to have the "conventions used in this document" > (that is the use of MUST language and such) after the TOC > - in the example on page 8-0, you use xxxEntry and xxx PRC terminology > Might be better to choose one and stick to that, no? thanks for better consistency > - sect 3.2 at the end (i.e. top of page 10) > missing 2) ?? aha, now no longer ordered lists ;-) Anyway, a 1) does make people to expect a 2) and possibly more > - would be good to add WG mailing list infor in CONTACT info > I also see only 4 of the 5 authors in the contact info. > that is fine with me... but ?? thansk for addition > - frwkFeedbackActionEntry has in description: > "An instance of this class can indicates a action...' > proper english? > - references must be split in normative and informative, again > see: http://www.rfc-editor.org/policy.html Thanks for doing so. I now am missing reference [RFC2119] ??!! > - I see no IANA considerations to request assignment of the PIB oid Thanks for adding that > - I am missing an IPR section as per RFC2026 sect 10. > I see you did not add it. If we go for Informational, that is OK (I think) It would not be OK for STDS track Bert From owner-rap@ops.ietf.org Thu Dec 19 09:43:26 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17064 for ; Thu, 19 Dec 2002 09:43:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P1vA-000BwT-00 for rap-data@psg.com; Thu, 19 Dec 2002 06:45:08 -0800 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #2) id 18P1v7-000BtZ-00 for rap@ops.ietf.org; Thu, 19 Dec 2002 06:45:05 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gBJEiWD18022 for ; Thu, 19 Dec 2002 09:44:32 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Dec 2002 15:44:31 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15583CF30@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Rap-wg (E-mail)'" Subject: RE: AD-review of draft-ietf-rap-feedback-frwk-03.txt Date: Thu, 19 Dec 2002 15:44:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-0.1 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk OK, so Just reviewed revison 3. A few minor nits remain, see below. But I can address these with an RFC Editor note as follows: - On first page, change [RFC-2119] into [RFC2119] - in the Abstract, change [RFC2748] into (RFC2748) - Move reference to RFC2119 from Informative to Normative section I will put doc on IESG agenda. See details below. My original comments on rev 02 were: > > > RAP WG, I got this requestst from your WG chairs. > > > > > > > > I would like to submit the following draft to the IESG for > > > > consideration as a Informational RFC: > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr > > > wk-02.txt > > > > > > > > > > My AD-evaluation comments (I understand that a lot of it is > > > admin/bureaucratic, but you basically knew that and it is always best > > > to avoid such comments at this late stage).: > > > > > > 1. Title and abstract contain Acronyms that RFC-Editor no > > > longer want to see. You have to expand them. > > > See: http://www.rfc-editor.org/policy.html > > > OK, fixed. > > > 2. abstract should not have references. You have a [COPS] reference. > > > I think you can just use RFC 2478 and leave the ref out. > > > See: http://www.rfc-editor.org/policy.html > > > What I meant was to use (RFC2748) instead of [RFC2748]. The RFC-Editor policy does not allow references in the abstract. > > > 3. References need to be split in normative and informative references > > > OK, thanks. RFC2119 needs to be a normative reference though > > > 4. You have text in "Conventions used in this document" on MUST > > > language and such. That is good. Probably better to include it in > > > the intro section (or at least after the abstract). > > > But more important, you need to add [RFC-2119] reference to the > > > references section > > > Done, thanks. The [RFC-2119] on the fromt page however does not match up with the [RFC2119] in the References section itself. > > > 5. I think it would be good to do some sort of terminology at the > > > beginning of the intro. Either explain terms like PDP, PEP, SIP, PRC > > > (or at least extend the acronym first time it is used). Might also > > > add a reference to the terminology as per RFC3198 > > > I see the Glossary, Thanks > > > 6. You seem to be using (what we call) redmond-characters in a few > > > places: 2nd para sect 2, sdt para sect 7, may be other places > > > OK, they seem to have dissapeared. > > > 7. Last sect of para 4.1. > > > Could we add HOW a PDP may sollicit usage feedback/ > > > Thanks, I see it > > > 8. sect 7, 2nd para > > > Can you ellaborate on what sort of "additional information > > > must be provided to uniquely identify...." > > > Thanks for the additions > > > 9. Sect 8, can you explain what a "context switch" is? > > > Thanks again > > > 10. Security consideration. > > > - You must specify one mandatory to implement. > > > you are now just saying "...protection can be accomplished". > > > - When you specify the use of IPsec, pls do not just say > > > "just use IPsec". A clearer statement is needed, > > > specifying the necessary IPsec selectors (per RFC 2401) > > > and the way the cryptographically protected endpoints are > > > related to the authorization model, i.e., who can do what. > > > The changes you made are fine with me (and porbably with sec ADs too, but we'll see when it goes to IESG). > > Bert > > > Bert From owner-rap@ops.ietf.org Thu Dec 19 11:47:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19734 for ; Thu, 19 Dec 2002 11:47:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P3s0-000HdN-00 for rap-data@psg.com; Thu, 19 Dec 2002 08:50:00 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.36 #2) id 18P3rx-000HdA-00 for rap@ops.ietf.org; Thu, 19 Dec 2002 08:49:58 -0800 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id gBJGnlGs024294 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 19 Dec 2002 17:49:47 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id gBJGnlAa003313 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 19 Dec 2002 17:49:47 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id gBJGnkHN003310; Thu, 19 Dec 2002 17:49:46 +0100 Date: Thu, 19 Dec 2002 17:49:46 +0100 Message-Id: <200212191649.gBJGnkHN003310@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: bwijnen@lucent.com CC: rap@ops.ietf.org In-reply-to: <7D5D48D2CAA3D84C813F5B154F43B15583CF1C@nl0006exch001u.nl.lucent.com> (bwijnen@lucent.com) Subject: Re: AD review of draft-ietf-rap-feedback-fr-pib-04.txt References: <7D5D48D2CAA3D84C813F5B154F43B15583CF1C@nl0006exch001u.nl.lucent.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> Wijnen, Bert (Bert) writes: Bert> Current real concerns: - Section 3.2 start off with new text Bert> stating that SNMP Counter32 and Counter64 are not supported by Bert> SPPI. What is this based on? I do not understand that statement Bert> at all. RFC 3159 sections 7.1.1 and 7.1.5 I would say. /js -- Juergen Schoenwaelder From owner-rap@ops.ietf.org Thu Dec 19 11:53:09 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19833 for ; Thu, 19 Dec 2002 11:53:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P3xL-000Hya-00 for rap-data@psg.com; Thu, 19 Dec 2002 08:55:31 -0800 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #2) id 18P3x9-000HuF-00 for rap@ops.ietf.org; Thu, 19 Dec 2002 08:55:19 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gBJGskD06228 for ; Thu, 19 Dec 2002 11:54:46 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Dec 2002 17:54:45 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15583CFA1@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Juergen Schoenwaelder , bwijnen@lucent.com Cc: rap@ops.ietf.org Subject: RE: AD review of draft-ietf-rap-feedback-fr-pib-04.txt Date: Thu, 19 Dec 2002 17:54:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-0.1 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk > Bert> Current real concerns: - Section 3.2 start off with new text > Bert> stating that SNMP Counter32 and Counter64 are not supported by > Bert> SPPI. What is this based on? I do not understand that statement > Bert> at all. > > RFC 3159 sections 7.1.1 and 7.1.5 I would say. > > /js > Blush... indeed it says so. Mmm... so why would a TC like Usage32/64 be any better? Bert From owner-rap@ops.ietf.org Thu Dec 19 12:01:21 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20031 for ; Thu, 19 Dec 2002 12:01:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P45k-000ISG-00 for rap-data@psg.com; Thu, 19 Dec 2002 09:04:12 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.36 #2) id 18P45c-000IRz-00 for rap@ops.ietf.org; Thu, 19 Dec 2002 09:04:04 -0800 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id gBJH3xGs026367 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 19 Dec 2002 18:03:59 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id gBJH3xAa003636 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 19 Dec 2002 18:03:59 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id gBJH3wYc003633; Thu, 19 Dec 2002 18:03:58 +0100 Date: Thu, 19 Dec 2002 18:03:58 +0100 Message-Id: <200212191703.gBJH3wYc003633@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: bwijnen@lucent.com CC: bwijnen@lucent.com, rap@ops.ietf.org In-reply-to: <7D5D48D2CAA3D84C813F5B154F43B15583CFA1@nl0006exch001u.nl.lucent.com> (bwijnen@lucent.com) Subject: Re: AD review of draft-ietf-rap-feedback-fr-pib-04.txt References: <7D5D48D2CAA3D84C813F5B154F43B15583CFA1@nl0006exch001u.nl.lucent.com> X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> Wijnen, Bert (Bert) writes: Bert> Blush... indeed it says so. Mmm... so why would a TC like Bert> Usage32/64 be any better? I guess Keith just wanted to be very clear that PIBs are not for monitoring and just for configuration. But to do real things, you need to get a feedback loop running and so once you have COPS-PR running for configuration and control, you also want to get monitoring^H^H^H^H^H^H^H^H^H usage data. In Keith world, you would use SNMP and the DiffServ MIB to retrieve monitoring data and that is why it is crucial that MIBs and PIBs are very closely related. /js -- Juergen Schoenwaelder From owner-rap@ops.ietf.org Thu Dec 19 12:26:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20531 for ; Thu, 19 Dec 2002 12:26:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P4TP-000Jkp-00 for rap-data@psg.com; Thu, 19 Dec 2002 09:28:39 -0800 Received: from [204.92.244.243] (helo=kanatamail.kanata.unispherenetworks.ca) by psg.com with esmtp (Exim 3.36 #2) id 18P4TN-000JjH-00 for rap@ops.ietf.org; Thu, 19 Dec 2002 09:28:37 -0800 Received: by mailkanata.unispherenetworks.ca with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Dec 2002 12:27:36 -0500 Message-ID: From: "Bokaemper, Martin" To: "'Wijnen, Bert (Bert)'" , "Rap-wg (E-mail)" Subject: AD review of draft-ietf-rap-feedback-fr-pib-04.txt Date: Thu, 19 Dec 2002 12:27:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.4 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk [Sorry for the duplicate(?) ... I was still subscribed with an old email address] -----Original Message----- From: Bokaemper, Martin Sent: Thursday, December 19, 2002 12:03 PM To: Wijnen, Bert (Bert); Rap-wg (E-mail) Subject: RE: AD review of draft-ietf-rap-feedback-fr-pib-04.txt Hello Bert, > Thanks for the revision. Sorry, I forgot to post a change summary in the pre/post meeting hustle. > My comments inline below. > > Current real concerns: > - Section 3.2 start off with new text stating that SNMP Counter32 and > Counter64 are not supported by SPPI. What is this based on? > I do not understand that statement at all. RFC3159 (SPPI) sections 7.1.1 and 7.1.5 say "The Counter[32/64] type is not supported by the SPPI" When addressing the comment on the Counter types in the previous revision I stumbled over these sections and read them as 'these types are not to be used in PIB modules'. > - And as I explain below in my answers/comments, I am not sure that > your new definitions of Usage32/Usage64 make sense. Pls explain > in relation to the above and to my comments inline below. [and from below] > Mmm... I see that you now have defined two TCs Usage32 and Usage64 > that look very much like a Counter32 or a Counter64, if not that, > then they look very much like a ZeroBasedCounter32 (as defined in RMON > MIB, RFC2021) and ZerobasedCounter64 (as defined in HNUM-TC, RFC2856) > > Is this wise? The intention of the Usage32/64 TCs is to allow absolute readings for cases when the PDP either explicitly or implicitly knows the creation time of the object, so the main difference to Counter32/64 is the initial value of 0. ZeroBasedCounter[32/64] allow that too, so I agree they are more appropriate to use here - I have not been aware of these TCs before. I'll remove the Usage TCs again and will import and use ZeroBasedCounter[32/64] instead. Any issues with that? > > Could I have a response to this review today? Do you think you can fix > > a new rev today, that would allow me to put it on IESG agenda for 27 Dec I'll prepare a new revision with the changes mentioned here this afternoon, so it can go to internet-drafts@ietf.org and this list today. On the 'minor things': > - pls answer my questions inline below > - In the Abstract, it is probably better to change > This document describes a Policy Information Base (PIB) to control > policy usage collection and reporting in a device. [...] > into something aka: > This document describes a portion of the Policy Information Base > (PIB) to control policy usage collection and reporting in a device. [...] > The idea being (similar as with the MIB), that there is only ONE PIB > and several/multiple PIB Modules that together make up the PIB. Will change this. > > - I am missing a REVISION clause in the MODULE-IDENTITY macro > > You have added that now. Thanks. > But the LAST-UPDATED and the REVISION date/time need to be in sync. Will be fixed. [...] > > - Not sure if it is me, but I do not understand the DESCRIPTION > > clauses of frwkFeedbackActionListGroup and frwkFeedbackActionListRefID > > How does that work? Can you be more elaborate so I can understand > Mmm... I guess the WG members understand it... > It's a tidbit better though. Still a convoluted sentence - will make some improvements here. > > - can you explain (in the description clause) how the seOID is used > > for the selection process for object/attribute > > frwkFeedbackSelUsageComboCapsSelection > > it is a bit better Not sure what/how to improve here - will leave unchanged. [...] > > - sect 3.2 at the end (i.e. top of page 10) > > missing 2) ?? > aha, now no longer ordered lists ;-) > Anyway, a 1) does make people to expect a 2) and possibly more The underlying issue is that there is one group that has only one PRC in it, so numbering will always look odd. [...] > > - references must be split in normative and informative, again > > see: http://www.rfc-editor.org/policy.html > > Thanks for doing so. I now am missing reference [RFC2119] ??!! Will add this. [...] > > - I am missing an IPR section as per RFC2026 sect 10. > > > I see you did not add it. If we go for Informational, that is OK (I think) > It would not be OK for STDS track The 'ok' from all authors on this section did not arrive in time before the deadline, so it was not added. That should not be a problem since it's informational. Fixing 'nits' in drafts opens the eye to other nits: RFC3084 (COPS-PR), which is on the standards track, does not seem to have any IPR statement. An accident? ciao, Martin. -- From owner-rap@ops.ietf.org Thu Dec 19 12:35:26 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20852 for ; Thu, 19 Dec 2002 12:35:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P4cj-000KQE-00 for rap-data@psg.com; Thu, 19 Dec 2002 09:38:17 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.36 #2) id 18P4ch-000KQ0-00 for rap@ops.ietf.org; Thu, 19 Dec 2002 09:38:15 -0800 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id gBJHc5Gs031447 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 19 Dec 2002 18:38:05 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id gBJHc5Aa004116 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 19 Dec 2002 18:38:05 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id gBJHc5rf004113; Thu, 19 Dec 2002 18:38:05 +0100 Date: Thu, 19 Dec 2002 18:38:05 +0100 Message-Id: <200212191738.gBJHc5rf004113@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: MBokaemper@juniper.net CC: bwijnen@lucent.com, rap@ops.ietf.org In-reply-to: (MBokaemper@juniper.net) Subject: Re: AD review of draft-ietf-rap-feedback-fr-pib-04.txt References: X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> Bokaemper, Martin writes: Martin> ZeroBasedCounter[32/64] allow that too, so I agree they are Martin> more appropriate to use here - I have not been aware of these Martin> TCs before. I'll remove the Usage TCs again and will import Martin> and use ZeroBasedCounter[32/64] instead. Any issues with Martin> that? ZeroBasedCounter32/64 is derived from Counter32/64 so the encoding is a Counter32/64 on the wire. In SPPI, there is no Counter32/64 and thus there is no defined coding. Also note that ZeroBasedCounter32/64 formally break SMIv2 rules since you are actually not allowed to derive a TC from a TC. Someone needs to check whether this rule also exists in the SPPI. On the other hand, the MIB folks were allowed to ignore this rule so SPPI folks should be treated the same. /js -- Juergen Schoenwaelder From owner-rap@ops.ietf.org Thu Dec 19 13:02:03 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21783 for ; Thu, 19 Dec 2002 13:02:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P52J-000LzF-00 for rap-data@psg.com; Thu, 19 Dec 2002 10:04:43 -0800 Received: from [204.92.244.243] (helo=kanatamail.kanata.unispherenetworks.ca) by psg.com with esmtp (Exim 3.36 #2) id 18P52G-000LyI-00 for rap@ops.ietf.org; Thu, 19 Dec 2002 10:04:40 -0800 Received: by mailkanata.unispherenetworks.ca with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Dec 2002 13:03:39 -0500 Message-ID: From: "Bokaemper, Martin" To: "'Juergen Schoenwaelder'" Cc: bwijnen@lucent.com, rap@ops.ietf.org Subject: RE: AD review of draft-ietf-rap-feedback-fr-pib-04.txt Date: Thu, 19 Dec 2002 13:03:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.1 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk [ Juergen Schoenwaelder wrote] > Martin> ZeroBasedCounter[32/64] allow that too, so I agree they are > Martin> more appropriate to use here - I have not been aware of these > Martin> TCs before. I'll remove the Usage TCs again and will import > Martin> and use ZeroBasedCounter[32/64] instead. Any issues with > Martin> that? > > ZeroBasedCounter32/64 is derived from Counter32/64 so the encoding is > a Counter32/64 on the wire. In SPPI, there is no Counter32/64 and thus > there is no defined coding. [...] It looks like the clean solution is to keep the Usage32/64 TCs we have now which are based on Unsigned32/64 from the SPPI. Thanks, Martin. -- From owner-rap@ops.ietf.org Thu Dec 19 15:15:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26020 for ; Thu, 19 Dec 2002 15:15:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18P76R-0004Ks-00 for rap-data@psg.com; Thu, 19 Dec 2002 12:17:07 -0800 Received: from [204.92.244.243] (helo=kanatamail.kanata.unispherenetworks.ca) by psg.com with esmtp (Exim 3.36 #2) id 18P76I-0004K6-00 for rap@ops.ietf.org; Thu, 19 Dec 2002 12:16:58 -0800 Received: by mailkanata.unispherenetworks.ca with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Dec 2002 15:15:57 -0500 Message-ID: From: "Bokaemper, Martin" To: "Rap-wg (E-mail)" Cc: "'Wijnen, Bert (Bert)'" Subject: FW: draft-ietf-rap-feedback-fr-pib-05.txt submission Date: Thu, 19 Dec 2002 15:15:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2A79B.6BD11830" X-Spam-Status: No, hits=0.1 required=5.0 tests=BALANCE_FOR_LONG_20K,BALANCE_FOR_LONG_40K,EXCHANGE_SERVER, HOT_NASTY,MIME_NULL_BLOCK,OUTLOOK_FW_MSG,SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C2A79B.6BD11830 Content-Type: text/plain; charset="iso-8859-1" Hello! A version of the draft with changes to address Berts comments has just been submitted. The changes: - 'portion of Policy Information Base' change in Abstract - REVISION and LAST-UPDATED clause updated & synced. - Clarified DESCRIPTIONs for frwkFeedbackActionList, frwkFeedbackActionListTable, frwkFeedbackActionListTag and frwkFeedbackActionListRefID. - added [RFC2119] reference - updated DESCRIPTION of Usage64 objects to for initialization of Usage64. - housekeeping ('Last Updated', 'Expiration' and TOC) Unchanged: - Usage32/64 - see todays discussion on the list ciao, Martin. -----Original Message----- From: Bokaemper, Martin Sent: Thursday, December 19, 2002 2:56 PM To: 'Internet-Drafts@ietf.org' Cc: 'Rawlins, Diana'; Bokaemper, Martin; 'Kwok Ho Chan (Kwok Ho Chan [khchan@NortelNetworks.com])'; Hahn, Scott; 'Wijnen, Bert (Bert)'; Kulkarni, Amol; 'ddutt@cisco.com' Subject: draft-ietf-rap-feedback-fr-pib-05.txt submission I would like to submit an updated Internet Draft. This draft is a work of the Resource Allocation Protocol (RAP) WG. The details are as follows: Title : Framework Policy Information Base for Usage Feedback Filename : draft-ietf-rap-feedback-fr-pib-05.txt Please let me know if there are any problems. Thanks, Martin. ------_=_NextPart_000_01C2A79B.6BD11830 Content-Type: text/plain; name="draft-ietf-rap-feedback-fr-pib-05.txt" Content-Disposition: attachment; filename="draft-ietf-rap-feedback-fr-pib-05.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= Internet Draft Diana Rawlins = =0A= Expiration: June 2003 WorldCom = =0A= File: draft-ietf-rap-feedback-fr-pib-05.txt Amol Kulkarni = =0A= Intel = =0A= Kwok Ho Chan = =0A= Nortel Networks = =0A= Martin Bokaemper = =0A= Juniper Networks = =0A= Dinesh Dutt = =0A= Cisco = =0A= =0A= Framework Policy Information Base for Usage Feedback =0A= =0A= Last Updated December 19, 2002 =0A= =0A= Status of this Memo =0A= This document is an Internet-Draft and is in full conformance with = =0A= all provisions of Section 10 of RFC2026. =0A= =0A= Internet-Drafts are working documents of the Internet Engineering = =0A= Task Force (IETF), its areas, and its working groups. Note that = =0A= other groups may also distribute working documents as Internet-=0A= Drafts. =0A= =0A= Internet-Drafts are draft documents valid for a maximum of six =0A= months and may be updated, replaced, or obsoleted by other =0A= documents at any time. It is inappropriate to use Internet-Drafts = =0A= as reference material or to cite them other than as "work in =0A= progress." =0A= =0A= The list of current Internet-Drafts can be accessed at =0A= http://www.ietf.org/ietf/1id-abstracts.txt =0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at = =0A= http://www.ietf.org/shadow.html. =0A= =0A= Abstract =0A= =0A= This document describes a portion of the Policy Information Base = =0A= (PIB) to control policy usage collection and reporting in a = device. =0A= =0A= The provisioning classes specified here allow a Policy Decision = =0A= Point (PDP) to select which policy objects should collect usage = =0A= information, what information should be collected and when it =0A= should be reported. =0A= =0A= This PIB requires the presence of other PIBs (defined elsewhere) = =0A= that provide the policy objects that usage information is = collected =0A= from. =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rawlins et al.@ Expires December 2002 [Page 1] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= Conventions used in this document =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL =0A= NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" = =0A= in this document are to be interpreted as described in [RFC2119]. = =0A= =0A= =0A= Table of Contents =0A= =0A= 1 Introduction.....................................................3 = =0A= 2 General Concepts.................................................3 = =0A= 2.1 Selection, Usage and Linkage Policies..........................3 = =0A= 2.2 Normal Operations..............................................4 = =0A= 2.2.1 Connection Establishment and Initial Configuration Request...4 = =0A= 2.2.2 Unsolicited Reports - Periodic Reporting.....................5 = =0A= 2.2.3 Unsolicited Reports - Reporting Conditions...................5 = =0A= 2.2.4 Solicited Reports............................................5 = =0A= 2.2.5 Resuming and Suspending Periodic Feedback Reporting..........6 = =0A= 2.2.6 Failover.....................................................6 = =0A= 2.3 Usage Policy and Under-specified Selection Criteria............6 = =0A= 3 Summary of the Feedback Framework Policy Information Base........7 = =0A= 3.1 SPPI ACCESS clause report-only.................................7 = =0A= 3.2 Usage32 and Usage64 textual conventions........................7 = =0A= 3.3 Feedback Groups and PRCs.......................................8 = =0A= 3.3.1 Feedback Action..............................................8 = =0A= 3.3.2 Feedback Action List.........................................9 = =0A= 3.3.3 Feedback Linkage Capability..................................9 = =0A= 3.3.4 Feedback Linkage.............................................9 = =0A= 3.3.5 Feedback Traffic Statistics Threshold.......................10 = =0A= 4 The Feedback Framework PIB Module...............................10 = =0A= 6 IANA Considerations.............................................29 = =0A= 7 Acknowledgements................................................29 = =0A= 8 Authors' Addresses..............................................29 = =0A= 9 References......................................................30 = =0A= 9.1 Normative References..........................................30 = =0A= 9.2 Informational References......................................31 = =0A= 10 Copyright......................................................31 = =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rawlins et al. Expires June 2003 [Page 2] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= =0A= 1 Introduction =0A= =0A= The Framework of COPS-PR Usage Feedback describes the overall =0A= approach to policy usage monitoring and reporting. This document =0A= defines the specific Policy Information Base (PIB) framework for =0A= policy usage feedback. The policy classes for monitoring and =0A= reporting policy usage feedback as well as policy classes for =0A= controlling reporting intervals, suspension, resumption and =0A= solicitation are defined. =0A= =0A= 2 General Concepts =0A= =0A= 2.1 Selection, Usage and Linkage Policies =0A= =0A= There are three basic types of policy used to define what the PEP is = =0A= to monitor, record and report. These are the selection criteria =0A= policy, the usage policy and the feedback report linkage policy. = =0A= =0A= The selection criteria policy is installed by the PDP. It defines = the =0A= conditions used by the PEP to monitor and record a usage policy. The = =0A= selection criteria policy may only be used for defining usage =0A= feedback selection criteria. However, the more general case is that = a =0A= policy that already exists for policy enforcement may also be used = =0A= for specifying feedback usage selection criteria. An example of this = =0A= is the frwkRoleCombo instance, which may be used in defining QoS =0A= enforcement policies but may also be used to specify conditions on = =0A= which to base usage - i.e. count the number of packets meeting the = =0A= criterion of an interface capability set name and role combination. = =0A= =0A= The usage policy defines what attributes are recorded by the PEP. = =0A= These policies have an ACCESS clause of 'report-only'. Generally, = the =0A= usage policies specify counts related to a specific action such as a = =0A= packet being dropped. The feedback framework PIB defines two usage = =0A= policy classes, frwkFeedbackTraffic and frwkFeedbackIfTraffic. Usage = =0A= PRCs may be generic, collecting basic statistics, or they may be =0A= specific to a particular usage. The PDP decides which PRC(s) best = =0A= suit(s) its requirements. The PEP may support only one usage = feedback =0A= PRC, in which case all statistics are gathered using instances of = =0A= that PRC. Alternatively, the PEP may support multiple usage feedback = =0A= PRCs. The PDP then decides which PRC to associate with a particular = =0A= selection criterion. =0A= =0A= =0A= A usage feedback policy and selection policy are tightly associated = =0A= with one another. A third policy, the frwkFeedbackLinkTable, is used = =0A= to associate, or provide a linkage for the selection and usage =0A= policies. The frwkFeedbackLinkTable also specifies when to report = the =0A= usage feedback. The frwkFeedbackLinkTable entry permits the same = =0A= selection criteria instance to be re-used for various usage feedback = =0A= policies. The frwkFeedbackLinkTable contains the value of the =0A= selection criteria instance as well as the value of the usage =0A= feedback PRC. =0A= =0A= =0A= =0A= Rawlins et al. Expires June 2003 [Page 3] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= ----------------- ------------------ ----------------- = =0A= | | | | | | = =0A= | Select Criteria | |Linkage Instance | |Usage Instance | = =0A= | | |-instance ID | |- instance ID | = =0A= | -instance ID |<--|-PRID of selection|--->|- PRID of Linkage| = =0A= | -conditions... | |-PRC of usage | |- counts... | = =0A= | | | | | | = =0A= ----------------- ------------------ ----------------- = =0A= =0A= Figure 1 =0A= =0A= Figure 1 illustrates the relationship between the selection = criteria, =0A= linkage and usage policies. =0A= =0A= The PDP is not aware of the instance identifier of the usage = feedback =0A= policy when installing the selection criteria and feedback linkage = =0A= policies. The usage feedback policy is instantiated on the PEP by = the =0A= installation of a feedback report linkage and the PEP designates the = =0A= instance identifier. The usage feedback policy class always contains = =0A= an attribute of type ReferenceId that contains the instance value of = =0A= the associated frwkFeedbackLinkTable instance installed by the PDP. = =0A= An example of this is the attribute frwkFeedbackTrafficLinkRef =0A= =0A= =0A= 2.2 Normal Operations =0A= =0A= 2.2.1 Connection Establishment and Initial Configuration Request =0A= =0A= The Accounting Timer object in the COPS Connection Accept message = =0A= contains the minimum number of seconds between reporting intervals = as =0A= described in [COPS] and [FEEDBACKfWK]. This is used as the basic = unit =0A= of measurement in defining intervals for specific usage policies = with =0A= the frwkFeedbackLinkInterval attribute. =0A= =0A= The PEP notifies the PDP of the selection criteria policy classes = and =0A= usage policy classes it supports during the initial request for =0A= configuration data using frwkPRCSupport instances [FR-PIB]. The PEP = =0A= also indicates whether it supports the frwkFeedbackLinkTable as = well. =0A= =0A= The PDP responds to the initial request for configuration with a =0A= DECISION that installs policies. The PDP may also specify maximum = =0A= reporting intervals associated with each of the usage policies. This = =0A= is done with the frwkFeedbackLinkInterval attribute in the =0A= frwkFeedbackLink class. It may also specify reporting thresholds by = =0A= including an instance of a threshold class (e.g. =0A= frwkFeedbackTrafficThreshold) in the decision. The PEP monitors and = =0A= records the usage per the conditions defined by its associated =0A= selection criteria policy. Periodically the PEP reports the usage = =0A= with a REPORT message or provides a REPORT when solicited by the = PDP. =0A= The PDP solicits usage feedback with the frwkFeedbackActionIndicator = =0A= attribute of the frwkFeedbackAction class. =0A= =0A= =0A= =0A= Rawlins et al. Expires June 2003 [Page 4] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= 2.2.2 Unsolicited Reports - Periodic Reporting =0A= =0A= Reporting may be periodic in nature and unsolicited. The intervals = =0A= at which the unsolicited reports are provided by the PEP are defined = =0A= in the specific Linkage policies. The defined intervals are based on = =0A= the number of seconds specified by the PDP in the ACCT Timer value. = =0A= The PDP may specify that the associated usage instance be included = =0A= in a periodic unsolicited report only if the threshold is reached = =0A= and/or if the usage value has changed from the previous reporting = =0A= interval. =0A= =0A= There are cases when the PEP must supply unsolicited feedback =0A= reports that may not fall on an interval boundary. The PEP MUST =0A= provide an unsolicited REPORT containing all defined usage instances = =0A= just prior to the PEP issuing a Delete Request State and just prior = =0A= to the PEP de-activating a PIB instance context. =0A= =0A= 2.2.3 Unsolicited Reports - Reporting Conditions =0A= =0A= Periodic unsolicited reports for individual usage feedback instances = =0A= can be suppressed by specifying additional conditions in the =0A= frwkFeedbackLink instances. Supported conditions are: =0A= ChangeOnly =0A= If this flag is set in the frwkFeedbackLinkFlags attribute, the = =0A= associated usage instance is only included in a periodic =0A= unsolicited report if its value changed since the last =0A= unsolicited report. =0A= =0A= Threshold =0A= If this flag is set in the frwkFeedbackLinkFlags attribute, the = =0A= associated usage instance is only included in a periodic =0A= unsolicited report, if the threshold condition referenced in = =0A= the frwkLinkThreshold field evaluates successfully for the =0A= associated usage instance. =0A= =0A= Both conditions can be combined in one frwkFeedbackLinkUsage object. = =0A= In this case both conditions need to succeed for the usage instance = =0A= to be reported. =0A= =0A= Unsolicited reports triggered by a Delete Request State or the =0A= deactivation of a PIB instance are not subject to these conditions - = =0A= all usage objects must be included in these cases. =0A= =0A= =0A= 2.2.4 Solicited Reports =0A= =0A= The PDP may solicit policy usage feedback by issuing an unsolicited = =0A= Decision containing the frwkFeedbackActionIndicator set to =0A= 'solicitReport'. The PEP is to provide a solicited REPORT feedback = =0A= containing usage feedback. The PEP shall continue to provide =0A= periodic feedback as well at the specified intervals established at = =0A= client connection acceptance. =0A= =0A= =0A= Rawlins et al. Expires June 2003 [Page 5] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= The reporting conditions (ChangeOnly and Threshold) do not affect = =0A= solicited reports - all requested usage instances must be included. = =0A= =0A= 2.2.5 Resuming and Suspending Periodic Feedback Reporting =0A= = =0A= =0A= The PDP may suspend usage monitoring and tracking at the PEP with = the =0A= frwkFeedbackActionIndicator set to 'suspendMonitoringAndReports'. = The =0A= PEP must stop tracking usage information and must not issue any =0A= feedback reports. The PDP may only suspend feedback reporting by =0A= setting the ActionIndicator to 'suspendReports'. The PEP must cease = =0A= sending unsolicited reports but is to continue monitoring and =0A= tracking usage. The PDP may resume the sending of feedback reports = =0A= and may resume usage monitoring by setting the ActionIndicator to = =0A= 'resume'. =0A= =0A= The PDP may suspend or resume all usage instances or the PDP may =0A= specify one or more instances that are to be suspended or resumed. = =0A= The frwkFeedbackActionList attribute contains a tag identifier that = =0A= references a list of one or more frwkFeedbackActionList instances. = =0A= =0A= The PDP may halt usage monitoring, tracking and reporting of usage = =0A= policies by removing the associated Linkage entry. =0A= =0A= =0A= 2.2.6 Failover =0A= =0A= In the event the connection is lost between the PEP and PDP, the PEP = =0A= continues to track usage information as long as it continues to =0A= operate with the installed policy. When the locally installed policy = =0A= at the PEP expires, the usage policy data also expires. =0A= =0A= Upon successful reconnection where the PEP is still caching policy, = =0A= the PDP indicates to the PEP that the PEP may resume sending of the = =0A= COPS accounting type report messages. The PDP does this by issuing = an =0A= unsolicited decision containing the frwkFeedbackResumeIndicator set = =0A= to 'resume'. The PEP should resume reporting at the next appropriate = =0A= feedback interval established upon the acceptance of the re-=0A= connection. The PDP is aware of the request state Handle(s) and the = =0A= supported PRCs either through the state synchronization mechanism or = =0A= because the PDP considers itself synchronized with the PEP upon =0A= reconnection. =0A= =0A= 2.3 Usage Policy and Under-specified Selection Criteria =0A= =0A= Some of the usage policy objects created in the PEP with COPS-PR can = =0A= be used by the PEP multiple times - they effectively act as =0A= templates for the objects created by the PEP. COPS-PR only has the = =0A= identity (OID) of the object that is shared between all the =0A= assignments the PEP created, however it is desirable to collect =0A= usage information for each of the derived objects individually. =0A= =0A= This capability is achieved in the feedback framework PIB by =0A= distributing additional information to qualify a specific assignment = =0A= =0A= =0A= Rawlins et al. Expires June 2003 [Page 6] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= of an object between the selection criteria PRC and the feedback =0A= usage PRC. =0A= =0A= A selection criteria PRC that refers to a shared object but contains = =0A= no qualifying information selects all of the object's assignments. = =0A= Such a selection criteria PRC SHOULD be combined with a feedback =0A= usage PRC that includes all the necessary information to identify a = =0A= specific assignment - a single selection criteria policy can then = =0A= result in the generation of many feedback usage objects, one for =0A= each derived object. =0A= =0A= If the selection criteria PRC contains all the required qualifying = =0A= attributes for a specific assignment, it is combined with a feedback = =0A= usage PRC that only contains the desired metrics but no additional = =0A= attributes. =0A= =0A= Example: =0A= =0A= A frwkRoleCombo instance may be used as a selection criteria, =0A= identifying a set of interfaces through their the role =0A= combination and capability set. If it is desired to get per-=0A= interface traffic statistics, the usage PRC has to include an =0A= additional attribute to qualify the specific interface. =0A= =0A= This could be achieved by linking the frwkFeedbackIfTraffic class = =0A= with a frwkRoleCombo instance in a frwkFeedbackLink instance. =0A= Multiple frwkFeedbackIfTraffic instances will be created by the = =0A= PEP, one for each interface selected by the frwkRoleCombo =0A= instance. The frwkFeedbackIfTraffic class contains the =0A= frwkFeedbackIfTrafficIfIndex attribute that allows the PDP to =0A= identify each interface's individual counters when the PEP =0A= reports the frwkFeedbackIfTraffic instances. =0A= =0A= If traffic usage collection is only desired for an individual =0A= interface, a selection criteria should be used that qualifies the = =0A= interface completely, for example a frwkIfRoleCombo instance. =0A= In this case it can be linked to the usage class that has no =0A= additional qualifying attributes, frwkFeedbackTraffic. =0A= =0A= =0A= =0A= 3 Summary of the Feedback Framework Policy Information Base =0A= =0A= =0A= 3.1 SPPI ACCESS clause report-only =0A= =0A= The selection criteria and linkage policy classes follow the =0A= definitions specified by [SPPI]. This structure specifies well-=0A= defined policy classes and their instances residing in a common, =0A= virtual repository [FR-PIB]. The additional PIB-ACCESS clause =0A= attribute of "report-only" denotes the usage policy class reported = by =0A= the PEP. =0A= =0A= 3.2 Usage32 and Usage64 textual conventions =0A= =0A= =0A= Rawlins et al. Expires June 2003 [Page 7] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= =0A= The SPPI does not support the Counter32/64 textual conventions (TC) = =0A= of SNMP - for feedback collection two similar textual conventions = =0A= have been defined in this PIB: Usage32 and Usage64. =0A= =0A= In addition to the differential functionality of 'Counter', where = =0A= only the difference between two samples generally carries =0A= information, a single value of a 'Usage' attribute usually provides = =0A= absolute information, since =0A= - its initial value is known (0) =0A= - no wrap-around events should occur =0A= - the time or event when the initial value was set should be =0A= available directly or indirectly from other objects. =0A= =0A= When 'Usage' attributes are defined in a PRC, events that could =0A= cause a reset of the attribute to it's initial value should be =0A= defined in the description as well as the mechanism that allows the = =0A= PDP to detect the time of the last reset. =0A= =0A= No usual COPS activity however should cause the reset of a Usage =0A= attribute. In the case of a suspension of monitoring activity =0A= (frwkFeedbackActionIndicator set to 'suspendMonitoringAndReports'), = =0A= 'Usage' attributes should keep their values and continue counting = =0A= after monitoring is resumed. =0A= =0A= 3.3 Feedback Groups and PRCs =0A= =0A= These policy classes defined in this PIB are common to account type = =0A= reporting for various technologies and apply to ALL SUBJECT-=0A= CATEGORIES. The policy classes are divided into three new groups, = =0A= namely, The Feedback Report Group, The Feedback Usage Group and The = =0A= Feedback Selection Group. =0A= =0A= The policy classes in the Feedback Report Group are: =0A= - Feedback Action =0A= - Feedback Action List =0A= - Feedback Selection Usage Combination Capability =0A= - Feedback Linkage =0A= - Feedback Traffic Statistics Threshold =0A= =0A= The policy classes in the Feedback Usage Group are: =0A= - Feedback Traffic =0A= - Feedback Interface Traffic =0A= =0A= The policy class in the Feedback Selection Group is: =0A= - Feedback RoleCombo Filter Selection =0A= =0A= 3.3.1 Feedback Action =0A= =0A= The Feedback Action class contains the attributes that specify =0A= action that the PEP is to take regarding policy usage, monitoring = =0A= and tracking. The PDP may suspend usage monitoring and periodic =0A= reporting, suspend periodic reporting only, resume usage and =0A= =0A= Rawlins et al. Expires June 2003 [Page 8] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= periodic reporting or solicit immediate reporting. The action may = =0A= affect all feedback policies or be associated with one or more =0A= frwkFeedbackLink instances. =0A= =0A= The frwkFeedbackActionIndicator attribute defines the action. The = =0A= frwkFeedbackActionPri attribute indicates whether the action applies = =0A= to all of the usage policies or to a list. The =0A= frwkFeedbackActionList attribute is the identifier of the list of = =0A= Linkage policy instances to which the action is to be applied. =0A= =0A= The PDP can solicit the PEP for immediate usage feedback. The PEP = =0A= shall respond with a solicited report containing the usage feedback. = =0A= =0A= The PDP can direct the resumption of usage monitoring and reporting = =0A= per the defined intervals. For example, the PEP may have re-=0A= connected to a PDP and has cached usage policies. The PDP indicates = =0A= to the PEP to resume usage tracking and monitoring and to send all = =0A= the cached usage policy. The PEP shall respond at the next =0A= appropriate interval with an unsolicited report containing the usage = =0A= feedback. =0A= =0A= The PDP can suspend the monitoring of usage policy. The PEP =0A= maintains the current usage that has been monitored but discontinues = =0A= any further monitoring until the PDP directs the PEP to resume =0A= monitoring in a subsequent Decision. =0A= =0A= The PDP can also suspend just the reporting of usage, but not =0A= interrupt the monitoring and tracking of usage. The PEP shall =0A= discontinue sending Report messages with usage feedback until the = =0A= PDP directs the PEP to resume. The PEP then begins reporting the =0A= usage feedback at the next interval. =0A= =0A= =0A= 3.3.2 Feedback Action List =0A= =0A= =0A= This class defines sets of linkage instances that can be referred to = =0A= from the frwkFeedbackActionList attribute. =0A= =0A= 3.3.3 Feedback Linkage Capability =0A= =0A= This class defines the valid selection criteria PRC, usage PRC and = =0A= threshold PRC combinations supported by the PEP. =0A= =0A= 3.3.4 Feedback Linkage =0A= =0A= This class links the selection criteria instance with the usage =0A= class. This table permits the reuse of a selection criteria instance = =0A= for multiple usage policies. =0A= =0A= The linkage table also permits the definition of a maximum reporting = =0A= interval to use when issuing the COPS accounting type reports for = the =0A= =0A= =0A= Rawlins et al. Expires June 2003 [Page 9] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= usage instance. A value of 0 in this attribute indicates that the = =0A= usage policy must be solicited. =0A= =0A= 3.3.5 Feedback Traffic Statistics Threshold =0A= =0A= This class is used to provide threshold values for the attributes = =0A= described in the traffic usage classes below. =0A= =0A= 3.3.6 Feedback Traffic =0A= =0A= This class includes the packet counts, byte counts and a reference = to =0A= the associated Linkage instance. =0A= =0A= 3.3.7 Feedback Interface Traffic =0A= =0A= This class is similar to the previous Feedback Traffic class, except = =0A= that it includes an additional reference to an interface index. This = =0A= class should be used with a selection criteria instance that matches = =0A= an element that is assigned to multiple interfaces. The interface = =0A= field can be used to associate the instances of this table with the = =0A= specific element's assignment. =0A= =0A= =0A= 3.3.8 Feedback RoleCombo Filter Selection =0A= =0A= This class is used as selection criteria based on role combination, = =0A= capability set and a filter instance. =0A= =0A= =0A= =0A= =0A= =0A= 4 The Feedback Framework PIB Module =0A= =0A= =0A= FEEDBACK-FRAMEWORK-PIB PIB-DEFINITIONS ::=3D BEGIN =0A= =0A= IMPORTS =0A= pib, Unsigned32, Unsigned64, Integer32, =0A= MODULE-IDENTITY, OBJECT-TYPE, MODULE-COMPLIANCE, OBJECT-GROUP = =0A= FROM COPS-PR-SPPI =0A= TruthValue, TEXTUAL-CONVENTION =0A= FROM SNMPv2-TC =0A= InstanceId, ReferenceId, Prid, =0A= TagId, TagReferenceId =0A= FROM COPS-PR-SPPI-TC =0A= PrcIdentifierOid, PrcIdentifierOidOrZero =0A= FROM FRAMEWORK-TC-PIB =0A= frwkRoleComboEntry =0A= FROM FRAMEWORK-PIB =0A= InterfaceIndex =0A= FROM IF-MIB; =0A= =0A= =0A= Rawlins et al. Expires June 2003 [Page 10] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= frwkFeedbackPib MODULE-IDENTITY =0A= SUBJECT-CATEGORIES { all } =0A= LAST-UPDATED "200212191400Z" =0A= ORGANIZATION "IETF RAP WG" =0A= CONTACT-INFO "IETF RAP WG =0A= Email: rap@ops.ietf.org =0A= =0A= Diana Rawlins =0A= WorldCom =0A= 901 International Parkway =0A= Richardson, TX 75081 =0A= Phone: 972 729 1044 =0A= Email: diana.rawlins@wcom.com =0A= =0A= Amol Kulkarni =0A= JF3-206 =0A= 2111 NE 25th Ave =0A= Hillsboro, Oregon 97124 =0A= Phone: 503-712-1168 =0A= Email: amol.kulkarni@intel.com =0A= =0A= Kwok Ho Chan =0A= Nortel Networks. =0A= 600 Technology Park Drive =0A= Billerica, MA 01821 USA =0A= Phone: 978-288-8175 =0A= Email: khchan@nortelnetworks.com =0A= =0A= Martin Bokaemper =0A= Juniper Networks =0A= 700 Silver Seven Road =0A= Kanata, ON, K2V 1C3, Canada =0A= Phone: 613-591-2735 =0A= Email: mbokaemper@juniper.net =0A= =0A= Dinesh G Dutt =0A= Cisco Systems, Inc. =0A= 170 Tasman Dr. =0A= San Jose, CA 95134-1706 =0A= Phone: 408-527-0955 =0A= Email: ddutt@cisco.com" =0A= =0A= DESCRIPTION =0A= "The PIB module containing the base set of policy rule = =0A= classes that are required for support of all policy =0A= usage monitoring, tracking and reporting policies" =0A= REVISION "200212191400Z" =0A= DESCRIPTION =0A= "Initial version, published in RFC xxxx." =0A= -- xxxx to be assigned by RFC editor =0A= =0A= ::=3D { pib xx } -- xx will be assigned by IANA, according = =0A= -- to RFC 3159 (IANA considerations) =0A= =0A= Rawlins et al. Expires June 2003 [Page 11] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= =0A= -- =0A= -- Textual Conventions =0A= -- =0A= =0A= Usage32 ::=3D TEXTUAL-CONVENTION =0A= STATUS current =0A= DESCRIPTION =0A= "The Usage32 type represents a non-negative integer = =0A= which monotonically increases. =0A= Usage32 initial value is 0 and the object-type using = =0A= Usage32 needs to specify when it is initialized. =0A= =0A= The Usage32 type is intended to reflect the absolute = =0A= number of counted events, so that even a new PDP =0A= after a COPS reconnect can use the value directly. =0A= =0A= If there is the possibility that the maximum Usage32 = =0A= value of 2^32-1 is exceeded during the lifetime =0A= of the Usage32 object, the larger Usage64 type =0A= should be used. =0A= =0A= If conditions other than the reset of the COPS =0A= subsystem exist that disrupt the monotonic =0A= characteristics of Usage32, these conditions and a =0A= method how to detect their presence should be =0A= specified in the description of the object-type using = =0A= Usage32 or its enclosing object-types (e.g. the =0A= Entry or Table object-type of the Usage32 =0A= object-type). =0A= =0A= Whenever the monotonic increase of Usage32 is violated, = =0A= it should be reset to 0 and the fact that this occurred = =0A= should be indicated through an appropriate mechanism, = =0A= for example a corresponding object of type TimeStamp = =0A= or TimeAndDate." =0A= SYNTAX Unsigned32 =0A= =0A= Usage64 ::=3D TEXTUAL-CONVENTION =0A= STATUS current =0A= DESCRIPTION =0A= "The Usage64 type represents a non-negative integer = =0A= which monotonically increases. =0A= Usage64 initial value is 0 and the object-type using = =0A= Usage64 needs to specify when it is initialized. =0A= =0A= The Usage64 type is intended to reflect the absolute = =0A= number of counted events, so that even a new PDP =0A= after a COPS reconnect can use the value directly. =0A= =0A= The lifetime of the Usage64 object should be defined = =0A= in a way that ensures the maximum Usage64 value of =0A= 2^64-1 is never exceeded. =0A= =0A= Rawlins et al. Expires June 2003 [Page 12] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= =0A= If conditions other than the reset of the COPS =0A= subsystem exist that disrupt the monotonic =0A= characteristics of Usage64, these conditions and a =0A= method how to detect their presence should be =0A= specified in the description of the object-type using = =0A= Usage64 or its enclosing object-types (e.g. the =0A= Entry or Table object-type of the Usage64 =0A= object-type). =0A= =0A= Whenever the monotonic increase of Usage64 is violated, = =0A= it should be reset to 0 and the fact that this occurred = =0A= should be indicated through an appropriate mechanism, = =0A= for example a corresponding object of type TimeStamp = =0A= or TimeAndDate." =0A= SYNTAX Unsigned64 =0A= =0A= -- =0A= -- The feedback report group =0A= -- =0A= =0A= frwkFeedbackGroupClasses =0A= OBJECT IDENTIFIER ::=3D { frwkFeedbackPib 1 } =0A= =0A= -- =0A= -- Feedback Action Table =0A= -- =0A= =0A= frwkFeedbackActionTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF FrwkFeedbackActionEntry =0A= PIB-ACCESS install =0A= STATUS current =0A= DESCRIPTION =0A= "This class represents commands that the PDP sends to = =0A= suspend, resume or solicit collection or reporting of = =0A= usage data." =0A= =0A= ::=3D { frwkFeedbackGroupClasses 1} =0A= =0A= frwkFeedbackActionEntry OBJECT-TYPE =0A= SYNTAX FrwkFeedbackActionEntry =0A= STATUS current =0A= DESCRIPTION =0A= "Each frwkFeedbackActionEntry represents a command from = =0A= the PDP. FrwkFeedbackActionIndicator specifies the =0A= command itself while frwkFeedbackActionSpecificPri =0A= indicates if all frwkFeedbackLink objects in the system = =0A= are affected by the command, or just the set that is = =0A= referenced by frwkFeedbackActionList." =0A= PIB-INDEX { frwkFeedbackActionId} =0A= =0A= ::=3D { frwkFeedbackActionTable 1} =0A= =0A= =0A= Rawlins et al. Expires June 2003 [Page 13] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= FrwkFeedbackActionEntry ::=3D SEQUENCE { =0A= frwkFeedbackActionId InstanceId, =0A= frwkFeedbackActionIndicator INTEGER, =0A= frwkFeedbackActionSpecificPri TruthValue, =0A= frwkFeedbackActionList TagReferenceId =0A= } =0A= =0A= frwkFeedbackActionId OBJECT-TYPE =0A= SYNTAX InstanceId =0A= STATUS current =0A= DESCRIPTION =0A= "An arbitrary integer index that uniquely identifies an = =0A= instance of the frwkFeedbackAction class." =0A= =0A= ::=3D { frwkFeedbackActionEntry 1} =0A= =0A= frwkFeedbackActionIndicator OBJECT-TYPE =0A= SYNTAX INTEGER { =0A= suspendMonitoringAndReports(0), =0A= suspendReports(1), =0A= resume(2), =0A= solicitReport(3) =0A= } =0A= STATUS current =0A= DESCRIPTION =0A= "The value indicates if the PEP is to send cached = =0A= usage policies via COPS accounting type report =0A= messages. =0A= The enumeration values are: =0A= (0) suspendMonitoringAndReports =0A= (1) suspendReports =0A= (2) resume =0A= (3) solicitReport " =0A= =0A= ::=3D { frwkFeedbackActionEntry 2 } =0A= =0A= frwkFeedbackActionSpecificPri OBJECT-TYPE =0A= SYNTAX TruthValue =0A= STATUS current =0A= DESCRIPTION =0A= "A value of 0 indicates that the =0A= frwkFeedbackActionList attribute should be ignored, = =0A= and the action applied to all policies. A value of = =0A= 1 indicates that the action entry has a specific = =0A= list of policies to which it is to be applied." =0A= ::=3D { frwkFeedbackActionEntry 3} =0A= =0A= frwkFeedbackActionList OBJECT-TYPE =0A= SYNTAX TagReferenceId =0A= PIB-TAG { frwkFeedbackActionListTag } =0A= STATUS current =0A= DESCRIPTION =0A= =0A= =0A= Rawlins et al. Expires June 2003 [Page 14] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= "Identifies a group of frwkFeedbackLink instances = =0A= that this action should affect. The group is =0A= identified through a tag reference in the =0A= frwkFeedbackList class." =0A= ::=3D { frwkFeedbackActionEntry 4} =0A= =0A= -- =0A= -- Feedback Action List Table =0A= -- =0A= =0A= frwkFeedbackActionListTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF FrwkFeedbackActionListEntry =0A= PIB-ACCESS install =0A= STATUS current =0A= DESCRIPTION =0A= "This class defines groups of linkage instances. = =0A= Groups can be referenced by commands sent by the = =0A= PDP in a frwkFeedbackActionEntry -in this case the = =0A= command affects all linkage instances that are part = =0A= of the group. =0A= A group can be referred to by its tag stored in =0A= frwkFeedbackActionListTag." =0A= ::=3D { frwkFeedbackGroupClasses 2} =0A= =0A= frwkFeedbackActionListEntry OBJECT-TYPE =0A= SYNTAX FrwkFeedbackActionListEntry =0A= STATUS current =0A= DESCRIPTION =0A= "Each instance associates a linkage instance with a = =0A= specific ActionListGroup." =0A= =0A= PIB-INDEX {frwkFeedbackActionListId } =0A= UNIQUENESS { frwkFeedbackActionListTag, =0A= frwkFeedbackActionListRefID =0A= } =0A= ::=3D { frwkFeedbackActionListTable 1} =0A= =0A= FrwkFeedbackActionListEntry::=3D SEQUENCE { =0A= frwkFeedbackActionListId InstanceId, =0A= frwkFeedbackActionListTag TagId, =0A= frwkFeedbackActionListRefID ReferenceId =0A= } =0A= =0A= frwkFeedbackActionListId OBJECT-TYPE =0A= SYNTAX InstanceId =0A= STATUS current =0A= DESCRIPTION =0A= "Arbitrary integer index that uniquely =0A= identifies an instance of the class." =0A= =0A= ::=3D { frwkFeedbackActionListEntry 1 } =0A= =0A= frwkFeedbackActionListTag OBJECT-TYPE =0A= =0A= Rawlins et al. Expires June 2003 [Page 15] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= SYNTAX TagId =0A= STATUS current =0A= DESCRIPTION =0A= "Identifies a group of linkage instances that can = =0A= be referenced from the Action class." =0A= =0A= ::=3D { frwkFeedbackActionListEntry 2 } =0A= =0A= frwkFeedbackActionListRefID OBJECT-TYPE =0A= SYNTAX ReferenceId =0A= PIB-REFERENCES { frwkFeedbackLinkEntry } =0A= STATUS current =0A= DESCRIPTION =0A= "A frwkFeedbackLink instance that is referred to = =0A= by this ReferenceId becomes part of the group, =0A= that is identified by the =0A= frwkFeedbackActionListTag." =0A= =0A= ::=3D { frwkFeedbackActionListEntry 3 } =0A= =0A= -- =0A= -- The Feedback Link Capability Table =0A= -- =0A= =0A= frwkFeedbackLinkCapsTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF FrwkFeedbackLinkCapsEntry =0A= PIB-ACCESS notify =0A= STATUS current =0A= DESCRIPTION =0A= "Instances of the frwkFeedbackLink class reference =0A= instances of selection and threshold classes and a =0A= usage class. =0A= This class allows the PEP to communicate valid =0A= combinations of these three classes to the PDP." =0A= ::=3D { frwkFeedbackGroupClasses 3} =0A= =0A= =0A= frwkFeedbackLinkCapsEntry OBJECT-TYPE =0A= SYNTAX FrwkFeedbackLinkCapsEntry =0A= STATUS current =0A= DESCRIPTION =0A= "The attributes of this class identify valid =0A= combinations of selection criteria, usage and =0A= threshold classes for feedback." =0A= PIB-INDEX { frwkFeedbackLinkCapsId } =0A= UNIQUENESS { =0A= frwkFeedbackLinkCapsSelection, =0A= frwkFeedbackLinkCapsUsage, =0A= frwkFeedbackLinkCapsThreshold =0A= } =0A= ::=3D {frwkFeedbackLinkCapsTable 1} =0A= =0A= FrwkFeedbackLinkCapsEntry ::=3D SEQUENCE { =0A= =0A= Rawlins et al. Expires June 2003 [Page 16] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= frwkFeedbackLinkCapsId InstanceId, =0A= frwkFeedbackLinkCapsSelection PrcIdentifierOid, =0A= frwkFeedbackLinkCapsUsage PrcIdentifierOid, =0A= frwkFeedbackLinkCapsThreshold PrcIdentifierOidOrZero =0A= } =0A= =0A= frwkFeedbackLinkCapsId OBJECT-TYPE =0A= SYNTAX InstanceId =0A= STATUS current =0A= DESCRIPTION =0A= "An arbitrary integer index that uniquely identifies an = =0A= instance of the frwkFeedbackLinkCaps class." =0A= ::=3D { frwkFeedbackLinkCapsEntry 1} =0A= =0A= frwkFeedbackLinkCapsSelection OBJECT-TYPE =0A= SYNTAX PrcIdentifierOid =0A= STATUS current =0A= DESCRIPTION =0A= "The identifier of a class that is supported by the =0A= device for feedback selection in combination with the = =0A= usage and threshold classes referenced in this =0A= instance." =0A= ::=3D { frwkFeedbackLinkCapsEntry 2} =0A= =0A= frwkFeedbackLinkCapsUsage OBJECT-TYPE =0A= SYNTAX PrcIdentifierOid =0A= STATUS current =0A= DESCRIPTION =0A= "The identifier of the usage class that is supported by = =0A= the PEP in combination with the selection and threshold = =0A= classes referenced in this instance." =0A= ::=3D { frwkFeedbackLinkCapsEntry 3} =0A= =0A= =0A= frwkFeedbackLinkCapsThreshold OBJECT-TYPE =0A= SYNTAX PrcIdentifierOidOrZero =0A= STATUS current =0A= DESCRIPTION =0A= "The identifier of the threshold class that is =0A= supported by the PEP in combination with the selection = =0A= and usage classes referenced in this instance. =0A= 0.0 is used if this combination does not allow a =0A= threshold." =0A= ::=3D { frwkFeedbackLinkCapsEntry 4} =0A= =0A= -- =0A= -- The Feedback Report Linkage Table =0A= -- =0A= =0A= frwkFeedbackLinkTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF FrwkFeedbackLinkEntry =0A= PIB-ACCESS install =0A= STATUS current =0A= =0A= Rawlins et al. Expires June 2003 [Page 17] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= DESCRIPTION =0A= "This class associates the selection criteria with the = =0A= usage policy. It also permits the defining of the max = =0A= interval used for reporting the usage instance." =0A= =0A= ::=3D { frwkFeedbackGroupClasses 4} =0A= =0A= frwkFeedbackLinkEntry OBJECT-TYPE =0A= SYNTAX FrwkFeedbackLinkEntry =0A= STATUS current =0A= DESCRIPTION =0A= "This class associates the selection criteria with the = =0A= usage policy. It also permits the defining of the max = =0A= interval used for reporting the usage instance." =0A= PIB-INDEX { frwkFeedbackLinkId } =0A= UNIQUENESS {frwkFeedbackLinkSel, =0A= frwkFeedbackLinkUsage } =0A= ::=3D {frwkFeedbackLinkTable 1} =0A= =0A= FrwkFeedbackLinkEntry ::=3D SEQUENCE { =0A= frwkFeedbackLinkId InstanceId, =0A= frwkFeedbackLinkSel Prid, =0A= frwkFeedbackLinkUsage PrcIdentifierOid, =0A= frwkFeedbackLinkInterval Integer32, =0A= frwkFeedbackLinkThreshold Prid, =0A= frwkFeedbackLinkFlags BITS =0A= } =0A= =0A= frwkFeedbackLinkId OBJECT-TYPE =0A= SYNTAX InstanceId =0A= STATUS current =0A= DESCRIPTION =0A= " An arbitrary integer index that uniquely identifies an = =0A= instance of the frwkFeedbackLinkTable class." =0A= ::=3D { frwkFeedbackLinkEntry 1} =0A= =0A= frwkFeedbackLinkSel OBJECT-TYPE =0A= SYNTAX Prid =0A= STATUS current =0A= DESCRIPTION =0A= "The PRID of the Policy Class instance as the monitoring = =0A= point, or the PRID of the selection criteria instance that = =0A= defines the conditions for monitoring, to be use by the = =0A= PEP for usage reporting." =0A= =0A= ::=3D { frwkFeedbackLinkEntry 2} =0A= =0A= frwkFeedbackLinkUsage OBJECT-TYPE =0A= SYNTAX PrcIdentifierOid =0A= STATUS current =0A= DESCRIPTION =0A= "The identifier of the usage class that the PEP uses to = =0A= monitor, record and report." =0A= =0A= Rawlins et al. Expires June 2003 [Page 18] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= =0A= ::=3D { frwkFeedbackLinkEntry 3} =0A= =0A= frwkFeedbackLinkInterval OBJECT-TYPE =0A= SYNTAX Integer32 =0A= STATUS current =0A= DESCRIPTION =0A= "Maximum interval in units of the value of the =0A= Accounting Timer specified by the PDP in the client =0A= accept message. A frwkFeedbackLinkInterval of 1 is =0A= equal to the value of the Accounting Timer. This value = =0A= must be 1 or greater. " =0A= =0A= ::=3D { frwkFeedbackLinkEntry 4} =0A= =0A= frwkFeedbackLinkThreshold OBJECT-TYPE =0A= SYNTAX Prid =0A= STATUS current =0A= DESCRIPTION =0A= "The PRID of a threshold class instance. This instance = =0A= specifies the threshold values for the usage policy." = =0A= ::=3D { frwkFeedbackLinkEntry 5} =0A= =0A= frwkFeedbackLinkFlags OBJECT-TYPE =0A= SYNTAX BITS { =0A= periodic(0), =0A= threshold(1), =0A= changeOnly(2) =0A= } =0A= STATUS current =0A= DESCRIPTION =0A= "This value indicates the reporting basis of the usage = =0A= policy. The feed back may be generated on demand, on a = =0A= periodic basis regardless of a change in value from the = =0A= previous report, on a periodic basis if a change in =0A= value has occurred, or the usage is reported when an = =0A= identified threshold value in the usage instance has = =0A= been reached. =0A= If the 'periodic' flag is set, the PEP will provide =0A= unsolicited reports at the rate specified in =0A= frwkFeedbackLinkInterval. =0A= If the 'periodic' flag is not set, reports will only be = =0A= generated when solicited by the PDP. =0A= The 'threshold' and 'changeOnly' flags make the =0A= periodic reports conditional - these flags only make = =0A= sense in combination with the 'periodic' flag." =0A= =0A= ::=3D { frwkFeedbackLinkEntry 6} =0A= =0A= =0A= -- =0A= -- The Threshold class that accompanies the above Usage PRCs =0A= -- =0A= =0A= Rawlins et al. Expires June 2003 [Page 19] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= =0A= frwkFeedbackTrafficThresTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF FrwkFeedbackTrafficThresEntry = =0A= PIB-ACCESS install =0A= STATUS current =0A= DESCRIPTION =0A= "This class defines the threshold attributes =0A= corresponding to usage attributes specified in =0A= frwkFeedbackTrafficTable, frwkFeedbackIfTrafficTable = =0A= and other similar usage classes. =0A= =0A= The usage object is considered to match the threshold = =0A= condition if at least one of the packet or byte =0A= threshold conditions match. =0A= =0A= The byte and packet thresholds are considered to =0A= match, if the threshold is present (not ASN1 NULL) = =0A= and the corresponding usage value exceeds the =0A= threshold." =0A= =0A= ::=3D { frwkFeedbackGroupClasses 5} =0A= =0A= frwkFeedbackTrafficThresEntry OBJECT-TYPE =0A= SYNTAX FrwkFeedbackTrafficThresEntry =0A= STATUS current =0A= DESCRIPTION =0A= "Defines the attributes to hold threshold values." = =0A= PIB-INDEX {frwkFeedbackTrafficThresId} =0A= =0A= ::=3D {frwkFeedbackTrafficThresTable 1} =0A= =0A= FrwkFeedbackTrafficThresEntry ::=3D SEQUENCE { =0A= frwkFeedbackTrafficThresId InstanceId, = =0A= frwkFeedbackTrafficThresPackets Unsigned64, = =0A= frwkFeedbackTrafficThresBytes Unsigned64 = =0A= } =0A= =0A= frwkFeedbackTrafficThresId OBJECT-TYPE =0A= SYNTAX InstanceId =0A= STATUS current =0A= DESCRIPTION =0A= "Arbitrary integer index that uniquely identifies = =0A= an instance of the class." =0A= ::=3D { frwkFeedbackTrafficThresEntry 1 } =0A= =0A= frwkFeedbackTrafficThresPackets OBJECT-TYPE =0A= SYNTAX Unsigned64 =0A= STATUS current =0A= DESCRIPTION =0A= "The threshold, in terms of packets, that must be = =0A= matched or exceeded to trigger a report in the = =0A= next reporting interval. =0A= A value of 0 or a missing value (" =0A= =0A= Rawlins et al. Expires June 2003 [Page 20] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= ::=3D { frwkFeedbackTrafficThresEntry 2 } =0A= =0A= frwkFeedbackTrafficThresBytes OBJECT-TYPE =0A= SYNTAX Unsigned64 =0A= STATUS current =0A= DESCRIPTION =0A= "The threshold, in terms of bytes, that must be =0A= exceeded to trigger a report in the next reporting = =0A= interval." =0A= ::=3D { frwkFeedbackTrafficThresEntry 3 } =0A= =0A= =0A= -- =0A= -- All actual usage classes are in the separate =0A= -- frwkFeedbackUsageClasses group =0A= -- =0A= =0A= frwkFeedbackUsageClasses =0A= OBJECT IDENTIFIER ::=3D { frwkFeedbackPib 2 } =0A= =0A= =0A= -- =0A= -- The generic traffic (byte & packet count) usage class =0A= -- =0A= =0A= frwkFeedbackTrafficTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF FrwkFeedbackTrafficEntry =0A= PIB-ACCESS report-only =0A= STATUS current =0A= DESCRIPTION =0A= "This class defines the usage attributes that the PEP = =0A= is to monitor for plain traffic handling elements =0A= like filters. All packets and the bytes contained in = =0A= these packets are counted. It also contains the PRID = =0A= of the linkage instance associating the selection =0A= criteria instance with the usage instance." =0A= =0A= ::=3D { frwkFeedbackUsageClasses 1} =0A= =0A= frwkFeedbackTrafficEntry OBJECT-TYPE =0A= SYNTAX FrwkFeedbackTrafficEntry =0A= STATUS current =0A= DESCRIPTION =0A= "Defines the attributes the PEP is to monitor, =0A= record and report." =0A= PIB-INDEX {frwkFeedbackTrafficId} =0A= UNIQUENESS { frwkFeedbackTrafficLinkRefID } =0A= =0A= ::=3D {frwkFeedbackTrafficTable 1} =0A= =0A= FrwkFeedbackTrafficEntry ::=3D SEQUENCE { =0A= frwkFeedbackTrafficId InstanceId, =0A= frwkFeedbackTrafficLinkRefID ReferenceId, =0A= =0A= Rawlins et al. Expires June 2003 [Page 21] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= frwkFeedbackTrafficPacketCount Usage64, =0A= frwkFeedbackTrafficByteCount Usage64 =0A= =0A= } =0A= =0A= frwkFeedbackTrafficId OBJECT-TYPE =0A= SYNTAX InstanceId =0A= STATUS current =0A= DESCRIPTION =0A= "Arbitrary integer index that uniquely identifies = =0A= an instance of the class." =0A= ::=3D { frwkFeedbackTrafficEntry 1 } =0A= =0A= frwkFeedbackTrafficLinkRefID OBJECT-TYPE =0A= SYNTAX ReferenceId =0A= PIB-REFERENCES { frwkFeedbackLinkEntry } =0A= STATUS current =0A= DESCRIPTION =0A= "The ReferenceId of the Linkage policy instance used = =0A= to base this usage policy instance upon." =0A= =0A= ::=3D { frwkFeedbackTrafficEntry 2 } =0A= =0A= frwkFeedbackTrafficPacketCount OBJECT-TYPE =0A= SYNTAX Usage64 =0A= STATUS current =0A= DESCRIPTION =0A= "The count of packets handled by the associated =0A= element. The initial value of 0 is set when the =0A= frwkFeedbackTraffic instance is created, for example = =0A= triggered through the creation of a frwkFeedbackLink = =0A= instance." =0A= =0A= ::=3D {frwkFeedbackTrafficEntry 3} =0A= =0A= frwkFeedbackTrafficByteCount OBJECT-TYPE =0A= SYNTAX Usage64 =0A= STATUS current =0A= DESCRIPTION =0A= "The byte count of packets handled by the associated = =0A= element. The initial value of 0 is set when the =0A= frwkFeedbackTraffic instance is created." =0A= ::=3D { frwkFeedbackTrafficEntry 4} =0A= =0A= =0A= =0A= -- =0A= -- The traffic usage class, qualified for an interface =0A= -- =0A= =0A= frwkFeedbackIfTrafficTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF FrwkFeedbackIfTrafficEntry =0A= PIB-ACCESS report-only =0A= =0A= Rawlins et al. Expires June 2003 [Page 22] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= STATUS current =0A= DESCRIPTION =0A= "A usage class similar to the basic Traffic class that = =0A= also contains a reference to an interface index. This = =0A= class should be used with a underspecified selection = =0A= criteria entry from the frwkRoleComboTable that matches = =0A= an element that can be assigned to multiple interface = =0A= indices. The interface field can be used to associate = =0A= the instances of this class with the specific element's = =0A= assignment." =0A= ::=3D { frwkFeedbackUsageClasses 2 } =0A= =0A= frwkFeedbackIfTrafficEntry OBJECT-TYPE =0A= SYNTAX FrwkFeedbackIfTrafficEntry =0A= STATUS current =0A= DESCRIPTION =0A= "Defines the attributes the PEP is to monitor, =0A= record and report." =0A= PIB-INDEX {frwkFeedbackIfTrafficId} =0A= UNIQUENESS { frwkFeedbackIfTrafficLinkRefID, =0A= frwkFeedbackIfTrafficIfIndex } =0A= =0A= ::=3D {frwkFeedbackIfTrafficTable 1} =0A= =0A= FrwkFeedbackIfTrafficEntry ::=3D SEQUENCE { =0A= frwkFeedbackIfTrafficId InstanceId, =0A= frwkFeedbackIfTrafficLinkRefID ReferenceId, =0A= frwkFeedbackIfTrafficIfIndex InterfaceIndex, =0A= frwkFeedbackIfTrafficPacketCount Usage64, =0A= frwkFeedbackIfTrafficByteCount Usage64 =0A= =0A= } =0A= =0A= frwkFeedbackIfTrafficId OBJECT-TYPE =0A= SYNTAX InstanceId =0A= STATUS current =0A= DESCRIPTION =0A= "Arbitrary integer index that uniquely identifies = =0A= an instance of the class." =0A= ::=3D { frwkFeedbackIfTrafficEntry 1 } =0A= =0A= frwkFeedbackIfTrafficLinkRefID OBJECT-TYPE =0A= SYNTAX ReferenceId =0A= PIB-REFERENCES { frwkFeedbackLinkEntry } =0A= STATUS current =0A= DESCRIPTION =0A= "The ReferenceId of the Linkage policy instance used = =0A= to base this usage policy instance upon." =0A= ::=3D { frwkFeedbackIfTrafficEntry 2 } =0A= =0A= =0A= frwkFeedbackIfTrafficIfIndex OBJECT-TYPE =0A= SYNTAX InterfaceIndex =0A= =0A= Rawlins et al. Expires June 2003 [Page 23] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= STATUS current =0A= DESCRIPTION =0A= "The value of this attribute is the ifIndex which is = =0A= associated with the specified RoleCombination and =0A= interface capability set name." =0A= =0A= ::=3D { frwkFeedbackIfTrafficEntry 3 } =0A= =0A= frwkFeedbackIfTrafficPacketCount OBJECT-TYPE =0A= SYNTAX Usage64 =0A= STATUS current =0A= DESCRIPTION =0A= "The count of packets handled by the associated =0A= element. The initial value of 0 is set when the =0A= frwkFeedbackIfTraffic instance is created." =0A= ::=3D { frwkFeedbackIfTrafficEntry 4 } =0A= =0A= frwkFeedbackIfTrafficByteCount OBJECT-TYPE =0A= SYNTAX Usage64 =0A= STATUS current =0A= DESCRIPTION =0A= "The byte count of packets handled by the associated = =0A= element. The initial value of 0 is set when the =0A= frwkFeedbackIfTraffic instance is created." =0A= ::=3D { frwkFeedbackIfTrafficEntry 5 } =0A= =0A= =0A= -- =0A= -- All Selection classes are in the separate =0A= -- FrwkFeedbackSelectionClasses group =0A= -- =0A= =0A= frwkFeedbackSelectionClasses =0A= OBJECT IDENTIFIER ::=3D { frwkFeedbackPib 3 } =0A= =0A= -- =0A= -- The Role Combination Filter Selection Table =0A= -- =0A= =0A= frwkFeedbackRoleFilterSelTable OBJECT-TYPE =0A= SYNTAX SEQUENCE OF FrwkFeedbackRoleFilterSelEntry = =0A= PIB-ACCESS install =0A= STATUS current =0A= DESCRIPTION =0A= "A selection class that defines selection of objects = =0A= for monitoring based on the role combination, =0A= capability set and a filter." =0A= ::=3D { frwkFeedbackSelectionClasses 1 } =0A= =0A= frwkFeedbackRoleFilterSelEntry OBJECT-TYPE =0A= SYNTAX FrwkFeedbackRoleFilterSelEntry =0A= STATUS current =0A= DESCRIPTION =0A= =0A= Rawlins et al. Expires June 2003 [Page 24] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= "Each instance selects a filter on multiple interfaces = =0A= that share the same frwkRoleCombo instance." =0A= PIB-INDEX { frwkFeedbackRoleFilterSelId} =0A= UNIQUENESS { frwkFeedbackRoleFilterSelRCombo, =0A= frwkFeedbackRoleFilterSelFilter =0A= } =0A= =0A= ::=3D {frwkFeedbackRoleFilterSelTable 1} =0A= =0A= FrwkFeedbackRoleFilterSelEntry ::=3D SEQUENCE { =0A= frwkFeedbackRoleFilterSelId InstanceId, =0A= frwkFeedbackRoleFilterSelRCombo ReferenceId, =0A= frwkFeedbackRoleFilterSelFilter Prid =0A= } =0A= =0A= frwkFeedbackRoleFilterSelId OBJECT-TYPE =0A= SYNTAX InstanceId =0A= STATUS current =0A= DESCRIPTION =0A= "Arbitrary integer index that uniquely identifies = =0A= an instance of the class." =0A= ::=3D { frwkFeedbackRoleFilterSelEntry 1 } =0A= =0A= frwkFeedbackRoleFilterSelRCombo OBJECT-TYPE =0A= SYNTAX ReferenceId =0A= PIB-REFERENCES { frwkRoleComboEntry } =0A= STATUS current =0A= DESCRIPTION =0A= "The ReferenceId of the frwkRoleComboTable policy =0A= instance used for selection." =0A= ::=3D { frwkFeedbackRoleFilterSelEntry 2 } =0A= =0A= frwkFeedbackRoleFilterSelFilter OBJECT-TYPE =0A= SYNTAX Prid =0A= STATUS current =0A= DESCRIPTION =0A= "The identifier of a filter instance. Valid classes = =0A= are the subclasses of frwkBaseFilter: =0A= - frwkIpFilter =0A= - frwk802Filter =0A= - frwkILabelFilter" =0A= ::=3D { frwkFeedbackRoleFilterSelEntry 3 } =0A= =0A= =0A= -- =0A= -- Compliance Section =0A= -- =0A= =0A= frwkFeedbackPibConformance =0A= OBJECT IDENTIFIER ::=3D { frwkFeedbackPib 4 } =0A= =0A= frwkFeedbackPibCompliances =0A= OBJECT IDENTIFIER ::=3D { frwkFeedbackPibConformance 1 = } =0A= =0A= Rawlins et al. Expires June 2003 [Page 25] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= =0A= frwkFeedbackPibGroups =0A= OBJECT IDENTIFIER ::=3D { frwkFeedbackPibConformance 2 = } =0A= =0A= =0A= frwkFeedbackPibCompliance MODULE-COMPLIANCE =0A= STATUS current =0A= DESCRIPTION =0A= "Describes the requirements for conformance to the feedback =0A= framework PIB" =0A= =0A= MODULE -- this module =0A= MANDATORY-GROUPS { frwkFeedbackLinkCapsGroup, =0A= frwkFeedbackLinkGroup, =0A= frwkFeedbackActionGroup } =0A= =0A= GROUP frwkFeedbackActionListGroup =0A= DESCRIPTION =0A= "The frwkFeedbackActionListGroup is mandatory if = =0A= actions on subsets linkEntries are to be =0A= supported." =0A= =0A= GROUP frwkFeedbackTrafficGroup =0A= DESCRIPTION =0A= "The frwkFeedbackTrafficGroup is mandatory if =0A= monitoring of traffic data is to be supported." = =0A= =0A= GROUP frwkFeedbackTrafficThresGroup =0A= DESCRIPTION =0A= "The frwkFeedbackTrafficThresGroup is mandatory = =0A= if conditional reporting of traffic usage =0A= thresholds is to be supported." =0A= =0A= GROUP frwkFeedbackIfTrafficGroup =0A= DESCRIPTION =0A= "The frwkFeedbackIfTrafficGroup is mandatory if = =0A= per-interface usage collection of traffic data is = =0A= to be supported." =0A= =0A= GROUP frwkFeedbackRoleFilterSelGroup =0A= DESCRIPTION =0A= "The frwkFeedbackRoleFilterSelGroup is mandatory = =0A= if monitoring of filters referenced through the = =0A= frwkRoleCombo class is to be supported." =0A= =0A= ::=3D { frwkFeedbackPibCompliances 1 } =0A= =0A= frwkFeedbackLinkCapsGroup OBJECT-GROUP =0A= OBJECTS { =0A= frwkFeedbackLinkCapsId, =0A= frwkFeedbackLinkCapsSelection, =0A= frwkFeedbackLinkCapsUsage, =0A= frwkFeedbackLinkCapsThreshold } =0A= =0A= Rawlins et al. Expires June 2003 [Page 26] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= STATUS current =0A= DESCRIPTION =0A= "Objects from the frwkFeedbackLinkCapsTable." =0A= =0A= ::=3D { frwkFeedbackPibGroups 1 } =0A= =0A= frwkFeedbackLinkGroup OBJECT-GROUP =0A= OBJECTS { =0A= frwkFeedbackLinkId, =0A= frwkFeedbackLinkSel, =0A= frwkFeedbackLinkUsage, =0A= frwkFeedbackLinkInterval, =0A= frwkFeedbackLinkThreshold, =0A= frwkFeedbackLinkFlags } =0A= STATUS current =0A= DESCRIPTION =0A= "Objects from the frwkFeedbackLinkTable." =0A= =0A= ::=3D { frwkFeedbackPibGroups 2 } =0A= =0A= frwkFeedbackActionGroup OBJECT-GROUP =0A= OBJECTS { =0A= frwkFeedbackActionId, =0A= frwkFeedbackActionIndicator, =0A= frwkFeedbackActionSpecificPri, =0A= frwkFeedbackActionList } =0A= STATUS current =0A= DESCRIPTION =0A= "Objects from the frwkFeedbackActionTable." =0A= =0A= ::=3D { frwkFeedbackPibGroups 3 } =0A= =0A= frwkFeedbackActionListGroup OBJECT-GROUP =0A= OBJECTS { =0A= frwkFeedbackActionListId, =0A= frwkFeedbackActionListTag, =0A= frwkFeedbackActionListRefID } =0A= STATUS current =0A= DESCRIPTION =0A= "Objects from the frwkFeedbackActionListTable." =0A= =0A= ::=3D { frwkFeedbackPibGroups 4 } =0A= =0A= frwkFeedbackTrafficGroup OBJECT-GROUP =0A= OBJECTS { =0A= frwkFeedbackTrafficId, =0A= frwkFeedbackTrafficLinkRefID, =0A= frwkFeedbackTrafficPacketCount, =0A= frwkFeedbackTrafficByteCount } =0A= STATUS current =0A= DESCRIPTION =0A= "Objects from the frwkFeedbackTrafficTable." =0A= =0A= =0A= Rawlins et al. Expires June 2003 [Page 27] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= ::=3D { frwkFeedbackPibGroups 5 } =0A= =0A= frwkFeedbackTrafficThresGroup OBJECT-GROUP =0A= OBJECTS { =0A= frwkFeedbackTrafficThresId, =0A= frwkFeedbackTrafficThresPackets, =0A= frwkFeedbackTrafficThresBytes } =0A= STATUS current =0A= DESCRIPTION =0A= "Objects from the frwkFeedbackTrafficThresTable." =0A= =0A= ::=3D { frwkFeedbackPibGroups 6 } =0A= =0A= frwkFeedbackIfTrafficGroup OBJECT-GROUP =0A= OBJECTS { =0A= frwkFeedbackIfTrafficId, =0A= frwkFeedbackIfTrafficLinkRefID, =0A= frwkFeedbackIfTrafficIfIndex, =0A= frwkFeedbackIfTrafficPacketCount, =0A= frwkFeedbackIfTrafficByteCount } =0A= STATUS current =0A= DESCRIPTION =0A= "Objects from the frwkFeedbackIfTrafficTable." =0A= =0A= ::=3D { frwkFeedbackPibGroups 7 } =0A= =0A= frwkFeedbackRoleFilterSelGroup OBJECT-GROUP =0A= OBJECTS { =0A= frwkFeedbackRoleFilterSelId, =0A= frwkFeedbackRoleFilterSelRCombo, =0A= frwkFeedbackRoleFilterSelFilter } =0A= STATUS current =0A= DESCRIPTION =0A= "Objects from the frwkFeedbackRoleFilterSelTable." =0A= =0A= ::=3D { frwkFeedbackPibGroups 8 } =0A= =0A= END =0A= =0A= =0A= =0A= 5 Security Considerations =0A= =0A= This PIB defines structured information that may be sensitive when = =0A= transported by the COPS protocol [COPS-PR]. =0A= =0A= This PIB does not contain classes that directly contain security =0A= relevant information like passwords or monetary amounts, however =0A= unauthorized access or changes to information defined in this PIB =0A= could compromise network operations or reveal sensitive business or = =0A= personal information. =0A= Specifically for the classes: =0A= frwkFeedbackLinkCaps =0A= =0A= Rawlins et al. Expires June 2003 [Page 28] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= This class has the ACCESS clause 'notify'. Access to this =0A= information reveals feedback collection capabilities of the COPS = =0A= client and malicious changes could affect feedback operation by = =0A= misleading the server to generate corrupt feedback configuration. = =0A= frwkFeedbackLinkTable, frwkFeedbackAction, frwkFeedbackActionList, = =0A= frwkFeedbackTrafficThres, frwkFeedbackRoleFilterSel =0A= These classes have the ACCESS clause 'install' and allow the COPS = =0A= server to control feedback collection and reporting on the =0A= client. Access to this information exposes the client's =0A= configuration, malicious changes could disrupt network or =0A= business operations and raise privacy issues. =0A= frwkFeedbackTraffic, frwkFeedbackIfTraffic =0A= These classed have the ACCESS clause 'report-only' and contain = =0A= the usage information delivered from the COPS client to the =0A= server. Unauthorized access to this information may reveal =0A= detailed information on the network and its users. Malicious =0A= changes may affect network and business operations. =0A= =0A= [COPS] and [COPS-PR] define mechanisms to secure the COPS protocol = =0A= communication and implementations of COPS servers or clients =0A= supporting this PIB MUST follow the security guidelines specified =0A= there. =0A= =0A= =0A= 6 IANA Considerations =0A= =0A= This document describes the frwkFeedbackPib Policy Information Base = =0A= (PIB) module for standardization under the "pib" branch registered = =0A= with IANA. An IANA assigned PIB number is requested for this PIB =0A= under the "pib" branch. =0A= =0A= This PIB uses "all" in the SUBJECT-CATEGORY clause, so it applies to = =0A= all COPS client types. No new COPS client type is requested for this = =0A= PIB. =0A= =0A= =0A= 7 Acknowledgements =0A= =0A= The authors would like to thank Dave Durham and Russell Fenger of =0A= Intel and John K. Gallant of WorldCom for their contribution to this = =0A= document. =0A= =0A= =0A= 8 Authors' Addresses =0A= =0A= Diana Rawlins =0A= WorldCom =0A= 901 International Parkway =0A= Richardson, Texas 75081 =0A= Phone: 972-729-1044 =0A= Email: Diana.Rawlins@wcom.com =0A= =0A= Amol Kulkarni =0A= =0A= Rawlins et al. Expires June 2003 [Page 29] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= JF3-206 =0A= 2111 NE 25th Ave =0A= Hillsboro, Oregon 97124 =0A= Phone: 503-712-1168 =0A= Email: amol.kulkarni@intel.com =0A= =0A= Kwok Ho Chan =0A= Nortel Networks =0A= 600 Technology Park Drive =0A= Billerica, MA 01821 USA =0A= Phone: 978-288-8175 =0A= Email: khchan@nortelnetworks.com =0A= =0A= Martin Bokaemper =0A= Juniper Networks =0A= 700 Silver Seven Road =0A= Kanata, ON, K2V 1C3, Canada =0A= Phone: 613-591-2735 =0A= Email: mbokaemper@juniper.net =0A= =0A= Dinesh G Dutt =0A= Cisco Systems, Inc. =0A= 170 Tasman Dr. =0A= San Jose, CA 95134-1706 =0A= Phone: 408-527-0955 =0A= Email: ddutt@cisco.com =0A= =0A= =0A= 9 References =0A= =0A= 9.1 Normative References =0A= =0A= [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., = =0A= and A. Sastry, "The COPS (Common Open Policy Service) Protocol" = =0A= RFC 2748, January 2000. =0A= =0A= [COPS-PR] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. = =0A= Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage for = =0A= Policy Provisioning," RFC 3084, May 2001. =0A= =0A= [SPPI] K. McCloghrie, et.al., "Structure of Policy Provisioning = =0A= Information," RFC 3159, August 2001. =0A= =0A= [FR-PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A. = =0A= Smith, F. Reichmeyer "Framework Policy Information Base", RFC =0A= xxxx, xxxx 2002 =0A= =0A= [FEEDBACKfWK] D. Rawlins, A. Kulkarni, K. Chan, M. Bokaemper, D. = =0A= Dutt, "Framework of COPS-PR Policy Usage Feedback", RFC yyyy, yyyy = =0A= 2002. =0A= =0A= [RFC2119] Bradner, S., "Key wordss for use in RFCs to Indicate =0A= Requirement Levels", BCP 14, RFC 2119, March 1997. =0A= =0A= Rawlins et al. Expires June 2003 [Page 30] = =0C=0A= Internet Draft Feedback-FR-PIB June 2002 = =0A= =0A= =0A= =0A= 9.2 Informational References =0A= =0A= [COPS-TLS], Walker, J., Kulkarni, A.,"COPS Over TLS", draft-ietf- = =0A= rap-cops-tls-04.txt, June 2002. =0A= =0A= [DIFFSERV-PIB] Fine, M., McCloghrie, K., Seligson, J., Chan, K., = =0A= Hahn, S., Bell, C., Smith, A. and Reichmeyer, A. "Differentiated = =0A= Services Quality of Service Policy Information Base", = draft-ietf-=0A= diffserv-pib-09.txt, June 2002 =0A= =0A= =0A= 10 Copyright =0A= =0A= Copyright (C) The Internet Society (2002). All Rights Reserved. =0A= =0A= This document and translations of it may be copied and furnished to = =0A= others, and derivative works that comment on or otherwise explain it = =0A= or assist in its implementation may be prepared, copied, published = =0A= and distributed, in whole or in part, without restriction of any =0A= kind, provided that the above copyright notice and this paragraph = =0A= are included on all such copies and derivative works. However, this = =0A= document itself may not be modified in any way, such as by removing = =0A= the copyright notice or references to the Internet Society or other = =0A= Internet organizations, except as needed for the purpose of =0A= developing Internet standards in which case the procedures for =0A= copyrights defined in the Internet Standards process must be =0A= followed, or as required to translate it into languages other than = =0A= English. =0A= =0A= The limited permissions granted above are perpetual and will not be = =0A= revoked by the Internet Society or its successors or assigns. =0A= =0A= This document and the information contained herein is provided on an = =0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING = =0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING = =0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION =0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF =0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rawlins et al. Expires June 2003 [Page 31] = =0C ------_=_NextPart_000_01C2A79B.6BD11830-- From owner-rap@ops.ietf.org Thu Dec 19 19:08:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01431 for ; Thu, 19 Dec 2002 19:08:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18PAkq-000KGg-00 for rap-data@psg.com; Thu, 19 Dec 2002 16:11:04 -0800 Received: from roam.psg.com ([147.28.0.10] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18PAkn-000KGM-00 for rap@ops.ietf.org; Thu, 19 Dec 2002 16:11:01 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18PAkm-0000Fn-00 for rap@ops.ietf.org; Thu, 19 Dec 2002 16:11:00 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: "Bokaemper, Martin" To: "'Wijnen, Bert (Bert)'" , "Rap-wg (E-mail)" Subject: RE: AD review of draft-ietf-rap-feedback-fr-pib-04.txt Date: Thu, 19 Dec 2002 12:02:28 -0500 X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Hello Bert, > Thanks for the revision. Sorry, I forgot to post a change summary in the pre/post meeting hustle. > My comments inline below. > > Current real concerns: > - Section 3.2 start off with new text stating that SNMP Counter32 and > Counter64 are not supported by SPPI. What is this based on? > I do not understand that statement at all. RFC3159 (SPPI) sections 7.1.1 and 7.1.5 say "The Counter[32/64] type is not supported by the SPPI" When addressing the comment on the Counter types in the previous revision I stumbled over these sections and read them as 'these types are not to be used in PIB modules'. > - And as I explain below in my answers/comments, I am not sure that > your new definitions of Usage32/Usage64 make sense. Pls explain > in relation to the above and to my comments inline below. [and from below] > Mmm... I see that you now have defined two TCs Usage32 and Usage64 > that look very much like a Counter32 or a Counter64, if not that, > then they look very much like a ZeroBasedCounter32 (as defined in RMON > MIB, RFC2021) and ZerobasedCounter64 (as defined in HNUM-TC, RFC2856) > > Is this wise? The intention of the Usage32/64 TCs is to allow absolute readings for cases when the PDP either explicitly or implicitly knows the creation time of the object, so the main difference to Counter32/64 is the initial value of 0. ZeroBasedCounter[32/64] allow that too, so I agree they are more appropriate to use here - I have not been aware of these TCs before. I'll remove the Usage TCs again and will import and use ZeroBasedCounter[32/64] instead. Any issues with that? > > Could I have a response to this review today? Do you think you can fix > > a new rev today, that would allow me to put it on IESG agenda for 27 Dec I'll prepare a new revision with the changes mentioned here this afternoon, so it can go to internet-drafts@ietf.org and this list today. On the 'minor things': > - pls answer my questions inline below > - In the Abstract, it is probably better to change > This document describes a Policy Information Base (PIB) to control > policy usage collection and reporting in a device. [...] > into something aka: > This document describes a portion of the Policy Information Base > (PIB) to control policy usage collection and reporting in a device. [...] > The idea being (similar as with the MIB), that there is only ONE PIB > and several/multiple PIB Modules that together make up the PIB. Will change this. > > - I am missing a REVISION clause in the MODULE-IDENTITY macro > > You have added that now. Thanks. > But the LAST-UPDATED and the REVISION date/time need to be in sync. Will be fixed. [...] > > - Not sure if it is me, but I do not understand the DESCRIPTION > > clauses of frwkFeedbackActionListGroup and frwkFeedbackActionListRefID > > How does that work? Can you be more elaborate so I can understand > Mmm... I guess the WG members understand it... > It's a tidbit better though. Still a convoluted sentence - will make some improvements here. > > - can you explain (in the description clause) how the seOID is used > > for the selection process for object/attribute > > frwkFeedbackSelUsageComboCapsSelection > > it is a bit better Not sure what/how to improve here - will leave unchanged. [...] > > - sect 3.2 at the end (i.e. top of page 10) > > missing 2) ?? > aha, now no longer ordered lists ;-) > Anyway, a 1) does make people to expect a 2) and possibly more The underlying issue is that there is one group that has only one PRC in it, so numbering will always look odd. [...] > > - references must be split in normative and informative, again > > see: http://www.rfc-editor.org/policy.html > > Thanks for doing so. I now am missing reference [RFC2119] ??!! Will add this. [...] > > - I am missing an IPR section as per RFC2026 sect 10. > > > I see you did not add it. If we go for Informational, that is OK (I think) > It would not be OK for STDS track The 'ok' from all authors on this section did not arrive in time before the deadline, so it was not added. That should not be a problem since it's informational. Fixing 'nits' in drafts opens the eye to other nits: RFC3084 (COPS-PR), which is on the standards track, does not seem to have any IPR statement. An accident? ciao, Martin. -- From owner-rap@ops.ietf.org Fri Dec 20 05:31:16 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21308 for ; Fri, 20 Dec 2002 05:31:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18PKRo-000ALU-00 for rap-data@psg.com; Fri, 20 Dec 2002 02:32:04 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.36 #2) id 18PKRl-000ALH-00 for rap@ops.ietf.org; Fri, 20 Dec 2002 02:32:01 -0800 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id gBKAVrGs011358 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Fri, 20 Dec 2002 11:31:53 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id gBKAVrAa011515 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Fri, 20 Dec 2002 11:31:53 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id gBKAVrfa011512; Fri, 20 Dec 2002 11:31:53 +0100 Date: Fri, 20 Dec 2002 11:31:53 +0100 Message-Id: <200212201031.gBKAVrfa011512@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: MBokaemper@juniper.net CC: rap@ops.ietf.org, bwijnen@lucent.com In-reply-to: (MBokaemper@juniper.net) Subject: Re: FW: draft-ietf-rap-feedback-fr-pib-05.txt submission References: X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,OUTLOOK_FW_MSG,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> Bokaemper, Martin writes: Martin> Unchanged: - Usage32/64 - see todays discussion on the list 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. 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. I do not really know how a PIB author should make such a decision. There are two factors here - the lifetime you assume and the frequency of the events you are counting. In the MIB space we have learned that technology changes in just a few years can totally change how long it takes to fill up 32 bit counters. Now assume that I have implemented a Usage32 object and the event frequency changes such that I reach the upper limit - what is going to happen? Is your text saying that in case I reach the end of my number space, I have to end the lifetime of the object? Or is the text trying to tell me that PIB authors SHOULD choose the right UsageXX type (which in most cases will just be Usage64) which avoids rollovers but the type itself does rollover just like a normal SMIv2 CounterXX type? Perhaps just some rewording would help to distinguish between (a) how the type behaves and (b) how the type should be used by PIB authors. /js -- Juergen Schoenwaelder From owner-rap@ops.ietf.org Fri Dec 20 12:50:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03520 for ; Fri, 20 Dec 2002 12:50:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18PRKi-000On6-00 for rap-data@psg.com; Fri, 20 Dec 2002 09:53:12 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18PRKf-000Omu-00 for rap@ops.ietf.org; Fri, 20 Dec 2002 09:53:09 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03496; Fri, 20 Dec 2002 12:50:06 -0500 (EST) Message-Id: <200212201750.MAA03496@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-feedback-frwk-04.txt Date: Fri, 20 Dec 2002 12:50:06 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR) Author(s) : D. Rawlins, A. Kulkarni et al. Filename : draft-ietf-rap-feedback-frwk-04.txt Pages : 8 Date : 2002-12-20 Common Open Policy Services Protocol [COPS], RFC 2748, defined the capability of reporting information to the PDP. The types of report information are success, failure and accounting of an installed state. This document focuses on the COPS Report Type of Accounting and the necessary framework for the monitoring and reporting of usage feedback for an installed state. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-frwk-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-feedback-frwk-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-feedback-frwk-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-20130135.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-feedback-frwk-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-feedback-frwk-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-20130135.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Mon Dec 23 07:58:29 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28354 for ; Mon, 23 Dec 2002 07:58:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QSAs-000LSP-00 for rap-data@psg.com; Mon, 23 Dec 2002 04:59:14 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18QSAp-000LNj-00 for rap@ops.ietf.org; Mon, 23 Dec 2002 04:59:11 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27784; Mon, 23 Dec 2002 07:56:07 -0500 (EST) Message-Id: <200212231256.HAA27784@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-feedback-fr-pib-05.txt Date: Mon, 23 Dec 2002 07:56:07 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Framework Policy Information Base for Usage Feedback Author(s) : D. Rawlins et al. Filename : draft-ietf-rap-feedback-fr-pib-05.txt Pages : 31 Date : 2002-12-20 This document describes a portion of the Policy Information Base (PIB) to control policy usage collection and reporting in a device. The provisioning classes specified here allow a Policy Decision Point (PDP) to select which policy objects should collect usage information, what information should be collected and when it should be reported. This PIB requires the presence of other PIBs (defined elsewhere) that provide the policy objects that usage information is collected from. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-feedback-fr-pib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-feedback-fr-pib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-20130143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-feedback-fr-pib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-feedback-fr-pib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-20130143.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Mon Dec 23 08:57:03 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02149 for ; Mon, 23 Dec 2002 08:57:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18QT5S-000527-00 for rap-data@psg.com; Mon, 23 Dec 2002 05:57:42 -0800 Received: from [211.45.79.102] (helo=jupiter.jmi.co.kr) by psg.com with smtp (Exim 3.36 #2) id 18QT5N-00051K-00 for rap@ops.ietf.org; Mon, 23 Dec 2002 05:57:37 -0800 Received: (qmail 13741 invoked by uid 525); 23 Dec 2002 22:58:27 +0900 Received: (qmail 13724 invoked from network); 23 Dec 2002 22:58:25 +0900 Received: from unknown (HELO polo.jmi.co.kr) (211.45.79.31) by 0 with SMTP; 23 Dec 2002 22:58:25 +0900 Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by polo.jmi.co.kr (8.9.0/8.9.0) with ESMTP id XAA29414 for ; Mon, 23 Dec 2002 23:01:33 +0900 (KST) Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18QSEj-0003lR-00 for ietf-announce-list@ran.ietf.org; Mon, 23 Dec 2002 08:03:13 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18QSCN-0003fr-00 for all-ietf@ran.ietf.org; Mon, 23 Dec 2002 08:00:47 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27784; Mon, 23 Dec 2002 07:56:07 -0500 (EST) Message-Id: <200212231256.HAA27784@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: hangsang@dreamwiz.com Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-feedback-fr-pib-05.txt Date: Mon, 23 Dec 2002 07:56:07 -0500 X-Spam-Status: No, hits=4.0 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: **** Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : Framework Policy Information Base for Usage Feedback Author(s) : D. Rawlins et al. Filename : draft-ietf-rap-feedback-fr-pib-05.txt Pages : 31 Date : 2002-12-20 This document describes a portion of the Policy Information Base (PIB) to control policy usage collection and reporting in a device. The provisioning classes specified here allow a Policy Decision Point (PDP) to select which policy objects should collect usage information, what information should be collected and when it should be reported. This PIB requires the presence of other PIBs (defined elsewhere) that provide the policy objects that usage information is collected from. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-feedback-fr-pib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-feedback-fr-pib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-20130143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-feedback-fr-pib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-feedback-fr-pib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-20130143.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Dec 27 13:46:17 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12823 for ; Fri, 27 Dec 2002 13:46:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18RzVP-000Fez-00 for rap-data@psg.com; Fri, 27 Dec 2002 10:46:47 -0800 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #2) id 18RzVM-000Fd7-00 for rap@ops.ietf.org; Fri, 27 Dec 2002 10:46:44 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gBRIkCG09793 for ; Fri, 27 Dec 2002 13:46:12 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Dec 2002 19:46:11 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15583D6C0@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Rap-wg (E-mail)" Date: Fri, 27 Dec 2002 19:46:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.0 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01,SUBJ_MISSING version=2.43 X-Spam-Level: * Sender: owner-rap@ops.ietf.org Precedence: bulk The IESG just approved this document with the following RFC-Editor note (request for change/fix): RFC-Editor note: Pls expand the acronym PDP in the 1st sentence of the abstract. That is, pls change current text: Abstract Common Open Policy Services (COPS) Protocol (RFC2748), defined the capability of reporting information to the PDP. The types of into this new text: Abstract Common Open Policy Services (COPS) Protocol (RFC2748), defined the capability of reporting information to the Policy Decision Point (PDP). The types of Thanks to the WG and specifically to the authors/editors. Thanks, Bert From owner-rap@ops.ietf.org Fri Dec 27 15:50:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14125 for ; Fri, 27 Dec 2002 15:50:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18S1T0-000Kn2-00 for rap-data@psg.com; Fri, 27 Dec 2002 12:52:26 -0800 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #2) id 18S1Sx-000Klx-00 for rap@ops.ietf.org; Fri, 27 Dec 2002 12:52:23 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gBRKpqN13690 for ; Fri, 27 Dec 2002 15:51:52 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Dec 2002 21:51:51 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15583D6C2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Rap-wg (E-mail)" Subject: draft-ietf-rap-feedback-frwk-04.txt Date: Fri, 27 Dec 2002 21:51:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.4 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Guess I should have added the document that in fact was approved. It is in the subject line now. Thanks, Bert > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: vrijdag 27 december 2002 19:46 > To: Rap-wg (E-mail) > Subject: > > > The IESG just approved this document with the following > RFC-Editor note (request for change/fix): > > RFC-Editor note: > > Pls expand the acronym PDP in the 1st sentence of the abstract. > That is, pls change current text: > Abstract > Common Open Policy Services (COPS) Protocol (RFC2748), > defined the > capability of reporting information to the PDP. The types of > into this new text: > Abstract > Common Open Policy Services (COPS) Protocol (RFC2748), > defined the > capability of reporting information to the Policy > Decision Point (PDP). > The types of > > Thanks to the WG and specifically to the authors/editors. > > Thanks, > Bert > From owner-rap@ops.ietf.org Tue Dec 31 11:40:07 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25537 for ; Tue, 31 Dec 2002 11:40:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18TPS5-000Ev1-00 for rap-data@psg.com; Tue, 31 Dec 2002 08:41:13 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18TPS2-000Euo-00 for rap@ops.ietf.org; Tue, 31 Dec 2002 08:41:10 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25523; Tue, 31 Dec 2002 11:37:57 -0500 (EST) Message-Id: <200212311637.LAA25523@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , rap@ops.ietf.org From: The IESG Subject: Document Action: Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR) to Informational Date: Tue, 31 Dec 2002 11:37:57 -0500 X-Spam-Status: No, hits=1.4 required=5.0 tests=SPAM_PHRASE_00_01,TO_MALFORMED version=2.43 X-Spam-Level: * Sender: owner-rap@ops.ietf.org Precedence: bulk The IESG has approved the Internet-Draft 'Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR)' as an Informational RFC. This document is the product of the Resource Allocation Protocol Working Group. The IESG contact persons are Randy Bush and Bert Wijnen. RFC-Editor note: Pls expand the acronym PDP in the 1st sentence of the abstract. That is, pls change current text: Abstract Common Open Policy Services (COPS) Protocol (RFC2748), defined the capability of reporting information to the PDP. The types of into this new text: Abstract Common Open Policy Services (COPS) Protocol (RFC2748), defined the capability of reporting information to the Policy Decision Point (PDP). The types of