From daemon@optimus.ietf.org Wed May 1 15:45:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23942 for ; Wed, 1 May 2002 15:45:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA05959 for policy-archive@odin.ietf.org; Wed, 1 May 2002 15:45:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05796; Wed, 1 May 2002 15:42:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05766 for ; Wed, 1 May 2002 15:42:50 -0400 (EDT) Received: from longmail2.lboard.com ([63.109.116.89]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23639 for ; Wed, 1 May 2002 15:42:48 -0400 (EDT) Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id <2FCSNT06>; Wed, 1 May 2002 15:41:10 -0400 Message-ID: From: Ed Ellesson To: "'policy@ietf.org'" Cc: "'Joel Halpern'" , "'Wijnen, Bert (Bert)'" , "'Randy Bush'" Date: Wed, 1 May 2002 15:41:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Policy] End of Working Group Last Call for QDDIM Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org This is to announce the close of the Last Call on the QDDIM draft. http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device-info-model- 07.txt There were no comments to the working group mailing list on this draft during the last call period. Our next step will be to forward the draft to our Area Directors for consideration by the IESG as a Proposed Standard RFC. Thanks to all who contributed! Regards, Ed Ellesson, with Joel Halpern Chairs, Policy Framework WG _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Fri May 3 09:53:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13548 for ; Fri, 3 May 2002 09:53:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA07337 for policy-archive@odin.ietf.org; Fri, 3 May 2002 09:53:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06633; Fri, 3 May 2002 09:42:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06603 for ; Fri, 3 May 2002 09:42:28 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13188 for ; Fri, 3 May 2002 09:42:24 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g43Dfud01826 for ; Fri, 3 May 2002 09:41:57 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2GN8FB1H>; Fri, 3 May 2002 15:41:56 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: "Larry S. Bartz" , IETF Policy WG LIST , joel@stevecrocker.com, eellesson@lboard.com, randy@psg.com, bwijnen@lucent.com Date: Fri, 3 May 2002 15:41:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Policy] RE: PCLS status? Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Sorry, my fault. I had it in my queue and I was having discussions with authors/wg chairs and reviewer. I forgot to turn on a flag to show it was in review. It is now in the hands of AD and being prepared for IESG agenda. Bert > -----Original Message----- > From: Larry S. Bartz [mailto:lbartz@parnelli.indy.cr.irs.gov] > Sent: Monday, April 29, 2002 10:16 PM > To: IETF Policy WG LIST; joel@stevecrocker.com; eellesson@lboard.com; > randy@psg.com; bwijnen@lucent.com > Subject: PCLS status? > > > What is the status of draft-ietf-policy-core-schema-14.txt? > > It is not mentioned in http://www.ops.ietf.org/draft-status.html > > -- > #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > :::::::::| > # Larry Bartz > # > # voice (317) 226-7060 > # FAX (317) 226-6378 > #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > :::::::::| > > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Fri May 3 15:06:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24885 for ; Fri, 3 May 2002 15:06:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA26348 for policy-archive@odin.ietf.org; Fri, 3 May 2002 15:06:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26039; Fri, 3 May 2002 15:00:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25284 for ; Fri, 3 May 2002 14:52:21 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24305; Fri, 3 May 2002 14:52:16 -0400 (EDT) Message-Id: <200205031852.OAA24305@ietf.org> To: IETF-Announce: ; Cc: policy@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Fri, 03 May 2002 14:52:16 -0400 Subject: [Policy] Last Call: Policy Core Information Model Extensions to Proposed Standard Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org The IESG has received a request from the Policy Framework Working Group to consider Policy Core Information Model Extensions as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 17, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-policy-pcim-ext-07.txt _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Mon May 6 09:57:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19229 for ; Mon, 6 May 2002 09:57:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA21592 for policy-archive@odin.ietf.org; Mon, 6 May 2002 09:58:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20276; Mon, 6 May 2002 09:43:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20201 for ; Mon, 6 May 2002 09:43:40 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18593; Mon, 6 May 2002 09:43:33 -0400 (EDT) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g46DgwP05811; Mon, 6 May 2002 09:42:58 -0400 (EDT) Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KHDTMXKH; Mon, 6 May 2002 09:42:48 -0400 Received: from metasolv.com (mpana-1.ca.nortel.com [47.128.183.58]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JZLB1Q1Q; Mon, 6 May 2002 09:43:07 -0400 Message-ID: <3CD68832.B35ADD9B@metasolv.com> Date: Mon, 06 May 2002 09:42:10 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Mircea Pana Reply-To: mpana@metasolv.com Organization: Metasolv Software X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: iesg@ietf.org CC: policy@ietf.org, brunner@ccrle.nec.de, andreaw@cisco.com Subject: Re: [Policy] Last Call: Policy Core Information Model Extensions toProposed Standard References: <200205031852.OAA24305@ietf.org> Content-Type: multipart/mixed; boundary="------------E031ABB7D50C95A683504B9C" Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org This is a multi-part message in MIME format. --------------E031ABB7D50C95A683504B9C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The "FilterList and EntriesInFilterList" issue, discussed in the attached message, has not been closed yet. I would appreciate if the authors of PCIMe could address it. Thanks, Mircea Pana. The IESG wrote: > The IESG has received a request from the Policy Framework Working Group > to consider Policy Core Information Model Extensions > as a Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by May 17, 2002. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-policy-pcim-ext-07.txt > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy --------------E031ABB7D50C95A683504B9C Content-Type: message/rfc822 Content-Disposition: inline Received: from zrtps0km.us.nortel.com ([47.140.192.54]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2C54GPVB; Wed, 3 Apr 2002 12:04:13 -0500 Received: from ertpsms3.internet.nortel.com (ertpsms3.internet.nortel.com [47.234.0.33] (may be forged)) by zrtps0km.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g33H3uQ02659 for ; Wed, 3 Apr 2002 12:03:56 -0500 (EST) Received: from srvmaddog.metasolv.com (mail.metasolv.com [12.105.131.5]) by ertpsms3.internet.nortel.com with SMTP (MailShield v1.5); Wed, 03 Apr 2002 12:10:56 -0500 Received: by mail.metasolv.com with Internet Mail Service (5.5.2653.19) id <218XYA89>; Wed, 3 Apr 2002 11:05:43 -0600 Received: from wsiegsymantec.metasolv.com ([10.1.1.45]) by srvmaddog.metasolv.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 218XYA86; Wed, 3 Apr 2002 11:05:38 -0600 Received: from smtpgtwy.metasolv.com ([10.1.1.105]) by wsiegsymantec.metasolv.com (NAVGW 2.5.1.6) with SMTP id M2002040311013530535 for ; Wed, 03 Apr 2002 11:01:35 -0600 Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09151; Wed, 3 Apr 2002 11:57:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09120 for ; Wed, 3 Apr 2002 11:57:35 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09002 for ; Wed, 3 Apr 2002 11:57:31 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33Gv1i19584; Wed, 3 Apr 2002 11:57:01 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33Gux511703; Wed, 3 Apr 2002 11:56:59 -0500 (EST) Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2C54G3TW; Wed, 3 Apr 2002 11:56:55 -0500 Received: from metasolv.com (mpana-1.ca.nortel.com [47.128.183.58]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HQL95K99; Wed, 3 Apr 2002 11:56:53 -0500 Message-ID: <3CAB348A.85EA1AA8@metasolv.com> Date: Wed, 03 Apr 2002 11:57:46 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Mircea Pana Reply-To: mpana@metasolv.com Organization: Metasolv Software X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: brunner@ccrle.nec.de CC: Andrea Westerinen , IETF Policy , "Wg-Policy@Dmtf. Org" , "Wg-Network@Dmtf. Org" Subject: Re: [Policy] FilterList and EntriesInFilterList in PCIMe References: <3C854B31.63F427AC@metasolv.com> <18556342.1017769719@[192.168.102.79]> Content-Type: text/plain; charset=us-ascii Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org X-SMTP-HELO: srvmaddog.metasolv.com X-SMTP-MAIL-FROM: X-SMTP-RCPT-TO: mpana@nortelnetworks.com X-SMTP-PEER-INFO: mail.metasolv.com [12.105.131.5] X-Mozilla-Status2: 00000000 Content-Transfer-Encoding: 7bit Marcus, I agree that this restriction should be generally applicable through PCIMe to submodels. Andrea's mail seemed to suggest that the restriction would only apply to DiffServ/QoS. This is where my first issue came from. In the second issue, I compare "FilterList" with "CompoundContition". Either can be used to aggregate a Set of traffic selection criteria. IMO either both or none of them should allow component ordering. My preference is for no ordering. So, the text in PCIMe would read: " 5.21. The Class FilterList This is a concrete class that aggregates instances of (subclasses of) FilterEntryBase via the aggregation EntriesInFilterList. It is possible to aggregate different types of filters into a single FilterList - for example, packet header filters (represented by the IpHeadersFilter class) and security filters (represented by subclasses of FilterEntryBase defined by IPsec). The aggregation property EntriesInFilterList.EntrySequence is always set to 0, to indicate that the aggregated filter entries are ANDed together to form a selector for a class of traffic." Regards, Mircea. Marcus Brunner wrote: > Mircea, > > --On Tuesday, March 05, 2002 5:48 PM -0500 Mircea Pana > wrote: > > > Andrea, > > > > > > I have two issues that are somewhat related to each other: > > > > 1. If the restriction only applies to DiffServ then why is it defined in > > PCIMe? If, as you explain, this restriction is there to align with the > > DiffServ model then (IMO) QPIM would be a better place for it. PCIMe > > would simply indicate that if sequencing is not intended then the value > > "0" is to be used and as result the aggregated filters are ANDed. > > > > It is defined in PCIMe because we want to use it in other models (e.g. > MPLS), and has been regarded very general. > > Does your mail mean that the text proposal from Andrea is not what you want > to see? > > > 2. However, if PCIMe allows sequencing for device-level filters (a > > FilterList of FilterEntries), then why doesn't it have the same > > functionality for the domain-level equivalent (a CompoundCondition of > > CompoundFilters)? I understand that the consensus is against component > > sequencing in the PCIMe CompoundCondition. Maybe the sequencing should > > be removed from the FilterList on the same premise that devices, due to > > their implementation, may not be able to honor it. > > I am sorry, but do not understand what you mean. > > Marcus > > > Regards, > > Mircea. > > > > > > > > > > > > Andrea Westerinen wrote: > >> > >> Mircea, When the restriction was originally discussed, it was put in > >> place to align the model with the DiffServ Informal Model. IE, to put a > >> default value in place such that the property COULD be used but may also > >> be ignored (and the default taken). So, this was specifically about QoS > >> and not about the general model. I am not sure where it got generalized > >> - or that it even should be generalized. I would recommend that we > >> remove the word "always" in the phrase "always takes its default value" > >> (Section 4.9.2). "Typically" or "usually" seems safer. > >> > >> The original thinking was to include all the model properties and align > >> the IETF and DMTF work, but also specify the "expected" defaults. > >> > >> Andrea > >> > >> -----Original Message----- > >> From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of > >> Mircea Pana > >> Sent: Monday, March 04, 2002 8:28 AM > >> To: IETF Policy > >> Subject: [Policy] FilterList and EntriesInFilterList in PCIMe > >> > >> The "FilterList" class imported from CIM, is redefined by PCIMe with an > >> additional restriction relative to the "EntriesInFilterList" > >> aggregation. This restriction is described in both Sections 4.9.2 and > >> 5.21. > >> > >> The two descriptions seem to be somewhat contradictory. Thus, while > >> 4.9.2 indicates the applicability of this restriction to *all* the > >> submodels: > >> > >> "For PCIMe and its submodels, the EntrySequence property in this > >> aggregation always takes its default value '0', indicating that > >> the aggregated filter entries are ANDed together." > >> > >> in section 5.21 the scope seems to be reduced to QoS submodel(s) *only*: > >> > >> "In modeling QoS classifiers, however, this property is always > >> set to 0, to indicate that the aggregated filter entries are > >> ANDed together to form a selector for a class of traffic." > >> > >> In section 5.21, was the reference to QoS intended as a scope limitation > >> or was that used as example? IMO clarification is necessary. > >> > >> Regards, > >> Mircea. > >> > >> _______________________________________________ > >> Policy mailing list > >> Policy@ietf.org > >> https://www1.ietf.org/mailman/listinfo/policy > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy --------------E031ABB7D50C95A683504B9C-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Mon May 6 12:46:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26528 for ; Mon, 6 May 2002 12:46:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA04694 for policy-archive@odin.ietf.org; Mon, 6 May 2002 12:46:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04103; Mon, 6 May 2002 12:34:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16966 for ; Sat, 4 May 2002 08:01:01 -0400 (EDT) Received: from duck.doc.ic.ac.uk (IDENT:exim@duck.doc.ic.ac.uk [146.169.1.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22945 for ; Sat, 4 May 2002 08:00:56 -0400 (EDT) Received: from [146.169.27.14] (helo=mss-home-pc.doc.ic.ac.uk) by duck.doc.ic.ac.uk with esmtp (Exim 3.16 #7) id 173yDg-0004K8-00 for policy@ietf.org; Sat, 04 May 2002 13:00:56 +0100 Message-Id: <5.1.0.14.2.20020504125823.03f9f030@pop.doc.ic.ac.uk> X-Sender: mss@pop.doc.ic.ac.uk X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 04 May 2002 13:00:24 +0100 To: policy@ietf.org From: Morris Sloman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Policy] POLICY 2002 - 2nd Call for Participation [ietf] Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org (Please accept our apologies if you receive duplicates of this message) (Please forward this Call to interested colleagues and groups) POLICY 2002 - Call for Participation IEEE 3rd International Workshop on Policies for Distributed Systems and Networks 5-7 June, 2002 Hosted by the Naval Postgraduate School, Monterey, USA URL: http://www.policy-workshop.org/2002/ Policy-based systems continue to be the subject of a wide range of activities in universities, standardisation bodies and within industry. They have a wide spectrum of applicability ranging from systems management, to quality of service adaptation, to security and enterprise modelling. POLICY 2002 is the 3rd in a highly successful series of workshops, which since 1999 has brought together leading researchers and industry experts to discuss problems, solutions and experiences in developing policy-based systems. The Workshop programme includes 17 full papers and 13 position papers selected from 67 submissions; as well as invited talks, a panel and two Birds of a Feather sessions. This year POLICY 2002 is co-located with SACMAT 2002 (3-4 June 2002) Important Registration Information ---------------------------------- Due to increased security requirements participants must register in advance (on-site registrations will not be allowed). The deadlines are: Early Registration: ** 15 May 2002 ** Late Registration: 30 May 2002 For Program Details and registration see http://www.policy-workshop.org/2002/ _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Tue May 7 11:47:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13438 for ; Tue, 7 May 2002 11:47:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06249 for policy-archive@odin.ietf.org; Tue, 7 May 2002 11:47:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04049; Tue, 7 May 2002 11:26:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04016 for ; Tue, 7 May 2002 11:26:06 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12241 for ; Tue, 7 May 2002 11:25:59 -0400 (EDT) From: remoore@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g47FQ064097898; Tue, 7 May 2002 11:26:00 -0400 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g47FPxC209864; Tue, 7 May 2002 11:25:59 -0400 Subject: Re: [Policy] Last Call: Policy Core Information Model Extensions toProposed Standard To: mpana@metasolv.com Cc: andreaw@cisco.com, brunner@ccrle.nec.de, iesg@ietf.org, policy@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Tue, 7 May 2002 11:33:12 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build V60_M13_04292002 Pre-release 2|April 29, 2002) at 05/07/2002 11:25:57 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBE121DFC6801B8f9e8a93df938690918c0ABBE121DFC6801B" Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --0__=0ABBE121DFC6801B8f9e8a93df938690918c0ABBE121DFC6801B Content-type: multipart/alternative; Boundary="1__=0ABBE121DFC6801B8f9e8a93df938690918c0ABBE121DFC6801B" --1__=0ABBE121DFC6801B8f9e8a93df938690918c0ABBE121DFC6801B Content-type: text/plain; charset=US-ASCII Mircea, Sorry - we have been very slow responding to you here. I talked this over with Lee and Andrea, and we, at least, have no problem with aligning both PCIMe and the DMTF model on your proposed text: " 5.21. The Class FilterList This is a concrete class that aggregates instances of (subclasses of) FilterEntryBase via the aggregation EntriesInFilterList. It is possible to aggregate different types of filters into a single FilterList - for example, packet header filters (represented by the IpHeadersFilter class) and security filters (represented by subclasses of FilterEntryBase defined by IPsec). The aggregation property EntriesInFilterList.EntrySequence is always set to 0, to indicate that the aggregated filter entries are ANDed together to form a selector for a class of traffic." Unless somebody else objects, I'll make this update to PCIMe after it exits IETF Last Call. (I want to wait until then in case there are other changes that come out of Last Call - we should be able to make do with just one more revision.) Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com Mircea Pana cc: policy@ietf.org, brunner@ccrle.nec.de, andreaw@cisco.com Sent by: policy- Subject: Re: [Policy] Last Call: Policy Core Information Model Extensions toProposed admin@ietf.org Standard 05/06/02 09:42 AM Please respond to mpana The "FilterList and EntriesInFilterList" issue, discussed in the attached message, has not been closed yet. I would appreciate if the authors of PCIMe could address it. Thanks, Mircea Pana. The IESG wrote: > The IESG has received a request from the Policy Framework Working Group > to consider Policy Core Information Model Extensions > as a Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by May 17, 2002. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-policy-pcim-ext-07.txt > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy ----- Message from Mircea Pana on Wed, 03 Apr 2002 11: 57:46 -0500 ----- To: brunner@ccrle.nec.de cc: Andrea Westerinen , IETF Policy , "Wg-Policy@Dmtf. Org" , "Wg-Network@Dmtf. Org" Subject: Re: [Policy] FilterList and EntriesInFilterList in PCIMe Marcus, I agree that this restriction should be generally applicable through PCIMe to submodels. Andrea's mail seemed to suggest that the restriction would only apply to DiffServ/QoS. This is where my first issue came from. In the second issue, I compare "FilterList" with "CompoundContition". Either can be used to aggregate a Set of traffic selection criteria. IMO either both or none of them should allow component ordering. My preference is for no ordering. So, the text in PCIMe would read: " 5.21. The Class FilterList This is a concrete class that aggregates instances of (subclasses of) FilterEntryBase via the aggregation EntriesInFilterList. It is possible to aggregate different types of filters into a single FilterList - for example, packet header filters (represented by the IpHeadersFilter class) and security filters (represented by subclasses of FilterEntryBase defined by IPsec). The aggregation property EntriesInFilterList.EntrySequence is always set to 0, to indicate that the aggregated filter entries are ANDed together to form a selector for a class of traffic." Regards, Mircea. Marcus Brunner wrote: > Mircea, > > --On Tuesday, March 05, 2002 5:48 PM -0500 Mircea Pana > wrote: > > > Andrea, > > > > > > I have two issues that are somewhat related to each other: > > > > 1. If the restriction only applies to DiffServ then why is it defined in > > PCIMe? If, as you explain, this restriction is there to align with the > > DiffServ model then (IMO) QPIM would be a better place for it. PCIMe > > would simply indicate that if sequencing is not intended then the value > > "0" is to be used and as result the aggregated filters are ANDed. > > > > It is defined in PCIMe because we want to use it in other models (e.g. > MPLS), and has been regarded very general. > > Does your mail mean that the text proposal from Andrea is not what you want > to see? > > > 2. However, if PCIMe allows sequencing for device-level filters (a > > FilterList of FilterEntries), then why doesn't it have the same > > functionality for the domain-level equivalent (a CompoundCondition of > > CompoundFilters)? I understand that the consensus is against component > > sequencing in the PCIMe CompoundCondition. Maybe the sequencing should > > be removed from the FilterList on the same premise that devices, due to > > their implementation, may not be able to honor it. > > I am sorry, but do not understand what you mean. > > Marcus > > > Regards, > > Mircea. > > > > > > > > > > > > Andrea Westerinen wrote: > >> > >> Mircea, When the restriction was originally discussed, it was put in > >> place to align the model with the DiffServ Informal Model. IE, to put a > >> default value in place such that the property COULD be used but may also > >> be ignored (and the default taken). So, this was specifically about QoS > >> and not about the general model. I am not sure where it got generalized > >> - or that it even should be generalized. I would recommend that we > >> remove the word "always" in the phrase "always takes its default value" > >> (Section 4.9.2). "Typically" or "usually" seems safer. > >> > >> The original thinking was to include all the model properties and align > >> the IETF and DMTF work, but also specify the "expected" defaults. > >> > >> Andrea > >> > >> -----Original Message----- > >> From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of > >> Mircea Pana > >> Sent: Monday, March 04, 2002 8:28 AM > >> To: IETF Policy > >> Subject: [Policy] FilterList and EntriesInFilterList in PCIMe > >> > >> The "FilterList" class imported from CIM, is redefined by PCIMe with an > >> additional restriction relative to the "EntriesInFilterList" > >> aggregation. This restriction is described in both Sections 4.9.2 and > >> 5.21. > >> > >> The two descriptions seem to be somewhat contradictory. Thus, while > >> 4.9.2 indicates the applicability of this restriction to *all* the > >> submodels: > >> > >> "For PCIMe and its submodels, the EntrySequence property in this > >> aggregation always takes its default value '0', indicating that > >> the aggregated filter entries are ANDed together." > >> > >> in section 5.21 the scope seems to be reduced to QoS submodel(s) *only*: > >> > >> "In modeling QoS classifiers, however, this property is always > >> set to 0, to indicate that the aggregated filter entries are > >> ANDed together to form a selector for a class of traffic." > >> > >> In section 5.21, was the reference to QoS intended as a scope limitation > >> or was that used as example? IMO clarification is necessary. > >> > >> Regards, > >> Mircea. > >> > >> _______________________________________________ > >> Policy mailing list > >> Policy@ietf.org > >> https://www1.ietf.org/mailman/listinfo/policy > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > personal home page: http://www.brubers.org/marcus _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy --1__=0ABBE121DFC6801B8f9e8a93df938690918c0ABBE121DFC6801B Content-type: text/html; charset=US-ASCII Content-Disposition: inline Mircea,

Sorry - we have been very slow responding to you here. I talked this over with Lee and Andrea, and we, at least, have no problem with aligning both PCIMe and the DMTF model on your proposed text:


" 5.21. The Class FilterList

This is a concrete class that aggregates instances of (subclasses of)
FilterEntryBase via the aggregation EntriesInFilterList. It is possible
to aggregate different types of filters into a single FilterList - for
example, packet header filters (represented by the IpHeadersFilter class)
and security filters (represented by subclasses of FilterEntryBase
defined by IPsec).

The aggregation property EntriesInFilterList.EntrySequence is always
set to 0, to indicate that the aggregated filter entries are ANDed together
to form a selector for a class of traffic."

Unless somebody else objects, I'll make this update to PCIMe after it exits IETF Last Call. (I want to wait until then in case there are other changes that come out of Last Call - we should be able to make do with just one more revision.)

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com

Mircea Pana <mpana@metasolv.com>




          Mircea Pana <mpana@metasolv.com>
          Sent by: policy-admin@ietf.org

          05/06/02 09:42 AM
          Please respond to mpana



To: iesg@ietf.org
cc: policy@ietf.org, brunner@ccrle.nec.de, andreaw@cisco.com
Subject: Re: [Policy] Last Call: Policy Core Information Model Extensions toProposed Standard


The "FilterList and EntriesInFilterList" issue, discussed in the attached
message, has not been closed yet. I would appreciate if the authors of
PCIMe could address it.

Thanks,
Mircea Pana.


The IESG wrote:

> The IESG has received a request from the Policy Framework Working Group
> to consider Policy Core Information Model Extensions
> <draft-ietf-policy-pcim-ext-07.txt> as a Proposed Standard.
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by May 17, 2002.
>
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-policy-pcim-ext-07.txt
>
> _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy

----- Message from Mircea Pana <mpana@metasolv.com> on Wed, 03 Apr 2002 11:57:46 -0500 -----
To:
brunner@ccrle.nec.de
cc:
Andrea Westerinen <andreaw@cisco.com>, IETF Policy <policy@ietf.org>, "Wg-Policy@Dmtf. Org" <wg-policy@dmtf.org>, "Wg-Network@Dmtf. Org" <wg-network@dmtf.org>
Subject:
Re: [Policy] FilterList and EntriesInFilterList in PCIMe
Marcus,

I agree that this restriction should be generally applicable through PCIMe to
submodels. Andrea's mail seemed to suggest that the restriction would only
apply to DiffServ/QoS. This is where my first issue came from.

In the second issue, I compare "FilterList" with "CompoundContition". Either
can be used to aggregate a Set of traffic selection criteria. IMO either both
or none of them should allow component ordering. My preference is for no
ordering.

So, the text in PCIMe would read:

" 5.21. The Class FilterList

This is a concrete class that aggregates instances of (subclasses of)
FilterEntryBase via the aggregation EntriesInFilterList. It is possible
to aggregate different types of filters into a single FilterList - for
example, packet header filters (represented by the IpHeadersFilter class)
and security filters (represented by subclasses of FilterEntryBase
defined by IPsec).

The aggregation property EntriesInFilterList.EntrySequence is always
set to 0, to indicate that the aggregated filter entries are ANDed together
to form a selector for a class of traffic."

Regards,
Mircea.


Marcus Brunner wrote:

> Mircea,
>
> --On Tuesday, March 05, 2002 5:48 PM -0500 Mircea Pana <mpana@metasolv.com>
> wrote:
>
> > Andrea,
> >
> >
> > I have two issues that are somewhat related to each other:
> >
> > 1. If the restriction only applies to DiffServ then why is it defined in
> > PCIMe? If, as you explain, this restriction is there to align with the
> > DiffServ model then (IMO) QPIM would be a better place for it. PCIMe
> > would simply indicate that if sequencing is not intended then the value
> > "0" is to be used and as result the aggregated filters are ANDed.
> >
>
> It is defined in PCIMe because we want to use it in other models (e.g.
> MPLS), and has been regarded very general.
>
> Does your mail mean that the text proposal from Andrea is not what you want
> to see?
>
> > 2. However, if PCIMe allows sequencing for device-level filters (a
> > FilterList of FilterEntries), then why doesn't it have the same
> > functionality for the domain-level equivalent (a CompoundCondition of
> > CompoundFilters)? I understand that the consensus is against component
> > sequencing in the PCIMe CompoundCondition. Maybe the sequencing should
> > be removed from the FilterList on the same premise that devices, due to
> > their implementation, may not be able to honor it.
>
> I am sorry, but do not understand what you mean.
>
> Marcus
>
> > Regards,
> > Mircea.
> >
> >
> >
> >
> >
> > Andrea Westerinen wrote:
> >>
> >> Mircea, When the restriction was originally discussed, it was put in
> >> place to align the model with the DiffServ Informal Model. IE, to put a
> >> default value in place such that the property COULD be used but may also
> >> be ignored (and the default taken). So, this was specifically about QoS
> >> and not about the general model. I am not sure where it got generalized
> >> - or that it even should be generalized. I would recommend that we
> >> remove the word "always" in the phrase "always takes its default value"
> >> (Section 4.9.2). "Typically" or "usually" seems safer.
> >>
> >> The original thinking was to include all the model properties and align
> >> the IETF and DMTF work, but also specify the "expected" defaults.
> >>
> >> Andrea
> >>
> >> -----Original Message-----
> >> From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of
> >> Mircea Pana
> >> Sent: Monday, March 04, 2002 8:28 AM
> >> To: IETF Policy
> >> Subject: [Policy] FilterList and EntriesInFilterList in PCIMe
> >>
> >> The "FilterList" class imported from CIM, is redefined by PCIMe with an
> >> additional restriction relative to the "EntriesInFilterList"
> >> aggregation. This restriction is described in both Sections 4.9.2 and
> >> 5.21.
> >>
> >> The two descriptions seem to be somewhat contradictory. Thus, while
> >> 4.9.2 indicates the applicability of this restriction to *all* the
> >> submodels:
> >>
> >> "For PCIMe and its submodels, the EntrySequence property in this
> >> aggregation always takes its default value '0', indicating that
> >> the aggregated filter entries are ANDed together."
> >>
> >> in section 5.21 the scope seems to be reduced to QoS submodel(s) *only*:
> >>
> >> "In modeling QoS classifiers, however, this property is always
> >> set to 0, to indicate that the aggregated filter entries are
> >> ANDed together to form a selector for a class of traffic."
> >>
> >> In section 5.21, was the reference to QoS intended as a scope limitation
> >> or was that used as example? IMO clarification is necessary.
> >>
> >> Regards,
> >> Mircea.
> >>
> >> _______________________________________________
> >> Policy mailing list
> >> Policy@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/policy
>
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW: http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus


_______________________________________________
Policy mailing list
Policy@ietf.org
https://www1.ietf.org/mailman/listinfo/policy

--1__=0ABBE121DFC6801B8f9e8a93df938690918c0ABBE121DFC6801B-- --0__=0ABBE121DFC6801B8f9e8a93df938690918c0ABBE121DFC6801B Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=0ABBE121DFC6801B8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE121DFC6801B8f9e8a93df938690918c0ABBE121DFC6801B Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=0ABBE121DFC6801B8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE121DFC6801B8f9e8a93df938690918c0ABBE121DFC6801B-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Tue May 14 18:40:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10245 for ; Tue, 14 May 2002 18:40:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29786 for policy-archive@odin.ietf.org; Tue, 14 May 2002 18:40:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28938; Tue, 14 May 2002 18:29:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28896 for ; Tue, 14 May 2002 18:29:03 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09783 for ; Tue, 14 May 2002 18:28:50 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4EMSOuF017953; Tue, 14 May 2002 15:28:24 -0700 (PDT) Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ACW87326; Tue, 14 May 2002 15:28:30 -0700 (PDT) From: "Andrea Westerinen" To: "Policy@Ietf. Org" , "Bob Moore" Date: Tue, 14 May 2002 15:28:30 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01C1FB5C.002014B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [Policy] Inconsistencies in QDDIM -07 Draft Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_004E_01C1FB5C.002014B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In reading QDDIM very closely :-), I noticed some inconsistencies in the text in Section 3, in the formal class definitions in Section 4, and in the intent. Here are my observations and recommendations ... 1. For RED droppers, I think that we wanted the following ... A REDDropperService can be related to many DropThresholdCalculationServices (many to many), but each CalculationService examines a single queue (many to one). 2. This means that ... IF you define a DropThresholdCalculationService, you really MUST specify the queue that is examined. So, CalculationBasedOnQueue should have a cardinality of 1..1 on the QueuingService side (currently it has 0..1). AND A REDDropper MAY be associated with one or more CalculationServices (each looking at a specific queue). So, CalculationServiceForDropper should have a cardinality of 0..n on the DropThresholdCalculationService side (currently it is a mandatory 1). 3. For a HeadTailDropperService, its determinations can also be based on several queues (as discussed at the bottom of page 23). So, HeadTailDropQueueBinding should have a cardinality of 1..n for the QueuingService (currently, it has mandatory 1). I agree that at least queue is mandatory - but more than one can be examined. Andrea ------=_NextPart_000_004E_01C1FB5C.002014B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In=20 reading QDDIM very closely :-), I noticed some inconsistencies in the = text=20 in Section 3, in the formal class definitions in Section 4, and in = the=20 intent.  Here are my observations and recommendations=20 ...
 
1.  For RED droppers, I think that = we=20 wanted the following ...
A=20 REDDropperService can be related to many = DropThresholdCalculationServices (many=20 to many), but each CalculationService examines a single queue (many=20 to one).
 
2.=20 This means that ... 
IF you=20 define a DropThresholdCalculationService, you really MUST specify the=20 queue that is examined.  So, CalculationBasedOnQueue should = have a=20 cardinality of 1..1 on the QueuingService side (currently it has=20 0..1).  
AND
A=20 REDDropper MAY be associated with one or more CalculationServices (each = looking=20 at a specific queue).  So, CalculationServiceForDropper should have = a=20 cardinality of 0..n on the DropThresholdCalculationService side = (currently it is=20 a mandatory 1).   
 
3.  For a HeadTailDropperService, its=20 determinations can also be based on several queues (as discussed at = the=20 bottom of page 23).  So, HeadTailDropQueueBinding should have a = cardinality=20 of 1..n for the QueuingService (currently, it has mandatory 1).  I = agree=20 that at least queue is mandatory - but more than one can be=20 examined.
 
Andrea 


 
------=_NextPart_000_004E_01C1FB5C.002014B0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Wed May 15 10:24:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06736 for ; Wed, 15 May 2002 10:24:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24418 for policy-archive@odin.ietf.org; Wed, 15 May 2002 10:24:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23691; Wed, 15 May 2002 10:17:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23664 for ; Wed, 15 May 2002 10:17:06 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06132 for ; Wed, 15 May 2002 10:16:51 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4FEGYs0010832; Wed, 15 May 2002 07:16:34 -0700 (PDT) Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ACX00021; Wed, 15 May 2002 07:16:34 -0700 (PDT) From: "Andrea Westerinen" To: "Policy@Ietf. Org" , "Bob Moore" Date: Wed, 15 May 2002 07:16:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [Policy] QDDIM Question Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit Don't you need a DepthUnits enum for QueuingService.CurrentQueueDepth as we have in the REDDropperService for the thresholds? Andrea _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Wed May 15 10:49:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08425 for ; Wed, 15 May 2002 10:49:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28610 for policy-archive@odin.ietf.org; Wed, 15 May 2002 10:49:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27200; Wed, 15 May 2002 10:40:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27164 for ; Wed, 15 May 2002 10:40:40 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07782 for ; Wed, 15 May 2002 10:40:24 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4FEe8Hs000724; Wed, 15 May 2002 07:40:08 -0700 (PDT) Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ACX00367; Wed, 15 May 2002 07:40:07 -0700 (PDT) From: "Andrea Westerinen" To: Cc: "Policy@Ietf. Org" Date: Wed, 15 May 2002 07:40:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C1FBE3.BC186D70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [Policy] RE: QDDIM Question Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1FBE3.BC186D70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C1FBE3.BC186D70" ------=_NextPart_001_0006_01C1FBE3.BC186D70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I also could live with any of these, but we do have to pick one. The property is not quite usable, as is. Andrea -----Original Message----- From: remoore@us.ibm.com [mailto:remoore@us.ibm.com] Sent: Wednesday, May 15, 2002 7:45 AM To: Andrea Westerinen Cc: Policy@Ietf. Org Subject: Re: QDDIM Question Well, you'd think so, wouldn't you? But then you wonder what it means for an instance of QueuingService to surface this one piece of state information to CIM in, say, bytes, while feeding queue-depth information to a RED dropper that has its thresholds specified in packets. Note that QDDIM says on page 15 that the job of modelling state has really not been done, and hence that this CurrentQueueDepth property is something of an anomaly. So maybe it's OK to have a queue that will only tell *us* its current depth in bytes, yet is perfectly willing to tell a dropper its current depth in packets. I see three choices we might make: - Remove the current depth property from QueuingService, and have it wait for the rest of the state model. - Pick a unit for it, either bytes or packets, and define it to always have that as its unit. - Add a units enum as you suggest. I could live with any of these. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" "Andrea Westerinen" 05/15/02 10:16 AM To: "Policy@Ietf. Org" , Robert Moore/Raleigh/IBM@IBMUS cc: Subject: QDDIM Question Don't you need a DepthUnits enum for QueuingService.CurrentQueueDepth as we have in the REDDropperService for the thresholds? Andrea ------=_NextPart_001_0006_01C1FBE3.BC186D70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I also=20 could live with any of these, but we do have to pick one.  The = property is=20 not quite usable, as is.
Andrea
-----Original Message-----
From: remoore@us.ibm.com = [mailto:remoore@us.ibm.com]
Sent: Wednesday, May 15, 2002 = 7:45=20 AM
To: Andrea Westerinen
Cc: Policy@Ietf.=20 Org
Subject: Re: QDDIM Question

Well, you'd think so, wouldn't you? But then you=20 wonder
what it means for an instance of = QueuingService to
surface this one = piece of=20 state information to CIM in,
say, = bytes, while=20 feeding queue-depth information to a
RED dropper=20 that has its thresholds specified in packets.
Note that QDDIM says on page 15 that the job of=20 modelling
state has really not been = done, and=20 hence that this
CurrentQueueDepth = property is=20 something of an anomaly.
So maybe it's = OK to=20 have a queue that will only tell *us*
its current=20 depth in bytes, yet is perfectly willing to
tell=20 a dropper its current depth in packets.

I see=20 three choices we might make:

- = Remove the=20 current depth property from QueuingService,
and=20 have it wait for the rest of the state model.
-=20 Pick a unit for it, either bytes or packets, and
define it to always have that as its = unit.
- Add a units enum as you suggest.

I could live with any of these.

Regards,
Bob

Bob Moore
Advanced Design and = Technology
Application Integration Middleware Division
IBM = Software=20 Group
+1-919-254-4436
remoore@us.ibm.com

3D"""Andrea = Westerinen"=20 <andreaw@cisco.com>


3D""
          "Andrea Westerinen"=20 <andreaw@cisco.com>=20

          05/15/02 10:16 = AM

3D""
 3D""

To:=20 "Policy@Ietf. Org" = <policy@ietf.org>, Robert=20 Moore/Raleigh/IBM@IBMUS
cc: =
Subject: QDDIM = Question


Don't you need a DepthUnits enum for=20 QueuingService.CurrentQueueDepth as we
have in the = REDDropperService for=20 the = thresholds?

Andrea


------=_NextPart_001_0006_01C1FBE3.BC186D70-- ------=_NextPart_000_0005_01C1FBE3.BC186D70 Content-Type: image/gif; name="graycol.gif" Content-Transfer-Encoding: base64 Content-ID: <340293914@15052002-0c74> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_0005_01C1FBE3.BC186D70 Content-Type: image/gif; name="ecblank.gif" Content-Transfer-Encoding: base64 Content-ID: <340293914@15052002-0c7b> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_0005_01C1FBE3.BC186D70-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Wed May 15 10:49:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08453 for ; Wed, 15 May 2002 10:49:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28624 for policy-archive@odin.ietf.org; Wed, 15 May 2002 10:49:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26685; Wed, 15 May 2002 10:38:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26652 for ; Wed, 15 May 2002 10:38:05 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07502 for ; Wed, 15 May 2002 10:37:50 -0400 (EDT) From: remoore@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4FEc2FD107512; Wed, 15 May 2002 10:38:02 -0400 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4FEbwp161804; Wed, 15 May 2002 10:37:58 -0400 To: "Andrea Westerinen" Cc: "Policy@Ietf. Org" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 15 May 2002 10:45:27 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build V60_M13_04292002 Pre-release 2|April 29, 2002) at 05/15/2002 10:37:58 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBE129DFDC7EFB8f9e8a93df938690918c0ABBE129DFDC7EFB" Subject: [Policy] Re: QDDIM Question Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --0__=0ABBE129DFDC7EFB8f9e8a93df938690918c0ABBE129DFDC7EFB Content-type: multipart/alternative; Boundary="1__=0ABBE129DFDC7EFB8f9e8a93df938690918c0ABBE129DFDC7EFB" --1__=0ABBE129DFDC7EFB8f9e8a93df938690918c0ABBE129DFDC7EFB Content-type: text/plain; charset=US-ASCII Well, you'd think so, wouldn't you? But then you wonder what it means for an instance of QueuingService to surface this one piece of state information to CIM in, say, bytes, while feeding queue-depth information to a RED dropper that has its thresholds specified in packets. Note that QDDIM says on page 15 that the job of modelling state has really not been done, and hence that this CurrentQueueDepth property is something of an anomaly. So maybe it's OK to have a queue that will only tell *us* its current depth in bytes, yet is perfectly willing to tell a dropper its current depth in packets. I see three choices we might make: - Remove the current depth property from QueuingService, and have it wait for the rest of the state model. - Pick a unit for it, either bytes or packets, and define it to always have that as its unit. - Add a units enum as you suggest. I could live with any of these. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" To: "Policy@Ietf. Org" , Robert Moore/Raleigh/IBM@IBMUS Subject: QDDIM Question 05/15/02 10:16 AM Don't you need a DepthUnits enum for QueuingService.CurrentQueueDepth as we have in the REDDropperService for the thresholds? Andrea --1__=0ABBE129DFDC7EFB8f9e8a93df938690918c0ABBE129DFDC7EFB Content-type: text/html; charset=US-ASCII Content-Disposition: inline Well, you'd think so, wouldn't you? But then you wonder
what it means for an instance of QueuingService to
surface this one piece of state information to CIM in,
say, bytes, while feeding queue-depth information to a
RED dropper that has its thresholds specified in packets.
Note that QDDIM says on page 15 that the job of modelling
state has really not been done, and hence that this
CurrentQueueDepth property is something of an anomaly.
So maybe it's OK to have a queue that will only tell *us*
its current depth in bytes, yet is perfectly willing to
tell a dropper its current depth in packets.

I see three choices we might make:

- Remove the current depth property from QueuingService,
and have it wait for the rest of the state model.
- Pick a unit for it, either bytes or packets, and
define it to always have that as its unit.
- Add a units enum as you suggest.

I could live with any of these.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com

"Andrea Westerinen" <andreaw@cisco.com>




          "Andrea Westerinen" <andreaw@cisco.com>

          05/15/02 10:16 AM



To: "Policy@Ietf. Org" <policy@ietf.org>, Robert Moore/Raleigh/IBM@IBMUS
cc:
Subject: QDDIM Question


Don't you need a DepthUnits enum for QueuingService.CurrentQueueDepth as we
have in the REDDropperService for the thresholds?

Andrea


--1__=0ABBE129DFDC7EFB8f9e8a93df938690918c0ABBE129DFDC7EFB-- --0__=0ABBE129DFDC7EFB8f9e8a93df938690918c0ABBE129DFDC7EFB Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=0ABBE129DFDC7EFB8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE129DFDC7EFB8f9e8a93df938690918c0ABBE129DFDC7EFB Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=0ABBE129DFDC7EFB8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE129DFDC7EFB8f9e8a93df938690918c0ABBE129DFDC7EFB-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Fri May 17 15:07:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28199 for ; Fri, 17 May 2002 15:07:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA26067 for policy-archive@odin.ietf.org; Fri, 17 May 2002 15:07:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25134; Fri, 17 May 2002 14:56:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25102 for ; Fri, 17 May 2002 14:56:35 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27546 for ; Fri, 17 May 2002 14:56:18 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4HIu4PI009549; Fri, 17 May 2002 11:56:04 -0700 (PDT) Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ACX60444; Fri, 17 May 2002 11:56:03 -0700 (PDT) From: "Andrea Westerinen" To: "Policy@Ietf. Org" , "Bob Moore" Date: Fri, 17 May 2002 11:56:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [Policy] Another QDDIM issue Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit NextServiceAfterMeter is defined as a subclass of NextService. However, this is not strictly correct since it adds another identifying/key property - MeterResult. For example, both in-profile and partially conforming traffic could go to the same FollowingService. This would require that NextServiceAfterMeter distinguish between instances based on the MeterResult. For this reason, it should subclass from nothing but have similar semantics to NextService. Andrea _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Sat May 18 05:21:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06807 for ; Sat, 18 May 2002 05:21:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA07267 for policy-archive@odin.ietf.org; Sat, 18 May 2002 05:21:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07019; Sat, 18 May 2002 05:10:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06990 for ; Sat, 18 May 2002 05:10:11 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06690 for ; Sat, 18 May 2002 05:09:55 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4I99aPI019374 for ; Sat, 18 May 2002 02:09:36 -0700 (PDT) Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ACX72343; Sat, 18 May 2002 02:09:35 -0700 (PDT) From: "Andrea Westerinen" To: "Policy@Ietf. Org" Date: Sat, 18 May 2002 02:09:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [Policy] Some Scheduling issues in QDDIM Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit 1. According to the definition of the WorkFlexible property in AllocationSchedulingElement, the inherited WorkConserving property should be writeable. 2. The first reference in SchedulingServiceToSchedule shouldn't be Queue, should it? I would think that this is a cut and paste error since it references a packet scheduling service. Andrea _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Wed May 29 10:38:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19512 for ; Wed, 29 May 2002 10:38:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18480 for policy-archive@odin.ietf.org; Wed, 29 May 2002 10:38:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17397; Wed, 29 May 2002 10:28:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02851 for ; Wed, 29 May 2002 07:33:55 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11146; Wed, 29 May 2002 07:33:23 -0400 (EDT) Message-Id: <200205291133.HAA11146@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: policy@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 29 May 2002 07:33:21 -0400 Subject: [Policy] I-D ACTION:draft-ietf-policy-pcim-ext-08.txt Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Policy Framework Working Group of the IETF. Title : Policy Core Information Model Extensions Author(s) : B. Moore Filename : draft-ietf-policy-pcim-ext-08.txt Pages : 87 Date : 28-May-02 This document specifies a number of changes to the Policy Core Information Model (PCIM, RFC 3060). Two types of changes are included. First, several completely new elements are introduced, for example, classes for header filtering, that extend PCIM into areas that it did not previously cover. Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules). Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved. This document updates RFC 3060. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-policy-pcim-ext-08.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-policy-pcim-ext-08.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-policy-pcim-ext-08.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: <20020528130832.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-policy-pcim-ext-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-policy-pcim-ext-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020528130832.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Wed May 29 13:34:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25950 for ; Wed, 29 May 2002 13:34:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01446 for policy-archive@odin.ietf.org; Wed, 29 May 2002 13:35:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01232; Wed, 29 May 2002 13:31:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01198 for ; Wed, 29 May 2002 13:31:48 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25830 for ; Wed, 29 May 2002 13:31:23 -0400 (EDT) From: remoore@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4THViFD116970; Wed, 29 May 2002 13:31:44 -0400 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4THVcr293970; Wed, 29 May 2002 13:31:38 -0400 Subject: Re: [Policy] Some Scheduling issues in QDDIM To: "Andrea Westerinen" Cc: "Policy@Ietf. Org" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 29 May 2002 13:39:35 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build V60_M13_04292002 Pre-release 2|April 29, 2002) at 05/29/2002 13:31:38 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBE15BDFF3718B8f9e8a93df938690918c0ABBE15BDFF3718B" Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --0__=0ABBE15BDFF3718B8f9e8a93df938690918c0ABBE15BDFF3718B Content-type: multipart/alternative; Boundary="1__=0ABBE15BDFF3718B8f9e8a93df938690918c0ABBE15BDFF3718B" --1__=0ABBE15BDFF3718B8f9e8a93df938690918c0ABBE15BDFF3718B Content-type: text/plain; charset=US-ASCII OK, the update to QDDIM will reflect these changes. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" To: "Policy@Ietf. Org" Subject: [Policy] Some Scheduling issues in QDDIM Sent by: policy- admin@ietf.org 05/18/02 05:09 AM 1. According to the definition of the WorkFlexible property in AllocationSchedulingElement, the inherited WorkConserving property should be writeable. 2. The first reference in SchedulingServiceToSchedule shouldn't be Queue, should it? I would think that this is a cut and paste error since it references a packet scheduling service. Andrea _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy --1__=0ABBE15BDFF3718B8f9e8a93df938690918c0ABBE15BDFF3718B Content-type: text/html; charset=US-ASCII Content-Disposition: inline OK, the update to QDDIM will reflect these changes.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com

"Andrea Westerinen" <andreaw@cisco.com>




          "Andrea Westerinen" <andreaw@cisco.com>
          Sent by: policy-admin@ietf.org

          05/18/02 05:09 AM



To: "Policy@Ietf. Org" <policy@ietf.org>
cc:
Subject: [Policy] Some Scheduling issues in QDDIM


1. According to the definition of the WorkFlexible property in
AllocationSchedulingElement, the inherited WorkConserving property should be
writeable.

2. The first reference in SchedulingServiceToSchedule shouldn't be Queue,
should it? I would think that this is a cut and paste error since it
references a packet scheduling service.

Andrea


_______________________________________________
Policy mailing list
Policy@ietf.org
https://www1.ietf.org/mailman/listinfo/policy

--1__=0ABBE15BDFF3718B8f9e8a93df938690918c0ABBE15BDFF3718B-- --0__=0ABBE15BDFF3718B8f9e8a93df938690918c0ABBE15BDFF3718B Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=0ABBE15BDFF3718B8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE15BDFF3718B8f9e8a93df938690918c0ABBE15BDFF3718B Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=0ABBE15BDFF3718B8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15BDFF3718B8f9e8a93df938690918c0ABBE15BDFF3718B-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Wed May 29 13:35:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26004 for ; Wed, 29 May 2002 13:35:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01579 for policy-archive@odin.ietf.org; Wed, 29 May 2002 13:35:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00457; Wed, 29 May 2002 13:28:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00425 for ; Wed, 29 May 2002 13:28:21 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25739 for ; Wed, 29 May 2002 13:27:56 -0400 (EDT) From: remoore@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4THSCFD074646; Wed, 29 May 2002 13:28:12 -0400 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4THSCr179962; Wed, 29 May 2002 13:28:12 -0400 To: "Andrea Westerinen" Cc: "Policy@Ietf. Org" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 29 May 2002 13:36:09 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build V60_M13_04292002 Pre-release 2|April 29, 2002) at 05/29/2002 13:28:12 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBE15BDFCCEFFC8f9e8a93df938690918c0ABBE15BDFCCEFFC" Subject: [Policy] Re: Inconsistencies in QDDIM -07 Draft Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --0__=0ABBE15BDFCCEFFC8f9e8a93df938690918c0ABBE15BDFCCEFFC Content-type: multipart/alternative; Boundary="1__=0ABBE15BDFCCEFFC8f9e8a93df938690918c0ABBE15BDFCCEFFC" --1__=0ABBE15BDFCCEFFC8f9e8a93df938690918c0ABBE15BDFCCEFFC Content-type: text/plain; charset=US-ASCII Hi Andrea, Busy editing QDDIM .... From CR 795: // ================================================================== // CalculationServiceForDropper // ================================================================== [Association, Experimental, Version ("2.7.0"), Description ( "This association is a subclass of ServiceServiceDependency, " "and represents the reliance of a REDDropperService on one or " "more DropThresholdCalculationServices. The latter calculate " "average queue depth, based on the observed depths of a " "queue. The specific queue examined by each CalculationService " "is defined using the CalculationBasedOnQueue association.") ] class CIM_CalculationServiceForDropper : CIM_ServiceServiceDependency { [Override ("Antecedent"), Description ( "A calculation service for the dropper.") ] CIM_DropThresholdCalculationService REF Antecedent; [Override ("Dependent"), Description ( "The RED dropper which is dependent on average queue depth " "calculations by the Antecedent Service.") ] CIM_REDDropperService REF Dependent; }; For the calculation service, the words say "one or more", but the cardinality says 0..n. You also propose 0..n for QDDIM, but I think that the words are correct here - the cardinality should be 1..n, since the only path to get from a RED dropper to a queue for it to examine is via a calculation service instance. Assuming that you'll say "Yes, of course," I've tentatively gone with 1..n in the QDDIM update. You can still talk me out of this is you're quick. Otherwise, I've edited QDDIM as you've proposed in this note. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" To: "Policy@Ietf. Org" , Robert Moore/Raleigh/IBM@IBMUS Subject: Inconsistencies in QDDIM -07 Draft 05/14/02 06:28 PM In reading QDDIM very closely :-), I noticed some inconsistencies in the text in Section 3, in the formal class definitions in Section 4, and in the intent. Here are my observations and recommendations ... 1. For RED droppers, I think that we wanted the following ... A REDDropperService can be related to many DropThresholdCalculationServices (many to many), but each CalculationService examines a single queue (many to one). 2. This means that ... IF you define a DropThresholdCalculationService, you really MUST specify the queue that is examined. So, CalculationBasedOnQueue should have a cardinality of 1..1 on the QueuingService side (currently it has 0..1). AND A REDDropper MAY be associated with one or more CalculationServices (each looking at a specific queue). So, CalculationServiceForDropper should have a cardinality of 0..n on the DropThresholdCalculationService side (currently it is a mandatory 1). 3. For a HeadTailDropperService, its determinations can also be based on several queues (as discussed at the bottom of page 23). So, HeadTailDropQueueBinding should have a cardinality of 1..n for the QueuingService (currently, it has mandatory 1). I agree that at least queue is mandatory - but more than one can be examined. Andrea --1__=0ABBE15BDFCCEFFC8f9e8a93df938690918c0ABBE15BDFCCEFFC Content-type: text/html; charset=US-ASCII Content-Disposition: inline Hi Andrea,

Busy editing QDDIM ....

From CR 795:

// ==================================================================
// CalculationServiceForDropper
// ==================================================================
[Association, Experimental, Version ("2.7.0"),
Description (
"This association is a subclass of ServiceServiceDependency, "
"and represents the reliance of a REDDropperService on one or "
"more DropThresholdCalculationServices. The latter calculate "
"average queue depth, based on the observed depths of a "
"queue. The specific queue examined by each CalculationService "
"is defined using the CalculationBasedOnQueue association.") ]
class CIM_CalculationServiceForDropper : CIM_ServiceServiceDependency {
[Override ("Antecedent"), Description (
"A calculation service for the dropper.") ]
CIM_DropThresholdCalculationService REF Antecedent;
[Override ("Dependent"), Description (
"The RED dropper which is dependent on average queue depth "
"calculations by the Antecedent Service.") ]
CIM_REDDropperService REF Dependent;
};

For the calculation service, the words say "one or more", but the cardinality says 0..n. You also propose 0..n for QDDIM, but I think that the words are correct here - the cardinality should be 1..n, since the only path to get from a RED dropper to a queue for it to examine is via a calculation service instance.

Assuming that you'll say "Yes, of course," I've tentatively gone with 1..n in the QDDIM update. You can still talk me out of this is you're quick.

Otherwise, I've edited QDDIM as you've proposed in this note.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com

"Andrea Westerinen" <andreaw@cisco.com>




          "Andrea Westerinen" <andreaw@cisco.com>

          05/14/02 06:28 PM



To: "Policy@Ietf. Org" <policy@ietf.org>, Robert Moore/Raleigh/IBM@IBMUS
cc:
Subject: Inconsistencies in QDDIM -07 Draft


In reading QDDIM very closely :-), I noticed some inconsistencies in the text in Section 3, in the formal class definitions in Section 4, and in the intent. Here are my observations and recommendations ...

1. For RED droppers, I think that we wanted the following ...
A REDDropperService can be related to many DropThresholdCalculationServices (many to many), but each CalculationService examines a single queue (many to one).

2. This means that ...
IF you define a DropThresholdCalculationService, you really MUST specify the queue that is examined. So, CalculationBasedOnQueue should have a cardinality of 1..1 on the QueuingService side (currently it has 0..1).
AND
A REDDropper MAY be associated with one or more CalculationServices (each looking at a specific queue). So, CalculationServiceForDropper should have a cardinality of 0..n on the DropThresholdCalculationService side (currently it is a mandatory 1).

3. For a HeadTailDropperService, its determinations can also be based on several queues (as discussed at the bottom of page 23). So, HeadTailDropQueueBinding should have a cardinality of 1..n for the QueuingService (currently, it has mandatory 1). I agree that at least queue is mandatory - but more than one can be examined.

Andrea



--1__=0ABBE15BDFCCEFFC8f9e8a93df938690918c0ABBE15BDFCCEFFC-- --0__=0ABBE15BDFCCEFFC8f9e8a93df938690918c0ABBE15BDFCCEFFC Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=0ABBE15BDFCCEFFC8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE15BDFCCEFFC8f9e8a93df938690918c0ABBE15BDFCCEFFC Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=0ABBE15BDFCCEFFC8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15BDFCCEFFC8f9e8a93df938690918c0ABBE15BDFCCEFFC-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Wed May 29 13:36:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26065 for ; Wed, 29 May 2002 13:36:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01663 for policy-archive@odin.ietf.org; Wed, 29 May 2002 13:36:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00818; Wed, 29 May 2002 13:30:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00761 for ; Wed, 29 May 2002 13:30:31 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25776; Wed, 29 May 2002 13:30:06 -0400 (EDT) From: remoore@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4THUSFD028324; Wed, 29 May 2002 13:30:28 -0400 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4THURr242196; Wed, 29 May 2002 13:30:27 -0400 Subject: Re: [Policy] Another QDDIM issue To: "Andrea Westerinen" Cc: "Policy@Ietf. Org" , policy-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 29 May 2002 13:38:24 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build V60_M13_04292002 Pre-release 2|April 29, 2002) at 05/29/2002 13:30:27 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBE15BDFF358408f9e8a93df938690918c0ABBE15BDFF35840" Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --0__=0ABBE15BDFF358408f9e8a93df938690918c0ABBE15BDFF35840 Content-type: multipart/alternative; Boundary="1__=0ABBE15BDFF358408f9e8a93df938690918c0ABBE15BDFF35840" --1__=0ABBE15BDFF358408f9e8a93df938690918c0ABBE15BDFF35840 Content-type: text/plain; charset=US-ASCII OK, the update to QDDIM will reflect this change. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" To: "Policy@Ietf. Org" , Robert Moore/Raleigh/IBM@IBMUS Subject: [Policy] Another QDDIM issue Sent by: policy- admin@ietf.org 05/17/02 02:56 PM NextServiceAfterMeter is defined as a subclass of NextService. However, this is not strictly correct since it adds another identifying/key property - MeterResult. For example, both in-profile and partially conforming traffic could go to the same FollowingService. This would require that NextServiceAfterMeter distinguish between instances based on the MeterResult. For this reason, it should subclass from nothing but have similar semantics to NextService. Andrea _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy --1__=0ABBE15BDFF358408f9e8a93df938690918c0ABBE15BDFF35840 Content-type: text/html; charset=US-ASCII Content-Disposition: inline OK, the update to QDDIM will reflect this change.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com

"Andrea Westerinen" <andreaw@cisco.com>




          "Andrea Westerinen" <andreaw@cisco.com>
          Sent by: policy-admin@ietf.org

          05/17/02 02:56 PM



To: "Policy@Ietf. Org" <policy@ietf.org>, Robert Moore/Raleigh/IBM@IBMUS
cc:
Subject: [Policy] Another QDDIM issue


NextServiceAfterMeter is defined as a subclass of NextService. However,
this is not strictly correct since it adds another identifying/key
property - MeterResult. For example, both in-profile and partially
conforming traffic could go to the same FollowingService. This would
require that NextServiceAfterMeter distinguish between instances based on
the MeterResult.

For this reason, it should subclass from nothing but have similar semantics
to NextService.

Andrea


_______________________________________________
Policy mailing list
Policy@ietf.org
https://www1.ietf.org/mailman/listinfo/policy

--1__=0ABBE15BDFF358408f9e8a93df938690918c0ABBE15BDFF35840-- --0__=0ABBE15BDFF358408f9e8a93df938690918c0ABBE15BDFF35840 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=0ABBE15BDFF358408f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE15BDFF358408f9e8a93df938690918c0ABBE15BDFF35840 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=0ABBE15BDFF358408f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15BDFF358408f9e8a93df938690918c0ABBE15BDFF35840-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Wed May 29 13:40:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26330 for ; Wed, 29 May 2002 13:40:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02089 for policy-archive@odin.ietf.org; Wed, 29 May 2002 13:41:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01533; Wed, 29 May 2002 13:35:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01460 for ; Wed, 29 May 2002 13:35:16 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25966 for ; Wed, 29 May 2002 13:34:46 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4THYSuF023451; Wed, 29 May 2002 10:34:28 -0700 (PDT) Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ACZ70891; Wed, 29 May 2002 10:34:39 -0700 (PDT) From: "Andrea Westerinen" To: Cc: "Policy@Ietf. Org" Date: Wed, 29 May 2002 10:34:39 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_005F_01C206FC.6FB2A8A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: [Policy] RE: Inconsistencies in QDDIM -07 Draft Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_005F_01C206FC.6FB2A8A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0060_01C206FC.6FB2A8A0" ------=_NextPart_001_0060_01C206FC.6FB2A8A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bob, I think that the operative words in my email are "IF you define a CalculationService, then ..." Since CalculationService is a new concept and may not be visibly instrumented, I did not want to make it mandatory. Hence, the 0..n on the CalculationService, as related to a REDDropper. I think that the "one or more" wording in the Description is a cut and paste error. Andrea -----Original Message----- From: remoore@us.ibm.com [mailto:remoore@us.ibm.com] Sent: Wednesday, May 29, 2002 10:36 AM To: Andrea Westerinen Cc: Policy@Ietf. Org Subject: Re: Inconsistencies in QDDIM -07 Draft Hi Andrea, Busy editing QDDIM .... From CR 795: // ================================================================== // CalculationServiceForDropper // ================================================================== [Association, Experimental, Version ("2.7.0"), Description ( "This association is a subclass of ServiceServiceDependency, " "and represents the reliance of a REDDropperService on one or " "more DropThresholdCalculationServices. The latter calculate " "average queue depth, based on the observed depths of a " "queue. The specific queue examined by each CalculationService " "is defined using the CalculationBasedOnQueue association.") ] class CIM_CalculationServiceForDropper : CIM_ServiceServiceDependency { [Override ("Antecedent"), Description ( "A calculation service for the dropper.") ] CIM_DropThresholdCalculationService REF Antecedent; [Override ("Dependent"), Description ( "The RED dropper which is dependent on average queue depth " "calculations by the Antecedent Service.") ] CIM_REDDropperService REF Dependent; }; For the calculation service, the words say "one or more", but the cardinality says 0..n. You also propose 0..n for QDDIM, but I think that the words are correct here - the cardinality should be 1..n, since the only path to get from a RED dropper to a queue for it to examine is via a calculation service instance. Assuming that you'll say "Yes, of course," I've tentatively gone with 1..n in the QDDIM update. You can still talk me out of this is you're quick. Otherwise, I've edited QDDIM as you've proposed in this note. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" "Andrea Westerinen" 05/14/02 06:28 PM To: "Policy@Ietf. Org" , Robert Moore/Raleigh/IBM@IBMUS cc: Subject: Inconsistencies in QDDIM -07 Draft In reading QDDIM very closely :-), I noticed some inconsistencies in the text in Section 3, in the formal class definitions in Section 4, and in the intent. Here are my observations and recommendations ... 1. For RED droppers, I think that we wanted the following ... A REDDropperService can be related to many DropThresholdCalculationServices (many to many), but each CalculationService examines a single queue (many to one). 2. This means that ... IF you define a DropThresholdCalculationService, you really MUST specify the queue that is examined. So, CalculationBasedOnQueue should have a cardinality of 1..1 on the QueuingService side (currently it has 0..1). AND A REDDropper MAY be associated with one or more CalculationServices (each looking at a specific queue). So, CalculationServiceForDropper should have a cardinality of 0..n on the DropThresholdCalculationService side (currently it is a mandatory 1). 3. For a HeadTailDropperService, its determinations can also be based on several queues (as discussed at the bottom of page 23). So, HeadTailDropQueueBinding should have a cardinality of 1..n for the QueuingService (currently, it has mandatory 1). I agree that at least queue is mandatory - but more than one can be examined. Andrea ------=_NextPart_001_0060_01C206FC.6FB2A8A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bob, I=20 think that the operative words in my email are "IF you define a=20 CalculationService, then ..."  Since CalculationService is a new = concept=20 and may not be visibly instrumented, I did not want to make=20 it mandatory.  Hence, the 0..n on = the CalculationService, as=20 related to a REDDropper.  I think that the "one or more" wording in = the=20 Description is a cut and paste error.
 
Andrea 
-----Original Message-----
From: remoore@us.ibm.com = [mailto:remoore@us.ibm.com]
Sent: Wednesday, May 29, 2002 = 10:36=20 AM
To: Andrea Westerinen
Cc: Policy@Ietf.=20 Org
Subject: Re: Inconsistencies in QDDIM -07=20 Draft

Hi Andrea,

Busy editing QDDIM=20 ....

From CR 795:

//=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
//=20 CalculationServiceForDropper
//=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
[Association,=20 Experimental, Version ("2.7.0"),
Description (
"This = association is a=20 subclass of ServiceServiceDependency, "
"and represents the = reliance of a=20 REDDropperService on one or "
"more = DropThresholdCalculationServices. The=20 latter calculate "
"average queue depth, based on the observed = depths of a=20 "
"queue. The specific queue examined by each CalculationService = "
"is=20 defined using the CalculationBasedOnQueue association.") ]
class=20 CIM_CalculationServiceForDropper : CIM_ServiceServiceDependency = {
[Override=20 ("Antecedent"), Description (
"A calculation service for the = dropper.")=20 ]
CIM_DropThresholdCalculationService REF Antecedent;
[Override=20 ("Dependent"), Description (
"The RED dropper which is dependent on = average=20 queue depth "
"calculations by the Antecedent Service.")=20 ]
CIM_REDDropperService REF Dependent;
};

For the = calculation=20 service, the words say "one or more", but the cardinality says 0..n. = You also=20 propose 0..n for QDDIM, but I think that the words are correct here - = the=20 cardinality should be 1..n, since the only path to get from a RED = dropper to a=20 queue for it to examine is via a calculation service = instance.

Assuming=20 that you'll say "Yes, of course," I've tentatively gone with 1..n in = the QDDIM=20 update. You can still talk me out of this is you're = quick.

Otherwise,=20 I've edited QDDIM as you've proposed in this=20 note.

Regards,
Bob

Bob Moore
Advanced Design and=20 Technology
Application Integration Middleware Division
IBM = Software=20 Group
+1-919-254-4436
remoore@us.ibm.com

3D"""Andrea Westerinen"=20 <andreaw@cisco.com>


