From daemon@optimus.ietf.org Mon Mar 4 10:26: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 KAA28514 for ; Mon, 4 Mar 2002 10:26:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05246 for policy-archive@odin.ietf.org; Mon, 4 Mar 2002 10:26:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04089; Mon, 4 Mar 2002 10:04:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23612 for ; Mon, 4 Mar 2002 07:08:49 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20859; Mon, 4 Mar 2002 07:08:45 -0500 (EST) Message-Id: <200203041208.HAA20859@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: Mon, 04 Mar 2002 07:08:45 -0500 Subject: [Policy] I-D ACTION:draft-ietf-policy-qos-device-info-model-07.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 : Information Model for Describing Network Device QoS Mechanisms Author(s) : B. Moore, D. Durham, J. Strassner, A. Westerinen, W. Weiss, J. Halpern Filename : draft-ietf-policy-qos-device-info-model-07.txt Pages : 90 Date : 01-Mar-02 The purpose of this draft is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the attributes common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services (see [R2475]) and Integrated Services (see [R1633]). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device-info-model-07.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-qos-device-info-model-07.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-qos-device-info-model-07.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: <20020301135529.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-policy-qos-device-info-model-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-policy-qos-device-info-model-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020301135529.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Mon Mar 4 10:28:21 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 KAA28631 for ; Mon, 4 Mar 2002 10:28:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05405 for policy-archive@odin.ietf.org; Mon, 4 Mar 2002 10:28:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04124; Mon, 4 Mar 2002 10:05:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23637 for ; Mon, 4 Mar 2002 07:08:54 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20876; Mon, 4 Mar 2002 07:08:51 -0500 (EST) Message-Id: <200203041208.HAA20876@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: Mon, 04 Mar 2002 07:08:50 -0500 Subject: [Policy] I-D ACTION:draft-ietf-policy-pcim-ext-07.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 et al. Filename : draft-ietf-policy-pcim-ext-07.txt Pages : 86 Date : 01-Mar-02 This document proposes a number of changes to the Policy Core Information Model (PCIM, RFC 3060). These changes include both extensions of PCIM into areas that it did not previously cover, and changes to the existing PCIM classes and associations. Both sets of changes are done in a way that, to the extent possible, preserves interoperability with implementations of the original PCIM model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-policy-pcim-ext-07.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-07.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-07.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: <20020301135544.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-policy-pcim-ext-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-policy-pcim-ext-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020301135544.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Mon Mar 4 11:38: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 LAA01518 for ; Mon, 4 Mar 2002 11:38:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09986 for policy-archive@odin.ietf.org; Mon, 4 Mar 2002 11:38:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08477; Mon, 4 Mar 2002 11:25:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08448 for ; Mon, 4 Mar 2002 11:25:30 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00668 for ; Mon, 4 Mar 2002 11:25:26 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g24GOs426232 for ; Mon, 4 Mar 2002 11:24:54 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g24GOpY22431 for ; Mon, 4 Mar 2002 11:24:51 -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 FYC2BH2Z; Mon, 4 Mar 2002 11:24:49 -0500 Received: from metasolv.com (mpana-1.ca.nortel.com [47.128.213.55]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDK89M4S; Mon, 4 Mar 2002 11:24:52 -0500 Message-ID: <3C83A090.E22C0BE1@metasolv.com> Date: Mon, 04 Mar 2002 11:28:00 -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: IETF Policy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Policy] FilterList and EntriesInFilterList in PCIMe 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 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 From daemon@optimus.ietf.org Tue Mar 5 03:15:55 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 DAA20809 for ; Tue, 5 Mar 2002 03:15:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA16525 for policy-archive@odin.ietf.org; Tue, 5 Mar 2002 03:15:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15233; Tue, 5 Mar 2002 02:55:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15208 for ; Tue, 5 Mar 2002 02:55:20 -0500 (EST) 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 CAA20519 for ; Tue, 5 Mar 2002 02:55:17 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g257sj323432; Mon, 4 Mar 2002 23:54:45 -0800 (PST) Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ABY49334; Mon, 4 Mar 2002 23:54:23 -0800 (PST) From: "Andrea Westerinen" To: , "IETF Policy" , "Wg-Policy@Dmtf. Org" , "Wg-Network@Dmtf. Org" Subject: RE: [Policy] FilterList and EntriesInFilterList in PCIMe Date: Mon, 4 Mar 2002 23:57:40 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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) In-Reply-To: <3C83A090.E22C0BE1@metasolv.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit 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 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 _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Tue Mar 5 17:59:12 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 RAA04917 for ; Tue, 5 Mar 2002 17:59:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA13530 for policy-archive@odin.ietf.org; Tue, 5 Mar 2002 17:59:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12433; Tue, 5 Mar 2002 17:45:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12400 for ; Tue, 5 Mar 2002 17:45:51 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04227 for ; Tue, 5 Mar 2002 17:45:48 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g25MjBQ19330; Tue, 5 Mar 2002 17:45:11 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g25Mj8O24630; Tue, 5 Mar 2002 17:45:08 -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 FYC2GFS4; Tue, 5 Mar 2002 17:45:08 -0500 Received: from metasolv.com (mpana-1.ca.nortel.com [47.128.213.55]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDK893S7; Tue, 5 Mar 2002 17:45:09 -0500 Message-ID: <3C854B31.63F427AC@metasolv.com> Date: Tue, 05 Mar 2002 17:48:17 -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: Andrea Westerinen CC: IETF Policy , "Wg-Policy@Dmtf. Org" , "Wg-Network@Dmtf. Org" Subject: Re: [Policy] FilterList and EntriesInFilterList in PCIMe References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 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. 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. 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 _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Fri Mar 22 11:52:41 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 LAA25950 for ; Fri, 22 Mar 2002 11:52:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15622 for policy-archive@odin.ietf.org; Fri, 22 Mar 2002 11:52:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14775; Fri, 22 Mar 2002 11:36:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14709 for ; Fri, 22 Mar 2002 11:36:43 -0500 (EST) Received: from longmail2.lboard.com ([63.109.116.89]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25536 for ; Fri, 22 Mar 2002 11:36:40 -0500 (EST) Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id <17YLY84P>; Fri, 22 Mar 2002 11:35:17 -0500 Message-ID: From: Ed Ellesson To: "'policy@ietf.org'" Cc: "'Joel Halpern'" , "'Wijnen, Bert (Bert)'" , "'Randy Bush'" Date: Fri, 22 Mar 2002 11:35:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Policy] 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 Working group last call is hereby announced for the document titled "Information Model for Describing Network Device QoS Datapath Mechanisms", which is in the I-D repository at: http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device-info-model- 07.txt This revision reflects all known issues and comments discussed in face-to-face working group meetings and on the working group mailing list. This note commences a two week working group last call, intended to bring forth any last, remaining issues. Please post comments to the list. After any such issues are resolved according to working group consensus, the plan is to submit this document to the IESG for approval as a proposed standard. This working group last call ends at COB on Friday, April 5, 2002. Thanks, 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 Tue Mar 26 10:59: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 KAA08117 for ; Tue, 26 Mar 2002 10:59:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26781 for policy-archive@odin.ietf.org; Tue, 26 Mar 2002 10:59:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19970; Tue, 26 Mar 2002 10:36:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19930 for ; Tue, 26 Mar 2002 10:36:55 -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 KAA07031 for ; Tue, 26 Mar 2002 10:36:52 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2QFaEI27365; Tue, 26 Mar 2002 10:36:14 -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 HLCVY03Q; Tue, 26 Mar 2002 10:36:13 -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 HQL95D8L; Tue, 26 Mar 2002 10:36:14 -0500 Message-ID: <3CA095E9.BEA8749A@metasolv.com> Date: Tue, 26 Mar 2002 10:38:17 -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: Andrea Westerinen , IETF Policy Subject: Re: [Policy] FilterList and EntriesInFilterList in PCIMe References: <3C854B31.63F427AC@metasolv.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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 I haven't received any response to these issues and I'm not quite sure what would be the reason: 1. They don't make any sense at all. Please excuse me! 2. They are still discussed among the authors and a common opinion hasn't been reached yet. 3. They are low priority waiting to be addressed, while other issues are getting the authors attention. 4. They have been missed due to the high quantities of spam mail we are all getting from public mailing lists. Regards, Mircea. 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. > > 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. > > 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 > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Tue Mar 26 23:21: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 XAA07170 for ; Tue, 26 Mar 2002 23:21:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA15022 for policy-archive@odin.ietf.org; Tue, 26 Mar 2002 23:21:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09749; Tue, 26 Mar 2002 22:57:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09719 for ; Tue, 26 Mar 2002 22:57:54 -0500 (EST) Received: from indica.wipsys.stph.net ([203.197.249.146]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06863 for ; Tue, 26 Mar 2002 22:57:49 -0500 (EST) Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.11.6/8.11.6) with SMTP id g2R3uKw09498 for ; Wed, 27 Mar 2002 09:26:20 +0530 (IST) Received: from wipro.com ([192.168.143.56]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GTM5NF00.79Z for ; Wed, 27 Mar 2002 09:27:15 +0530 Message-ID: <3CA14346.E6D9E84B@wipro.com> Date: Wed, 27 Mar 2002 09:27:58 +0530 From: "Krishna Prasad Akkineni" Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,ja MIME-Version: 1.0 To: IETF Policy Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-f0ed2c9f-412c-11d6-84a5-0000e2293f7c" Subject: [Policy] Applicability of threshold values 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. ------=_NextPartTM-000-f0ed2c9f-412c-11d6-84a5-0000e2293f7c Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, This is a query about congestion control properties of draft-ietf-policy-qos-info-model-04.txt. (QoS Info model) Are the properties qpDropThresholdUnits, qpDropMinThresholdValue and qpDropMaxThresholdValue applicable *ONLY* for random-drop algorithm? Are not those properties relavent for tail-drop or head-drop also? Following is a related exerpt from the I-D: 3.4.2 Congestion Control Actions The QoSPolicyCongestionControlAction class controls queue length, thresholds and congestion control algorithms. A PEP should be able to keep in its queues qpQueueSize packets matching the rule's condition. In order to provide a link-speed independent queue size, the qpQueueSize property can also be measured in milliseconds. The time interval specifies the time needed to transmit all packets within the queue if the link speed is dedicated entirely for transmission of packets within this queue. The property qpQueueSizeUnit determines whether queue size is measured in number of packets or in milliseconds. The property qpDropMethod selects either tail-drop, head-drop or random- drop algorithms. The set of maximum and minimum threshold values can be specified as well, using qpDropMinThresholdValue and qpDropMaxThresholdValue properties, either in packets or in percentage of the total available queue size as specified by the qpDropThresholdUnits property. Thanks & Regards Krishna ------=_NextPartTM-000-f0ed2c9f-412c-11d6-84a5-0000e2293f7c Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ***************************************************************************** ------=_NextPartTM-000-f0ed2c9f-412c-11d6-84a5-0000e2293f7c-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Thu Mar 28 04:22:11 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 EAA19660 for ; Thu, 28 Mar 2002 04:22:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA03083 for policy-archive@odin.ietf.org; Thu, 28 Mar 2002 04:22:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02692; Thu, 28 Mar 2002 04:14:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02665 for ; Thu, 28 Mar 2002 04:14:11 -0500 (EST) Received: from smtp2.enst.fr (matrix2.enst.fr [137.194.2.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19551 for ; Thu, 28 Mar 2002 04:14:07 -0500 (EST) Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by smtp2.enst.fr (Postfix) with ESMTP id 2CD611EF15 for ; Thu, 28 Mar 2002 10:14:10 +0100 (MET) Received: from lppro01 (dhcp26-109.enst.fr [137.194.26.109] (may be forged)) by email.enst.fr (8.9.3/8.9.3) with SMTP id KAA07125 for ; Thu, 28 Mar 2002 10:14:10 +0100 (MET) Reply-To: From: "cherkaoui omar" To: Date: Thu, 28 Mar 2002 04:12:28 -0500 Message-ID: <000a01c1d638$afc6ab70$6d1ac289@lppro01> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Policy] Net-con 2002 conference with focus on Policy-based Networking 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 (Please accept our apologies if you receive duplicates of this message) CALL FOR PAPERS AND TUTORIALS Net-Con'2002 Network Control and Engineering for QoS, Security and Mobility with focus on Policy-based Networking IFIP and IEEE Conference The intention of the conference is to provide a forum for the exchange of ideas and findings in a wide range of areas related to network control and network engineering with a focus on QoS, security and mobility control. Suggested topics for papers include,but are not limited to, the following: QoS Policy-based management architecture Programmable network and Active networks Intelligent agent QoS Control and QoS Engineering Traffic measurements and monitoring,Traffic engineering in converging networks Traffic modeling and simulation Quality of Service provisioning, Network planning and optimization Process, methodologies, and tools for network control Policy models for system management, Provisioning of policies Policy frameworks for active networks, mobile systems, e-commerce Integrating policies into existing systems and environments Business rules and organizational control Extensions and refinements to policy standards Distributed game control Case studies of applying policy-based technologies Security Security control and Security engineering AAA Configurable security policies Cryptography protocols Policy models for security Distributed trusted infrastructure Water marking for flow control Mobility Mobility control and mobility engineering Policy models for mobility Virtual Home Environment (VHE) Pervasive/ubiquitous/wearable mobile systems Security and privacy issues for mobile and wireless systems Mobility and QoS management Control schemes in ad-hoc networks Personal area networks QoS and security IEEE 802.11 engineering Smart devices Smart cards, security and mobility Important deadlines: April 26, 2002 Papers due May 10, 2002 Tutorials, panel proposals due June 15, 2002 Authors notified of acceptance July 15, 2002 Final papers due Submission: Submissions should be original and 10-15 pages in length. Authors are requested to submit their manuscripts electronically as a Microsoft Word document, a PDF document,or in Postscript format. The proceedings of the conference will be published by Kluwer. Information: http://net-con.utt.fr/netcon/index.html email information@net-con.org _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Fri Mar 29 02:11:19 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 CAA05977 for ; Fri, 29 Mar 2002 02:11:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA21026 for policy-archive@odin.ietf.org; Fri, 29 Mar 2002 02:11:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20823; Fri, 29 Mar 2002 02:02:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20785 for ; Fri, 29 Mar 2002 02:02:36 -0500 (EST) Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01010 for ; Fri, 29 Mar 2002 02:02:32 -0500 (EST) Received: from RONC (62.0.182.43) by mail.san.yahoo.com (6.5.017.1) id 3CA3697800028181; Thu, 28 Mar 2002 23:01:51 -0800 From: "Ron Cohen" To: "'Krishna Prasad Akkineni'" , "'IETF Policy'" Subject: RE: [Policy] Applicability of threshold values Date: Fri, 29 Mar 2002 09:01:01 +0200 Message-ID: <000001c1d6ef$7f967860$6401010a@RONC> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3CA14346.E6D9E84B@wipro.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit 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 Krishna, > This is a query about congestion control > properties of draft-ietf-policy-qos-info-model-04.txt. > (QoS Info model) > > Are the properties qpDropThresholdUnits, > qpDropMinThresholdValue and qpDropMaxThresholdValue > applicable *ONLY* for random-drop algorithm? > Are not those properties relavent for tail-drop or head-drop also? These properties are relevant to head-drop and tail-drop algorithms as well. Please see example within section 3.4.3 Regards Ron > Following is a related exerpt from the I-D: > 3.4.2 Congestion Control Actions > The QoSPolicyCongestionControlAction class controls queue length, > thresholds and congestion control algorithms. > A PEP should be able to keep in its queues qpQueueSize > packets matching > the rule's condition. In order to provide a link-speed > independent queue > size, the qpQueueSize property can also be measured in > milliseconds. The > time interval specifies the time needed to transmit all > packets within > the queue if the link speed is dedicated entirely for transmission of > packets within this queue. The property qpQueueSizeUnit determines > whether queue size is measured in number of packets or in > milliseconds. > > The property qpDropMethod selects either tail-drop, head-drop > or random- > drop algorithms. The set of maximum and minimum threshold > values can be > specified as well, using qpDropMinThresholdValue and > qpDropMaxThresholdValue properties, either in packets or in > percentage > of the total available queue size as specified by the > qpDropThresholdUnits property. > > Thanks & Regards > Krishna > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy