From majordomo@raleigh.ibm.com  Fri Dec  1 00:15:31 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15045
	for <policy-archive@odin.ietf.org>; Fri, 1 Dec 2000 00:15:31 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA18584;
	Fri, 1 Dec 2000 00:00:52 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id XAA17334;
	Thu, 30 Nov 2000 23:58:10 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA27628; Thu, 30 Nov 2000 11:11:14 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA33252; Thu, 30 Nov 2000 11:11:10 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA22012
	for <policy@raleigh.ibm.com>; Thu, 30 Nov 2000 11:11:18 -0500
Received: from mailmaestro.smartpipes.com (mailmaestro.smartpipes.com [63.98.224.170])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA17290
	for <policy@raleigh.ibm.com>; Thu, 30 Nov 2000 11:11:11 -0500
Received: by mailmaestro.smartpipes.com with Internet Mail Service (5.5.2650.21)
	id <XYCWAQA2>; Thu, 30 Nov 2000 16:10:53 -0000
Message-Id: <8E1E94178828D143B34A560A7A6F2C0B01A6A0F1@mailmaestro.smartpipes.com>
From: "Quevedo, Felix" <FQuevedo@smartpipes.com>
To: "'Larry S. Bartz'" <lbartz@parnelli.indy.cr.irs.gov>,
        IETF Policy WG LIST <policy@raleigh.ibm.com>
Cc: "LIST, DEN discussion" <dir-nets@andrew.cmu.edu>, chair-den@dmtf.org,
        chair-ldap@dmtf.org, chair-network@dmtf.org, cim-support@dmtf.org
Subject: RE: CIM24 schema tweaks
Date: Thu, 30 Nov 2000 16:10:49 -0000
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Quevedo, Felix" <FQuevedo@smartpipes.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA15045


In the same DSP0117 spec there is also an issue with DITContentRules. It
uses the MAY term to indicate that an entry "may attach" an auxiliary class.
Per ye olde ITU X.501, the AUX term may be more appropriate, as done in
DSP0101. Or maybe not?

Then again, IETF RFC 2252 does not detail a ditContentRules BNF.
Félix E Quevedo
? Smile, everything is possible!
E-Mail: fquevedo@smartpipes.com
Voice: 614 923 6242
Fax: 614 923 6299

 -----Original Message-----
From: 	Larry S. Bartz [mailto:lbartz@parnelli.indy.cr.irs.gov] 
Sent:	Thursday, November 30, 2000 07:42
To:	IETF Policy WG LIST
Cc:	LIST, DEN discussion; chair-den@dmtf.org; chair-ldap@dmtf.org;
chair-network@dmtf.org; cim-support@dmtf.org
Subject:	CIM24 schema tweaks

 << File: tweakedCIM24schema.txt >> My previous message on this subject was
mishandled by my mailer,
resulting in severe truncation. Here's a retry:

I have encountered some difficulties implementing the CIM v2.4 
schema, as described in the DSP0117 documents at
http://www.dmtf.org/spec/denh.html .

Since the IETF Policy WG's draft-ietf-policy-core-schema-08.txt depends 
upon the cim24 schema, experimental implementers of "schema-08" may find 
the following comments and attached edited ABNF helpful.

I am also sharing these comments with the DMTF's WG chairs and CIM
support e-mail addresses. I request that these comments be forwarded
to the appropriate individuals for review.

 - DESC - Some Directory products enforce a length limit on the 
   DESC terms of objectclass and attributeType descriptions. X.501 
   defines the limit as {ub-schema}. Annex C of X.520 defines
   {ub-schema} as 1024. DESC term values which exceed 1024 characters 
   violate this limit. Several of the descriptions in DSP0117 contain 
   DESC term values which exceed 1024 characters in length. 

 - Matching Rules - Many of the attribute descriptions in DSP0117 
   have no matching rule terms specified. The attachment nominates 
   matching rule terms where appropriate, with comments designated by 
   #LSB.

 - Unspecified Attributes - Several attribute types are nominated by
   objectClass descriptions but which have not been defined. These
   include three whose names begin with "dlmHelperRefTo...". Based on 
   a presumption that other previously-defined attributes were intended, 
   the attachment substitutes defined attribute names for those which 
   are not defined, with comments designated by #LSB.

 - Forward references precluded - The attachment relocates entries 
   in the file to avoid forward references.

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|


From majordomo@raleigh.ibm.com  Fri Dec  1 10:32:21 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20866
	for <policy-archive@odin.ietf.org>; Fri, 1 Dec 2000 10:32:20 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA07356;
	Fri, 1 Dec 2000 10:21:02 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA41850;
	Fri, 1 Dec 2000 10:20:56 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA50168; Fri, 1 Dec 2000 09:56:24 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA63960; Fri, 1 Dec 2000 09:56:19 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA43066
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 09:56:23 -0500
Received: from mailmaestro.smartpipes.com (mailmaestro.smartpipes.com [63.98.224.170])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA24836
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 09:56:21 -0500
Received: by mailmaestro.smartpipes.com with Internet Mail Service (5.5.2650.21)
	id <XYCWASCB>; Fri, 1 Dec 2000 14:55:24 -0000
Message-Id: <8E1E94178828D143B34A560A7A6F2C0B01A6A0FA@mailmaestro.smartpipes.com>
From: "Quevedo, Felix" <FQuevedo@smartpipes.com>
To: "'Larry S. Bartz'" <lbartz@parnelli.indy.cr.irs.gov>,
        IETF Policy WG LIST <policy@raleigh.ibm.com>
Cc: "LIST, DEN discussion" <dir-nets@andrew.cmu.edu>, chair-den@dmtf.org,
        chair-ldap@dmtf.org, chair-network@dmtf.org, cim-support@dmtf.org
Subject: RE: CIM24 schema tweaks
Date: Fri, 1 Dec 2000 14:55:19 -0000 
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Quevedo, Felix" <FQuevedo@smartpipes.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA20866

Larry,

It looks like the dlmHelperRefTo... should actually be: dlm...HelperRef.
This must have happen when applying a "new" naming convention to the
attributes type descriptions, but did not to modify their references in the
object class descriptions.

Can the DMTF team confirm this?
Félix E Quevedo
? Smile, everything is possible!
E-Mail: fquevedo@smartpipes.com
Voice: 614 923 6242
Fax: 614 923 6299

 -----Original Message-----
From: 	Larry S. Bartz [mailto:lbartz@parnelli.indy.cr.irs.gov] 
Sent:	Thursday, November 30, 2000 07:42
To:	IETF Policy WG LIST
Cc:	LIST, DEN discussion; chair-den@dmtf.org; chair-ldap@dmtf.org;
chair-network@dmtf.org; cim-support@dmtf.org
Subject:	CIM24 schema tweaks

 << File: tweakedCIM24schema.txt >> My previous message on this subject was
mishandled by my mailer,
resulting in severe truncation. Here's a retry:

I have encountered some difficulties implementing the CIM v2.4 
schema, as described in the DSP0117 documents at
http://www.dmtf.org/spec/denh.html .

Since the IETF Policy WG's draft-ietf-policy-core-schema-08.txt depends 
upon the cim24 schema, experimental implementers of "schema-08" may find 
the following comments and attached edited ABNF helpful.

I am also sharing these comments with the DMTF's WG chairs and CIM
support e-mail addresses. I request that these comments be forwarded
to the appropriate individuals for review.

 - DESC - Some Directory products enforce a length limit on the 
   DESC terms of objectclass and attributeType descriptions. X.501 
   defines the limit as {ub-schema}. Annex C of X.520 defines
   {ub-schema} as 1024. DESC term values which exceed 1024 characters 
   violate this limit. Several of the descriptions in DSP0117 contain 
   DESC term values which exceed 1024 characters in length. 

 - Matching Rules - Many of the attribute descriptions in DSP0117 
   have no matching rule terms specified. The attachment nominates 
   matching rule terms where appropriate, with comments designated by 
   #LSB.

 - Unspecified Attributes - Several attribute types are nominated by
   objectClass descriptions but which have not been defined. These
   include three whose names begin with "dlmHelperRefTo...". Based on 
   a presumption that other previously-defined attributes were intended, 
   the attachment substitutes defined attribute names for those which 
   are not defined, with comments designated by #LSB.

 - Forward references precluded - The attachment relocates entries 
   in the file to avoid forward references.

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|


From majordomo@raleigh.ibm.com  Fri Dec  1 10:39:02 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21620
	for <policy-archive@odin.ietf.org>; Fri, 1 Dec 2000 10:39:02 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA35704;
	Fri, 1 Dec 2000 10:23:06 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA43912;
	Fri, 1 Dec 2000 10:20:59 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA57884; Fri, 1 Dec 2000 09:49:42 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA39956; Fri, 1 Dec 2000 09:49:39 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA31748
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 09:49:43 -0500
Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA32140
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 09:49:40 -0500
Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id eB1EolE54814;
	Fri, 1 Dec 2000 15:50:47 +0100 (CET)
Received: from ccrle.nec.de (santiago.heidelberg.ccrle.nec.de [192.168.102.117])
	by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA04016;
	Fri, 1 Dec 2000 15:50:01 +0100
Message-Id: <3A266763.2A2CCCB0@ccrle.nec.de>
Date: Thu, 30 Nov 2000 15:42:43 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Organization: NEC Europe Ltd
X-Mailer: Mozilla 4.72 [en] (Win98; I)
X-Accept-Language: en,de
Mime-Version: 1.0
To: Yoram Snir <ysnir@cisco.com>
Cc: "'Policy Mailing List' (E-mail)" <policy@raleigh.ibm.com>
Subject: Re: QoS Policy Information Model draft
References: <001c01c05aac$3ae14350$ab5afe90@ysnirnt70>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Marcus Brunner <brunner@ccrle.nec.de>
Content-Transfer-Encoding: 7bit

Yoram,

I have some questions and comments (see inline)

Yoram Snir wrote:
[...]

> 1. Some of the classes defined in QPIM are intended for usage outside the
> scope of QoS domain. The concept of conditions as building blocks of
> filters, the basic condition structure of <variable operator value>, the
> concept of variable binding and the concept of variable to
> value relationship are valuable to domains out side QoS policy. In order to
> allow more natural usage of these concept in other domains, the relevant
> classes prefix was changed from qosPolicyXXX to gpsPolicyXXX and properties
> prefix was changed from qpPolicyXXX to
> gpPolicy ,i.e., general policy XXX.
>

This is a grewat idea. We have to talk about what to do with this
calsses in SD.
 
> 2. The notion of a class representing a filter or a Boolean expression made
> of policy conditions, that could also serve as a reusable filter was added.
> The class gpsPolicyCompoundCondition allows the definition of a flexible
> reusable filter, leveraging the mechanism defined in CPIM for associating
> policy conditions to a policy rule .
>

I do not understand, why you added this condition. I see no additional
value. Do you want to group conditions, representing a packet filter,
together for reuse and easier handling?

> 3. This draft was updated to be compatible with the latest PCIM draft.
> 
> 4. PHB Actions added to allow full coverage of the QoS policy model required
> for definition of policies for a differential service domain. References to
> external PHB definitions removed.
> 
> 5. Alignment between policy definition of QPIM and low level PIB / MIB Was
> illustrated.
> 
> 6. Reuse of Policy groups and their QPIM extensions, gpsPolicyGroups and
> Policy rules were explained and examples were added.
>
 
Rule nesting
What is the semantic of the PolicyRuleinPolicyRule aggregation?
Basically, I do not see the execution semantic. I have the feeling this
concept will run us in problems implementing it properly (defined
semantic)
Why is ordered grouping of rules not sufficient?

Rule Decsision Strategy
Why do we need another method additional to conditions and roles to
decide, whether a rule is applied/executed?

Is the semantic of the priority value of the policy rule really defined
within a container in PCIM? I have not found this in the lasted PCIM
draft.

> 7. Role usage in the context of QoS policy was explained. No new concepts
> were introduced. Role were also defined per gpsPolicyGroups.

What do we gain having roles in the policy group, and each group and
rule will inherite the role from its container? Form the execution point
of view, this should be the other way around. A policy groups role
property should contain all roles and role combinations from the rules
and groups contained in the specific group.

> 
> 8. Change gpsPolicyMeter to include a traffic profile and scope. The
> previous way of binding the meter the traffic profile and a scope using a
> provisioning action could lead to inconsistencies if not used properly.
> 
> 9. Clarification of the use of gpValueTypes property of values and the
> meaning of table 3.
> 
> 10. Rewriting the draft in a storage independent way. The previous draft was
> not general enough. Added appropriate association and aggregations and
> removed references from objects. Changed text
> appropriately.
> 
> 11. qpsNamedPolicyContainer class name was changes to gpsPolicyGroup to
> allow for usage outside the scope of QoS domain.
> 
> The draft is available in via ftp (util the ietf repository updates):
> ftp ftpeng.cisco.com.
> user: anonymous
> cd ietf-policy-wg (under login dir)
> get draft-ietf-policy-qos-info-model-02.txt
> 
> Enjoy
> 
> Yoram Snir

-- 

Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155


From majordomo@raleigh.ibm.com  Fri Dec  1 11:06:56 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01045
	for <policy-archive@odin.ietf.org>; Fri, 1 Dec 2000 11:06:53 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA25488;
	Fri, 1 Dec 2000 10:57:54 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA44806;
	Fri, 1 Dec 2000 10:57:52 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA69526; Fri, 1 Dec 2000 10:28:49 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA42126; Fri, 1 Dec 2000 10:28:45 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA34840
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 10:28:46 -0500
Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA26618
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 10:28:21 -0500
Received: from ysnirnt70 (ysnir-isdn-home.cisco.com [10.49.112.178])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id RAA06397;
	Fri, 1 Dec 2000 17:27:47 +0200 (IST)
From: "Yoram Snir" <ysnir@cisco.com>
To: <brunner@ccrle.nec.de>
Cc: "''Policy Mailing List' \(E-mail\)'" <policy@raleigh.ibm.com>
Subject: RE: QoS Policy Information Model draft
Date: Fri, 1 Dec 2000 17:25:43 +0200
Message-Id: <004501c05baa$f8e06f80$b270310a@ysnirnt70>
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 8.5, Build 4.71.2173.0
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
In-Reply-To: <3A266763.2A2CCCB0@ccrle.nec.de>
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Yoram Snir" <ysnir@cisco.com>
Content-Transfer-Encoding: 7bit

Marcus please see in line.

Yoram Snir

> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de]
> Sent: Thursday, November 30, 2000 4:43 PM
> To: Yoram Snir
> Cc: 'Policy Mailing List' (E-mail)
> Subject: Re: QoS Policy Information Model draft
>
>
> Yoram,
>
> I have some questions and comments (see inline)
>
> Yoram Snir wrote:
> [...]
>
> > 1. Some of the classes defined in QPIM are intended for
> usage outside the
> > scope of QoS domain. The concept of conditions as building blocks of
> > filters, the basic condition structure of <variable
> operator value>, the
> > concept of variable binding and the concept of variable to
> > value relationship are valuable to domains out side QoS
> policy. In order to
> > allow more natural usage of these concept in other domains,
> the relevant
> > classes prefix was changed from qosPolicyXXX to
> gpsPolicyXXX and properties
> > prefix was changed from qpPolicyXXX to
> > gpPolicy ,i.e., general policy XXX.
> >
>
> This is a grewat idea. We have to talk about what to do with this
> calsses in SD.
>
OK

> > 2. The notion of a class representing a filter or a Boolean
> expression made
> > of policy conditions, that could also serve as a reusable
> filter was added.
> > The class gpsPolicyCompoundCondition allows the definition
> of a flexible
> > reusable filter, leveraging the mechanism defined in CPIM
> for associating
> > policy conditions to a policy rule .
> >
>
> I do not understand, why you added this condition. I see no additional
> value. Do you want to group conditions, representing a packet filter,
> together for reuse and easier handling?

Exactly, the only way you could reuse a group of condition with specific
semantics is by adding this class. For example condition A and not
ConditionB. It doesn't have to be a packet filter, how about:
(URL = *.jpg or URL = *.gif) to represent HTML GETS  of pictures?

>
> > 3. This draft was updated to be compatible with the latest
> PCIM draft.
> >
> > 4. PHB Actions added to allow full coverage of the QoS
> policy model required
> > for definition of policies for a differential service
> domain. References to
> > external PHB definitions removed.
> >
> > 5. Alignment between policy definition of QPIM and low
> level PIB / MIB Was
> > illustrated.
> >
> > 6. Reuse of Policy groups and their QPIM extensions,
> gpsPolicyGroups and
> > Policy rules were explained and examples were added.
> >
>
> Rule nesting
> What is the semantic of the PolicyRuleinPolicyRule aggregation?
> Basically, I do not see the execution semantic. I have the
> feeling this
> concept will run us in problems implementing it properly (defined
> semantic)
> Why is ordered grouping of rules not sufficient?

Please see explanation and example in the draft, it illustrates the order of
grouping and rules, and how the combination works.
>
> Rule Decsision Strategy
> Why do we need another method additional to conditions and roles to
> decide, whether a rule is applied/executed?

It has to do with the usage of orders in groups and rules and explained in
the same section. In general you might want to have a "first match" on the
groups of rules, an a "match all in the group itself". Remember that sub
rules are allowed.

>
> Is the semantic of the priority value of the policy rule
> really defined
> within a container in PCIM? I have not found this in the lasted PCIM
> draft.

It should be, will check.

>
> > 7. Role usage in the context of QoS policy was explained.
> No new concepts
> > were introduced. Role were also defined per gpsPolicyGroups.
>
> What do we gain having roles in the policy group, and each group and
> rule will inherite the role from its container? Form the
> execution point
> of view, this should be the other way around. A policy groups role
> property should contain all roles and role combinations from the rules
> and groups contained in the specific group.

I disagree, roles are used by policy engines to pick which rules are
applicable to them and should be acted on. So if a rule is defined for
special case and has a special role, the group or sub rule containing it and
other rules should not be effected.
We should talk more in SD.
>
> >
> > 8. Change gpsPolicyMeter to include a traffic profile and scope. The
> > previous way of binding the meter the traffic profile and a
> scope using a
> > provisioning action could lead to inconsistencies if not
> used properly.
> >
> > 9. Clarification of the use of gpValueTypes property of
> values and the
> > meaning of table 3.
> >
> > 10. Rewriting the draft in a storage independent way. The
> previous draft was
> > not general enough. Added appropriate association and
> aggregations and
> > removed references from objects. Changed text
> > appropriately.
> >
> > 11. qpsNamedPolicyContainer class name was changes to
> gpsPolicyGroup to
> > allow for usage outside the scope of QoS domain.
> >
> > The draft is available in via ftp (util the ietf repository
> updates):
> > ftp ftpeng.cisco.com.
> > user: anonymous
> > cd ietf-policy-wg (under login dir)
> > get draft-ietf-policy-qos-info-model-02.txt
> >
> > Enjoy
> >
> > Yoram Snir
>
> --
>
> Dr. Marcus Brunner
> C&C Research Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.tik.ee.ethz.ch/~brunner
>
> Adenauerplatz 6
> D-69115 Heidelberg
> Germany
>
> Phone: +49 (0)6221/ 9051129
> Fax:   +49 (0)6221/ 9051155
>



From majordomo@raleigh.ibm.com  Fri Dec  1 11:42:12 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12189
	for <policy-archive@odin.ietf.org>; Fri, 1 Dec 2000 11:42:08 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA25554;
	Fri, 1 Dec 2000 11:27:50 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA38210;
	Fri, 1 Dec 2000 11:27:47 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA32266; Fri, 1 Dec 2000 11:00:07 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA51932; Fri, 1 Dec 2000 11:00:01 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA32358
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 11:00:05 -0500
Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA30254
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 10:59:46 -0500
Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id eB1G0YE56810;
	Fri, 1 Dec 2000 17:00:34 +0100 (CET)
Received: from imap.heidelberg.ccrle.nec.de (postfix@imap.heidelberg.ccrle.nec.de [192.168.102.7])
	by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA04596;
	Fri, 1 Dec 2000 16:59:47 +0100
Received: by imap.heidelberg.ccrle.nec.de (Postfix, from userid 30)
	id 960C67DC9; Fri,  1 Dec 2000 18:59:19 +0100 (CET)
From: Marcus Brunner <brunner@ccrle.nec.de>
To: ysnir@cisco.com, Yoram Snir <ysnir@cisco.com>
Cc: brunner@ccrle.nec.de,
        "''Policy Mailing List' (E-mail)'" <policy@raleigh.ibm.com>
References: <004501c05baa$f8e06f80$b270310a@ysnirnt70>
In-Reply-To: <004501c05baa$f8e06f80$b270310a@ysnirnt70>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: IMP/PHP3 Imap webMail Program 2.0.9
Subject: RE: QoS Policy Information Model draft
Message-Id: <20001201175919.960C67DC9@imap.heidelberg.ccrle.nec.de>
Date: Fri,  1 Dec 2000 18:59:19 +0100 (CET)
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Marcus Brunner <brunner@ccrle.nec.de>
Content-Transfer-Encoding: 7bit

Yoram,

Quoting Yoram Snir <ysnir@cisco.com>:

[...]

> > > 2. The notion of a class representing a filter or a Boolean
> > expression made
> > > of policy conditions, that could also serve as a reusable
> > filter was added.
> > > The class gpsPolicyCompoundCondition allows the definition
> > of a flexible
> > > reusable filter, leveraging the mechanism defined in CPIM
> > for associating
> > > policy conditions to a policy rule .
> > >
> >
> > I do not understand, why you added this condition. I see no additional
> > value. Do you want to group conditions, representing a packet filter,
> > together for reuse and easier handling?
> 
> Exactly, the only way you could reuse a group of condition with specific
> semantics is by adding this class. For example condition A and not
> ConditionB. It doesn't have to be a packet filter, how about:
> (URL = *.jpg or URL = *.gif) to represent HTML GETS  of pictures?

So basically it is a condition group, like a group of rules (gpsPolicyGroup), 
should there be the same for action groups?

> 
> >
> > > 3. This draft was updated to be compatible with the latest
> > PCIM draft.
> > >
> > > 4. PHB Actions added to allow full coverage of the QoS
> > policy model required
> > > for definition of policies for a differential service
> > domain. References to
> > > external PHB definitions removed.
> > >
> > > 5. Alignment between policy definition of QPIM and low
> > level PIB / MIB Was
> > > illustrated.
> > >
> > > 6. Reuse of Policy groups and their QPIM extensions,
> > gpsPolicyGroups and
> > > Policy rules were explained and examples were added.
> > >
> >
> > Rule nesting
> > What is the semantic of the PolicyRuleinPolicyRule aggregation?
> > Basically, I do not see the execution semantic. I have the
> > feeling this
> > concept will run us in problems implementing it properly (defined
> > semantic)
> > Why is ordered grouping of rules not sufficient?
> 
> Please see explanation and example in the draft, it illustrates the order
> of
> grouping and rules, and how the combination works.

So lets try, if I understand it correct.

We have three rules R1,R2, and R3, with conditions C1,C2, C3, and actions A1, 
A2, A3. R2 and R3 are associated to R1.

So if C1 is true perform A1 and evalute rules R2 and R3
                if C2 is true then perform A2
                if C2 is false then (stop of evalute R3 ??? -> define 
sequential or paralell evaluation of the rules)
if C1 is false do nothing

What is the difference to the three rules?
IF C1 THEN A1
IF C1 AND C2 THEN A2
IF C1 AND C3 THEN A3

What is the context of the evaluation of R2, R3? Same as R1? Global?
Is the semantic the same as if one would model it with a EvaluationAction?

> >
> > Rule Decsision Strategy
> > Why do we need another method additional to conditions and roles to
> > decide, whether a rule is applied/executed?
> 
> It has to do with the usage of orders in groups and rules and explained in
> the same section. In general you might want to have a "first match" on the
> groups of rules, an a "match all in the group itself". Remember that sub
> rules are allowed.
> 
> >
> > Is the semantic of the priority value of the policy rule
> > really defined
> > within a container in PCIM? I have not found this in the lasted PCIM
> > draft.
> 
> It should be, will check.
> 
> >
> > > 7. Role usage in the context of QoS policy was explained.
> > No new concepts
> > > were introduced. Role were also defined per gpsPolicyGroups.
> >
> > What do we gain having roles in the policy group, and each group and
> > rule will inherite the role from its container? Form the
> > execution point
> > of view, this should be the other way around. A policy groups role
> > property should contain all roles and role combinations from the rules
> > and groups contained in the specific group.
> 
> I disagree, roles are used by policy engines to pick which rules are
> applicable to them and should be acted on. So if a rule is defined for
> special case and has a special role, the group or sub rule containing it
> and
> other rules should not be effected.
> We should talk more in SD.

As you said, basically a role helps to implement a policy engine more efficent, 
because only rules which a written for a particular role are evaluated. But if 
the engine has to check for all roles of all rules in a group you have nothing 
gained. So what is the role property in the policyGroup for?

Marcus



Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155


From majordomo@raleigh.ibm.com  Fri Dec  1 14:14:46 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27179
	for <policy-archive@odin.ietf.org>; Fri, 1 Dec 2000 14:14:45 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA31954;
	Fri, 1 Dec 2000 13:58:13 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA34612;
	Fri, 1 Dec 2000 13:58:12 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA55260; Fri, 1 Dec 2000 13:26:22 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA33982; Fri, 1 Dec 2000 13:26:17 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA35784
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 13:26:18 -0500
Received: from mx-relay1.treas.gov (mx-relay1.treas.gov [199.196.144.5])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA37574
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 13:26:14 -0500
Received: from tias4.treas.gov (tias-gw4.treas.gov [199.196.144.14])
	by mx-relay1.treas.gov (8.9.1b+Sun/8.9.3) with SMTP id NAA04971;
	Fri, 1 Dec 2000 13:26:32 -0500 (EST)
Received: from mailhub.net.treas.gov by tias4.treas.gov
          via smtpd (for mx-relay.treas.gov [199.196.144.5]) with SMTP; 1 Dec 2000 18:26:32 UT
Received: from mears.indy.cr.irs.gov (mailhub-3.net.treas.gov [10.7.8.11])
	by mailhub-3.net.treas.gov (8.9.3+Sun/8.9.3) with ESMTP id NAA18403;
	Fri, 1 Dec 2000 13:24:40 -0500 (EST)
Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1])
	by mears.indy.cr.irs.gov (8.9.3/8.9.3) with ESMTP id NAA04566;
	Fri, 1 Dec 2000 13:26:24 -0500
Message-Id: <3A27ED50.A870B878@parnelli.indy.cr.irs.gov>
Date: Fri, 01 Dec 2000 13:26:24 -0500
From: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686)
X-Accept-Language: en
Mime-Version: 1.0
To: "Quevedo, Felix" <FQuevedo@smartpipes.com>
Cc: IETF Policy WG LIST <policy@raleigh.ibm.com>,
        "LIST, DEN discussion" <dir-nets@andrew.cmu.edu>, chair-den@dmtf.org,
        chair-ldap@dmtf.org, chair-network@dmtf.org, cim-support@dmtf.org
Subject: Re: CIM24 schema tweaks
References: <8E1E94178828D143B34A560A7A6F2C0B01A6A0FA@mailmaestro.smartpipes.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
Content-Transfer-Encoding: 7bit

"Quevedo, Felix" wrote:
> 
> Larry,
> 
> It looks like the dlmHelperRefTo... should actually be: dlm...HelperRef.
> This must have happen when applying a "new" naming convention to the
> attributes type descriptions, but did not to modify their references in the
> object class descriptions.
> 
> Can the DMTF team confirm this?

I guessed the same. I substituted the dlm...HelperRef attrs in the 
attachment to my initial message.

I've spotted another potential difficulty with the schema of DSP0117.

See this description:

attributetype    ( 1.3.6.1.4.1.412.100.1.2.1
     NAME 'orderedCimKeys'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE
     EQUALITY octetStringMatch
   )

The matching rule syntax does not match the attribute's syntax. This 
must be corrected.


--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|


From majordomo@raleigh.ibm.com  Fri Dec  1 15:32:36 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15179
	for <policy-archive@odin.ietf.org>; Fri, 1 Dec 2000 15:32:34 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA25374;
	Fri, 1 Dec 2000 14:54:57 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA34714;
	Fri, 1 Dec 2000 14:54:57 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA63856; Fri, 1 Dec 2000 14:34:15 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA51304; Fri, 1 Dec 2000 14:34:11 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA27732
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 14:34:11 -0500
Received: from mx-relay1.treas.gov (mx-relay1.treas.gov [199.196.144.5])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA31512
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 14:34:04 -0500
Received: from tias4.treas.gov (tias-gw4.treas.gov [199.196.144.14])
	by mx-relay1.treas.gov (8.9.1b+Sun/8.9.3) with SMTP id OAA05991;
	Fri, 1 Dec 2000 14:33:32 -0500 (EST)
Received: from mailhub.net.treas.gov by tias4.treas.gov
          via smtpd (for mx-relay.treas.gov [199.196.144.5]) with SMTP; 1 Dec 2000 19:33:32 UT
Received: from mears.indy.cr.irs.gov (mailhub-3.net.treas.gov [10.7.8.11])
	by mailhub-3.net.treas.gov (8.9.3+Sun/8.9.3) with ESMTP id OAA17710;
	Fri, 1 Dec 2000 14:31:40 -0500 (EST)
Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1])
	by mears.indy.cr.irs.gov (8.9.3/8.9.3) with ESMTP id OAA04628;
	Fri, 1 Dec 2000 14:33:25 -0500
Message-Id: <3A27FD05.5022C523@parnelli.indy.cr.irs.gov>
Date: Fri, 01 Dec 2000 14:33:25 -0500
From: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686)
X-Accept-Language: en
Mime-Version: 1.0
Cc: IETF Policy WG LIST <policy@raleigh.ibm.com>,
        "LIST, DEN discussion" <dir-nets@andrew.cmu.edu>, chair-den@dmtf.org,
        chair-ldap@dmtf.org, chair-network@dmtf.org, cim-support@dmtf.org
Subject: dlm1/CIM24 schema suggestion
References: <8E1E94178828D143B34A560A7A6F2C0B01A6A0FA@mailmaestro.smartpipes.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
Content-Transfer-Encoding: 7bit

Since there is no "public" forum for discussion of the dlm1/CIM24 LDAP
schema, I'm forwarding these comments through various DMTF Working Group
chairs. Please forward these comments to your working group members as
you deem appropriate.

Since the IETF's Policy WG has such a close working relationship with
the
DMTF WGs, I'm sharing these comments with the Policy WG, as well.

--

The attributes dlmPrimaryOwnerName and dlmPrimaryOwnerContact do not
adequately leverage the potential of the Directory information model.
These attributes of the objectclass dlm1System are defined as
directoryString types.

If the "primary owner" is not represented in the Directory (or a 
federated Directory instance), these string values may adequately
serve their purpose. This could be considered "best effort" information.

In a thorough Directory implementation, it is likely that the
"primary owner" will be represented with a Directory entry. This
could be via objectclasses such as person, organizationalUnit, 
organizationalRole, or similar.

In such cases, the "primary owner(s)" should be identified by a
distinguishedName (DN) -type attribute.

By leveraging Directory-based information about "primary owner",
clients can discover and use specific and strongly-typed attribute
values such as e-mail, URL, and phone numbers for voice, fax, pager, 
and mobile .   

The next iteration of the dlm/CIM schema should support an additional
attribute of distinguishedName (DN) type, an attribute to augment
the "primary owner" notion of the information model. The attribute
could be named dlmPrimaryOwnerDN. This attributeType should allow
multiple values.

Similar rationale applies to the dlmSupportAccess objectclass. If
the supporting entity is represented in the Directory (or federated
Directory instance), it should be identified by a distinguishedName 
(DN) -type attribute.

The next iteration of the dlm/CIM schema should support an additional
attribute of distinguishedName (DN) type, an attribute to augment
the "support entity" notion of the information model. The attribute
could be named dlmSupportAccessDN. This attributeType should allow
multiple values.

Thank you for your consideration of this issue. 
 
--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|


From majordomo@raleigh.ibm.com  Fri Dec  1 18:27:50 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28769
	for <policy-archive@odin.ietf.org>; Fri, 1 Dec 2000 18:27:50 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA07548;
	Fri, 1 Dec 2000 18:18:22 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA44082;
	Fri, 1 Dec 2000 18:18:17 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA48442; Fri, 1 Dec 2000 15:56:20 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA66864; Fri, 1 Dec 2000 15:56:16 -0500
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA29834
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 15:56:19 -0500
Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37])
	by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id PAA58506;
	Fri, 1 Dec 2000 15:53:40 -0500
Importance: Normal
Subject: Modeling of algorithmic droppers and queues
To: diffserv@ietf.org, policy@raleigh.ibm.com
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-Id: <OFB526E895.22B4E91D-ON852569A8.0070C70B@raleigh.ibm.com>
From: "Robert Moore" <remoore@us.ibm.com>
Date: Fri, 1 Dec 2000 15:57:43 -0500
X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at
 12/01/2000 03:54:01 PM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Robert Moore" <remoore@us.ibm.com>

After reading through the -05 Informal Model, and comparing
it with the new -02 QDDIM, it appears that neither of us is
quite there yet on modeling the relationship between an
algorithmic dropper and a queue.  There are (at least!) two
ways of modeling these two elements, and both documents
contain elements of both approaches.

Option 1:  an algorithmic dropper sits before its queue
in the data path, and based on what it sees in the
queue, it discards "packets that arrive at its input"
(Informal Model, p. 27).  This is what the Informal Model
describes as the alternative it has chosen.  It is the
basis for the NextService association in QDDIM and the
Next pointer in the -06 MIB, which show a progression
from <some preceding element>-to-AlgorithmicDropper-to-queue.

Option 2:  an algorithmic dropper sits beside its queue,
outside the data path, and based on what it sees in the
queue, it discards packets "from the head, tail, or other
part of the associated queue" (Informal Model, p. 29).
Figure 5 in the Informal Model shows this interpretation
very clearly, and it's also represented in the QDDIM
by the HeadTailDropQueueBinding association.

If we look at the example TCB in section 8.2 of the
informal model, we see that the droppers are all placed
before their associated queues, as Option 1 requires.
But they're also dropping from the tails of the queues,
which, given the picture, isn't too much of a stretch:
if the observed properties of the queue tell it to,
the dropper drops a packet that it's holding, rather
than putting it onto the tail of the queue.

What would the picture look like if the dropping were
from the head of one of the queues?  We can't place the
dropper after the queue -- both the Informal Model and
the MIB explicitly rule this out.  The only picture
that works is the one for Option 2.  But here the
dropper is plainly not dropping a packet that "arrives
at its input" -- it's dropping a packet from the head
of the queue.

I'm not sure what's the best way to clarify all of this.
My inclination, though, would be to say that Option 2
is the right way to think of this relationship, with
the *convention* that the chain of Next pointers /
NextService associations always goes
<preceding element>-->AlgorithmicDropper-->queue.

I'm also wondering whether, in the QDDIM, we should
have made HeadTailDropQueueBinding a subclass of
NextService,  This would embody the convention that
I just described, without requiring a separate NextService
association between the dropper and the queue, alongside
the HeadTailDropQueueBinding.  (This assumes that the
queue that a HeadTailDropper monitors is always the
same one from which it causes packets to be dropped --
I haven't seen anything to indicate that this is not
the case.)

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
remoore@us.ibm.com



From majordomo@raleigh.ibm.com  Fri Dec  1 18:56:08 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05837
	for <policy-archive@odin.ietf.org>; Fri, 1 Dec 2000 18:56:07 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA15732;
	Fri, 1 Dec 2000 18:33:44 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA28558;
	Fri, 1 Dec 2000 18:33:40 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA58010; Fri, 1 Dec 2000 16:43:50 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA12164; Fri, 1 Dec 2000 16:43:47 -0500
Received: from lmr (lig32-227-160-45.us.lig-dial.ibm.com [32.227.160.45])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA19990;
	Fri, 1 Dec 2000 16:43:53 -0500
Message-Id: <002101c05bdf$8cfe8920$08a0e320@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
Cc: "IETF Policy WG LIST" <policy@raleigh.ibm.com>,
        "LIST, DEN discussion" <dir-nets@andrew.cmu.edu>
References: <8E1E94178828D143B34A560A7A6F2C0B01A6A0FA@mailmaestro.smartpipes.com> <3A27FD05.5022C523@parnelli.indy.cr.irs.gov>
Subject: Re: dlm1/CIM24 schema suggestion
Date: Fri, 1 Dec 2000 16:41:58 -0500
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Lee Rafalow" <rafalow@raleigh.ibm.com>
Content-Transfer-Encoding: 7bit

Larry, these mailing lists seem fine for having this discussion.  The Policy
Core LDAP Schema draft references the CIM Core mapping so it's relevent.
(Joel, Ed, if you disagree, let us know and we'll find another forum.)

The CIM user-security model (see http://www.dmtf.org/spec/cims.html ) has
three associations of interest that augment the primary owner name and
contact properties.  (An argument could be made that these properties should
be deprecated, but that hasn't been done as yet.)  The SystemAdministrator,
SystemAdministratorRole and SystemAdministratorGroup associations define
relationships between a System and a UserEntity (in CIM, Person and
UsersAccess are subclasses of UserEntity), Role and Group respectively.

The mapping of the CIM user-security model to an LDAP schema is in process
right now.  The Person, Role and Group objects will be mapped directly to
familiar LDAP classes.  If you look at the way associations are mapped in
the Core mapping, you'll see that the preferred way of doing these
associations would be to have an aux class of the association, e.g.,
dlm1SystemAdminsitratorAuxClass, attached to both a Person instance (e.g.,
inetOrgPerson) with a DN pointer back to the system,
dlmSystemAdministratorAntecedentRef, and attached to a system instance with
a DN pointer to the Person, dlmSystemAdministratorDependentRef.

We haven't gotten to the Support model yet.  I hope this helps.  Cheers, Lee

----- Original Message -----
From: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
Cc: "IETF Policy WG LIST" <policy@raleigh.ibm.com>; "LIST, DEN discussion"
<dir-nets@andrew.cmu.edu>; <chair-den@dmtf.org>; <chair-ldap@dmtf.org>;
<chair-network@dmtf.org>; <cim-support@dmtf.org>
Sent: Friday, December 01, 2000 2:33 PM
Subject: dlm1/CIM24 schema suggestion


> Since there is no "public" forum for discussion of the dlm1/CIM24 LDAP
> schema, I'm forwarding these comments through various DMTF Working Group
> chairs. Please forward these comments to your working group members as
> you deem appropriate.
>
> Since the IETF's Policy WG has such a close working relationship with
> the
> DMTF WGs, I'm sharing these comments with the Policy WG, as well.
>
> --
>
> The attributes dlmPrimaryOwnerName and dlmPrimaryOwnerContact do not
> adequately leverage the potential of the Directory information model.
> These attributes of the objectclass dlm1System are defined as
> directoryString types.
>
> If the "primary owner" is not represented in the Directory (or a
> federated Directory instance), these string values may adequately
> serve their purpose. This could be considered "best effort" information.
>
> In a thorough Directory implementation, it is likely that the
> "primary owner" will be represented with a Directory entry. This
> could be via objectclasses such as person, organizationalUnit,
> organizationalRole, or similar.
>
> In such cases, the "primary owner(s)" should be identified by a
> distinguishedName (DN) -type attribute.
>
> By leveraging Directory-based information about "primary owner",
> clients can discover and use specific and strongly-typed attribute
> values such as e-mail, URL, and phone numbers for voice, fax, pager,
> and mobile .
>
> The next iteration of the dlm/CIM schema should support an additional
> attribute of distinguishedName (DN) type, an attribute to augment
> the "primary owner" notion of the information model. The attribute
> could be named dlmPrimaryOwnerDN. This attributeType should allow
> multiple values.
>
> Similar rationale applies to the dlmSupportAccess objectclass. If
> the supporting entity is represented in the Directory (or federated
> Directory instance), it should be identified by a distinguishedName
> (DN) -type attribute.
>
> The next iteration of the dlm/CIM schema should support an additional
> attribute of distinguishedName (DN) type, an attribute to augment
> the "support entity" notion of the information model. The attribute
> could be named dlmSupportAccessDN. This attributeType should allow
> multiple values.
>
> Thank you for your consideration of this issue.
>
> --
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
> # Larry Bartz                           |                              |
> #  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
> #                                       | Ooo, ooo, oooooo!            |
> #                                       | I've got a gnu attitude!     |
> #  voice (317) 226-7060                 |                              |
> #  FAX   (317) 226-6378                 |                              |
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|



From majordomo@raleigh.ibm.com  Fri Dec  1 18:58:50 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06468
	for <policy-archive@odin.ietf.org>; Fri, 1 Dec 2000 18:58:50 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA33970;
	Fri, 1 Dec 2000 18:33:50 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA22010;
	Fri, 1 Dec 2000 18:33:41 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA12240; Fri, 1 Dec 2000 16:49:37 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA53190; Fri, 1 Dec 2000 16:49:34 -0500
Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA24558
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 16:49:42 -0500
From: Ed_Ellesson@tivoli.com
Received: from schub.tivoli.com (schub.tivoli.com [146.84.104.17])
	by corp.tivoli.com (8.9.3/8.9.0) with ESMTP id PAA24903;
	Fri, 1 Dec 2000 15:49:57 -0600 (CST)
Importance: Normal
Subject: Proposed Policy Framework Agenda
To: policy@raleigh.ibm.com
Cc: "Joel M. Halpern" <joel@longsys.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Date: Fri, 1 Dec 2000 16:42:15 -0500
Message-Id: <OF119E4236.71384208-ON852569A8.00748F9A@tivoli.com>
X-Mimetrack: Serialize by Router on SCHub/Tivoli Systems(Release 5.0.4a |July 24, 2000) at
 12/01/2000 03:49:13 PM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Ed_Ellesson@tivoli.com

Hi, Policy Frameworkers:

I understand that we have until Monday at 5pm to get this into the
agenda@ietf.org address, for posting on the IETF web page.  Please comment.


Proposed Policy Framework Agenda (still being negotiated):



Monday Afternoon, Dec. 11:  3:30 - 5:30pm (120 minutes)

1.  Intro/Objectives/Milestones:  Joel ,  10 minutes

2.  Agenda Bash:  Ed, 5 minutes

3.  QDDIM:  Bob Moore,  Editor.    Total: 30 minutes

      (20 minutes issues presentation, plus 10 min. for discussion)

4.  QPIM:  QPIM Author(s)   Total:  30 minutes

       (20 minutes issues presentation, plus 10 min. for discussion)

5.  QDIM/QPIM compatibility with DiffServ:    Total 30 minutes

     (Conceptual Model, MIB, and PIB Issues discussion)

6.  Wrap-up:   Ed and Joel, 15 minutes.

      (Summary and short re-review of Wed agenda)



Wednesday Morning, Dec. 13:  9:00 - 11:30am (150 minutes)

1.  Intro/News since Monday:  Ed and Joel, 5 minutes

2.  IPSP's PCIM-based Model:  Lee Rafalow/IPSP Participants:  Total 30
minutes

     (20 minutes issues presentation, plus 10 for discussion)

3.  Packet Classification, priority, and link between policy and
configuration mechanisms:    30 minutes

     (Issues/Harmonization discussion: QDIM, QPIM, IPSP)

4.  PCLS Update:  Bob Moore:  5 minutes,  Ed Ellesson: 15 minutes:   Total
20 minutes

      (General PCLS issues update, plus Security Considerations issues):

5.  Terminology Draft Update/Issues and harmonization discussion:  Andrea:
20 minutes

6.  (If time permits) AAA Architecture:  Use of policy framework in context
of AAA Architecture:  Cees deLaat, and John Vollbrecht:  10 minutes

7.  (If time permits)  MPLS:  MPLS Policy Draft Author(s):    Use of policy
framework in context of MPLS:   10 minute update

8.  Wrap-up, and charter milestones re-visit:  25 minutes, Ed, Joel and
Bert


*********************

Thanks,

Ed and Joel




From majordomo@raleigh.ibm.com  Fri Dec  1 19:23:04 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12022
	for <policy-archive@odin.ietf.org>; Fri, 1 Dec 2000 19:23:03 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA28104;
	Fri, 1 Dec 2000 19:14:05 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id TAA26604;
	Fri, 1 Dec 2000 19:13:58 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA51882; Fri, 1 Dec 2000 18:47:30 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA48524; Fri, 1 Dec 2000 18:47:25 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA25730
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 18:47:25 -0500
Received: from mail7.nc.rr.com (mail7.southeast.rr.com [24.93.67.54])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA31814
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 18:42:33 -0500
Received: from ellesson ([24.25.4.246]) by mail7.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.537.53);
	 Fri, 1 Dec 2000 18:41:45 -0500
Message-Id: <005701c05bf0$42b041e0$f6041918@nc.rr.com>
From: "Ed Ellesson" <EELLESSON@nc.rr.com>
To: <policy@raleigh.ibm.com>
Subject: Fw: Proposed Policy Framework Agenda
Date: Fri, 1 Dec 2000 18:41:43 -0500
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Ed Ellesson" <EELLESSON@nc.rr.com>
Content-Transfer-Encoding: 7bit

I have not seen this posted yet, so I will try from another account.
----- Original Message -----
From: <Ed_Ellesson@tivoli.com>
To: <eellesson@nc.rr.com>
Sent: Friday, December 01, 2000 6:25 PM
Subject: Proposed Policy Framework Agenda


>
> ---------------------- Forwarded by Ed Ellesson/Tivoli Systems on
> 12/01/2000 06:29 PM ---------------------------
>
> Ed Ellesson
> 12/01/2000 04:42 PM
>
> To:   policy@raleigh.ibm.com
> cc:   "Joel M. Halpern" <joel@longsys.com>, "Wijnen, Bert (Bert)"
>       <bwijnen@lucent.com>
> From: Ed Ellesson/Tivoli Systems@Tivoli Systems
> Subject:  Proposed Policy Framework Agenda
>
>
> Hi, Policy Frameworkers:
>
> I understand that we have until Monday at 5pm to get this into the
> agenda@ietf.org address, for posting on the IETF web page.  Please
comment.
>
>
> Proposed Policy Framework Agenda (still being negotiated):
>
>
>
> Monday Afternoon, Dec. 11:  3:30 - 5:30pm (120 minutes)
>
> 1.  Intro/Objectives/Milestones:  Joel ,  10 minutes
>
> 2.  Agenda Bash:  Ed, 5 minutes
>
> 3.  QDDIM:  Bob Moore,  Editor.    Total: 30 minutes
>
>       (20 minutes issues presentation, plus 10 min. for discussion)
>
> 4.  QPIM:  QPIM Author(s)   Total:  30 minutes
>
>        (20 minutes issues presentation, plus 10 min. for discussion)
>
> 5.  QDIM/QPIM compatibility with DiffServ:    Total 30 minutes
>
>      (Conceptual Model, MIB, and PIB Issues discussion)
>
> 6.  Wrap-up:   Ed and Joel, 15 minutes.
>
>       (Summary and short re-review of Wed agenda)
>
>
>
> Wednesday Morning, Dec. 13:  9:00 - 11:30am (150 minutes)
>
> 1.  Intro/News since Monday:  Ed and Joel, 5 minutes
>
> 2.  IPSP's PCIM-based Model:  Lee Rafalow/IPSP Participants:  Total 30
> minutes
>
>      (20 minutes issues presentation, plus 10 for discussion)
>
> 3.  Packet Classification, priority, and link between policy and
> configuration mechanisms:    30 minutes
>
>      (Issues/Harmonization discussion: QDIM, QPIM, IPSP)
>
> 4.  PCLS Update:  Bob Moore:  5 minutes,  Ed Ellesson: 15 minutes:   Total
> 20 minutes
>
>       (General PCLS issues update, plus Security Considerations issues):
>
> 5.  Terminology Draft Update/Issues and harmonization discussion:  Andrea:
> 20 minutes
>
> 6.  (If time permits) AAA Architecture:  Use of policy framework in
context
> of AAA Architecture:  Cees deLaat, and John Vollbrecht:  10 minutes
>
> 7.  (If time permits)  MPLS:  MPLS Policy Draft Author(s):    Use of
policy
> framework in context of MPLS:   10 minute update
>
> 8.  Wrap-up, and charter milestones re-visit:  25 minutes, Ed, Joel and
> Bert
>
>
> *********************
>
> Thanks,
>
> Ed and Joel
>
>
>
>



From majordomo@raleigh.ibm.com  Fri Dec  1 20:35:15 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27843
	for <policy-archive@odin.ietf.org>; Fri, 1 Dec 2000 20:35:15 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id UAA24588;
	Fri, 1 Dec 2000 20:26:35 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id UAA44182;
	Fri, 1 Dec 2000 20:26:34 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA50022; Fri, 1 Dec 2000 19:59:30 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA12124; Fri, 1 Dec 2000 19:59:27 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id TAA05378
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 19:59:28 -0500
Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA35748
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 19:59:27 -0500
Received: from mail.coreon.net (mail.coreon.net [216.74.131.6])
	by mail.coreon.net (Mirapoint)
	with SMTP id AAO48966;
	Fri, 1 Dec 2000 19:59:42 -0500 (EST)
From: <rmoats@coreon.net>
Message-Id: <200012020059.AAO48966@mail.coreon.net>
Date: Fri, 1 Dec 2000 20:13:19 -0500
Subject: Re: CIM24 schema tweaks
To: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
Cc: "Quevedo, Felix" <FQuevedo@smartpipes.com>,
        IETF Policy WG LIST <policy@raleigh.ibm.com>,
        ietf-ldapbis@openldap.org, ietf-ldapext@netscape.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: <rmoats@coreon.net>
Content-Transfer-Encoding: 7bit



>> It looks like the dlmHelperRefTo... should actually be: 
dlm...HelperRef.
>> This must have happen when applying a "new" naming 
convention to the
>> attributes type descriptions, but did not to modify their 
references in the
>> object class descriptions.
>> 
>> Can the DMTF team confirm this?

I can confirm that... they should be ..HelperRef,
but in editing the document we got them out of sync.

>I guessed the same. I substituted the dlm...HelperRef attrs 
in the 
>attachment to my initial message.
>
>I've spotted another potential difficulty with the schema of 
DSP0117.
>
>See this description:
>
>attributetype    ( 1.3.6.1.4.1.412.100.1.2.1
>     NAME 'orderedCimKeys'
>     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE
>     EQUALITY octetStringMatch
>   )
>
>The matching rule syntax does not match the attribute's 
syntax. This 
>must be corrected.

Well, as an editor, I get to play the "no complaints without
making a suggestion" card.  What do you suggest as the
equality match?  Based on my reading of the X.500-series and
LDAP RFCs the only option for Directory Strings is 
caseIgnoreMatch, and I'm not at all comfortable with
declaring that as the matching rule for a syntax that holds
UTF-8 strings.  

Actually, the more I think about this, I think this is a 
bigger issue than just Policy, so I'm cross posting to
ldapext and the newly minted ldapbis to see what those
folks can add.

Ryan Moats


From majordomo@raleigh.ibm.com  Fri Dec  1 21:54:30 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11876
	for <policy-archive@odin.ietf.org>; Fri, 1 Dec 2000 21:54:29 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA18414;
	Fri, 1 Dec 2000 21:44:45 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id VAA23252;
	Fri, 1 Dec 2000 21:44:51 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA45154; Fri, 1 Dec 2000 21:21:19 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43080; Fri, 1 Dec 2000 21:21:15 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id VAA46172
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 21:21:17 -0500
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA38704
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 21:21:14 -0500
Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54])
	by netscape.com (8.10.0/8.10.0) with ESMTP id eB228Ds13555
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 18:08:14 -0800 (PST)
Received: from sun.com ([192.18.120.101]) by dredd.mcom.com
          (Netscape Messaging Server 4.15 dredd Jun 22 2000 16:29:39) with
          ESMTP id G4X57600.7S7; Fri, 1 Dec 2000 18:21:06 -0800 
Message-Id: <3A285C91.64107968@sun.com>
Date: Fri, 01 Dec 2000 18:21:05 -0800
From: Mark Wahl <Mark.Wahl@sun.com>
Organization: Sun Microsystems, Inc.
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
Mime-Version: 1.0
To: rmoats@coreon.net
Cc: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>,
        "Quevedo Felix" <FQuevedo@smartpipes.com>,
        IETF Policy WG LIST <policy@raleigh.ibm.com>,
        ietf-ldapbis@openldap.org, ietf-ldapext@netscape.com
Subject: Re: CIM24 schema tweaks
References: <200012020059.AAO48966@mail.coreon.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Mark Wahl <Mark.Wahl@sun.com>
Content-Transfer-Encoding: 7bit

rmoats@coreon.net wrote:
> 

> 
> Well, as an editor, I get to play the "no complaints without
> making a suggestion" card.  What do you suggest as the
> equality match?  Based on my reading of the X.500-series and
> LDAP RFCs the only option for Directory Strings is
> caseIgnoreMatch, and I'm not at all comfortable with
> declaring that as the matching rule for a syntax that holds
> UTF-8 strings.

There can be other matching rules for Directory String syntax 
attributes besides case ignore.  Case ignore is just the most 
common.  You can have a Case Sensitive, or other more complex
ones if you define them.

Mark Wahl
Sun Microsystems Inc.


From majordomo@raleigh.ibm.com  Fri Dec  1 23:52:10 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02957
	for <policy-archive@odin.ietf.org>; Fri, 1 Dec 2000 23:52:10 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id XAA34638;
	Fri, 1 Dec 2000 23:42:12 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id XAA27048;
	Fri, 1 Dec 2000 23:42:12 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA46542; Fri, 1 Dec 2000 23:21:55 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA56006; Fri, 1 Dec 2000 23:21:52 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id XAA32866
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 23:22:02 -0500
Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id XAA20534
	for <policy@raleigh.ibm.com>; Fri, 1 Dec 2000 23:21:53 -0500
Received: from mail.coreon.net (mail.coreon.net [216.74.131.6])
	by mail.coreon.net (Mirapoint)
	with SMTP id AAO49142;
	Fri, 1 Dec 2000 23:22:27 -0500 (EST)
From: <rmoats@coreon.net>
Message-Id: <200012020422.AAO49142@mail.coreon.net>
Date: Fri, 1 Dec 2000 23:36:06 -0500
Subject: Re: CIM24 schema tweaks
To: Mark Wahl <Mark.Wahl@sun.com>
Cc: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>,
        Quevedo Felix <FQuevedo@smartpipes.com>,
        IETF Policy WG LIST <policy@raleigh.ibm.com>,
        ietf-ldapbis@openldap.org, ietf-ldapext@netscape.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: <rmoats@coreon.net>
Content-Transfer-Encoding: 7bit

Mark-

I realize that but doesn't, that sort of put the cart
before the horse, by creating an implementation barrier?

Thinking about it, I suppose the document could define
a new matching rule and say "in case your directory
implementation doesn't support this you can use <blah>",
but I was looking for what <blah> could be besides
caseIgnoreMatch.

Ryan

---- Original message ----
>Date: Fri, 01 Dec 2000 18:21:05 -0800
>From: Mark Wahl <Mark.Wahl@sun.com>
>Subject: Re: CIM24 schema tweaks
>To: rmoats@coreon.net
>Cc: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>, 
"Quevedo Felix" <FQuevedo@smartpipes.com>, IETF Policy WG LIST 
<policy@raleigh.ibm.com>, ietf-ldapbis@openldap.org, 
ietf-ldapext@netscape.com
>
>rmoats@coreon.net wrote:
>> 
>
>> 
>> Well, as an editor, I get to play the "no complaints 
without
>> making a suggestion" card.  What do you suggest as the
>> equality match?  Based on my reading of the X.500-series 
and
>> LDAP RFCs the only option for Directory Strings is
>> caseIgnoreMatch, and I'm not at all comfortable with
>> declaring that as the matching rule for a syntax that holds
>> UTF-8 strings.
>
>There can be other matching rules for Directory String syntax 
>attributes besides case ignore.  Case ignore is just the most 
>common.  You can have a Case Sensitive, or other more complex
>ones if you define them.
>
>Mark Wahl
>Sun Microsystems Inc.


From majordomo@raleigh.ibm.com  Sat Dec  2 08:56:36 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05838
	for <policy-archive@odin.ietf.org>; Sat, 2 Dec 2000 08:56:36 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA18426;
	Sat, 2 Dec 2000 08:46:33 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA35962;
	Sat, 2 Dec 2000 08:46:32 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA39984; Sat, 2 Dec 2000 08:15:30 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA50216; Sat, 2 Dec 2000 08:15:25 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA32226
	for <policy@raleigh.ibm.com>; Sat, 2 Dec 2000 08:15:30 -0500
Received: from mailmaestro.smartpipes.com (mailmaestro.smartpipes.com [63.98.224.170])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA27920
	for <policy@raleigh.ibm.com>; Sat, 2 Dec 2000 08:15:27 -0500
Received: by mailmaestro.smartpipes.com with Internet Mail Service (5.5.2650.21)
	id <XYCWATQT>; Sat, 2 Dec 2000 13:15:22 -0000
Message-Id: <8E1E94178828D143B34A560A7A6F2C0B01A6A0FC@mailmaestro.smartpipes.com>
From: "Quevedo, Felix" <FQuevedo@smartpipes.com>
To: "'rmoats@coreon.net'" <rmoats@coreon.net>, Mark Wahl
	 <Mark.Wahl@sun.com>
Cc: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>,
        "Quevedo, Felix"
	 <FQuevedo@smartpipes.com>,
        IETF Policy WG LIST <policy@raleigh.ibm.com>,
        ietf-ldapbis@openldap.org, ietf-ldapext@netscape.com
Subject: RE: CIM24 schema tweaks
Date: Sat, 2 Dec 2000 13:15:21 -0000 
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Quevedo, Felix" <FQuevedo@smartpipes.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA05838

All,

Interesting... Having the opportunity to be at the directory server vendor
side, and now as a server user,  I do believe the spec work has been
wonderful. Functional inter-operations are possible thanks to the effort.
Schema inter-operations... we are not there yet.

We all know there could be many implementations, but only one (one hopes)
guideline/recommendation/standard document. It would be a daunting task to
cover all possible interpretations (implementations). This may be beyond the
scope of the spec. 

To all of this we should also consider the limitations of the underlining
technology on which that implementation is based on. Is there a Directory
server that supports near 100% the LDAP spec? Maybe. Is it the one we all
use? Sure not.

Let's take MS ActiveDirectory (pardon the example). It does not support
multiple names or attribute superiors or matching rules or ... It does
however have other features like LinkID's to define relationships. So we
have to take the spec and "adjust" it to the technology. Who should do it?
The developer? The vendor? The spec editor?

The industry is hungry for guidance from the standard bodies. Not
necessarily the ultimate solution.

Thanks to all!!
Félix E Quevedo
:) Smile, everything is possible!
E-Mail: fquevedo@smartpipes.com
Voice: 614 923 6242
Fax: 614 923 6299

 -----Original Message-----
From: 	rmoats@coreon.net [mailto:rmoats@coreon.net] 
Sent:	Friday, December 01, 2000 23:36
To:	Mark Wahl
Cc:	Larry S. Bartz; Quevedo Felix; IETF Policy WG LIST;
ietf-ldapbis@openldap.org; ietf-ldapext@netscape.com
Subject:	Re: CIM24 schema tweaks

Mark-

I realize that but doesn't, that sort of put the cart
before the horse, by creating an implementation barrier?

Thinking about it, I suppose the document could define
a new matching rule and say "in case your directory
implementation doesn't support this you can use <blah>",
but I was looking for what <blah> could be besides
caseIgnoreMatch.

Ryan

---- Original message ----
>Date: Fri, 01 Dec 2000 18:21:05 -0800
>From: Mark Wahl <Mark.Wahl@sun.com>
>Subject: Re: CIM24 schema tweaks
>To: rmoats@coreon.net
>Cc: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>, 
"Quevedo Felix" <FQuevedo@smartpipes.com>, IETF Policy WG LIST 
<policy@raleigh.ibm.com>, ietf-ldapbis@openldap.org, 
ietf-ldapext@netscape.com
>
>rmoats@coreon.net wrote:
>> 
>
>> 
>> Well, as an editor, I get to play the "no complaints 
without
>> making a suggestion" card.  What do you suggest as the
>> equality match?  Based on my reading of the X.500-series 
and
>> LDAP RFCs the only option for Directory Strings is
>> caseIgnoreMatch, and I'm not at all comfortable with
>> declaring that as the matching rule for a syntax that holds
>> UTF-8 strings.
>
>There can be other matching rules for Directory String syntax 
>attributes besides case ignore.  Case ignore is just the most 
>common.  You can have a Case Sensitive, or other more complex
>ones if you define them.
>
>Mark Wahl
>Sun Microsystems Inc.


From majordomo@raleigh.ibm.com  Sat Dec  2 12:46:51 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16905
	for <policy-archive@odin.ietf.org>; Sat, 2 Dec 2000 12:46:50 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA19178;
	Sat, 2 Dec 2000 12:36:35 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA28644;
	Sat, 2 Dec 2000 12:36:22 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA66840; Sat, 2 Dec 2000 12:05:51 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA42254; Sat, 2 Dec 2000 12:05:47 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA31598
	for <policy@raleigh.ibm.com>; Sat, 2 Dec 2000 12:05:53 -0500
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA28050
	for <policy@raleigh.ibm.com>; Sat, 2 Dec 2000 12:05:51 -0500
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id JAA10152;
	Sat, 2 Dec 2000 09:05:45 -0800 (PST)
Received: from jstrassnlap (sj-dial-1-149.cisco.com [171.68.179.150])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with SMTP id ADT24464;
	Sat, 2 Dec 2000 09:05:38 -0800 (PST)
Message-Id: <001a01c05c82$922a6650$96b344ab@cisco.com>
From: "John Strassner" <jstrassn@cisco.com>
To: "Jean Christophe Martin \(From Home\)" <jcmartin@Eng.Sun.COM>,
        "Yoram Ramberg" <yramberg@cisco.com>, <johns@cisco.com>
Cc: <policy@raleigh.ibm.com>
References: <4.3.2.7.2.20001129171501.00cf4190@csi-admin1.cisco.com> <3A254215.EFC1C41A@eng.sun.com>
Subject: Re: new version of QPIM
Date: Sat, 2 Dec 2000 02:08:13 -0800
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "John Strassner" <jstrassn@cisco.com>
Content-Transfer-Encoding: 7bit

Hi Jean, I believe your issue is that if you want to build a
condition to filter traffic, the IETF IPsec model uses
classes derived from FilterEntryBase whereas QPIM uses two
different classes - gpsPolicySimpleCondition and
gpsPolicyCompoundCondition.

The reason for this is that the QPIM extends the definition
of a condition into an ordered triplet (i.e., {variable,
operator, value}). These semantics are not present in the
current definition of FilterEntryBase or its subclasses.
Furthermore, the QPIM further extends these semantics to
define a set of classes to model a set of common variables,
a corresponding set of classes to model the values that the
variables can take, and relationships to:

  1) constrain the values that a given variable can take
  2) relate the variables and values to a condition
  3) represent reusable variables and values

Note that an implementation could in fact produce a
FilterEntry from these classes.

HTH and kind regards,
John

----- Original Message -----
From: "Jean Christophe Martin (From Home)"
<jcmartin@eng.sun.com>
To: "Yoram Ramberg" <yramberg@cisco.com>; <johns@cisco.com>
Cc: <policy@raleigh.ibm.com>
Sent: Wednesday, November 29, 2000 9:51 AM
Subject: Re: new version of QPIM


> Yoram , John
>
> > A new (-02) version of the QoS Policy Information Model
draft has been sent
> > to the IETF for posting.
>
> Here is the motivation of my first mail to the alias :
>
> The CIM Network sub-model defines the elements :
FilterList,
> FilterEntryBase
> and FilterEntry.
> These Filters are describing the traffic in the Forwarding
Path.
>
> The IPSEC policy Model (IETF/DMTF)  is using these classes
as the basis
> for
> the condition part of the policy.
>
> However, your draft is redefining a condition object that
is not at all
> aligned with the IETF (IPSEC) or the DMTF (QoS Device
Sub-Model &
> IPSEC).
>
> Do you have any plans to change your draft so that, at a
minimum, one
> can
> reuse already existing Filters as Conditions in the QoS
Policy Model ?
>
> Thanks.
>
> JC.



From majordomo@raleigh.ibm.com  Sun Dec  3 07:19:15 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28729
	for <policy-archive@odin.ietf.org>; Sun, 3 Dec 2000 07:19:15 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA09124;
	Sun, 3 Dec 2000 07:08:35 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA37298;
	Sun, 3 Dec 2000 07:08:42 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA54828; Sun, 3 Dec 2000 06:38:12 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA52004; Sun, 3 Dec 2000 06:38:09 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id GAA48086
	for <policy@raleigh.ibm.com>; Sun, 3 Dec 2000 06:38:13 -0500
Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA39116
	for <policy@raleigh.ibm.com>; Sun, 3 Dec 2000 06:38:11 -0500
Received: from yramberg-hpxu.cisco.com (telaviv3-dhcp65.cisco.com [144.254.93.193])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id NAA17906;
	Sun, 3 Dec 2000 13:37:55 +0200 (IST)
Message-Id: <4.3.2.7.2.20001203102134.034c9d80@csi-admin1.cisco.com>
X-Sender: yramberg@csi-admin1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 03 Dec 2000 13:38:00 -0600
To: Marcus Brunner <brunner@ccrle.nec.de>, ysnir@cisco.com,
        Yoram Snir <ysnir@cisco.com>
From: Yoram Ramberg <yramberg@cisco.com>
Subject: Rule nesting and ordering
Cc: brunner@ccrle.nec.de,
        "''Policy Mailing List' (E-mail)'" <policy@raleigh.ibm.com>
In-Reply-To: <20001201175919.960C67DC9@imap.heidelberg.ccrle.nec.de>
References: <004501c05baa$f8e06f80$b270310a@ysnirnt70>
 <004501c05baa$f8e06f80$b270310a@ysnirnt70>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Yoram Ramberg <yramberg@cisco.com>

I took the liberty to snip the stuff I didn';t address...
*Yoram

At 06:59 PM 12/1/00 +0100, Marcus Brunner wrote:
[...snip...]
> > >
> > > Rule nesting
> > > What is the semantic of the PolicyRuleinPolicyRule aggregation?
> > > Basically, I do not see the execution semantic. I have the
> > > feeling this
> > > concept will run us in problems implementing it properly (defined
> > > semantic)
> > > Why is ordered grouping of rules not sufficient?
> >
> > Please see explanation and example in the draft, it illustrates the order
> > of
> > grouping and rules, and how the combination works.
>
>So lets try, if I understand it correct.
>
>We have three rules R1,R2, and R3, with conditions C1,C2, C3, and actions A1,
>A2, A3. R2 and R3 are associated to R1.
>
>So if C1 is true perform A1 and evalute rules R2 and R3
>                 if C2 is true then perform A2
>                 if C2 is false then (stop of evalute R3 ??? -> define
>sequential or paralell evaluation of the rules)
>if C1 is false do nothing
>
>What is the difference to the three rules?
>IF C1 THEN A1
>IF C1 AND C2 THEN A2
>IF C1 AND C3 THEN A3
>
>What is the context of the evaluation of R2, R3? Same as R1? Global?
>Is the semantic the same as if one would model it with a EvaluationAction?

This is my understanding of the evaluation and execution order:
Assuming the 1, 2 and 3 designate rule priority,

If the decision strategy is MATCH ALL (expected to be rare for constructs 
like this),
If (C1) {
   If (C2)  {A1; A2;};
   if (C3)  {A1; A3;};
   A1;
}

If the decision strategy is MATCH FIRST (which us the usual case),
if (C1) {
    if (C2) {A1; A2;}
    else if (C3) {A1; A3}
    else A1;
}

Am I right?
*Yoram



From majordomo@raleigh.ibm.com  Mon Dec  4 14:44:45 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10794
	for <policy-archive@odin.ietf.org>; Mon, 4 Dec 2000 14:44:45 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA27542;
	Mon, 4 Dec 2000 14:29:49 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA24330;
	Mon, 4 Dec 2000 14:29:20 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA39244; Mon, 4 Dec 2000 13:55:23 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA40758; Mon, 4 Dec 2000 13:55:15 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA36294
	for <policy@raleigh.ibm.com>; Mon, 4 Dec 2000 13:55:17 -0500
Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA24550
	for <policy@raleigh.ibm.com>; Mon, 4 Dec 2000 13:55:13 -0500
Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id eB4IuME94423;
	Mon, 4 Dec 2000 19:56:22 +0100 (CET)
Received: from imap.heidelberg.ccrle.nec.de (postfix@imap.heidelberg.ccrle.nec.de [192.168.102.7])
	by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA24326;
	Mon, 4 Dec 2000 19:55:30 +0100
Received: by imap.heidelberg.ccrle.nec.de (Postfix, from userid 30)
	id 5EDF77DCC; Mon,  4 Dec 2000 21:55:07 +0100 (CET)
From: Marcus Brunner <brunner@ccrle.nec.de>
To: Ed_Ellesson@tivoli.com
Cc: policy@raleigh.ibm.com, "Joel M. Halpern" <joel@longsys.com>
References: <OF119E4236.71384208-ON852569A8.00748F9A@tivoli.com>
In-Reply-To: <OF119E4236.71384208-ON852569A8.00748F9A@tivoli.com>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: IMP/PHP3 Imap webMail Program 2.0.9
Subject: Re: Proposed Policy Framework Agenda
Message-Id: <20001204205507.5EDF77DCC@imap.heidelberg.ccrle.nec.de>
Date: Mon,  4 Dec 2000 21:55:07 +0100 (CET)
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Marcus Brunner <brunner@ccrle.nec.de>
Content-Transfer-Encoding: 7bit

> 3.  Packet Classification, priority, and link between policy and
> configuration mechanisms:    30 minutes
>
>      (Issues/Harmonization discussion: QDIM, QPIM, IPSP)

There are other, more genreal issues concenrning reusability in QDIM, QPIM,IPSP 
as well as the MPLS part. (see the extention draft)



Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155


From majordomo@raleigh.ibm.com  Mon Dec  4 15:14:44 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18331
	for <policy-archive@odin.ietf.org>; Mon, 4 Dec 2000 15:14:43 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA28974;
	Mon, 4 Dec 2000 15:02:42 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA31318;
	Mon, 4 Dec 2000 15:02:40 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA47306; Mon, 4 Dec 2000 14:42:13 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA24002; Mon, 4 Dec 2000 14:42:10 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA29068
	for <policy@raleigh.ibm.com>; Mon, 4 Dec 2000 14:42:12 -0500
Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA15972
	for <policy@raleigh.ibm.com>; Mon, 4 Dec 2000 14:12:31 -0500
Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id eB4JDnE94510;
	Mon, 4 Dec 2000 20:13:49 +0100 (CET)
Received: from imap.heidelberg.ccrle.nec.de (postfix@imap.heidelberg.ccrle.nec.de [192.168.102.7])
	by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA24425;
	Mon, 4 Dec 2000 20:12:58 +0100
Received: by imap.heidelberg.ccrle.nec.de (Postfix, from userid 30)
	id 76C857DCC; Mon,  4 Dec 2000 22:12:32 +0100 (CET)
From: Marcus Brunner <brunner@ccrle.nec.de>
To: Yoram Ramberg <yramberg@cisco.com>
Cc: Marcus Brunner <brunner@ccrle.nec.de>, ysnir@cisco.com,
        Yoram Snir <ysnir@cisco.com>, brunner@ccrle.nec.de,
        "''Policy Mailing List' (E-mail)'" <policy@raleigh.ibm.com>
References: <004501c05baa$f8e06f80$b270310a@ysnirnt70> <004501c05baa$f8e06f80$b270310a@ysnirnt70> <4.3.2.7.2.20001203102134.034c9d80@csi-admin1.cisco.com>
In-Reply-To: <4.3.2.7.2.20001203102134.034c9d80@csi-admin1.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: IMP/PHP3 Imap webMail Program 2.0.9
Subject: Re: Rule nesting and ordering
Message-Id: <20001204211232.76C857DCC@imap.heidelberg.ccrle.nec.de>
Date: Mon,  4 Dec 2000 22:12:32 +0100 (CET)
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Marcus Brunner <brunner@ccrle.nec.de>
Content-Transfer-Encoding: 7bit

Quoting Yoram Ramberg <yramberg@cisco.com>:

> I took the liberty to snip the stuff I didn';t address...
> *Yoram
>
> At 06:59 PM 12/1/00 +0100, Marcus Brunner wrote:
> [...snip...]
> > > >
> > > > Rule nesting
> > > > What is the semantic of the PolicyRuleinPolicyRule aggregation?
> > > > Basically, I do not see the execution semantic. I have the
> > > > feeling this
> > > > concept will run us in problems implementing it properly (defined
> > > > semantic)
> > > > Why is ordered grouping of rules not sufficient?
> > >
> > > Please see explanation and example in the draft, it illustrates the
> order
> > > of
> > > grouping and rules, and how the combination works.
> >
> >So lets try, if I understand it correct.
> >
> >We have three rules R1,R2, and R3, with conditions C1,C2, C3, and actions
> A1,
> >A2, A3. R2 and R3 are associated to R1.
> >
> >So if C1 is true perform A1 and evalute rules R2 and R3
> >                 if C2 is true then perform A2
> >                 if C2 is false then (stop of evalute R3 ??? -> define
> >sequential or paralell evaluation of the rules)
> >if C1 is false do nothing
> >
> >What is the difference to the three rules?
> >IF C1 THEN A1
> >IF C1 AND C2 THEN A2
> >IF C1 AND C3 THEN A3
> >
> >What is the context of the evaluation of R2, R3? Same as R1? Global?
> >Is the semantic the same as if one would model it with a EvaluationAction?
>
> This is my understanding of the evaluation and execution order:
> Assuming the 1, 2 and 3 designate rule priority,
>
> If the decision strategy is MATCH ALL (expected to be rare for constructs
> like this),
> If (C1) {
>    If (C2)  {A1; A2;};
>    if (C3)  {A1; A3;};
>    A1;
> }
>

The question is here, what is the action order? Why not like the following?
If (C1) {
    A1;
    If (C2)  {A1;A2;};
    if (C3)  {A1;A3;};
 }

Seceond question, why do you perform A1 potentially many times?

> If the decision strategy is MATCH FIRST (which us the usual case),
> if (C1) {
>     if (C2) {A1; A2;}
>     else if (C3) {A1; A3}
>     else A1;
> }
>
> Am I right?

Yes.

Marcus
> *Yoram
>
> 



Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155


From majordomo@raleigh.ibm.com  Mon Dec  4 17:13:23 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19325
	for <policy-archive@odin.ietf.org>; Mon, 4 Dec 2000 17:13:23 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA29332;
	Mon, 4 Dec 2000 17:03:28 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA23346;
	Mon, 4 Dec 2000 17:03:20 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA41312; Mon, 4 Dec 2000 16:41:55 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA37450; Mon, 4 Dec 2000 16:41:51 -0500
Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA21758
	for <policy@raleigh.ibm.com>; Mon, 4 Dec 2000 16:41:54 -0500
From: Ed_Ellesson@tivoli.com
Received: from schub.tivoli.com (schub.tivoli.com [146.84.104.17])
	by corp.tivoli.com (8.9.3/8.9.0) with ESMTP id PAA00931;
	Mon, 4 Dec 2000 15:42:11 -0600 (CST)
Importance: Normal
Subject: Re: Proposed Policy Framework Agenda
To: Marcus Brunner <brunner@ccrle.nec.de>
Cc: Ed_Ellesson@tivoli.com, policy@raleigh.ibm.com,
        "Joel M. Halpern" <joel@longsys.com>
Date: Mon, 4 Dec 2000 16:36:32 -0500
Message-Id: <OFF8F0FB8C.35802FD8-ON852569AB.00768F60@tivoli.com>
X-Mimetrack: Serialize by Router on SCHub/Tivoli Systems(Release 5.0.4a |July 24, 2000) at
 12/04/2000 03:41:16 PM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Ed_Ellesson@tivoli.com

Marcus,

Thanks for your note about the agenda.

I modified the description of that agenda item slightly, with the addition
of "other", in case we need to capture any additional issues that come up.

Regarding PCIM extensions,  I think that we should first get some
experience in applying PCIM to the QOS and IPSP disciplines, and find out
whether or not we run into any fundamental roadblocks in the context of
those disciplines.


Ed Ellesson
Tivoli Systems
Durham, NC
ellesson@tivoli.com
Office at Tivoli:  919-224-2111
Office at home:  919-644-3977


Marcus Brunner <brunner@ccrle.nec.de>@raleigh.ibm.com on 12/04/2000
03:55:07 PM

Please respond to Marcus Brunner <brunner@ccrle.nec.de>

Sent by:  policy-owner@raleigh.ibm.com


To:   Ed_Ellesson@tivoli.com
cc:   policy@raleigh.ibm.com, "Joel M. Halpern" <joel@longsys.com>
Subject:  Re: Proposed Policy Framework Agenda



> 3.  Packet Classification, priority, and link between policy and
> configuration mechanisms:    30 minutes
>
>      (Issues/Harmonization discussion: QDIM, QPIM, IPSP)

There are other, more genreal issues concenrning reusability in QDIM,
QPIM,IPSP
as well as the MPLS part. (see the extention draft)



Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155




From majordomo@raleigh.ibm.com  Mon Dec  4 17:13:45 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19496
	for <policy-archive@odin.ietf.org>; Mon, 4 Dec 2000 17:13:44 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA22174;
	Mon, 4 Dec 2000 17:03:30 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA25310;
	Mon, 4 Dec 2000 17:03:21 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43594; Mon, 4 Dec 2000 16:33:31 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43578; Mon, 4 Dec 2000 16:33:27 -0500
Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA30302
	for <policy@raleigh.ibm.com>; Mon, 4 Dec 2000 16:33:27 -0500
From: Ed_Ellesson@tivoli.com
Received: from schub.tivoli.com (schub.tivoli.com [146.84.104.17])
	by corp.tivoli.com (8.9.3/8.9.0) with ESMTP id PAA26178;
	Mon, 4 Dec 2000 15:33:37 -0600 (CST)
Importance: Normal
Subject: Policy Framework WG Agenda
To: agenda@ietf.org
Cc: policy@raleigh.ibm.com, "Joel M. Halpern" <joel@longsys.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Date: Mon, 4 Dec 2000 16:28:00 -0500
Message-Id: <OFB6899718.892B11A9-ON852569AB.00756E90@tivoli.com>
X-Mimetrack: Serialize by Router on SCHub/Tivoli Systems(Release 5.0.4a |July 24, 2000) at
 12/04/2000 03:32:42 PM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Ed_Ellesson@tivoli.com

We are still negotiating some of the specifics, but this is the agenda we
are posting for the IETF Working Group and BOF Agendas page:


Proposed Policy Framework Agenda:


Monday Afternoon, Dec. 11:  3:30 - 5:30pm (120 minutes)

1.  Intro/Objectives/Milestones:  Joel ,  10 minutes

2.  Agenda Bash:  Ed, 5 minutes

3.  QDDIM:  Bob Moore,  Editor.    Total: 30 minutes

      (20 minutes issues presentation, plus 10 min. for discussion)

4.  QPIM:  QPIM Author(s)   Total:  30 minutes

       (20 minutes issues presentation, plus 10 min. for discussion)

5.  QDIM/QPIM compatibility with DiffServ:    Total 30 minutes

     (Conceptual Model, MIB, and PIB Issues discussion)

6.  Wrap-up:   Ed and Joel, 15 minutes.

      (Summary and short re-review of Wed agenda)



Wednesday Morning, Dec. 13:  9:00 - 11:30am (150 minutes)

1.  Intro/News since Monday:  Ed and Joel, 5 minutes

2.  IPSP's PCIM-based Model:  Lee Rafalow/IPSP Participants:  Total 30
minutes

     (20 minutes issues presentation, plus 10 for discussion)

3.  Applying/Linking Policy to QDDIM, QPIM, IPSP:    30 minutes

     (Issues: Packet Classification, Priority, Policy/Configuration
Linkage, Other)

4.  PCLS Update:  PCLS Author(s):  10 minutes,  Ed Ellesson: 10 minutes:
Total
20 minutes

      (General PCLS issues update, plus Security Considerations issues):

5.  Terminology Draft Update/Issues and harmonization discussion:  Andrea:
20 minutes

6.  (If time permits) AAA Architecture:  Use of policy framework in context
of AAA Architecture:  Cees deLaat, and John Vollbrecht:  10 minutes

7.  (If time permits)  MPLS:  MPLS Policy Draft Author(s):    Use of policy
framework in context of MPLS:   10 minute update

8.  Wrap-up, and charter milestones re-visit:  25 minutes, Ed, Joel and
Bert


*********************

Thanks,

Ed and Joel




Ed Ellesson

ellesson@tivoli.com
Office at Tivoli:  919-224-2111
Office at home:  919-644-3977



From majordomo@raleigh.ibm.com  Tue Dec  5 11:04:31 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25803
	for <policy-archive@odin.ietf.org>; Tue, 5 Dec 2000 11:04:30 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA40524;
	Tue, 5 Dec 2000 10:47:32 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA33528;
	Tue, 5 Dec 2000 10:47:28 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA52510; Tue, 5 Dec 2000 08:04:16 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA35726; Tue, 5 Dec 2000 08:04:03 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA29182
	for <policy@raleigh.ibm.com>; Tue, 5 Dec 2000 08:04:04 -0500
Received: from mx-relay2.treas.gov (mx-relay2.treas.gov [199.196.144.6])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA19994
	for <policy@raleigh.ibm.com>; Tue, 5 Dec 2000 08:04:01 -0500
Received: from tias4.treas.gov (tias-gw4.treas.gov [199.196.144.14])
	by mx-relay2.treas.gov (8.9.1b+Sun/8.9.3) with SMTP id IAA22792;
	Tue, 5 Dec 2000 08:04:27 -0500 (EST)
Received: from mailhub.net.treas.gov by tias4.treas.gov
          via smtpd (for mx-relay.treas.gov [199.196.144.6]) with SMTP; 5 Dec 2000 13:04:27 UT
Received: from mears.indy.cr.irs.gov (mailhub-3.net.treas.gov [10.7.8.11])
	by mailhub-3.net.treas.gov (8.9.3+Sun/8.9.3) with ESMTP id IAA26070;
	Tue, 5 Dec 2000 08:02:32 -0500 (EST)
Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1])
	by mears.indy.cr.irs.gov (8.9.3/8.9.3) with ESMTP id IAA17714;
	Tue, 5 Dec 2000 08:04:11 -0500
Message-Id: <3A2CE7CB.F8C3EE9C@parnelli.indy.cr.irs.gov>
Date: Tue, 05 Dec 2000 08:04:11 -0500
From: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686)
X-Accept-Language: en
Mime-Version: 1.0
To: rmoats@coreon.net
Cc: "Quevedo, Felix" <FQuevedo@smartpipes.com>,
        IETF Policy WG LIST <policy@raleigh.ibm.com>,
        ietf-ldapbis@openldap.org, ietf-ldapext@netscape.com
Subject: matching rules for directoryString [was: Re: CIM24 schema tweaks]
References: <200012020059.AAO48966@mail.coreon.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
Content-Transfer-Encoding: 7bit

rmoats@coreon.net wrote:
> 
.[snip]
> What do you suggest as the
> equality match?  Based on my reading of the X.500-series and
> LDAP RFCs the only option for Directory Strings is
> caseIgnoreMatch, and I'm not at all comfortable with
> declaring that as the matching rule for a syntax that holds
> UTF-8 strings.
[snip]
> 

I'm reading X.501 and X.520 from 
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ (hurry for your
copy). Although these are drafts from the 4th edition of the X.500
series, it does not appear that the sections which apply to this 
immediate issue are new or different from current/previous documents.  

X.501 requires that the assertion syntax of the matching rule and
the syntax of attributes to which the matching rule is applied
must be equivalent. See section 13.5.

X.520 defines a caseExactMatch rule which applies to directoryString
attributes. See section 6.1.4. 

Section 8 of RFC2252 does not mention a caseExactMatch rule which 
applies to directoryString attributes. But neither does it appear that
section 8 was intended to describe the entire universe of allowable
or appropriate matching rules. Nothing in RFC2252's section 8 precludes
a Directory implementation from supporting matching rules beyond those
which are enumerated.

Section 3.3 of RFC2251 asserts LDAP's relationship to X.500 and the
requirement for LDAP servers to support the X.500 data and service
models.

Based on these facts, think it is reasonable to specify caseExactMatch
for directoryString attributes. Further, I think it is reasonable to
expect that Directory implementations will support it. 

Also see http://www.alvestrand.no/objectid/2.5.13.5.html

Note that the specification of caseExactMatch for directoryString 
attributes did not prevent RFCs 2713 and 2714 from obtaining.

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|


From majordomo@raleigh.ibm.com  Tue Dec  5 11:04:49 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25871
	for <policy-archive@odin.ietf.org>; Tue, 5 Dec 2000 11:04:49 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA23374;
	Tue, 5 Dec 2000 10:55:06 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA29374;
	Tue, 5 Dec 2000 10:54:57 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA36182; Tue, 5 Dec 2000 10:25:13 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA24648; Tue, 5 Dec 2000 10:25:09 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA20364
	for <policy@raleigh.ibm.com>; Tue, 5 Dec 2000 10:25:10 -0500
Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA28360
	for <policy@raleigh.ibm.com>; Tue, 5 Dec 2000 10:15:08 -0500
Received: from rmoats2 (node-64-248-71-118.dslspeed.zyan.com [64.248.71.118])
	by mail.coreon.net (Mirapoint)
	with ESMTP id AAO53092 (AUTH rmoats);
	Tue, 5 Dec 2000 10:15:29 -0500 (EST)
From: "Ryan Moats" <rmoats@coreon.net>
To: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
Cc: "Quevedo, Felix" <FQuevedo@smartpipes.com>,
        "IETF Policy WG LIST" <policy@raleigh.ibm.com>
Subject: RE: matching rules for directoryString [was: Re: CIM24 schema tweaks]
Date: Tue, 5 Dec 2000 09:21:36 -0600
Message-Id: <OAEPJLLCHIJCOBJMOMBOGEBFCIAA.rmoats@coreon.com>
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.2911.0)
Importance: Normal
In-Reply-To: <3A2CE7CB.F8C3EE9C@parnelli.indy.cr.irs.gov>
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Ryan Moats" <rmoats@coreon.net>
Content-Transfer-Encoding: 7bit

Thank you, Thank you, Thank you!

Having looked at the relevant section, I am MUCH more comfortable
with this than with caseIgnoreMatch.

I think caseExactMatch should be used for

- orderedCimKeys in the 2.4 Mapping
- policyKeywords, policyGroupName, policyRuleName, policyConditionName,
policyActionName, policyInstanceName, policyRepositoryName in the PCLS
(Hey Bob, there's going to be a -09 isn't there ;-)

Ryan

-----Original Message-----
From: lsbart35@mears.indy.cr.irs.gov
[mailto:lsbart35@mears.indy.cr.irs.gov]On Behalf Of Larry S. Bartz
Sent: Tuesday, December 05, 2000 7:04 AM
To: rmoats@coreon.net
Cc: Quevedo, Felix; IETF Policy WG LIST; ietf-ldapbis@openldap.org;
ietf-ldapext@netscape.com
Subject: matching rules for directoryString [was: Re: CIM24 schema
tweaks]


rmoats@coreon.net wrote:
>
.[snip]
> What do you suggest as the
> equality match?  Based on my reading of the X.500-series and
> LDAP RFCs the only option for Directory Strings is
> caseIgnoreMatch, and I'm not at all comfortable with
> declaring that as the matching rule for a syntax that holds
> UTF-8 strings.
[snip]
>

I'm reading X.501 and X.520 from
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ (hurry for your
copy). Although these are drafts from the 4th edition of the X.500
series, it does not appear that the sections which apply to this
immediate issue are new or different from current/previous documents.

X.501 requires that the assertion syntax of the matching rule and
the syntax of attributes to which the matching rule is applied
must be equivalent. See section 13.5.

X.520 defines a caseExactMatch rule which applies to directoryString
attributes. See section 6.1.4.

Section 8 of RFC2252 does not mention a caseExactMatch rule which
applies to directoryString attributes. But neither does it appear that
section 8 was intended to describe the entire universe of allowable
or appropriate matching rules. Nothing in RFC2252's section 8 precludes
a Directory implementation from supporting matching rules beyond those
which are enumerated.

Section 3.3 of RFC2251 asserts LDAP's relationship to X.500 and the
requirement for LDAP servers to support the X.500 data and service
models.

Based on these facts, think it is reasonable to specify caseExactMatch
for directoryString attributes. Further, I think it is reasonable to
expect that Directory implementations will support it.

Also see http://www.alvestrand.no/objectid/2.5.13.5.html

Note that the specification of caseExactMatch for directoryString
attributes did not prevent RFCs 2713 and 2714 from obtaining.

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|




From majordomo@raleigh.ibm.com  Tue Dec  5 13:23:51 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00062
	for <policy-archive@odin.ietf.org>; Tue, 5 Dec 2000 13:23:51 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA22924;
	Tue, 5 Dec 2000 13:14:39 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA23500;
	Tue, 5 Dec 2000 13:14:34 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA46598; Tue, 5 Dec 2000 10:44:27 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA61168; Tue, 5 Dec 2000 10:44:23 -0500
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA29784
	for <policy@raleigh.ibm.com>; Tue, 5 Dec 2000 10:44:24 -0500
Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37])
	by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id KAA127238;
	Tue, 5 Dec 2000 10:44:22 -0500
Importance: Normal
Subject: RE: matching rules for directoryString [was: Re: CIM24 schema tweaks]
To: wg-ldap@www.dmtf.org
Cc: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>,
        "Quevedo, Felix" <FQuevedo@smartpipes.com>,
        "IETF Policy WG LIST" <policy@raleigh.ibm.com>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-Id: <OF9EB6C9B6.6C3F8174-ON852569AC.00569DFA@raleigh.ibm.com>
From: "Robert Moore" <remoore@us.ibm.com>
Date: Tue, 5 Dec 2000 10:48:48 -0500
X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at
 12/05/2000 10:44:47 AM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Robert Moore" <remoore@us.ibm.com>

Yes, there's going to be an -09 version.  Does this
mean we also need to add a reference to X.520 in the
References section?

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
remoore@us.ibm.com



"Ryan Moats" <rmoats@coreon.net>@www.dmtf.org on 12/05/2000 10:21:36 AM

Please respond to wg-ldap@www.dmtf.org

Sent by:  wg-ldap-owner@www.dmtf.org


To:   "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
cc:   "Quevedo, Felix" <FQuevedo@smartpipes.com>, "IETF Policy WG LIST"
      <policy@raleigh.ibm.com>
Subject:  RE: matching rules for directoryString [was: Re: CIM24 schema
      tweaks]



Thank you, Thank you, Thank you!

Having looked at the relevant section, I am MUCH more comfortable
with this than with caseIgnoreMatch.

I think caseExactMatch should be used for

- orderedCimKeys in the 2.4 Mapping
- policyKeywords, policyGroupName, policyRuleName, policyConditionName,
policyActionName, policyInstanceName, policyRepositoryName in the PCLS
(Hey Bob, there's going to be a -09 isn't there ;-)

Ryan

-----Original Message-----
From: lsbart35@mears.indy.cr.irs.gov
[mailto:lsbart35@mears.indy.cr.irs.gov]On Behalf Of Larry S. Bartz
Sent: Tuesday, December 05, 2000 7:04 AM
To: rmoats@coreon.net
Cc: Quevedo, Felix; IETF Policy WG LIST; ietf-ldapbis@openldap.org;
ietf-ldapext@netscape.com
Subject: matching rules for directoryString [was: Re: CIM24 schema
tweaks]


rmoats@coreon.net wrote:
>
.[snip]
> What do you suggest as the
> equality match?  Based on my reading of the X.500-series and
> LDAP RFCs the only option for Directory Strings is
> caseIgnoreMatch, and I'm not at all comfortable with
> declaring that as the matching rule for a syntax that holds
> UTF-8 strings.
[snip]
>

I'm reading X.501 and X.520 from
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ (hurry for your
copy). Although these are drafts from the 4th edition of the X.500
series, it does not appear that the sections which apply to this
immediate issue are new or different from current/previous documents.

X.501 requires that the assertion syntax of the matching rule and
the syntax of attributes to which the matching rule is applied
must be equivalent. See section 13.5.

X.520 defines a caseExactMatch rule which applies to directoryString
attributes. See section 6.1.4.

Section 8 of RFC2252 does not mention a caseExactMatch rule which
applies to directoryString attributes. But neither does it appear that
section 8 was intended to describe the entire universe of allowable
or appropriate matching rules. Nothing in RFC2252's section 8 precludes
a Directory implementation from supporting matching rules beyond those
which are enumerated.

Section 3.3 of RFC2251 asserts LDAP's relationship to X.500 and the
requirement for LDAP servers to support the X.500 data and service
models.

Based on these facts, think it is reasonable to specify caseExactMatch
for directoryString attributes. Further, I think it is reasonable to
expect that Directory implementations will support it.

Also see http://www.alvestrand.no/objectid/2.5.13.5.html

Note that the specification of caseExactMatch for directoryString
attributes did not prevent RFCs 2713 and 2714 from obtaining.

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|






From majordomo@raleigh.ibm.com  Tue Dec  5 14:23:41 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20603
	for <policy-archive@odin.ietf.org>; Tue, 5 Dec 2000 14:23:40 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA25166;
	Tue, 5 Dec 2000 14:14:31 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA25450;
	Tue, 5 Dec 2000 14:14:29 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA52800; Tue, 5 Dec 2000 11:17:28 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA53048; Tue, 5 Dec 2000 11:17:24 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA29552
	for <policy@raleigh.ibm.com>; Tue, 5 Dec 2000 11:17:26 -0500
Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA18836
	for <policy@raleigh.ibm.com>; Tue, 5 Dec 2000 11:17:23 -0500
Received: from rmoats2 (node-64-248-71-118.dslspeed.zyan.com [64.248.71.118])
	by mail.coreon.net (Mirapoint)
	with ESMTP id AAO53269 (AUTH rmoats);
	Tue, 5 Dec 2000 11:18:04 -0500 (EST)
From: "Ryan Moats" <rmoats@coreon.net>
To: "IETF Policy WG LIST" <policy@raleigh.ibm.com>
Subject: RE: matching rules for directoryString [was: Re: CIM24 schema tweaks]
Date: Tue, 5 Dec 2000 10:24:09 -0600
Message-Id: <OAEPJLLCHIJCOBJMOMBOAEBICIAA.rmoats@coreon.com>
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.2911.0)
Importance: Normal
In-Reply-To: <OF9EB6C9B6.6C3F8174-ON852569AC.00569DFA@raleigh.ibm.com>
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Ryan Moats" <rmoats@coreon.net>
Content-Transfer-Encoding: 7bit

Wouldn't be a bad idea at that :-)  I'm not sure what the exact
relevant information have. My guess would be

ITU, "Information Technology - Open System Interconnection - The Directory:
Selected Attribute Types," X.520 (11/93), 1995.

But I think I have an old copy.

Ryan

-----Original Message-----
From: wg-ldap-owner@www.dmtf.org [mailto:wg-ldap-owner@www.dmtf.org]On
Behalf Of Robert Moore
Sent: Tuesday, December 05, 2000 9:49 AM
To: wg-ldap@www.dmtf.org
Cc: Larry S. Bartz; Quevedo, Felix; IETF Policy WG LIST
Subject: RE: matching rules for directoryString [was: Re: CIM24 schema
tweaks]


Yes, there's going to be an -09 version.  Does this
mean we also need to add a reference to X.520 in the
References section?

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
remoore@us.ibm.com



"Ryan Moats" <rmoats@coreon.net>@www.dmtf.org on 12/05/2000 10:21:36 AM

Please respond to wg-ldap@www.dmtf.org

Sent by:  wg-ldap-owner@www.dmtf.org


To:   "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
cc:   "Quevedo, Felix" <FQuevedo@smartpipes.com>, "IETF Policy WG LIST"
      <policy@raleigh.ibm.com>
Subject:  RE: matching rules for directoryString [was: Re: CIM24 schema
      tweaks]



Thank you, Thank you, Thank you!

Having looked at the relevant section, I am MUCH more comfortable
with this than with caseIgnoreMatch.

I think caseExactMatch should be used for

- orderedCimKeys in the 2.4 Mapping
- policyKeywords, policyGroupName, policyRuleName, policyConditionName,
policyActionName, policyInstanceName, policyRepositoryName in the PCLS
(Hey Bob, there's going to be a -09 isn't there ;-)

Ryan

-----Original Message-----
From: lsbart35@mears.indy.cr.irs.gov
[mailto:lsbart35@mears.indy.cr.irs.gov]On Behalf Of Larry S. Bartz
Sent: Tuesday, December 05, 2000 7:04 AM
To: rmoats@coreon.net
Cc: Quevedo, Felix; IETF Policy WG LIST; ietf-ldapbis@openldap.org;
ietf-ldapext@netscape.com
Subject: matching rules for directoryString [was: Re: CIM24 schema
tweaks]


rmoats@coreon.net wrote:
>
.[snip]
> What do you suggest as the
> equality match?  Based on my reading of the X.500-series and
> LDAP RFCs the only option for Directory Strings is
> caseIgnoreMatch, and I'm not at all comfortable with
> declaring that as the matching rule for a syntax that holds
> UTF-8 strings.
[snip]
>

I'm reading X.501 and X.520 from
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ (hurry for your
copy). Although these are drafts from the 4th edition of the X.500
series, it does not appear that the sections which apply to this
immediate issue are new or different from current/previous documents.

X.501 requires that the assertion syntax of the matching rule and
the syntax of attributes to which the matching rule is applied
must be equivalent. See section 13.5.

X.520 defines a caseExactMatch rule which applies to directoryString
attributes. See section 6.1.4.

Section 8 of RFC2252 does not mention a caseExactMatch rule which
applies to directoryString attributes. But neither does it appear that
section 8 was intended to describe the entire universe of allowable
or appropriate matching rules. Nothing in RFC2252's section 8 precludes
a Directory implementation from supporting matching rules beyond those
which are enumerated.

Section 3.3 of RFC2251 asserts LDAP's relationship to X.500 and the
requirement for LDAP servers to support the X.500 data and service
models.

Based on these facts, think it is reasonable to specify caseExactMatch
for directoryString attributes. Further, I think it is reasonable to
expect that Directory implementations will support it.

Also see http://www.alvestrand.no/objectid/2.5.13.5.html

Note that the specification of caseExactMatch for directoryString
attributes did not prevent RFCs 2713 and 2714 from obtaining.

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|







From majordomo@raleigh.ibm.com  Tue Dec  5 15:02:38 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04218
	for <policy-archive@odin.ietf.org>; Tue, 5 Dec 2000 15:02:38 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA34540;
	Tue, 5 Dec 2000 14:48:57 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA07216;
	Tue, 5 Dec 2000 14:48:57 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA39184; Tue, 5 Dec 2000 12:21:06 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA53504; Tue, 5 Dec 2000 12:21:02 -0500
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA35692
	for <policy@raleigh.ibm.com>; Tue, 5 Dec 2000 12:21:04 -0500
Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37])
	by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id MAA118802;
	Tue, 5 Dec 2000 12:21:02 -0500
Importance: Normal
Subject: DSCP marking versus DSCP remarking
To: "'diffserv@ietf.org'" <diffserv@ietf.org>, policy@raleigh.ibm.com
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-Id: <OFACF3000E.2C79C597-ON852569AC.005D1768@raleigh.ibm.com>
From: "Robert Moore" <remoore@us.ibm.com>
Date: Tue, 5 Dec 2000 12:25:30 -0500
X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at
 12/05/2000 12:21:28 PM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Robert Moore" <remoore@us.ibm.com>

In the DiffServ Informal Model, MIB, and PIB, there
is a distinction drawn between a marker that marks
unmarked packets, and one that remarks packets that
had been marked previously.  This distinction appears
most clearly in section 6.1 of the Informal Model.
The MIB and the PIB make it implicitly, by importing
the terms "mark" and "remark" from the Informal Model.
This distinction presupposes that among the packets
coming into a marker, some can be identified as
already marked, and others can be identified as
unmarked.  I don't believe that this is the case.

In QDDIM, we have come down squarely on the side that
says there is no such thing as an unmarked packet, and
thus no distinction between packet marking and packet
remarking.  Every packet has one of 64 values, decimal
0 - 63, in the DSCP field.  Each of these values,
including 0, is a legitimate DSCP.  So a DSCP marker
always takes in a packet that is already marked with a
DSCP, and marks (or remarks - which word we choose isn't
important) the packet with another DSCP, which may or
may not be the same DSCP as the one the packet had
when it came into the marker.  Based on this view, we
removed from the MarkerService class in QDDIM a boolean
property CanRemark, which said whether a marker was
allowed to mark all packets, or only packets that were
not already marked when they got to it.

This is *almost* just a question of wordsmithing in the
three diffserv WG documents.  But not quite.  If there is
actual disagreement in the WG about whether there is such
a thing as an unmarked packet, that is, a packet that's
not marked with any DSCP, then the question should be
discussed until the WG reaches a consensus one way or the
other.  Does everybody agree with the QDDIM team that
there is no such thing as a packet unmarked with any DSCP?

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
remoore@us.ibm.com



From majordomo@raleigh.ibm.com  Tue Dec  5 19:59:30 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28534
	for <policy-archive@odin.ietf.org>; Tue, 5 Dec 2000 19:59:30 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA38896;
	Tue, 5 Dec 2000 19:50:30 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id TAA24846;
	Tue, 5 Dec 2000 19:50:25 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA48352; Tue, 5 Dec 2000 16:28:29 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA44248; Tue, 5 Dec 2000 16:28:26 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA32808
	for <policy@raleigh.ibm.com>; Tue, 5 Dec 2000 16:28:29 -0500
Received: from mailmaestro.smartpipes.com (mailmaestro.smartpipes.com [63.98.224.170])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA32198
	for <policy@raleigh.ibm.com>; Tue, 5 Dec 2000 16:28:25 -0500
Received: by mailmaestro.smartpipes.com with Internet Mail Service (5.5.2650.21)
	id <XYCWAX5P>; Tue, 5 Dec 2000 21:28:14 -0000
Message-Id: <8E1E94178828D143B34A560A7A6F2C0B0199AB41@mailmaestro.smartpipes.com>
From: "Wang, Cliff" <CWang@smartpipes.com>
To: "'Ed_Ellesson@tivoli.com'" <Ed_Ellesson@tivoli.com>
Cc: policy@raleigh.ibm.com, "Joel M. Halpern" <joel@longsys.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Subject: RE: Policy Framework WG Agendapolicy@raleigh.ibm.com
Date: Tue, 5 Dec 2000 21:28:13 -0000 
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Wang, Cliff" <CWang@smartpipes.com>

Ed,

Can you give the doc name/location with respect to QDDIM, QPIM, and all
other items listed in the agenda?
I am sure that the meeting goers would benefit if they have read the latest
documents before attending the meeting.

The other working group typically put the draft name in the agenda.

Thanks!



-----Original Message-----
From: Ed_Ellesson@tivoli.com [mailto:Ed_Ellesson@tivoli.com]
Sent: Monday, December 04, 2000 4:28 PM
To: agenda@ietf.org
Cc: policy@raleigh.ibm.com; Joel M. Halpern; Wijnen, Bert (Bert)
Subject: Policy Framework WG Agendapolicy@raleigh.ibm.com


We are still negotiating some of the specifics, but this is the agenda we
are posting for the IETF Working Group and BOF Agendas page:


Proposed Policy Framework Agenda:


Monday Afternoon, Dec. 11:  3:30 - 5:30pm (120 minutes)

1.  Intro/Objectives/Milestones:  Joel ,  10 minutes

2.  Agenda Bash:  Ed, 5 minutes

3.  QDDIM:  Bob Moore,  Editor.    Total: 30 minutes

      (20 minutes issues presentation, plus 10 min. for discussion)

4.  QPIM:  QPIM Author(s)   Total:  30 minutes

       (20 minutes issues presentation, plus 10 min. for discussion)

5.  QDIM/QPIM compatibility with DiffServ:    Total 30 minutes

     (Conceptual Model, MIB, and PIB Issues discussion)

6.  Wrap-up:   Ed and Joel, 15 minutes.

      (Summary and short re-review of Wed agenda)



Wednesday Morning, Dec. 13:  9:00 - 11:30am (150 minutes)

1.  Intro/News since Monday:  Ed and Joel, 5 minutes

2.  IPSP's PCIM-based Model:  Lee Rafalow/IPSP Participants:  Total 30
minutes

     (20 minutes issues presentation, plus 10 for discussion)

3.  Applying/Linking Policy to QDDIM, QPIM, IPSP:    30 minutes

     (Issues: Packet Classification, Priority, Policy/Configuration
Linkage, Other)

4.  PCLS Update:  PCLS Author(s):  10 minutes,  Ed Ellesson: 10 minutes:
Total
20 minutes

      (General PCLS issues update, plus Security Considerations issues):

5.  Terminology Draft Update/Issues and harmonization discussion:  Andrea:
20 minutes

6.  (If time permits) AAA Architecture:  Use of policy framework in context
of AAA Architecture:  Cees deLaat, and John Vollbrecht:  10 minutes

7.  (If time permits)  MPLS:  MPLS Policy Draft Author(s):    Use of policy
framework in context of MPLS:   10 minute update

8.  Wrap-up, and charter milestones re-visit:  25 minutes, Ed, Joel and
Bert


*********************

Thanks,

Ed and Joel




Ed Ellesson

ellesson@tivoli.com
Office at Tivoli:  919-224-2111
Office at home:  919-644-3977


From majordomo@raleigh.ibm.com  Wed Dec  6 11:20:48 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11559
	for <policy-archive@odin.ietf.org>; Wed, 6 Dec 2000 11:20:47 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA23846;
	Wed, 6 Dec 2000 11:10:11 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA31452;
	Wed, 6 Dec 2000 11:10:02 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA28222; Wed, 6 Dec 2000 10:31:04 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA28210; Wed, 6 Dec 2000 10:31:00 -0500
Received: from lmr (dyn9-37-48-47.raleigh.ibm.com [9.37.48.47])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA35382;
	Wed, 6 Dec 2000 10:31:02 -0500
Message-Id: <005701c05f99$45de3780$2f302509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <policy@raleigh.ibm.com>
Cc: <wg-ldap@dmtf.org>
References: <OAEPJLLCHIJCOBJMOMBOGEBFCIAA.rmoats@coreon.com>
Subject: Re: matching rules for directoryString [was: Re: CIM24 schema tweaks]
Date: Wed, 6 Dec 2000 10:29:05 -0500
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Lee Rafalow" <rafalow@raleigh.ibm.com>
Content-Transfer-Encoding: 7bit

So, now that we've resolved the question of what matching rules are
possible, let's address what matching rules we want to use.

Although the attributes listed below have been thought of as case exact in
the past (e.g., earlier drafts of PCLS when they were IA5string syntax), I'm
not sure we should stay with that interpretation.  The attributes listed
below are intended for search and/or rdn usage and requiring case exact
seems restrictive to me.  In most uses there's nothing about
policyGroupName=Atlanta Routers that's different from
policyGroupName=atlanta routers or policyRepositoryName=Southeast and
policyRepositoryName=southeast.   Further, if you look at other typically
used search and/or rdn attributes (e.g., cn, ou, o, l, etc.) they're cis.

Cheers, Lee

----- Original Message -----
From: "Ryan Moats" <rmoats@coreon.net>
To: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
Cc: "Quevedo, Felix" <FQuevedo@smartpipes.com>; "IETF Policy WG LIST"
<policy@raleigh.ibm.com>
Sent: Tuesday, December 05, 2000 10:21 AM
Subject: RE: matching rules for directoryString [was: Re: CIM24 schema
tweaks]


> Thank you, Thank you, Thank you!
>
> Having looked at the relevant section, I am MUCH more comfortable
> with this than with caseIgnoreMatch.
>
> I think caseExactMatch should be used for
>
> - orderedCimKeys in the 2.4 Mapping
> - policyKeywords, policyGroupName, policyRuleName, policyConditionName,
> policyActionName, policyInstanceName, policyRepositoryName in the PCLS
> (Hey Bob, there's going to be a -09 isn't there ;-)
>
> Ryan
>
> -----Original Message-----
> From: lsbart35@mears.indy.cr.irs.gov
> [mailto:lsbart35@mears.indy.cr.irs.gov]On Behalf Of Larry S. Bartz
> Sent: Tuesday, December 05, 2000 7:04 AM
> To: rmoats@coreon.net
> Cc: Quevedo, Felix; IETF Policy WG LIST; ietf-ldapbis@openldap.org;
> ietf-ldapext@netscape.com
> Subject: matching rules for directoryString [was: Re: CIM24 schema
> tweaks]
>
>
> rmoats@coreon.net wrote:
> >
> .[snip]
> > What do you suggest as the
> > equality match?  Based on my reading of the X.500-series and
> > LDAP RFCs the only option for Directory Strings is
> > caseIgnoreMatch, and I'm not at all comfortable with
> > declaring that as the matching rule for a syntax that holds
> > UTF-8 strings.
> [snip]
> >
>
> I'm reading X.501 and X.520 from
> ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ (hurry for your
> copy). Although these are drafts from the 4th edition of the X.500
> series, it does not appear that the sections which apply to this
> immediate issue are new or different from current/previous documents.
>
> X.501 requires that the assertion syntax of the matching rule and
> the syntax of attributes to which the matching rule is applied
> must be equivalent. See section 13.5.
>
> X.520 defines a caseExactMatch rule which applies to directoryString
> attributes. See section 6.1.4.
>
> Section 8 of RFC2252 does not mention a caseExactMatch rule which
> applies to directoryString attributes. But neither does it appear that
> section 8 was intended to describe the entire universe of allowable
> or appropriate matching rules. Nothing in RFC2252's section 8 precludes
> a Directory implementation from supporting matching rules beyond those
> which are enumerated.
>
> Section 3.3 of RFC2251 asserts LDAP's relationship to X.500 and the
> requirement for LDAP servers to support the X.500 data and service
> models.
>
> Based on these facts, think it is reasonable to specify caseExactMatch
> for directoryString attributes. Further, I think it is reasonable to
> expect that Directory implementations will support it.
>
> Also see http://www.alvestrand.no/objectid/2.5.13.5.html
>
> Note that the specification of caseExactMatch for directoryString
> attributes did not prevent RFCs 2713 and 2714 from obtaining.
>
> --
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
> # Larry Bartz                           |                              |
> #  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
> #                                       | Ooo, ooo, oooooo!            |
> #                                       | I've got a gnu attitude!     |
> #  voice (317) 226-7060                 |                              |
> #  FAX   (317) 226-6378                 |                              |
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
>



From majordomo@raleigh.ibm.com  Wed Dec  6 13:48:56 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15024
	for <policy-archive@odin.ietf.org>; Wed, 6 Dec 2000 13:48:54 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA23584;
	Wed, 6 Dec 2000 13:39:47 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA27062;
	Wed, 6 Dec 2000 13:39:05 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA52750; Wed, 6 Dec 2000 13:04:16 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA52460; Wed, 6 Dec 2000 13:04:09 -0500
Received: from lmr (dyn9-37-48-47.raleigh.ibm.com [9.37.48.47])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA22566;
	Wed, 6 Dec 2000 13:04:11 -0500
Message-Id: <008301c05fae$7719c660$2f302509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: "Jean Christophe Martin" <jean-christophe.martin@sun.com>,
        <policy@raleigh.ibm.com>, <ipsec-policy@vpnc.org>
References: <3A1AEFAD.41055193@sun.com>
Subject: QoS/IPSEC alignment questions
Date: Wed, 6 Dec 2000 13:00:47 -0500
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Lee Rafalow" <rafalow@raleigh.ibm.com>
Content-Transfer-Encoding: 7bit

Jean,

1. I think the difference between the condition representations can be
justified.

The IETF QDDIM and IPSP models (and their corresponding DMTF QoS and IPsec
models)are device-level models, i.e., in the PEP.  In these device-level
models, the intent is to create an object model that is reasonably close to
implementation structures and yet independent of any specific
implementation.  Filters are commonly used to determine packet handling and,
therefore, are used in these device-level models.

The QPIM model, on the other hand, is a domain-level model (i.e., in the
PMT, repository and/or PDP).  The approach taken in the current draft is
very general in its capability.  Without discussing the merits of the
"atoms" approach in the QPIM, for a domain-level policy specification this
generality might be seen as very beneficial.  But it's not likely that a
Diffserv PEP or an IKE service are going to have data structures that are
going to sacrifice the efficiency of filters in favor of that generality.

The question, then, comes down to how closely do we want the model and the
application of the model to be to one another.  So, this is not to say that
we shouldn't explore convergence here, it's just that we haven't to date
because of the perceived affinity to implementations at the two different
levels.

I hope this helps.

2. There's another divergence that you didn't mention that I've noticed and
that I'm less comfortable with.  It's in the handling of the rule priorities
as they're aggregated in policy groups.

Specifically, in the soon to be released DMTF IPsec model (and presumably in
Jamie's revision of the IPsec Configuration Policy Model when it's posted)
the IPsecPolicyGroupInPolicyGroup aggregation of groups has a GroupPriority
property that is used to assign absolute priorities to rules within groups
of groups.  The model uses the PolicyRule.RulePriority for the rule and, for
simplicity, we limit a rule to be in a single group.  But since groups can
be in multiple groups, it is the relationship between the groups that assign
the relative priorities of the contained rules to those contained in other
groups.

In QPIM, however, PolicyGroup subclasses are limited to a single parent in
the aggregation hierarchy.  With that limitation in mind, the gpPriority
property has been placed in the gpsPolicyGroup class instead of in the
aggregating relationship.

I believe that we should settle on a single way of prioritizing groups
within groups and that generality would lead to putting that priority into
the PolicyGroupInPolicyGroup subclasses.

There may be other alignment concerns but this is what I've spotted so far.

Lee

----- Original Message -----
From: "Jean Christophe Martin" <jean-christophe.martin@sun.com>
To: <policy@raleigh.ibm.com>
Sent: Tuesday, November 21, 2000 4:57 PM
Subject: QoS/IPSEC alignement questions


>
>
> I'm trying to understand how the QoS drafts are relating to the
> IPSEC drafts , and so far, I have little succes. For example :
>
>
> The IPSEC Policy Model is defining :
>
>  PolicyCondition
>         |
>    SACondition <----FilterofSACondition--->FilterList
>
>
>
> That should map, for the QoS, into :
>
>  PolicyCondition
>         |
>    QoSCondition <---FilterofQosCondition-->FilterList
>
>
> The FilterList is a list of FilterEntryBase that can either be
> QoS specific Filter Entries or plain FilterEntry as defined in
> CIM network model.
>
> However, in draft-ietf-policy-qos-info-model-01.txt, the Condition
> is using a complete different model.
>
> Is there any plan to update the documents : Policy Framework QoS
> Information Model and QoS Policy Schema to use a model like the
> IPSEC model that seems closer to the DMTF model ?
>
> Thanks
>
> JC.




From majordomo@raleigh.ibm.com  Wed Dec  6 14:43:35 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26575
	for <policy-archive@odin.ietf.org>; Wed, 6 Dec 2000 14:43:33 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA25050;
	Wed, 6 Dec 2000 14:34:22 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA06418;
	Wed, 6 Dec 2000 14:34:20 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43114; Wed, 6 Dec 2000 14:01:45 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA37730; Wed, 6 Dec 2000 14:01:42 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA26208;
	Wed, 6 Dec 2000 14:01:45 -0500
Received: from mx-relay1.treas.gov (mx-relay1.treas.gov [199.196.144.5])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA18808;
	Wed, 6 Dec 2000 14:01:41 -0500
Received: from tias4.treas.gov (tias-gw4.treas.gov [199.196.144.14])
	by mx-relay1.treas.gov (8.9.1b+Sun/8.9.3) with SMTP id OAA21680;
	Wed, 6 Dec 2000 14:02:10 -0500 (EST)
Received: from mailhub.net.treas.gov by tias4.treas.gov
          via smtpd (for mx-relay.treas.gov [199.196.144.5]) with SMTP; 6 Dec 2000 19:02:10 UT
Received: from mears.indy.cr.irs.gov (mailhub-2.net.treas.gov [10.7.8.10])
	by mailhub-2.net.treas.gov (8.9.1b+Sun/8.9.3) with ESMTP id OAA06215;
	Wed, 6 Dec 2000 14:02:04 -0500 (EST)
Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1])
	by mears.indy.cr.irs.gov (8.9.3/8.9.3) with ESMTP id OAA20350;
	Wed, 6 Dec 2000 14:01:59 -0500
Message-Id: <3A2E8D27.688DC79D@parnelli.indy.cr.irs.gov>
Date: Wed, 06 Dec 2000 14:01:59 -0500
From: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686)
X-Accept-Language: en
Mime-Version: 1.0
To: Lee Rafalow <rafalow@raleigh.ibm.com>
Cc: policy@raleigh.ibm.com, wg-ldap@dmtf.org
Subject: Re: matching rules for directoryString [was: Re: CIM24 schema tweaks]
References: <OAEPJLLCHIJCOBJMOMBOGEBFCIAA.rmoats@coreon.com> <005701c05f99$45de3780$2f302509@raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
Content-Transfer-Encoding: 7bit

Lee,

I think the answer depends in part on how much we care about supporting
internationalization, and for which attributes. "Ignore case" is 
meaningless (maybe dangerous) if the string is a UTF-8 representation 
of a non-ASCII character set.

I inferred from the draft's initial assignment of octetStringMatch to 
the orderedCimKeys attribute that there was a significant potential for
non-ASCII characters in the value. Did I infer correctly?

Is internationalization an issue for orderedCimKeys or any other 
directoryString attribute? 

If not, then I agree with you, Lee. caseIgnoreMatch makes the data
easier to use.

How about substring matching rules?

Several attributes will possess meaningful substrings in their values.
The schema should facilitate discovering those substrings. The
following attribute descriptions should designate
caseIgnoreSubstringsMatch
in addition to the existing caseIgnoreMatch designation:

- policyRoles
- ptpConditionTime
- ptpConditionTimeOfDayMask

Depending upon whether "exact" or "ignore" is applied to orderedCimKeys,
it should also be assigned the corresponding substring matching rule.


Lee Rafalow wrote:
> 
> So, now that we've resolved the question of what matching rules are
> possible, let's address what matching rules we want to use.
> 
> Although the attributes listed below have been thought of as case exact in
> the past (e.g., earlier drafts of PCLS when they were IA5string syntax), I'm
> not sure we should stay with that interpretation.  The attributes listed
> below are intended for search and/or rdn usage and requiring case exact
> seems restrictive to me.  In most uses there's nothing about
> policyGroupName=Atlanta Routers that's different from
> policyGroupName=atlanta routers or policyRepositoryName=Southeast and
> policyRepositoryName=southeast.   Further, if you look at other typically
> used search and/or rdn attributes (e.g., cn, ou, o, l, etc.) they're cis.
> 
> Cheers, Lee
> 
> ----- Original Message -----
> From: "Ryan Moats" <rmoats@coreon.net>
> To: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
> Cc: "Quevedo, Felix" <FQuevedo@smartpipes.com>; "IETF Policy WG LIST"
> <policy@raleigh.ibm.com>
> Sent: Tuesday, December 05, 2000 10:21 AM
> Subject: RE: matching rules for directoryString [was: Re: CIM24 schema
> tweaks]
> 
> > Thank you, Thank you, Thank you!
> >
> > Having looked at the relevant section, I am MUCH more comfortable
> > with this than with caseIgnoreMatch.
> >
> > I think caseExactMatch should be used for
> >
> > - orderedCimKeys in the 2.4 Mapping
> > - policyKeywords, policyGroupName, policyRuleName, policyConditionName,
> > policyActionName, policyInstanceName, policyRepositoryName in the PCLS
> > (Hey Bob, there's going to be a -09 isn't there ;-)
> >
> > Ryan
> >
> > -----Original Message-----
> > From: lsbart35@mears.indy.cr.irs.gov
> > [mailto:lsbart35@mears.indy.cr.irs.gov]On Behalf Of Larry S. Bartz
> > Sent: Tuesday, December 05, 2000 7:04 AM
> > To: rmoats@coreon.net
> > Cc: Quevedo, Felix; IETF Policy WG LIST; ietf-ldapbis@openldap.org;
> > ietf-ldapext@netscape.com
> > Subject: matching rules for directoryString [was: Re: CIM24 schema
> > tweaks]
> >
> >
> > rmoats@coreon.net wrote:
> > >
> > .[snip]
> > > What do you suggest as the
> > > equality match?  Based on my reading of the X.500-series and
> > > LDAP RFCs the only option for Directory Strings is
> > > caseIgnoreMatch, and I'm not at all comfortable with
> > > declaring that as the matching rule for a syntax that holds
> > > UTF-8 strings.
> > [snip]
> > >
> >
> > I'm reading X.501 and X.520 from
> > ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ (hurry for your
> > copy). Although these are drafts from the 4th edition of the X.500
> > series, it does not appear that the sections which apply to this
> > immediate issue are new or different from current/previous documents.
> >
> > X.501 requires that the assertion syntax of the matching rule and
> > the syntax of attributes to which the matching rule is applied
> > must be equivalent. See section 13.5.
> >
> > X.520 defines a caseExactMatch rule which applies to directoryString
> > attributes. See section 6.1.4.
> >
> > Section 8 of RFC2252 does not mention a caseExactMatch rule which
> > applies to directoryString attributes. But neither does it appear that
> > section 8 was intended to describe the entire universe of allowable
> > or appropriate matching rules. Nothing in RFC2252's section 8 precludes
> > a Directory implementation from supporting matching rules beyond those
> > which are enumerated.
> >
> > Section 3.3 of RFC2251 asserts LDAP's relationship to X.500 and the
> > requirement for LDAP servers to support the X.500 data and service
> > models.
> >
> > Based on these facts, think it is reasonable to specify caseExactMatch
> > for directoryString attributes. Further, I think it is reasonable to
> > expect that Directory implementations will support it.
> >
> > Also see http://www.alvestrand.no/objectid/2.5.13.5.html
> >
> > Note that the specification of caseExactMatch for directoryString
> > attributes did not prevent RFCs 2713 and 2714 from obtaining.
> >
> > --
> > #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
> > # Larry Bartz                           |                              |
> > #  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
> > #                                       | Ooo, ooo, oooooo!            |
> > #                                       | I've got a gnu attitude!     |
> > #  voice (317) 226-7060                 |                              |
> > #  FAX   (317) 226-6378                 |                              |
> > #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
> >

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|


From majordomo@raleigh.ibm.com  Wed Dec  6 17:04:46 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08738
	for <policy-archive@odin.ietf.org>; Wed, 6 Dec 2000 17:04:46 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA19046;
	Wed, 6 Dec 2000 16:55:34 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA30564;
	Wed, 6 Dec 2000 16:55:23 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA59586; Wed, 6 Dec 2000 16:24:56 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA53678; Wed, 6 Dec 2000 16:24:50 -0500
Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA32990
	for <policy@raleigh.ibm.com>; Wed, 6 Dec 2000 16:24:53 -0500
From: Ed_Ellesson@tivoli.com
Received: from schub.tivoli.com (schub.tivoli.com [146.84.104.17])
	by corp.tivoli.com (8.9.3/8.9.0) with ESMTP id PAA18260;
	Wed, 6 Dec 2000 15:25:20 -0600 (CST)
Importance: Normal
Subject: Drafts (RE: Policy Framework WG Agenda)
To: policy@raleigh.ibm.com, "Wang, Cliff" <CWang@smartpipes.com>
Cc: "'Ed_Ellesson@tivoli.com'" <Ed_Ellesson@tivoli.com>,
        "Joel M. Halpern" <joel@longsys.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Date: Wed, 6 Dec 2000 16:19:36 -0500
Message-Id: <OFEF6800CC.2907037F-ON852569AD.00577D0B@tivoli.com>
X-Mimetrack: Serialize by Router on SCHub/Tivoli Systems(Release 5.0.4a |July 24, 2000) at
 12/06/2000 03:24:17 PM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Ed_Ellesson@tivoli.com

Cliff,

>Can you give the doc name/location with respect to QDDIM, QPIM, and all
>other items listed in the agenda?

Yes, I can.  Sorry, that I did not include this info on the agenda.   By
the way, many of these are linked via the working group's charter web page,
but not all of them:

http://www.ietf.org/html.charters/policy-charter.html


If anyone sees anything that I missed, please comment to the list.


1.  Documents directly related to Policy Framework WG agenda:

PCIM:
http://www.ietf.org/internet-drafts/draft-ietf-policy-core-info-model-08.txt

QDDIM:
http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device-info-model-02.txt

QPIM:
http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info-model-02.txt

IPSP:   (see note 1)
http://www.ietf.org/internet-drafts/draft-ietf-ipsp-config-policy-model-01.txt

PCLS:
http://www.ietf.org/internet-drafts/draft-ietf-policy-core-info-model-08.txt

Policy Terminology:
http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-01.txt


DiffServ MIB:
http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-06.txt

DiffServ PIB:
http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-02.txt

DiffServ Conceptual Model:
http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-05.txt


2.  Requirements and Use Cases Drafts:  (see note 2, below)

Requirements:
http://www.ietf.org/internet-drafts/draft-ietf-policy-req-02.txt

Use Cases:
http://www.ietf.org/internet-drafts/draft-mahon-policy-use-00.txt

Managing Policy:
http://www.ietf.org/internet-drafts/draft-mahon-policy-mgmt-00.txt


3.  AAA Architecture and MPLS application of Policy:  (see note 3, below)

Policy for AAA:
http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-aaa-pol-00.txt

Generic Policy for AAA:
http://www.ietf.org/internet-drafts/draft-taal-aaaarch-generic-pol-00.txt

Policy for Accounting:
http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-pol-acct-01.txt

MPLS:
http://www.ietf.org/internet-drafts/draft-chadha-policy-mpls-te-01.txt



Notes:

1.  I think some work has been done on the ipsp model, since the ipsp draft
listed here, was issued.   I expect there will be another draft posted to
the ietf internet-draft repository, after the San Diego meeting, which will
reflect this additional work.

2.  The requirements, and use cases drafts will be mentioned during the
charter discussion at the beginning of the first session, but we don't
expect detailed discussions on the content of these drafts, at these IETF
sessions.

3.  We may not have time to get to the discussion of the AAA Architecture
and MPLS drafts, depending on how long the discussion of the QOS and IPsec
issues goes on.   We will make that call in the second session on
Wednesday.


Ed Ellesson
Tivoli Systems
Durham, NC
ellesson@tivoli.com
Office at Tivoli:  919-224-2111
Office at home:  919-644-3977



From majordomo@raleigh.ibm.com  Wed Dec  6 17:36:38 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18345
	for <policy-archive@odin.ietf.org>; Wed, 6 Dec 2000 17:36:37 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA35994;
	Wed, 6 Dec 2000 17:25:29 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA35458;
	Wed, 6 Dec 2000 17:25:30 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA37710; Wed, 6 Dec 2000 15:40:47 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA33094; Wed, 6 Dec 2000 15:40:44 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA26934;
	Wed, 6 Dec 2000 15:40:38 -0500
Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA27276;
	Wed, 6 Dec 2000 15:39:55 -0500
Received: from user-53.cisco.com ([144.254.95.35])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id WAA20748;
	Wed, 6 Dec 2000 22:39:44 +0200 (IST)
Message-Id: <4.3.2.7.2.20001206122857.00b37100@csi-admin1>
X-Sender: ronc@csi-admin1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 06 Dec 2000 12:39:00 -0800
To: "Lee Rafalow" <rafalow@raleigh.ibm.com>,
        "Jean Christophe Martin" <jean-christophe.martin@sun.com>,
        <policy@raleigh.ibm.com>, <ipsec-policy@vpnc.org>
From: Ron Cohen <ronc@cisco.com>
Subject: Re: QoS/IPSEC alignment questions
In-Reply-To: <008301c05fae$7719c660$2f302509@raleigh.ibm.com>
References: <3A1AEFAD.41055193@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Ron Cohen <ronc@cisco.com>

Lee,

I fully agree with point 1.

For the second point, in the QPIM 02 draft we explain the reuse of policy 
groups, i.e. we allow having more than one parent for each policy group. We 
have a section that discuss how to use priority in this case. The 
PolicyGroupInPolicyGroup aggregation is defined in PCIM, not in QPIM, 
without the additional priority property. I think that your proposal to 
include the priority in the aggregation is much more elegant. We might 
still do it by defining a new aggregation, or a derived one. Lets talk 
about this in the IETF and find the right solution.

Thanks
Ron


>Jean,
>
>1. I think the difference between the condition representations can be
>justified.
>
>The IETF QDDIM and IPSP models (and their corresponding DMTF QoS and IPsec
>models)are device-level models, i.e., in the PEP.  In these device-level
>models, the intent is to create an object model that is reasonably close to
>implementation structures and yet independent of any specific
>implementation.  Filters are commonly used to determine packet handling and,
>therefore, are used in these device-level models.
>
>The QPIM model, on the other hand, is a domain-level model (i.e., in the
>PMT, repository and/or PDP).  The approach taken in the current draft is
>very general in its capability.  Without discussing the merits of the
>"atoms" approach in the QPIM, for a domain-level policy specification this
>generality might be seen as very beneficial.  But it's not likely that a
>Diffserv PEP or an IKE service are going to have data structures that are
>going to sacrifice the efficiency of filters in favor of that generality.
>
>The question, then, comes down to how closely do we want the model and the
>application of the model to be to one another.  So, this is not to say that
>we shouldn't explore convergence here, it's just that we haven't to date
>because of the perceived affinity to implementations at the two different
>levels.
>
>I hope this helps.
>
>2. There's another divergence that you didn't mention that I've noticed and
>that I'm less comfortable with.  It's in the handling of the rule priorities
>as they're aggregated in policy groups.
>
>Specifically, in the soon to be released DMTF IPsec model (and presumably in
>Jamie's revision of the IPsec Configuration Policy Model when it's posted)
>the IPsecPolicyGroupInPolicyGroup aggregation of groups has a GroupPriority
>property that is used to assign absolute priorities to rules within groups
>of groups.  The model uses the PolicyRule.RulePriority for the rule and, for
>simplicity, we limit a rule to be in a single group.  But since groups can
>be in multiple groups, it is the relationship between the groups that assign
>the relative priorities of the contained rules to those contained in other
>groups.
>
>In QPIM, however, PolicyGroup subclasses are limited to a single parent in
>the aggregation hierarchy.  With that limitation in mind, the gpPriority
>property has been placed in the gpsPolicyGroup class instead of in the
>aggregating relationship.
>
>I believe that we should settle on a single way of prioritizing groups
>within groups and that generality would lead to putting that priority into
>the PolicyGroupInPolicyGroup subclasses.
>
>There may be other alignment concerns but this is what I've spotted so far.
>
>Lee
>
>----- Original Message -----
>From: "Jean Christophe Martin" <jean-christophe.martin@sun.com>
>To: <policy@raleigh.ibm.com>
>Sent: Tuesday, November 21, 2000 4:57 PM
>Subject: QoS/IPSEC alignement questions
>
>
> >
> >
> > I'm trying to understand how the QoS drafts are relating to the
> > IPSEC drafts , and so far, I have little succes. For example :
> >
> >
> > The IPSEC Policy Model is defining :
> >
> >  PolicyCondition
> >         |
> >    SACondition <----FilterofSACondition--->FilterList
> >
> >
> >
> > That should map, for the QoS, into :
> >
> >  PolicyCondition
> >         |
> >    QoSCondition <---FilterofQosCondition-->FilterList
> >
> >
> > The FilterList is a list of FilterEntryBase that can either be
> > QoS specific Filter Entries or plain FilterEntry as defined in
> > CIM network model.
> >
> > However, in draft-ietf-policy-qos-info-model-01.txt, the Condition
> > is using a complete different model.
> >
> > Is there any plan to update the documents : Policy Framework QoS
> > Information Model and QoS Policy Schema to use a model like the
> > IPSEC model that seems closer to the DMTF model ?
> >
> > Thanks
> >
> > JC.



From majordomo@raleigh.ibm.com  Wed Dec  6 18:38:14 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05740
	for <policy-archive@odin.ietf.org>; Wed, 6 Dec 2000 18:38:13 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA30900;
	Wed, 6 Dec 2000 18:28:59 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA24560;
	Wed, 6 Dec 2000 18:28:57 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA51404; Wed, 6 Dec 2000 17:52:11 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA37572; Wed, 6 Dec 2000 17:52:08 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA37468
	for <policy@raleigh.ibm.com>; Wed, 6 Dec 2000 17:52:13 -0500
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA29990
	for <policy@raleigh.ibm.com>; Wed, 6 Dec 2000 17:52:08 -0500
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Wed, 6 Dec 2000 17:51:41 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <Y239MXJ5>; Wed, 6 Dec 2000 17:51:43 -0500
Message-Id: <28560036253BD41191A10000F8BCBD11841D27@zcard00g.ca.nortel.com>
From: "Mircea Pana" <mpana@nortelnetworks.com>
To: "'policy@raleigh.ibm.com'" <policy@raleigh.ibm.com>
Subject: cardinality of policyRuleSequencedActions
Date: Wed, 6 Dec 2000 17:51:35 -0500
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C05FD7.15B191E0"
X-Orig: <mpana@americasm01.nt.com>
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Mircea Pana" <mpana@nortelnetworks.com>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C05FD7.15B191E0
Content-Type: text/plain;
	charset="iso-8859-1"

Wrt. the cardinality of some LDAP attributes defined in
"draft-ietf-policy-core-schema-08":

1. Isn't the "policyRuleSequencedActions" attribute supposed to be
single-valued (in "policyRule")? The document does not specify this
attribute's cardinality, which implies as default: multi-value.

2. Same comment for "ptpConditionTimeOfDayMask" attribute (in
"policyTimePeriodConditionAuxClass").
However, if this last one should be multi-valued, by extrapolation,
shouldn't the "ptpConditionTime" be multi-valued as well?

Thanks,  
Mircea Pana.

------_=_NextPart_001_01C05FD7.15B191E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>cardinality of policyRuleSequencedActions</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Wrt. the cardinality of some LDAP attributes defined =
in &quot;draft-ietf-policy-core-schema-08&quot;:</FONT>
</P>

<P><FONT SIZE=3D2>1. Isn't the &quot;policyRuleSequencedActions&quot; =
attribute supposed to be single-valued (in &quot;policyRule&quot;)? The =
document does not specify this attribute's cardinality, which implies =
as default: multi-value.</FONT></P>

<P><FONT SIZE=3D2>2. Same comment for =
&quot;ptpConditionTimeOfDayMask&quot; attribute (in =
&quot;policyTimePeriodConditionAuxClass&quot;).</FONT>
<BR><FONT SIZE=3D2>However, if this last one should be multi-valued, by =
extrapolation, shouldn't the &quot;ptpConditionTime&quot; be =
multi-valued as well?</FONT></P>

<P><FONT SIZE=3D2>Thanks,&nbsp; </FONT>
<BR><FONT SIZE=3D2>Mircea Pana.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C05FD7.15B191E0--


From majordomo@raleigh.ibm.com  Wed Dec  6 19:16:33 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14160
	for <policy-archive@odin.ietf.org>; Wed, 6 Dec 2000 19:16:33 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA33954;
	Wed, 6 Dec 2000 19:06:02 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id TAA33534;
	Wed, 6 Dec 2000 19:05:57 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA52688; Wed, 6 Dec 2000 18:32:10 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA41672; Wed, 6 Dec 2000 18:32:07 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA24426;
	Wed, 6 Dec 2000 18:32:10 -0500
Received: from mailmaestro.smartpipes.com (mailmaestro.smartpipes.com [63.98.224.170])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA31110;
	Wed, 6 Dec 2000 18:32:07 -0500
Received: by mailmaestro.smartpipes.com with Internet Mail Service (5.5.2650.21)
	id <YK0BAP08>; Wed, 6 Dec 2000 23:32:04 -0000
Message-Id: <8E1E94178828D143B34A560A7A6F2C0B01A6A115@mailmaestro.smartpipes.com>
From: "Quevedo, Felix" <FQuevedo@smartpipes.com>
To: "'Larry S. Bartz'" <lbartz@parnelli.indy.cr.irs.gov>,
        Lee Rafalow
	 <rafalow@raleigh.ibm.com>
Cc: policy@raleigh.ibm.com, wg-ldap@dmtf.org
Subject: RE: matching rules for directoryString [was: Re: CIM24 schema twe
	aks]
Date: Wed, 6 Dec 2000 23:32:04 -0000 
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Quevedo, Felix" <FQuevedo@smartpipes.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA14160

Larry, Lee,

I like the proposal for caseIgnoreMatch. Per the DSP0100 the content of
orderedCimKeys looks a lot like a DN. The DN Match is not a trivial MR to
implement. I can see developers validating components of the attribute
following similar rules as the ones for a DN. This means that string
pre-validation may well be base on the MR of the components.

The next question, is the usage. How will we build search filters? Does a
DirectoryString meet our need? I bet somebody thought about this. For a
orderedCimKeys of:

	DLM_Rack.CreationClassName=DLM_Rack,Tag=AcmeRack4279B

A valid filter for a caseIgnoreMatch DirectoryString would be:

	OrderedCimKeys=*_Rack.creationClass*b

Is this valid? Would there be a search per orderedCimKeys? Will all the
components be known for an exact match? Would the expected usage is that we
will always know exactly how an orderedCimKeys look like?

Quite interesting.

Félix E Quevedo
:) Smile, everything is possible!
E-Mail: fquevedo@smartpipes.com
Voice: 614 923 6242
Fax: 614 923 6299

 -----Original Message-----
From: 	Larry S. Bartz [mailto:lbartz@parnelli.indy.cr.irs.gov] 
Sent:	Wednesday, December 06, 2000 14:02
To:	Lee Rafalow
Cc:	policy@raleigh.ibm.com; wg-ldap@dmtf.org
Subject:	Re: matching rules for directoryString [was: Re: CIM24
schema tweaks]

Lee,

I think the answer depends in part on how much we care about supporting
internationalization, and for which attributes. "Ignore case" is 
meaningless (maybe dangerous) if the string is a UTF-8 representation 
of a non-ASCII character set.

I inferred from the draft's initial assignment of octetStringMatch to 
the orderedCimKeys attribute that there was a significant potential for
non-ASCII characters in the value. Did I infer correctly?

Is internationalization an issue for orderedCimKeys or any other 
directoryString attribute? 

If not, then I agree with you, Lee. caseIgnoreMatch makes the data
easier to use.

How about substring matching rules?

Several attributes will possess meaningful substrings in their values.
The schema should facilitate discovering those substrings. The
following attribute descriptions should designate
caseIgnoreSubstringsMatch
in addition to the existing caseIgnoreMatch designation:

- policyRoles
- ptpConditionTime
- ptpConditionTimeOfDayMask

Depending upon whether "exact" or "ignore" is applied to orderedCimKeys,
it should also be assigned the corresponding substring matching rule.


Lee Rafalow wrote:
> 
> So, now that we've resolved the question of what matching rules are
> possible, let's address what matching rules we want to use.
> 
> Although the attributes listed below have been thought of as case exact in
> the past (e.g., earlier drafts of PCLS when they were IA5string syntax),
I'm
> not sure we should stay with that interpretation.  The attributes listed
> below are intended for search and/or rdn usage and requiring case exact
> seems restrictive to me.  In most uses there's nothing about
> policyGroupName=Atlanta Routers that's different from
> policyGroupName=atlanta routers or policyRepositoryName=Southeast and
> policyRepositoryName=southeast.   Further, if you look at other typically
> used search and/or rdn attributes (e.g., cn, ou, o, l, etc.) they're cis.
> 
> Cheers, Lee
> 
> ----- Original Message -----
> From: "Ryan Moats" <rmoats@coreon.net>
> To: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
> Cc: "Quevedo, Felix" <FQuevedo@smartpipes.com>; "IETF Policy WG LIST"
> <policy@raleigh.ibm.com>
> Sent: Tuesday, December 05, 2000 10:21 AM
> Subject: RE: matching rules for directoryString [was: Re: CIM24 schema
> tweaks]
> 
> > Thank you, Thank you, Thank you!
> >
> > Having looked at the relevant section, I am MUCH more comfortable
> > with this than with caseIgnoreMatch.
> >
> > I think caseExactMatch should be used for
> >
> > - orderedCimKeys in the 2.4 Mapping
> > - policyKeywords, policyGroupName, policyRuleName, policyConditionName,
> > policyActionName, policyInstanceName, policyRepositoryName in the PCLS
> > (Hey Bob, there's going to be a -09 isn't there ;-)
> >
> > Ryan
> >
> > -----Original Message-----
> > From: lsbart35@mears.indy.cr.irs.gov
> > [mailto:lsbart35@mears.indy.cr.irs.gov]On Behalf Of Larry S. Bartz
> > Sent: Tuesday, December 05, 2000 7:04 AM
> > To: rmoats@coreon.net
> > Cc: Quevedo, Felix; IETF Policy WG LIST; ietf-ldapbis@openldap.org;
> > ietf-ldapext@netscape.com
> > Subject: matching rules for directoryString [was: Re: CIM24 schema
> > tweaks]
> >
> >
> > rmoats@coreon.net wrote:
> > >
> > .[snip]
> > > What do you suggest as the
> > > equality match?  Based on my reading of the X.500-series and
> > > LDAP RFCs the only option for Directory Strings is
> > > caseIgnoreMatch, and I'm not at all comfortable with
> > > declaring that as the matching rule for a syntax that holds
> > > UTF-8 strings.
> > [snip]
> > >
> >
> > I'm reading X.501 and X.520 from
> > ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ (hurry for your
> > copy). Although these are drafts from the 4th edition of the X.500
> > series, it does not appear that the sections which apply to this
> > immediate issue are new or different from current/previous documents.
> >
> > X.501 requires that the assertion syntax of the matching rule and
> > the syntax of attributes to which the matching rule is applied
> > must be equivalent. See section 13.5.
> >
> > X.520 defines a caseExactMatch rule which applies to directoryString
> > attributes. See section 6.1.4.
> >
> > Section 8 of RFC2252 does not mention a caseExactMatch rule which
> > applies to directoryString attributes. But neither does it appear that
> > section 8 was intended to describe the entire universe of allowable
> > or appropriate matching rules. Nothing in RFC2252's section 8 precludes
> > a Directory implementation from supporting matching rules beyond those
> > which are enumerated.
> >
> > Section 3.3 of RFC2251 asserts LDAP's relationship to X.500 and the
> > requirement for LDAP servers to support the X.500 data and service
> > models.
> >
> > Based on these facts, think it is reasonable to specify caseExactMatch
> > for directoryString attributes. Further, I think it is reasonable to
> > expect that Directory implementations will support it.
> >
> > Also see http://www.alvestrand.no/objectid/2.5.13.5.html
> >
> > Note that the specification of caseExactMatch for directoryString
> > attributes did not prevent RFCs 2713 and 2714 from obtaining.
> >
> > --
> > #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
> > # Larry Bartz                           |                              |
> > #  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
> > #                                       | Ooo, ooo, oooooo!            |
> > #                                       | I've got a gnu attitude!     |
> > #  voice (317) 226-7060                 |                              |
> > #  FAX   (317) 226-6378                 |                              |
> > #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
> >

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|


From majordomo@raleigh.ibm.com  Thu Dec  7 00:41:46 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20916
	for <policy-archive@odin.ietf.org>; Thu, 7 Dec 2000 00:41:45 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA38680;
	Thu, 7 Dec 2000 00:32:14 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id AAA28650;
	Thu, 7 Dec 2000 00:32:11 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA33030; Wed, 6 Dec 2000 23:52:49 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA56300; Wed, 6 Dec 2000 23:52:44 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id XAA34200
	for <policy@raleigh.ibm.com>; Wed, 6 Dec 2000 23:52:48 -0500
Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id XAA19978
	for <policy@raleigh.ibm.com>; Wed, 6 Dec 2000 23:52:44 -0500
Received: (qmail 14458 invoked from network); 7 Dec 2000 04:55:08 -0000
Received: from unknown (HELO osmium) (203.8.85.176)
  by arnie.adacel.com.au with SMTP; 7 Dec 2000 04:55:08 -0000
From: "Steven Legg" <steven.legg@adacel.com.au>
To: <rmoats@coreon.net>
Cc: "'Quevedo, Felix'" <FQuevedo@smartpipes.com>,
        "'Larry S. Bartz'" <lbartz@parnelli.indy.cr.irs.gov>,
        "'IETF Policy WG LIST'" <policy@raleigh.ibm.com>,
        <ietf-ldapext@netscape.com>
Subject: RE: CIM24 schema tweaks
Date: Thu, 7 Dec 2000 15:53:41 +1100
Message-Id: <000301c06009$acad61f0$b05508cb@osmium.adacel.com.au>
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 8.5, Build 4.71.2377.0
In-Reply-To: <200012020059.AAO48966@mail.coreon.net>
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0
Importance: Normal
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Steven Legg" <steven.legg@adacel.com.au>
Content-Transfer-Encoding: 7bit


Ryan,

> -----Original Message-----
> From: owner-ietf-ldapbis@OpenLDAP.org
> [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of rmoats@coreon.net
> Sent: Saturday, 2 December 2000 12:13
> To: Larry S. Bartz
> Cc: Quevedo, Felix; IETF Policy WG LIST; ietf-ldapbis@OpenLDAP.org;
> ietf-ldapext@netscape.com
> Subject: Re: CIM24 schema tweaks

[snip]

> >I've spotted another potential difficulty with the schema of
> DSP0117.
> >
> >See this description:
> >
> >attributetype    ( 1.3.6.1.4.1.412.100.1.2.1
> >     NAME 'orderedCimKeys'
> >     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE
> >     EQUALITY octetStringMatch
> >   )
> >
> >The matching rule syntax does not match the attribute's
> syntax. This
> >must be corrected.
>
> Well, as an editor, I get to play the "no complaints without
> making a suggestion" card.  What do you suggest as the
> equality match?  Based on my reading of the X.500-series and
> LDAP RFCs the only option for Directory Strings is
> caseIgnoreMatch, and I'm not at all comfortable with
> declaring that as the matching rule for a syntax that holds
> UTF-8 strings.
>
> Actually, the more I think about this, I think this is a
> bigger issue than just Policy, so I'm cross posting to
> ldapext and the newly minted ldapbis to see what those
> folks can add.

It was attributes like orderedCimKeys that motivated me to write the
component
matching rules draft (draft-legg-ldapext-component-matching-00.txt).
The content of the orderedCimKeys attribute is structured data with a well
defined format, rather than free text, so a specific new attribute
syntax is warranted. Stuffing highly structured data into attributes
with the Directory String syntax means that the directory can do nothing
more than treat values as opaque blobs of bytes. Almost inevitably the
question of a suitable equality matching rule is raised because the
existing string matching rules are not designed for matching structured
data.

The component matching rules are intended to provide convenient default
equality matching rules for structured data, as well as a generic capability
(that is more expressive than simple substring matching) to filter match
component parts of the structured attribute values. The key to all this
is a formal way to describe the structure of the data, which for the
component matching rules is ASN.1 type notation.

I note that the structure of an LDAP string encoded value of orderedCimKeys
is described by:

    <className>.<key>=<value>[,<key>=<value>]*

Without looking into the details, I'm guessing that something like the
following ASN.1 type would adequately describe the conceptual structure
of the syntax.

	OrderedCIMKeys ::= SEQUENCE {
		className	UTF8String,
		keys		SEQUENCE SIZE (1..MAX) OF {
			key			UTF8String,
			value		UTF8String } }

This is enough to completely define the behaviour of the
directoryComponentsMatch matching rule (a component by component equality
match) on a value of orderedCimKeys. If the default matching of
directoryComponentsMatch doesn't quite suit a particular application then
there is an easy way of extending it to define, for example, a
policyComponentsMatch matching rule that is more generally suitable for
policy attribute syntaxes.

The ASN.1 type definition for the syntax is also sufficient to completely
define the behaviour of the componentFilterMatch matching rule. This
matching
rule would provide the ability to search for orderCimKeys values with
particular class names, particular key types, or particular (key, value)
pairs, etc, in whatever filter combinations a user might want.

These matching capabilities are completely specified just by writing down an
ASN.1 definition of a syntax. Having that definition also opens up the
possibility of the directory doing other useful things with values.
For example, in the not too distant future directory servers may be
receiving and returning XML encoded versions of attribute values.
If the attribute syntax is a bland directory string then the XML
encoding of, say, a value of orderedCimKeys will look something like this:

	<orderedCIMKeys>
		whatever.abc=vvvv,def=wwww
	</orderedCIMKeys>

whereas a knowledge of the structure of the data will allow the directory
to produce XML encodings that are more meaningfully marked up (and more
verbose of course) as in the following:

	<orderedCIMKeys>
		<className>
			whatever
		</className>
		<keys>
			<instance>
				<key>abc</key>
				<value>vvvv</value>
			</instance>
			<instance>
				<key>def</key>
				<value>wwww</value>
			</instance>
		</keys>
	</orderedCIMKeys>

The component matching rules make it easy for applications to define
powerful
matching capabilities, but the directory servers have to implement those
capabilities, so there is an initial implementation barrier on the
directory server side. My hope is that directory server vendors will take
advantage of the fact that the component matching framework lends itself
to high levels of automation, whereby exotic new application syntaxes can
be easily and quickly accommodated (through run-time interpretation or
compiled plug-ins).

Regards,
Steven

>
> Ryan Moats
>



From majordomo@raleigh.ibm.com  Thu Dec  7 02:26:48 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11296
	for <policy-archive@odin.ietf.org>; Thu, 7 Dec 2000 02:26:48 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id CAA38770;
	Thu, 7 Dec 2000 02:17:09 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id CAA29136;
	Thu, 7 Dec 2000 02:17:06 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA58466; Thu, 7 Dec 2000 01:36:38 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA36950; Thu, 7 Dec 2000 01:36:34 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id BAA28704
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 01:36:39 -0500
Received: from web10501.mail.yahoo.com (web10501.mail.yahoo.com [216.136.130.151])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id BAA37252
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 01:36:37 -0500
Message-Id: <20001207063636.22236.qmail@web10501.mail.yahoo.com>
Received: from [198.206.187.100] by web10501.mail.yahoo.com; Wed, 06 Dec 2000 22:36:36 PST
Date: Wed, 6 Dec 2000 22:36:36 -0800 (PST)
From: Mahadevan Iyer <iyermahadevan@yahoo.com>
Subject: gpsPolicyGroup class in qos info model
To: policy@raleigh.ibm.com, ipsec-policy@vpnc.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Mahadevan Iyer <iyermahadevan@yahoo.com>

I would like to suggest an update to the
gpsPolicyGroup class.
This also relates to the PolicyRuleInPolicyRule usage.

I need to indicate that a group of policy rules should
be checked only if the traffic matches some aggregate
conditions. These aggregate conditions summarize the
conditions within the policy rules.

I would like to specify the aggregate conditions at
the level of the gpsPolicyGroup. An alternative is to
use the PolicyRule + PolicyRuleInPolicyRule instead of
the gpsPolicyGroup. However I prefer to use the
gpsPolicyGroup.

I would suggest adding an aggregate policy condition
to the gpsPolicyGroup. This condition would typically
be a gpsPolicyCompoundCondition.


Thanks

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/


From majordomo@raleigh.ibm.com  Thu Dec  7 04:28:53 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12585
	for <policy-archive@odin.ietf.org>; Thu, 7 Dec 2000 04:28:53 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA26716;
	Thu, 7 Dec 2000 04:16:52 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id EAA18772;
	Thu, 7 Dec 2000 04:16:51 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA31688; Thu, 7 Dec 2000 03:34:33 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA31728; Thu, 7 Dec 2000 03:34:11 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id DAA35242
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 03:34:11 -0500
Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA33014
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 03:34:08 -0500
Received: from user-53.cisco.com (telaviv3-dhcp153.cisco.com [144.254.93.91])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id KAA05329;
	Thu, 7 Dec 2000 10:34:00 +0200 (IST)
Message-Id: <4.3.2.7.2.20001207003148.00b3a240@csi-admin1>
X-Sender: ronc@csi-admin1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 07 Dec 2000 00:33:15 -0800
To: Mahadevan Iyer <iyermahadevan@yahoo.com>, policy@raleigh.ibm.com,
        ipsec-policy@vpnc.org
From: Ron Cohen <ronc@cisco.com>
Subject: Re: gpsPolicyGroup class in qos info model
In-Reply-To: <20001207063636.22236.qmail@web10501.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Ron Cohen <ronc@cisco.com>

Mahadevan,

Can you provide more details why you prefer to change the gpsPolicyGroup 
than using the current policyRuleInPolicyRule method?

Thanks
Ron


>I would like to suggest an update to the
>gpsPolicyGroup class.
>This also relates to the PolicyRuleInPolicyRule usage.
>
>I need to indicate that a group of policy rules should
>be checked only if the traffic matches some aggregate
>conditions. These aggregate conditions summarize the
>conditions within the policy rules.
>
>I would like to specify the aggregate conditions at
>the level of the gpsPolicyGroup. An alternative is to
>use the PolicyRule + PolicyRuleInPolicyRule instead of
>the gpsPolicyGroup. However I prefer to use the
>gpsPolicyGroup.
>
>I would suggest adding an aggregate policy condition
>to the gpsPolicyGroup. This condition would typically
>be a gpsPolicyCompoundCondition.
>
>
>Thanks
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Shopping - Thousands of Stores. Millions of Products.
>http://shopping.yahoo.com/



From majordomo@raleigh.ibm.com  Thu Dec  7 08:40:54 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18116
	for <policy-archive@odin.ietf.org>; Thu, 7 Dec 2000 08:40:54 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA31048;
	Thu, 7 Dec 2000 08:30:53 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA33984;
	Thu, 7 Dec 2000 08:30:47 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA46110; Thu, 7 Dec 2000 07:52:24 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA62742; Thu, 7 Dec 2000 07:52:20 -0500
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id HAA31526
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 07:52:22 -0500
Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37])
	by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id HAA48430;
	Thu, 7 Dec 2000 07:52:19 -0500
Importance: Normal
Subject: Re: Drafts (RE: Policy Framework WG Agenda)
To: Ed_Ellesson@tivoli.com
Cc: policy@raleigh.ibm.com, "Wang, Cliff" <CWang@smartpipes.com>,
        "'Ed_Ellesson@tivoli.com'" <Ed_Ellesson@tivoli.com>,
        "Joel M. Halpern" <joel@longsys.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-Id: <OF18501991.63EACBDB-ON852569AE.00470083@raleigh.ibm.com>
From: "Robert Moore" <remoore@us.ibm.com>
Date: Thu, 7 Dec 2000 07:56:52 -0500
X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at
 12/07/2000 07:52:47 AM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Robert Moore" <remoore@us.ibm.com>

Ed,

I spotted a typo in your note.  The correct URL for the PCLS is

http://ietf-mirror.raleigh.ibm.com/internet-drafts/draft-ietf-policy-core-schema-08.txt


Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
remoore@us.ibm.com



From majordomo@raleigh.ibm.com  Thu Dec  7 09:38:08 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24953
	for <policy-archive@odin.ietf.org>; Thu, 7 Dec 2000 09:38:07 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA24392;
	Thu, 7 Dec 2000 09:19:37 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA28684;
	Thu, 7 Dec 2000 09:19:35 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA23810; Thu, 7 Dec 2000 08:45:57 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA58848; Thu, 7 Dec 2000 08:45:53 -0500
Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA25274
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 08:45:54 -0500
From: Ed_Ellesson@tivoli.com
Received: from schub.tivoli.com (schub.tivoli.com [146.84.104.17])
	by corp.tivoli.com (8.9.3/8.9.0) with ESMTP id HAA16808;
	Thu, 7 Dec 2000 07:46:17 -0600 (CST)
Importance: Normal
Subject: Re: Drafts (RE: Policy Framework WG Agenda)
To: "Robert Moore" <remoore@us.ibm.com>
Cc: Ed_Ellesson@tivoli.com, policy@raleigh.ibm.com,
        "Wang, Cliff" <CWang@smartpipes.com>,
        "'Ed_Ellesson@tivoli.com'" <Ed_Ellesson@tivoli.com>,
        "Joel M. Halpern" <joel@longsys.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Date: Thu, 7 Dec 2000 08:40:28 -0500
Message-Id: <OF2AECF366.2C78EFE5-ON852569AE.004B905C@tivoli.com>
X-Mimetrack: Serialize by Router on SCHub/Tivoli Systems(Release 5.0.4a |July 24, 2000) at
 12/07/2000 07:45:12 AM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Ed_Ellesson@tivoli.com

Bob,

Yes, thank you....I had the info model url rather than the schema url
listed for pcls.  The url from the ietf repository is:

http://www.ietf.org/internet-drafts/draft-ietf-policy-core-schema-08.txt



Ed Ellesson
Tivoli Systems
Durham, NC
ellesson@tivoli.com
Office at Tivoli:  919-224-2111
Office at home:  919-644-3977


"Robert Moore" <remoore@us.ibm.com> on 12/07/2000 07:56:52 AM

To:   Ed_Ellesson@tivoli.com
cc:   policy@raleigh.ibm.com, "Wang, Cliff" <CWang@smartpipes.com>,
      "'Ed_Ellesson@tivoli.com'" <Ed_Ellesson@tivoli.com>, "Joel M.
      Halpern" <joel@longsys.com>, "Wijnen, Bert (Bert)"
      <bwijnen@lucent.com>
Subject:  Re: Drafts (RE: Policy Framework WG Agenda)



Ed,

I spotted a typo in your note.  The correct URL for the PCLS is

http://ietf-mirror.raleigh.ibm.com/internet-drafts/draft-ietf-policy-core-schema-08.txt



Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
remoore@us.ibm.com





From majordomo@raleigh.ibm.com  Thu Dec  7 12:36:20 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29974
	for <policy-archive@odin.ietf.org>; Thu, 7 Dec 2000 12:36:20 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA32316;
	Thu, 7 Dec 2000 12:21:45 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA29878;
	Thu, 7 Dec 2000 12:21:36 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA54894; Thu, 7 Dec 2000 11:47:20 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA30054; Thu, 7 Dec 2000 11:47:17 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA22838
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 11:47:19 -0500
Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA30312
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 11:47:15 -0500
Received: from rmoats2 (node-64-248-71-118.dslspeed.zyan.com [64.248.71.118])
	by mail.coreon.net (Mirapoint)
	with ESMTP id AAO58934 (AUTH rmoats);
	Thu, 7 Dec 2000 11:47:44 -0500 (EST)
From: "Ryan Moats" <rmoats@coreon.net>
To: <steven.legg@adacel.com.au>
Cc: "'IETF Policy WG LIST'" <policy@raleigh.ibm.com>,
        <ietf-ldapext@netscape.com>
Subject: RE: CIM24 schema tweaks
Date: Thu, 7 Dec 2000 10:54:04 -0600
Message-Id: <OAEPJLLCHIJCOBJMOMBOKEFDCIAA.rmoats@coreon.com>
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.2911.0)
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <000301c06009$acad61f0$b05508cb@osmium.adacel.com.au>
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Ryan Moats" <rmoats@coreon.net>
Content-Transfer-Encoding: 7bit

Since this is a standards track document, I do not
want to use something that creates a dependency and
will hold up the document.

Ryan

-----Original Message-----

Ryan,

> -----Original Message-----

[snip]

> >I've spotted another potential difficulty with the schema of
> DSP0117.
> >
> >See this description:
> >
> >attributetype    ( 1.3.6.1.4.1.412.100.1.2.1
> >     NAME 'orderedCimKeys'
> >     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE
> >     EQUALITY octetStringMatch
> >   )
> >
> >The matching rule syntax does not match the attribute's
> syntax. This
> >must be corrected.
>
> Well, as an editor, I get to play the "no complaints without
> making a suggestion" card.  What do you suggest as the
> equality match?  Based on my reading of the X.500-series and
> LDAP RFCs the only option for Directory Strings is
> caseIgnoreMatch, and I'm not at all comfortable with
> declaring that as the matching rule for a syntax that holds
> UTF-8 strings.
>
> Actually, the more I think about this, I think this is a
> bigger issue than just Policy, so I'm cross posting to
> ldapext and the newly minted ldapbis to see what those
> folks can add.

It was attributes like orderedCimKeys that motivated me to write the
component
matching rules draft (draft-legg-ldapext-component-matching-00.txt).
The content of the orderedCimKeys attribute is structured data with a well
defined format, rather than free text, so a specific new attribute
syntax is warranted. Stuffing highly structured data into attributes
with the Directory String syntax means that the directory can do nothing
more than treat values as opaque blobs of bytes. Almost inevitably the
question of a suitable equality matching rule is raised because the
existing string matching rules are not designed for matching structured
data.

The component matching rules are intended to provide convenient default
equality matching rules for structured data, as well as a generic capability
(that is more expressive than simple substring matching) to filter match
component parts of the structured attribute values. The key to all this
is a formal way to describe the structure of the data, which for the
component matching rules is ASN.1 type notation.

I note that the structure of an LDAP string encoded value of orderedCimKeys
is described by:

    <className>.<key>=<value>[,<key>=<value>]*

Without looking into the details, I'm guessing that something like the
following ASN.1 type would adequately describe the conceptual structure
of the syntax.

	OrderedCIMKeys ::= SEQUENCE {
		className	UTF8String,
		keys		SEQUENCE SIZE (1..MAX) OF {
			key			UTF8String,
			value		UTF8String } }

This is enough to completely define the behaviour of the
directoryComponentsMatch matching rule (a component by component equality
match) on a value of orderedCimKeys. If the default matching of
directoryComponentsMatch doesn't quite suit a particular application then
there is an easy way of extending it to define, for example, a
policyComponentsMatch matching rule that is more generally suitable for
policy attribute syntaxes.

The ASN.1 type definition for the syntax is also sufficient to completely
define the behaviour of the componentFilterMatch matching rule. This
matching
rule would provide the ability to search for orderCimKeys values with
particular class names, particular key types, or particular (key, value)
pairs, etc, in whatever filter combinations a user might want.

These matching capabilities are completely specified just by writing down an
ASN.1 definition of a syntax. Having that definition also opens up the
possibility of the directory doing other useful things with values.
For example, in the not too distant future directory servers may be
receiving and returning XML encoded versions of attribute values.
If the attribute syntax is a bland directory string then the XML
encoding of, say, a value of orderedCimKeys will look something like this:

	<orderedCIMKeys>
		whatever.abc=vvvv,def=wwww
	</orderedCIMKeys>

whereas a knowledge of the structure of the data will allow the directory
to produce XML encodings that are more meaningfully marked up (and more
verbose of course) as in the following:

	<orderedCIMKeys>
		<className>
			whatever
		</className>
		<keys>
			<instance>
				<key>abc</key>
				<value>vvvv</value>
			</instance>
			<instance>
				<key>def</key>
				<value>wwww</value>
			</instance>
		</keys>
	</orderedCIMKeys>

The component matching rules make it easy for applications to define
powerful
matching capabilities, but the directory servers have to implement those
capabilities, so there is an initial implementation barrier on the
directory server side. My hope is that directory server vendors will take
advantage of the fact that the component matching framework lends itself
to high levels of automation, whereby exotic new application syntaxes can
be easily and quickly accommodated (through run-time interpretation or
compiled plug-ins).

Regards,
Steven

>
> Ryan Moats
>




From majordomo@raleigh.ibm.com  Thu Dec  7 13:35:43 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08352
	for <policy-archive@odin.ietf.org>; Thu, 7 Dec 2000 13:35:38 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA28720;
	Thu, 7 Dec 2000 13:05:00 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA33604;
	Thu, 7 Dec 2000 13:02:55 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA35598; Thu, 7 Dec 2000 12:30:18 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA54788; Thu, 7 Dec 2000 12:30:14 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA24496
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 12:30:17 -0500
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA15086
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 12:30:12 -0500
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 7 Dec 2000 12:29:34 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <YMXD8JK7>; Thu, 7 Dec 2000 12:29:35 -0500
Message-Id: <28560036253BD41191A10000F8BCBD11841D29@zcard00g.ca.nortel.com>
From: "Mircea Pana" <mpana@nortelnetworks.com>
To: "'Robert Moore'" <remoore@us.ibm.com>
Cc: "'policy@raleigh.ibm.com'" <policy@raleigh.ibm.com>
Subject: RE: cardinality of policyRuleSequencedActions
Date: Thu, 7 Dec 2000 12:29:33 -0500
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C06073.43855150"
X-Orig: <mpana@americasm01.nt.com>
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Mircea Pana" <mpana@nortelnetworks.com>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C06073.43855150
Content-Type: text/plain;
	charset="iso-8859-1"

Bob,

For consistency I would have both attributes (ptpConditionTime and
ptpConditionTimeOfDayMask) with the same cardinality.

If these attributes are single-value, this may lead to a higher number of
policyTimePeriodCondition[AuxClass] entries necessary to specify the
validity period.
On the other hand, if they are multi-valued, the semantics of the
policyTimePeriodCondition[AuxClass] are overloaded. Therefore, an increase
in complexity of the provisioning and consumption activities.

I tend to be in favor of the single-valued option due to its reduced
complexity.

However, in an environment where the "LDAP Control for a Duplicate Entry
Representation of Search Results"
(http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-dupent-06.txt
) is used, the client experience could be similar in both cases.

Regards,
Mircea.

> -----Original Message-----
> From: Robert Moore [mailto:remoore@us.ibm.com]
> Sent: Thursday, December 07, 2000 10:38 AM
> To: Pana, Mircea [CAR:5E10:EXCH]
> Cc: 'policy@raleigh.ibm.com'
> Subject: Re: cardinality of policyRuleSequencedActions
> 
> 
> Mircea,
> 
> You're definitely right about #1 -- I've already changed
> this in the PCLS source file.
> 
> For #2, I *think* that having it multi-valued was
> intentional, but I'm not really sure.  The idea would be
> to allow us to represent in a single object a schedule
> like 0800 to 1200 AND 1300 to 1700.  I don't know if such
> schedules will be common enough to warrant the extra
> complexity.
> 
> One further factor:  both of the ptpCondition properties
> in PCIM that correspond to these two attributes are
> single-valued.  So we either need to change
> ptpConditionTimeOfDayMask to single-valued (and leave
> ptpConditionTime single-valued), or else make one or both
> of them multi-valued, and track the corresponding change
> to PCIM as our first piece of Proposed Standard
> implementation experience.  I could go either way, but my
> vote would be to make the two attributes single-valued,
> on the grounds that in general we've applied more careful
> thought to PCIM than we have to PCLS.
> 
> Regards,
> Bob
> 
> Bob Moore
> IBM Networking Software
> +1-919-254-4436
> remoore@us.ibm.com
> 
> 
> 
> "Mircea Pana" <mpana@nortelnetworks.com>@raleigh.ibm.com on 12/06/2000
> 05:51:35 PM
> 
> Please respond to "Mircea Pana" <mpana@nortelnetworks.com>
> 
> Sent by:  policy-owner@raleigh.ibm.com
> 
> 
> To:   "'policy@raleigh.ibm.com'" <policy@raleigh.ibm.com>
> cc:
> Subject:  cardinality of policyRuleSequencedActions
> 
> 
> 
> 
> 
> Wrt. the cardinality of some LDAP attributes defined in
> "draft-ietf-policy-core-schema-08":
> 
> 1. Isn't the "policyRuleSequencedActions" attribute supposed to be
> single-valued (in "policyRule")? The document does not specify this
> attribute's cardinality, which implies as default: multi-value.
> 
> 2. Same comment for "ptpConditionTimeOfDayMask" attribute (in
> "policyTimePeriodConditionAuxClass").
> However, if this last one should be multi-valued, by extrapolation,
> shouldn't the "ptpConditionTime" be multi-valued as well?
> 
> Thanks,
> Mircea Pana.
> 
> 
> 
> 

------_=_NextPart_001_01C06073.43855150
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: cardinality of policyRuleSequencedActions</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Bob,</FONT>
</P>

<P><FONT SIZE=3D2>For consistency I would have both attributes =
(ptpConditionTime and ptpConditionTimeOfDayMask) with the same =
cardinality.</FONT></P>

<P><FONT SIZE=3D2>If these attributes are single-value, this may lead =
to a higher number of policyTimePeriodCondition[AuxClass] entries =
necessary to specify the validity period.</FONT></P>

<P><FONT SIZE=3D2>On the other hand, if they are multi-valued, the =
semantics of the policyTimePeriodCondition[AuxClass] are overloaded. =
Therefore, an increase in complexity of the provisioning and =
consumption activities.</FONT></P>

<P><FONT SIZE=3D2>I tend to be in favor of the single-valued option due =
to its reduced complexity.</FONT>
</P>

<P><FONT SIZE=3D2>However, in an environment where the &quot;LDAP =
Control for a Duplicate Entry Representation of Search Results&quot; =
(<A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-du=
pent-06.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-ldapext=
-ldapv3-dupent-06.txt</A>) is used, the client experience could be =
similar in both cases.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Mircea.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Robert Moore [<A =
HREF=3D"mailto:remoore@us.ibm.com">mailto:remoore@us.ibm.com</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; Sent: Thursday, December 07, 2000 10:38 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Pana, Mircea [CAR:5E10:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'policy@raleigh.ibm.com'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: cardinality of =
policyRuleSequencedActions</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Mircea,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; You're definitely right about #1 -- I've =
already changed</FONT>
<BR><FONT SIZE=3D2>&gt; this in the PCLS source file.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; For #2, I *think* that having it multi-valued =
was</FONT>
<BR><FONT SIZE=3D2>&gt; intentional, but I'm not really sure.&nbsp; The =
idea would be</FONT>
<BR><FONT SIZE=3D2>&gt; to allow us to represent in a single object a =
schedule</FONT>
<BR><FONT SIZE=3D2>&gt; like 0800 to 1200 AND 1300 to 1700.&nbsp; I =
don't know if such</FONT>
<BR><FONT SIZE=3D2>&gt; schedules will be common enough to warrant the =
extra</FONT>
<BR><FONT SIZE=3D2>&gt; complexity.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; One further factor:&nbsp; both of the =
ptpCondition properties</FONT>
<BR><FONT SIZE=3D2>&gt; in PCIM that correspond to these two attributes =
are</FONT>
<BR><FONT SIZE=3D2>&gt; single-valued.&nbsp; So we either need to =
change</FONT>
<BR><FONT SIZE=3D2>&gt; ptpConditionTimeOfDayMask to single-valued (and =
leave</FONT>
<BR><FONT SIZE=3D2>&gt; ptpConditionTime single-valued), or else make =
one or both</FONT>
<BR><FONT SIZE=3D2>&gt; of them multi-valued, and track the =
corresponding change</FONT>
<BR><FONT SIZE=3D2>&gt; to PCIM as our first piece of Proposed =
Standard</FONT>
<BR><FONT SIZE=3D2>&gt; implementation experience.&nbsp; I could go =
either way, but my</FONT>
<BR><FONT SIZE=3D2>&gt; vote would be to make the two attributes =
single-valued,</FONT>
<BR><FONT SIZE=3D2>&gt; on the grounds that in general we've applied =
more careful</FONT>
<BR><FONT SIZE=3D2>&gt; thought to PCIM than we have to PCLS.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; Bob</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Bob Moore</FONT>
<BR><FONT SIZE=3D2>&gt; IBM Networking Software</FONT>
<BR><FONT SIZE=3D2>&gt; +1-919-254-4436</FONT>
<BR><FONT SIZE=3D2>&gt; remoore@us.ibm.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;Mircea Pana&quot; =
&lt;mpana@nortelnetworks.com&gt;@raleigh.ibm.com on 12/06/2000</FONT>
<BR><FONT SIZE=3D2>&gt; 05:51:35 PM</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Please respond to &quot;Mircea Pana&quot; =
&lt;mpana@nortelnetworks.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sent by:&nbsp; =
policy-owner@raleigh.ibm.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; To:&nbsp;&nbsp; =
&quot;'policy@raleigh.ibm.com'&quot; =
&lt;policy@raleigh.ibm.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; cc:</FONT>
<BR><FONT SIZE=3D2>&gt; Subject:&nbsp; cardinality of =
policyRuleSequencedActions</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Wrt. the cardinality of some LDAP attributes =
defined in</FONT>
<BR><FONT SIZE=3D2>&gt; =
&quot;draft-ietf-policy-core-schema-08&quot;:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1. Isn't the =
&quot;policyRuleSequencedActions&quot; attribute supposed to be</FONT>
<BR><FONT SIZE=3D2>&gt; single-valued (in &quot;policyRule&quot;)? The =
document does not specify this</FONT>
<BR><FONT SIZE=3D2>&gt; attribute's cardinality, which implies as =
default: multi-value.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2. Same comment for =
&quot;ptpConditionTimeOfDayMask&quot; attribute (in</FONT>
<BR><FONT SIZE=3D2>&gt; =
&quot;policyTimePeriodConditionAuxClass&quot;).</FONT>
<BR><FONT SIZE=3D2>&gt; However, if this last one should be =
multi-valued, by extrapolation,</FONT>
<BR><FONT SIZE=3D2>&gt; shouldn't the &quot;ptpConditionTime&quot; be =
multi-valued as well?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; Mircea Pana.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C06073.43855150--


From majordomo@raleigh.ibm.com  Thu Dec  7 16:58:11 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14122
	for <policy-archive@odin.ietf.org>; Thu, 7 Dec 2000 16:58:11 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA25496;
	Thu, 7 Dec 2000 16:47:39 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAB25796;
	Thu, 7 Dec 2000 16:47:36 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA38824; Thu, 7 Dec 2000 16:13:04 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA33182; Thu, 7 Dec 2000 16:13:00 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA29096
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 16:13:04 -0500
Received: from longsys.com (dmz.longsys.com [63.111.150.5])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA25570
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 16:12:59 -0500
Received: from joel (discordian.longsys.com [63.111.150.74])
	by longsys.com (8.10.0/8.10.0) with ESMTP id eB7LDGI15038;
	Thu, 7 Dec 2000 21:13:17 GMT
Message-Id: <4.2.2.20001207160640.00b32220@localhost>
X-Sender: joel@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 07 Dec 2000 16:11:05 -0500
To: Brian E Carpenter <brian@hursley.ibm.com>,
        Kathleen Nichols <nichols@packetdesign.com>
From: "Joel M. Halpern" <joel@longsys.com>
Subject: Re: [Diffserv] DSCP marking versus DSCP remarking
Cc: "'diffserv@ietf.org'" <diffserv@ietf.org>, policy@raleigh.ibm.com
In-Reply-To: <3A2FB980.14BEAD33@hursley.ibm.com>
References: <OFACF3000E.2C79C597-ON852569AC.005D1768@raleigh.ibm.com>
 <3A2D4EE0.EBFEAE43@packetdesign.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Joel M. Halpern" <joel@longsys.com>

Actually, I believe that this misses the point of the issue Bob is 
raising.  From the point of view of the processing elements, I can find no 
difference between a marker and a remarker.  If one places the processing 
element on a data path such that the packet is coming from outside 
diffserv, then it is a marker.  If it could have been previously remarked.

The problem is that the informal model actually says that one might have a 
processing element that was allowed to be a marker, but not a 
remarker.  That would require the processing element to know the history of 
the packet.  It would need to know whether the packet arrived over an 
interface considered to be inside or outside the diffserv domain.  For 
those arriving over an outside interface that was not considered to be 
applying useful diffserv markings, it would have to know if the current 
value in the DSCP came from the input or was put there by an earlier marker 
in the processing stream.

These are things that the "marker" element has no way to determine.  The 
human being placing it there may have a way to tell.  But then, the human 
being can put in a classifier if he is concerned about what value is in the 
field.  It is NOT up to a marker to look at the packet and decide if it 
should stamp the value.  If the packet gets to the marker, mark it.

Yours,
Joel M. Halpern

At 10:23 AM 12/7/00 -0600, Brian E Carpenter wrote:
>I believe this is quite clearly discussed in RFC 2474/5.
>Packets arriving from a non-DS domain can't be regarded
>as containing a meaningful DSCP value until they have
>been classified and marked.
>
>I don't think that Policy WG documents should be in the
>business of tweaking the diffserv architecture.
>
>   Brian
>
>Kathleen Nichols wrote:
> >
> > Robert Moore wrote:
> > >
> > ...
> > >
> > > This is *almost* just a question of wordsmithing in the
> > > three diffserv WG documents.  But not quite.  If there is
> > > actual disagreement in the WG about whether there is such
> > > a thing as an unmarked packet, that is, a packet that's
> > > not marked with any DSCP, then the question should be
> > > discussed until the WG reaches a consensus one way or the
> > > other.  Does everybody agree with the QDDIM team that
> > > there is no such thing as a packet unmarked with any DSCP?
> > >
> >
> > With my WG co-chair hat OFF, I agree that we should just have
> > a "marker" as a primitive element. I would not phrase this as
> > saying "there is no such thing as a packet unmarked with any
> > DSCP". If someone chooses to use that phrase to describe
> > packets marked with an unknown, illegal, or unverified DSCP,
> > it should not have any architectural effect.
> >
> >         Kathie
> >
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive: 
> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
>
>_______________________________________________
>diffserv mailing list
>diffserv@ietf.org
>http://www1.ietf.org/mailman/listinfo/diffserv
>Archive: 
>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From majordomo@raleigh.ibm.com  Thu Dec  7 17:21:45 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17832
	for <policy-archive@odin.ietf.org>; Thu, 7 Dec 2000 17:21:43 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA19332;
	Thu, 7 Dec 2000 17:12:32 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA32742;
	Thu, 7 Dec 2000 17:12:31 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA61742; Thu, 7 Dec 2000 10:33:16 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA61732; Thu, 7 Dec 2000 10:33:13 -0500
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA26232
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 10:33:15 -0500
Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37])
	by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id KAA42526;
	Thu, 7 Dec 2000 10:33:13 -0500
Importance: Normal
Subject: Re: cardinality of policyRuleSequencedActions
To: "Mircea Pana" <mpana@nortelnetworks.com>
Cc: "'policy@raleigh.ibm.com'" <policy@raleigh.ibm.com>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-Id: <OF5317DE1E.74F8B7FD-ON852569AE.00550BB0@raleigh.ibm.com>
From: "Robert Moore" <remoore@us.ibm.com>
Date: Thu, 7 Dec 2000 10:37:47 -0500
X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at
 12/07/2000 10:33:41 AM
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Robert Moore" <remoore@us.ibm.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA17832

Mircea,

You're definitely right about #1 -- I've already changed
this in the PCLS source file.

For #2, I *think* that having it multi-valued was
intentional, but I'm not really sure.  The idea would be
to allow us to represent in a single object a schedule
like 0800 to 1200 AND 1300 to 1700.  I don't know if such
schedules will be common enough to warrant the extra
complexity.

One further factor:  both of the ptpCondition properties
in PCIM that correspond to these two attributes are
single-valued.  So we either need to change
ptpConditionTimeOfDayMask to single-valued (and leave
ptpConditionTime single-valued), or else make one or both
of them multi-valued, and track the corresponding change
to PCIM as our first piece of Proposed Standard
implementation experience.  I could go either way, but my
vote would be to make the two attributes single-valued,
on the grounds that in general we've applied more careful
thought to PCIM than we have to PCLS.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
remoore@us.ibm.com



"Mircea Pana" <mpana@nortelnetworks.com>@raleigh.ibm.com on 12/06/2000
05:51:35 PM

Please respond to "Mircea Pana" <mpana@nortelnetworks.com>

Sent by:  policy-owner@raleigh.ibm.com


To:   "'policy@raleigh.ibm.com'" <policy@raleigh.ibm.com>
cc:
Subject:  cardinality of policyRuleSequencedActions





Wrt. the cardinality of some LDAP attributes defined in
"draft-ietf-policy-core-schema-08":

1. Isn't the "policyRuleSequencedActions" attribute supposed to be
single-valued (in "policyRule")? The document does not specify this
attribute's cardinality, which implies as default: multi-value.

2. Same comment for "ptpConditionTimeOfDayMask" attribute (in
"policyTimePeriodConditionAuxClass").
However, if this last one should be multi-valued, by extrapolation,
shouldn't the "ptpConditionTime" be multi-valued as well?

Thanks,
Mircea Pana.





From majordomo@raleigh.ibm.com  Thu Dec  7 18:02:10 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22910
	for <policy-archive@odin.ietf.org>; Thu, 7 Dec 2000 18:02:10 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA29800;
	Thu, 7 Dec 2000 17:52:21 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA31996;
	Thu, 7 Dec 2000 17:52:19 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA46236; Thu, 7 Dec 2000 17:26:23 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA61332; Thu, 7 Dec 2000 17:26:20 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA34438
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 17:26:23 -0500
Received: from longsys.com (dmz.longsys.com [63.111.150.5])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA19300
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 17:26:20 -0500
Received: from joel (discordian.longsys.com [63.111.150.74])
	by longsys.com (8.10.0/8.10.0) with ESMTP id eB7MQjW16778;
	Thu, 7 Dec 2000 22:26:45 GMT
Message-Id: <4.2.2.20001207172221.00b49520@localhost>
X-Sender: joel@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Thu, 07 Dec 2000 17:24:33 -0500
To: Andrew Smith <andrew@allegronetworks.com>
From: "Joel M. Halpern" <joel@longsys.com>
Subject: Re: [Diffserv] Re: DSCP marking versus DSCP remarking
Cc: "'diffserv@ietf.org'" <diffserv@ietf.org>, policy@raleigh.ibm.com
In-Reply-To: <3A2FEA97.7040705@allegronetworks.com>
References: <OFACF3000E.2C79C597-ON852569AC.005D1768@raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Joel M. Halpern" <joel@longsys.com>

As I said in another recent reply, I really believe that this is not the case.
Even a human being looking from outside the box might well have trouble 
telling if a packet sitting at a marker is already marked or not.  Suppose 
that one of the several paths to this marker goes through an earlier 
marker/meter sequence.  Suppose that the customer SLA says that the 
customers diffserv marking will be respected.
The device component is certainly in no position to tell the difference.
It seems to me that this distinction is distracting and error prone.  It 
can not translate to a difference in resulting behavior.

Yours,
Joel M. Halpern

At 11:52 AM 12/7/00 -0800, Andrew Smith wrote:

>I'm slightly confused as to whether I need to change anything in the Model 
>draft here: I think, to paraphrase Brian's answer, that there *is* such a 
>thing, conceptually, as an unmarked packet. You can tell, by implicit 
>context, whether a packet is or is not already "marked" (it's a "policy" 
>or "trust" thing, in the abstract sense of those terms).
>
>Do I have this right?
>
>Andrew Smith
>(Diffserv Model draft editor)
>
>
>Robert Moore wrote:
>
>>In the DiffServ Informal Model, MIB, and PIB, there
>>is a distinction drawn between a marker that marks
>>unmarked packets, and one that remarks packets that
>>had been marked previously.  This distinction appears
>>most clearly in section 6.1 of the Informal Model.
>>The MIB and the PIB make it implicitly, by importing
>>the terms "mark" and "remark" from the Informal Model.
>>This distinction presupposes that among the packets
>>coming into a marker, some can be identified as
>>already marked, and others can be identified as
>>unmarked.  I don't believe that this is the case.
>>In QDDIM, we have come down squarely on the side that
>>says there is no such thing as an unmarked packet, and
>>thus no distinction between packet marking and packet
>>remarking.  Every packet has one of 64 values, decimal
>>0 - 63, in the DSCP field.  Each of these values,
>>including 0, is a legitimate DSCP.  So a DSCP marker
>>always takes in a packet that is already marked with a
>>DSCP, and marks (or remarks - which word we choose isn't
>>important) the packet with another DSCP, which may or
>>may not be the same DSCP as the one the packet had
>>when it came into the marker.  Based on this view, we
>>removed from the MarkerService class in QDDIM a boolean
>>property CanRemark, which said whether a marker was
>>allowed to mark all packets, or only packets that were
>>not already marked when they got to it.
>>This is *almost* just a question of wordsmithing in the
>>three diffserv WG documents.  But not quite.  If there is
>>actual disagreement in the WG about whether there is such
>>a thing as an unmarked packet, that is, a packet that's
>>not marked with any DSCP, then the question should be
>>discussed until the WG reaches a consensus one way or the
>>other.  Does everybody agree with the QDDIM team that
>>there is no such thing as a packet unmarked with any DSCP?
>>Regards,
>>Bob
>>Bob Moore
>>IBM Networking Software
>>+1-919-254-4436
>>remoore@us.ibm.com
>
>
>_______________________________________________
>diffserv mailing list
>diffserv@ietf.org
>http://www1.ietf.org/mailman/listinfo/diffserv
>Archive: 
>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html



From majordomo@raleigh.ibm.com  Thu Dec  7 18:41:35 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28823
	for <policy-archive@odin.ietf.org>; Thu, 7 Dec 2000 18:41:34 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA21760;
	Thu, 7 Dec 2000 18:32:06 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA36798;
	Thu, 7 Dec 2000 18:32:01 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA38748; Thu, 7 Dec 2000 18:04:23 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA50888; Thu, 7 Dec 2000 18:04:05 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA29550
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 18:04:03 -0500
Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA26968
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 18:03:46 -0500
Received: by BOR with Internet Mail Service (5.5.2650.21)
	id <YJY1AB7R>; Thu, 7 Dec 2000 17:57:11 -0500
Message-Id: <A3617F281546D411958C00D0B760121CEBDC77@BOR>
From: "Weiss, Walter" <wweiss@ellacoya.com>
To: "'Joel M. Halpern'" <joel@longsys.com>,
        Brian E Carpenter
	 <brian@hursley.ibm.com>,
        Kathleen Nichols <nichols@packetdesign.com>
Cc: "'diffserv@ietf.org'" <diffserv@ietf.org>, policy@raleigh.ibm.com
Subject: RE: [Diffserv] DSCP marking versus DSCP remarking
Date: Thu, 7 Dec 2000 17:57:03 -0500 
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C060A1.080B7586"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Weiss, Walter" <wweiss@ellacoya.com>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C060A1.080B7586
Content-Type: text/plain;
	charset="ISO-8859-1"

I agree with Joel. I was thinking about the scenario where a DS edge router
may also be transiting traffic between two non DS domains and it occured to
me that one may want to mark  as DS on ingress and (re)mark to non-DS on
egress or do nothing at all depending on how the classifiers and markers
were configured and where they were located in the data path.

A remarker is inherently ambiguous because it has been used at times to
describe a mapping from one DSCP to another (map AF1 to EF) and at other
times to enforce an SLS (remark non-conforming AF11 traffic to AF12). It is
clear that a marker just assigns a dscp for the first time. However, would
we consider a mapping from TOS precedence 3 low delay to EF as a remarking
or a marking function? It seems more convenient to me to punt on the
distinction then to draw out and distinguish each unique case.

regards,

-Walter

> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@longsys.com]
> Sent: Thursday, December 07, 2000 4:11 PM
> To: Brian E Carpenter; Kathleen Nichols
> Cc: 'diffserv@ietf.org'; policy@raleigh.ibm.com
> Subject: Re: [Diffserv] DSCP marking versus DSCP remarking
> 
> 
> Actually, I believe that this misses the point of the issue Bob is 
> raising.  From the point of view of the processing elements, 
> I can find no 
> difference between a marker and a remarker.  If one places 
> the processing 
> element on a data path such that the packet is coming from outside 
> diffserv, then it is a marker.  If it could have been 
> previously remarked.
> 
> The problem is that the informal model actually says that one 
> might have a 
> processing element that was allowed to be a marker, but not a 
> remarker.  That would require the processing element to know 
> the history of 
> the packet.  It would need to know whether the packet arrived over an 
> interface considered to be inside or outside the diffserv 
> domain.  For 
> those arriving over an outside interface that was not 
> considered to be 
> applying useful diffserv markings, it would have to know if 
> the current 
> value in the DSCP came from the input or was put there by an 
> earlier marker 
> in the processing stream.
> 
> These are things that the "marker" element has no way to 
> determine.  The 
> human being placing it there may have a way to tell.  But 
> then, the human 
> being can put in a classifier if he is concerned about what 
> value is in the 
> field.  It is NOT up to a marker to look at the packet and 
> decide if it 
> should stamp the value.  If the packet gets to the marker, mark it.
> 
> Yours,
> Joel M. Halpern
> 
> At 10:23 AM 12/7/00 -0600, Brian E Carpenter wrote:
> >I believe this is quite clearly discussed in RFC 2474/5.
> >Packets arriving from a non-DS domain can't be regarded
> >as containing a meaningful DSCP value until they have
> >been classified and marked.
> >
> >I don't think that Policy WG documents should be in the
> >business of tweaking the diffserv architecture.
> >
> >   Brian
> >
> >Kathleen Nichols wrote:
> > >
> > > Robert Moore wrote:
> > > >
> > > ...
> > > >
> > > > This is *almost* just a question of wordsmithing in the
> > > > three diffserv WG documents.  But not quite.  If there is
> > > > actual disagreement in the WG about whether there is such
> > > > a thing as an unmarked packet, that is, a packet that's
> > > > not marked with any DSCP, then the question should be
> > > > discussed until the WG reaches a consensus one way or the
> > > > other.  Does everybody agree with the QDDIM team that
> > > > there is no such thing as a packet unmarked with any DSCP?
> > > >
> > >
> > > With my WG co-chair hat OFF, I agree that we should just have
> > > a "marker" as a primitive element. I would not phrase this as
> > > saying "there is no such thing as a packet unmarked with any
> > > DSCP". If someone chooses to use that phrase to describe
> > > packets marked with an unknown, illegal, or unverified DSCP,
> > > it should not have any architectural effect.
> > >
> > >         Kathie
> > >
> > > _______________________________________________
> > > diffserv mailing list
> > > diffserv@ietf.org
> > > http://www1.ietf.org/mailman/listinfo/diffserv
> > > Archive: 
> > 
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml
>
>_______________________________________________
>diffserv mailing list
>diffserv@ietf.org
>http://www1.ietf.org/mailman/listinfo/diffserv
>Archive: 
>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.
html

------_=_NextPart_001_01C060A1.080B7586
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: [Diffserv] DSCP marking versus DSCP remarking</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree with Joel. I was thinking about the scenario =
where a DS edge router may also be transiting traffic between two non =
DS domains and it occured to me that one may want to mark&nbsp; as DS =
on ingress and (re)mark to non-DS on egress or do nothing at all =
depending on how the classifiers and markers were configured and where =
they were located in the data path.</FONT></P>

<P><FONT SIZE=3D2>A remarker is inherently ambiguous because it has =
been used at times to describe a mapping from one DSCP to another (map =
AF1 to EF) and at other times to enforce an SLS (remark non-conforming =
AF11 traffic to AF12). It is clear that a marker just assigns a dscp =
for the first time. However, would we consider a mapping from TOS =
precedence 3 low delay to EF as a remarking or a marking function? It =
seems more convenient to me to punt on the distinction then to draw out =
and distinguish each unique case.</FONT></P>

<P><FONT SIZE=3D2>regards,</FONT>
</P>

<P><FONT SIZE=3D2>-Walter</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Joel M. Halpern [<A =
HREF=3D"mailto:joel@longsys.com">mailto:joel@longsys.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, December 07, 2000 4:11 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Brian E Carpenter; Kathleen Nichols</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'diffserv@ietf.org'; =
policy@raleigh.ibm.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [Diffserv] DSCP marking versus =
DSCP remarking</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Actually, I believe that this misses the point =
of the issue Bob is </FONT>
<BR><FONT SIZE=3D2>&gt; raising.&nbsp; From the point of view of the =
processing elements, </FONT>
<BR><FONT SIZE=3D2>&gt; I can find no </FONT>
<BR><FONT SIZE=3D2>&gt; difference between a marker and a =
remarker.&nbsp; If one places </FONT>
<BR><FONT SIZE=3D2>&gt; the processing </FONT>
<BR><FONT SIZE=3D2>&gt; element on a data path such that the packet is =
coming from outside </FONT>
<BR><FONT SIZE=3D2>&gt; diffserv, then it is a marker.&nbsp; If it =
could have been </FONT>
<BR><FONT SIZE=3D2>&gt; previously remarked.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The problem is that the informal model actually =
says that one </FONT>
<BR><FONT SIZE=3D2>&gt; might have a </FONT>
<BR><FONT SIZE=3D2>&gt; processing element that was allowed to be a =
marker, but not a </FONT>
<BR><FONT SIZE=3D2>&gt; remarker.&nbsp; That would require the =
processing element to know </FONT>
<BR><FONT SIZE=3D2>&gt; the history of </FONT>
<BR><FONT SIZE=3D2>&gt; the packet.&nbsp; It would need to know whether =
the packet arrived over an </FONT>
<BR><FONT SIZE=3D2>&gt; interface considered to be inside or outside =
the diffserv </FONT>
<BR><FONT SIZE=3D2>&gt; domain.&nbsp; For </FONT>
<BR><FONT SIZE=3D2>&gt; those arriving over an outside interface that =
was not </FONT>
<BR><FONT SIZE=3D2>&gt; considered to be </FONT>
<BR><FONT SIZE=3D2>&gt; applying useful diffserv markings, it would =
have to know if </FONT>
<BR><FONT SIZE=3D2>&gt; the current </FONT>
<BR><FONT SIZE=3D2>&gt; value in the DSCP came from the input or was =
put there by an </FONT>
<BR><FONT SIZE=3D2>&gt; earlier marker </FONT>
<BR><FONT SIZE=3D2>&gt; in the processing stream.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; These are things that the &quot;marker&quot; =
element has no way to </FONT>
<BR><FONT SIZE=3D2>&gt; determine.&nbsp; The </FONT>
<BR><FONT SIZE=3D2>&gt; human being placing it there may have a way to =
tell.&nbsp; But </FONT>
<BR><FONT SIZE=3D2>&gt; then, the human </FONT>
<BR><FONT SIZE=3D2>&gt; being can put in a classifier if he is =
concerned about what </FONT>
<BR><FONT SIZE=3D2>&gt; value is in the </FONT>
<BR><FONT SIZE=3D2>&gt; field.&nbsp; It is NOT up to a marker to look =
at the packet and </FONT>
<BR><FONT SIZE=3D2>&gt; decide if it </FONT>
<BR><FONT SIZE=3D2>&gt; should stamp the value.&nbsp; If the packet =
gets to the marker, mark it.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Yours,</FONT>
<BR><FONT SIZE=3D2>&gt; Joel M. Halpern</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 10:23 AM 12/7/00 -0600, Brian E Carpenter =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;I believe this is quite clearly discussed =
in RFC 2474/5.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Packets arriving from a non-DS domain can't =
be regarded</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;as containing a meaningful DSCP value until =
they have</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;been classified and marked.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;I don't think that Policy WG documents =
should be in the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;business of tweaking the diffserv =
architecture.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; Brian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Kathleen Nichols wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Robert Moore wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; This is *almost* just a question =
of wordsmithing in the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; three diffserv WG =
documents.&nbsp; But not quite.&nbsp; If there is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; actual disagreement in the WG =
about whether there is such</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; a thing as an unmarked packet, =
that is, a packet that's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; not marked with any DSCP, then =
the question should be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; discussed until the WG reaches a =
consensus one way or the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; other.&nbsp; Does everybody =
agree with the QDDIM team that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; there is no such thing as a =
packet unmarked with any DSCP?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; With my WG co-chair hat OFF, I agree =
that we should just have</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; a &quot;marker&quot; as a primitive =
element. I would not phrase this as</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; saying &quot;there is no such thing =
as a packet unmarked with any</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; DSCP&quot;. If someone chooses to use =
that phrase to describe</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; packets marked with an unknown, =
illegal, or unverified DSCP,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; it should not have any architectural =
effect.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Kathie</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; diffserv mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; diffserv@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; <A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/diffserv" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/diffserv</A></FO=
NT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Archive: </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www2.ietf.org/mail-archive/working-groups/diffserv/curren=
t/maillist.html" =
TARGET=3D"_blank">http://www2.ietf.org/mail-archive/working-groups/diffs=
erv/current/maillist.html</A></FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;_______________________________________________</=
FONT>
<BR><FONT SIZE=3D2>&gt;diffserv mailing list</FONT>
<BR><FONT SIZE=3D2>&gt;diffserv@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt;<A =
HREF=3D"http://www1.ietf.org/mailman/listinfo/diffserv" =
TARGET=3D"_blank">http://www1.ietf.org/mailman/listinfo/diffserv</A></FO=
NT>
<BR><FONT SIZE=3D2>&gt;Archive: </FONT>
<BR><FONT SIZE=3D2>&gt;<A =
HREF=3D"http://www2.ietf.org/mail-archive/working-groups/diffserv/curren=
t/maillist.html" =
TARGET=3D"_blank">http://www2.ietf.org/mail-archive/working-groups/diffs=
erv/current/maillist.html</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C060A1.080B7586--


From majordomo@raleigh.ibm.com  Thu Dec  7 23:14:32 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04478
	for <policy-archive@odin.ietf.org>; Thu, 7 Dec 2000 23:14:32 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id XAA21810;
	Thu, 7 Dec 2000 23:04:28 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id XAA24560;
	Thu, 7 Dec 2000 23:04:26 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA31010; Thu, 7 Dec 2000 22:30:02 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA52758; Thu, 7 Dec 2000 22:29:57 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id WAA28008
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 22:30:00 -0500
Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id WAA36324
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 22:29:57 -0500
Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id eB83V9E73325;
	Fri, 8 Dec 2000 04:31:09 +0100 (CET)
Received: from imap.heidelberg.ccrle.nec.de (postfix@imap.heidelberg.ccrle.nec.de [192.168.102.7])
	by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id EAA22649;
	Fri, 8 Dec 2000 04:30:12 +0100
Received: by imap.heidelberg.ccrle.nec.de (Postfix, from userid 30)
	id 6CB587DCF; Fri,  8 Dec 2000 06:29:55 +0100 (CET)
From: Marcus Brunner <brunner@ccrle.nec.de>
To: Ron Cohen <ronc@cisco.com>
Cc: Mahadevan Iyer <iyermahadevan@yahoo.com>, policy@raleigh.ibm.com,
        ipsec-policy@vpnc.org
References: <4.3.2.7.2.20001207003148.00b3a240@csi-admin1>
In-Reply-To: <4.3.2.7.2.20001207003148.00b3a240@csi-admin1>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: IMP/PHP3 Imap webMail Program 2.0.9
Subject: Re: gpsPolicyGroup class in qos info model
Message-Id: <20001208052955.6CB587DCF@imap.heidelberg.ccrle.nec.de>
Date: Fri,  8 Dec 2000 06:29:55 +0100 (CET)
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Marcus Brunner <brunner@ccrle.nec.de>
Content-Transfer-Encoding: 7bit

Ron,

I agree with Mahadevan, that I do not like the policyRuleInPolicyRule method, 
because 
a) there are now two different grouping models,
b) it is unclear what happens to the context when the ruleInrule is executed 
(full new start of execution engine or reuse the context)
c) I do not see the need for rulesInrules, what makes them different compared to 
the grouping already available

However, I do not agree to add a condition to the group. I think what is 
available is enough.

Marcus  

Quoting Ron Cohen <ronc@cisco.com>:

> Mahadevan,
>
> Can you provide more details why you prefer to change the gpsPolicyGroup
> than using the current policyRuleInPolicyRule method?
>
> Thanks
> Ron
>
>
> >I would like to suggest an update to the
> >gpsPolicyGroup class.
> >This also relates to the PolicyRuleInPolicyRule usage.
> >
> >I need to indicate that a group of policy rules should
> >be checked only if the traffic matches some aggregate
> >conditions. These aggregate conditions summarize the
> >conditions within the policy rules.
> >
> >I would like to specify the aggregate conditions at
> >the level of the gpsPolicyGroup. An alternative is to
> >use the PolicyRule + PolicyRuleInPolicyRule instead of
> >the gpsPolicyGroup. However I prefer to use the
> >gpsPolicyGroup.
> >
> >I would suggest adding an aggregate policy condition
> >to the gpsPolicyGroup. This condition would typically
> >be a gpsPolicyCompoundCondition.
> >
> >
> >Thanks
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Yahoo! Shopping - Thousands of Stores. Millions of Products.
> >http://shopping.yahoo.com/
>
> 



Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155


From majordomo@raleigh.ibm.com  Fri Dec  8 00:14:13 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21562
	for <policy-archive@odin.ietf.org>; Fri, 8 Dec 2000 00:14:12 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA22314;
	Fri, 8 Dec 2000 00:02:20 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id AAA29170;
	Fri, 8 Dec 2000 00:02:18 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43798; Thu, 7 Dec 2000 23:30:20 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA31500; Thu, 7 Dec 2000 23:30:16 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id XAA37982
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 23:30:21 -0500
Received: from web10501.mail.yahoo.com (web10501.mail.yahoo.com [216.136.130.151])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id XAA34176
	for <policy@raleigh.ibm.com>; Thu, 7 Dec 2000 23:30:18 -0500
Message-Id: <20001208043008.17348.qmail@web10501.mail.yahoo.com>
Received: from [198.206.187.100] by web10501.mail.yahoo.com; Thu, 07 Dec 2000 20:30:08 PST
Date: Thu, 7 Dec 2000 20:30:08 -0800 (PST)
From: Mahadevan Iyer <iyermahadevan@yahoo.com>
Subject: Re: gpsPolicyGroup class in qos info model
To: Marcus Brunner <brunner@ccrle.nec.de>, Ron Cohen <ronc@cisco.com>
Cc: Mahadevan Iyer <iyermahadevan@yahoo.com>, policy@raleigh.ibm.com,
        ipsec-policy@vpnc.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Mahadevan Iyer <iyermahadevan@yahoo.com>

Hello Marcus, Ron,

  there are 2 issues mentioned in you responses.

1. Why not use the PolicyRuleInPolicyRule instead of
..

   I must say that if we had started out saying that
any collection of policies can be logically thought of
as "a policy"(which I find attractive) I wouldn't have
minded using this class.
   However we seemed to have clearly called out the
notion of a "collection of policies" to be a
policyGroup. This too has its benefits. This has led
me to think of the of the PolicyRule as an "atomic"
class to be aggregated using PolicyGroups.

2. Why do we need a condition at the level of a
"collection of policies" ...

   This is an optimization which could be leveraged in
almost all applications. A PDP can do this on its own
by analysing the conditions in the contained rules.
However the administrator can configure far more
optimal and powerful aggregation of conditions. It is
possible that these aggregations might be a subset or
a superset of the aggregation derived by analysing the
conditions.

Thanks

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/


From majordomo@raleigh.ibm.com  Fri Dec  8 09:57:33 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24598
	for <policy-archive@odin.ietf.org>; Fri, 8 Dec 2000 09:57:31 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA22078;
	Fri, 8 Dec 2000 09:28:08 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA24924;
	Fri, 8 Dec 2000 09:28:07 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA48756; Fri, 8 Dec 2000 08:38:31 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA47184; Fri, 8 Dec 2000 08:38:26 -0500
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA30400
	for <policy@raleigh.ibm.com>; Fri, 8 Dec 2000 08:38:29 -0500
Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37])
	by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id IAA128794;
	Fri, 8 Dec 2000 08:38:24 -0500
Importance: Normal
Subject: Re: [Diffserv] Re: DSCP marking versus DSCP remarking
To: Andrew Smith <andrew@allegronetworks.com>
Cc: Brian E Carpenter <brian@hursley.ibm.com>,
        "Joel M. Halpern" <joel@longsys.com>,
        Walter Weiss <wweiss@ellacoya.com>,
        "'diffserv@ietf.org'" <diffserv@ietf.org>, policy@raleigh.ibm.com
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-Id: <OFDDE8CBFF.554D4A93-ON852569AF.004AF837@raleigh.ibm.com>
From: "Robert Moore" <remoore@us.ibm.com>
Date: Fri, 8 Dec 2000 08:43:05 -0500
X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at
 12/08/2000 08:38:54 AM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Robert Moore" <remoore@us.ibm.com>

Andrew,

My vote is definitely for the one-line version you give below.
The problem with the paragraph version is that a Classifier is
just as ignorant as a Marker about whether a packet is marked
or unmarked.  All the Classifier knows is that a packet does
or does not match a filter like "DSCP = 13" or "DSCP = 0".
Brian's helicopter might know whether a packet that matches
one of these filters is marked.  But the Classifier doesn't
know this.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
remoore@us.ibm.com



Andrew Smith <andrew@allegronetworks.com>@ietf.org on 12/08/2000 12:03:41
AM

Sent by:  diffserv-admin@ietf.org


To:   Brian E Carpenter <brian@hursley.ibm.com>, "Joel M. Halpern"
      <joel@longsys.com>
cc:   Walter Weiss <wweiss@ellacoya.com>, "'diffserv@ietf.org'"
      <diffserv@ietf.org>, policy@raleigh.ibm.com
Subject:  Re: [Diffserv] Re: DSCP marking versus DSCP remarking



That's also exactly what I meant in my response. The "you" in my statement
was
meant to be Brian's helicopter, not a Marker element in the Model.

But I'm still unclear if the Model draft needs to change. The only
re-marking
described is in 6.1 in the context of the things that a DSCP Marker element
might do:
   "DSCP Markers are 1:1 elements which set a codepoint (e.g. the DSCP
   in an IP header). DSCP Markers may also act on unmarked packets (e.g.
   those submitted with DSCP of zero) or may re-mark previously marked
   packets."

Would it be clearer instead to say something like:
  "DSCP Markers are 1:1 elements which set the DSCP in an IP header. DSCP
Markers might, for example, act on packets that a previous Classifier
element
has deemed to be unmarked (e.g. because they were received from a
non-Diffserv
domain). They might also re-mark previously marked packets (e.g. those that
a
previous Classifier element has recognised as having valid DSCP values but
which
now need to be marked with a different one, perhaps because they failed to
conform to a Meter)."

Or should the Model, at this point, just not go there and say merely:
  "DSCP Markers are 1:1 elements which set the DSCP in an IP header."

Joel wrote:
 > The problem is that the informal model actually says that one
 > might have a processing element that was allowed to be a marker,
 > but not a remarker
I'm not quite sure which part of the Informal Model draft Joel is referring
to
(is it the "or" that you don't like? It was not meant to be an "exclusive
or",
just an "and/or") but perhaps my proposed re-wording above (using "also")
helps
clarify?

But that still sits uneasily with Walter's statement that "It is clear that
a
marker just assigns a dscp for the first time" (perhaps I'm reading that
statement in the wrong context?).

Any more thoughts on this? I think we're in a rat-hole - should we perhaps
work
offline to clarify what it is that we're all mis-understanding?

Andrew

Brian E Carpenter wrote:

> I certainly agree that the marker itself can have no idea, and need have
> no idea, whether it is the first marker to mark a given packet - i.e.
> there is no functional difference between marking and remarking. It's
> only if you could watch the packets from a helicopter, and observe
> them passing from a non-DS domain into a DS domain, that you would know
> the difference. It's certainly a good idea to reflect this in the
> documents.
>
>   Brian
>
> "Joel M. Halpern" wrote:
>
>> As I said in another recent reply, I really believe that this is not the
case.
>> Even a human being looking from outside the box might well have trouble
>> telling if a packet sitting at a marker is already marked or not.
Suppose
>> that one of the several paths to this marker goes through an earlier
>> marker/meter sequence.  Suppose that the customer SLA says that the
>> customers diffserv marking will be respected.
>> The device component is certainly in no position to tell the difference.
>> It seems to me that this distinction is distracting and error prone.  It
>> can not translate to a difference in resulting behavior.
>>
>> Yours,
>> Joel M. Halpern
>>
>> At 11:52 AM 12/7/00 -0800, Andrew Smith wrote:
>>
>>
>>> I'm slightly confused as to whether I need to change anything in the
Model
>>> draft here: I think, to paraphrase Brian's answer, that there *is* such
a
>>> thing, conceptually, as an unmarked packet. You can tell, by implicit
>>> context, whether a packet is or is not already "marked" (it's a
"policy"
>>> or "trust" thing, in the abstract sense of those terms).
>>>
>>> Do I have this right?
>>>
>>> Andrew Smith
>>> (Diffserv Model draft editor)
>>>
>>>
>>> Robert Moore wrote:
>>>
>>>
>>>> In the DiffServ Informal Model, MIB, and PIB, there
>>>> is a distinction drawn between a marker that marks
>>>> unmarked packets, and one that remarks packets that
>>>> had been marked previously.  This distinction appears
>>>> most clearly in section 6.1 of the Informal Model.
>>>> The MIB and the PIB make it implicitly, by importing
>>>> the terms "mark" and "remark" from the Informal Model.
>>>> This distinction presupposes that among the packets
>>>> coming into a marker, some can be identified as
>>>> already marked, and others can be identified as
>>>> unmarked.  I don't believe that this is the case.
>>>> In QDDIM, we have come down squarely on the side that
>>>> says there is no such thing as an unmarked packet, and
>>>> thus no distinction between packet marking and packet
>>>> remarking.  Every packet has one of 64 values, decimal
>>>> 0 - 63, in the DSCP field.  Each of these values,
>>>> including 0, is a legitimate DSCP.  So a DSCP marker
>>>> always takes in a packet that is already marked with a
>>>> DSCP, and marks (or remarks - which word we choose isn't
>>>> important) the packet with another DSCP, which may or
>>>> may not be the same DSCP as the one the packet had
>>>> when it came into the marker.  Based on this view, we
>>>> removed from the MarkerService class in QDDIM a boolean
>>>> property CanRemark, which said whether a marker was
>>>> allowed to mark all packets, or only packets that were
>>>> not already marked when they got to it.
>>>> This is *almost* just a question of wordsmithing in the
>>>> three diffserv WG documents.  But not quite.  If there is
>>>> actual disagreement in the WG about whether there is such
>>>> a thing as an unmarked packet, that is, a packet that's
>>>> not marked with any DSCP, then the question should be
>>>> discussed until the WG reaches a consensus one way or the
>>>> other.  Does everybody agree with the QDDIM team that
>>>> there is no such thing as a packet unmarked with any DSCP?
>>>> Regards,
>>>> Bob
>>>> Bob Moore
>>>> IBM Networking Software
>>>> +1-919-254-4436
>>>> remoore@us.ibm.com


_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive:
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html





From majordomo@raleigh.ibm.com  Fri Dec  8 14:21:20 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17251
	for <policy-archive@odin.ietf.org>; Fri, 8 Dec 2000 14:21:20 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA16756;
	Fri, 8 Dec 2000 14:01:31 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA30518;
	Fri, 8 Dec 2000 14:01:29 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA47186; Fri, 8 Dec 2000 12:45:05 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA21302; Fri, 8 Dec 2000 12:44:55 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA37648;
	Fri, 8 Dec 2000 12:44:33 -0500
Received: from creeper.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA23560;
	Fri, 8 Dec 2000 12:44:26 -0500
Received: from ec02-hou.bmc.com (localhost [127.0.0.1])
	by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id eB8High05354;
	Fri, 8 Dec 2000 11:44:42 -0600 (CST)
Received: by EC02-HOU.bmc.com with Internet Mail Service (5.5.2650.21)
	id <X8RCMJTB>; Fri, 8 Dec 2000 11:44:55 -0600
Message-Id: <F7E4D46ABD8FD211928E00A0C9EBD1D603E0EA48@es01-sjc.bmc.com>
From: "Ayers, Mike" <Mike_Ayers@bmc.com>
To: "'Larry S. Bartz'" <lbartz@parnelli.indy.cr.irs.gov>,
        Lee Rafalow
	 <rafalow@raleigh.ibm.com>
Cc: policy@raleigh.ibm.com, wg-ldap@dmtf.org
Subject: RE: matching rules for directoryString [was: Re: CIM24 schema twe
	aks]
Date: Fri, 8 Dec 2000 11:47:15 -0600
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Ayers, Mike" <Mike_Ayers@bmc.com>


> From: Larry S. Bartz [mailto:lbartz@parnelli.indy.cr.irs.gov]
>
> I think the answer depends in part on how much we care about
> supporting
> internationalization, and for which attributes. "Ignore case" is
> meaningless (maybe dangerous) if the string is a UTF-8 representation
> of a non-ASCII character set.

	Not quite true.  Since, in UTF-8, all octets which comprise a
character higher than 0x7F have the MSB set, the case folding rules will
ignore everything except the ASCII range.  However, folding case in only
this range produces quirky results with European languages which use
characters outside the ASCII range (umlauted vowels, etc.), since the
algorithm will fold everything except a few characters.  See
http://www.unicode.org/unicode/reports/tr21/ for more.


	HTH,

/|/|ike


From majordomo@raleigh.ibm.com  Fri Dec  8 22:31:10 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24927
	for <policy-archive@odin.ietf.org>; Fri, 8 Dec 2000 22:31:10 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id WAA43784;
	Fri, 8 Dec 2000 22:19:54 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id WAA35310;
	Fri, 8 Dec 2000 22:19:51 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA42116; Fri, 8 Dec 2000 10:30:00 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA61048; Fri, 8 Dec 2000 10:29:57 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA24654
	for <policy@raleigh.ibm.com>; Fri, 8 Dec 2000 10:29:59 -0500
Received: from longsys.com (dmz.longsys.com [63.111.150.5])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA34448
	for <policy@raleigh.ibm.com>; Fri, 8 Dec 2000 10:29:55 -0500
Received: from joel (discordian.longsys.com [63.111.150.74])
	by longsys.com (8.10.0/8.10.0) with ESMTP id eB8ExZ928653;
	Fri, 8 Dec 2000 14:59:35 GMT
Message-Id: <4.2.2.20001208095537.00b67390@localhost>
X-Sender: joel@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 08 Dec 2000 09:57:23 -0500
To: Andrew Smith <andrew@allegronetworks.com>,
        Brian E Carpenter <brian@hursley.ibm.com>
From: "Joel M. Halpern" <joel@longsys.com>
Subject: Re: [Diffserv] Re: DSCP marking versus DSCP remarking
Cc: Walter Weiss <wweiss@ellacoya.com>,
        "'diffserv@ietf.org'" <diffserv@ietf.org>, policy@raleigh.ibm.com
In-Reply-To: <3A306BAD.5090308@allegronetworks.com>
References: <OFACF3000E.2C79C597-ON852569AC.005D1768@raleigh.ibm.com>
 <4.2.2.20001207172221.00b49520@localhost>
 <3A3020F1.B1448231@hursley.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Joel M. Halpern" <joel@longsys.com>

On the question fo whether to refer to markers and re-markers in teh 
description of the marker action element, I would prefer that we went with:

At 09:03 PM 12/7/00 -0800, Andrew Smith wrote:
>Or should the Model, at this point, just not go there and say merely:
>  "DSCP Markers are 1:1 elements which set the DSCP in an IP header."

If we want to mention the omniscient view-point distinction petween marking 
and remarking it would go in some text that talks about the fact that the 
entire processing stream may be different for packets considered to have 
been processed (marked) from those which have not been sanitized as it were.

Yours,
Joel M. Halpern



From majordomo@raleigh.ibm.com  Sat Dec  9 07:31:14 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04154
	for <policy-archive@odin.ietf.org>; Sat, 9 Dec 2000 07:31:14 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA15896;
	Sat, 9 Dec 2000 07:21:35 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA36836;
	Sat, 9 Dec 2000 07:21:37 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA50586; Sat, 9 Dec 2000 06:33:00 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA50066; Sat, 9 Dec 2000 06:32:56 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id GAA25482
	for <policy@raleigh.ibm.com>; Sat, 9 Dec 2000 06:32:58 -0500
Received: from web10507.mail.yahoo.com (web10507.mail.yahoo.com [216.136.130.157])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id GAA36934
	for <policy@raleigh.ibm.com>; Sat, 9 Dec 2000 06:32:55 -0500
Message-Id: <20001209113257.13992.qmail@web10507.mail.yahoo.com>
Received: from [198.206.187.100] by web10507.mail.yahoo.com; Sat, 09 Dec 2000 03:32:57 PST
Date: Sat, 9 Dec 2000 03:32:57 -0800 (PST)
From: Mahadevan Iyer <iyermahadevan@yahoo.com>
Subject: Policy Domain Comments ...
To: policy@raleigh.ibm.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Mahadevan Iyer <iyermahadevan@yahoo.com>

There are 3 distinct domains in the context of
policies

1. Administrative domain - Relates to setting policies
2. Enforcement domain - Relates to consuming policies
3. Functional domain - Relates to the nature of the
policies

The administrative domain is modeled as a QoS domain
in the QPIM and is reflected in the containment tree.

There are probably stronger arguments to be made for
reflecting the enforcement/functional domain in the
containment tree, from a policy distribution point of
view.

I would like to hear the views of the authors on this
topic. 

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/


From majordomo@raleigh.ibm.com  Sat Dec  9 22:14:55 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22135
	for <policy-archive@odin.ietf.org>; Sat, 9 Dec 2000 22:14:54 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id WAA15980;
	Sat, 9 Dec 2000 22:04:05 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id WAA27916;
	Sat, 9 Dec 2000 22:04:06 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA56156; Sat, 9 Dec 2000 21:24:49 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA41964; Sat, 9 Dec 2000 21:24:41 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id VAA38448
	for <policy@raleigh.ibm.com>; Sat, 9 Dec 2000 21:24:44 -0500
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA34252
	for <policy@raleigh.ibm.com>; Sat, 9 Dec 2000 21:24:41 -0500
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id SAA15516;
	Sat, 9 Dec 2000 18:24:14 -0800 (PST)
Received: from jstrassnlap (sjck-dial-gw5-24.cisco.com [10.19.238.25])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with SMTP id AEE00875;
	Sat, 9 Dec 2000 18:23:57 -0800 (PST)
Message-Id: <001301c06250$bdf1cca0$19ee130a@cisco.com>
From: "John Strassner" <jstrassn@cisco.com>
To: "Mahadevan Iyer" <iyermahadevan@yahoo.com>,
        "Marcus Brunner" <brunner@ccrle.nec.de>, "Ron Cohen" <ronc@cisco.com>
Cc: "Mahadevan Iyer" <iyermahadevan@yahoo.com>, <policy@raleigh.ibm.com>,
        <ipsec-policy@vpnc.org>
References: <20001208043008.17348.qmail@web10501.mail.yahoo.com>
Subject: Re: gpsPolicyGroup class in qos info model
Date: Sat, 9 Dec 2000 18:03:31 -0800
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "John Strassner" <jstrassn@cisco.com>
Content-Transfer-Encoding: 7bit

Hi Mahadevan,

I'm still not quite sure I understand your reasoning for the
putting an aggregate condition in the gpsPolicyRule class. I
also don't think that this works. Let me explain.

As you say, a policyRule is an atomic object. You're asking
to "peek inside" a group of policyRules in a policyGroup and
copy their aggregate conditions out into a higher-level
condition that you can then trap on. At the very minimum,
this means that you also have to copy the decision
strategies that are applied to each group of conditions.
Remember that QPIM defines multiple decision strategies, so
you now have to re-create the decision strategies defined at
each container and apply them to the conditions at each
level of containment. Yuck.

In addition, in QPIM, we have nested rules as well as
sub-rules. You can't flatten out the condition in these
cases, or you lose the hierarchy of the structure of the
rules.

Finally, putting in such optimizations sets a dangerous
standard - where do we stop? Does every relationship and
every different case get standardized, or is this better
handled in an application-specific way?

So in summary, I don't think this can work for QPIM, and
doubt that it can work for PCIM in general. Please explain
how you solve the above problems.

regards,
John
----- Original Message -----
From: "Mahadevan Iyer" <iyermahadevan@yahoo.com>
To: "Marcus Brunner" <brunner@ccrle.nec.de>; "Ron Cohen"
<ronc@cisco.com>
Cc: "Mahadevan Iyer" <iyermahadevan@yahoo.com>;
<policy@raleigh.ibm.com>; <ipsec-policy@vpnc.org>
Sent: Thursday, December 07, 2000 8:30 PM
Subject: Re: gpsPolicyGroup class in qos info model


> Hello Marcus, Ron,
>
>   there are 2 issues mentioned in you responses.
>
> 1. Why not use the PolicyRuleInPolicyRule instead of
> ..
>
>    I must say that if we had started out saying that
> any collection of policies can be logically thought of
> as "a policy"(which I find attractive) I wouldn't have
> minded using this class.
>    However we seemed to have clearly called out the
> notion of a "collection of policies" to be a
> policyGroup. This too has its benefits. This has led
> me to think of the of the PolicyRule as an "atomic"
> class to be aggregated using PolicyGroups.
>
> 2. Why do we need a condition at the level of a
> "collection of policies" ...
>
>    This is an optimization which could be leveraged in
> almost all applications. A PDP can do this on its own
> by analysing the conditions in the contained rules.
> However the administrator can configure far more
> optimal and powerful aggregation of conditions. It is
> possible that these aggregations might be a subset or
> a superset of the aggregation derived by analysing the
> conditions.
>
> Thanks
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of
Products.
> http://shopping.yahoo.com/



From majordomo@raleigh.ibm.com  Sat Dec  9 22:26:16 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24441
	for <policy-archive@odin.ietf.org>; Sat, 9 Dec 2000 22:26:16 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id WAA39054;
	Sat, 9 Dec 2000 22:04:11 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id WAA19496;
	Sat, 9 Dec 2000 22:03:54 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA58876; Sat, 9 Dec 2000 21:24:43 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA56218; Sat, 9 Dec 2000 21:24:36 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id VAA29744
	for <policy@raleigh.ibm.com>; Sat, 9 Dec 2000 21:24:41 -0500
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA29274
	for <policy@raleigh.ibm.com>; Sat, 9 Dec 2000 21:24:35 -0500
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA11283;
	Sat, 9 Dec 2000 18:24:43 -0800 (PST)
Received: from jstrassnlap (sjck-dial-gw5-24.cisco.com [10.19.238.25])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with SMTP id AEE00882;
	Sat, 9 Dec 2000 18:24:22 -0800 (PST)
Message-Id: <001401c06250$cc5c2330$19ee130a@cisco.com>
From: "John Strassner" <jstrassn@cisco.com>
To: <policy@raleigh.ibm.com>,
        "Jean Christophe Martin \(From Home\)" <jcmartin@Eng.Sun.COM>
Cc: <rafalow@us.ibm.com>, <johns@cisco.com>
Subject: Resend of filter alignment message
Date: Sat, 9 Dec 2000 18:05:51 -0800
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "John Strassner" <jstrassn@cisco.com>
Content-Transfer-Encoding: 7bit

It appears that this mail didn't get through, so I'm
resending.

>Hi Jean, I believe your issue is that if you want to build
a
>condition to filter traffic, the IETF IPsec model uses
>classes derived from FilterEntryBase whereas QPIM uses two
>different classes - gpsPolicySimpleCondition and
>gpsPolicyCompoundCondition.
>
>The reason for this is that the QPIM extends the definition
>of a condition into an ordered triplet (i.e., {variable,
>operator, value}). These semantics are not present in the
>current definition of FilterEntryBase or its subclasses.
>Furthermore, the QPIM further extends these semantics to
>define a set of classes to model a set of common variables,
>a corresponding set of classes to model the values that the
>variables can take, and relationships to:
>
>   1) constrain the values that a given variable can take
>   2) relate the variables and values to a condition
>   3) represent reusable variables and values
>
>Note that an implementation could in fact produce a
>FilterEntry from these classes.
>
>HTH and kind regards,
>John
>----- Original Message -----
>From: "Jean Christophe Martin (From Home)"
><jcmartin@eng.sun.com>
>To: "Yoram Ramberg" <yramberg@cisco.com>; <johns@cisco.com>
>Cc: <policy@raleigh.ibm.com>
>Sent: Wednesday, November 29, 2000 9:51 AM
>Subject: Re: new version of QPIM
>
>
> > Yoram , John
> >
> >> A new (-02) version of the QoS Policy Information
> >> Model draft has been sent to the IETF for posting.
> >
> > Here is the motivation of my first mail to the alias :
> >
> > The CIM Network sub-model defines the elements :
> > FilterList, FilterEntryBase and FilterEntry.
> > These Filters are describing the traffic in the
> > Forwarding Path.
> >
> > The IPSEC policy Model (IETF/DMTF) is using these
> > classes as the basis for the condition part of
> > the policy.
> >
> > However, your draft is redefining a condition object
> > that is not at all aligned with the IETF (IPSEC) or
> > the DMTF (QoS Device Sub-Model & IPSEC).
> >
> > Do you have any plans to change your draft so that,
> > at a minimum, one can reuse already existing Filters as
> > Conditions in the QoS Policy Model ?
> >
> > Thanks.
> >
> > JC.

regards,
John



From majordomo@raleigh.ibm.com  Sat Dec  9 22:40:29 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28268
	for <policy-archive@odin.ietf.org>; Sat, 9 Dec 2000 22:40:29 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id WAA45714;
	Sat, 9 Dec 2000 22:11:29 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id WAA37076;
	Sat, 9 Dec 2000 22:04:08 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA45136; Sat, 9 Dec 2000 21:24:26 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA51270; Sat, 9 Dec 2000 21:24:22 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id VAA37114
	for <policy@raleigh.ibm.com>; Sat, 9 Dec 2000 21:24:26 -0500
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA34996
	for <policy@raleigh.ibm.com>; Sat, 9 Dec 2000 21:24:24 -0500
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id SAA15460;
	Sat, 9 Dec 2000 18:23:56 -0800 (PST)
Received: from jstrassnlap (sjck-dial-gw5-24.cisco.com [10.19.238.25])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with SMTP id AEE00871;
	Sat, 9 Dec 2000 18:23:23 -0800 (PST)
Message-Id: <001201c06250$b7a73bf0$19ee130a@cisco.com>
From: "John Strassner" <jstrassn@cisco.com>
To: "Marcus Brunner" <brunner@ccrle.nec.de>, "Ron Cohen" <ronc@cisco.com>
Cc: "Mahadevan Iyer" <iyermahadevan@yahoo.com>, <policy@raleigh.ibm.com>,
        <ipsec-policy@vpnc.org>
References: <4.3.2.7.2.20001207003148.00b3a240@csi-admin1> <20001208052955.6CB587DCF@imap.heidelberg.ccrle.nec.de>
Subject: Re: gpsPolicyGroup class in qos info model
Date: Sat, 9 Dec 2000 17:56:14 -0800
Mime-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "John Strassner" <jstrassn@cisco.com>
Content-Transfer-Encoding: 7bit

PolicyRuleInPolicyRule is used to build sub-rules. We also
allow for PolicyGroupInPolicyRule to build a sub-rule, with
a policyGroup as a nested container. This capability is not
in PCIM.

As far as the context, sub-rules execute before their
containing rules, as explained in the draft.

I not only don't like conditions in gpsPolicyGroup, I don't
think they work.

regards,
John
----- Original Message -----
From: "Marcus Brunner" <brunner@ccrle.nec.de>
To: "Ron Cohen" <ronc@cisco.com>
Cc: "Mahadevan Iyer" <iyermahadevan@yahoo.com>;
<policy@raleigh.ibm.com>; <ipsec-policy@vpnc.org>
Sent: Thursday, December 07, 2000 9:29 PM
Subject: Re: gpsPolicyGroup class in qos info model


> Ron,
>
> I agree with Mahadevan, that I do not like the
policyRuleInPolicyRule method,
> because
> a) there are now two different grouping models,
> b) it is unclear what happens to the context when the
ruleInrule is executed
> (full new start of execution engine or reuse the context)
> c) I do not see the need for rulesInrules, what makes them
different compared to
> the grouping already available
>
> However, I do not agree to add a condition to the group. I
think what is
> available is enough.
>
> Marcus
>
> Quoting Ron Cohen <ronc@cisco.com>:
>
> > Mahadevan,
> >
> > Can you provide more details why you prefer to change
the gpsPolicyGroup
> > than using the current policyRuleInPolicyRule method?
> >
> > Thanks
> > Ron
> >
> >
> > >I would like to suggest an update to the
> > >gpsPolicyGroup class.
> > >This also relates to the PolicyRuleInPolicyRule usage.
> > >
> > >I need to indicate that a group of policy rules should
> > >be checked only if the traffic matches some aggregate
> > >conditions. These aggregate conditions summarize the
> > >conditions within the policy rules.
> > >
> > >I would like to specify the aggregate conditions at
> > >the level of the gpsPolicyGroup. An alternative is to
> > >use the PolicyRule + PolicyRuleInPolicyRule instead of
> > >the gpsPolicyGroup. However I prefer to use the
> > >gpsPolicyGroup.
> > >
> > >I would suggest adding an aggregate policy condition
> > >to the gpsPolicyGroup. This condition would typically
> > >be a gpsPolicyCompoundCondition.
> > >
> > >
> > >Thanks
> > >
> > >__________________________________________________
> > >Do You Yahoo!?
> > >Yahoo! Shopping - Thousands of Stores. Millions of
Products.
> > >http://shopping.yahoo.com/
> >
> >
>
>
>
> Dr. Marcus Brunner
> C&C Research Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.tik.ee.ethz.ch/~brunner
>
> Adenauerplatz 6
> D-69115 Heidelberg
> Germany
>
> Phone: +49 (0)6221/ 9051129
> Fax:   +49 (0)6221/ 9051155



From majordomo@raleigh.ibm.com  Sat Dec  9 22:48:09 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29819
	for <policy-archive@odin.ietf.org>; Sat, 9 Dec 2000 22:48:09 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id WAA35020;
	Sat, 9 Dec 2000 22:29:07 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id WAA28814;
	Sat, 9 Dec 2000 22:15:47 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43268; Sat, 9 Dec 2000 21:39:23 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA51270; Sat, 9 Dec 2000 21:24:22 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id VAA37114
	for <policy@raleigh.ibm.com>; Sat, 9 Dec 2000 21:24:26 -0500
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA34996
	for <policy@raleigh.ibm.com>; Sat, 9 Dec 2000 21:24:24 -0500
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id SAA15460;
	Sat, 9 Dec 2000 18:23:56 -0800 (PST)
Received: from jstrassnlap (sjck-dial-gw5-24.cisco.com [10.19.238.25])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with SMTP id AEE00871;
	Sat, 9 Dec 2000 18:23:23 -0800 (PST)
Message-Id: <001201c06250$b7a73bf0$19ee130a@cisco.com>
From: "John Strassner" <jstrassn@cisco.com>
To: "Marcus Brunner" <brunner@ccrle.nec.de>, "Ron Cohen" <ronc@cisco.com>
Cc: "Mahadevan Iyer" <iyermahadevan@yahoo.com>, <policy@raleigh.ibm.com>,
        <ipsec-policy@vpnc.org>
References: <4.3.2.7.2.20001207003148.00b3a240@csi-admin1> <20001208052955.6CB587DCF@imap.heidelberg.ccrle.nec.de>
Subject: Re: gpsPolicyGroup class in qos info model
Date: Sat, 9 Dec 2000 17:56:14 -0800
Mime-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "John Strassner" <jstrassn@cisco.com>
Content-Transfer-Encoding: 7bit

PolicyRuleInPolicyRule is used to build sub-rules. We also
allow for PolicyGroupInPolicyRule to build a sub-rule, with
a policyGroup as a nested container. This capability is not
in PCIM.

As far as the context, sub-rules execute before their
containing rules, as explained in the draft.

I not only don't like conditions in gpsPolicyGroup, I don't
think they work.

regards,
John
----- Original Message -----
From: "Marcus Brunner" <brunner@ccrle.nec.de>
To: "Ron Cohen" <ronc@cisco.com>
Cc: "Mahadevan Iyer" <iyermahadevan@yahoo.com>;
<policy@raleigh.ibm.com>; <ipsec-policy@vpnc.org>
Sent: Thursday, December 07, 2000 9:29 PM
Subject: Re: gpsPolicyGroup class in qos info model


> Ron,
>
> I agree with Mahadevan, that I do not like the
policyRuleInPolicyRule method,
> because
> a) there are now two different grouping models,
> b) it is unclear what happens to the context when the
ruleInrule is executed
> (full new start of execution engine or reuse the context)
> c) I do not see the need for rulesInrules, what makes them
different compared to
> the grouping already available
>
> However, I do not agree to add a condition to the group. I
think what is
> available is enough.
>
> Marcus
>
> Quoting Ron Cohen <ronc@cisco.com>:
>
> > Mahadevan,
> >
> > Can you provide more details why you prefer to change
the gpsPolicyGroup
> > than using the current policyRuleInPolicyRule method?
> >
> > Thanks
> > Ron
> >
> >
> > >I would like to suggest an update to the
> > >gpsPolicyGroup class.
> > >This also relates to the PolicyRuleInPolicyRule usage.
> > >
> > >I need to indicate that a group of policy rules should
> > >be checked only if the traffic matches some aggregate
> > >conditions. These aggregate conditions summarize the
> > >conditions within the policy rules.
> > >
> > >I would like to specify the aggregate conditions at
> > >the level of the gpsPolicyGroup. An alternative is to
> > >use the PolicyRule + PolicyRuleInPolicyRule instead of
> > >the gpsPolicyGroup. However I prefer to use the
> > >gpsPolicyGroup.
> > >
> > >I would suggest adding an aggregate policy condition
> > >to the gpsPolicyGroup. This condition would typically
> > >be a gpsPolicyCompoundCondition.
> > >
> > >
> > >Thanks
> > >
> > >__________________________________________________
> > >Do You Yahoo!?
> > >Yahoo! Shopping - Thousands of Stores. Millions of
Products.
> > >http://shopping.yahoo.com/
> >
> >
>
>
>
> Dr. Marcus Brunner
> C&C Research Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.tik.ee.ethz.ch/~brunner
>
> Adenauerplatz 6
> D-69115 Heidelberg
> Germany
>
> Phone: +49 (0)6221/ 9051129
> Fax:   +49 (0)6221/ 9051155



From majordomo@raleigh.ibm.com  Sun Dec 10 03:11:43 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01041
	for <policy-archive@odin.ietf.org>; Sun, 10 Dec 2000 03:11:42 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA33226;
	Sun, 10 Dec 2000 03:02:25 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id DAA29536;
	Sun, 10 Dec 2000 03:02:24 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA26018; Sun, 10 Dec 2000 02:18:10 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA41846; Sun, 10 Dec 2000 02:18:04 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id CAA23126
	for <policy@raleigh.ibm.com>; Sun, 10 Dec 2000 02:18:04 -0500
Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id CAA29042
	for <policy@raleigh.ibm.com>; Sun, 10 Dec 2000 02:18:01 -0500
Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id CAA05242
	for <policy@raleigh.ibm.com>; Sun, 10 Dec 2000 02:18:34 -0500 (EST)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id CAA05228
	for <policy@raleigh.ibm.com>; Sun, 10 Dec 2000 02:18:33 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21)
	id <YCJP6Z4Q>; Sun, 10 Dec 2000 08:18:21 +0100
Message-Id: <2413FED0DFE6D111B3F90008C7FA61FB0A670510@nl0006exch002u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Andrea Westerinen <andreaw@cisco.com>, snmpconf@snmp.com
Cc: Policy Mailing List <policy@raleigh.ibm.com>
Subject: RE: snmpconf Re: Comments on the draft-ietf-policy-terminology-00
	.txt document
Date: Sun, 10 Dec 2000 08:18:21 +0100
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>



> ----------
> From: 	Jon Saperia[SMTP:saperia@mediaone.net]
> Reply To: 	snmpconf@snmp.com
> Sent: 	Tuesday, November 21, 2000 11:01 AM
> To: 	Andrea Westerinen
> Cc: 	policy@raleigh.ibm.com; snmpconf
> Subject: 	snmpconf Re: Comments on the
> draft-ietf-policy-terminology-00.txt document
> 
> Thanks for all the comments. I look forward to the next draft.
> 
> /jon
> 


From majordomo@raleigh.ibm.com  Mon Dec 11 00:17:11 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00185
	for <policy-archive@odin.ietf.org>; Mon, 11 Dec 2000 00:17:11 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA38434;
	Mon, 11 Dec 2000 00:07:52 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id AAA25764;
	Mon, 11 Dec 2000 00:07:49 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA47980; Sun, 10 Dec 2000 23:26:40 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA50520; Sun, 10 Dec 2000 23:26:36 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id XAA29592
	for <policy@raleigh.ibm.com>; Sun, 10 Dec 2000 23:26:40 -0500
Received: from web10501.mail.yahoo.com (web10501.mail.yahoo.com [216.136.130.151])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id XAA17984
	for <policy@raleigh.ibm.com>; Sun, 10 Dec 2000 23:26:32 -0500
Message-Id: <20001211042641.30000.qmail@web10501.mail.yahoo.com>
Received: from [198.206.187.100] by web10501.mail.yahoo.com; Sun, 10 Dec 2000 20:26:41 PST
Date: Sun, 10 Dec 2000 20:26:41 -0800 (PST)
From: Mahadevan Iyer <iyermahadevan@yahoo.com>
Subject: Re: gpsPolicyGroup class in qos info model
To: John Strassner <johns@cisco.com>, Marcus Brunner <brunner@ccrle.nec.de>,
        Ron Cohen <ronc@cisco.com>
Cc: policy@raleigh.ibm.com, ipsec-policy@vpnc.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Mahadevan Iyer <iyermahadevan@yahoo.com>

--- John Strassner <jstrassn@cisco.com> wrote:
> Hi Mahadevan,
> 
> I'm still not quite sure I understand your reasoning
> for the
> putting an aggregate condition in the gpsPolicyRule
> class. 

Hello John,

there are 2 parts to this reply :

  1. Issues raised in your response, 
  2. Explanation of the requirement.

Issues raised in your response ...

  1. There is no "peeking" inside the rules, it is an
administrator generated condition. This should answer
most of your issues related to aggregating conditions
and decisions.

  2. The PolicyRuleInPolicyRule can satisfy the
requirement. I have explained my reservations
regarding using this class in my earlier email.

Explanation of the requirement ...

  1. The requirements is driven from the practical
issues at the PDP. I have a whole tree of policies and
nothing but the priority to decide how I traverse the
tree(at the group level). This could be a very
expensive. I need to have a quick way of narrowing
down the possibilities at the top of the tree(where
the policyGroups are defined). It is a lot more than
an optimization, it would be a requirement when
defining policy trees for a carrier network.

Do you see this as a problem that needs to be
addressed at this level ?


Thanks


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/


From majordomo@raleigh.ibm.com  Mon Dec 11 00:40:08 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05945
	for <policy-archive@odin.ietf.org>; Mon, 11 Dec 2000 00:40:08 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA39640;
	Mon, 11 Dec 2000 00:21:31 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id AAA38462;
	Mon, 11 Dec 2000 00:21:28 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA35300; Sun, 10 Dec 2000 23:41:53 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA27354; Sun, 10 Dec 2000 23:41:49 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id XAA27286
	for <policy@raleigh.ibm.com>; Sun, 10 Dec 2000 23:41:55 -0500
Received: from web10502.mail.yahoo.com (web10502.mail.yahoo.com [216.136.130.152])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id XAA21908
	for <policy@raleigh.ibm.com>; Sun, 10 Dec 2000 23:41:52 -0500
Message-Id: <20001211044156.13902.qmail@web10502.mail.yahoo.com>
Received: from [198.206.187.100] by web10502.mail.yahoo.com; Sun, 10 Dec 2000 20:41:56 PST
Date: Sun, 10 Dec 2000 20:41:56 -0800 (PST)
From: Mahadevan Iyer <iyermahadevan@yahoo.com>
Subject: Policy Target Comments for PCIM/QPIM ...
To: policy@raleigh.ibm.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Mahadevan Iyer <iyermahadevan@yahoo.com>

These comments are related to "policy targets" as
defined in "draft-mahon-policy-use-00.txt".

The association of a policy target to the policy rule
seems to be implicit based on the network nodes
referenced in the policy. One could also add policy
conditions to a policy rule to make this association
more explicit.

The draft points to some reasons why the mention
should be more explicit. I can think of some
reasons(primarily distribution related) where it would
be useful to have explicit references to the targets.

Would it make sense to formalize the reference of a
policyGroup or policyRule to policy targets?

Thanks

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/


From majordomo@raleigh.ibm.com  Mon Dec 11 00:47:39 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07542
	for <policy-archive@odin.ietf.org>; Mon, 11 Dec 2000 00:47:39 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA38610;
	Mon, 11 Dec 2000 00:21:30 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id AAA31540;
	Mon, 11 Dec 2000 00:21:30 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA58638; Sun, 10 Dec 2000 23:39:28 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA50520; Sun, 10 Dec 2000 23:26:36 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id XAA29592
	for <policy@raleigh.ibm.com>; Sun, 10 Dec 2000 23:26:40 -0500
Received: from web10501.mail.yahoo.com (web10501.mail.yahoo.com [216.136.130.151])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id XAA17984
	for <policy@raleigh.ibm.com>; Sun, 10 Dec 2000 23:26:32 -0500
Message-Id: <20001211042641.30000.qmail@web10501.mail.yahoo.com>
Received: from [198.206.187.100] by web10501.mail.yahoo.com; Sun, 10 Dec 2000 20:26:41 PST
Date: Sun, 10 Dec 2000 20:26:41 -0800 (PST)
From: Mahadevan Iyer <iyermahadevan@yahoo.com>
Subject: Re: gpsPolicyGroup class in qos info model
To: John Strassner <johns@cisco.com>, Marcus Brunner <brunner@ccrle.nec.de>,
        Ron Cohen <ronc@cisco.com>
Cc: policy@raleigh.ibm.com, ipsec-policy@vpnc.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Mahadevan Iyer <iyermahadevan@yahoo.com>

--- John Strassner <jstrassn@cisco.com> wrote:
> Hi Mahadevan,
> 
> I'm still not quite sure I understand your reasoning
> for the
> putting an aggregate condition in the gpsPolicyRule
> class. 

Hello John,

there are 2 parts to this reply :

  1. Issues raised in your response, 
  2. Explanation of the requirement.

Issues raised in your response ...

  1. There is no "peeking" inside the rules, it is an
administrator generated condition. This should answer
most of your issues related to aggregating conditions
and decisions.

  2. The PolicyRuleInPolicyRule can satisfy the
requirement. I have explained my reservations
regarding using this class in my earlier email.

Explanation of the requirement ...

  1. The requirements is driven from the practical
issues at the PDP. I have a whole tree of policies and
nothing but the priority to decide how I traverse the
tree(at the group level). This could be a very
expensive. I need to have a quick way of narrowing
down the possibilities at the top of the tree(where
the policyGroups are defined). It is a lot more than
an optimization, it would be a requirement when
defining policy trees for a carrier network.

Do you see this as a problem that needs to be
addressed at this level ?


Thanks


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/


From majordomo@raleigh.ibm.com  Mon Dec 11 18:02:59 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26181
	for <policy-archive@odin.ietf.org>; Mon, 11 Dec 2000 18:02:59 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA11096;
	Mon, 11 Dec 2000 17:50:02 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA29952;
	Mon, 11 Dec 2000 17:49:47 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA39416; Mon, 11 Dec 2000 16:59:08 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA33520; Mon, 11 Dec 2000 16:59:04 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA31512
	for <policy@raleigh.ibm.com>; Mon, 11 Dec 2000 16:59:08 -0500
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA18000
	for <policy@raleigh.ibm.com>; Mon, 11 Dec 2000 16:59:04 -0500
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Mon, 11 Dec 2000 12:36:57 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 11 Dec 2000 12:37:39 -0800 (Pacific Standard Time)
Received: from DF-MILO.platinum.corp.microsoft.com ([172.30.236.125]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532);
	 Mon, 11 Dec 2000 12:37:38 -0800
Content-Class: urn:content-classes:message
Subject: comments on draft-ietf-policy-qos-device-info-model-02.txt
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C063B2.32881A2C"
Date: Mon, 11 Dec 2000 12:37:36 -0800
X-Mimeole: Produced By Microsoft Exchange V6.0.4604.0
Message-Id: <A5769B3C2F02274B9D17F5FB4495DD5F2CC4D7@DF-SCOOBY.platinum.corp.microsoft.com>
Thread-Topic: comments on draft-ietf-policy-qos-device-info-model-02.txt
Thread-Index: AcBjsoK0xW8/XuVkRoqjQajZN3bHtw==
From: "Yoram Bernet" <yoramb@Exchange.Microsoft.com>
To: <policy@raleigh.ibm.com>
X-Originalarrivaltime: 11 Dec 2000 20:37:38.0772 (UTC) FILETIME=[339E6140:01C063B2]
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Yoram Bernet" <yoramb@Exchange.Microsoft.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C063B2.32881A2C
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Here are a couple of high level comments on the above draft:

Distinction between IntServ and DiffServ
Introductory sections distinguish between IntServ and DiffServ, but on
shaky grounds. Fore example, section 2.1states that IntServ differs from
DiffServ because it forwards based on 5-tuples, whereas DiffServ
(mostly) forwards based on DSCP. It also states that IntServ is much
more dynamic than DiffServ. It also states that DiffServ operates
exclusively in the forwarding plane. None of these strike me as true.
Many associate IntServ with 5-tuple classification, but this is not
necessarily the case. IntServ can be applied to aggregates (just see
1633). Also - IntServ can be invoked dynamically, when used with RSVP,
but nothing dictates that it be used with RSVP. Further, nothing says
that DiffServ should be static -- especially, when considering using
DiffServ at ingress routers to mark based on MF criteria, DiffServ will
have to be quite dynamic. Finally, DiffServ operates quite significantly
at ingress nodes in classifying, marking, policing, none of which are
really 'forwarding' functions. So - I see the distinction between
IntServ and DiffServ, with respect to classification, scheduling,
buffering and policing (all types of traffic handling), to be quite
arbitrary.

I think that a much more useful distinction is between the configuration
of traffic handling components (which are common to IntServ and
DiffServ) on the one hand and the mechanisms used to configure these
(such as COPS, SNMP, RSVP, etc) on the other hand. I think that this
draft is mostly about traffic handling, which is common to both IntServ
and DiffServ. In other words - the traffic handling is mostly forwarding
path or data path stuff. The other stuff is control-plane stuff.

Use of the term 'service'
Probably because of the cim background, the term 'services' is used
quite liberally in this draft, and I ifnd it very confusing. In section
3.6, it states that: QoS
   is a set of services that can be controlled using policy.  These
services are represented as device mechanisms. Device mechanism are not
services nor do they represent services. Services in DiffServ are much
more than device mechanisms - they are combinations of device mechanisms
coupled with policing and related criteria. The use of the term
'services' throughout the draft should be significantly scaled back. In
addition, the usage should be defined up front.=20

More as I read further.

Yoram

------_=_NextPart_001_01C063B2.32881A2C
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4604.0">
<TITLE>comments on =
draft-ietf-policy-qos-device-info-model-02.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Here are a couple of high level =
comments on the above draft:</FONT>
</P>

<P><U><FONT SIZE=3D2 FACE=3D"Arial">Distinction between IntServ and =
DiffServ</FONT></U>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Introductory sections distinguish =
between IntServ and DiffServ, but on shaky grounds. Fore example, =
section 2.1states that IntServ differs from DiffServ because it forwards =
based on 5-tuples, whereas DiffServ (mostly) forwards based on DSCP. It =
also states that IntServ is much more dynamic than DiffServ. It also =
states that DiffServ operates exclusively in the forwarding plane. None =
of these strike me as true. Many associate IntServ with 5-tuple =
classification, but this is not necessarily the case. IntServ can be =
applied to aggregates (just see 1633). Also - IntServ can be invoked =
dynamically, when used with RSVP, but nothing dictates that it be used =
with RSVP. Further, nothing says that DiffServ should be static -- =
especially, when considering using DiffServ at ingress routers to mark =
based on MF criteria, DiffServ will have to be quite dynamic. Finally, =
DiffServ operates quite significantly at ingress nodes in classifying, =
marking, policing, none of which are really 'forwarding' functions. So - =
I see the distinction between IntServ and DiffServ, with respect to =
classification, scheduling, buffering and policing (all types of traffic =
handling), to be quite arbitrary.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I think that a much more useful =
distinction is between the configuration of traffic handling components =
(which are common to IntServ and DiffServ) on the one hand and the =
mechanisms used to configure these (such as COPS, SNMP, RSVP, etc) on =
the other hand. I think that this draft is mostly about traffic =
handling, which is common to both IntServ and DiffServ. In other words - =
the traffic handling is mostly forwarding path or data path stuff. The =
other stuff is control-plane stuff.</FONT></P>

<P><U><FONT SIZE=3D2 FACE=3D"Arial">Use of the term 'service'</FONT></U>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Probably because of the cim =
background, the term 'services' is used quite liberally in this draft, =
and I ifnd it very confusing. In section 3.6, it states that:</FONT> =
<FONT SIZE=3D2 FACE=3D"Courier New">QoS</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; is a set of services =
that can be controlled using policy.&nbsp; These</FONT><FONT =
FACE=3D"Times New Roman">&nbsp;</FONT>&nbsp;<FONT SIZE=3D2 =
FACE=3D"Courier New"> services are represented as device =
mechanisms</FONT><FONT FACE=3D"Times New Roman">.</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">Device mechanism are not services nor do they represent =
services. Services in DiffServ are much more than device mechanisms - =
they are combinations of device mechanisms coupled with policing and =
related criteria. The use of the term 'services' throughout the draft =
should be significantly scaled back. In addition, the usage should be =
defined up front. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">More as I read further.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Yoram</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C063B2.32881A2C--


From majordomo@raleigh.ibm.com  Mon Dec 11 20:41:53 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23893
	for <policy-archive@odin.ietf.org>; Mon, 11 Dec 2000 20:41:53 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id UAA30672;
	Mon, 11 Dec 2000 20:29:17 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id UAA27928;
	Mon, 11 Dec 2000 20:29:16 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA30802; Mon, 11 Dec 2000 14:23:26 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA36938; Mon, 11 Dec 2000 14:23:23 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA31186
	for <policy@raleigh.ibm.com>; Mon, 11 Dec 2000 14:23:26 -0500
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA18104
	for <policy@raleigh.ibm.com>; Mon, 11 Dec 2000 14:23:23 -0500
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA21170;
	Mon, 11 Dec 2000 11:22:54 -0800 (PST)
Received: from jstrassnlap (sj-dial-4-55.cisco.com [171.68.181.184])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with SMTP id AEG08828;
	Mon, 11 Dec 2000 11:22:49 -0800 (PST)
Message-Id: <015401c063a8$3dfe5eb0$b8b544ab@cisco.com>
From: "John Strassner" <jstrassn@cisco.com>
To: "Mahadevan Iyer" <iyermahadevan@yahoo.com>,
        "John Strassner" <johns@cisco.com>,
        "Marcus Brunner" <brunner@ccrle.nec.de>, "Ron Cohen" <ronc@cisco.com>
Cc: <policy@raleigh.ibm.com>, <ipsec-policy@vpnc.org>
References: <20001211042641.30000.qmail@web10501.mail.yahoo.com>
Subject: Re: gpsPolicyGroup class in qos info model
Date: Mon, 11 Dec 2000 11:25:57 -0800
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "John Strassner" <jstrassn@cisco.com>
Content-Transfer-Encoding: 7bit

Hi Mahadevan,

I'm still confused. It sounds like you want to copy the
conditions inside different rules that are contained in
different groups to a higher level of containment in order
to trim the tree, right? This is what I meant when I said:

  "As you say, a policyRule is an atomic object. You're
   asking to "peek inside" a group of policyRules in a
   policyGroup and copy their aggregate conditions out
   into a higher-level condition that you can then
   trap on."

Now, while this may work for PCIM, for QPIM I don't think it
can work, because at the very minimum, this means that you
also have to copy the decision strategies that are applied
to each group of conditions. QPIM provides the ability to
CHANGE decision strategies at each containment level. This
means that you now have to re-create the decision strategies
defined at each container and apply them to the conditions
at each level of containment. You haven't addressed how this
will be done.

In addition, in QPIM, we have nested rules as well as
sub-rules. You can't flatten out the condition in these
cases, or you lose the hierarchy of the structure of the
rules. You also haven't addressed how this will be done.

That's why I continue to have questions.

regards,
John

----- Original Message -----
From: "Mahadevan Iyer" <iyermahadevan@yahoo.com>
To: "John Strassner" <johns@cisco.com>; "Marcus Brunner"
<brunner@ccrle.nec.de>; "Ron Cohen" <ronc@cisco.com>
Cc: <policy@raleigh.ibm.com>; <ipsec-policy@vpnc.org>
Sent: Sunday, December 10, 2000 8:26 PM
Subject: Re: gpsPolicyGroup class in qos info model


> --- John Strassner <jstrassn@cisco.com> wrote:
> > Hi Mahadevan,
> >
> > I'm still not quite sure I understand your reasoning
> > for the
> > putting an aggregate condition in the gpsPolicyRule
> > class.
>
> Hello John,
>
> there are 2 parts to this reply :
>
>   1. Issues raised in your response,
>   2. Explanation of the requirement.
>
> Issues raised in your response ...
>
>   1. There is no "peeking" inside the rules, it is an
> administrator generated condition. This should answer
> most of your issues related to aggregating conditions
> and decisions.
>
>   2. The PolicyRuleInPolicyRule can satisfy the
> requirement. I have explained my reservations
> regarding using this class in my earlier email.
>
> Explanation of the requirement ...
>
>   1. The requirements is driven from the practical
> issues at the PDP. I have a whole tree of policies and
> nothing but the priority to decide how I traverse the
> tree(at the group level). This could be a very
> expensive. I need to have a quick way of narrowing
> down the possibilities at the top of the tree(where
> the policyGroups are defined). It is a lot more than
> an optimization, it would be a requirement when
> defining policy trees for a carrier network.
>
> Do you see this as a problem that needs to be
> addressed at this level ?
>
>
> Thanks
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of
Products.
> http://shopping.yahoo.com/



From majordomo@raleigh.ibm.com  Tue Dec 12 01:25:37 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28676
	for <policy-archive@odin.ietf.org>; Tue, 12 Dec 2000 01:25:36 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id BAA11072;
	Tue, 12 Dec 2000 01:15:49 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id BAA27098;
	Tue, 12 Dec 2000 01:15:43 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43862; Tue, 12 Dec 2000 00:34:26 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA33102; Tue, 12 Dec 2000 00:34:22 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id AAA28486
	for <policy@raleigh.ibm.com>; Tue, 12 Dec 2000 00:34:28 -0500
Received: from web10507.mail.yahoo.com (web10507.mail.yahoo.com [216.136.130.157])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id AAA29734
	for <policy@raleigh.ibm.com>; Tue, 12 Dec 2000 00:34:24 -0500
Message-Id: <20001212053429.7077.qmail@web10507.mail.yahoo.com>
Received: from [198.206.187.100] by web10507.mail.yahoo.com; Mon, 11 Dec 2000 21:34:29 PST
Date: Mon, 11 Dec 2000 21:34:29 -0800 (PST)
From: Mahadevan Iyer <iyermahadevan@yahoo.com>
Subject: Re: gpsPolicyGroup class in qos info model
To: John Strassner <johns@cisco.com>, Marcus Brunner <brunner@ccrle.nec.de>,
        Ron Cohen <ronc@cisco.com>
Cc: policy@raleigh.ibm.com, ipsec-policy@vpnc.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Mahadevan Iyer <iyermahadevan@yahoo.com>

--- John Strassner <jstrassn@cisco.com> wrote:
> I'm still confused. It sounds like you want to copy
> the

Not copy, let the administrator create higher level
condition traps. They might be very coarse and loose.
They will provide a coarse level of aggregation.
I agree that if we try to directly copy we will run
into the problems as you have pointed out.

> conditions inside different rules that are contained
> in
> different groups to a higher level of containment in
> order
> to trim the tree, right? This is what I meant when I
> said:

Exactly right: "Trim the tree" for the decision
process.

> 
>   "As you say, a policyRule is an atomic object.
> You're
>    asking to "peek inside" a group of policyRules in
> a
>    policyGroup and copy their aggregate conditions
> out
>    into a higher-level condition that you can then
>    trap on."

Not copy as stated earlier.

> 
> Now, while this may work for PCIM, for QPIM I don't
> think it
> can work, because at the very minimum, this means
> that you
> also have to copy the decision strategies that are
> applied
> to each group of conditions. QPIM provides the
> ability to
> CHANGE decision strategies at each containment
> level. This
> means that you now have to re-create the decision
> strategies
> defined at each container and apply them to the
> conditions
> at each level of containment. You haven't addressed
> how this
> will be done.

I agree that it will not be feasable to do this
automatically and will not be feasable to do it at
every level. 
It is upto the administrator to decide whether he
wants to include an aggregated condition at a certain
point or not. It is upto the administrator to manually
build the condition.

> 
> In addition, in QPIM, we have nested rules as well
> as
> sub-rules. You can't flatten out the condition in
> these
> cases, or you lose the hierarchy of the structure of
> the
> rules. You also haven't addressed how this will be
> done.
> 
> That's why I continue to have questions.

I hope I have communicated the problem clearly.
At this point I can't think of an alternative solution
to the problem.

As far as the QPIM if I were to take the example
quoted on page 24 (version 02). 

I am assuming that PDP's within a region would try to
trim the policy tree by picking up policies meant for
their respective regions.(I have posted some related
questions "Policy Target, Policy Domains etc" on the
mailing list)

If most of the policies have to  do with inter-region
traffic or inter-group traffic to a hub there isn't
much trimming I can do on the basis of "policies
required by a region". 

In such cases source and destination of the traffic
can be used to zero in into a policy group which then
defines exactly what policies need to be applied to
the  traffic.

Thanks

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/


From majordomo@raleigh.ibm.com  Tue Dec 12 16:28:32 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12767
	for <policy-archive@odin.ietf.org>; Tue, 12 Dec 2000 16:28:32 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA28006;
	Tue, 12 Dec 2000 16:03:01 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA24384;
	Tue, 12 Dec 2000 16:02:20 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA45530; Tue, 12 Dec 2000 15:09:29 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43762; Tue, 12 Dec 2000 14:37:34 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA10248
	for <policy@raleigh.ibm.com>; Tue, 12 Dec 2000 14:37:37 -0500
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA25824
	for <policy@raleigh.ibm.com>; Tue, 12 Dec 2000 14:37:33 -0500
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 12 Dec 2000 10:22:55 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 12 Dec 2000 10:23:37 -0800 (Pacific Standard Time)
Received: from DF-MILO.platinum.corp.microsoft.com ([172.30.236.125]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532);
	 Tue, 12 Dec 2000 10:23:37 -0800
X-Mimeole: Produced By Microsoft Exchange V6.0.4604.0
Content-Class: urn:content-classes:message
Subject: Clarification of comments made during yesterday's WG meeting
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C06468.A49E4626"
Date: Tue, 12 Dec 2000 10:23:36 -0800
Message-Id: <A5769B3C2F02274B9D17F5FB4495DD5F2CC561@DF-SCOOBY.platinum.corp.microsoft.com>
Thread-Topic: comments on draft-ietf-policy-qos-device-info-model-02.txt
Thread-Index: AcBjsoK0xW8/XuVkRoqjQajZN3bHtwArykuA
From: "Yoram Bernet" <yoramb@Exchange.Microsoft.com>
To: <policy@raleigh.ibm.com>
X-Originalarrivaltime: 12 Dec 2000 18:23:37.0228 (UTC) FILETIME=[A4E5E4C0:01C06468]
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Yoram Bernet" <yoramb@Exchange.Microsoft.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C06468.A49E4626
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

At the end of yesterday's meeting, Ed paraphrased my comments. I think
that my comments were not clearly understood. I will attempt to clarify:

The fundamental issue is one of modularization. Policy is such an
overwhelming 'blob' to tackle - as a result, the authors of QDDIM and
QPIM are tackling the effort picemeal. This makes sense. I am not
calling for all pieces of the QoS policy puzzle to be tackled at once.
What i'm calling for is very careful modularization. As I commented
yesterday on the list, the modulariztion in QDDIM strikes me as wrong.
QDDIM repeatedly states that it is tacking the DiffServ module in this
pass and will tackle the IntServ model in the next pass. QPIM talks
about the RSVP part versus the DiffServ part. In QPIM, the two are
pretty much separated, except for the brief part about using RSVP to
return DCLASS objects (whihc are DiffServ related).

In my opinion, the modularization should be one of datapath mechanisms
versus control mechanisms. Datapath mechanisms include:

Classification=20
Metering
Dropping
Marking
Queuing

These are neither IntServ nor DiffServ - they are equally applicable to
both. They are more generic than IntServ or DiffServ.=20

Control mechanisms configure the datapath mechanisms. They include:

SNMP
COPS
RSVP
Others...

Datapath and control mechanisms interact. For example - when a DiffServ
network provider provisions an EF service instance between ingress point
A and egress point B, it's necessary to verify that resources are
available along the path from A to B and to install the appropriate
policers to assure that the EF service is not abused. This requires
interaction between some policy agents and the queuing and
classification mechanisms in at least some of the network elements along
the path from A to B. Part of this interaction involves admission
control (are there sufficient resources to support the SLA? can the new
service be provisioned without violating other SLAs?), part of it
amounts to configuring policers. Similarly, when an RSVP request arrives
at a PEP/PDP, it is necessary to apply admission control, and then to
configure policers and queuing in accordance with the admission control
decision.=20

So - IMHO, the drafts should identify the two types of mechanisms and
the types of interaction between them. They may then choose to tackle
one set or the other set at this time, with the remainder to be tackled
later. However - they should not draw distinctions between IntServ
*versus* DiffServ, nor between DiffServ *versus* RSVP. This distinction
is misleading and short sighted. Just consider that RSVP can be used for
admission control to and configuration of DiffServ traffic handling
mechanisms just as it can be used for admission to and control of
microflow (per 5-tuple) traffic handling mechanisms. Consider that a
single end-to-end path may offer aggregate traffic handling (diffserv)
in certain devices and per-flow traffic handling (traditionally
associated with intserv) in other devices.

In summary, a full service QoS network should be able to make use of
per-flow traffic handling, aggregate traffic handling, relatively static
'push' provisioning and configuration mechanisms and the more dynamic
RSVP signaling configuration mechanism *all in the same network*. Policy
should focus on how these interact seamlessly, thereby uniting them. As
the drafts carve out pieces to tackle, these interactions should be
noted and similar pieces should be tackled in the same draft.=20

This is a difficult message to convey - it's somewhat abstract. So -
here's a concrete example of what happens when we artificially separate
RSVP/IntServ from DiffServ:

***************** Example*******************

Consider how COPS/RSVP and COPS/PR are used between PEPs and PDPs:

COPS/RSVP:
* An RSVP message arrives at a PEP. It is a request for resources that
specifies the type of service desired, the amount of traffic for which
this service is required and the classification information by which the
traffic can be recognized.
* The PDP makes an admission control decision.
* If the request is admitted, then the PDP tells the PEP that the
request is admitted.=20
* Now the PEP configures: 1. a microflow classifier corresponding to the
5-tuple in the RSVP message 2. a policer corresponding to the tspec in
the RSVP message 3. the appropriate queuing to provide the service
approved (2 and 3 are closely related).

COPS/PR:
* A PEP needs to be configured to support a certain SLA for certain
traffic.
* The PDP must check with the PEP to be sure that it can accommodate
the SLA (admission control decision is made)
* If the SLA can be supported, the PDP configures in the PEP: 1. a
classifier (potentially microflow) corresponding to the customer traffic
stream to recieve the diffserv service per the SLA. 2. a policer to
protect the diffserv network and possibly to protect one subset of the
customer's traffic from another. 3. the appropriate queuing in the same
or in subsequent PEPs.=20

Note that in both cases, there is a need to configure classifiers,
policers and queuing mechanisms in PEPs. In the first case, the PDP does
so indirectly (by admitting the RSVP request). In the second case, it
does so directly. However, in both cases - the result is to consume
resources from the same interfaces. It would have been much simpler if
the work of COPS was separated into 1. responding to provisioning and
configuration requests (whetehr they arrvie by RSVP or by administrative
control) and 2. configuring traffic handling mechanisms. In that case,
the COPS/RSVP example would have the PDP directly configuring the
traffic handling mechanisms in response to the RSVP message, just as it
does in the COPS/PR case. There is overlap between COPS/PR and COPS/RSVP
that is related to an artificial distinction between RSVP/IntServ and
DiffServ.
***********************************************=20


------_=_NextPart_001_01C06468.A49E4626
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4604.0">
<TITLE>Clarification of comments made during yesterday's WG =
meeting</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">At the end of =
yesterday's meeting, Ed paraphrased my comments. I think that my =
comments were not clearly understood. I will attempt to =
clarify:</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The fundamental issue =
is one of modularization. Policy is such an overwhelming 'blob' to =
tackle - as a result, the authors of QDDIM and QPIM are tackling the =
effort picemeal. This makes sense. I am not calling for all pieces of =
the QoS policy puzzle to be tackled at once. What i'm calling for is =
very careful modularization. As I commented yesterday on the list, the =
modulariztion in QDDIM strikes me as wrong. QDDIM repeatedly states that =
it is tacking the DiffServ module in this pass and will tackle the =
IntServ model in the next pass. QPIM talks about the RSVP part versus =
the DiffServ part. In QPIM, the two are pretty much separated, except =
for the brief part about using RSVP to return DCLASS objects (whihc are =
DiffServ related).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">In my opinion, the =
modularization should be one of datapath mechanisms versus control =
mechanisms. Datapath mechanisms include:</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Classification =
</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Metering</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Dropping</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Marking</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Queuing</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">These are neither =
IntServ nor DiffServ - they are equally applicable to both. They are =
more generic than IntServ or DiffServ. </FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Control mechanisms =
configure the datapath mechanisms. They include:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">SNMP</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">COPS</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">RSVP</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Others...</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Datapath and control =
mechanisms interact. For example - when a DiffServ network provider =
provisions an EF service instance between ingress point A and egress =
point B, it's necessary to verify that resources are available along the =
path from A to B and to install the appropriate policers to assure that =
the EF service is not abused. This requires interaction between some =
policy agents and the queuing and classification mechanisms in at least =
some of the network elements along the path from A to B. Part of this =
interaction involves admission control (are there sufficient resources =
to support the SLA? can the new service be provisioned without violating =
other SLAs?), part of it amounts to configuring policers. Similarly, =
when an RSVP request arrives at a PEP/PDP, it is necessary to apply =
admission control, and then to configure policers and queuing in =
accordance with the admission control decision. </FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">So - IMHO, the drafts =
should identify the two types of mechanisms and the types of interaction =
between them. They may then choose to tackle one set or the other set at =
this time, with the remainder to be tackled later. However - they should =
not draw distinctions between IntServ *versus* DiffServ, nor between =
DiffServ *versus* RSVP. This distinction is misleading and short =
sighted. Just consider that RSVP can be used for admission control to =
and configuration of DiffServ traffic handling mechanisms just as it can =
be used for admission to and control of microflow (per 5-tuple) traffic =
handling mechanisms. Consider that a single end-to-end path may offer =
aggregate traffic handling (diffserv) in certain devices and per-flow =
traffic handling (traditionally associated with intserv) in other =
devices.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">In summary, a full =
service QoS network should be able to make use of per-flow traffic =
handling, aggregate traffic handling, relatively static 'push' =
provisioning and configuration mechanisms and the more dynamic RSVP =
signaling configuration mechanism *all in the same network*. Policy =
should focus on how these interact seamlessly, thereby uniting them. As =
the drafts carve out pieces to tackle, these interactions should be =
noted and similar pieces should be tackled in the same draft. =
</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">This is a difficult =
message to convey - it's somewhat abstract. So - here's a concrete =
example of what happens when we artificially separate RSVP/IntServ from =
DiffServ:</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">***************** =
Example*******************</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Consider how =
COPS/RSVP and COPS/PR are used between PEPs and PDPs:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">COPS/RSVP:</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">* An RSVP message =
arrives at a PEP. It is a request for resources that specifies the type =
of service desired, the amount of traffic for which this service is =
required and the classification information by which the traffic can be =
recognized.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">* The PDP makes an =
admission control decision.</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">* If the request is =
admitted, then the PDP tells the PEP that the request is admitted. =
</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">* Now the PEP =
configures: 1. a microflow classifier corresponding to the 5-tuple in =
the RSVP message 2. a policer corresponding to the tspec in the RSVP =
message 3. the appropriate queuing to provide the service approved (2 =
and 3 are closely related).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">COPS/PR:</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">* A PEP needs to be =
configured to support a certain SLA for certain traffic.</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">* The PDP must check =
with the PEP to be sure that it can accommodate&nbsp; the SLA (admission =
control decision is made)</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">* If the SLA can be =
supported, the PDP configures in the PEP: 1. a classifier (potentially =
microflow) corresponding to the customer traffic stream to recieve the =
diffserv service per the SLA. 2. a policer to protect the diffserv =
network and possibly to protect one subset of the customer's traffic =
from another. 3. the appropriate queuing in the same or in subsequent =
PEPs. </FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Note that in both =
cases, there is a need to configure classifiers, policers and queuing =
mechanisms in PEPs. In the first case, the PDP does so indirectly (by =
admitting the RSVP request). In the second case, it does so directly. =
However, in both cases - the result is to consume resources from the =
same interfaces. It would have been much simpler if the work of COPS was =
separated into 1. responding to provisioning and configuration requests =
(whetehr they arrvie by RSVP or by administrative control) and 2. =
configuring traffic handling mechanisms. In that case, the COPS/RSVP =
example would have the PDP directly configuring the traffic handling =
mechanisms in response to the RSVP message, just as it does in the =
COPS/PR case. There is overlap between COPS/PR and COPS/RSVP that is =
related to an artificial distinction between RSVP/IntServ and =
DiffServ.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">*********************************************** </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C06468.A49E4626--


From majordomo@raleigh.ibm.com  Tue Dec 12 17:32:28 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26356
	for <policy-archive@odin.ietf.org>; Tue, 12 Dec 2000 17:32:26 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA16626;
	Tue, 12 Dec 2000 17:22:37 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA27114;
	Tue, 12 Dec 2000 17:22:30 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA42984; Tue, 12 Dec 2000 16:53:33 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA38358; Tue, 12 Dec 2000 16:53:29 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA43064
	for <policy@raleigh.ibm.com>; Tue, 12 Dec 2000 16:53:32 -0500
Received: from ns1.49thietf.org (ietf.207.137.80.5.tx.verio.net [207.137.80.5])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA36904
	for <policy@raleigh.ibm.com>; Tue, 12 Dec 2000 16:53:28 -0500
Received: from ccrle.nec.de (ietf.207.137.70.105.tx.verio.net [207.137.70.105])
	by ns1.49thietf.org (8.9.3+Sun/8.9.3) with ESMTP id NAA05730;
	Tue, 12 Dec 2000 13:49:42 -0800 (PST)
Message-Id: <3A354A3A.9CA4AA09@ccrle.nec.de>
Date: Mon, 11 Dec 2000 22:42:18 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Organization: NEC Europe Ltd
X-Mailer: Mozilla 4.72 [en] (Win98; I)
X-Accept-Language: en,de
Mime-Version: 1.0
To: John Strassner <johns@cisco.com>
Cc: Ron Cohen <ronc@cisco.com>, Mahadevan Iyer <iyermahadevan@yahoo.com>,
        policy@raleigh.ibm.com, ipsec-policy@vpnc.org
Subject: Re: gpsPolicyGroup class in qos info model
References: <4.3.2.7.2.20001207003148.00b3a240@csi-admin1> <20001208052955.6CB587DCF@imap.heidelberg.ccrle.nec.de> <001201c06250$b7a73bf0$19ee130a@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Marcus Brunner <brunner@ccrle.nec.de>
Content-Transfer-Encoding: 7bit

John,

John Strassner wrote:
> 
> PolicyRuleInPolicyRule is used to build sub-rules. We also
> allow for PolicyGroupInPolicyRule to build a sub-rule, with
> a policyGroup as a nested container. This capability is not
> in PCIM.
>

Do you have an example, motivating why the rule in the rule is useful?
Is there a specific application of this modeling for QPIM?
I personally do not like having a rule playing so many different role.
The containment is dealt with in the policy group, why should a policy
rule also be a container for sub-rules?
 
> As far as the context, sub-rules execute before their
> containing rules, as explained in the draft.
>

Thank you, I have not found this in the draft.
 
> I not only don't like conditions in gpsPolicyGroup, I don't
> think they work.
>

I do not like the as well.

Marcus
 
> regards,
> John
> ----- Original Message -----
> From: "Marcus Brunner" <brunner@ccrle.nec.de>
> To: "Ron Cohen" <ronc@cisco.com>
> Cc: "Mahadevan Iyer" <iyermahadevan@yahoo.com>;
> <policy@raleigh.ibm.com>; <ipsec-policy@vpnc.org>
> Sent: Thursday, December 07, 2000 9:29 PM
> Subject: Re: gpsPolicyGroup class in qos info model
> 
> > Ron,
> >
> > I agree with Mahadevan, that I do not like the
> policyRuleInPolicyRule method,
> > because
> > a) there are now two different grouping models,
> > b) it is unclear what happens to the context when the
> ruleInrule is executed
> > (full new start of execution engine or reuse the context)
> > c) I do not see the need for rulesInrules, what makes them
> different compared to
> > the grouping already available
> >
> > However, I do not agree to add a condition to the group. I
> think what is
> > available is enough.
> >
> > Marcus
> >
> > Quoting Ron Cohen <ronc@cisco.com>:
> >
> > > Mahadevan,
> > >
> > > Can you provide more details why you prefer to change
> the gpsPolicyGroup
> > > than using the current policyRuleInPolicyRule method?
> > >
> > > Thanks
> > > Ron
> > >
> > >
> > > >I would like to suggest an update to the
> > > >gpsPolicyGroup class.
> > > >This also relates to the PolicyRuleInPolicyRule usage.
> > > >
> > > >I need to indicate that a group of policy rules should
> > > >be checked only if the traffic matches some aggregate
> > > >conditions. These aggregate conditions summarize the
> > > >conditions within the policy rules.
> > > >
> > > >I would like to specify the aggregate conditions at
> > > >the level of the gpsPolicyGroup. An alternative is to
> > > >use the PolicyRule + PolicyRuleInPolicyRule instead of
> > > >the gpsPolicyGroup. However I prefer to use the
> > > >gpsPolicyGroup.
> > > >
> > > >I would suggest adding an aggregate policy condition
> > > >to the gpsPolicyGroup. This condition would typically
> > > >be a gpsPolicyCompoundCondition.
> > > >
> > > >
> > > >Thanks
> > > >
> > > >__________________________________________________
> > > >Do You Yahoo!?
> > > >Yahoo! Shopping - Thousands of Stores. Millions of
> Products.
> > > >http://shopping.yahoo.com/
> > >
> > >
> >
> >
> >
> > Dr. Marcus Brunner
> > C&C Research Laboratories
> > NEC Europe Ltd.
> >
> > E-Mail: brunner@ccrle.nec.de
> > WWW:    http://www.ccrle.nec.de/
> > personal home page: http://www.tik.ee.ethz.ch/~brunner
> >
> > Adenauerplatz 6
> > D-69115 Heidelberg
> > Germany
> >
> > Phone: +49 (0)6221/ 9051129
> > Fax:   +49 (0)6221/ 9051155


From majordomo@raleigh.ibm.com  Tue Dec 12 20:49:37 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02656
	for <policy-archive@odin.ietf.org>; Tue, 12 Dec 2000 20:49:36 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id UAA11780;
	Tue, 12 Dec 2000 20:25:00 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id UAA25608;
	Tue, 12 Dec 2000 20:24:59 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA27912; Tue, 12 Dec 2000 14:37:39 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43762; Tue, 12 Dec 2000 14:37:34 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA10248
	for <policy@raleigh.ibm.com>; Tue, 12 Dec 2000 14:37:37 -0500
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA25824
	for <policy@raleigh.ibm.com>; Tue, 12 Dec 2000 14:37:33 -0500
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 12 Dec 2000 10:22:55 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 12 Dec 2000 10:23:37 -0800 (Pacific Standard Time)
Received: from DF-MILO.platinum.corp.microsoft.com ([172.30.236.125]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532);
	 Tue, 12 Dec 2000 10:23:37 -0800
X-Mimeole: Produced By Microsoft Exchange V6.0.4604.0
Content-Class: urn:content-classes:message
Subject: Clarification of comments made during yesterday's WG meeting
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C06468.A49E4626"
Date: Tue, 12 Dec 2000 10:23:36 -0800
Message-Id: <A5769B3C2F02274B9D17F5FB4495DD5F2CC561@DF-SCOOBY.platinum.corp.microsoft.com>
Thread-Topic: comments on draft-ietf-policy-qos-device-info-model-02.txt
Thread-Index: AcBjsoK0xW8/XuVkRoqjQajZN3bHtwArykuA
From: "Yoram Bernet" <yoramb@Exchange.Microsoft.com>
To: <policy@raleigh.ibm.com>
X-Originalarrivaltime: 12 Dec 2000 18:23:37.0228 (UTC) FILETIME=[A4E5E4C0:01C06468]
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Yoram Bernet" <yoramb@Exchange.Microsoft.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C06468.A49E4626
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

At the end of yesterday's meeting, Ed paraphrased my comments. I think
that my comments were not clearly understood. I will attempt to clarify:

The fundamental issue is one of modularization. Policy is such an
overwhelming 'blob' to tackle - as a result, the authors of QDDIM and
QPIM are tackling the effort picemeal. This makes sense. I am not
calling for all pieces of the QoS policy puzzle to be tackled at once.
What i'm calling for is very careful modularization. As I commented
yesterday on the list, the modulariztion in QDDIM strikes me as wrong.
QDDIM repeatedly states that it is tacking the DiffServ module in this
pass and will tackle the IntServ model in the next pass. QPIM talks
about the RSVP part versus the DiffServ part. In QPIM, the two are
pretty much separated, except for the brief part about using RSVP to
return DCLASS objects (whihc are DiffServ related).

In my opinion, the modularization should be one of datapath mechanisms
versus control mechanisms. Datapath mechanisms include:

Classification=20
Metering
Dropping
Marking
Queuing

These are neither IntServ nor DiffServ - they are equally applicable to
both. They are more generic than IntServ or DiffServ.=20

Control mechanisms configure the datapath mechanisms. They include:

SNMP
COPS
RSVP
Others...

Datapath and control mechanisms interact. For example - when a DiffServ
network provider provisions an EF service instance between ingress point
A and egress point B, it's necessary to verify that resources are
available along the path from A to B and to install the appropriate
policers to assure that the EF service is not abused. This requires
interaction between some policy agents and the queuing and
classification mechanisms in at least some of the network elements along
the path from A to B. Part of this interaction involves admission
control (are there sufficient resources to support the SLA? can the new
service be provisioned without violating other SLAs?), part of it
amounts to configuring policers. Similarly, when an RSVP request arrives
at a PEP/PDP, it is necessary to apply admission control, and then to
configure policers and queuing in accordance with the admission control
decision.=20

So - IMHO, the drafts should identify the two types of mechanisms and
the types of interaction between them. They may then choose to tackle
one set or the other set at this time, with the remainder to be tackled
later. However - they should not draw distinctions between IntServ
*versus* DiffServ, nor between DiffServ *versus* RSVP. This distinction
is misleading and short sighted. Just consider that RSVP can be used for
admission control to and configuration of DiffServ traffic handling
mechanisms just as it can be used for admission to and control of
microflow (per 5-tuple) traffic handling mechanisms. Consider that a
single end-to-end path may offer aggregate traffic handling (diffserv)
in certain devices and per-flow traffic handling (traditionally
associated with intserv) in other devices.

In summary, a full service QoS network should be able to make use of
per-flow traffic handling, aggregate traffic handling, relatively static
'push' provisioning and configuration mechanisms and the more dynamic
RSVP signaling configuration mechanism *all in the same network*. Policy
should focus on how these interact seamlessly, thereby uniting them. As
the drafts carve out pieces to tackle, these interactions should be
noted and similar pieces should be tackled in the same draft.=20

This is a difficult message to convey - it's somewhat abstract. So -
here's a concrete example of what happens when we artificially separate
RSVP/IntServ from DiffServ:

***************** Example*******************

Consider how COPS/RSVP and COPS/PR are used between PEPs and PDPs:

COPS/RSVP:
* An RSVP message arrives at a PEP. It is a request for resources that
specifies the type of service desired, the amount of traffic for which
this service is required and the classification information by which the
traffic can be recognized.
* The PDP makes an admission control decision.
* If the request is admitted, then the PDP tells the PEP that the
request is admitted.=20
* Now the PEP configures: 1. a microflow classifier corresponding to the
5-tuple in the RSVP message 2. a policer corresponding to the tspec in
the RSVP message 3. the appropriate queuing to provide the service
approved (2 and 3 are closely related).

COPS/PR:
* A PEP needs to be configured to support a certain SLA for certain
traffic.
* The PDP must check with the PEP to be sure that it can accommodate
the SLA (admission control decision is made)
* If the SLA can be supported, the PDP configures in the PEP: 1. a
classifier (potentially microflow) corresponding to the customer traffic
stream to recieve the diffserv service per the SLA. 2. a policer to
protect the diffserv network and possibly to protect one subset of the
customer's traffic from another. 3. the appropriate queuing in the same
or in subsequent PEPs.=20

Note that in both cases, there is a need to configure classifiers,
policers and queuing mechanisms in PEPs. In the first case, the PDP does
so indirectly (by admitting the RSVP request). In the second case, it
does so directly. However, in both cases - the result is to consume
resources from the same interfaces. It would have been much simpler if
the work of COPS was separated into 1. responding to provisioning and
configuration requests (whetehr they arrvie by RSVP or by administrative
control) and 2. configuring traffic handling mechanisms. In that case,
the COPS/RSVP example would have the PDP directly configuring the
traffic handling mechanisms in response to the RSVP message, just as it
does in the COPS/PR case. There is overlap between COPS/PR and COPS/RSVP
that is related to an artificial distinction between RSVP/IntServ and
DiffServ.
***********************************************=20


------_=_NextPart_001_01C06468.A49E4626
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4604.0">
<TITLE>Clarification of comments made during yesterday's WG =
meeting</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">At the end of =
yesterday's meeting, Ed paraphrased my comments. I think that my =
comments were not clearly understood. I will attempt to =
clarify:</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The fundamental issue =
is one of modularization. Policy is such an overwhelming 'blob' to =
tackle - as a result, the authors of QDDIM and QPIM are tackling the =
effort picemeal. This makes sense. I am not calling for all pieces of =
the QoS policy puzzle to be tackled at once. What i'm calling for is =
very careful modularization. As I commented yesterday on the list, the =
modulariztion in QDDIM strikes me as wrong. QDDIM repeatedly states that =
it is tacking the DiffServ module in this pass and will tackle the =
IntServ model in the next pass. QPIM talks about the RSVP part versus =
the DiffServ part. In QPIM, the two are pretty much separated, except =
for the brief part about using RSVP to return DCLASS objects (whihc are =
DiffServ related).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">In my opinion, the =
modularization should be one of datapath mechanisms versus control =
mechanisms. Datapath mechanisms include:</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Classification =
</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Metering</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Dropping</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Marking</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Queuing</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">These are neither =
IntServ nor DiffServ - they are equally applicable to both. They are =
more generic than IntServ or DiffServ. </FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Control mechanisms =
configure the datapath mechanisms. They include:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">SNMP</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">COPS</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">RSVP</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Others...</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Datapath and control =
mechanisms interact. For example - when a DiffServ network provider =
provisions an EF service instance between ingress point A and egress =
point B, it's necessary to verify that resources are available along the =
path from A to B and to install the appropriate policers to assure that =
the EF service is not abused. This requires interaction between some =
policy agents and the queuing and classification mechanisms in at least =
some of the network elements along the path from A to B. Part of this =
interaction involves admission control (are there sufficient resources =
to support the SLA? can the new service be provisioned without violating =
other SLAs?), part of it amounts to configuring policers. Similarly, =
when an RSVP request arrives at a PEP/PDP, it is necessary to apply =
admission control, and then to configure policers and queuing in =
accordance with the admission control decision. </FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">So - IMHO, the drafts =
should identify the two types of mechanisms and the types of interaction =
between them. They may then choose to tackle one set or the other set at =
this time, with the remainder to be tackled later. However - they should =
not draw distinctions between IntServ *versus* DiffServ, nor between =
DiffServ *versus* RSVP. This distinction is misleading and short =
sighted. Just consider that RSVP can be used for admission control to =
and configuration of DiffServ traffic handling mechanisms just as it can =
be used for admission to and control of microflow (per 5-tuple) traffic =
handling mechanisms. Consider that a single end-to-end path may offer =
aggregate traffic handling (diffserv) in certain devices and per-flow =
traffic handling (traditionally associated with intserv) in other =
devices.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">In summary, a full =
service QoS network should be able to make use of per-flow traffic =
handling, aggregate traffic handling, relatively static 'push' =
provisioning and configuration mechanisms and the more dynamic RSVP =
signaling configuration mechanism *all in the same network*. Policy =
should focus on how these interact seamlessly, thereby uniting them. As =
the drafts carve out pieces to tackle, these interactions should be =
noted and similar pieces should be tackled in the same draft. =
</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">This is a difficult =
message to convey - it's somewhat abstract. So - here's a concrete =
example of what happens when we artificially separate RSVP/IntServ from =
DiffServ:</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">***************** =
Example*******************</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Consider how =
COPS/RSVP and COPS/PR are used between PEPs and PDPs:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">COPS/RSVP:</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">* An RSVP message =
arrives at a PEP. It is a request for resources that specifies the type =
of service desired, the amount of traffic for which this service is =
required and the classification information by which the traffic can be =
recognized.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">* The PDP makes an =
admission control decision.</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">* If the request is =
admitted, then the PDP tells the PEP that the request is admitted. =
</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">* Now the PEP =
configures: 1. a microflow classifier corresponding to the 5-tuple in =
the RSVP message 2. a policer corresponding to the tspec in the RSVP =
message 3. the appropriate queuing to provide the service approved (2 =
and 3 are closely related).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">COPS/PR:</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">* A PEP needs to be =
configured to support a certain SLA for certain traffic.</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">* The PDP must check =
with the PEP to be sure that it can accommodate&nbsp; the SLA (admission =
control decision is made)</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">* If the SLA can be =
supported, the PDP configures in the PEP: 1. a classifier (potentially =
microflow) corresponding to the customer traffic stream to recieve the =
diffserv service per the SLA. 2. a policer to protect the diffserv =
network and possibly to protect one subset of the customer's traffic =
from another. 3. the appropriate queuing in the same or in subsequent =
PEPs. </FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Note that in both =
cases, there is a need to configure classifiers, policers and queuing =
mechanisms in PEPs. In the first case, the PDP does so indirectly (by =
admitting the RSVP request). In the second case, it does so directly. =
However, in both cases - the result is to consume resources from the =
same interfaces. It would have been much simpler if the work of COPS was =
separated into 1. responding to provisioning and configuration requests =
(whetehr they arrvie by RSVP or by administrative control) and 2. =
configuring traffic handling mechanisms. In that case, the COPS/RSVP =
example would have the PDP directly configuring the traffic handling =
mechanisms in response to the RSVP message, just as it does in the =
COPS/PR case. There is overlap between COPS/PR and COPS/RSVP that is =
related to an artificial distinction between RSVP/IntServ and =
DiffServ.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">*********************************************** </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C06468.A49E4626--


From majordomo@raleigh.ibm.com  Tue Dec 12 21:39:23 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14278
	for <policy-archive@odin.ietf.org>; Tue, 12 Dec 2000 21:39:21 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA32420;
	Tue, 12 Dec 2000 21:25:54 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id VAA26236;
	Tue, 12 Dec 2000 21:25:53 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA44096; Tue, 12 Dec 2000 17:32:36 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43562; Tue, 12 Dec 2000 17:32:32 -0500
Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA18012
	for <policy@raleigh.ibm.com>; Tue, 12 Dec 2000 17:32:36 -0500
From: Ed_Ellesson@tivoli.com
Received: from schub.tivoli.com (schub.tivoli.com [146.84.104.17])
	by corp.tivoli.com (8.9.3/8.9.0) with ESMTP id QAA27132;
	Tue, 12 Dec 2000 16:13:21 -0600 (CST)
Importance: Normal
Subject: Re: Clarification of comments made during yesterday's WG meeting
To: "Yoram Bernet" <yoramb@Exchange.Microsoft.com>
Cc: <policy@raleigh.ibm.com>
Date: Tue, 12 Dec 2000 17:07:20 -0500
Message-Id: <OF874BC29B.5D87228A-ON852569B3.0079BD49@tivoli.com>
X-Mimetrack: Serialize by Router on SCHub/Tivoli Systems(Release 5.0.4a |July 24, 2000) at
 12/12/2000 04:11:56 PM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Ed_Ellesson@tivoli.com

Yoram,

Thanks for sending this clarification.  I think you are right in that we
collectively need to understand the linkages better, between rsvp/intserv
and diffserv, from the perspective of policy.

Thanks again,


Ed Ellesson

ellesson@tivoli.com
Office at Tivoli:  919-224-2111
Office at home:  919-644-3977



From majordomo@raleigh.ibm.com  Wed Dec 13 02:40:01 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11695
	for <policy-archive@odin.ietf.org>; Wed, 13 Dec 2000 02:39:57 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id BAA27144;
	Wed, 13 Dec 2000 01:56:20 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id BAA40894;
	Wed, 13 Dec 2000 01:53:09 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA28772; Wed, 13 Dec 2000 01:03:36 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA45660; Wed, 13 Dec 2000 01:03:32 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id BAA32966
	for <policy@raleigh.ibm.com>; Wed, 13 Dec 2000 01:03:31 -0500
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id BAA37816
	for <policy@raleigh.ibm.com>; Wed, 13 Dec 2000 01:03:28 -0500
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id WAA04610;
	Tue, 12 Dec 2000 22:02:30 -0800 (PST)
Received: from jstrassnlap (sj-dial-4-45.cisco.com [171.68.181.174])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with SMTP id AEJ13417;
	Tue, 12 Dec 2000 22:02:23 -0800 (PST)
Message-Id: <015c01c064ca$c1f47a10$aeb544ab@cisco.com>
From: "John Strassner" <jstrassn@cisco.com>
To: "Mahadevan Iyer" <iyermahadevan@yahoo.com>,
        "John Strassner" <johns@cisco.com>,
        "Marcus Brunner" <brunner@ccrle.nec.de>, "Ron Cohen" <ronc@cisco.com>
Cc: <policy@raleigh.ibm.com>, <ipsec-policy@vpnc.org>
References: <20001212053429.7077.qmail@web10507.mail.yahoo.com>
Subject: Re: gpsPolicyGroup class in qos info model
Date: Tue, 12 Dec 2000 13:43:21 -0800
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "John Strassner" <jstrassn@cisco.com>
Content-Transfer-Encoding: 7bit

I think I understand in principle what you want to do, but
just to be clear, is this a fair description:

  you want to be able to trim a tree of policy
  information from consideration to be evaluated
  efficiently; therefore, you want to add a
  condition clause, defined by the admin, on a
  high-level container, to do this

Assuming that this is correct, you still haven't addressed
how you accommodate decision strategy and nested rules. In
other words, are you proposing that you construct these new
trimming rules INDEPENDENTLY of the actual structure of the
rules below that containment point (e.g., taking into
account their individual decision strategies, priorities,
etc.)? How can you be sure that you are capturing the
semantics and maintaining the correct execution order by
your newly defined trimming rules?

regards,
John
----- Original Message -----
From: "Mahadevan Iyer" <iyermahadevan@yahoo.com>
To: "John Strassner" <johns@cisco.com>; "Marcus Brunner"
<brunner@ccrle.nec.de>; "Ron Cohen" <ronc@cisco.com>
Cc: <policy@raleigh.ibm.com>; <ipsec-policy@vpnc.org>
Sent: Monday, December 11, 2000 9:34 PM
Subject: Re: gpsPolicyGroup class in qos info model


> --- John Strassner <jstrassn@cisco.com> wrote:
> > I'm still confused. It sounds like you want to copy
> > the
>
> Not copy, let the administrator create higher level
> condition traps. They might be very coarse and loose.
> They will provide a coarse level of aggregation.
> I agree that if we try to directly copy we will run
> into the problems as you have pointed out.
>
> > conditions inside different rules that are contained
> > in
> > different groups to a higher level of containment in
> > order
> > to trim the tree, right? This is what I meant when I
> > said:
>
> Exactly right: "Trim the tree" for the decision
> process.
>
> >
> >   "As you say, a policyRule is an atomic object.
> > You're
> >    asking to "peek inside" a group of policyRules in
> > a
> >    policyGroup and copy their aggregate conditions
> > out
> >    into a higher-level condition that you can then
> >    trap on."
>
> Not copy as stated earlier.
>
> >
> > Now, while this may work for PCIM, for QPIM I don't
> > think it
> > can work, because at the very minimum, this means
> > that you
> > also have to copy the decision strategies that are
> > applied
> > to each group of conditions. QPIM provides the
> > ability to
> > CHANGE decision strategies at each containment
> > level. This
> > means that you now have to re-create the decision
> > strategies
> > defined at each container and apply them to the
> > conditions
> > at each level of containment. You haven't addressed
> > how this
> > will be done.
>
> I agree that it will not be feasable to do this
> automatically and will not be feasable to do it at
> every level.
> It is upto the administrator to decide whether he
> wants to include an aggregated condition at a certain
> point or not. It is upto the administrator to manually
> build the condition.
>
> >
> > In addition, in QPIM, we have nested rules as well
> > as
> > sub-rules. You can't flatten out the condition in
> > these
> > cases, or you lose the hierarchy of the structure of
> > the
> > rules. You also haven't addressed how this will be
> > done.
> >
> > That's why I continue to have questions.
>
> I hope I have communicated the problem clearly.
> At this point I can't think of an alternative solution
> to the problem.
>
> As far as the QPIM if I were to take the example
> quoted on page 24 (version 02).
>
> I am assuming that PDP's within a region would try to
> trim the policy tree by picking up policies meant for
> their respective regions.(I have posted some related
> questions "Policy Target, Policy Domains etc" on the
> mailing list)
>
> If most of the policies have to  do with inter-region
> traffic or inter-group traffic to a hub there isn't
> much trimming I can do on the basis of "policies
> required by a region".
>
> In such cases source and destination of the traffic
> can be used to zero in into a policy group which then
> defines exactly what policies need to be applied to
> the  traffic.
>
> Thanks
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of
Products.
> http://shopping.yahoo.com/



From majordomo@raleigh.ibm.com  Wed Dec 13 03:35:50 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23785
	for <policy-archive@odin.ietf.org>; Wed, 13 Dec 2000 03:35:49 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA27414;
	Wed, 13 Dec 2000 03:05:43 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id DAA36324;
	Wed, 13 Dec 2000 03:05:36 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA33078; Wed, 13 Dec 2000 01:39:36 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA44832; Wed, 13 Dec 2000 01:39:29 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id BAA26928
	for <policy@raleigh.ibm.com>; Wed, 13 Dec 2000 01:39:25 -0500
Received: from web10503.mail.yahoo.com (web10503.mail.yahoo.com [216.136.130.153])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id BAA36160
	for <policy@raleigh.ibm.com>; Wed, 13 Dec 2000 01:39:22 -0500
Message-Id: <20001213063833.30930.qmail@web10503.mail.yahoo.com>
Received: from [198.206.187.100] by web10503.mail.yahoo.com; Tue, 12 Dec 2000 22:38:33 PST
Date: Tue, 12 Dec 2000 22:38:33 -0800 (PST)
From: Mahadevan Iyer <iyermahadevan@yahoo.com>
Subject: Re: gpsPolicyGroup class in qos info model
To: John Strassner <johns@cisco.com>, Marcus Brunner <brunner@ccrle.nec.de>,
        Ron Cohen <ronc@cisco.com>
Cc: policy@raleigh.ibm.com, ipsec-policy@vpnc.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Mahadevan Iyer <iyermahadevan@yahoo.com>

--- John Strassner <jstrassn@cisco.com> wrote:
> I think I understand in principle what you want to
> do, but
> just to be clear, is this a fair description:
> 
>   you want to be able to trim a tree of policy
>   information from consideration to be evaluated
>   efficiently; therefore, you want to add a
>   condition clause, defined by the admin, on a
>   high-level container, to do this
> 

This is correct.

> Assuming that this is correct, you still haven't
> addressed
> how you accommodate decision strategy and nested
> rules. In
> other words, are you proposing that you construct
> these new
> trimming rules INDEPENDENTLY of the actual structure
> of the
> rules below that containment point (e.g., taking
> into
> account their individual decision strategies,
> priorities,
> etc.)? How can you be sure that you are capturing
> the
> semantics and maintaining the correct execution
> order by
> your newly defined trimming rules?

This is the responsibility of the policy
administrator.
The exact same responsibility exists when creating
PolicyRuleInPolicyRule trees.
Isn't this true ?

Regards



__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/


From majordomo@raleigh.ibm.com  Wed Dec 13 23:12:50 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22286
	for <policy-archive@odin.ietf.org>; Wed, 13 Dec 2000 23:12:50 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id XAA27354;
	Wed, 13 Dec 2000 23:03:41 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id XAA30704;
	Wed, 13 Dec 2000 23:03:30 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA52910; Wed, 13 Dec 2000 14:15:41 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA45222; Wed, 13 Dec 2000 14:15:37 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA45734
	for <policy@raleigh.ibm.com>; Wed, 13 Dec 2000 14:15:24 -0500
Received: from longsys.com (dmz.longsys.com [63.111.150.5])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA34662
	for <policy@raleigh.ibm.com>; Wed, 13 Dec 2000 14:14:46 -0500
Received: from longsys.com (discordian.longsys.com [63.111.150.74])
	by longsys.com (8.10.0/8.10.0) with ESMTP id eBDJEgw11687
	for <policy@raleigh.ibm.com>; Wed, 13 Dec 2000 19:14:42 GMT
Message-Id: <3A37CB9E.D4DED5CD@longsys.com>
Date: Wed, 13 Dec 2000 11:18:54 -0800
From: Rob Frye <rfrye@longsys.com>
Organization: Longitude Systems, Inc.
X-Mailer: Mozilla 4.72 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: en
Mime-Version: 1.0
To: policy@raleigh.ibm.com
Subject: Policy term: MPLS (draft-ietf-policy-terminology-01.txt)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Rob Frye <rfrye@longsys.com>
Content-Transfer-Encoding: 7bit

MPLS is also Multi-Protocol LAMBDA switching, for use in optical
networks.  I suggest adding a statement to that regard under the heading
of "Multiprotocol Label Switching (MPLS)".

--
// Rob.

Rob Frye
Director, Software Development
Longitude Systems, Inc.
15000 Conference Center Drive
Chantilly, VA  20151
www.longsys.com
voice:  +1-703-818-5426
fax:    +1-703-961-8751
mobile: +1-703-725-1130
email:  rfrye@longsys.com


From majordomo@raleigh.ibm.com  Thu Dec 14 03:15:40 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23226
	for <policy-archive@odin.ietf.org>; Thu, 14 Dec 2000 03:15:40 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA23466;
	Thu, 14 Dec 2000 03:02:48 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id DAA40684;
	Thu, 14 Dec 2000 03:02:46 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA53682; Thu, 14 Dec 2000 01:38:42 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA53134; Thu, 14 Dec 2000 01:38:17 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id BAA46314
	for <policy@raleigh.ibm.com>; Thu, 14 Dec 2000 01:36:52 -0500
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id BAA22876
	for <policy@raleigh.ibm.com>; Thu, 14 Dec 2000 01:36:48 -0500
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id WAA26696;
	Wed, 13 Dec 2000 22:35:56 -0800 (PST)
Received: from jstrassnlap (sj-dial-4-23.cisco.com [171.68.181.152])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with SMTP id AEL03082;
	Wed, 13 Dec 2000 22:35:44 -0800 (PST)
Message-Id: <026001c06598$96111470$98b544ab@cisco.com>
From: "John Strassner" <jstrassn@cisco.com>
To: "Mahadevan Iyer" <iyermahadevan@yahoo.com>,
        "John Strassner" <johns@cisco.com>,
        "Marcus Brunner" <brunner@ccrle.nec.de>, "Ron Cohen" <ronc@cisco.com>
Cc: <policy@raleigh.ibm.com>, <ipsec-policy@vpnc.org>
References: <20001213063833.30930.qmail@web10503.mail.yahoo.com>
Subject: Re: gpsPolicyGroup class in qos info model
Date: Wed, 13 Dec 2000 11:34:51 -0800
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "John Strassner" <jstrassn@cisco.com>
Content-Transfer-Encoding: 7bit

No. The point of QPIM is to use gpsPolicyGroup and
qosPolicyGroup to develop specific containers that are used
to hold decision strategies, etc. that apply to objects in
their scope. Telling the administrator to try and build a
condition that captures the complex evaluation strategies
that are contained in containers below it and hoping that a
single condition can capture these complexities is, imho,
not achievable.

regards,
John
----- Original Message -----
From: "Mahadevan Iyer" <iyermahadevan@yahoo.com>
To: "John Strassner" <johns@cisco.com>; "Marcus Brunner"
<brunner@ccrle.nec.de>; "Ron Cohen" <ronc@cisco.com>
Cc: <policy@raleigh.ibm.com>; <ipsec-policy@vpnc.org>
Sent: Tuesday, December 12, 2000 10:38 PM
Subject: Re: gpsPolicyGroup class in qos info model


> --- John Strassner <jstrassn@cisco.com> wrote:
> > I think I understand in principle what you want to
> > do, but
> > just to be clear, is this a fair description:
> >
> >   you want to be able to trim a tree of policy
> >   information from consideration to be evaluated
> >   efficiently; therefore, you want to add a
> >   condition clause, defined by the admin, on a
> >   high-level container, to do this
> >
>
> This is correct.
>
> > Assuming that this is correct, you still haven't
> > addressed
> > how you accommodate decision strategy and nested
> > rules. In
> > other words, are you proposing that you construct
> > these new
> > trimming rules INDEPENDENTLY of the actual structure
> > of the
> > rules below that containment point (e.g., taking
> > into
> > account their individual decision strategies,
> > priorities,
> > etc.)? How can you be sure that you are capturing
> > the
> > semantics and maintaining the correct execution
> > order by
> > your newly defined trimming rules?
>
> This is the responsibility of the policy
> administrator.
> The exact same responsibility exists when creating
> PolicyRuleInPolicyRule trees.
> Isn't this true ?
>
> Regards
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of
Products.
> http://shopping.yahoo.com/



From majordomo@raleigh.ibm.com  Thu Dec 14 14:47:30 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27713
	for <policy-archive@odin.ietf.org>; Thu, 14 Dec 2000 14:47:28 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA15726;
	Thu, 14 Dec 2000 14:38:08 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA26202;
	Thu, 14 Dec 2000 14:37:59 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA41610; Thu, 14 Dec 2000 10:59:10 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA70786; Thu, 14 Dec 2000 10:59:06 -0500
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA47032
	for <policy@raleigh.ibm.com>; Thu, 14 Dec 2000 10:59:10 -0500
Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37])
	by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id KAA43948;
	Thu, 14 Dec 2000 10:58:58 -0500
Importance: Normal
Subject: Re: Clarification of comments made during yesterday's WG meeting
To: "Yoram Bernet" <yoramb@Exchange.Microsoft.com>
Cc: <policy@raleigh.ibm.com>
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-Id: <OF2098979C.89E11758-ON852569B5.0057175F@raleigh.ibm.com>
From: "Robert Moore" <remoore@us.ibm.com>
Date: Thu, 14 Dec 2000 10:59:04 -0500
X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at
 12/14/2000 10:59:03 AM
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Robert Moore" <remoore@us.ibm.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA27713

Yoram,

Speaking just for myself, i.e., not for the other
QDDIM authors, I think you have described more
accurately than we did the reduction of scope we
intended when we moved from QDIM to QDDIM.
I know, for example, that we said things like
"Let's just focus on the data path elements, and
finish them."

Obviously there's more to it than this, but I think
that we should move immediately to a more accurate
full title for QDDIM, QoS Device Datapath Information
Model, when we produce the -03 draft.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
remoore@us.ibm.com



"Yoram Bernet" <yoramb@Exchange.Microsoft.com>@raleigh.ibm.com on
12/12/2000 01:23:36 PM

Please respond to "Yoram Bernet" <yoramb@Exchange.Microsoft.com>

Sent by:  policy-owner@raleigh.ibm.com


To:   <policy@raleigh.ibm.com>
cc:
Subject:  Clarification of comments made during yesterday's WG meeting





At the end of yesterday's meeting, Ed paraphrased my comments. I think that
my comments were not clearly understood. I will attempt to clarify:

The fundamental issue is one of modularization. Policy is such an
overwhelming 'blob' to tackle - as a result, the authors of QDDIM and QPIM
are tackling the effort picemeal. This makes sense. I am not calling for
all pieces of the QoS policy puzzle to be tackled at once. What i'm calling
for is very careful modularization. As I commented yesterday on the list,
the modulariztion in QDDIM strikes me as wrong. QDDIM repeatedly states
that it is tacking the DiffServ module in this pass and will tackle the
IntServ model in the next pass. QPIM talks about the RSVP part versus the
DiffServ part. In QPIM, the two are pretty much separated, except for the
brief part about using RSVP to return DCLASS objects (whihc are DiffServ
related).

In my opinion, the modularization should be one of datapath mechanisms
versus control mechanisms. Datapath mechanisms include:

Classification
Metering
Dropping
Marking
Queuing

These are neither IntServ nor DiffServ - they are equally applicable to
both. They are more generic than IntServ or DiffServ.

Control mechanisms configure the datapath mechanisms. They include:

SNMP
COPS
RSVP
Others...

Datapath and control mechanisms interact. For example - when a DiffServ
network provider provisions an EF service instance between ingress point A
and egress point B, it's necessary to verify that resources are available
along the path from A to B and to install the appropriate policers to
assure that the EF service is not abused. This requires interaction between
some policy agents and the queuing and classification mechanisms in at
least some of the network elements along the path from A to B. Part of this
interaction involves admission control (are there sufficient resources to
support the SLA? can the new service be provisioned without violating other
SLAs?), part of it amounts to configuring policers. Similarly, when an RSVP
request arrives at a PEP/PDP, it is necessary to apply admission control,
and then to configure policers and queuing in accordance with the admission
control decision.

So - IMHO, the drafts should identify the two types of mechanisms and the
types of interaction between them. They may then choose to tackle one set
or the other set at this time, with the remainder to be tackled later.
However - they should not draw distinctions between IntServ *versus*
DiffServ, nor between DiffServ *versus* RSVP. This distinction is
misleading and short sighted. Just consider that RSVP can be used for
admission control to and configuration of DiffServ traffic handling
mechanisms just as it can be used for admission to and control of microflow
(per 5-tuple) traffic handling mechanisms. Consider that a single
end-to-end path may offer aggregate traffic handling (diffserv) in certain
devices and per-flow traffic handling (traditionally associated with
intserv) in other devices.

In summary, a full service QoS network should be able to make use of
per-flow traffic handling, aggregate traffic handling, relatively static
'push' provisioning and configuration mechanisms and the more dynamic RSVP
signaling configuration mechanism *all in the same network*. Policy should
focus on how these interact seamlessly, thereby uniting them. As the drafts
carve out pieces to tackle, these interactions should be noted and similar
pieces should be tackled in the same draft.

This is a difficult message to convey - it's somewhat abstract. So - here's
a concrete example of what happens when we artificially separate
RSVP/IntServ from DiffServ:

***************** Example*******************

Consider how COPS/RSVP and COPS/PR are used between PEPs and PDPs:

COPS/RSVP:
* An RSVP message arrives at a PEP. It is a request for resources that
specifies the type of service desired, the amount of traffic for which this
service is required and the classification information by which the traffic
can be recognized.

* The PDP makes an admission control decision.
* If the request is admitted, then the PDP tells the PEP that the request
is admitted.
* Now the PEP configures: 1. a microflow classifier corresponding to the
5-tuple in the RSVP message 2. a policer corresponding to the tspec in the
RSVP message 3. the appropriate queuing to provide the service approved (2
and 3 are closely related).

COPS/PR:
* A PEP needs to be configured to support a certain SLA for certain
traffic.
* The PDP must check with the PEP to be sure that it can accommodate  the
SLA (admission control decision is made)
* If the SLA can be supported, the PDP configures in the PEP: 1. a
classifier (potentially microflow) corresponding to the customer traffic
stream to recieve the diffserv service per the SLA. 2. a policer to protect
the diffserv network and possibly to protect one subset of the customer's
traffic from another. 3. the appropriate queuing in the same or in
subsequent PEPs.

Note that in both cases, there is a need to configure classifiers, policers
and queuing mechanisms in PEPs. In the first case, the PDP does so
indirectly (by admitting the RSVP request). In the second case, it does so
directly. However, in both cases - the result is to consume resources from
the same interfaces. It would have been much simpler if the work of COPS
was separated into 1. responding to provisioning and configuration requests
(whetehr they arrvie by RSVP or by administrative control) and 2.
configuring traffic handling mechanisms. In that case, the COPS/RSVP
example would have the PDP directly configuring the traffic handling
mechanisms in response to the RSVP message, just as it does in the COPS/PR
case. There is overlap between COPS/PR and COPS/RSVP that is related to an
artificial distinction between RSVP/IntServ and DiffServ.

***********************************************





From majordomo@raleigh.ibm.com  Thu Dec 14 14:50:38 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28570
	for <policy-archive@odin.ietf.org>; Thu, 14 Dec 2000 14:50:38 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA37228;
	Thu, 14 Dec 2000 14:38:08 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA39948;
	Thu, 14 Dec 2000 14:37:58 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA11824; Thu, 14 Dec 2000 11:26:30 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA65546; Thu, 14 Dec 2000 11:26:20 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA23386
	for <policy@raleigh.ibm.com>; Thu, 14 Dec 2000 11:26:19 -0500
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA29278
	for <policy@raleigh.ibm.com>; Thu, 14 Dec 2000 11:26:16 -0500
Received: from bbn.com (TC091.BBN.COM [128.33.238.91])
	by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA19026;
	Thu, 14 Dec 2000 11:26:01 -0500 (EST)
Message-Id: <3A382269.A05B6B77@bbn.com>
Date: Wed, 13 Dec 2000 20:29:13 -0500
From: "Luis A. Sanchez" <lsanchez@bbn.com>
Organization: BBN Technologies
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
Mime-Version: 1.0
To: brunner@ccrle.nec.de
Cc: John Strassner <johns@cisco.com>, Ron Cohen <ronc@cisco.com>,
        Mahadevan Iyer <iyermahadevan@yahoo.com>, policy@raleigh.ibm.com,
        ipsec-policy@vpnc.org
Subject: Re: gpsPolicyGroup class in qos info model
References: <4.3.2.7.2.20001207003148.00b3a240@csi-admin1> <20001208052955.6CB587DCF@imap.heidelberg.ccrle.nec.de> <001201c06250$b7a73bf0$19ee130a@cisco.com> <3A354A3A.9CA4AA09@ccrle.nec.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Luis A. Sanchez" <lsanchez@bbn.com>
Content-Transfer-Encoding: 7bit

Folks, lets keep this discussion to the Policy Framework mailing list
only.

Luis

Marcus Brunner wrote:

> John,
>
> John Strassner wrote:
> >
> > PolicyRuleInPolicyRule is used to build sub-rules. We also
> > allow for PolicyGroupInPolicyRule to build a sub-rule, with
> > a policyGroup as a nested container. This capability is not
> > in PCIM.
> >
>
> Do you have an example, motivating why the rule in the rule is useful?
> Is there a specific application of this modeling for QPIM?
> I personally do not like having a rule playing so many different role.
> The containment is dealt with in the policy group, why should a policy
> rule also be a container for sub-rules?
>
> > As far as the context, sub-rules execute before their
> > containing rules, as explained in the draft.
> >
>
> Thank you, I have not found this in the draft.
>
> > I not only don't like conditions in gpsPolicyGroup, I don't
> > think they work.
> >
>
> I do not like the as well.
>
> Marcus
>
> > regards,
> > John
> > ----- Original Message -----
> > From: "Marcus Brunner" <brunner@ccrle.nec.de>
> > To: "Ron Cohen" <ronc@cisco.com>
> > Cc: "Mahadevan Iyer" <iyermahadevan@yahoo.com>;
> > <policy@raleigh.ibm.com>; <ipsec-policy@vpnc.org>
> > Sent: Thursday, December 07, 2000 9:29 PM
> > Subject: Re: gpsPolicyGroup class in qos info model
> >
> > > Ron,
> > >
> > > I agree with Mahadevan, that I do not like the
> > policyRuleInPolicyRule method,
> > > because
> > > a) there are now two different grouping models,
> > > b) it is unclear what happens to the context when the
> > ruleInrule is executed
> > > (full new start of execution engine or reuse the context)
> > > c) I do not see the need for rulesInrules, what makes them
> > different compared to
> > > the grouping already available
> > >
> > > However, I do not agree to add a condition to the group. I
> > think what is
> > > available is enough.
> > >
> > > Marcus
> > >
> > > Quoting Ron Cohen <ronc@cisco.com>:
> > >
> > > > Mahadevan,
> > > >
> > > > Can you provide more details why you prefer to change
> > the gpsPolicyGroup
> > > > than using the current policyRuleInPolicyRule method?
> > > >
> > > > Thanks
> > > > Ron
> > > >
> > > >
> > > > >I would like to suggest an update to the
> > > > >gpsPolicyGroup class.
> > > > >This also relates to the PolicyRuleInPolicyRule usage.
> > > > >
> > > > >I need to indicate that a group of policy rules should
> > > > >be checked only if the traffic matches some aggregate
> > > > >conditions. These aggregate conditions summarize the
> > > > >conditions within the policy rules.
> > > > >
> > > > >I would like to specify the aggregate conditions at
> > > > >the level of the gpsPolicyGroup. An alternative is to
> > > > >use the PolicyRule + PolicyRuleInPolicyRule instead of
> > > > >the gpsPolicyGroup. However I prefer to use the
> > > > >gpsPolicyGroup.
> > > > >
> > > > >I would suggest adding an aggregate policy condition
> > > > >to the gpsPolicyGroup. This condition would typically
> > > > >be a gpsPolicyCompoundCondition.
> > > > >
> > > > >
> > > > >Thanks
> > > > >
> > > > >__________________________________________________
> > > > >Do You Yahoo!?
> > > > >Yahoo! Shopping - Thousands of Stores. Millions of
> > Products.
> > > > >http://shopping.yahoo.com/
> > > >
> > > >
> > >
> > >
> > >
> > > Dr. Marcus Brunner
> > > C&C Research Laboratories
> > > NEC Europe Ltd.
> > >
> > > E-Mail: brunner@ccrle.nec.de
> > > WWW:    http://www.ccrle.nec.de/
> > > personal home page: http://www.tik.ee.ethz.ch/~brunner
> > >
> > > Adenauerplatz 6
> > > D-69115 Heidelberg
> > > Germany
> > >
> > > Phone: +49 (0)6221/ 9051129
> > > Fax:   +49 (0)6221/ 9051155





From majordomo@raleigh.ibm.com  Thu Dec 14 23:58:06 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27926
	for <policy-archive@odin.ietf.org>; Thu, 14 Dec 2000 23:58:06 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id XAA28650;
	Thu, 14 Dec 2000 23:48:20 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id XAA24628;
	Thu, 14 Dec 2000 23:48:15 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA55230; Thu, 14 Dec 2000 23:27:30 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA37814; Thu, 14 Dec 2000 23:27:27 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id XAA34222
	for <policy@raleigh.ibm.com>; Thu, 14 Dec 2000 23:27:30 -0500
Received: from web10506.mail.yahoo.com (web10506.mail.yahoo.com [216.136.130.156])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id XAA40042
	for <policy@raleigh.ibm.com>; Thu, 14 Dec 2000 23:27:26 -0500
Message-Id: <20001215042726.4312.qmail@web10506.mail.yahoo.com>
Received: from [198.206.187.100] by web10506.mail.yahoo.com; Thu, 14 Dec 2000 20:27:26 PST
Date: Thu, 14 Dec 2000 20:27:26 -0800 (PST)
From: Mahadevan Iyer <iyermahadevan@yahoo.com>
Subject: Re: gpsPolicyGroup class in qos info model
To: "Luis A. Sanchez" <lsanchez@bbn.com>
Cc: policy@raleigh.ibm.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Mahadevan Iyer <iyermahadevan@yahoo.com>

--- "Luis A. Sanchez" <lsanchez@bbn.com> wrote:
> Folks, lets keep this discussion to the Policy
> Framework mailing list
> only.

Interestingly enough this discussion is relevant to
them in the context of supporting nested VPN's in
their policy information model. However we can leave
them out of this for now.

Regards

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/


From majordomo@raleigh.ibm.com  Fri Dec 15 00:00:04 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28540
	for <policy-archive@odin.ietf.org>; Fri, 15 Dec 2000 00:00:03 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id XAB30948;
	Thu, 14 Dec 2000 23:48:20 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id XAA42032;
	Thu, 14 Dec 2000 23:48:14 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA52816; Thu, 14 Dec 2000 23:23:32 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA24890; Thu, 14 Dec 2000 23:23:27 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id XAA44328
	for <policy@raleigh.ibm.com>; Thu, 14 Dec 2000 23:23:28 -0500
Received: from web10503.mail.yahoo.com (web10503.mail.yahoo.com [216.136.130.153])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id XAA07110
	for <policy@raleigh.ibm.com>; Thu, 14 Dec 2000 23:23:26 -0500
Message-Id: <20001215042326.10441.qmail@web10503.mail.yahoo.com>
Received: from [198.206.187.100] by web10503.mail.yahoo.com; Thu, 14 Dec 2000 20:23:26 PST
Date: Thu, 14 Dec 2000 20:23:26 -0800 (PST)
From: Mahadevan Iyer <iyermahadevan@yahoo.com>
Subject: Re: gpsPolicyGroup class in qos info model
To: John Strassner <jstrassn@cisco.com>
Cc: policy@raleigh.ibm.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Mahadevan Iyer <iyermahadevan@yahoo.com>

To repeat my last question ...

Don't the PolicyRuleInPolicyRule and the
PolicyConditionInPolicyGroup have the exact same
complexity in terms of capturing the summary of the
conditions of the contained rules ?

Thanks

> > This is the responsibility(capturing the  of the
policy
> > administrator.
> > The exact same responsibility exists when creating
> > PolicyRuleInPolicyRule trees.
> > Isn't this true ?


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/


From majordomo@raleigh.ibm.com  Fri Dec 15 03:15:49 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25679
	for <policy-archive@odin.ietf.org>; Fri, 15 Dec 2000 03:15:48 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA22298;
	Fri, 15 Dec 2000 03:02:15 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id DAA31484;
	Fri, 15 Dec 2000 03:01:34 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA70498; Fri, 15 Dec 2000 01:12:34 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA61530; Fri, 15 Dec 2000 01:12:31 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id BAA34808
	for <policy@raleigh.ibm.com>; Fri, 15 Dec 2000 01:12:34 -0500
Received: from cisco.com (sigma.cisco.com [171.69.63.142])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id BAA34948
	for <policy@raleigh.ibm.com>; Fri, 15 Dec 2000 01:12:30 -0500
Received: from andreawlap (sj-dial-3-165.cisco.com [171.68.180.166])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id WAA01649;
	Thu, 14 Dec 2000 22:11:17 -0800 (PST)
From: "Andrea Westerinen" <andreaw@cisco.com>
To: "Rob Frye" <rfrye@longsys.com>, <policy@raleigh.ibm.com>
Subject: RE: Policy term: MPLS (draft-ietf-policy-terminology-01.txt)
Date: Thu, 14 Dec 2000 22:12:28 -0800
Message-Id: <GGEOLLMKEOKMFKADFNHOCEIIDAAA.andreaw@cisco.com>
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)
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <3A37CB9E.D4DED5CD@longsys.com>
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Andrea Westerinen" <andreaw@cisco.com>
Content-Transfer-Encoding: 7bit

Ok - will do.
Thanks.
Andrea

-----Original Message-----
From: policy-owner@raleigh.ibm.com
[mailto:policy-owner@raleigh.ibm.com]On Behalf Of Rob Frye
Sent: Wednesday, December 13, 2000 11:19 AM
To: policy@raleigh.ibm.com
Subject: Policy term: MPLS (draft-ietf-policy-terminology-01.txt)


MPLS is also Multi-Protocol LAMBDA switching, for use in optical
networks.  I suggest adding a statement to that regard under the heading
of "Multiprotocol Label Switching (MPLS)".

--
// Rob.

Rob Frye
Director, Software Development
Longitude Systems, Inc.
15000 Conference Center Drive
Chantilly, VA  20151
www.longsys.com
voice:  +1-703-818-5426
fax:    +1-703-961-8751
mobile: +1-703-725-1130
email:  rfrye@longsys.com



From majordomo@raleigh.ibm.com  Fri Dec 15 03:33:27 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01234
	for <policy-archive@odin.ietf.org>; Fri, 15 Dec 2000 03:33:26 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA21388;
	Fri, 15 Dec 2000 03:19:16 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id DAA43580;
	Fri, 15 Dec 2000 03:19:15 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA35702; Fri, 15 Dec 2000 02:09:43 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA61530; Fri, 15 Dec 2000 01:12:31 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id BAA34808
	for <policy@raleigh.ibm.com>; Fri, 15 Dec 2000 01:12:34 -0500
Received: from cisco.com (sigma.cisco.com [171.69.63.142])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id BAA34948
	for <policy@raleigh.ibm.com>; Fri, 15 Dec 2000 01:12:30 -0500
Received: from andreawlap (sj-dial-3-165.cisco.com [171.68.180.166])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id WAA01649;
	Thu, 14 Dec 2000 22:11:17 -0800 (PST)
From: "Andrea Westerinen" <andreaw@cisco.com>
To: "Rob Frye" <rfrye@longsys.com>, <policy@raleigh.ibm.com>
Subject: RE: Policy term: MPLS (draft-ietf-policy-terminology-01.txt)
Date: Thu, 14 Dec 2000 22:12:28 -0800
Message-Id: <GGEOLLMKEOKMFKADFNHOCEIIDAAA.andreaw@cisco.com>
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)
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700
In-Reply-To: <3A37CB9E.D4DED5CD@longsys.com>
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Andrea Westerinen" <andreaw@cisco.com>
Content-Transfer-Encoding: 7bit

Ok - will do.
Thanks.
Andrea

-----Original Message-----
From: policy-owner@raleigh.ibm.com
[mailto:policy-owner@raleigh.ibm.com]On Behalf Of Rob Frye
Sent: Wednesday, December 13, 2000 11:19 AM
To: policy@raleigh.ibm.com
Subject: Policy term: MPLS (draft-ietf-policy-terminology-01.txt)


MPLS is also Multi-Protocol LAMBDA switching, for use in optical
networks.  I suggest adding a statement to that regard under the heading
of "Multiprotocol Label Switching (MPLS)".

--
// Rob.

Rob Frye
Director, Software Development
Longitude Systems, Inc.
15000 Conference Center Drive
Chantilly, VA  20151
www.longsys.com
voice:  +1-703-818-5426
fax:    +1-703-961-8751
mobile: +1-703-725-1130
email:  rfrye@longsys.com



From majordomo@raleigh.ibm.com  Fri Dec 15 20:04:34 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26217
	for <policy-archive@odin.ietf.org>; Fri, 15 Dec 2000 20:04:33 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA31542;
	Fri, 15 Dec 2000 19:51:34 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id TAA39370;
	Fri, 15 Dec 2000 19:51:30 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA50244; Fri, 15 Dec 2000 19:21:41 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA25404; Fri, 15 Dec 2000 19:21:37 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id TAA45818
	for <policy@raleigh.ibm.com>; Fri, 15 Dec 2000 19:21:38 -0500
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA35354
	for <policy@raleigh.ibm.com>; Fri, 15 Dec 2000 18:20:54 -0500
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id PAA00393;
	Fri, 15 Dec 2000 15:20:25 -0800 (PST)
Received: from jstrassnlap ([171.69.108.130])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with SMTP id AEN29782;
	Fri, 15 Dec 2000 15:20:17 -0800 (PST)
Message-Id: <010101c066ee$18542070$826c45ab@cisco.com>
From: "John Strassner" <jstrassn@cisco.com>
To: "Mahadevan Iyer" <iyermahadevan@yahoo.com>
Cc: <policy@raleigh.ibm.com>
References: <20001215042326.10441.qmail@web10503.mail.yahoo.com>
Subject: Re: gpsPolicyGroup class in qos info model
Date: Fri, 15 Dec 2000 15:23:48 -0800
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "John Strassner" <jstrassn@cisco.com>
Content-Transfer-Encoding: 7bit

Certainly not.

The former is rule-specific. For the latter to mean
anything, it needs to reflect when all of the rules in the
gpsPolicyGroup container would fire. That's rather hard.
Especially since a gpsPolicyGroup could contain other
containers that each have their own different decision
strategies.

John
----- Original Message -----
From: "Mahadevan Iyer" <iyermahadevan@yahoo.com>
To: "John Strassner" <jstrassn@cisco.com>
Cc: <policy@raleigh.ibm.com>
Sent: Thursday, December 14, 2000 8:23 PM
Subject: Re: gpsPolicyGroup class in qos info model


> To repeat my last question ...
>
> Don't the PolicyRuleInPolicyRule and the
> PolicyConditionInPolicyGroup have the exact same
> complexity in terms of capturing the summary of the
> conditions of the contained rules ?
>
> Thanks
>
> > > This is the responsibility(capturing the  of the
> policy
> > > administrator.
> > > The exact same responsibility exists when creating
> > > PolicyRuleInPolicyRule trees.
> > > Isn't this true ?
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of
Products.
> http://shopping.yahoo.com/



From majordomo@raleigh.ibm.com  Sat Dec 16 07:01:06 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18429
	for <policy-archive@odin.ietf.org>; Sat, 16 Dec 2000 07:01:01 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA36112;
	Sat, 16 Dec 2000 06:41:32 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id GAA09952;
	Sat, 16 Dec 2000 06:41:28 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA50914; Sat, 16 Dec 2000 06:12:44 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA27836; Sat, 16 Dec 2000 06:12:40 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id GAA09566;
	Sat, 16 Dec 2000 06:10:10 -0500
From: g.perez@india.com
Received: from ionet.net.tw ([203.69.202.65])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id GAA38932;
	Sat, 16 Dec 2000 06:10:02 -0500
Received: from amele.com by ionet.net.tw (SMI-8.6/SMI-SVR4)
	id TAA17477; Sat, 16 Dec 2000 19:28:57 +0800
Subject: GIVE YOUR CHILD A STAR
Date: Sat, 16 Dec 2000 04:04:13
Message-Id: <659.387702.625309@india.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Apparently-To: <policy@raleigh.ibm.com>
Apparently-To: <srinivas@raleigh.ibm.com>
Apparently-To: <pogue@raleigh.ibm.com>
Apparently-To: <pacew@raleigh.ibm.com>
Apparently-To: <canns@raleigh.ibm.com>
Apparently-To: <rdycus@raleigh.ibm.com>
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: g.perez@india.com


<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
</HEAD>
<BODY bgColor=#ffffff leftMargin=0 topMargin=0>
<DIV align=center>
<CENTER>
    <table width="650" border="0" cellspacing="0" cellpadding="0">
      <tr bgcolor="#000066"> 
        <td> 
          <div align="center"><a href="http://www.starbabies.net"><img src="http://1078386566/stars/index_files/banner.gif" width="600" height="20" border="0"></a></div>
        </td>
      </tr>
    </table>
    <TABLE cellSpacing=0 cellPadding=0 width="650" border=0>
      <TBODY> 
      <TR>
    <TD vAlign=center align=middle width="100%" 
background=http://1078386566/stars/index_files/tile1.gif>
          <P align=center><a href="http://www.starbabies.net"><IMG height=124 src="http://1078386566/stars/index_files/search2.gif" width=428 
      border=0 alt="Click Here to Visit Our Site"></a></P>
        </TD></TR></TBODY></TABLE></CENTER></DIV>
<DIV align=center>
  <TABLE borderColor=#ffffff cellSpacing=0 cellPadding=2 width="650" 
bgColor=#ffffff border=0>
    <TBODY> 
    <TR bgcolor="#000080"> 
      <TD align=middle>&nbsp;</TD>
    </TR>
    <TR> 
      <TD align=middle> 
        <div align="center"><a href="http://www.starbabies.net"><img src="http://1078386566/stars/index_files/set.gif" align=center border=0 
      valign="center" alt="Click Here to Buy Me!"></a> <a href="http://www.starbabies.net"><img src="http://1078386566/stars/index_files/rock.gif" align=center border=0 
      valign="center" alt="Click Here to Buy Me!"></a><a href="http://www.starbabies.net"><img src="http://1078386566/stars/index_files/movie.gif" align=center border=0 
      valign="center" alt="Click Here to Buy Me!"></a> <a href="http://www.starbabies.net"><img src="http://1078386566/stars/index_files/lucky.gif" align=center border=0 
      valign="center" alt="Click Here to Buy Me!"></a> <a href="http://www.starbabies.net"><img src="http://1078386566/stars/index_files/love.gif" align=center border=0 
      valign="center" alt="Click Here to Buy Me!"></a> </div>
        <HR color=#000080 SIZE=8>
        <div align="center"> 
          <p><font size="5"><b><font size="6">Now, for the first time ever, Starbabies 
            <br>
            are being offered on the Internet</font></b></font> </p>
          <p><font size="5"><b><font size="6" color="#FF0000">Special Christmas 
            Offer</font></b><br>
            <b>A sneek peek at Jingle, the Christmas Star for 2001</b></font></p>
          <p><b><font size="6" color="#FF0000">FREE PLUSH JINGLE TOY</font><font size="5"><br>
            with purchase of two or more</font></b></p>
          <p><b><font size="5" color="#FF0000">PLUS</font><font size="5"> a coupon 
            for 10% off<br>
            any future purchases!</font></b></p>
          <p><b><font size="5"><a href="http://www.starbabies.net">Click Here 
            to Visit Our Site!</a></font></b></p>
          <hr color=#000080 size=8>
          <p><a href="http://www.starbabies.net"><img src="http://1078386566/stars/index_files/set.gif" align=center border=0 
      valign="center" alt="Click Here to Buy Me!"></a> <a href="http://www.starbabies.net"><img src="http://1078386566/stars/index_files/rock.gif" align=center border=0 
      valign="center" alt="Click Here to Buy Me!"></a><a href="http://www.starbabies.net"><img src="http://1078386566/stars/index_files/movie.gif" align=center border=0 
      valign="center" alt="Click Here to Buy Me!"></a> <a href="http://www.starbabies.net"><img src="http://1078386566/stars/index_files/lucky.gif" align=center border=0 
      valign="center" alt="Click Here to Buy Me!"></a> <a href="http://www.starbabies.net"><img src="http://1078386566/stars/index_files/love.gif" align=center border=0 
      valign="center" alt="Click Here to Buy Me!"></a> </p>
          <p>&nbsp;</p>
        </div>
      </TD>
    </TR>
    <TR bgcolor="#000080"> 
      <TD align=middle> 
        <div align="center"><font size="2"><b><font face="Arial, Helvetica, sans-serif" size="1" color="#FFFF00">If 
          you received this in error or would like to be removed from our list,</font><font face="Arial, Helvetica, sans-serif" size="1"> 
          <a 
      href="mailto:johns712@excite.com?subject=RemoveSB"><font color="#FFFFFF">PLEASE 
          CLICK HERE</font></a></font></b></font></div>
      </TD>
    </TR>
    </TBODY> 
  </TABLE>
</DIV>
<DIV align=center> </DIV>
<DIV align=center> </DIV>
<P>&nbsp;</P>
<CENTER></CENTER></BODY></HTML>


From majordomo@raleigh.ibm.com  Mon Dec 18 08:49:44 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08531
	for <policy-archive@odin.ietf.org>; Mon, 18 Dec 2000 08:49:43 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA06684;
	Mon, 18 Dec 2000 08:37:07 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA20308;
	Mon, 18 Dec 2000 08:36:58 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA23782; Mon, 18 Dec 2000 08:02:08 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AB23772; Mon, 18 Dec 2000 08:02:04 -0500
Received: from lmr (lig32-227-160-213.us.lig-dial.ibm.com [32.227.160.213])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA30212;
	Mon, 18 Dec 2000 08:02:01 -0500
Message-Id: <000401c068f2$7ae0c8a0$d5a0e320@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <ipsec-policy@vpnc.org>
Cc: <policy@raleigh.ibm.com>
References: <5.0.0.25.0.20001213135252.00a14900@mail.redcreek.com>
Subject: Re: IPSP policy model: contidtions and actions
Date: Fri, 15 Dec 2000 18:24:45 -0500
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Lee Rafalow" <rafalow@raleigh.ibm.com>
Content-Transfer-Encoding: 7bit

Ricky, et al,

At the Policy Framework meeting on Wednesday, a small team of a subset of
the authors of the various drafts was formed to examine the differences
between the various drafts and propose a convergence or an explanation for
differences.  Packet classification is certainly one of the areas and in a
couple of ad hoc meetings we have already made some progress toward a common
understanding of the some of the differences.

First, as I mentioned in my talk, the background on the difference in packet
classification has to do with the level of abstraction of the domain-level
and device-level models.  As I mentioned in my response to Jean last week,
we haven't really discussed the relative merits of having the models close
to their target implementations vs. having the models close to each other.
Right now, the two device-level models both use filters (tho there are some
differences there as well, imo, caused by the need for compromises among the
QDDIM draft authors).

The more general technique of using a <variable><operator><value> grammar
(aka "atoms") is appealing even though it can be more verbose than the
filters approach.  Right now, that grammar has only one operator defined,
match, that compares a packet variable with a value or a set of values.  In
ICIM, we have a term of the condition specified by the AcceptCredentialsFrom
association to CredentialManagementService(s) and their trust hierarchies.
To do this with the atoms approach is not a simple extension.  The typing of
the association between the condition and variable would be extended to
include objects, similarly for condition and value.  Further, the use of an
enumeration to specify the operation needs to be examined: perhaps there's a
match method that is redefined in subclasses as needed.  We're looking at
these questions.

Of course, a simpler approach to convergence here would be to use atoms as
is for those things that can be specified with them and use other techniques
(e.g., AcceptCredentialsFrom) as needed.

Regardless, for IPsec to use the atoms technique, we would need to define
subclasses of variable and value for things like ID payloads and credential
fields.

Thoughts?  Lee

----- Original Message -----
From: "Ricky Charlet" <rcharlet@redcreek.com>
To: ""ipsec-policy@vpnc.org, Ricky Charlet"" <"ipsec-policy@vpnc.org, Ricky
Charlet":@ns.secondary.com;@rtpmail02.raleigh.ibm.com;>
Sent: Wednesday, December 13, 2000 5:12 PM
Subject: IPSP policy model: contidtions and actions


> Howdy,
>
> I think that the IPSP policy model puts conditions in the wrong place.
> SAConditions are contained by SARules which are derived from the Policy
> Core Information Model's Policy Rule. The problem I see here is that
> SAConditions are too specific to IPsec. I would rather see a model which
> sets up generic conditions to classify packets. Once a packet is classify
> by generalized conditions, then various actions (ie. ipsec, qos, nat,...)
> could be applied in a list of actions.
>
> Now, to do this would require tremendous coordination between all groups
> who might have an interest in packet classification. We know that right
> now, the qos and ipsec ways of modeling conditions or filters or are
> disjoint. So I am making a recommendation which will require a good bit of
> cross WG work and might perhaps move slowly.
>
> So what would be the benefit?
>
> If current trends hold, and each group who has an interest in classifying
> packets develops its own classification method, then we are very close to
> requiring that unnecessarily repetitive classification operations be done
> for each action which should be applied to the packet. It should be easy
> for us to envision examples where several actions (ipsec, qos, nat,
> firewall, ...) should be applied to the same packet. We should obviously
> strive to classify the packet once in implementations.
>
> Now, I said  ' very close to requiring' . I guess that even if different
> groups do invent different models of how to do classification, that does
> not necessarily mean that implementations must actually do classifications
> differently. But it certainly would be a confusion situation.
>
> Ricky Charlet
> rcharlet@redcreek.com
>



From majordomo@raleigh.ibm.com  Mon Dec 18 21:45:10 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21353
	for <policy-archive@odin.ietf.org>; Mon, 18 Dec 2000 21:45:06 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA21504;
	Mon, 18 Dec 2000 21:38:01 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id VAA20566;
	Mon, 18 Dec 2000 21:38:00 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA07634; Mon, 18 Dec 2000 12:43:33 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA26314; Mon, 18 Dec 2000 12:43:29 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA23722
	for <policy@raleigh.ibm.com>; Mon, 18 Dec 2000 12:43:31 -0500
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA20652
	for <policy@raleigh.ibm.com>; Mon, 18 Dec 2000 11:05:00 -0500
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Mon, 18 Dec 2000 08:03:17 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 18 Dec 2000 08:03:59 -0800 (Pacific Standard Time)
Received: from DF-SPIKE.platinum.corp.microsoft.com ([172.30.236.82]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532);
	 Mon, 18 Dec 2000 08:03:58 -0800
X-Mimeole: Produced By Microsoft Exchange V6.0.4604.0
Content-Class: urn:content-classes:message
Subject: RE: Clarification of comments made during yesterday's WG meeting
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Mon, 18 Dec 2000 08:03:58 -0800
Message-Id: <A5769B3C2F02274B9D17F5FB4495DD5F53698B@DF-SCOOBY.platinum.corp.microsoft.com>
Thread-Topic: Clarification of comments made during yesterday's WG meeting
Thread-Index: AcBmHr2Mr7DKF40cSS2233zjOhX7dQArzbcA
From: "Yoram Bernet" <yoramb@Exchange.Microsoft.com>
To: "Robert Moore" <remoore@US.IBM.COM>
Cc: <policy@raleigh.ibm.com>
X-Originalarrivaltime: 18 Dec 2000 16:03:58.0989 (UTC) FILETIME=[218E93D0:01C0690C]
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Yoram Bernet" <yoramb@Exchange.Microsoft.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA21353

Bob:

I think that your suggestion regarding focusing on the datapath elements
is valid. But - I think that first, we need to sketch out the high level
'modules' and to keep that modularization in mind while pursuing the
datapath elements. This doesn't have to be a painful or drawn out
effort. I think that we understand pretty well what the modules are:

1. Datapath stuff.
2. Provisioning and configuration stuff (which includes signaling and
admission control).

The scope of the modules should also be made clear wrt the various
underlying QoS technologies:

Datapath stuff is equally applicable to diffserv and the kind of traffic
handling that is traditionally (yet erroneously) associated with
RSVP/Intserv. In other words - datapath stuff is equally applicable to
aggregate and per-flow traffic handling.

Provisioning and configuration (including signaling and explicit
admission control) include COPS and RSVP (among others) and are
applicable both to intserv and to diffserv. The various mechanisms can
be applied to configure the various datapath elements. The goal of the
provisioning and configuration mechanisms is to configure the datapath
elements in a cohesive manner across a network. 

I would like to see this message captured somewhere, loud and clear. It
could be kept short and inserted in the introduction to the QDDIM (and
related drafts). Or - it could be made part of a policy framework draft.
It doesn't necessarily need more words than offered here, but it might
benefit from a few paragraphs of elaboration and some examples. 

Yoram

> -----Original Message-----
> From: Robert Moore [mailto:remoore@us.ibm.com]
> Sent: Thursday, December 14, 2000 7:59 AM
> To: Yoram Bernet
> Cc: policy@raleigh.ibm.com
> Subject: Re: Clarification of comments made during yesterday's WG
> meeting
> 
> 
> Yoram,
> 
> Speaking just for myself, i.e., not for the other
> QDDIM authors, I think you have described more
> accurately than we did the reduction of scope we
> intended when we moved from QDIM to QDDIM.
> I know, for example, that we said things like
> "Let's just focus on the data path elements, and
> finish them."
> 
> Obviously there's more to it than this, but I think
> that we should move immediately to a more accurate
> full title for QDDIM, QoS Device Datapath Information
> Model, when we produce the -03 draft.
> 
> Regards,
> Bob
> 
> Bob Moore
> IBM Networking Software
> +1-919-254-4436
> remoore@us.ibm.com
> 
> 
> 
> "Yoram Bernet" <yoramb@Exchange.Microsoft.com>@raleigh.ibm.com on
> 12/12/2000 01:23:36 PM
> 
> Please respond to "Yoram Bernet" <yoramb@Exchange.Microsoft.com>
> 
> Sent by:  policy-owner@raleigh.ibm.com
> 
> 
> To:   <policy@raleigh.ibm.com>
> cc:
> Subject:  Clarification of comments made during yesterday's WG meeting
> 
> 
> 
> 
> 
> At the end of yesterday's meeting, Ed paraphrased my 
> comments. I think that
> my comments were not clearly understood. I will attempt to clarify:
> 
> The fundamental issue is one of modularization. Policy is such an
> overwhelming 'blob' to tackle - as a result, the authors of 
> QDDIM and QPIM
> are tackling the effort picemeal. This makes sense. I am not 
> calling for
> all pieces of the QoS policy puzzle to be tackled at once. 
> What i'm calling
> for is very careful modularization. As I commented yesterday 
> on the list,
> the modulariztion in QDDIM strikes me as wrong. QDDIM 
> repeatedly states
> that it is tacking the DiffServ module in this pass and will 
> tackle the
> IntServ model in the next pass. QPIM talks about the RSVP 
> part versus the
> DiffServ part. In QPIM, the two are pretty much separated, 
> except for the
> brief part about using RSVP to return DCLASS objects (whihc 
> are DiffServ
> related).
> 
> In my opinion, the modularization should be one of datapath mechanisms
> versus control mechanisms. Datapath mechanisms include:
> 
> Classification
> Metering
> Dropping
> Marking
> Queuing
> 
> These are neither IntServ nor DiffServ - they are equally 
> applicable to
> both. They are more generic than IntServ or DiffServ.
> 
> Control mechanisms configure the datapath mechanisms. They include:
> 
> SNMP
> COPS
> RSVP
> Others...
> 
> Datapath and control mechanisms interact. For example - when 
> a DiffServ
> network provider provisions an EF service instance between 
> ingress point A
> and egress point B, it's necessary to verify that resources 
> are available
> along the path from A to B and to install the appropriate policers to
> assure that the EF service is not abused. This requires 
> interaction between
> some policy agents and the queuing and classification mechanisms in at
> least some of the network elements along the path from A to 
> B. Part of this
> interaction involves admission control (are there sufficient 
> resources to
> support the SLA? can the new service be provisioned without 
> violating other
> SLAs?), part of it amounts to configuring policers. 
> Similarly, when an RSVP
> request arrives at a PEP/PDP, it is necessary to apply 
> admission control,
> and then to configure policers and queuing in accordance with 
> the admission
> control decision.
> 
> So - IMHO, the drafts should identify the two types of 
> mechanisms and the
> types of interaction between them. They may then choose to 
> tackle one set
> or the other set at this time, with the remainder to be tackled later.
> However - they should not draw distinctions between IntServ *versus*
> DiffServ, nor between DiffServ *versus* RSVP. This distinction is
> misleading and short sighted. Just consider that RSVP can be used for
> admission control to and configuration of DiffServ traffic handling
> mechanisms just as it can be used for admission to and 
> control of microflow
> (per 5-tuple) traffic handling mechanisms. Consider that a single
> end-to-end path may offer aggregate traffic handling 
> (diffserv) in certain
> devices and per-flow traffic handling (traditionally associated with
> intserv) in other devices.
> 
> In summary, a full service QoS network should be able to make use of
> per-flow traffic handling, aggregate traffic handling, 
> relatively static
> 'push' provisioning and configuration mechanisms and the more 
> dynamic RSVP
> signaling configuration mechanism *all in the same network*. 
> Policy should
> focus on how these interact seamlessly, thereby uniting them. 
> As the drafts
> carve out pieces to tackle, these interactions should be 
> noted and similar
> pieces should be tackled in the same draft.
> 
> This is a difficult message to convey - it's somewhat 
> abstract. So - here's
> a concrete example of what happens when we artificially separate
> RSVP/IntServ from DiffServ:
> 
> ***************** Example*******************
> 
> Consider how COPS/RSVP and COPS/PR are used between PEPs and PDPs:
> 
> COPS/RSVP:
> * An RSVP message arrives at a PEP. It is a request for resources that
> specifies the type of service desired, the amount of traffic 
> for which this
> service is required and the classification information by 
> which the traffic
> can be recognized.
> 
> * The PDP makes an admission control decision.
> * If the request is admitted, then the PDP tells the PEP that 
> the request
> is admitted.
> * Now the PEP configures: 1. a microflow classifier 
> corresponding to the
> 5-tuple in the RSVP message 2. a policer corresponding to the 
> tspec in the
> RSVP message 3. the appropriate queuing to provide the 
> service approved (2
> and 3 are closely related).
> 
> COPS/PR:
> * A PEP needs to be configured to support a certain SLA for certain
> traffic.
> * The PDP must check with the PEP to be sure that it can 
> accommodate  the
> SLA (admission control decision is made)
> * If the SLA can be supported, the PDP configures in the PEP: 1. a
> classifier (potentially microflow) corresponding to the 
> customer traffic
> stream to recieve the diffserv service per the SLA. 2. a 
> policer to protect
> the diffserv network and possibly to protect one subset of 
> the customer's
> traffic from another. 3. the appropriate queuing in the same or in
> subsequent PEPs.
> 
> Note that in both cases, there is a need to configure 
> classifiers, policers
> and queuing mechanisms in PEPs. In the first case, the PDP does so
> indirectly (by admitting the RSVP request). In the second 
> case, it does so
> directly. However, in both cases - the result is to consume 
> resources from
> the same interfaces. It would have been much simpler if the 
> work of COPS
> was separated into 1. responding to provisioning and 
> configuration requests
> (whetehr they arrvie by RSVP or by administrative control) and 2.
> configuring traffic handling mechanisms. In that case, the COPS/RSVP
> example would have the PDP directly configuring the traffic handling
> mechanisms in response to the RSVP message, just as it does 
> in the COPS/PR
> case. There is overlap between COPS/PR and COPS/RSVP that is 
> related to an
> artificial distinction between RSVP/IntServ and DiffServ.
> 
> ***********************************************
> 
> 
> 
> 


From majordomo@raleigh.ibm.com  Tue Dec 19 12:12:24 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18579
	for <policy-archive@odin.ietf.org>; Tue, 19 Dec 2000 12:12:21 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA29192;
	Tue, 19 Dec 2000 12:03:14 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA34696;
	Tue, 19 Dec 2000 12:03:09 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA23528; Tue, 19 Dec 2000 11:26:53 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA23490; Tue, 19 Dec 2000 11:26:46 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA35158
	for <policy@raleigh.ibm.com>; Tue, 19 Dec 2000 11:26:48 -0500
Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA29436
	for <policy@raleigh.ibm.com>; Tue, 19 Dec 2000 10:46:39 -0500
Received: from yramberg-8000.cisco.com (telaviv3-dhcp11.cisco.com [144.254.93.139])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id RAA15594
	for <policy@raleigh.ibm.com>; Tue, 19 Dec 2000 17:45:59 +0200 (IST)
Message-Id: <4.3.2.7.2.20001219021611.03a81540@csi-admin1.cisco.com>
X-Sender: yramberg@csi-admin1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 19 Dec 2000 07:41:59 +0200
To: policy@raleigh.ibm.com
From: Yoram Ramberg <yramberg@cisco.com>
Subject: On unified QoS policy model
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Yoram Ramberg <yramberg@cisco.com>

Dear esteemed modeling gurus,

Having almost fully recovered from my jet lag, I'm doing some rethinking on 
some of the issues that came up in the San Diego meeting. One thing that's 
stuck in my mind and may be worth commenting on (surely among many 
others...) is the comments made by Yoram Barnet about unified QoS policy 
modeling (my term - I think he would call it 'modular QoS policy 
modeling'). I have to say that I'm quite taken by Yoram's approach. Kindly 
humor me for a few paragraphs as I'm engaged in on-line rumination here...

Yoram talks about two drafts in particular: QPIM and QDDIM. Even though 
Yoram criticized QDDIM for the explicit DiffServ-only scope it spans (and 
for which an extra 'D' had been added to the document's title), I think his 
critique of QDDIM is unduly harsh. The Barnet argument can actually be used 
to justify QDDIM's DiffServ-only approach as long as it is explicitly 
stated, which it is. QDDIM (at its current form) is an attempt to take the 
next step past the DiffServ "informal model" and formalize it. It is a 
DiffServ information model. Nothing wrong with this, IMO. Some may claim 
that this positions QDDIM outside the scope of the W'G's charter but I 
won't go into this argument now. The rest of this memo deals with QPIM 
only. Furthermore, when I say 'QPIM' I'm referring to the narrow scope of 
QoS -- not the parts of QPIM that are offered now as extension for PCIM. 
While there are interesting implications to other modeling efforts such as 
ICIM (the IPSP work) and MPLS, I'll restrict myself to QoS as an 
independent discipline, artificial though this approach might seem. It's a 
convenient, narrow scope.

To recap and interpret the Barnet argument: Yoram expressed a concern 
regarding the artificial distinction between IntServ and DiffServ in the 
various documents. In his comments (spoken and written) he points out that 
the correct distinction is between data path and control path constructs. 
Data path constructs are those which effect (or operate on) the *objects* 
of policy, e.g. micro and/or aggregate flows. Control path constructs are 
those which are used to configure the data path constructs, e.g. COPS, 
RSVP, etc.. (I'm using the term 'constructs' because it is still "clean" 
enough and has no problematic connotation. Saying 'class' or 'mechanism', 
for example, might imply inaccurate context).

Regardless of the control path constructs used in a given policy system, 
says Yoram, a scheduler may still have to be configure and admission 
control may still have to be imposed. Yoram gives some compelling examples 
that I won't repeat here.

What does it all say about the WG work? Quite a bit, IMO. In particular, 
this is a critique of the approach taken by QPIM as a "high level"  QoS 
policy model. What was done in QPIM is an attempt to model DiffServ and 
IntServ (the latter is not distinguished from RSVP, an interesting 
discussion all by itself...) as part of the same policy system but still as 
distinct constructs. It is the wrong "modularization", as Barnet puts it. 
Take, for instance, the construct called PR action (qosPolicyPRAction). 
This is a conglomeration of a set of parameters to configure several data 
path constructs. I suppose this fits well with the DS MIB. However, 
"policing" and "shaping" are not necessarily the exclusive domain of 
DiffServ. In particular, these are useful concepts when specifying how to 
treat data flowing through the network. But this treatment may be 
configured as a result of an RSVP RESV signal as well as result of 
provisioned DiffServ policy. Barnet claims (not in so many words) that this 
is a modeling mistake that may cost us in the future (I'll leave the 
detailed argument to Yoram as he fathered it).

Does this mean that QPIM should not include a PR action or and RSVP action? 
I don't necessarily think so. Policy systems may wish to allow their users 
to specify control path constructs, data path constructs and 
inter-associate them as part of the policy specification. A certain policy 
instance may contain specification for the markers, shapers, droppers, 
schedulers, etc. and also the control path constructs such as PR actions 
and/or RSVP actions that may clump them together as a "control" action. Say 
a PDP responds to a user command by reading the data path construct for a 
set of PEPs (roles come to play here) and use COPS to configure those PEPs 
(how nice we're mapped to the PIB...). A PEP may also respond to an RSVP 
signal by consulting a PDP and, based on a PDP response, configure the very 
same elements using the very same policers, etc. It is a matter of 
"modularization", right?

Can we live with current QPIM (or the next revision thereof)? Probably, but 
I really think that some work should be done to manifest the elegance and 
clarity that the Barnet approach preaches. I'm not sure how much work this 
entails but I want to find out. Is it merely a matter of elegance? Barnet 
says it is not. I hereby request Yoram to clarify his point regarding the 
future price we may incur for not using his unified approach. Do I wish 
Yoram had made his enlightening comments on these issues before? I do.

I most certainly expect to be severely flamed for this note, either for 
missing the point altogether, being wrong on the issues themselves or, at 
an extreme, for discombobulating the work processes of the WG. Still, I'd 
rather be flamed than ignored...

Cheers,
*Yoram



From majordomo@raleigh.ibm.com  Tue Dec 19 19:49:09 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28833
	for <policy-archive@odin.ietf.org>; Tue, 19 Dec 2000 19:49:09 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA20670;
	Tue, 19 Dec 2000 19:40:58 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id TAA25674;
	Tue, 19 Dec 2000 19:40:09 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA48166; Tue, 19 Dec 2000 19:12:23 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA48148; Tue, 19 Dec 2000 19:12:19 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id TAA28944
	for <policy@raleigh.ibm.com>; Tue, 19 Dec 2000 19:12:23 -0500
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA26686
	for <policy@raleigh.ibm.com>; Tue, 19 Dec 2000 19:12:18 -0500
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 19 Dec 2000 14:59:18 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 19 Dec 2000 15:00:00 -0800 (Pacific Standard Time)
Received: from DF-SCOOBY.platinum.corp.microsoft.com ([172.30.236.82]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532);
	 Tue, 19 Dec 2000 15:00:00 -0800
X-Mimeole: Produced By Microsoft Exchange V6.0.4604.0
Content-Class: urn:content-classes:message
Subject: RE: On unified QoS policy model
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 19 Dec 2000 15:00:00 -0800
Message-Id: <A5769B3C2F02274B9D17F5FB4495DD5F536A0A@DF-SCOOBY.platinum.corp.microsoft.com>
Thread-Topic: On unified QoS policy model
Thread-Index: AcBp/02n20R6O+g8T7yUj13cFFbPdgADMDtg
From: "Yoram Bernet" <yoramb@Exchange.Microsoft.com>
To: "Yoram Ramberg" <yramberg@cisco.com>, <policy@raleigh.ibm.com>
X-Originalarrivaltime: 19 Dec 2000 23:00:00.0706 (UTC) FILETIME=[6A501220:01C06A0F]
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Yoram Bernet" <yoramb@Exchange.Microsoft.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA28833

Yoram:

Thanks for your comments. I think that I mostly agree with you. My
comments follow below...

> Yoram talks about two drafts in particular: QPIM and QDDIM. 
> Even though 
> Yoram criticized QDDIM for the explicit DiffServ-only scope 
> it spans (and 
> for which an extra 'D' had been added to the document's 
> title), I think his 
> critique of QDDIM is unduly harsh. The Barnet argument can 
> actually be used 
> to justify QDDIM's DiffServ-only approach as long as it is explicitly 
> stated, which it is. 

I fear that I have been misunderstood... I did not criticize it for
limiting its scope. In fact, I acknowledged the need to limit scope and
I fully support doing so. However, I questioned the 'definition' of the
scope. The scope is defined as 'diffserv', as opposed to 'intserv'. I
think that the scope is actually right, but the words defining the scope
strike me as wrong. I think that the draft talks about datapath
elements. That is an appropriate scope. These elements are equally
useful to insterv as they are to diffserv, as currently defined in the
draft. Therefore, the draft should not say "this is about diffserv and
not about intserv", but possibly: "this is about datapath elements
equally applicable to intserv as to diffserv.  Similarly, a useful and
complete policy model for diffserv must address issues of explicit
admission control. (Without doing so, it's impossible to support high
quality services without significant overprovisioning). Discussion of
admission control is absent in this draft, so - it doesn't provide a
complete model for diffserv. My claim is that - in some ways, this draft
defines more than diffserv and in some ways, less than diffserv. What it
defines is useful and is a resonable piece to chew off, but it's not
'diffserv'. All i'm saying is that that needs to be noted, up front.
And, as you questioned later in the mail, I do believe that in this case
(as in the case of QPIM) the issue is more than one of elegance, but
that it gets at the very heart of the model and will have repercussions
later if it's not clearly understood up front. More on this below.

> 
> To recap and interpret the Barnet argument: Yoram expressed a concern 
> regarding the artificial distinction between IntServ and 
> DiffServ in the 
> various documents. In his comments (spoken and written) he 
> points out that 
> the correct distinction is between data path and control path 
> constructs. 
> Data path constructs are those which effect (or operate on) 
> the *objects* 
> of policy, e.g. micro and/or aggregate flows. Control path 
> constructs are 
> those which are used to configure the data path constructs, 
> e.g. COPS, 
> RSVP, etc..

and SNMP and CLI - important to include these because they represent a
(generally) more static approach to provisioning and configuration of
the datapath elements, whereas COPS/RSVP and RSVP represent more dynamic
approaches. 

(I'm using the term 'constructs' because it is 
> still "clean" 
> enough and has no problematic connotation. Saying 'class' or 
> 'mechanism', 
> for example, might imply inaccurate context).
> 

What was done in QPIM is an attempt to model 
> DiffServ and 
> IntServ (the latter is not distinguished from RSVP, an interesting 
> discussion all by itself...)

Indeed. I have been the target of many a tongue lashing by esteeemed
gurus, that this distinction must be made. I must say that - I have come
to support this myself. IntServ and RSVP are very different things -
related, but different. 

However, 
> "policing" and "shaping" are not necessarily the exclusive domain of 
> DiffServ. In particular, these are useful concepts when 
> specifying how to 
> treat data flowing through the network. But this treatment may be 
> configured as a result of an RSVP RESV signal as well as result of 
> provisioned DiffServ policy. 

Exactly.

> Does this mean that QPIM should not include a PR action or 
> and RSVP action? 
> I don't necessarily think so. 

I agree. If you want the scope of QPIM to address PR actions and RSVP
actions, by all means - do so, but - these should be clearly identified
as similar actions that act on a common set of datapath elements. 

Policy systems may wish to 
> allow their users 
> to specify control path constructs, data path constructs and 
> inter-associate them as part of the policy specification. A 
> certain policy 
> instance may contain specification for the markers, shapers, 
> droppers, 
> schedulers, etc. and also the control path constructs such as 
> PR actions 
> and/or RSVP actions that may clump them together as a 
> "control" action. Say 
> a PDP responds to a user command by reading the data path 
> construct for a 
> set of PEPs (roles come to play here) and use COPS to 
> configure those PEPs 
> (how nice we're mapped to the PIB...). A PEP may also respond 
> to an RSVP 
> signal by consulting a PDP and, based on a PDP response, 
> configure the very 
> same elements using the very same policers, etc. 

Yes - I agree completely.

> Can we live with current QPIM (or the next revision thereof)? 
> Probably, but 
> I really think that some work should be done to manifest the 
> elegance and 
> clarity that the Barnet approach preaches.

Thanks. I'm honored.

 I'm not sure how 
> much work this 
> entails but I want to find out. Is it merely a matter of 
> elegance? Barnet 
> says it is not. I hereby request Yoram to clarify his point 
> regarding the 
> future price we may incur for not using his unified approach. 

Did you see my example of how COPS/PR and COPS/RSVP overlap (posted at
the end of my last mail on this)? It suggests that we arrived at
COPS/RSVP by focusing on RSVP and that we arrived at COPS for PR by
focusing on DiffServ. The result is kind of confusing. Admitting a
COPS/RSVP request results in actions that affect the very same datapath
elements that a COPS/PR command impact. But doing it via COPS/RSVP is
implicit, while doing it by COPS/PR is explicit. I think that this
raises all sorts of interesting questions such as - "where is the
accounting of the datapath resources actually kept (because both
approaches impact the resource availability)? Is this a sufficiently
clear example of what results? If not, we can discuss further. But -
this is one obvious example that i'd like to get common understanding on
before proceeding.

> Do I wish 
> Yoram had made his enlightening comments on these issues before? I do.

I did - in Adleaide and before, though with less vigor :-)...

> 
> I most certainly expect to be severely flamed for this note, 
> either for 
> missing the point altogether, being wrong on the issues 
> themselves or, at 
> an extreme, for discombobulating the work processes of the 
> WG. Still, I'd 
> rather be flamed than ignored...
> 
> Cheers,
> *Yoram
> 
Cheers
the other Yoram


From majordomo@raleigh.ibm.com  Wed Dec 20 01:05:56 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05529
	for <policy-archive@odin.ietf.org>; Wed, 20 Dec 2000 01:05:56 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA32698;
	Wed, 20 Dec 2000 00:58:20 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id AAA33024;
	Wed, 20 Dec 2000 00:58:16 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA45310; Wed, 20 Dec 2000 00:31:03 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA45272; Wed, 20 Dec 2000 00:30:57 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id AAA19110
	for <policy@raleigh.ibm.com>; Wed, 20 Dec 2000 00:31:02 -0500
Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA32532
	for <policy@raleigh.ibm.com>; Wed, 20 Dec 2000 00:31:02 -0500
Received: from pacbell.net ([207.214.220.160])
 by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9)
 with ESMTP id <0G5U00JY7PWJVX@mta5.snfc21.pbi.net> for policy@raleigh.ibm.com;
 Tue, 19 Dec 2000 21:29:09 -0800 (PST)
Date: Tue, 19 Dec 2000 21:37:40 -0800
From: Andrew Smith <ah_smith@pacbell.net>
Subject: Re: On unified QoS policy model
To: policy@raleigh.ibm.com
Message-Id: <3A4045A4.8000701@pacbell.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108
 Netscape6/6.0
X-Accept-Language: en
References: 
 <A5769B3C2F02274B9D17F5FB4495DD5F536A0A@DF-SCOOBY.platinum.corp.microsoft.com>
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Andrew Smith <ah_smith@pacbell.net>
Content-Transfer-Encoding: 7bit

I think we're onto an important issue with this thread and I'd fully support 
work along the lines outlined by these Yorams (seems like there are 2 out of 3 
of the Yorams in agreement :-)).

If the current scope of modelling work has to be limited (which I guess is 
necessary just to stop the whole thing from getting out of hand) then I think 
I'd rather see the scope of the current piece of work focus on the data plane 
model, one that includes Intserv as well as Diffserv data planes, and leave the 
"admission control" modelling (for IS and DS) for later.

BTW, Yoram B. and several others having been making this "grand unified theory 
of QoS" argument for quite a while now - maybe it's the first time in this WG 
though.

<WARNING: infocommercial follows> Yoram B. is probably too modest to mention it 
but there is quite a lot of argument in favour of this approach explained in 
gory detail in his new book "Networking QoS and Windows Operating Systems" (New 
Riders) - I'd highly recommend it as background reading material for this WG 
work item (don't worry - it doesn't mention W*****s until about page 500 :-) - 
most of the book is generically about the IETF QoS work).

Andrew

Yoram Bernet wrote:

> Yoram:
> 
> Thanks for your comments. I think that I mostly agree with you. My
> comments follow below...
...



From majordomo@raleigh.ibm.com  Wed Dec 20 12:56:02 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06872
	for <policy-archive@odin.ietf.org>; Wed, 20 Dec 2000 12:56:00 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA24600;
	Wed, 20 Dec 2000 12:45:47 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA32784;
	Wed, 20 Dec 2000 12:45:44 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA46426; Wed, 20 Dec 2000 12:19:05 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA25938; Wed, 20 Dec 2000 12:19:02 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA32090;
	Wed, 20 Dec 2000 12:18:59 -0500
From: c.mang@5services.cc
Received: from edongcity.com ([61.129.36.245])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA15914;
	Wed, 20 Dec 2000 12:18:37 -0500
Received: from ATHLON_[205.184.255.55] [205.184.255.55] by edongcity.com
	with Novonyx SMTP Server $Revision:   2.25  $; Thu, 21 Dec 2000 01:16:24 +0800 (CTT)
Received: from virtual.umb.edu.co by ATHLON with ESMTP; Tue, 29 Feb 2000 12:12:50 -0600
Message-Id: <00002eb7370c$00006f5f$00006d60@virtual.umb.edu.co>
To: <howard@5Business.cc>
Subject: Are you looking for the perfect tax write off?                         28000
Date: Tue, 29 Feb 2000 12:12:40 -0600
Mime-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: c.mang@5services.cc
Content-Transfer-Encoding: quoted-printable

<HTML>
<BODY>

<FONT face=3D"MS Sans Serif">
<FONT size=3D2> Do You Have The Yen To Be a A Millionaire?<BR>
<BR>
100% return in less than 90 days!<BR>
<BR>
Unique Strategy Trading in the International Currency Markets!<BR>
<BR>
Largest MarketPlace in the World!<BR>
<BR>
Get our Reports, Charts and Strategies on the U.S. Dollar vs<BR>
Japanese yen and euro dollar.<BR>
<BR>
Example:<BR>
<BR>
A $5,000 Investment in the yen vs the dollar, "properly positioned",<BR>
on 08/18 could have returned $15,184.45 on 09/19/99.<BR>
<BR>
For a "FREE NO OBLIGATION" investors packet Just Click Below to visit our =
website:<BR>
<BR>
<a href=3D"http://205.232.74.222">click here</a><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
To be removed:removepromonow@5services.cc<BR>
<BR>
</FONT></FONT>
</BODY>
</HTML>




From majordomo@raleigh.ibm.com  Fri Dec 22 21:51:58 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18496
	for <policy-archive@odin.ietf.org>; Fri, 22 Dec 2000 21:51:58 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA30982;
	Fri, 22 Dec 2000 21:41:33 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id VAA27744;
	Fri, 22 Dec 2000 21:41:27 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA28514; Fri, 22 Dec 2000 21:12:50 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA55626; Fri, 22 Dec 2000 21:12:45 -0500
Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id VAA34810
	for <policy@raleigh.ibm.com>; Fri, 22 Dec 2000 21:12:48 -0500
From: Ed_Ellesson@tivoli.com
Received: from schub.tivoli.com (schub.tivoli.com [146.84.104.17])
	by corp.tivoli.com (8.9.3/8.9.0) with ESMTP id UAA23900
	for <policy@raleigh.ibm.com>; Fri, 22 Dec 2000 20:12:45 -0600 (CST)
Importance: Normal
Subject: Draft Minutes from Policy WG Sessions in San Diego
To: policy@raleigh.ibm.com
Date: Fri, 22 Dec 2000 21:09:33 -0500
Message-Id: <OFC4BEB19D.7C9401FF-ON052569BE.000AFD62@tivoli.com>
X-Mimetrack: Serialize by Router on SCHub/Tivoli Systems(Release 5.0.4a |July 24, 2000) at
 12/22/2000 08:12:44 PM
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Ed_Ellesson@tivoli.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA18496

Hi,

Section 1 is from the wrap-up charts which we discussed at the end of each
session, and combines the action items from both days.  Joel and I turned
in this summary section (just Section 1), as our report to Bert on the
results of our meetings.

Section 2 is from my notes for Monday's session.

Section 3 is from my notes for Wednesday's session.

I have not reviewed Sections 2 and 3 with anyone.

Fire away.  We need to turn these in with the the charts by the end of next
week.

I have everyone's charts.  Thank you for sending them to me.  I will submit
them with the revised minutes.

*************************************

Draft Summary and Minutes
Policy Framework Working Group Meeting
49th IETF, San Diego
Submitted by Ed Ellesson, December 22, 2000

1.   Summary and Action Items, combined from both wg sessions:

1.1   QDDIM: (QOS DiffServ Device Info Model, or QOS Datapath Device Info Model)

      -Differences with DiffServ are now resolved

      -Expect name change to the QDDIM draft to reflect generic qos datapath focus for
       traffic handling and conditioning (ie. not just diffserv), but qos signaling
       (control plane) will continue to be out of scope for this document.

       *  Action:  Bob Moore

      -Schedulers/Queues relationship: Expect co-author consensus to be posted on
       the policy mailing list, in approximately two weeks.

       *  Action:  Walter Weiss

1.2   QPIM:  (QOS Policy Information Model)

       *  Action:  QPIM Authors:

      -Overlap and linkage with QDDIM: Need added text/terminology to describe
       how/why policy objects are approached differently in QPIM, than from
       device level view in QDDIM.

      -Further clarification may be added to describe distinctions among the
       following functions:  Configuration, policy (operational behavior), and
       state.

      -QPIM continues to be device independent, and mechanism independent. Examples
       are needed that show the abstraction level for QPIM, including policy vs.
       mechanism.

      -A new PCIM extensions draft will be written, which describes generic PCIM
       functions that can be broken out separately from the current QPIM draft
       (ie. those that are not QOS-specific.  The first phase of this was agreed
       to be done by the current QPIM authors, themselves.

      -RSVP with diffserv in the same network. Positioning statement needed for
       this situation.

1.3   ICIM (IPSP Configuration Information Model):

      -The content of this document is owned by the IPSP working group.

      -Our liaison with IPSP (Lee Rafalow) will take a look at similarities with
       QPIM, to determine if there is any reason to recommend further harmonizing
       any of the functionality there with QDDIM or QPIM approaches, such as in
       the area of sequenced actions.

1.4   Packet classification work effort proposed:

      -Small design team will be formed to clearly document the motivations for the
       differing approaches to packet classification across QDDIM, QPIM and ICIM.
       This team will clearly express the design goals of each approach


From majordomo@raleigh.ibm.com  Fri Dec 22 22:29:34 2000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18716
	for <policy-archive@odin.ietf.org>; Fri, 22 Dec 2000 22:29:34 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id WAA25024;
	Fri, 22 Dec 2000 22:19:06 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id WAA30686;
	Fri, 22 Dec 2000 22:19:05 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43920; Fri, 22 Dec 2000 21:53:34 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA53384; Fri, 22 Dec 2000 21:53:31 -0500
Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id VAA21942
	for <policy@raleigh.ibm.com>; Fri, 22 Dec 2000 21:53:35 -0500
From: Ed_Ellesson@tivoli.com
Received: from schub.tivoli.com (schub.tivoli.com [146.84.104.17])
	by corp.tivoli.com (8.9.3/8.9.0) with ESMTP id UAA00981;
	Fri, 22 Dec 2000 20:53:33 -0600 (CST)
Importance: Normal
Subject: Retry:  Draft Minutes from Policy WG Sessions in San Diego
To: policy@raleigh.ibm.com
Cc: eellesson@nc.rr.com
Date: Fri, 22 Dec 2000 21:46:47 -0500
Message-Id: <OF4551B4D0.FA945161-ON052569BE.000F8099@tivoli.com>
X-Mimetrack: Serialize by Router on SCHub/Tivoli Systems(Release 5.0.4a |July 24, 2000) at
 12/22/2000 08:53:32 PM
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Ed_Ellesson@tivoli.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA18716

Hi,

[The copy of this which I received on my first try did not include anything
beyond the first paragraph of item 1.4.  I don't know why.  Here is another
attempt at sending the whole thing.]

Section 1 is from the wrap-up charts which we discussed at the end of each
session, and combines the action items from both days.  Joel and I turned
in this summary section (just Section 1), as our report to Bert on the
results of our meetings.

Section 2 is from my notes for Monday's session.

Section 3 is from my notes for Wednesday's session.

I have not reviewed Sections 2 and 3 with anyone.

Fire away.  We need to turn these in with the the charts by the end of next
week.

I have everyone's charts.  Thank you for sending them to me.  I will submit
them with the revised minutes.

*************************************

Draft Summary and Minutes
Policy Framework Working Group Meeting
49th IETF, San Diego
Submitted by Ed Ellesson, December 22, 2000

1.   Summary and Action Items, combined from both wg sessions:

1.1   QDDIM: (QOS DiffServ Device Info Model, or QOS Datapath Device Info Model)

      -Differences with DiffServ are now resolved

      -Expect name change to the QDDIM draft to reflect generic qos datapath focus for
       traffic handling and conditioning (ie. not just diffserv), but qos signaling
       (control plane) will continue to be out of scope for this document.

       *  Action:  Bob Moore

      -Schedulers/Queues relationship: Expect co-author consensus to be posted on
       the policy mailing list, in approximately two weeks.

       *  Action:  Walter Weiss

1.2   QPIM:  (QOS Policy Information Model)

       *  Action:  QPIM Authors:

      -Overlap and linkage with QDDIM: Need added text/terminology to describe
       how/why policy objects are approached differently in QPIM, than from
       device level view in QDDIM.

      -Further clarification may be added to describe distinctions among the
       following functions:  Configuration, policy (operational behavior), and
       state.

      -QPIM continues to be device independent, and mechanism independent. Examples
       are needed that show the abstraction level for QPIM, including policy vs.
       mechanism.

      -A new PCIM extensions draft will be written, which describes generic PCIM
       functions that can be broken out separately from the current QPIM draft
       (ie. those that are not QOS-specific.  The first phase of this was agreed
       to be done by the current QPIM authors, themselves.

      -RSVP with diffserv in the same network. Positioning statement needed for
       this situation.

1.3   ICIM (IPSP Configuration Information Model):

      -The content of this document is owned by the IPSP working group.

      -Our liaison with IPSP (Lee Rafalow) will take a look at similarities with
       QPIM, to determine if there is any reason to recommend further harmonizing
       any of the functionality there with QDDIM or QPIM approaches, such as in
       the area of sequenced actions.

1.4   Packet classification work effort proposed:

      -Small design team will be formed to clearly document the motivations for the
       differing approaches to packet classification across QDDIM, QPIM and ICIM.
       This team will clearly express the design goals of each approach


From majordomo@raleigh.ibm.com  Sat Dec 23 11:16:04 2000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05301
	for <policy-archive@odin.ietf.org>; Sat, 23 Dec 2000 11:16:04 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA30794;
	Sat, 23 Dec 2000 11:08:13 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA35938;
	Sat, 23 Dec 2000 11:08:05 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA56328; Sat, 23 Dec 2000 10:24:38 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA57592; Sat, 23 Dec 2000 10:24:33 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA27926
	for <policy@raleigh.ibm.com>; Sat, 23 Dec 2000 10:24:35 -0500
Received: from mail7.nc.rr.com (mail7.southeast.rr.com [24.93.67.54])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA22948
	for <policy@raleigh.ibm.com>; Sat, 23 Dec 2000 10:24:31 -0500
Received: from ellesson ([24.25.4.12]) by mail7.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.537.53);
	 Sat, 23 Dec 2000 10:24:32 -0500
Message-Id: <000c01c06cf4$7846cda0$0c041918@nc.rr.com>
From: "Ed Ellesson" <EELLESSON@nc.rr.com>
To: <policy@raleigh.ibm.com>
Cc: <ellesson@mindspring.com>
Subject: Fw: Retry:  Draft Minutes from Policy WG Sessions in San Diego
Date: Sat, 23 Dec 2000 10:24:40 -0500
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Ed Ellesson" <EELLESSON@nc.rr.com>
Content-Transfer-Encoding: 7bit

I am going to try this one more time before I call the help desk about the
server not forwarding the whole note.  Sorry for filling up people's mail
boxes!
----- Original Message -----
From: <Ed_Ellesson@tivoli.com>
To: <policy@raleigh.ibm.com>
Cc: <eellesson@nc.rr.com>
Sent: Friday, December 22, 2000 9:46 PM
Subject: Retry: Draft Minutes from Policy WG Sessions in San Diego


Hi,

[The copy of this which I received on my first try did not include anything
beyond the first paragraph of item 1.4.  I don't know why.  Here is another
attempt at sending the whole thing.]

Section 1 is from the wrap-up charts which we discussed at the end of each
session, and combines the action items from both days.  Joel and I turned
in this summary section (just Section 1), as our report to Bert on the
results of our meetings.

Section 2 is from my notes for Monday's session.

Section 3 is from my notes for Wednesday's session.

I have not reviewed Sections 2 and 3 with anyone.

Fire away.  We need to turn these in with the the charts by the end of next
week.

I have everyone's charts.  Thank you for sending them to me.  I will submit
them with the revised minutes.

*************************************

Draft Summary and Minutes
Policy Framework Working Group Meeting
49th IETF, San Diego
Submitted by Ed Ellesson, December 22, 2000

1.   Summary and Action Items, combined from both wg sessions:

1.1   QDDIM: (QOS DiffServ Device Info Model, or QOS Datapath Device Info
Model)

      -Differences with DiffServ are now resolved

      -Expect name change to the QDDIM draft to reflect generic qos datapath
focus for
       traffic handling and conditioning (ie. not just diffserv), but qos
signaling
       (control plane) will continue to be out of scope for this document.

       *  Action:  Bob Moore

      -Schedulers/Queues relationship: Expect co-author consensus to be
posted on
       the policy mailing list, in approximately two weeks.

       *  Action:  Walter Weiss

1.2   QPIM:  (QOS Policy Information Model)

       *  Action:  QPIM Authors:

      -Overlap and linkage with QDDIM: Need added text/terminology to
describe
       how/why policy objects are approached differently in QPIM, than from
       device level view in QDDIM.

      -Further clarification may be added to describe distinctions among the
       following functions:  Configuration, policy (operational behavior),
and
       state.

      -QPIM continues to be device independent, and mechanism independent.
Examples
       are needed that show the abstraction level for QPIM, including policy
vs.
       mechanism.

      -A new PCIM extensions draft will be written, which describes generic
PCIM
       functions that can be broken out separately from the current QPIM
draft
       (ie. those that are not QOS-specific.  The first phase of this was
agreed
       to be done by the current QPIM authors, themselves.

      -RSVP with diffserv in the same network. Positioning statement needed
for
       this situation.

1.3   ICIM (IPSP Configuration Information Model):

      -The content of this document is owned by the IPSP working group.

      -Our liaison with IPSP (Lee Rafalow) will take a look at similarities
with
       QPIM, to determine if there is any reason to recommend further
harmonizing
       any of the functionality there with QDDIM or QPIM approaches, such as
in
       the area of sequenced actions.

1.4   Packet classification work effort proposed:

      -Small design team will be formed to clearly document the motivations
for the
       differing approaches to packet classification across QDDIM, QPIM and
ICIM.
       This team will clearly express the design goals of each approach.

       *Action:  Volunteers to contact WG chairs

      -Consideration will be given, to converge or not, the four approaches
to
       packet classification presented by Bob Moore:

       a) single field generic (filter entry)
       b) variables/operators/values (qpim)
       c) single field specific (ipsp's icim)
       d) multi-field specific (6-tuple)

      -Consideration will be given to documenting this in the separate,
common
       document, (see above) which defines general purpose mechanisms, or to
       document why general purpose approaches are not appropriate.  These
       guidelines will be intended to guide further application of our
models
       to other domains.

      -If multiple approaches continue to exist after this design team
effort,
       mapping the methods, one to the other, will need to be documented.

1.5   Terminology Draft:

      -Expect document rev in a few weeks, then working group Last Call.

       *  Action:  Andrea

1.6   PCLS (Policy Core LDAP Schema):

      -Expect another rev with recent input from mailing list, and a new
security
       considerations section.

      *Action:  Ryan Moats, Bob Moore and Ed Ellesson.

      -Expect this document to be ready for last call next month.

1.7   MPLS Policy:

      -Authors will discuss potential homes for this work with wg chairs,
and the
       appropriate AD's . The Policy Framework wg charter does not cover
this.  As
       a general rule, it is expected that further application of the policy
model,
       beyond qos, will be accomplished within technologly-specific working
groups,
       which is where the subject matter experts are for those technical
domains.
       This is similar to the way mibs/pibs are developed.

       *  Action:  Joel will help by discussing this with the chairs and/or
AD's
          for MPLS.

1.8   Charter Milestones:

      The co-chairs will work with Bert on a new set of wg
charter-milestones, now
      that our first document (PCIM) has been approved for advancement to
Proposed
      Standard.

      *   Action:  Joel and Ed


2.   Detailed Minutes from the Monday, December 11 Session:

      -The order of the minutes is in the order of the agenda topics.

2.1   Intro/Objectives/Milestones:  Joel Halpern:

      -Welcome.  Thanks to the many authors who have worked to get drafts
for this
       meeting.

      -However, we are WAY behind schedule.

      -Particular items of note that need to be worked on include:

       a) Framework
       b) Requirements
       c) Use Cases
       d) Terminology

      -The QPIM and QDIM work has made some significant progress.  Remember:
"A
       key part of demonstrating that this model can provide end-to-end
translation
       of high-level policy specifications to device configurations is to
ensure that
       the information model and schemata are compatible with and can use
the
       information contained in the PIB(s) and MIB(s) being developed in the
       Differentiated Services WG. To this end, the Policy Framework WG will
supply
       input to the development of the PIBs, and include all applicable PIBs
and MIBs
       in its development considerations for the framework, information
model, and
       schemata." So we need to get QPIM and QDIM aligned with each other
and with the
       diffserv work.   QDIM is now much more closely aligned with diffserv
than in the
       past.  Cooperation with DiffServ here is a key goal.

       -Similarly, we need to work with the IPSP folks to align the usage of
the model
        there.  We will work to put together a new schedule.  We will be
reluctant to
        take on any new work items until the backlog has cleared.  And even
then we
        would like to get this working group wrapped up rather than
perpetually adding
        work items.

2.2   Agenda Bash.  No changes for now.  (see later changes to second day's
agenda)

2.3   QDDIM Issues Presentation:  Bob Moore

      -Bob's charts were also presented in the DiffServ working group, just
prior to
       this Policy Framework meeting.  Some of the decisions on these issues
are
       DiffServ's to make, since they are the owners of the diffserv
conceptual model,
       mib, and pib, with which we want to be consistent.

      -The word "device" was added to the title, to reflect the fact that
rsvp is no
       longer  included in the initial focus of this document.  (It proved
to be too
       hard to reach closure on both diffserv and rsvp at the same time.)

      -See the charts that Bob presented, for the details of each specific
issue.

       *   Issue 1: On whether the QDDIM Scheduler class is to be a subclass
of
           Condition:

           -It was decided that Scheduler is, indeed, to be a subclass of
            Condition.

       *   Issue 2: should scheduling disciplines be modeled as associations
or as classes?

           -Walter:  It turns out that the DiffServ MIB will not allow one
approach, but
            the conceptual model will support it.  The question  is:  should
we align with
            the mib or the informal conceptual model?

           -Andrea, Walter, John Strassner and Dave Durham all had opinions
on which was
            a better representation, and the vote among them was split.  The
decision was
            to revisit this...see the summary for the resolution.

       *   Issue 3:  How should the tail drop and head drop dropping
algorithms be
           represented?

           -The resolution is that the the DiffServ working group will
loosen the
            language in the conceptual model to allow for the dropper to be
represented
            either before or after the queue, and the MIB will be tightly
defined, as it
            is now, to include a property to describe a dropper as tail drop
or head drop.
            This leaves the policy working group clear to document the model
as we are
            doing it now.

       *   Issue 4:  Bob described a taxonomy for the four ways to represent
filters, used
           across multiple documents in our working group.

           -We will take up this topic for discussion in the Wednesday
session, after the
            ICIM presentation.

2.4   QPIM Issues Presentation:  Ron Cohen

      -QPIM includes PCIM extensions, including those that are QOS-specific
(both
       diffserv and intserv), as well as those that are useful beyond just
the QOS
       discipline.

      -See Ron's charts for a complete list of the changes from the last
draft of
       the QPIM document and for the generic and qos-specific extensions
included
       there.

      -Generic Extensions to PCIM include the modeling of variables and
values, which
       allows for the reuse of values, and for specifying value constraints,
and for
       adding new variables and values without changing the syntax.  See the
charts
       for other extensions.

      -Mapping to the DiffServ MIB is supported.

      -Reuse and "domain-wide" application of QPIM, are the primary drivers
for
       organizing the model the way it is currently.

      -Missing Pieces:

       *  a model of the "capabilities" functionality in the PIB

       *  an approach for binding roles to entities

      -Status of QPIM:  The last call on this document forced discussion,
and the
       feedback was valuable and incorporated into the current draft.

2.5   QPIM and QDDIM Compatibility with DiffServ Discussion
      Moderators:  Joel and Ed


      -On QPIM relationship to QDDIM:  This relationship is not formally
documented
       in the QPIM document.  John Strassner commented that this is a "works
with"
       relationship, rather than a "mapping" relationship, between QPIM and
QDDIM.

      -Bob Moore questioned the issue about DSCP markers not having two
values.  This
       may need to be clarified.  Also, Bob suggested not reusing the class
names
       from the QDDIM model, in the QPIM model, since that could cause
confusion.
       Ron accepted this last comment as a valid point.

      -Andrea expressed the opinion that a mapping from QPIM to QDDIM is,
indeed,
       required.  We also need to work on clarifying the "configuration" vs.
"state"
       issue.

      -It was agreed that a new PCIM extensions document would be created,
and the
       relevant parts of QPIM that are generically applicable, would be
pulled out
       and documented separately.  The QPIM authors will participate, as
well as
       volunteers, as they come forward.

       -Lee Rafalow:  Not convinced that the following aspects of QPIM are
justified:
        complexity of "atoms" approach, compound conditions, and Rules
within Rules.

       -Yoram Bernet requested that more attention be given to admission
control, and
        to those conditioning services that are in common to both intserv
and rsvp.

       -Shai Herzog questioned the level of the policy documented here...is
it
        "mechanism" or is it "policy"?

2.6   Monday's Session Wrap-up:

      -See Section 1, above, for the combined summary of both Monday and
Wednesday
       sessions


3.  Detailed Minutes from the Wednesday, December 13 Session:

3.1    Intro and News:  Changed the agenda to continue the discussion of
       Queues and Schedulers.  See the sixth item on the agenda (item 3.6,
below).

3.2   ICIM:  IPSP Policy Model Presentation, Lee Rafalow:

      -Lee suggests that we harmonize among the various document authors on
appropriate
       re-usable components for packet classification, across the several
documents
       which address this.

      -See Lee's charts for his review of the IPSP (ICIM) Model.

       *  Basic model structure

       *  Filter-based conditions

       *  Actions, Proposals, and Transforms

      -Discussion Points:

      -Differences between the multiple models that do packet classification
were
       reviewed.  Lee noted the different objectives for each model, which
motivated the
       different approaches.  See the charts.

      -Semantics of subclassed condition class, as used in the ipsp's icim
model, are
       specific to the ipsec negotiation, which can change from true to
false, as more
       info is received about the security association.  This is a different
semantic
       than in the case of QOS.

      -Grouping differences were also discussed.

      -Evaluation order is always determined ahead of time, in IPsec policy.
This is
       always mandatory, but the semantic is different from the mandatory
semantic in
       the rest of the policy model. The semantic is:  "Try this first, and
if it does
       not work try the next one."

      -Roles: As used in the policy model, roles represent a binding of
policy to
       interfaces.  This is not the appropriate semantic for IPsec, so the
PolicyRole
       object was not used.  Instead, the ipsp icim model uses
IdentityContexts.

      -The IPSP model is more oriented toward individual device policy, like
QDDIM,
       rather than the domain level, like QPIM, but the IPSP model derives
from the
       policy classes, like QPIM does.

      -Discussion:

       *  Strassner:  QPIM differences have to do with the reusability of
the classes,
          without binding to specific devices.

       *  Ron Cohen:  Sequenced actions:  There is a similar function in
QPIM, with a
          selector, for path messages.  Suggests we take a look at whether
we should
          have the same basic approach in both QPIM and IPSP's ICIM

       *  ICIM is a model for the PDP to PEP configuration function; it is
not a domain
          level model

       *  Rules are "leaf" objects in the IPSP's ICIM model

3.3  Applying and Linking Policy Discussion  (including the discussion about
packet
     classification)

     -Proposed objective:  Harmonize the reusable components across the
documents
      which describe how to represent policy for packet classification, or
clearly
      document why there are differences, due to different design points,
different
      disciplines, etc.  Are the semantics really different?

     -Walter Weiss:  Questions whether the IPSP's ICIM model should be
handling both
      levels in one model.  Conditions and Actions, can one thing be both?

     -A work effort is proposed:  mapping the different approaches, one to
the other.

     -Reuse of instances vs. reuse of classes:  this motivates some of the
differences
      in QPIM.

     -The usefulness of the QPIM "atoms" approach might drive the QPIM
method of
      representing filters, as being different from other models.  On the
other hand,
      maybe convergence of documentation is called for: perhaps a single
document which
      describes the generic approaches, and when each is called for:  single
field
      generic (filter entry), variables/operators/values (QPIM), single
field specific
      (ICIM), multi-field specific (6-tuple).

     -A separate document is proposed to split out the portion of QPIM that
documents
      functions, such as packet classification, that can be re-used across
multiple
      disciplines, with an explanation of the different approaches that
remain, if they
      do indeed remain after the attempt to harmonize them.  The current
authors of the
      QPIM document will take the lead with this effort, but volunteers are
encouraged,
      as well.  We may do this in a two-step process, with the current
authors taking
      the first shot at the generic document.

     -The MPLS needs for packet classification should also be taken into
account, since
      this is also valuable experience that we can learn from for the
purpose of coming
      up with a generic approach.

      -Example:  "Source Port = 80" appears to be in all the models.

      -There is controversy about this point:  The distinctions between QPIM
and QDDIM
       may be defensible, given the difference in their scope (network
domain-wide scope,
       vs. device level scope), but what about ICIM (the IPSP's model),
which appears to
       be device-level?   But we should be able to articulate the reason
that any
       differences remain, if we can.

      -The topic of policy languages came up.   This is not in our charter,
but Andrea
       suggested we might want to look at the language constructs developed
by Morris
       Sloman at Imperial College in London.

      -There was also a question about how SNMP handles differences in mibs.
Does the
       SNMP area directorate push back on working groups that taken
different approaches
       to the same problem?

       Bert:  Yes, the Ops and Management area pushes back on working groups
that want
       to go a different way, but the AD's are not always successful in
pushing for
       common approaches.  Despite the best of intentions,  there are mibs
that provide
       duplicate function in different ways.

       (BTW:  Wasn't Policy supposed to solve this?)

3.4   PCLS Update: (Ryan Moats and Ed Ellesson)

      -Changes for the -08 version:   Please see Ryan's charts for details.

      -Ryan reviewed the syntax changes from the previous version, as well
as other
       changes, including an issue associated with matching rules, and the
fact that
       there will be a -09 version shortly, with new aux classes, and a new
security
       considerations section.

      -Security Considerations section:  Please see Ed's charts for details.

      -Ed reviewed the security considerations which will be re-written for
the next
       version.  The challenge is to make sure that all the necessary
security
       considerations are covered, across the multiple documents which
complete the
       standardized "policy package" of documents for any specific
discipline.

      -For example, the QOS group of policy documents will include the core
policy
       documents, PCIM and PCLS, as well as the QOS-specific policy info
model (QPIM),
       and the device level info model for QOS (QDDIM), plus whatever the
appropriate
       mapping of these QOS-specific models turn out to be,  to an
LDAP-accessible
       directory.

      -The security considerations sections of all these documents taken
together, have
       to cover all the appropriate issues for applying QOS policy in a real
world
       environment.  The security considerations section of PCLS is part of
this total
       coverage.

      -Please contact Ed if you want to contribute to this section.

3.5   Polterm Harmonization:  Andrea Westerinen

      -See Andrea's charts.

      -The team which created this draft was successful in achieving its
goal:  to
       finalize common policy terminology across multiple working groups,
without creating
       new terms.

      -The team resolved the conflicting use of the term Policy Rule in
different wg's

      -Polterm draft will be revised with changes discussed in presentation
and sent to
       last call.

      -References to I-D's will be removed and maintained separately in a
cross-reference
       table linked from the policy framework working group's home page.

3.6   Queues and Schedulers:  Walter Weiss

      -See Walter's charts.  This is meant to provide a context for
continuing the
       discussion from Monday on this topic.

      -In the current QDDIM model, we have greater flexibility in
representing queues and
       schedulers than is currently available in the DiffServ mib with
SMIv2.  This was
       accepted as not being a problem, since individual vendors may extend
the DiffServ
       mib in proprietary ways, and we want the QDDIM model to be able to
map to these
       extensions, if possible, to the extent that we can anticipate them.

      -Brian Carpenter stated that the DiffServ working group's criteria for
including
       something in the DiffServ mib is that it be expressible, and that
vendors want it
       there.  Further, it should be clear that QDDIM does not drive the
content of the
       DiffServ mib.

      -There was considerable discussion of the six charts which Walter
presented, which
       described the pro's and con's of different ways of representing
queues, schedulers,
       and their relationships to each other.  This presentation and
discussion further
       clarified the issues, and will be used to help the QDDIM authors come
to an
       agreement for finalizing how that model will represent queues and
schedulers and
       their relationships.

3.7   Use of Policy in AAA Architecture:  Cees de Laat

      -See charts from Cees de Laat, at:

       http://www.phys.uu.nl/~wwwfi/aaaarch/sandiego/delaat.htm

      -Cees presented the policy work that is going on in the IRTF, under
the AAA
       Architecture working group.

      -This working group has an inter-domain focus and an architectural
focus, which
       differentiates it from the work in the policy framework working
group, in addition
       to the fact that they are working on AAA.

3.8   Use of Policy in MPLS:  Ritu Chadha and Marcus Brunner

     -Ritu presented the changes and convergence from the first drafts which
dealt with
      MPLS policy.  The authors re-used a number of the ideas for packet
filtering, roles
      and other functions, from the QDDIM and QPIM drafts.

     -Marcus presented the open issues, including the fact that MPLS policy
has not been
      accepted as a charter item by any IETF working group, including policy
framework,
      mpls, and traffic engineering.

     -Joel committed to talking to the chairs of the mpls and tewg to help
determine the
      appropriate home for this work.  It seems appropriate to host this
work where the
      subject matter experts are (mpls or tewg), with help provided from
policy liaison
      people who have experience in applying the policy information model.

3.9   Wrap-up:  See Section 1 of these minutes for the combined summary for
both sessions.




Ed Ellesson

ellesson@tivoli.com
Office at Tivoli:  919-224-2111
Office at home:  919-644-3977