3D""
          "Andrea Westerinen"=20 <andreaw@cisco.com>=20

          05/14/02 06:28 = PM

3D""
 3D""

To: "Policy@Ietf.=20 Org" <policy@ietf.org>, Robert=20 Moore/Raleigh/IBM@IBMUS
cc: =
Subject: Inconsistencies in QDDIM = -07=20 Draft


In=20 reading QDDIM very closely :-), I noticed some inconsistencies in the = text in=20 Section 3, in the formal class definitions in Section 4, and in the = intent.=20 Here are my observations and recommendations ...

1. For=20 RED droppers, I think that we wanted the following ...
A REDDropperService can be related to = many=20 DropThresholdCalculationServices (many to many), but each = CalculationService=20 examines a single queue (many to one).

2. This means = that ...=20
IF you define a=20 DropThresholdCalculationService, you really MUST specify the queue = that is=20 examined. So, CalculationBasedOnQueue should have a cardinality of = 1..1 on the=20 QueuingService side (currently it has 0..1).
AND
A = REDDropper MAY be=20 associated with one or more CalculationServices (each looking at a = specific=20 queue). So, CalculationServiceForDropper should have a cardinality of = 0..n on=20 the DropThresholdCalculationService side (currently it is a mandatory = 1).=20

3. For a HeadTailDropperService, its determinations can = also be=20 based on several queues (as discussed at the bottom of page 23). So,=20 HeadTailDropQueueBinding should have a cardinality of 1..n for the=20 QueuingService (currently, it has mandatory 1). I agree that at least = queue is=20 mandatory - but more than one can be examined.

Andrea=20



------=_NextPart_001_0060_01C206FC.6FB2A8A0-- ------=_NextPart_000_005F_01C206FC.6FB2A8A0 Content-Type: image/gif; name="graycol.gif" Content-Transfer-Encoding: base64 Content-ID: <634043217@29052002-235e> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_005F_01C206FC.6FB2A8A0 Content-Type: image/gif; name="ecblank.gif" Content-Transfer-Encoding: base64 Content-ID: <634043217@29052002-2365> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_005F_01C206FC.6FB2A8A0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Wed May 29 13:57:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26960 for ; Wed, 29 May 2002 13:57:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03642 for policy-archive@odin.ietf.org; Wed, 29 May 2002 13:58:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03281; Wed, 29 May 2002 13:53:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03253 for ; Wed, 29 May 2002 13:53:46 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26771 for ; Wed, 29 May 2002 13:53:21 -0400 (EDT) From: remoore@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4THrZFD136450; Wed, 29 May 2002 13:53:35 -0400 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4THrYr196788; Wed, 29 May 2002 13:53:34 -0400 To: "Andrea Westerinen" Cc: "Policy@Ietf. Org" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 29 May 2002 14:01:31 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build V60_M13_04292002 Pre-release 2|April 29, 2002) at 05/29/2002 13:53:34 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBE15BDFF15D7A8f9e8a93df938690918c0ABBE15BDFF15D7A" Subject: [Policy] RE: Inconsistencies in QDDIM -07 Draft Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --0__=0ABBE15BDFF15D7A8f9e8a93df938690918c0ABBE15BDFF15D7A Content-type: multipart/alternative; Boundary="1__=0ABBE15BDFF15D7A8f9e8a93df938690918c0ABBE15BDFF15D7A" --1__=0ABBE15BDFF15D7A8f9e8a93df938690918c0ABBE15BDFF15D7A Content-type: text/plain; charset=US-ASCII OK, but then how does a RED dropper get to a queue to watch if it doesn't go via a CalculationService? I didn't think we were using NextService for this. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" To: Robert Moore/Raleigh/IBM@IBMUS com> Subject: RE: Inconsistencies in QDDIM -07 Draft 05/29/02 01:34 PM Bob, I think that the operative words in my email are "IF you define a CalculationService, then ..." Since CalculationService is a new concept and may not be visibly instrumented, I did not want to make it mandatory. Hence, the 0..n on the CalculationService, as related to a REDDropper. I think that the "one or more" wording in the Description is a cut and paste error. Andrea -----Original Message----- From: remoore@us.ibm.com [mailto:remoore@us.ibm.com] Sent: Wednesday, May 29, 2002 10:36 AM To: Andrea Westerinen Cc: Policy@Ietf. Org Subject: Re: Inconsistencies in QDDIM -07 Draft Hi Andrea, Busy editing QDDIM .... From CR 795: // ================================================================== // CalculationServiceForDropper // ================================================================== [Association, Experimental, Version ("2.7.0"), Description ( "This association is a subclass of ServiceServiceDependency, " "and represents the reliance of a REDDropperService on one or " "more DropThresholdCalculationServices. The latter calculate " "average queue depth, based on the observed depths of a " "queue. The specific queue examined by each CalculationService " "is defined using the CalculationBasedOnQueue association.") ] class CIM_CalculationServiceForDropper : CIM_ServiceServiceDependency { [Override ("Antecedent"), Description ( "A calculation service for the dropper.") ] CIM_DropThresholdCalculationService REF Antecedent; [Override ("Dependent"), Description ( "The RED dropper which is dependent on average queue depth " "calculations by the Antecedent Service.") ] CIM_REDDropperService REF Dependent; }; For the calculation service, the words say "one or more", but the cardinality says 0..n. You also propose 0..n for QDDIM, but I think that the words are correct here - the cardinality should be 1..n, since the only path to get from a RED dropper to a queue for it to examine is via a calculation service instance. Assuming that you'll say "Yes, of course," I've tentatively gone with 1..n in the QDDIM update. You can still talk me out of this is you're quick. Otherwise, I've edited QDDIM as you've proposed in this note. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" "Andrea Westerinen To: "Policy@Ietf. Org" " , Robert cc: Subject: Inconsistencies in QDDIM -07 Draft 05/14/02 06:28 PM In reading QDDIM very closely :-), I noticed some inconsistencies in the text in Section 3, in the formal class definitions in Section 4, and in the intent. Here are my observations and recommendations ... 1. For RED droppers, I think that we wanted the following ... A REDDropperService can be related to many DropThresholdCalculationServices (many to many), but each CalculationService examines a single queue (many to one). 2. This means that ... IF you define a DropThresholdCalculationService, you really MUST specify the queue that is examined. So, CalculationBasedOnQueue should have a cardinality of 1..1 on the QueuingService side (currently it has 0..1). AND A REDDropper MAY be associated with one or more CalculationServices (each looking at a specific queue). So, CalculationServiceForDropper should have a cardinality of 0..n on the DropThresholdCalculationService side (currently it is a mandatory 1). 3. For a HeadTailDropperService, its determinations can also be based on several queues (as discussed at the bottom of page 23). So, HeadTailDropQueueBinding should have a cardinality of 1..n for the QueuingService (currently, it has mandatory 1). I agree that at least queue is mandatory - but more than one can be examined. Andrea --1__=0ABBE15BDFF15D7A8f9e8a93df938690918c0ABBE15BDFF15D7A Content-type: text/html; charset=US-ASCII Content-Disposition: inline OK, but then how does a RED dropper get to a queue to watch if it doesn't go via a CalculationService? I didn't think we were using NextService for this.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com

"Andrea Westerinen" <andreaw@cisco.com>




          "Andrea Westerinen" <andreaw@cisco.com>

          05/29/02 01:34 PM



To: Robert Moore/Raleigh/IBM@IBMUS
cc: "Policy@Ietf. Org" <policy@ietf.org>
Subject: RE: Inconsistencies in QDDIM -07 Draft


Bob, I think that the operative words in my email are "IF you define a CalculationService, then ..." Since CalculationService is a new concept and may not be visibly instrumented, I did not want to make it mandatory. Hence, the 0..n on the CalculationService, as related to a REDDropper. I think that the "one or more" wording in the Description is a cut and paste error.

Andrea
      -----Original Message-----
      From:       remoore@us.ibm.com [mailto:remoore@us.ibm.com]
      Sent:       Wednesday, May 29, 2002 10:36 AM
      To:       Andrea Westerinen
      Cc:       Policy@Ietf. Org
      Subject:       Re: Inconsistencies in QDDIM -07 Draft

      Hi Andrea,

      Busy editing QDDIM ....

      From CR 795:

      // ==================================================================
      // CalculationServiceForDropper
      // ==================================================================
      [Association, Experimental, Version ("2.7.0"),
      Description (
      "This association is a subclass of ServiceServiceDependency, "
      "and represents the reliance of a REDDropperService on one or "
      "more DropThresholdCalculationServices. The latter calculate "
      "average queue depth, based on the observed depths of a "
      "queue. The specific queue examined by each CalculationService "
      "is defined using the CalculationBasedOnQueue association.") ]
      class CIM_CalculationServiceForDropper : CIM_ServiceServiceDependency {
      [Override ("Antecedent"), Description (
      "A calculation service for the dropper.") ]
      CIM_DropThresholdCalculationService REF Antecedent;
      [Override ("Dependent"), Description (
      "The RED dropper which is dependent on average queue depth "
      "calculations by the Antecedent Service.") ]
      CIM_REDDropperService REF Dependent;
      };

      For the calculation service, the words say "one or more", but the cardinality says 0..n. You also propose 0..n for QDDIM, but I think that the words are correct here - the cardinality should be 1..n, since the only path to get from a RED dropper to a queue for it to examine is via a calculation service instance.

      Assuming that you'll say "Yes, of course," I've tentatively gone with 1..n in the QDDIM update. You can still talk me out of this is you're quick.

      Otherwise, I've edited QDDIM as you've proposed in this note.

      Regards,
      Bob

      Bob Moore
      Advanced Design and Technology
      Application Integration Middleware Division
      IBM Software Group
      +1-919-254-4436
      remoore@us.ibm.com

      "Andrea Westerinen" <andreaw@cisco.com>
                      "Andrea Westerinen" <andreaw@cisco.com>

                      05/14/02 06:28 PM



      To: "Policy@Ietf. Org" <policy@ietf.org>, Robert Moore/Raleigh/IBM@IBMUS
      cc:
      Subject: Inconsistencies in QDDIM -07 Draft

      In reading QDDIM very closely :-), I noticed some inconsistencies in the text in Section 3, in the formal class definitions in Section 4, and in the intent. Here are my observations and recommendations ...

      1. For RED droppers, I think that we wanted the following ...
      A REDDropperService can be related to many DropThresholdCalculationServices (many to many), but each CalculationService examines a single queue (many to one).

      2. This means that ...
      IF you define a DropThresholdCalculationService, you really MUST specify the queue that is examined. So, CalculationBasedOnQueue should have a cardinality of 1..1 on the QueuingService side (currently it has 0..1).
      AND
      A REDDropper MAY be associated with one or more CalculationServices (each looking at a specific queue). So, CalculationServiceForDropper should have a cardinality of 0..n on the DropThresholdCalculationService side (currently it is a mandatory 1).

      3. For a HeadTailDropperService, its determinations can also be based on several queues (as discussed at the bottom of page 23). So, HeadTailDropQueueBinding should have a cardinality of 1..n for the QueuingService (currently, it has mandatory 1). I agree that at least queue is mandatory - but more than one can be examined.

      Andrea



--1__=0ABBE15BDFF15D7A8f9e8a93df938690918c0ABBE15BDFF15D7A-- --0__=0ABBE15BDFF15D7A8f9e8a93df938690918c0ABBE15BDFF15D7A Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=0ABBE15BDFF15D7A8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE15BDFF15D7A8f9e8a93df938690918c0ABBE15BDFF15D7A Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=0ABBE15BDFF15D7A8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15BDFF15D7A8f9e8a93df938690918c0ABBE15BDFF15D7A Content-type: image/gif; name="C4404673.gif" Content-Disposition: inline; filename="C4404673.gif" Content-ID: <40__=0ABBE15BDFF15D7A8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE15BDFF15D7A8f9e8a93df938690918c0ABBE15BDFF15D7A Content-type: image/gif; name="C4929592.gif" Content-Disposition: inline; filename="C4929592.gif" Content-ID: <50__=0ABBE15BDFF15D7A8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15BDFF15D7A8f9e8a93df938690918c0ABBE15BDFF15D7A Content-type: image/gif; name="C2638232.gif" Content-Disposition: inline; filename="C2638232.gif" Content-ID: <60__=0ABBE15BDFF15D7A8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15BDFF15D7A8f9e8a93df938690918c0ABBE15BDFF15D7A Content-type: image/gif; name="C3486867.gif" Content-Disposition: inline; filename="C3486867.gif" Content-ID: <70__=0ABBE15BDFF15D7A8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15BDFF15D7A8f9e8a93df938690918c0ABBE15BDFF15D7A-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Wed May 29 14:32:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28056 for ; Wed, 29 May 2002 14:32:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06728 for policy-archive@odin.ietf.org; Wed, 29 May 2002 14:33:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05467; Wed, 29 May 2002 14:18:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05394 for ; Wed, 29 May 2002 14:18:07 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27563 for ; Wed, 29 May 2002 14:17:41 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4TIHaPI013554; Wed, 29 May 2002 11:17:36 -0700 (PDT) Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ACZ72144; Wed, 29 May 2002 11:17:32 -0700 (PDT) From: "Andrea Westerinen" To: Cc: "Policy@Ietf. Org" Subject: RE: [Policy] RE: Inconsistencies in QDDIM -07 Draft Date: Wed, 29 May 2002 11:17:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0075_01C20702.6D598EB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0075_01C20702.6D598EB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0076_01C20702.6D598EB0" ------=_NextPart_001_0076_01C20702.6D598EB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In the original incarnations of QDDIM, we had NextService only, for a REDDropper. The problem was that the Dropper did not have to base its calculations only on the queue from which it dropped. So, CalculationService was defined to describe the calculations separate from the queue to drop. We did not mandate the existence of the calculation definitions before, so I did not want to do that now. However, I am not religious about this one - mandating the association (based on cardinality) does force specificity. Do others have an opinion on this? Andrea -----Original Message----- From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of remoore@us.ibm.com Sent: Wednesday, May 29, 2002 11:02 AM To: Andrea Westerinen Cc: Policy@Ietf. Org Subject: [Policy] RE: Inconsistencies in QDDIM -07 Draft OK, but then how does a RED dropper get to a queue to watch if it doesn't go via a CalculationService? I didn't think we were using NextService for this. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" "Andrea Westerinen" 05/29/02 01:34 PM To: Robert Moore/Raleigh/IBM@IBMUS cc: "Policy@Ietf. Org" Subject: RE: Inconsistencies in QDDIM -07 Draft Bob, I think that the operative words in my email are "IF you define a CalculationService, then ..." Since CalculationService is a new concept and may not be visibly instrumented, I did not want to make it mandatory. Hence, the 0..n on the CalculationService, as related to a REDDropper. I think that the "one or more" wording in the Description is a cut and paste error. Andrea -----Original Message----- From: remoore@us.ibm.com [mailto:remoore@us.ibm.com] Sent: Wednesday, May 29, 2002 10:36 AM To: Andrea Westerinen Cc: Policy@Ietf. Org Subject: Re: Inconsistencies in QDDIM -07 Draft Hi Andrea, Busy editing QDDIM .... From CR 795: // ================================================================== // CalculationServiceForDropper // ================================================================== [Association, Experimental, Version ("2.7.0"), Description ( "This association is a subclass of ServiceServiceDependency, " "and represents the reliance of a REDDropperService on one or " "more DropThresholdCalculationServices. The latter calculate " "average queue depth, based on the observed depths of a " "queue. The specific queue examined by each CalculationService " "is defined using the CalculationBasedOnQueue association.") ] class CIM_CalculationServiceForDropper : CIM_ServiceServiceDependency { [Override ("Antecedent"), Description ( "A calculation service for the dropper.") ] CIM_DropThresholdCalculationService REF Antecedent; [Override ("Dependent"), Description ( "The RED dropper which is dependent on average queue depth " "calculations by the Antecedent Service.") ] CIM_REDDropperService REF Dependent; }; For the calculation service, the words say "one or more", but the cardinality says 0..n. You also propose 0..n for QDDIM, but I think that the words are correct here - the cardinality should be 1..n, since the only path to get from a RED dropper to a queue for it to examine is via a calculation service instance. Assuming that you'll say "Yes, of course," I've tentatively gone with 1..n in the QDDIM update. You can still talk me out of this is you're quick. Otherwise, I've edited QDDIM as you've proposed in this note. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" "Andrea Westerinen" 05/14/02 06:28 PM To: "Policy@Ietf. Org" , Robert Moore/Raleigh/IBM@IBMUS cc: Subject: Inconsistencies in QDDIM -07 Draft In reading QDDIM very closely :-), I noticed some inconsistencies in the text in Section 3, in the formal class definitions in Section 4, and in the intent. Here are my observations and recommendations ... 1. For RED droppers, I think that we wanted the following ... A REDDropperService can be related to many DropThresholdCalculationServices (many to many), but each CalculationService examines a single queue (many to one). 2. This means that ... IF you define a DropThresholdCalculationService, you really MUST specify the queue that is examined. So, CalculationBasedOnQueue should have a cardinality of 1..1 on the QueuingService side (currently it has 0..1). AND A REDDropper MAY be associated with one or more CalculationServices (each looking at a specific queue). So, CalculationServiceForDropper should have a cardinality of 0..n on the DropThresholdCalculationService side (currently it is a mandatory 1). 3. For a HeadTailDropperService, its determinations can also be based on several queues (as discussed at the bottom of page 23). So, HeadTailDropQueueBinding should have a cardinality of 1..n for the QueuingService (currently, it has mandatory 1). I agree that at least queue is mandatory - but more than one can be examined. Andrea ------=_NextPart_001_0076_01C20702.6D598EB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In the=20 original incarnations of QDDIM, we had NextService only, for a=20 REDDropper.  The problem was that the Dropper did not = have to base=20 its calculations only on the queue from which it dropped.  So,=20 CalculationService was defined to describe the calculations separate = from the=20 queue to drop.  We did not mandate the existence of the=20 calculation definitions before, so I did not want to do that now.  = However,=20 I am not religious about this one - mandating the association (based on=20 cardinality) does force specificity.  
 
Do=20 others have an opinion on this?
Andrea
-----Original Message-----
From: = policy-admin@ietf.org=20 [mailto:policy-admin@ietf.org]On Behalf Of=20 remoore@us.ibm.com
Sent: Wednesday, May 29, 2002 11:02=20 AM
To: Andrea Westerinen
Cc: Policy@Ietf.=20 Org
Subject: [Policy] RE: Inconsistencies in QDDIM -07=20 Draft

OK, but then how does a RED dropper get to a = queue=20 to watch if it doesn't go via a CalculationService? I didn't think we = were=20 using NextService for this.

Regards,
Bob

Bob=20 Moore
Advanced Design and Technology
Application Integration = Middleware=20 Division
IBM Software=20 Group
+1-919-254-4436
remoore@us.ibm.com

3D"""Andrea Westerinen"=20 <andreaw@cisco.com>


3D""
          "Andrea Westerinen"=20 <andreaw@cisco.com>=20

          05/29/02 01:34 = PM

3D""
 3D""

To: Robert=20 Moore/Raleigh/IBM@IBMUS
cc: = "Policy@Ietf. Org" = <policy@ietf.org>
Subject: RE: Inconsistencies in = QDDIM -07=20 Draft


Bob, I think that the operative words in my email are "IF = you=20 define a CalculationService, then ..." Since CalculationService is a = new=20 concept and may not be visibly instrumented, I did not want to make it = mandatory. Hence, the 0..n on the CalculationService, as related to a=20 REDDropper. I think that the "one or more" wording in the Description = is a cut=20 and paste error.

Andrea
      -----Original Message-----
      From:       = remoore@us.ibm.com [mailto:remoore@us.ibm.com]<= B>
      Sent: Wednesday, = May 29, 2002=20 10:36 AM
      To:      =20 Andrea Westerinen
      Cc:       Policy@Ietf. Org
      Subject:       Re: = Inconsistencies=20 in QDDIM -07 Draft

      Hi=20 Andrea,

      Busy editing QDDIM ....

      From CR = 795:

      //=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      //=20 CalculationServiceForDropper
      //=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
      [Association,=20 Experimental, Version ("2.7.0"),
      Description (
      "This = association is=20 a subclass of ServiceServiceDependency, "
      "and represents the = reliance=20 of a REDDropperService on one or "
      "more=20 DropThresholdCalculationServices. The latter calculate = "
      "average queue=20 depth, based on the observed depths of a "
      "queue. The specific = queue=20 examined by each CalculationService "
      "is defined using the=20 CalculationBasedOnQueue association.") ]
      class=20 CIM_CalculationServiceForDropper : CIM_ServiceServiceDependency=20 {
      [Override ("Antecedent"), Description (
      "A calculation = service for=20 the dropper.") ]
      CIM_DropThresholdCalculationService REF=20 Antecedent;
      [Override ("Dependent"), Description (
      "The RED = dropper=20 which is dependent on average queue depth "
      "calculations by = the=20 Antecedent Service.") ]
      CIM_REDDropperService REF=20 Dependent;
      };

      For the calculation service, the words say = "one or=20 more", but the cardinality says 0..n. You also propose 0..n for = QDDIM, but=20 I think that the words are correct here - the cardinality should = be 1..n,=20 since the only path to get from a RED dropper to a queue for it to = examine=20 is via a calculation service instance.

      Assuming that you'll = say=20 "Yes, of course," I've tentatively gone with 1..n in the QDDIM = update. You=20 can still talk me out of this is you're quick.

      Otherwise, = I've=20 edited QDDIM as you've proposed in this=20 note.

      Regards,
      Bob

      Bob Moore
      Advanced Design and=20 Technology
      Application Integration Middleware Division
      IBM = Software=20 Group
      +1-919-254-4436
      remoore@us.ibm.com

      3D""=20"Andrea Westerinen"=20 <andreaw@cisco.com>

      3D"" 3D""=20
                      "Andrea=20 Westerinen"=20 <andreaw@cisco.com>

                      05/14/02 = 06:28=20 = PM

      		 3D""

      To: "Policy@Ietf. Org"=20 <policy@ietf.org>, Robert = Moore/Raleigh/IBM@IBMUS
      cc:=20
      Subject: Inconsistencies in QDDIM -07 Draft

      In reading QDDIM very = closely :-), I=20 noticed some inconsistencies in the text in Section 3, in the = formal class=20 definitions in Section 4, and in the intent. Here are my = observations and=20 recommendations ...

      1. For RED=20 droppers, I think that we wanted the following ...
      A = REDDropperService=20 can be related to many DropThresholdCalculationServices (many to = many),=20 but each CalculationService examines a single queue (many to=20 one).

      2. This means that ... =
      IF you=20 define a DropThresholdCalculationService, you really MUST specify = the=20 queue that is examined. So, CalculationBasedOnQueue should have a=20 cardinality of 1..1 on the QueuingService side (currently it has = 0..1).=20
      AND
      A REDDropper MAY be associated with one or more=20 CalculationServices (each looking at a specific queue). So,=20 CalculationServiceForDropper should have a cardinality of 0..n on = the=20 DropThresholdCalculationService side (currently it is a mandatory = 1).=20

      3. For a HeadTailDropperService, its = determinations=20 can also be based on several queues (as discussed at the bottom of = page=20 23). So, HeadTailDropQueueBinding should have a cardinality of = 1..n for=20 the QueuingService (currently, it has mandatory 1). I agree that = at least=20 queue is mandatory - but more than one can be = examined.

      Andrea



------=_NextPart_001_0076_01C20702.6D598EB0-- ------=_NextPart_000_0075_01C20702.6D598EB0 Content-Type: image/gif; name="graycol.gif" Content-Transfer-Encoding: base64 Content-ID: <226110718@29052002-237a> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_0075_01C20702.6D598EB0 Content-Type: image/gif; name="ecblank.gif" Content-Transfer-Encoding: base64 Content-ID: <226110718@29052002-2381> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_0075_01C20702.6D598EB0 Content-Type: image/gif; name="C4404673.gif" Content-Transfer-Encoding: base64 Content-ID: <226110718@29052002-2388> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_0075_01C20702.6D598EB0 Content-Type: image/gif; name="C4929592.gif" Content-Transfer-Encoding: base64 Content-ID: <226110718@29052002-238f> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_0075_01C20702.6D598EB0 Content-Type: image/gif; name="C2638232.gif" Content-Transfer-Encoding: base64 Content-ID: <226110718@29052002-2396> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_0075_01C20702.6D598EB0 Content-Type: image/gif; name="C3486867.gif" Content-Transfer-Encoding: base64 Content-ID: <226110718@29052002-239d> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_0075_01C20702.6D598EB0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Wed May 29 15:51:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01119 for ; Wed, 29 May 2002 15:51:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13152 for policy-archive@odin.ietf.org; Wed, 29 May 2002 15:51:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12616; Wed, 29 May 2002 15:41:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12573 for ; Wed, 29 May 2002 15:41:45 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00728; Wed, 29 May 2002 15:41:15 -0400 (EDT) From: remoore@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4TJfSFD139206; Wed, 29 May 2002 15:41:28 -0400 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4TJfJr120600; Wed, 29 May 2002 15:41:19 -0400 Subject: RE: [Policy] RE: Inconsistencies in QDDIM -07 Draft To: "Andrea Westerinen" Cc: "Policy@Ietf. Org" , policy-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 29 May 2002 15:49:16 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build V60_M13_04292002 Pre-release 2|April 29, 2002) at 05/29/2002 15:41:19 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBE15BDFFFD4E98f9e8a93df938690918c0ABBE15BDFFFD4E9" Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --0__=0ABBE15BDFFFD4E98f9e8a93df938690918c0ABBE15BDFFFD4E9 Content-type: multipart/alternative; Boundary="1__=0ABBE15BDFFFD4E98f9e8a93df938690918c0ABBE15BDFFFD4E9" --1__=0ABBE15BDFFFD4E98f9e8a93df938690918c0ABBE15BDFFFD4E9 Content-type: text/plain; charset=US-ASCII Andrea, Just to be clear: you're asking whether to allow room in the model for a "watches" linkage between a RED dropper and a queue that does not traverse a CalculationService instance. As best I can figure out, in such a case: - only one queue could be watched; - the watched queue would have to be the queue from which packets are dropped; - there would be no smoothing of the current queue depth for the watched queue, since this is what the CalculationService does. I'm not saying yes or no - just asking whether this is in fact what you're proposing. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" To: Robert Moore/Raleigh/IBM@IBMUS com> Subject: RE: [Policy] RE: Inconsistencies in QDDIM -07 Draft Sent by: policy- admin@ietf.org 05/29/02 02:17 PM In the original incarnations of QDDIM, we had NextService only, for a REDDropper. The problem was that the Dropper did not have to base its calculations only on the queue from which it dropped. So, CalculationService was defined to describe the calculations separate from the queue to drop. We did not mandate the existence of the calculation definitions before, so I did not want to do that now. However, I am not religious about this one - mandating the association (based on cardinality) does force specificity. Do others have an opinion on this? Andrea -----Original Message----- From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of remoore@us.ibm.com Sent: Wednesday, May 29, 2002 11:02 AM To: Andrea Westerinen Cc: Policy@Ietf. Org Subject: [Policy] RE: Inconsistencies in QDDIM -07 Draft OK, but then how does a RED dropper get to a queue to watch if it doesn't go via a CalculationService? I didn't think we were using NextService for this. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" "Andrea Westerinen" To: Robert cc: "Policy@Ietf. Org" Subject: RE: 05/29/02 01:34 PM Inconsistencies in QDDIM -07 Draft Bob, I think that the operative words in my email are "IF you define a CalculationService, then ..." Since CalculationService is a new concept and may not be visibly instrumented, I did not want to make it mandatory. Hence, the 0..n on the CalculationService, as related to a REDDropper. I think that the "one or more" wording in the Description is a cut and paste error. Andrea -----Original Message----- From: remoore@us.ibm.com [mailto:remoore@us.ibm.com] Sent: Wednesday, May 29, 2002 10:36 AM To: Andrea Westerinen Cc: Policy@Ietf. Org Subject: Re: Inconsistencies in QDDIM -07 Draft Hi Andrea, Busy editing QDDIM .... From CR 795: // ================================================================== // CalculationServiceForDropper // ================================================================== [Association, Experimental, Version ("2.7.0"), Description ( "This association is a subclass of ServiceServiceDependency, " "and represents the reliance of a REDDropperService on one or " "more DropThresholdCalculationServices. The latter calculate " "average queue depth, based on the observed depths of a " "queue. The specific queue examined by each CalculationService " "is defined using the CalculationBasedOnQueue association.") ] class CIM_CalculationServiceForDropper : CIM_ServiceServiceDependency { [Override ("Antecedent"), Description ( "A calculation service for the dropper.") ] CIM_DropThresholdCalculationService REF Antecedent; [Override ("Dependent"), Description ( "The RED dropper which is dependent on average queue depth " "calculations by the Antecedent Service.") ] CIM_REDDropperService REF Dependent; }; For the calculation service, the words say "one or more", but the cardinality says 0..n. You also propose 0..n for QDDIM, but I think that the words are correct here - the cardinality should be 1..n, since the only path to get from a RED dropper to a queue for it to examine is via a calculation service instance. Assuming that you'll say "Yes, of course," I've tentatively gone with 1..n in the QDDIM update. You can still talk me out of this is you're quick. Otherwise, I've edited QDDIM as you've proposed in this note. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" "Andrea Westerinen" To: "Policy@Ietf. Org" , Robert Moore/Raleigh/IBM@IBM US cc: Subject: Inconsistencies in QDDIM -07 Draft In reading QDDIM very closely :-), I noticed some inconsistencies in the text in Section 3, in the formal class definitions in Section 4, and in the intent. Here are my observations and recommendations ... 1. For RED droppers, I think that we wanted the following ... A REDDropperService can be related to many DropThresholdCalculationServices (many to many), but each CalculationService examines a single queue (many to one). 2. This means that ... IF you define a DropThresholdCalculationService, you really MUST specify the queue that is examined. So, CalculationBasedOnQueue should have a cardinality of 1..1 on the QueuingService side (currently it has 0..1). AND A REDDropper MAY be associated with one or more CalculationServices (each looking at a specific queue). So, CalculationServiceForDropper should have a cardinality of 0..n on the DropThresholdCalculationService side (currently it is a mandatory 1). 3. For a HeadTailDropperService, its determinations can also be based on several queues (as discussed at the bottom of page 23). So, HeadTailDropQueueBinding should have a cardinality of 1..n for the QueuingService (currently, it has mandatory 1). I agree that at least queue is mandatory - but more than one can be examined. Andrea --1__=0ABBE15BDFFFD4E98f9e8a93df938690918c0ABBE15BDFFFD4E9 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Andrea,

Just to be clear: you're asking whether to allow room in the model for a "watches" linkage between a RED dropper and a queue that does not traverse a CalculationService instance. As best I can figure out, in such a case:

- only one queue could be watched;
- the watched queue would have to be the queue from which packets are dropped;
- there would be no smoothing of the current queue depth for the watched queue, since this is what the CalculationService does.

I'm not saying yes or no - just asking whether this is in fact what you're proposing.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com

"Andrea Westerinen" <andreaw@cisco.com>




          "Andrea Westerinen" <andreaw@cisco.com>
          Sent by: policy-admin@ietf.org

          05/29/02 02:17 PM



To: Robert Moore/Raleigh/IBM@IBMUS
cc: "Policy@Ietf. Org" <policy@ietf.org>
Subject: RE: [Policy] RE: Inconsistencies in QDDIM -07 Draft


In the original incarnations of QDDIM, we had NextService only, for a REDDropper. The problem was that the Dropper did not have to base its calculations only on the queue from which it dropped. So, CalculationService was defined to describe the calculations separate from the queue to drop. We did not mandate the existence of the calculation definitions before, so I did not want to do that now. However, I am not religious about this one - mandating the association (based on cardinality) does force specificity.

Do others have an opinion on this?
Andrea
      -----Original Message-----
      From:       policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of remoore@us.ibm.com
      Sent:       Wednesday, May 29, 2002 11:02 AM
      To:       Andrea Westerinen
      Cc:       Policy@Ietf. Org
      Subject:       [Policy] RE: Inconsistencies in QDDIM -07 Draft

      OK, but then how does a RED dropper get to a queue to watch if it doesn't go via a CalculationService? I didn't think we were using NextService for this.

      Regards,
      Bob

      Bob Moore
      Advanced Design and Technology
      Application Integration Middleware Division
      IBM Software Group
      +1-919-254-4436
      remoore@us.ibm.com

      "Andrea Westerinen" <andreaw@cisco.com>
                      "Andrea Westerinen" <andreaw@cisco.com>

                      05/29/02 01:34 PM



      To: Robert Moore/Raleigh/IBM@IBMUS
      cc: "Policy@Ietf. Org" <policy@ietf.org>
      Subject: RE: Inconsistencies in QDDIM -07 Draft

      Bob, I think that the operative words in my email are "IF you define a CalculationService, then ..." Since CalculationService is a new concept and may not be visibly instrumented, I did not want to make it mandatory. Hence, the 0..n on the CalculationService, as related to a REDDropper. I think that the "one or more" wording in the Description is a cut and paste error.

      Andrea
              -----Original Message-----
              From:               remoore@us.ibm.com [mailto:remoore@us.ibm.com]
              Sent:               Wednesday, May 29, 2002 10:36 AM
              To:               Andrea Westerinen
              Cc:               Policy@Ietf. Org
              Subject:               Re: Inconsistencies in QDDIM -07 Draft

              Hi Andrea,

              Busy editing QDDIM ....

              From CR 795:

              // ==================================================================
              // CalculationServiceForDropper
              // ==================================================================
              [Association, Experimental, Version ("2.7.0"),
              Description (
              "This association is a subclass of ServiceServiceDependency, "
              "and represents the reliance of a REDDropperService on one or "
              "more DropThresholdCalculationServices. The latter calculate "
              "average queue depth, based on the observed depths of a "
              "queue. The specific queue examined by each CalculationService "
              "is defined using the CalculationBasedOnQueue association.") ]
              class CIM_CalculationServiceForDropper : CIM_ServiceServiceDependency {
              [Override ("Antecedent"), Description (
              "A calculation service for the dropper.") ]
              CIM_DropThresholdCalculationService REF Antecedent;
              [Override ("Dependent"), Description (
              "The RED dropper which is dependent on average queue depth "
              "calculations by the Antecedent Service.") ]
              CIM_REDDropperService REF Dependent;
              };

              For the calculation service, the words say "one or more", but the cardinality says 0..n. You also propose 0..n for QDDIM, but I think that the words are correct here - the cardinality should be 1..n, since the only path to get from a RED dropper to a queue for it to examine is via a calculation service instance.

              Assuming that you'll say "Yes, of course," I've tentatively gone with 1..n in the QDDIM update. You can still talk me out of this is you're quick.

              Otherwise, I've edited QDDIM as you've proposed in this note.

              Regards,
              Bob

              Bob Moore
              Advanced Design and Technology
              Application Integration Middleware Division
              IBM Software Group
              +1-919-254-4436
              remoore@us.ibm.com

              "Andrea Westerinen" <andreaw@cisco.com>
                                              "Andrea Westerinen" <andreaw@cisco.com>

                                              05/14/02 06:28 PM



              To: "Policy@Ietf. Org" <policy@ietf.org>, Robert Moore/Raleigh/IBM@IBMUS
              cc:
              Subject: Inconsistencies in QDDIM -07 Draft

              In reading QDDIM very closely :-), I noticed some inconsistencies in the text in Section 3, in the formal class definitions in Section 4, and in the intent. Here are my observations and recommendations ...

              1. For RED droppers, I think that we wanted the following ...
              A REDDropperService can be related to many DropThresholdCalculationServices (many to many), but each CalculationService examines a single queue (many to one).

              2. This means that ...
              IF you define a DropThresholdCalculationService, you really MUST specify the queue that is examined. So, CalculationBasedOnQueue should have a cardinality of 1..1 on the QueuingService side (currently it has 0..1).
              AND
              A REDDropper MAY be associated with one or more CalculationServices (each looking at a specific queue). So, CalculationServiceForDropper should have a cardinality of 0..n on the DropThresholdCalculationService side (currently it is a mandatory 1).

              3. For a HeadTailDropperService, its determinations can also be based on several queues (as discussed at the bottom of page 23). So, HeadTailDropQueueBinding should have a cardinality of 1..n for the QueuingService (currently, it has mandatory 1). I agree that at least queue is mandatory - but more than one can be examined.

              Andrea



--1__=0ABBE15BDFFFD4E98f9e8a93df938690918c0ABBE15BDFFFD4E9-- --0__=0ABBE15BDFFFD4E98f9e8a93df938690918c0ABBE15BDFFFD4E9 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=0ABBE15BDFFFD4E98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE15BDFFFD4E98f9e8a93df938690918c0ABBE15BDFFFD4E9 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=0ABBE15BDFFFD4E98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15BDFFFD4E98f9e8a93df938690918c0ABBE15BDFFFD4E9 Content-type: image/gif; name="C4822032.gif" Content-Disposition: inline; filename="C4822032.gif" Content-ID: <40__=0ABBE15BDFFFD4E98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE15BDFFFD4E98f9e8a93df938690918c0ABBE15BDFFFD4E9 Content-type: image/gif; name="C7404108.gif" Content-Disposition: inline; filename="C7404108.gif" Content-ID: <50__=0ABBE15BDFFFD4E98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15BDFFFD4E98f9e8a93df938690918c0ABBE15BDFFFD4E9 Content-type: image/gif; name="C2019288.gif" Content-Disposition: inline; filename="C2019288.gif" Content-ID: <60__=0ABBE15BDFFFD4E98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15BDFFFD4E98f9e8a93df938690918c0ABBE15BDFFFD4E9 Content-type: image/gif; name="C7643349.gif" Content-Disposition: inline; filename="C7643349.gif" Content-ID: <70__=0ABBE15BDFFFD4E98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15BDFFFD4E98f9e8a93df938690918c0ABBE15BDFFFD4E9 Content-type: image/gif; name="C5094617.gif" Content-Disposition: inline; filename="C5094617.gif" Content-ID: <80__=0ABBE15BDFFFD4E98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE15BDFFFD4E98f9e8a93df938690918c0ABBE15BDFFFD4E9 Content-type: image/gif; name="C5695048.gif" Content-Disposition: inline; filename="C5695048.gif" Content-ID: <90__=0ABBE15BDFFFD4E98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15BDFFFD4E98f9e8a93df938690918c0ABBE15BDFFFD4E9 Content-type: image/gif; name="C9166747.gif" Content-Disposition: inline; filename="C9166747.gif" Content-ID: <100__=0ABBE15BDFFFD4E98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15BDFFFD4E98f9e8a93df938690918c0ABBE15BDFFFD4E9 Content-type: image/gif; name="C3220253.gif" Content-Disposition: inline; filename="C3220253.gif" Content-ID: <110__=0ABBE15BDFFFD4E98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15BDFFFD4E98f9e8a93df938690918c0ABBE15BDFFFD4E9-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Wed May 29 16:11:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01671 for ; Wed, 29 May 2002 16:11:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA14495 for policy-archive@odin.ietf.org; Wed, 29 May 2002 16:11:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13348; Wed, 29 May 2002 15:54:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13265 for ; Wed, 29 May 2002 15:54:18 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01180; Wed, 29 May 2002 15:53:48 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4TJqQuF009794; Wed, 29 May 2002 12:52:26 -0700 (PDT) Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ACZ74916; Wed, 29 May 2002 12:52:36 -0700 (PDT) From: "Andrea Westerinen" To: Cc: "Policy@Ietf. Org" , Subject: RE: [Policy] RE: Inconsistencies in QDDIM -07 Draft Date: Wed, 29 May 2002 12:52:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0086_01C2070F.B4A74480" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0086_01C2070F.B4A74480 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0087_01C2070F.B4A74480" ------=_NextPart_001_0087_01C2070F.B4A74480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes. Andrea -----Original Message----- From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of remoore@us.ibm.com Sent: Wednesday, May 29, 2002 12:49 PM To: Andrea Westerinen Cc: Policy@Ietf. Org; policy-admin@ietf.org Subject: RE: [Policy] RE: Inconsistencies in QDDIM -07 Draft Andrea, Just to be clear: you're asking whether to allow room in the model for a "watches" linkage between a RED dropper and a queue that does not traverse a CalculationService instance. As best I can figure out, in such a case: - only one queue could be watched; - the watched queue would have to be the queue from which packets are dropped; - there would be no smoothing of the current queue depth for the watched queue, since this is what the CalculationService does. I'm not saying yes or no - just asking whether this is in fact what you're proposing. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" "Andrea Westerinen" Sent by: policy-admin@ietf.org 05/29/02 02:17 PM To: Robert Moore/Raleigh/IBM@IBMUS cc: "Policy@Ietf. Org" Subject: RE: [Policy] RE: Inconsistencies in QDDIM -07 Draft In the original incarnations of QDDIM, we had NextService only, for a REDDropper. The problem was that the Dropper did not have to base its calculations only on the queue from which it dropped. So, CalculationService was defined to describe the calculations separate from the queue to drop. We did not mandate the existence of the calculation definitions before, so I did not want to do that now. However, I am not religious about this one - mandating the association (based on cardinality) does force specificity. Do others have an opinion on this? Andrea -----Original Message----- From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of remoore@us.ibm.com Sent: Wednesday, May 29, 2002 11:02 AM To: Andrea Westerinen Cc: Policy@Ietf. Org Subject: [Policy] RE: Inconsistencies in QDDIM -07 Draft OK, but then how does a RED dropper get to a queue to watch if it doesn't go via a CalculationService? I didn't think we were using NextService for this. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" "Andrea Westerinen" 05/29/02 01:34 PM To: Robert Moore/Raleigh/IBM@IBMUS cc: "Policy@Ietf. Org" Subject: RE: Inconsistencies in QDDIM -07 Draft Bob, I think that the operative words in my email are "IF you define a CalculationService, then ..." Since CalculationService is a new concept and may not be visibly instrumented, I did not want to make it mandatory. Hence, the 0..n on the CalculationService, as related to a REDDropper. I think that the "one or more" wording in the Description is a cut and paste error. Andrea -----Original Message----- From: remoore@us.ibm.com [mailto:remoore@us.ibm.com] Sent: Wednesday, May 29, 2002 10:36 AM To: Andrea Westerinen Cc: Policy@Ietf. Org Subject: Re: Inconsistencies in QDDIM -07 Draft Hi Andrea, Busy editing QDDIM .... From CR 795: // ================================================================== // CalculationServiceForDropper // ================================================================== [Association, Experimental, Version ("2.7.0"), Description ( "This association is a subclass of ServiceServiceDependency, " "and represents the reliance of a REDDropperService on one or " "more DropThresholdCalculationServices. The latter calculate " "average queue depth, based on the observed depths of a " "queue. The specific queue examined by each CalculationService " "is defined using the CalculationBasedOnQueue association.") ] class CIM_CalculationServiceForDropper : CIM_ServiceServiceDependency { [Override ("Antecedent"), Description ( "A calculation service for the dropper.") ] CIM_DropThresholdCalculationService REF Antecedent; [Override ("Dependent"), Description ( "The RED dropper which is dependent on average queue depth " "calculations by the Antecedent Service.") ] CIM_REDDropperService REF Dependent; }; For the calculation service, the words say "one or more", but the cardinality says 0..n. You also propose 0..n for QDDIM, but I think that the words are correct here - the cardinality should be 1..n, since the only path to get from a RED dropper to a queue for it to examine is via a calculation service instance. Assuming that you'll say "Yes, of course," I've tentatively gone with 1..n in the QDDIM update. You can still talk me out of this is you're quick. Otherwise, I've edited QDDIM as you've proposed in this note. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" "Andrea Westerinen" 05/14/02 06:28 PM To: "Policy@Ietf. Org" , Robert Moore/Raleigh/IBM@IBMUS cc: Subject: Inconsistencies in QDDIM -07 Draft In reading QDDIM very closely :-), I noticed some inconsistencies in the text in Section 3, in the formal class definitions in Section 4, and in the intent. Here are my observations and recommendations ... 1. For RED droppers, I think that we wanted the following ... A REDDropperService can be related to many DropThresholdCalculationServices (many to many), but each CalculationService examines a single queue (many to one). 2. This means that ... IF you define a DropThresholdCalculationService, you really MUST specify the queue that is examined. So, CalculationBasedOnQueue should have a cardinality of 1..1 on the QueuingService side (currently it has 0..1). AND A REDDropper MAY be associated with one or more CalculationServices (each looking at a specific queue). So, CalculationServiceForDropper should have a cardinality of 0..n on the DropThresholdCalculationService side (currently it is a mandatory 1). 3. For a HeadTailDropperService, its determinations can also be based on several queues (as discussed at the bottom of page 23). So, HeadTailDropQueueBinding should have a cardinality of 1..n for the QueuingService (currently, it has mandatory 1). I agree that at least queue is mandatory - but more than one can be examined. Andrea ------=_NextPart_001_0087_01C2070F.B4A74480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes.
Andrea
-----Original Message-----
From: = policy-admin@ietf.org=20 [mailto:policy-admin@ietf.org]On Behalf Of=20 remoore@us.ibm.com
Sent: Wednesday, May 29, 2002 12:49=20 PM
To: Andrea Westerinen
Cc: Policy@Ietf. Org;=20 policy-admin@ietf.org
Subject: RE: [Policy] RE: = Inconsistencies in=20 QDDIM -07 Draft

Andrea,

Just to be clear: = you're=20 asking whether to allow room in the model for a "watches" linkage = between a=20 RED dropper and a queue that does not traverse a CalculationService = instance.=20 As best I can figure out, in such a case:

- only one queue = could be=20 watched;
- the watched queue would have to be the queue from which = packets=20 are dropped;
- there would be no smoothing of the current queue = depth for=20 the watched queue, since this is what the CalculationService = does.

I'm=20 not saying yes or no - just asking whether this is in fact what you're = proposing.

Regards,
Bob

Bob Moore
Advanced Design = and=20 Technology
Application Integration Middleware Division
IBM = Software=20 Group
+1-919-254-4436
remoore@us.ibm.com

3D"""Andrea Westerinen"=20 <andreaw@cisco.com>


3D""
          "Andrea Westerinen"=20 <andreaw@cisco.com>
          Sent by:=20 policy-admin@ietf.org=20

          05/29/02 02:17 = PM

3D""
 3D""

To: Robert=20 Moore/Raleigh/IBM@IBMUS
cc: = "Policy@Ietf. Org" = <policy@ietf.org>
Subject: RE: [Policy] RE: = Inconsistencies in=20 QDDIM -07 Draft


In=20 the original incarnations of QDDIM, we had NextService only, for a = REDDropper.=20 The problem was that the Dropper did not have to base its calculations = only on=20 the queue from which it dropped. So, CalculationService was defined to = describe the calculations separate from the queue to drop. We did not = mandate=20 the existence of the calculation definitions before, so I did not want = to do=20 that now. However, I am not religious about this one - mandating the=20 association (based on cardinality) does force specificity. =

Do=20 others have an opinion on this?
Andrea=20
      -----Original Message-----
      From:       = policy-admin@ietf.org=20 [mailto:policy-admin@ietf.org]On Behalf Of remoore@us.ibm.com
      Sent:       Wednesday, = May 29, 2002=20 11:02 AM
      To:      =20 Andrea Westerinen
      Cc:       Policy@Ietf. Org
      Subject:       [Policy] = RE:=20 Inconsistencies in QDDIM -07 Draft

      OK, but then how does a RED = dropper get to a=20 queue to watch if it doesn't go via a CalculationService? I didn't = think=20 we were using NextService for = this.

      Regards,
      Bob

      Bob=20 Moore
      Advanced Design and Technology
      Application Integration = Middleware Division
      IBM Software=20 Group
      +1-919-254-4436
      remoore@us.ibm.com

      3D""=20"Andrea Westerinen"=20 <andreaw@cisco.com>

      3D"" 3D""=20
                      "Andrea=20 Westerinen"=20 <andreaw@cisco.com>

                      05/29/02 = 01:34=20 = PM

      		 3D""

      To: Robert = Moore/Raleigh/IBM@IBMUS
      cc:=20 "Policy@Ietf. Org" <policy@ietf.org>
      Subject: RE:=20 Inconsistencies in QDDIM -07 Draft

      Bob, I think that the = operative words=20 in my email are "IF you define a CalculationService, then ..." = Since=20 CalculationService is a new concept and may not be visibly = instrumented, I=20 did not want to make it mandatory. Hence, the 0..n on the=20 CalculationService, as related to a REDDropper. I think that the = "one or=20 more" wording in the Description is a cut and paste = error.

      Andrea
              -----Original=20 Message-----
              From:               = remoore@us.ibm.com [mailto:remoore@us.ibm.com]
              Sent:               = Wednesday,=20 May 29, 2002 10:36 AM
              To:               = Andrea=20 Westerinen
              Cc:               = Policy@Ietf.=20 Org
              Subject:               Re: Inconsistencies in QDDIM -07=20 Draft

              Hi = Andrea,

              Busy editing=20 QDDIM ....

              From CR 795:

              //=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
              //=20 CalculationServiceForDropper
              //=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
              [Association,=20 Experimental, Version ("2.7.0"),
              Description = (
              "This=20 association is a subclass of ServiceServiceDependency, = "
              "and=20 represents the reliance of a REDDropperService on one or=20 "
              "more DropThresholdCalculationServices. The latter = calculate=20 "
              "average queue depth, based on the observed depths of = a=20 "
              "queue. The specific queue examined by each=20 CalculationService "
              "is defined using the=20 CalculationBasedOnQueue association.") ]
              class=20 CIM_CalculationServiceForDropper : = CIM_ServiceServiceDependency=20 {
              [Override ("Antecedent"), Description (
              "A = calculation=20 service for the dropper.")=20 ]
              CIM_DropThresholdCalculationService REF=20 Antecedent;
              [Override ("Dependent"), Description = (
              "The RED=20 dropper which is dependent on average queue depth=20 "
              "calculations by the Antecedent Service.")=20 ]
              CIM_REDDropperService REF Dependent;
              };

              For = the=20 calculation service, the words say "one or more", but the=20 cardinality says 0..n. You also propose 0..n for QDDIM, = but I=20 think that the words are correct here - the cardinality = should be=20 1..n, since the only path to get from a RED dropper to a = queue for=20 it to examine is via a calculation service=20 instance.

              Assuming that you'll say "Yes, of = course," I've=20 tentatively gone with 1..n in the QDDIM update. You can = still talk=20 me out of this is you're quick.

              Otherwise, I've = edited=20 QDDIM as you've proposed in this=20 note.

              Regards,
              Bob

              Bob Moore
              Advanced = Design=20 and Technology
              Application Integration Middleware=20 Division
              IBM Software=20 = Group
              +1-919-254-4436
              remoore@us.ibm.com

              3D"""Andrea Westerinen"=20 <andreaw@cisco.com>
              3D"" 3D""=20
                                              "Andrea Westerinen"=20 = <andreaw@cisco.com> =

                                              05/14/02=20 06:28=20 = PM

                      =
              		3D""

              To: = "Policy@Ietf. Org"=20 <policy@ietf.org>, Robert=20 Moore/Raleigh/IBM@IBMUS
              cc:
              Subject: = Inconsistencies=20 in QDDIM -07 = Draft

              In reading QDDIM = very closely=20 :-), I noticed some inconsistencies in the text in Section = 3, in=20 the formal class definitions in Section 4, and in the = intent. Here=20 are my observations and recommendations ...

              1. For = RED=20 droppers, I think that we wanted the following ...
              A=20 REDDropperService can be related to many=20 DropThresholdCalculationServices (many to many), but each=20 CalculationService examines a single queue (many to=20 one).

              2. This means that ...
              IF you define a=20 DropThresholdCalculationService, you really MUST specify = the queue=20 that is examined. So, CalculationBasedOnQueue should have = a=20 cardinality of 1..1 on the QueuingService side (currently = it has=20 0..1).
              AND
              A REDDropper MAY be associated with one = or more=20 CalculationServices (each looking at a specific queue). = So,=20 CalculationServiceForDropper should have a cardinality of = 0..n on=20 the DropThresholdCalculationService side (currently it is = a=20 mandatory 1).

              3. For a HeadTailDropperService, its = determinations can also be based on several queues (as = discussed=20 at the bottom of page 23). So, HeadTailDropQueueBinding = should=20 have a cardinality of 1..n for the QueuingService = (currently, it=20 has mandatory 1). I agree that at least queue is mandatory = - but=20 more than one can be examined.

              Andrea



------=_NextPart_001_0087_01C2070F.B4A74480-- ------=_NextPart_000_0086_01C2070F.B4A74480 Content-Type: image/gif; name="graycol.gif" Content-Transfer-Encoding: base64 Content-ID: <397025219@29052002-23a4> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_0086_01C2070F.B4A74480 Content-Type: image/gif; name="ecblank.gif" Content-Transfer-Encoding: base64 Content-ID: <397025219@29052002-23ab> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_0086_01C2070F.B4A74480 Content-Type: image/gif; name="C4822032.gif" Content-Transfer-Encoding: base64 Content-ID: <397025219@29052002-23b2> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_0086_01C2070F.B4A74480 Content-Type: image/gif; name="C7404108.gif" Content-Transfer-Encoding: base64 Content-ID: <397025219@29052002-23b9> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_0086_01C2070F.B4A74480 Content-Type: image/gif; name="C2019288.gif" Content-Transfer-Encoding: base64 Content-ID: <397025219@29052002-23c0> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_0086_01C2070F.B4A74480 Content-Type: image/gif; name="C7643349.gif" Content-Transfer-Encoding: base64 Content-ID: <397025219@29052002-23c7> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_0086_01C2070F.B4A74480 Content-Type: image/gif; name="C5094617.gif" Content-Transfer-Encoding: base64 Content-ID: <397025219@29052002-23ce> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_0086_01C2070F.B4A74480 Content-Type: image/gif; name="C5695048.gif" Content-Transfer-Encoding: base64 Content-ID: <397025219@29052002-23d5> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_0086_01C2070F.B4A74480 Content-Type: image/gif; name="C9166747.gif" Content-Transfer-Encoding: base64 Content-ID: <397025219@29052002-23dc> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_0086_01C2070F.B4A74480 Content-Type: image/gif; name="C3220253.gif" Content-Transfer-Encoding: base64 Content-ID: <397025219@29052002-23e3> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_0086_01C2070F.B4A74480-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Wed May 29 16:30:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02266 for ; Wed, 29 May 2002 16:30:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15650 for policy-archive@odin.ietf.org; Wed, 29 May 2002 16:30:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14854; Wed, 29 May 2002 16:21:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14826 for ; Wed, 29 May 2002 16:21:12 -0400 (EDT) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01911 for ; Wed, 29 May 2002 16:20:47 -0400 (EDT) Received: from user-vcaurvs.dsl.mindspring.com ([216.175.111.252] helo=ANDREWHOME) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #2) id 17D9wL-0004yT-00; Wed, 29 May 2002 13:21:01 -0700 From: "Andrew Smith" To: , "Andrea Westerinen" Cc: "Policy@Ietf. Org" Subject: RE: [Policy] RE: Inconsistencies in QDDIM -07 Draft Date: Wed, 29 May 2002 13:54:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_06ED_01C20718.62E3C8E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_06ED_01C20718.62E3C8E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_06EE_01C20718.62E6D620" ------=_NextPart_001_06EE_01C20718.62E6D620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bob, Andrew, Rather than inventing a special case for this, why not just use a CalculationService instance that does a very simple calculation? Or is this issue really just because people feel a need to be backwards-compatible with an earlier draft? Andrew Smith -----Original Message----- From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of remoore@us.ibm.com Sent: Wednesday, May 29, 2002 12:49 PM To: Andrea Westerinen Cc: Policy@Ietf. Org; policy-admin@ietf.org Subject: RE: [Policy] RE: Inconsistencies in QDDIM -07 Draft Andrea, Just to be clear: you're asking whether to allow room in the model for a "watches" linkage between a RED dropper and a queue that does not traverse a CalculationService instance. As best I can figure out, in such a case: - only one queue could be watched; - the watched queue would have to be the queue from which packets are dropped; - there would be no smoothing of the current queue depth for the watched queue, since this is what the CalculationService does. I'm not saying yes or no - just asking whether this is in fact what you're proposing. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" "Andrea Westerinen" Sent by: policy-admin@ietf.org 05/29/02 02:17 PM To: Robert Moore/Raleigh/IBM@IBMUS cc: "Policy@Ietf. Org" Subject: RE: [Policy] RE: Inconsistencies in QDDIM -07 Draft In the original incarnations of QDDIM, we had NextService only, for a REDDropper. The problem was that the Dropper did not have to base its calculations only on the queue from which it dropped. So, CalculationService was defined to describe the calculations separate from the queue to drop. We did not mandate the existence of the calculation definitions before, so I did not want to do that now. However, I am not religious about this one - mandating the association (based on cardinality) does force specificity. Do others have an opinion on this? Andrea -----Original Message----- From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of remoore@us.ibm.com Sent: Wednesday, May 29, 2002 11:02 AM To: Andrea Westerinen Cc: Policy@Ietf. Org Subject: [Policy] RE: Inconsistencies in QDDIM -07 Draft OK, but then how does a RED dropper get to a queue to watch if it doesn't go via a CalculationService? I didn't think we were using NextService for this. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" "Andrea Westerinen" 05/29/02 01:34 PM To: Robert Moore/Raleigh/IBM@IBMUS cc: "Policy@Ietf. Org" Subject: RE: Inconsistencies in QDDIM -07 Draft Bob, I think that the operative words in my email are "IF you define a CalculationService, then ..." Since CalculationService is a new concept and may not be visibly instrumented, I did not want to make it mandatory. Hence, the 0..n on the CalculationService, as related to a REDDropper. I think that the "one or more" wording in the Description is a cut and paste error. Andrea -----Original Message----- From: remoore@us.ibm.com [mailto:remoore@us.ibm.com] Sent: Wednesday, May 29, 2002 10:36 AM To: Andrea Westerinen Cc: Policy@Ietf. Org Subject: Re: Inconsistencies in QDDIM -07 Draft Hi Andrea, Busy editing QDDIM .... From CR 795: // ================================================================== // CalculationServiceForDropper // ================================================================== [Association, Experimental, Version ("2.7.0"), Description ( "This association is a subclass of ServiceServiceDependency, " "and represents the reliance of a REDDropperService on one or " "more DropThresholdCalculationServices. The latter calculate " "average queue depth, based on the observed depths of a " "queue. The specific queue examined by each CalculationService " "is defined using the CalculationBasedOnQueue association.") ] class CIM_CalculationServiceForDropper : CIM_ServiceServiceDependency { [Override ("Antecedent"), Description ( "A calculation service for the dropper.") ] CIM_DropThresholdCalculationService REF Antecedent; [Override ("Dependent"), Description ( "The RED dropper which is dependent on average queue depth " "calculations by the Antecedent Service.") ] CIM_REDDropperService REF Dependent; }; For the calculation service, the words say "one or more", but the cardinality says 0..n. You also propose 0..n for QDDIM, but I think that the words are correct here - the cardinality should be 1..n, since the only path to get from a RED dropper to a queue for it to examine is via a calculation service instance. Assuming that you'll say "Yes, of course," I've tentatively gone with 1..n in the QDDIM update. You can still talk me out of this is you're quick. Otherwise, I've edited QDDIM as you've proposed in this note. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" "Andrea Westerinen" 05/14/02 06:28 PM To: "Policy@Ietf. Org" , Robert Moore/Raleigh/IBM@IBMUS cc: Subject: Inconsistencies in QDDIM -07 Draft In reading QDDIM very closely :-), I noticed some inconsistencies in the text in Section 3, in the formal class definitions in Section 4, and in the intent. Here are my observations and recommendations ... 1. For RED droppers, I think that we wanted the following ... A REDDropperService can be related to many DropThresholdCalculationServices (many to many), but each CalculationService examines a single queue (many to one). 2. This means that ... IF you define a DropThresholdCalculationService, you really MUST specify the queue that is examined. So, CalculationBasedOnQueue should have a cardinality of 1..1 on the QueuingService side (currently it has 0..1). AND A REDDropper MAY be associated with one or more CalculationServices (each looking at a specific queue). So, CalculationServiceForDropper should have a cardinality of 0..n on the DropThresholdCalculationService side (currently it is a mandatory 1). 3. For a HeadTailDropperService, its determinations can also be based on several queues (as discussed at the bottom of page 23). So, HeadTailDropQueueBinding should have a cardinality of 1..n for the QueuingService (currently, it has mandatory 1). I agree that at least queue is mandatory - but more than one can be examined. Andrea ------=_NextPart_001_06EE_01C20718.62E6D620 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bob,=20 Andrew,
 
Rather than inventing a = special case for=20 this, why not just use a CalculationService instance that does a very = simple=20 calculation? Or is this issue really just because people feel a = need to be=20 backwards-compatible with an earlier draft?
 
Andrew=20 Smith
-----Original Message-----
From: = policy-admin@ietf.org=20 [mailto:policy-admin@ietf.org]On Behalf Of=20 remoore@us.ibm.com
Sent: Wednesday, May 29, 2002 12:49=20 PM
To: Andrea Westerinen
Cc: Policy@Ietf. Org;=20 policy-admin@ietf.org
Subject: RE: [Policy] RE: = Inconsistencies in=20 QDDIM -07 Draft

Andrea,

Just to be clear: = you're=20 asking whether to allow room in the model for a "watches" linkage = between a=20 RED dropper and a queue that does not traverse a CalculationService = instance.=20 As best I can figure out, in such a case:

- only one queue = could be=20 watched;
- the watched queue would have to be the queue from which = packets=20 are dropped;
- there would be no smoothing of the current queue = depth for=20 the watched queue, since this is what the CalculationService = does.

I'm=20 not saying yes or no - just asking whether this is in fact what you're = proposing.

Regards,
Bob

Bob Moore
Advanced Design = and=20 Technology
Application Integration Middleware Division
IBM = Software=20 Group
+1-919-254-4436
remoore@us.ibm.com

3D""=20"Andrea Westerinen"=20 <andreaw@cisco.com>


3D""
          "Andrea Westerinen"=20 <andreaw@cisco.com>
          Sent by:=20 policy-admin@ietf.org=20

          05/29/02 02:17 = PM

3D""
 3D""

To:=20 Robert = Moore/Raleigh/IBM@IBMUS
cc: "Policy@Ietf. Org"=20 <policy@ietf.org>
Subject: = RE: [Policy] RE: Inconsistencies in QDDIM -07=20 Draft


In=20 the original incarnations of QDDIM, we had NextService only, for a = REDDropper.=20 The problem was that the Dropper did not have to base its calculations = only on=20 the queue from which it dropped. So, CalculationService was defined to = describe the calculations separate from the queue to drop. We did not = mandate=20 the existence of the calculation definitions before, so I did not want = to do=20 that now. However, I am not religious about this one - mandating the=20 association (based on cardinality) does force specificity. =

Do=20 others have an opinion on this?
Andrea=20
      -----Original Message-----
      From:       = policy-admin@ietf.org=20 [mailto:policy-admin@ietf.org]On Behalf Of remoore@us.ibm.com
      Sent:       Wednesday, = May 29, 2002=20 11:02 AM
      To:      =20 Andrea Westerinen
      Cc:       Policy@Ietf. Org
      Subject:       [Policy] = RE:=20 Inconsistencies in QDDIM -07 Draft

      OK, but then how does a RED = dropper get to a=20 queue to watch if it doesn't go via a CalculationService? I didn't = think=20 we were using NextService for = this.

      Regards,
      Bob

      Bob=20 Moore
      Advanced Design and Technology
      Application Integration = Middleware Division
      IBM Software=20 Group
      +1-919-254-4436
      remoore@us.ibm.com

      "Andrea Westerinen"=20 <andreaw@cisco.com>

      3D""=20 3D""=20=20
                      "Andrea=20 Westerinen"=20 <andreaw@cisco.com>

                      05/29/02 = 01:34=20 = PM

      		 3D""=20

      To: Robert = Moore/Raleigh/IBM@IBMUS
      cc:=20 "Policy@Ietf. Org" <policy@ietf.org>
      Subject: RE:=20 Inconsistencies in QDDIM -07 Draft

      Bob, I think that the = operative words=20 in my email are "IF you define a CalculationService, then ..." = Since=20 CalculationService is a new concept and may not be visibly = instrumented, I=20 did not want to make it mandatory. Hence, the 0..n on the=20 CalculationService, as related to a REDDropper. I think that the = "one or=20 more" wording in the Description is a cut and paste = error.

      Andrea
              -----Original=20 Message-----
              From:               = remoore@us.ibm.com [mailto:remoore@us.ibm.com]
              Sent:               = Wednesday,=20 May 29, 2002 10:36 AM
              To:               = Andrea=20 Westerinen
              Cc:               = Policy@Ietf.=20 Org
              Subject:               Re: Inconsistencies in QDDIM -07=20 Draft

              Hi = Andrea,

              Busy editing=20 QDDIM ....

              From CR 795:

              //=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
              //=20 CalculationServiceForDropper
              //=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
              [Association,=20 Experimental, Version ("2.7.0"),
              Description = (
              "This=20 association is a subclass of ServiceServiceDependency, = "
              "and=20 represents the reliance of a REDDropperService on one or=20 "
              "more DropThresholdCalculationServices. The latter = calculate=20 "
              "average queue depth, based on the observed depths of = a=20 "
              "queue. The specific queue examined by each=20 CalculationService "
              "is defined using the=20 CalculationBasedOnQueue association.") ]
              class=20 CIM_CalculationServiceForDropper : = CIM_ServiceServiceDependency=20 {
              [Override ("Antecedent"), Description (
              "A = calculation=20 service for the dropper.")=20 ]
              CIM_DropThresholdCalculationService REF=20 Antecedent;
              [Override ("Dependent"), Description = (
              "The RED=20 dropper which is dependent on average queue depth=20 "
              "calculations by the Antecedent Service.")=20 ]
              CIM_REDDropperService REF Dependent;
              };

              For = the=20 calculation service, the words say "one or more", but the=20 cardinality says 0..n. You also propose 0..n for QDDIM, = but I=20 think that the words are correct here - the cardinality = should be=20 1..n, since the only path to get from a RED dropper to a = queue for=20 it to examine is via a calculation service=20 instance.

              Assuming that you'll say "Yes, of = course," I've=20 tentatively gone with 1..n in the QDDIM update. You can = still talk=20 me out of this is you're quick.

              Otherwise, I've = edited=20 QDDIM as you've proposed in this=20 note.

              Regards,
              Bob

              Bob Moore
              Advanced = Design=20 and Technology
              Application Integration Middleware=20 Division
              IBM Software=20 = Group
              +1-919-254-4436
              remoore@us.ibm.com

              3D""=20"Andrea Westerinen"=20 <andreaw@cisco.com>
              3D""=20 3D""=20=20
                                              "Andrea Westerinen"=20 = <andreaw@cisco.com> =

                                              05/14/02=20 06:28=20 = PM

                      =
              		3D""=20

              To: = "Policy@Ietf. Org"=20 <policy@ietf.org>, Robert=20 Moore/Raleigh/IBM@IBMUS
              cc:
              Subject: = Inconsistencies=20 in QDDIM -07 = Draft

              In reading QDDIM = very closely=20 :-), I noticed some inconsistencies in the text in Section = 3, in=20 the formal class definitions in Section 4, and in the = intent. Here=20 are my observations and recommendations ...

              1. For = RED=20 droppers, I think that we wanted the following ...
              A=20 REDDropperService can be related to many=20 DropThresholdCalculationServices (many to many), but each=20 CalculationService examines a single queue (many to=20 one).

              2. This means that ...
              IF you define a=20 DropThresholdCalculationService, you really MUST specify = the queue=20 that is examined. So, CalculationBasedOnQueue should have = a=20 cardinality of 1..1 on the QueuingService side (currently = it has=20 0..1).
              AND
              A REDDropper MAY be associated with one = or more=20 CalculationServices (each looking at a specific queue). = So,=20 CalculationServiceForDropper should have a cardinality of = 0..n on=20 the DropThresholdCalculationService side (currently it is = a=20 mandatory 1).

              3. For a HeadTailDropperService, its = determinations can also be based on several queues (as = discussed=20 at the bottom of page 23). So, HeadTailDropQueueBinding = should=20 have a cardinality of 1..n for the QueuingService = (currently, it=20 has mandatory 1). I agree that at least queue is mandatory = - but=20 more than one can be examined.

              Andrea



------=_NextPart_001_06EE_01C20718.62E6D620-- ------=_NextPart_000_06ED_01C20718.62E3C8E0 Content-Type: image/gif; name="graycol.gif" Content-Transfer-Encoding: base64 Content-ID: <404474920@29052002-1f78> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_06ED_01C20718.62E3C8E0 Content-Type: image/gif; name="ecblank.gif" Content-Transfer-Encoding: base64 Content-ID: <404474920@29052002-1f7f> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_06ED_01C20718.62E3C8E0 Content-Type: image/gif; name="C4822032.gif" Content-Transfer-Encoding: base64 Content-ID: <404474920@29052002-1f86> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_06ED_01C20718.62E3C8E0 Content-Type: image/gif; name="C7404108.gif" Content-Transfer-Encoding: base64 Content-ID: <404474920@29052002-1f8d> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_06ED_01C20718.62E3C8E0 Content-Type: image/gif; name="C2019288.gif" Content-Transfer-Encoding: base64 Content-ID: <404474920@29052002-1f94> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_06ED_01C20718.62E3C8E0 Content-Type: image/gif; name="C7643349.gif" Content-Transfer-Encoding: base64 Content-ID: <404474920@29052002-1f9b> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_06ED_01C20718.62E3C8E0 Content-Type: image/gif; name="C5094617.gif" Content-Transfer-Encoding: base64 Content-ID: <404474920@29052002-1fa2> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_06ED_01C20718.62E3C8E0 Content-Type: image/gif; name="C5695048.gif" Content-Transfer-Encoding: base64 Content-ID: <404474920@29052002-1fa9> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_06ED_01C20718.62E3C8E0 Content-Type: image/gif; name="C9166747.gif" Content-Transfer-Encoding: base64 Content-ID: <404474920@29052002-1fb0> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_06ED_01C20718.62E3C8E0 Content-Type: image/gif; name="C3220253.gif" Content-Transfer-Encoding: base64 Content-ID: <404474920@29052002-1fb7> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_06ED_01C20718.62E3C8E0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Wed May 29 17:04:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03318 for ; Wed, 29 May 2002 17:04:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA18591 for policy-archive@odin.ietf.org; Wed, 29 May 2002 17:05:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17065; Wed, 29 May 2002 16:56:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16986 for ; Wed, 29 May 2002 16:56:49 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02993 for ; Wed, 29 May 2002 16:56:19 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4TKttuF014351; Wed, 29 May 2002 13:55:55 -0700 (PDT) Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ACZ76456; Wed, 29 May 2002 13:56:05 -0700 (PDT) From: "Andrea Westerinen" To: "Andrew Smith" , Cc: "Policy@Ietf. Org" Subject: RE: [Policy] RE: Inconsistencies in QDDIM -07 Draft Date: Wed, 29 May 2002 13:56:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_008F_01C20718.93377550" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_008F_01C20718.93377550 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0090_01C20718.93377550" ------=_NextPart_001_0090_01C20718.93377550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Let's just put a stake in the ground and say that you must have the CalculationService if you have a REDDropper (Bob's 1..n cardinality). Specificity is clearer and simpler than having multiple degrees of freedom. Andea -----Original Message----- From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of Andrew Smith Sent: Wednesday, May 29, 2002 1:55 PM To: remoore@us.ibm.com; Andrea Westerinen Cc: Policy@Ietf. Org Subject: RE: [Policy] RE: Inconsistencies in QDDIM -07 Draft Bob, Andrew, Rather than inventing a special case for this, why not just use a CalculationService instance that does a very simple calculation? Or is this issue really just because people feel a need to be backwards-compatible with an earlier draft? Andrew Smith -----Original Message----- From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of remoore@us.ibm.com Sent: Wednesday, May 29, 2002 12:49 PM To: Andrea Westerinen Cc: Policy@Ietf. Org; policy-admin@ietf.org Subject: RE: [Policy] RE: Inconsistencies in QDDIM -07 Draft Andrea, Just to be clear: you're asking whether to allow room in the model for a "watches" linkage between a RED dropper and a queue that does not traverse a CalculationService instance. As best I can figure out, in such a case: - only one queue could be watched; - the watched queue would have to be the queue from which packets are dropped; - there would be no smoothing of the current queue depth for the watched queue, since this is what the CalculationService does. I'm not saying yes or no - just asking whether this is in fact what you're proposing. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" "Andrea Westerinen" Sent by: policy-admin@ietf.org 05/29/02 02:17 PM To: Robert Moore/Raleigh/IBM@IBMUS cc: "Policy@Ietf. Org" Subject: RE: [Policy] RE: Inconsistencies in QDDIM -07 Draft In the original incarnations of QDDIM, we had NextService only, for a REDDropper. The problem was that the Dropper did not have to base its calculations only on the queue from which it dropped. So, CalculationService was defined to describe the calculations separate from the queue to drop. We did not mandate the existence of the calculation definitions before, so I did not want to do that now. However, I am not religious about this one - mandating the association (based on cardinality) does force specificity. Do others have an opinion on this? Andrea -----Original Message----- From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of remoore@us.ibm.com Sent: Wednesday, May 29, 2002 11:02 AM To: Andrea Westerinen Cc: Policy@Ietf. Org Subject: [Policy] RE: Inconsistencies in QDDIM -07 Draft OK, but then how does a RED dropper get to a queue to watch if it doesn't go via a CalculationService? I didn't think we were using NextService for this. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" "Andrea Westerinen" 05/29/02 01:34 PM To: Robert Moore/Raleigh/IBM@IBMUS cc: "Policy@Ietf. Org" Subject: RE: Inconsistencies in QDDIM -07 Draft Bob, I think that the operative words in my email are "IF you define a CalculationService, then ..." Since CalculationService is a new concept and may not be visibly instrumented, I did not want to make it mandatory. Hence, the 0..n on the CalculationService, as related to a REDDropper. I think that the "one or more" wording in the Description is a cut and paste error. Andrea -----Original Message----- From: remoore@us.ibm.com [mailto:remoore@us.ibm.com] Sent: Wednesday, May 29, 2002 10:36 AM To: Andrea Westerinen Cc: Policy@Ietf. Org Subject: Re: Inconsistencies in QDDIM -07 Draft Hi Andrea, Busy editing QDDIM .... From CR 795: // ================================================================== // CalculationServiceForDropper // ================================================================== [Association, Experimental, Version ("2.7.0"), Description ( "This association is a subclass of ServiceServiceDependency, " "and represents the reliance of a REDDropperService on one or " "more DropThresholdCalculationServices. The latter calculate " "average queue depth, based on the observed depths of a " "queue. The specific queue examined by each CalculationService " "is defined using the CalculationBasedOnQueue association.") ] class CIM_CalculationServiceForDropper : CIM_ServiceServiceDependency { [Override ("Antecedent"), Description ( "A calculation service for the dropper.") ] CIM_DropThresholdCalculationService REF Antecedent; [Override ("Dependent"), Description ( "The RED dropper which is dependent on average queue depth " "calculations by the Antecedent Service.") ] CIM_REDDropperService REF Dependent; }; For the calculation service, the words say "one or more", but the cardinality says 0..n. You also propose 0..n for QDDIM, but I think that the words are correct here - the cardinality should be 1..n, since the only path to get from a RED dropper to a queue for it to examine is via a calculation service instance. Assuming that you'll say "Yes, of course," I've tentatively gone with 1..n in the QDDIM update. You can still talk me out of this is you're quick. Otherwise, I've edited QDDIM as you've proposed in this note. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" "Andrea Westerinen" 05/14/02 06:28 PM To: "Policy@Ietf. Org" , Robert Moore/Raleigh/IBM@IBMUS cc: Subject: Inconsistencies in QDDIM -07 Draft In reading QDDIM very closely :-), I noticed some inconsistencies in the text in Section 3, in the formal class definitions in Section 4, and in the intent. Here are my observations and recommendations ... 1. For RED droppers, I think that we wanted the following ... A REDDropperService can be related to many DropThresholdCalculationServices (many to many), but each CalculationService examines a single queue (many to one). 2. This means that ... IF you define a DropThresholdCalculationService, you really MUST specify the queue that is examined. So, CalculationBasedOnQueue should have a cardinality of 1..1 on the QueuingService side (currently it has 0..1). AND A REDDropper MAY be associated with one or more CalculationServices (each looking at a specific queue). So, CalculationServiceForDropper should have a cardinality of 0..n on the DropThresholdCalculationService side (currently it is a mandatory 1). 3. For a HeadTailDropperService, its determinations can also be based on several queues (as discussed at the bottom of page 23). So, HeadTailDropQueueBinding should have a cardinality of 1..n for the QueuingService (currently, it has mandatory 1). I agree that at least queue is mandatory - but more than one can be examined. Andrea ------=_NextPart_001_0090_01C20718.93377550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Let's=20 just put a stake in the ground and say that you must have the = CalculationService=20 if you have a REDDropper (Bob's 1..n cardinality).  Specificity is = clearer=20 and simpler than having multiple degrees of freedom.
 
Andea
-----Original Message-----
From: = policy-admin@ietf.org=20 [mailto:policy-admin@ietf.org]On Behalf Of Andrew = Smith
Sent:=20 Wednesday, May 29, 2002 1:55 PM
To: remoore@us.ibm.com; = Andrea=20 Westerinen
Cc: Policy@Ietf. Org
Subject: RE: = [Policy] RE:=20 Inconsistencies in QDDIM -07 Draft

Bob,=20 Andrew,
 
Rather than inventing a = special case for=20 this, why not just use a CalculationService instance that does a very = simple=20 calculation? Or is this issue really just because people feel a = need to=20 be backwards-compatible with an earlier draft?
 
Andrew Smith
-----Original Message-----
From: = policy-admin@ietf.org=20 [mailto:policy-admin@ietf.org]On Behalf Of=20 remoore@us.ibm.com
Sent: Wednesday, May 29, 2002 12:49 = PM
To: Andrea Westerinen
Cc: Policy@Ietf. Org;=20 policy-admin@ietf.org
Subject: RE: [Policy] RE: = Inconsistencies in=20 QDDIM -07 Draft

Andrea,

Just to be clear: = you're=20 asking whether to allow room in the model for a "watches" linkage = between a=20 RED dropper and a queue that does not traverse a CalculationService=20 instance. As best I can figure out, in such a case:

- only = one queue=20 could be watched;
- the watched queue would have to be the queue = from=20 which packets are dropped;
- there would be no smoothing of the = current=20 queue depth for the watched queue, since this is what the = CalculationService=20 does.

I'm not saying yes or no - just asking whether this is = in fact=20 what you're proposing.

Regards,
Bob

Bob = Moore
Advanced=20 Design and Technology
Application Integration Middleware = Division
IBM=20 Software Group
+1-919-254-4436
remoore@us.ibm.com

3D""=20"Andrea = Westerinen"=20 <andreaw@cisco.com>


3D""
          "Andrea Westerinen"=20 <andreaw@cisco.com>
          Sent by:=20 policy-admin@ietf.org=20

          05/29/02 02:17 = PM

3D""
 3D""

To: Robert=20 Moore/Raleigh/IBM@IBMUS
cc: = "Policy@Ietf. Org" = <policy@ietf.org>
Subject: RE: [Policy] RE: = Inconsistencies=20 in QDDIM -07 Draft


In the original incarnations of QDDIM, we had = NextService only,=20 for a REDDropper. The problem was that the Dropper did not have to = base its=20 calculations only on the queue from which it dropped. So, = CalculationService=20 was defined to describe the calculations separate from the queue to = drop. We=20 did not mandate the existence of the calculation definitions before, = so I=20 did not want to do that now. However, I am not religious about this = one -=20 mandating the association (based on cardinality) does force = specificity.=20

Do others have an opinion on = this?
Andrea=20
      -----Original Message-----
      From:       = policy-admin@ietf.org=20 [mailto:policy-admin@ietf.org]On Behalf Of remoore@us.ibm.com
      Sent:       = Wednesday, May 29,=20 2002 11:02 AM
      To:       Andrea Westerinen
      Cc:       = Policy@Ietf.=20 Org
      Subject:      =20 [Policy] RE: Inconsistencies in QDDIM -07 = Draft

      OK, but then how does a RED = dropper get to=20 a queue to watch if it doesn't go via a CalculationService? I = didn't=20 think we were using NextService for=20 this.

      Regards,
      Bob

      Bob Moore
      Advanced Design = and=20 Technology
      Application Integration Middleware Division
      IBM = Software=20 = Group
      +1-919-254-4436
      remoore@us.ibm.com

      3D""=20"Andrea Westerinen"=20 <andreaw@cisco.com>
      3D"" 3D""=20
                      "Andrea=20 Westerinen"=20 <andreaw@cisco.com>

                      05/29/02 = 01:34=20 = PM

      		 3D""

      To: Robert=20 Moore/Raleigh/IBM@IBMUS
      cc: "Policy@Ietf. Org"=20 <policy@ietf.org>
      Subject: RE: Inconsistencies in = QDDIM=20 -07 Draft

      Bob, I think that the operative words = in my email=20 are "IF you define a CalculationService, then ..." Since=20 CalculationService is a new concept and may not be visibly = instrumented,=20 I did not want to make it mandatory. Hence, the 0..n on the=20 CalculationService, as related to a REDDropper. I think that the = "one or=20 more" wording in the Description is a cut and paste = error.

      Andrea
              -----Original=20 Message-----
              From:              =20 remoore@us.ibm.com [mailto:remoore@us.ibm.com]
              Sent:               Wednesday,=20 May 29, 2002 10:36 AM
              To:               = Andrea=20 Westerinen
              Cc:               = Policy@Ietf.=20 Org
              Subject:               Re:=20 Inconsistencies in QDDIM -07 Draft

              Hi = Andrea,

              Busy editing=20 QDDIM ....

              From CR 795:

              //=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
              //=20 CalculationServiceForDropper
              //=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
              [Association,=20 Experimental, Version ("2.7.0"),
              Description = (
              "This=20 association is a subclass of ServiceServiceDependency, = "
              "and=20 represents the reliance of a REDDropperService on one or = "
              "more DropThresholdCalculationServices. The latter=20 calculate "
              "average queue depth, based on the = observed=20 depths of a "
              "queue. The specific queue examined by = each=20 CalculationService "
              "is defined using the=20 CalculationBasedOnQueue association.") ]
              class=20 CIM_CalculationServiceForDropper : = CIM_ServiceServiceDependency=20 {
              [Override ("Antecedent"), Description (
              "A = calculation=20 service for the dropper.")=20 ]
              CIM_DropThresholdCalculationService REF=20 Antecedent;
              [Override ("Dependent"), Description = (
              "The=20 RED dropper which is dependent on average queue depth=20 "
              "calculations by the Antecedent Service.")=20 ]
              CIM_REDDropperService REF = Dependent;
              };

              For the=20 calculation service, the words say "one or more", but = the=20 cardinality says 0..n. You also propose 0..n for QDDIM, = but I=20 think that the words are correct here - the cardinality = should=20 be 1..n, since the only path to get from a RED dropper = to a=20 queue for it to examine is via a calculation service=20 instance.

              Assuming that you'll say "Yes, of = course," I've=20 tentatively gone with 1..n in the QDDIM update. You can = still=20 talk me out of this is you're quick.

              Otherwise, = I've=20 edited QDDIM as you've proposed in this=20 note.

              Regards,
              Bob

              Bob = Moore
              Advanced Design=20 and Technology
              Application Integration Middleware=20 Division
              IBM Software=20 = Group
              +1-919-254-4436
              remoore@us.ibm.com

              3D"""Andrea Westerinen"=20 <andreaw@cisco.com>
              3D"" 3D""=20
                                              "Andrea Westerinen"=20 = <andreaw@cisco.com> =

                                              05/14/02=20 06:28=20 = PM

                      =
              		3D""

              To: = "Policy@Ietf.=20 Org" <policy@ietf.org>, Robert=20 Moore/Raleigh/IBM@IBMUS
              cc:
              Subject:=20 Inconsistencies in QDDIM -07=20 Draft

              In reading QDDIM very closely = :-), I=20 noticed some inconsistencies in the text in Section 3, = in the=20 formal class definitions in Section 4, and in the = intent. Here=20 are my observations and recommendations ...

              1. = For RED=20 droppers, I think that we wanted the following ...
              A=20 REDDropperService can be related to many=20 DropThresholdCalculationServices (many to many), but = each=20 CalculationService examines a single queue (many to=20 one).

              2. This means that ...
              IF you define a=20 DropThresholdCalculationService, you really MUST specify = the=20 queue that is examined. So, CalculationBasedOnQueue = should have=20 a cardinality of 1..1 on the QueuingService side = (currently it=20 has 0..1).
              AND
              A REDDropper MAY be associated = with one or=20 more CalculationServices (each looking at a specific = queue). So,=20 CalculationServiceForDropper should have a cardinality = of 0..n=20 on the DropThresholdCalculationService side (currently = it is a=20 mandatory 1).

              3. For a HeadTailDropperService, = its=20 determinations can also be based on several queues (as = discussed=20 at the bottom of page 23). So, HeadTailDropQueueBinding = should=20 have a cardinality of 1..n for the QueuingService = (currently, it=20 has mandatory 1). I agree that at least queue is = mandatory - but=20 more than one can be examined.

              Andrea =



------=_NextPart_001_0090_01C20718.93377550-- ------=_NextPart_000_008F_01C20718.93377550 Content-Type: image/gif; name="graycol.gif" Content-Transfer-Encoding: base64 Content-ID: <915035320@29052002-23ea> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_008F_01C20718.93377550 Content-Type: image/gif; name="ecblank.gif" Content-Transfer-Encoding: base64 Content-ID: <915035320@29052002-23f1> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_008F_01C20718.93377550 Content-Type: image/gif; name="C4822032.gif" Content-Transfer-Encoding: base64 Content-ID: <915035320@29052002-23f8> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_008F_01C20718.93377550 Content-Type: image/gif; name="C7404108.gif" Content-Transfer-Encoding: base64 Content-ID: <915035320@29052002-23ff> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_008F_01C20718.93377550 Content-Type: image/gif; name="C2019288.gif" Content-Transfer-Encoding: base64 Content-ID: <915035320@29052002-2406> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_008F_01C20718.93377550 Content-Type: image/gif; name="C7643349.gif" Content-Transfer-Encoding: base64 Content-ID: <915035320@29052002-240d> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_008F_01C20718.93377550 Content-Type: image/gif; name="C5094617.gif" Content-Transfer-Encoding: base64 Content-ID: <915035320@29052002-2414> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_008F_01C20718.93377550 Content-Type: image/gif; name="C5695048.gif" Content-Transfer-Encoding: base64 Content-ID: <915035320@29052002-241b> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_008F_01C20718.93377550 Content-Type: image/gif; name="C9166747.gif" Content-Transfer-Encoding: base64 Content-ID: <915035320@29052002-2422> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_008F_01C20718.93377550 Content-Type: image/gif; name="C3220253.gif" Content-Transfer-Encoding: base64 Content-ID: <915035320@29052002-2429> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_008F_01C20718.93377550-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Thu May 30 12:38:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12331 for ; Thu, 30 May 2002 12:38:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18893 for policy-archive@odin.ietf.org; Thu, 30 May 2002 12:39:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18677; Thu, 30 May 2002 12:34:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18644 for ; Thu, 30 May 2002 12:34:41 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12242 for ; Thu, 30 May 2002 12:34:15 -0400 (EDT) From: remoore@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4UGYeFD132582 for ; Thu, 30 May 2002 12:34:40 -0400 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4UGYdV71000 for ; Thu, 30 May 2002 12:34:40 -0400 Subject: [Policy] RE: QDDIM Question To: "Policy@Ietf. Org" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 30 May 2002 12:42:38 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M13TT_05222002 Pre-release 2|May 22, 2002) at 05/30/2002 12:34:39 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBE15ADFC8FDC28f9e8a93df938690918c0ABBE15ADFC8FDC2" Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --0__=0ABBE15ADFC8FDC28f9e8a93df938690918c0ABBE15ADFC8FDC2 Content-type: multipart/alternative; Boundary="1__=0ABBE15ADFC8FDC28f9e8a93df938690918c0ABBE15ADFC8FDC2" --1__=0ABBE15ADFC8FDC28f9e8a93df938690918c0ABBE15ADFC8FDC2 Content-type: text/plain; charset=US-ASCII Well, there was a rare offer here: Andrea and I *both* said that we could go along with any of these three alternatives. But nobody took us up on the offer! Since I have to do something specific in QDDIM, I'm going to go with Andrea's original suggestion, and add a DepthUnits property. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com ----- Forwarded by Robert Moore/Raleigh/IBM on 05/30/02 12:39 PM ----- "Andrea Westerinen" To: Robert Moore/Raleigh/IBM@IBMUS com> Subject: [Policy] RE: QDDIM Question Sent by: policy- admin@ietf.org 05/15/02 10:40 AM I also could live with any of these, but we do have to pick one. The property is not quite usable, as is. Andrea -----Original Message----- From: remoore@us.ibm.com [mailto:remoore@us.ibm.com] Sent: Wednesday, May 15, 2002 7:45 AM To: Andrea Westerinen Cc: Policy@Ietf. Org Subject: Re: QDDIM Question Well, you'd think so, wouldn't you? But then you wonder what it means for an instance of QueuingService to surface this one piece of state information to CIM in, say, bytes, while feeding queue-depth information to a RED dropper that has its thresholds specified in packets. Note that QDDIM says on page 15 that the job of modelling state has really not been done, and hence that this CurrentQueueDepth property is something of an anomaly. So maybe it's OK to have a queue that will only tell *us* its current depth in bytes, yet is perfectly willing to tell a dropper its current depth in packets. I see three choices we might make: - Remove the current depth property from QueuingService, and have it wait for the rest of the state model. - Pick a unit for it, either bytes or packets, and define it to always have that as its unit. - Add a units enum as you suggest. I could live with any of these. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" "Andrea Westerinen To: "Policy@Ietf. Org" " , Robert cc: Subject: QDDIM Question 05/15/02 10:16 AM Don't you need a DepthUnits enum for QueuingService.CurrentQueueDepth as we have in the REDDropperService for the thresholds? Andrea --1__=0ABBE15ADFC8FDC28f9e8a93df938690918c0ABBE15ADFC8FDC2 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Well, there was a rare offer here: Andrea and I *both* said that we could go along with any of these three alternatives. But nobody took us up on the offer!

Since I have to do something specific in QDDIM, I'm going to go with Andrea's original suggestion, and add a DepthUnits property.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com

----- Forwarded by Robert Moore/Raleigh/IBM on 05/30/02 12:39 PM -----



          "Andrea Westerinen" <andreaw@cisco.com>
          Sent by: policy-admin@ietf.org

          05/15/02 10:40 AM



To: Robert Moore/Raleigh/IBM@IBMUS
cc: "Policy@Ietf. Org" <policy@ietf.org>
Subject: [Policy] RE: QDDIM Question


I also could live with any of these, but we do have to pick one. The property is not quite usable, as is.
Andrea
      -----Original Message-----
      From:       remoore@us.ibm.com [mailto:remoore@us.ibm.com]
      Sent:       Wednesday, May 15, 2002 7:45 AM
      To:       Andrea Westerinen
      Cc:       Policy@Ietf. Org
      Subject:       Re: QDDIM Question

      Well, you'd think so, wouldn't you? But then you wonder
      what it means for an instance of QueuingService to
      surface this one piece of state information to CIM in,
      say, bytes, while feeding queue-depth information to a
      RED dropper that has its thresholds specified in packets.
      Note that QDDIM says on page 15 that the job of modelling
      state has really not been done, and hence that this
      CurrentQueueDepth property is something of an anomaly.
      So maybe it's OK to have a queue that will only tell *us*
      its current depth in bytes, yet is perfectly willing to
      tell a dropper its current depth in packets.

      I see three choices we might make:

      - Remove the current depth property from QueuingService,
      and have it wait for the rest of the state model.
      - Pick a unit for it, either bytes or packets, and
      define it to always have that as its unit.
      - Add a units enum as you suggest.

      I could live with any of these.

      Regards,
      Bob

      Bob Moore
      Advanced Design and Technology
      Application Integration Middleware Division
      IBM Software Group
      +1-919-254-4436
      remoore@us.ibm.com

      "Andrea Westerinen" <andreaw@cisco.com>
                      "Andrea Westerinen" <andreaw@cisco.com>

                      05/15/02 10:16 AM



      To: "Policy@Ietf. Org" <policy@ietf.org>, Robert Moore/Raleigh/IBM@IBMUS
      cc:
      Subject: QDDIM Question

      Don't you need a DepthUnits enum for QueuingService.CurrentQueueDepth as we
      have in the REDDropperService for the thresholds?

      Andrea

--1__=0ABBE15ADFC8FDC28f9e8a93df938690918c0ABBE15ADFC8FDC2-- --0__=0ABBE15ADFC8FDC28f9e8a93df938690918c0ABBE15ADFC8FDC2 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <10__=0ABBE15ADFC8FDC28f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15ADFC8FDC28f9e8a93df938690918c0ABBE15ADFC8FDC2 Content-type: image/gif; name="C0344505.gif" Content-Disposition: inline; filename="C0344505.gif" Content-ID: <30__=0ABBE15ADFC8FDC28f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE15ADFC8FDC28f9e8a93df938690918c0ABBE15ADFC8FDC2 Content-type: image/gif; name="C3108155.gif" Content-Disposition: inline; filename="C3108155.gif" Content-ID: <40__=0ABBE15ADFC8FDC28f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15ADFC8FDC28f9e8a93df938690918c0ABBE15ADFC8FDC2 Content-type: image/gif; name="C1893218.gif" Content-Disposition: inline; filename="C1893218.gif" Content-ID: <50__=0ABBE15ADFC8FDC28f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15ADFC8FDC28f9e8a93df938690918c0ABBE15ADFC8FDC2 Content-type: image/gif; name="C9361169.gif" Content-Disposition: inline; filename="C9361169.gif" Content-ID: <60__=0ABBE15ADFC8FDC28f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE15ADFC8FDC28f9e8a93df938690918c0ABBE15ADFC8FDC2-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy