From daemon@optimus.ietf.org  Fri Nov  2 16:51:03 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19650
	for <policy-archive@odin.ietf.org>; Fri, 2 Nov 2001 16:51:03 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA01135
	for policy-archive@odin.ietf.org; Fri, 2 Nov 2001 16:50:52 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00585;
	Fri, 2 Nov 2001 16:30:16 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00526
	for <policy@optimus.ietf.org>; Fri, 2 Nov 2001 16:30:12 -0500 (EST)
Received: from cosds003.continuumnetworks.com ([12.41.184.243])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19037
	for <policy@ietf.org>; Fri, 2 Nov 2001 16:30:09 -0500 (EST)
Received: from FARILJCS ([12.41.186.49]) by
          cosds003.continuumnetworks.com (Netscape Messaging Server 4.15)
          with SMTP id GM6ZPI00.81X; Fri, 2 Nov 2001 14:29:42 -0700 
Reply-To: <john.strassner@intelliden.com>
From: "John Strassner" <john.strassner@intelliden.com>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>, <policy@ietf.org>
Subject: RE: RE [Policy] Policy WG I-D Last Call  draft-ietf-policy-core-schema-12.t
Date: Fri, 2 Nov 2001 14:29:41 -0700
MIME-Version: 1.0
Message-ID: <FCEKLEHMPIHFNLCMKHAMEEDICOAA.john.strassner@intelliden.com>
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: <5.1.0.14.0.20011026104629.01701cb0@127.0.0.1>
Content-Type: multipart/signed;
	micalg=SHA1;
	protocol="application/x-pkcs7-signature";
	boundary="----=_NextPart_000_0196_01C1639E.53B5CAD0"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0196_01C1639E.53B5CAD0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Kurt,

thanks for a thorough review. I'm going to concentrate solely on the =
technical matters, and leave the other matters up to other people to =
answer. Please see inline, look for <js>..</js>. I am eliding parts of =
the message that you didn't have questions on.

I will be posting a -13 that addresses your concerns. In some cases, I =
need clarification of the problem, so it would be very helpful and =
greatly appreciated if you can reply to this message asap so that -13 =
fully addresses all of your concerns.

regards,
John

-----Original Message-----
From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of
Kurt D. Zeilenga
Sent: Saturday, October 27, 2001 3:27 PM
To: policy@ietf.org
Subject: Re: RE [Policy] Policy WG I-D Last Call
draft-ietf-policy-core-schema-12.t


John wrote:
>this is a summary of the changes made between the -11
>and the -12 versions of PCLS.
>
>1. Stability of the DMTF References
>This issue has been resolved. The DMTF web site has
>been updated, one reference has been correspondingly
>updated, and the other reference has been changed.

Though stability is an issue, I am concerned primarily with the standard =
track maturity of the referenced DMTF specifications. "DMTF LDAP Schema =
for the CIM v2.5 Core Information Model" (May 21, 2001) [10] appears to =
suffer from many of the same problems which you have recently attempted =
to address in this I-D.  I note that reference has been updated since =
May 21, 2001 and, IMO, still needs significant more work.

<js>
My only comment here is that why is it relevant that the referenced CIM =
schema suffers from problems that we fixed in this specification? We're =
not reviewing the CIM spec, we're reviewing this I-D, and if it did =
solve problems, then hopefully this I-D (when published as an RFC) will =
help the DMTF improve their spec.
</js>

Another concern I have regarding references, is that RFC 3060 depends on =
CIM Schema 2.4, yet this document depends on CIM Schema 2.5. Are there =
compatibility issues resulting from this difference?  If so, how are =
these to be resolved by the implementor?

In particular, I note that the definition of orderedCimKeys differs in =
substance (matching rules) between CIM Schema 2.4 and CIM Schema 2.5.

<js>
First, the easy question - the CIM schema doesn't define orderedCimKeys. =
This is defined in the Mapping document. And imho, the definition of =
orderedCimKeys in the Mapping document has been improved in its latest =
incarnation.

Second, that answer is crucial to answering your first question. Yes, =
RFC3060 depends on CIM 2.4, while this I-D depends on CIM 2.5. However, =
the elements in CIM 2.5 are backwards compatible with the elements in =
CIM 2.4.
</js>

... text elided...

>4. Request to Add Ordering and Substring Matching Rules
>Ordering and Substring Matching Rules have been added
>for all appropriate classes in the PCLS.

I note that the I-D makes use of matching rules
(integerOrderingMatch, octetStringOrderingMatch,
octetStringSubstringsMatch) yet provides no specification
(itself or by reference) for them.

<js>
I'm not sure what you're asking for here. If you are asking for a =
reference to the definitions of these matching rules, I'll be happy to =
add them in -13. Please tell me if this addresses your concerns.
</js>

... text elided ...

>9. 2252 Syntax Conformance
>This version of the PCLS has moved the note that
>states that the RFC2252 syntax used has been line-
>wrapped for readability to a more prominent position
>in the document.

Have you verified that the syntaxes conformed to RFC 2252? I would have =
done this myself, but my tool requires dependent schema to be properly =
defined (and those in [10] are not).

<js>
I personally have not, but one of my developers has successfully =
implemented this version on two different servers.
</js>

... text elided...

>12. Non-Normative Appendix.
>This version of the PCLS has added an explicit statement
>in the Appendix stating that the Appendix is not
>normative.

I am concerned by this statement:
        See the appendix of this document for a complete
        description of the algorithm.

as it makes it unclear where the normative description of
the algorithm can be located.

<js>
While the appendix references [10], I would be happy to add an explicit =
statement in -13 defining that [10] is the location for the normative =
description of the algorithm, both at the start of the appendix and in =
the above statement. Please tell me if this addresses your concerns.
</js>

... text elided...

>14. Constraints
>This version of the PCLS specifies additional=20
>constraints on various data types (e.g., this integer=20
>has values that are valid from 1..10) and has added=20
>text to instruct servers and applications what to do if=20
>a value outside of this range is encountered.

I note that same needs to be done for all attributes.  In
particular, you missed attributes of bitString syntax,
pcimTPCTimeOfDayMask, and likely a few others.

<js>
Good catch - I'll rework this and send out a new version to the list for =
approval as -13. I'll also note explicitly any additonal constraint =
directives that I added to simplify checking by you and others.
</js>

And when you say "the policy rule SHOULD be disabled" do
you mean "the policy rule SHOULD be treated as being disable" or is =
there some action required by an LDAP client detecting such application =
constraint violation?

<js>
Yes, I meant that the policy rule SHOULD be disabled. I'll be happy to =
add additional clarification of this to the -13 version.
</js>

... text elided...

>17. DMTF Reference Updates
>This version of the PCLS updates references [9] and
>[10] as appropriate.

[10] needs updating again.

<js>
I don't understand this comment. [10] is controlled by the DMTF. They =
haven't updated it, and I don't have the power to update it. And this =
address is the address of the latest version of the DMTF spec. What am I =
missing?
</js>

...text elided...

>20. Correction of classes vs. instances
>This version of the PCLS corrects some inaccurate
>wording in various places in the document to clarify
>when classes vs. instances are being discussed.

I note that when you say "instances of the structural classes" you =
actually mean "instances of the structural classes or their subclasses". =
 Recall:   [X.501] 8.1.19 structural object class of an entry:
   With respect to a particular entry, the single structural object =
class used to determine the DIT Content Rule and DIT Structure Rule =
applying to the entry. This object class is indicated by the =
structuralObjectClass operational attribute.
   This object class is the most subordinate object class of the =
entry=12s structural object class superclass chain.

And as this I-D provides auxiliary classes which can
be used to instanstiate policy objects, additional clarification may be =
appropriate.

<js>
Good catch, I'll add this clarification in the -13 version.
</js>

...text elided...

I've attached my review notes which may aid the editor in
improving this work.

<js>
Thanks, much appreciated
</js>

Kurt
------=_NextPart_000_0196_01C1639E.53B5CAD0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw
ggH9oAMCAQICAwSkbzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMDQxOTE5MjY0NFoXDTAyMDQxOTE5MjY0NFowTzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdam9obi5zdHJhc3NuZXJAaW50ZWxsaWRl
bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKOQF9xvr2IzkspSZ5NHATzu64yNJl1D
NVVu08Upy0q/Dvfm0/dWVRc/sg09Tr1seHcVLIjAlY6QWFJsPf5tuglzSuMPy+6bGj/mI3KSXpte
dhD5o33qc0oBnIOyn+PuqW7fpWjIJwM2MNCLr7gG1IjrchggMput4b5jq2M3zXxJAgMBAAGjOjA4
MCgGA1UdEQQhMB+BHWpvaG4uc3RyYXNzbmVyQGludGVsbGlkZW4uY29tMAwGA1UdEwEB/wQCMAAw
DQYJKoZIhvcNAQEEBQADgYEAtHVVEjLYbfAxqW9D1GxSpZYh7kWX/em+JcgXrxFom6kU3wgCrluP
F0Ce97vS4VX/TTs9x9b9YUONsEi8kqN5XLY3995FwnFgT+s2ZVljKNFoCgk4COQJ3OS2l/bZWFRc
xgR4auC8sLZmE2oxtOm1cigZMhbT8ZnKvWuBN/8q2tUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3
DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD
YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0
aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg
Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw
MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp
ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj
NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2
17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB
ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN
aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB
UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD
AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk
W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP
6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9
edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O
+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi
rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R
hGvk+NHOd6KBMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0
aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDBKRvMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTAxMTEwMjIwMDAyMFowIwYJKoZIhvcNAQkEMRYEFHfU005dXt+zwmkwDswVeZXRMWNL
MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAeyOf
Sivg/xhjRwTwiiM1XK12N0tDnDEQ6CCJbjuhM7uSiwoYiAkIouDGuyg+aJHZLUIASKYk/EJZQ1G3
n7Hmv8tgeA+7SHXoGn3t1l+yJIEVI3oKmqg0iqv921TSzm/x150AuN9YfwV6U8YA6sqZ9ovDPY4v
5xiwACCAxQIaLxoAAAAAAAA=

------=_NextPart_000_0196_01C1639E.53B5CAD0--


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



From daemon@optimus.ietf.org  Mon Nov  5 10:34:30 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24006
	for <policy-archive@odin.ietf.org>; Mon, 5 Nov 2001 10:34:30 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA13820
	for policy-archive@odin.ietf.org; Mon, 5 Nov 2001 10:34:31 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12622;
	Mon, 5 Nov 2001 10:08:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12592
	for <policy@optimus.ietf.org>; Mon, 5 Nov 2001 10:07:58 -0500 (EST)
Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22153
	for <policy@ietf.org>; Mon, 5 Nov 2001 10:07:56 -0500 (EST)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA93234;
	Mon, 5 Nov 2001 10:05:14 -0500
Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62])
	by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id fA5F6F427172;
	Mon, 5 Nov 2001 10:06:15 -0500
Subject: RE: RE [Policy] Policy WG I-D Last Call  draft-ietf-policy-core-schema-12.t
To: <john.strassner@intelliden.com>
Cc: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>, policy@ietf.org
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OF35880DA3.1C60F3D1-ON85256AFB.0052530D@raleigh.ibm.com>
From: "Robert Moore" <remoore@us.ibm.com>
Date: Mon, 5 Nov 2001 10:07:15 -0500
X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.8 |June 18, 2001) at
 11/05/2001 10:06:15 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org


[10] needs updating again.

<js>
I don't understand this comment. [10] is controlled by the DMTF. They
haven't updated it, and I don't have the power to update it. And this
address is the address of the latest version of the DMTF spec. What am I
missing?
</js>

John, I think that Kurt's point is that if you follow the link
(which indeed does still work), the document you find has a
later date than the one we cite in PCLS.  I believe that this
is just an artifact of the way that the document was formatted
for the DMTF web site.  When a new pdf file was generated
(probably in connection with the general cutover to the new
DMTF site), it picked up the current date at that time.  Maybe
Ryan can confirm that this is how it happened - i.e., that the
date is the *only* thing that changed between the May 21, 2001
version that we cite and the June 5, 2001 version that's on
the DMTF site now.

Assuming that this is the case, we can just insert the new
date into PCLS, and make sure that the DMTF tightens up this
aspect of its document handling process.

Regards,
Bob

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



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



From daemon@optimus.ietf.org  Mon Nov  5 12:39:00 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00427
	for <policy-archive@odin.ietf.org>; Mon, 5 Nov 2001 12:38:59 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA19296
	for policy-archive@odin.ietf.org; Mon, 5 Nov 2001 12:39:02 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17358;
	Mon, 5 Nov 2001 11:53:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17330
	for <policy@optimus.ietf.org>; Mon, 5 Nov 2001 11:53:11 -0500 (EST)
Received: from cosds003.continuumnetworks.com ([12.41.184.243])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28014
	for <policy@ietf.org>; Mon, 5 Nov 2001 11:53:05 -0500 (EST)
Received: from FARILJCS ([12.41.186.49]) by
          cosds003.continuumnetworks.com (Netscape Messaging Server 4.15)
          with SMTP id GMC6VC00.P20; Mon, 5 Nov 2001 09:52:24 -0700 
Reply-To: <john.strassner@intelliden.com>
From: "John Strassner" <john.strassner@intelliden.com>
To: "Robert Moore" <remoore@us.ibm.com>
Cc: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>, <policy@ietf.org>
Subject: RE: RE [Policy] Policy WG I-D Last Call  draft-ietf-policy-core-schema-12.t
Date: Mon, 5 Nov 2001 09:52:22 -0700
MIME-Version: 1.0
Message-ID: <FCEKLEHMPIHFNLCMKHAMKEGECOAA.john.strassner@intelliden.com>
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: <OF35880DA3.1C60F3D1-ON85256AFB.0052530D@raleigh.ibm.com>
Content-Type: multipart/signed;
	micalg=SHA1;
	protocol="application/x-pkcs7-signature";
	boundary="----=_NextPart_000_008E_01C165DF.90A17FA0"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_008E_01C165DF.90A17FA0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Thanks Dr. Watson ;-) I missed this completely. I'll update this for -13.

regards,
John

-----Original Message-----
From: Robert Moore [mailto:remoore@us.ibm.com]
Sent: Monday, November 05, 2001 8:07 AM
To: john.strassner@intelliden.com
Cc: Kurt D. Zeilenga; policy@ietf.org
Subject: RE: RE [Policy] Policy WG I-D Last Call
draft-ietf-policy-core-schema-12.t



[10] needs updating again.

<js>
I don't understand this comment. [10] is controlled by the DMTF. They
haven't updated it, and I don't have the power to update it. And this
address is the address of the latest version of the DMTF spec. What am I
missing?
</js>

John, I think that Kurt's point is that if you follow the link
(which indeed does still work), the document you find has a
later date than the one we cite in PCLS.  I believe that this
is just an artifact of the way that the document was formatted
for the DMTF web site.  When a new pdf file was generated
(probably in connection with the general cutover to the new
DMTF site), it picked up the current date at that time.  Maybe
Ryan can confirm that this is how it happened - i.e., that the
date is the *only* thing that changed between the May 21, 2001
version that we cite and the June 5, 2001 version that's on
the DMTF site now.

Assuming that this is the case, we can just insert the new
date into PCLS, and make sure that the DMTF tightens up this
aspect of its document handling process.

Regards,
Bob

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



------=_NextPart_000_008E_01C165DF.90A17FA0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw
ggH9oAMCAQICAwSkbzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMDQxOTE5MjY0NFoXDTAyMDQxOTE5MjY0NFowTzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdam9obi5zdHJhc3NuZXJAaW50ZWxsaWRl
bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKOQF9xvr2IzkspSZ5NHATzu64yNJl1D
NVVu08Upy0q/Dvfm0/dWVRc/sg09Tr1seHcVLIjAlY6QWFJsPf5tuglzSuMPy+6bGj/mI3KSXpte
dhD5o33qc0oBnIOyn+PuqW7fpWjIJwM2MNCLr7gG1IjrchggMput4b5jq2M3zXxJAgMBAAGjOjA4
MCgGA1UdEQQhMB+BHWpvaG4uc3RyYXNzbmVyQGludGVsbGlkZW4uY29tMAwGA1UdEwEB/wQCMAAw
DQYJKoZIhvcNAQEEBQADgYEAtHVVEjLYbfAxqW9D1GxSpZYh7kWX/em+JcgXrxFom6kU3wgCrluP
F0Ce97vS4VX/TTs9x9b9YUONsEi8kqN5XLY3995FwnFgT+s2ZVljKNFoCgk4COQJ3OS2l/bZWFRc
xgR4auC8sLZmE2oxtOm1cigZMhbT8ZnKvWuBN/8q2tUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3
DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD
YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0
aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg
Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw
MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp
ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj
NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2
17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB
ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN
aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB
UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD
AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk
W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP
6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9
edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O
+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi
rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R
hGvk+NHOd6KBMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0
aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDBKRvMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTAxMTEwNTE2NTIyMlowIwYJKoZIhvcNAQkEMRYEFKVkPuaYSRLimOjP58PUhh2lnJzz
MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAlUkn
9Mi3KacBbjmouzrJGCeIx2ooHe36dfONleSdmqqa4ijL82F3JpN8sEES0gsb/n+1OO5CG+49q3yw
Avi8lz85wTl6ybPu82TljMnFuqzOr18/Ng+U9SDrmg2ymmQbIhgZrAi6qjUkmNaMZ2hD1ING9lSB
6y4D3/8NpOqBRYoAAAAAAAA=

------=_NextPart_000_008E_01C165DF.90A17FA0--


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



From daemon@optimus.ietf.org  Mon Nov  5 22:35:39 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15216
	for <policy-archive@odin.ietf.org>; Mon, 5 Nov 2001 22:35:39 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id WAA03305
	for policy-archive@odin.ietf.org; Mon, 5 Nov 2001 22:35:42 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02799;
	Mon, 5 Nov 2001 22:05:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02770
	for <policy@optimus.ietf.org>; Mon, 5 Nov 2001 22:04:58 -0500 (EST)
Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14082
	for <policy@ietf.org>; Mon, 5 Nov 2001 22:04:53 -0500 (EST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id fA639PC85128;
	Tue, 6 Nov 2001 03:09:25 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20011105172743.016ff3e0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 05 Nov 2001 19:04:32 -0800
To: <john.strassner@intelliden.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: RE: RE [Policy] Policy WG I-D Last Call 
  draft-ietf-policy-core-schema-12.t
Cc: <policy@ietf.org>
In-Reply-To: <FCEKLEHMPIHFNLCMKHAMEEDICOAA.john.strassner@intelliden.com
 >
References: <5.1.0.14.0.20011026104629.01701cb0@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

At 01:29 PM 2001-11-02, John Strassner wrote:
>>1. Stability of the DMTF References
>>This issue has been resolved. The DMTF web site has
>>been updated, one reference has been correspondingly
>>updated, and the other reference has been changed.
>
>Though stability is an issue, I am concerned primarily with the standard track maturity of the referenced DMTF specifications. "DMTF LDAP Schema for the CIM v2.5 Core Information Model" (May 21, 2001) [10] appears to suffer from many of the same problems which you have recently attempted to address in this I-D.  I note that reference has been updated since May 21, 2001 and, IMO, still needs significant more work.
>
><js>
>My only comment here is that why is it relevant that the referenced CIM schema suffers from problems that we fixed in this specification? We're not reviewing the CIM spec, we're reviewing this I-D, and if it did solve problems, then hopefully this I-D (when published as an RFC) will help the DMTF improve their spec.
></js>

I am primarily reviewing a technical specification consisting of this
I-D and relevant portions of its normative references for technical
errors and omissions.  I noted the concerns and/or issues I found
in my brief review of the reference as I believe they are relevant
to the actions under consideration.

>Another concern I have regarding references, is that RFC 3060 depends on CIM Schema 2.4, yet this document depends on CIM Schema 2.5. Are there compatibility issues resulting from this difference?  If so, how are these to be resolved by the implementor?
>
>In particular, I note that the definition of orderedCimKeys differs in substance (matching rules) between CIM Schema 2.4 and CIM Schema 2.5.
>
><js>
>First, the easy question - the CIM schema doesn't define orderedCimKeys. This is defined in the Mapping document.  And imho, the definition of orderedCimKeys in the Mapping document has been improved in its latest incarnation.

Please update the I-D such that you reference the appropriate technical
specification for orderedCimKeys and other elements of schema which the
I-D depends upon.

>Second, that answer is crucial to answering your first question. Yes, RFC3060 depends on CIM 2.4, while this I-D depends on CIM 2.5. However, the elements in CIM 2.5 are backwards compatible with the elements in CIM 2.4.
></js>

>>4. Request to Add Ordering and Substring Matching Rules
>>Ordering and Substring Matching Rules have been added
>>for all appropriate classes in the PCLS.
>
>I note that the I-D makes use of matching rules
>(integerOrderingMatch, octetStringOrderingMatch,
>octetStringSubstringsMatch) yet provides no specification
>(itself or by reference) for them.
>
><js>
>I'm not sure what you're asking for here.  If you are asking for a reference to the definitions of these matching rules, I'll be happy to add them in -13. Please tell me if this addresses your concerns.
></js>

If the reference has appropriate technical maturity and otherwise meets
RFC 2026 requirements, yes.

>>9. 2252 Syntax Conformance
>>This version of the PCLS has moved the note that
>>states that the RFC2252 syntax used has been line-
>>wrapped for readability to a more prominent position
>>in the document.
>
>Have you verified that the syntaxes conformed to RFC 2252? I would have done this myself, but my tool requires dependent schema to be properly defined (and those in [10] are not).
>
><js>
>I personally have not, but one of my developers has successfully implemented this version on two different servers.
></js>

Was this developer able to use the 2252 descriptions without modification
(other than to remove the line wrapping)?

Until the DMTF fixes the dependent schema descriptions, this document's
schema descriptions will not pass validation tests by my tool.

>>12. Non-Normative Appendix.
>>This version of the PCLS has added an explicit statement
>>in the Appendix stating that the Appendix is not
>>normative.
>
>I am concerned by this statement:
>        See the appendix of this document for a complete
>        description of the algorithm.
>
>as it makes it unclear where the normative description of
>the algorithm can be located.
>
><js>
>While the appendix references [10], I would be happy to add an explicit statement in -13 defining that [10] is the location for the normative description of the algorithm, both at the start of the appendix and in the above statement. Please tell me if this addresses your concerns.
></js>

Yes.

>... text elided...
>
>>14. Constraints
>>This version of the PCLS specifies additional 
>>constraints on various data types (e.g., this integer 
>>has values that are valid from 1..10) and has added 
>>text to instruct servers and applications what to do if 
>>a value outside of this range is encountered.
>
>I note that same needs to be done for all attributes.  In
>particular, you missed attributes of bitString syntax,
>pcimTPCTimeOfDayMask, and likely a few others.
>
><js>
>Good catch - I'll rework this and send out a new version to the list for approval as -13. I'll also note explicitly any additonal constraint directives that I added to simplify checking by you and others.
></js>
>
>And when you say "the policy rule SHOULD be disabled" do
>you mean "the policy rule SHOULD be treated as being disable" or is there some action required by an LDAP client detecting such application constraint violation?
>
><js>
>Yes, I meant that the policy rule SHOULD be disabled. I'll be happy to add additional clarification of this to the -13 version.
></js>

Please do clarify as I'm not sure what "the policy rule SHOULD be disabled" means
(though I think I understand what "the policy rule SHOULD be treated as being disable"
means).

>... text elided...
>
>>17. DMTF Reference Updates
>>This version of the PCLS updates references [9] and
>>[10] as appropriate.
>
>[10] needs updating again.
>
><js>
>I don't understand this comment. [10] is controlled by the DMTF. They haven't updated it, and I don't have the power to update it. And this address is the address of the latest version of the DMTF spec. What am I missing?
></js>

See Bob's note.

>...text elided...
>
>>20. Correction of classes vs. instances
>>This version of the PCLS corrects some inaccurate
>>wording in various places in the document to clarify
>>when classes vs. instances are being discussed.
>
>I note that when you say "instances of the structural classes" you actually mean "instances of the structural classes or their subclasses".  Recall:   [X.501] 8.1.19 structural object class of an entry:
>   With respect to a particular entry, the single structural object class used to determine the DIT Content Rule and DIT Structure Rule applying to the entry. This object class is indicated by the structuralObjectClass operational attribute.
>   This object class is the most subordinate object class of the entrys structural object class superclass chain.
>
>And as this I-D provides auxiliary classes which can
>be used to instanstiate policy objects, additional clarification may be appropriate.
>
><js>
>Good catch, I'll add this clarification in the -13 version.
></js>
>
>...text elided...
>
>I've attached my review notes which may aid the editor in
>improving this work.
>
><js>
>Thanks, much appreciated
></js>
>
>Kurt


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



From daemon@optimus.ietf.org  Thu Nov  8 01:22:36 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06130
	for <policy-archive@odin.ietf.org>; Thu, 8 Nov 2001 01:22:35 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA21925
	for policy-archive@odin.ietf.org; Thu, 8 Nov 2001 01:22:36 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17048;
	Thu, 8 Nov 2001 01:07:31 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16999
	for <policy@optimus.ietf.org>; Thu, 8 Nov 2001 01:07:28 -0500 (EST)
Received: from catcha.com (pokemon.catcha.com [202.160.235.228])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04425
	for <policy@ietf.org>; Thu, 8 Nov 2001 01:07:26 -0500 (EST)
From: deepblueman@catcha.com
Received: (qmail 27482 invoked by uid 1002); 8 Nov 2001 06:04:01 -0000
To: policy@ietf.org
Message-ID: <1005199441.3bea2051e3740@pokemon.catcha.com>
Date: Thu, 08 Nov 2001 14:04:01 +0800 (SGT)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: JOANNA PHP IMAP webmail program 2.2.5
Content-Transfer-Encoding: 8bit
Subject: [Policy] test
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org
Content-Transfer-Encoding: 8bit



-----------------------------------------------------------------------------
This mail is sent through: Catcha.com

Get your FREE Email from Catcha! http://mail.catcha.com

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



From daemon@optimus.ietf.org  Thu Nov  8 16:37:51 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08615
	for <policy-archive@odin.ietf.org>; Thu, 8 Nov 2001 16:37:50 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA17662
	for policy-archive@odin.ietf.org; Thu, 8 Nov 2001 16:37:52 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16988;
	Thu, 8 Nov 2001 16:11:17 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16958
	for <policy@optimus.ietf.org>; Thu, 8 Nov 2001 16:11:16 -0500 (EST)
Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07935
	for <policy@ietf.org>; Thu, 8 Nov 2001 16:11:12 -0500 (EST)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA43182
	for <policy@ietf.org>; Thu, 8 Nov 2001 15:08:38 -0600
Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62])
	by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id fA8L9vL99260
	for <policy@ietf.org>; Thu, 8 Nov 2001 16:09:57 -0500
To: policy@ietf.org
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OFB79D0F09.EBDDF829-ON85256AFE.0073D4F0@raleigh.ibm.com>
From: "Robert Moore" <remoore@us.ibm.com>
Date: Thu, 8 Nov 2001 16:11:07 -0500
X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.8 |June 18, 2001) at
 11/08/2001 04:09:57 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: [Policy] PCIMe: Doh!
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

In the course of doing our QPIM update, we discovered
an error in PCIMe-05, where, following Homer Simpson,
all we can say is "Doh!"  Here's the error and the
fix:

Section 5.12.9 defines the variable class PolicyIPToSVariable.
The ALLOWED VALUE TYPES clause is in error.

Change this line:

- PolicyIntegerValue (0..7)

to this:

- PolicyIntegerValue (0..255)

It's easy to see how this error happened.  We were thinking
"TOS octet = 8 bits = (0..7)", but we put this range on the
integer value (Doh!), where, coincidentally, it could be
read to refer to just the 3 precedence bits from the TOS
octet.

Since this is just fixing an editorial oversight in the
document, I don't think we need to do anything more than
just fix it, and let Bert take the corrected document
forward to the IESG as planned.  Consequently, I've
produced a PCIMe-06 draft with this one change, and
submitted it to the Internet-Drafts repository.  It will
probably show up there tomorrow.

Regards,
Bob

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



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



From daemon@optimus.ietf.org  Thu Nov  8 18:25:24 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11299
	for <policy-archive@odin.ietf.org>; Thu, 8 Nov 2001 18:25:24 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA19663
	for policy-archive@odin.ietf.org; Thu, 8 Nov 2001 18:25:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19486;
	Thu, 8 Nov 2001 18:09:39 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19457
	for <policy@optimus.ietf.org>; Thu, 8 Nov 2001 18:09:37 -0500 (EST)
Received: from cosds003.continuumnetworks.com ([12.41.184.243])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11094
	for <policy@ietf.org>; Thu, 8 Nov 2001 18:09:33 -0500 (EST)
Received: from FARILJCS ([12.41.186.49]) by
          cosds003.continuumnetworks.com (Netscape Messaging Server 4.15)
          with SMTP id GMI8B000.F3Y; Thu, 8 Nov 2001 16:09:00 -0700 
Reply-To: <john.strassner@intelliden.com>
From: "John Strassner" <john.strassner@intelliden.com>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Cc: <policy@ietf.org>
Subject: RE: RE [Policy] Policy WG I-D Last Call   draft-ietf-policy-core-schema-12.t
Date: Thu, 8 Nov 2001 16:08:59 -0700
MIME-Version: 1.0
Message-ID: <FCEKLEHMPIHFNLCMKHAMOEMGCOAA.john.strassner@intelliden.com>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-Type: multipart/signed;
	micalg=SHA1;
	protocol="application/x-pkcs7-signature";
	boundary="----=_NextPart_000_0044_01C1686D.68F73540"
Importance: Normal
In-Reply-To: <5.1.0.14.0.20011105172743.016ff3e0@127.0.0.1>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0044_01C1686D.68F73540
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

please see inline, look for <js2>..</js2>

regards,
John

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Monday, November 05, 2001 8:05 PM
To: john.strassner@intelliden.com
Cc: policy@ietf.org
Subject: RE: RE [Policy] Policy WG I-D Last Call
draft-ietf-policy-core-schema-12.t


At 01:29 PM 2001-11-02, John Strassner wrote:
>>1. Stability of the DMTF References
>>This issue has been resolved. The DMTF web site has
>>been updated, one reference has been correspondingly
>>updated, and the other reference has been changed.
>
>Though stability is an issue, I am concerned primarily with the standard
track maturity of the referenced DMTF specifications. "DMTF LDAP Schema
for the CIM v2.5 Core Information Model" (May 21, 2001) [10] appears to
suffer from many of the same problems which you have recently attempted to
address in this I-D.  I note that reference has been updated since May 21,
2001 and, IMO, still needs significant more work.
>
><js>
>My only comment here is that why is it relevant that the referenced CIM
schema suffers from problems that we fixed in this specification? We're
not reviewing the CIM spec, we're reviewing this I-D, and if it did solve
problems, then hopefully this I-D (when published as an RFC) will help the
DMTF improve their spec.
></js>

I am primarily reviewing a technical specification consisting of this I-D
and relevant portions of its normative references for technical errors and
omissions.  I noted the concerns and/or issues I found in my brief review
of the reference as I believe they are relevant to the actions under
consideration.

<js2>
This I-D has as its root the DMTF spec, but as you note, this I-D corrects
some problems found in the DMTF spec. I would expect the changes in this
I-D to be reflected in a future version of the DMTF spec. That being said,
I don't see how this affects this I-D.
</js2>

>Another concern I have regarding references, is that RFC 3060 depends on
CIM Schema 2.4, yet this document depends on CIM Schema 2.5. Are there
compatibility issues resulting from this difference?  If so, how are these
to be resolved by the implementor?
>
>In particular, I note that the definition of orderedCimKeys differs in
substance (matching rules) between CIM Schema 2.4 and CIM Schema 2.5.
>
><js>
>First, the easy question - the CIM schema doesn't define orderedCimKeys.
This is defined in the Mapping document.  And imho, the definition of
orderedCimKeys in the Mapping document has been improved in its latest
incarnation.

Please update the I-D such that you reference the appropriate technical
specification for orderedCimKeys and other elements of schema which the
I-D depends upon.

<js2>
The URL was right, the date in the reference was wrong and will be fixed.
</js2>

>Second, that answer is crucial to answering your first question. Yes,
RFC3060 depends on CIM 2.4, while this I-D depends on CIM 2.5. However,
the elements in CIM 2.5 are backwards compatible with the elements in CIM
2.4.
></js>

>>4. Request to Add Ordering and Substring Matching Rules
>>Ordering and Substring Matching Rules have been added
>>for all appropriate classes in the PCLS.
>
>I note that the I-D makes use of matching rules
>(integerOrderingMatch, octetStringOrderingMatch,
>octetStringSubstringsMatch) yet provides no specification
>(itself or by reference) for them.
>
><js>
>I'm not sure what you're asking for here.  If you are asking for a
reference to the definitions of these matching rules, I'll be happy to add
them in -13. Please tell me if this addresses your concerns.
></js>

If the reference has appropriate technical maturity and otherwise meets
RFC 2026 requirements, yes.

<js2>
Yes they do and yes they will be added
</js2>

>>9. 2252 Syntax Conformance
>>This version of the PCLS has moved the note that
>>states that the RFC2252 syntax used has been line-
>>wrapped for readability to a more prominent position
>>in the document.
>
>Have you verified that the syntaxes conformed to RFC 2252? I would have
done this myself, but my tool requires dependent schema to be properly
defined (and those in [10] are not).
>
><js>
>I personally have not, but one of my developers has successfully
implemented this version on two different servers.
></js>

Was this developer able to use the 2252 descriptions without modification
(other than to remove the line wrapping)?

Until the DMTF fixes the dependent schema descriptions, this document's
schema descriptions will not pass validation tests by my tool.

<js2>
The delay in responding to you was caused by this question. The answer is
yes, for this I-D, and no, for the DMTF spec. However, the developers were
able to build a running impementation.
</js2>

>>12. Non-Normative Appendix.
>>This version of the PCLS has added an explicit statement
>>in the Appendix stating that the Appendix is not
>>normative.
>
>I am concerned by this statement:
>        See the appendix of this document for a complete
>        description of the algorithm.
>
>as it makes it unclear where the normative description of
>the algorithm can be located.
>
><js>
>While the appendix references [10], I would be happy to add an explicit
statement in -13 defining that [10] is the location for the normative
description of the algorithm, both at the start of the appendix and in the
above statement. Please tell me if this addresses your concerns.
></js>

Yes.

>... text elided...
>
>>14. Constraints
>>This version of the PCLS specifies additional
>>constraints on various data types (e.g., this integer
>>has values that are valid from 1..10) and has added
>>text to instruct servers and applications what to do if
>>a value outside of this range is encountered.
>
>I note that same needs to be done for all attributes.  In
>particular, you missed attributes of bitString syntax,
>pcimTPCTimeOfDayMask, and likely a few others.
>
><js>
>Good catch - I'll rework this and send out a new version to the list for
approval as -13. I'll also note explicitly any additonal constraint
directives that I added to simplify checking by you and others.
></js>
>
>And when you say "the policy rule SHOULD be disabled" do
>you mean "the policy rule SHOULD be treated as being disable" or is there
some action required by an LDAP client detecting such application
constraint violation?
>
><js>
>Yes, I meant that the policy rule SHOULD be disabled. I'll be happy to
add additional clarification of this to the -13 version.
></js>

Please do clarify as I'm not sure what "the policy rule SHOULD be
disabled" means (though I think I understand what "the policy rule SHOULD
be treated as being disable" means).

<js2>
OK
<.js2>

>... text elided...
>
>>17. DMTF Reference Updates
>>This version of the PCLS updates references [9] and
>>[10] as appropriate.
>
>[10] needs updating again.
>
><js>
>I don't understand this comment. [10] is controlled by the DMTF. They
haven't updated it, and I don't have the power to update it. And this
address is the address of the latest version of the DMTF spec. What am I
missing?
></js>

See Bob's note.

<js2>
Got it...
</js2>

>...text elided...
>
>>20. Correction of classes vs. instances
>>This version of the PCLS corrects some inaccurate
>>wording in various places in the document to clarify
>>when classes vs. instances are being discussed.
>
>I note that when you say "instances of the structural classes" you
actually mean "instances of the structural classes or their subclasses".
Recall:   [X.501] 8.1.19 structural object class of an entry:
>   With respect to a particular entry, the single structural object class
used to determine the DIT Content Rule and DIT Structure Rule applying to
the entry. This object class is indicated by the structuralObjectClass
operational attribute.
>   This object class is the most subordinate object class of the entrys
structural object class superclass chain.
>
>And as this I-D provides auxiliary classes which can
>be used to instanstiate policy objects, additional clarification may be
appropriate.
>
><js>
>Good catch, I'll add this clarification in the -13 version.
></js>
>
>...text elided...
>
>I've attached my review notes which may aid the editor in
>improving this work.
>
><js>
>Thanks, much appreciated
></js>
>
>Kurt


------=_NextPart_000_0044_01C1686D.68F73540
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9jCCApQw
ggH9oAMCAQICAwSkbzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMDQxOTE5MjY0NFoXDTAyMDQxOTE5MjY0NFowTzEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEsMCoGCSqGSIb3DQEJARYdam9obi5zdHJhc3NuZXJAaW50ZWxsaWRl
bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKOQF9xvr2IzkspSZ5NHATzu64yNJl1D
NVVu08Upy0q/Dvfm0/dWVRc/sg09Tr1seHcVLIjAlY6QWFJsPf5tuglzSuMPy+6bGj/mI3KSXpte
dhD5o33qc0oBnIOyn+PuqW7fpWjIJwM2MNCLr7gG1IjrchggMput4b5jq2M3zXxJAgMBAAGjOjA4
MCgGA1UdEQQhMB+BHWpvaG4uc3RyYXNzbmVyQGludGVsbGlkZW4uY29tMAwGA1UdEwEB/wQCMAAw
DQYJKoZIhvcNAQEEBQADgYEAtHVVEjLYbfAxqW9D1GxSpZYh7kWX/em+JcgXrxFom6kU3wgCrluP
F0Ce97vS4VX/TTs9x9b9YUONsEi8kqN5XLY3995FwnFgT+s2ZVljKNFoCgk4COQJ3OS2l/bZWFRc
xgR4auC8sLZmE2oxtOm1cigZMhbT8ZnKvWuBN/8q2tUwggMpMIICkqADAgECAgEMMA0GCSqGSIb3
DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD
YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0
aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg
Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMw
MDAwMDAwWhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp
ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMw
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpj
NSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL2
17CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIB
ADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN
aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvB
UFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqAD
AgECAgEAMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRk
W3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP
6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9
edvlWsQcuQIDAQABoxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O
+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyi
rNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1R
hGvk+NHOd6KBMYICqjCCAqYCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0
aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDBKRvMAkGBSsOAwIaBQCgggFlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTAxMTEwODIyNTI0NlowIwYJKoZIhvcNAQkEMRYEFGXEpWYf/LxnKLS8VjvL8PLoON6u
MFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIx
CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBKRvMA0GCSqGSIb3DQEBAQUABIGAh9cw
TIN5R6sl4t93A5qEXYeMKp0MDZtQMRf7EndczPQy0231ZPPhRv3ccTfSPqqqFPXHrigGQvWBRNZj
ZsJjec3eLG47f2jzNK1AnzOZ+Oqmd/wQvVk3me8ZMjrgkum1thWyjm4M0Jvz/hZKZu3azroVYX8T
CvSK+6UMsKDZEosAAAAAAAA=

------=_NextPart_000_0044_01C1686D.68F73540--


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



From daemon@optimus.ietf.org  Mon Nov 12 06:53:51 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24887
	for <policy-archive@odin.ietf.org>; Mon, 12 Nov 2001 06:53:51 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA29844
	for policy-archive@odin.ietf.org; Mon, 12 Nov 2001 06:53:52 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29336;
	Mon, 12 Nov 2001 06:28:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29307
	for <policy@optimus.ietf.org>; Mon, 12 Nov 2001 06:28:04 -0500 (EST)
Received: from duck.doc.ic.ac.uk (duck.doc.ic.ac.uk [146.169.1.46])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24698
	for <policy@ietf.org>; Mon, 12 Nov 2001 06:28:02 -0500 (EST)
Received: from rhomaleo.doc.ic.ac.uk ([146.169.14.39])
	by duck.doc.ic.ac.uk with esmtp (Exim 3.16 #7)
	id 163FFy-0004jH-00
	for policy@ietf.org; Mon, 12 Nov 2001 11:28:02 +0000
Message-Id: <5.1.0.14.2.20011112112728.05e27960@pop.doc.ic.ac.uk>
X-Sender: mss@pop.doc.ic.ac.uk
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 12 Nov 2001 11:28:27 +0000
To: policy@ietf.org
From: Morris Sloman <m.sloman@doc.ic.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [Policy] Reminder Policy 2002 Call for Papers
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org



(Please accept our apologies if you receive duplicates of this message)

                POLICY 2002 - 1st Call for Papers
	
          IEEE 3rd International Workshop on Policies
            for Distributed Systems and Networks

                       5-7 June, 2002

      Hosted by the Naval Postgraduate School, Monterey, USA


              URL: http://www.policy-workshop.org/2002/

Contents

    1. Call for Papers       5. Paper Submission   9.  POLICY SIG Mailing
    2. Organising Committee  6. Dates                  List
    3. Program Committee     7. Special Event      10. SACMAT 2002
    4. Workshop Format       8. POLICY 2001 & 1999

1. Call for Papers

    Policy-based systems continue to be the subject of a wide range of
    activities in universities, standardization bodies and within
    industry.  They have a wide spectrum of applicability ranging from
    systems management, to quality of service adaptation, to security
    and enterprise modelling.  POLICY 2002 is the 3rd in a successful
    series of workshops, which since 1999 has brought together leading
    researchers and industry experts to discuss problems, solutions
    and experiences in developing policy-based systems. In order to
    encourage greater interaction with other communities, POLICY 2002
    will be co-located with SACMAT 2002 (3-4 June 2002) and attendees
    will have the opportunity to register for both conferences.

    POLICY 2002 invites contributions on all aspects of policy-based
    computing.  Papers must describe original work and must not have
    been accepted or submitted for publication elsewhere. Submitted
    papers will be evaluated for technical contribution, originality,
    and significance.  Topics of interest include, but are not limited
    to the following:

    * processes, methodologies, and tools for discovering, specifying,
      reasoning about, and refining policy
    * abstractions and languages for policy specification
    * policy models for access-control, systems management, QoS
      adaptation, intrusion detection, privacy
    * policy based networking
    * policy frameworks for active networks, mobile systems, e-commerce
    * implementation models and techniques
    * integrating policies into existing systems and environments
    * provisioning of policies
    * business rules and organizational modelling
    * trust models and trust management
    * extensions and refinements to policy standards
    * case studies of applying policy-based technologies

2. Organising Committee

    General Chair
      J. Bret Michael      Naval Postgraduate School, USA
                           bmichael@cs.nps.navy.mil

    Local Arrangements Chair
      Joe Puett            Naval Postgraduate School, USA
                           jfpuett@nps.navy.mil

    Finance Chair
      Takeo Hamada         Fujitsu Labs of America, USA
                           thamada@fla.fujitsu.com

    Program Co-Chairs
      Jorge Lobo           Teltier Technologies, USA
                           jorge@teltier.com

      Naranker Dulay       Imperial College, UK
                           nd@doc.ic.ac.uk

3. Program Committee

      Mark Bearden         Avaya Labs, USA
      Elisa Bertino        University of Milano, Italy
      Jeff Bradshaw        University of West Florida, USA
      Jan Chomicki         University at Buffalo, USA
      Frederic Cuppens     ONERA/DTIM, France
      Herve Debar          France Telecom, France
      Petre Dini           Concordia University & Cisco Systems, Canada
      Paulo Ferreira       INESC, Portugal
      Francisco Garcia     Agilent Laboratories, UK
      Virgil Gligor        University of Maryland, USA
      Peter Linington      University of Kent, UK
      Hanan Lutfiyya       University of Western Ontario, Canada
      Emil Lupu            Imperial College, UK
      Ian Marshall         BTexact Technologies, UK
      Zoran Milosevic      DSTC, Australia
      Naftaly Minksy       Rutgers University, USA
      Ken Moody            Cambridge University, UK
      Jonathan Moffett     University of York, UK
      Ravi Sandhu          George Mason University, USA
      Herve Schauer        HSC, France
      Edgar Sibley         George Mason University, USA
      Morris Sloman        Imperial College, UK
      John Strassner       IntelliDEN, USA
      Shel Sutton          MITRE, USA
      V.S. Subrahmanian    University of Maryland, USA
      Aad van Moorsel      HP Labs, USA
      Vijay Varadharajan   Macquarie University, Australia
      Dinesh Verma         IBM T.J. Watson Research Center, USA
      Andrea Westerinen    Cisco, USA


4. Workshop Format

    The workshop will include both refereed papers and invited
    presentations which will be published by IEEE Press. In line with
    past workshops there will be substantial time allocated for
    discussions as well as panel sessions.

5. Paper Submission

    Submitted papers must describe original work and must not have been
    accepted or submitted for publication elsewhere. Submitted papers
    will be evaluated for technical contribution, originality, and
    significance. Accepted papers will be included in the Workshop
    Proceedings and published by IEEE CS Press. Submitted papers should
    adhere to the IEEE format and not exceed 12 pages (see
    http://www.computer.org/cspress/instruct.htm for details of IEEE's
    format). Papers will be reviewed by at least 3 international experts
    and reviewers comments returned to authors after refereeing.
    Authors are requested to submit papers in electronic PDF or
    Postscript format. Details of submission procedures to follow.

6. Dates

    Paper Submission by       7 December 2001
    Notification to Authors   5 February 2002
    Camera Ready by           5 March 2002
    Workshop                  5-7 June 2002

7. Special Event

    The workshop dinner will be held at the Monterey Bay Aquarium.
    During that evening there will be a fish-feeding show at the Kelp
    Forest Exhibit.  Workshop attendees will have access to the entire
    Aquarium for approximately two and a half hours.

8. POLICY 2001 & POLICY 1999

    Two very successful workshops have been held:

    POLICY 2001 at http://www-dse.doc.ic.ac.uk/events/policy-2001/

      The Proceedings of POLICY 2001 are published in:

      Policies for Distributed Systems and Networks (POLICY 2001),
      Edited by M. Sloman, J. Lobo, and E. Lupu, Lecture Notes in
      Computer Science.  Volume 1995. Springer Verlag, ISBN 3-540-41610-2

    POLICY 1999 at http://www-dse.doc.ic.ac.uk/events/policy-99/

      Papers and presentations from POLICY 1999 can be downloaded from:

      http://www-dse.doc.ic.ac.uk/events/policy-99/program.html

9. POLICY SIG Mailing List

    Subscribe to the POLICY SIG mailing list at:

      http://www2.doc.ic.ac.uk/mailman/listinfo.cgi/policy-sig

10. SACMAT 2002

    POLICY 2002 will be co-located with SACMAT 2002 (The 7th ACM
    Symposium on Access Control Models and Technologies). SACMAT 2002
    will be held on June 3-4, POLICY 2002 will follow on June 5-7. It
    is expected that attendees of both events will receive a discount.

    See http://www.acm.org/sigsac/sacmat2002.html for further details
    on SACMAT 2002


______________________________________________________

Professor Morris Sloman
Imperial College of Science Technology and Medicine
Department of Computing
180 Queen's Gate
London SW7 2BZ, U.K.
Phone: +44 20 7594 8279    Fax: +44 20 7594 8282
Email: m.sloman@doc.ic.ac.uk
WWW: http://www.doc.ic.ac.uk/~mss



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



From daemon@optimus.ietf.org  Mon Nov 12 07:18:33 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25798
	for <policy-archive@odin.ietf.org>; Mon, 12 Nov 2001 07:18:33 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA00999
	for policy-archive@odin.ietf.org; Mon, 12 Nov 2001 07:18:35 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00329;
	Mon, 12 Nov 2001 07:03:01 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00295
	for <policy@optimus.ietf.org>; Mon, 12 Nov 2001 07:02:59 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25207;
	Mon, 12 Nov 2001 07:02:56 -0500 (EST)
Message-Id: <200111121202.HAA25207@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: policy@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Mon, 12 Nov 2001 07:02:56 -0500
Subject: [Policy] I-D ACTION:draft-ietf-policy-pcim-ext-06.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Policy Framework Working Group of the IETF.

	Title		: Policy Core Information Model Extensions
	Author(s)	: B. Moore et al.
	Filename	: draft-ietf-policy-pcim-ext-06.txt
	Pages		: 85
	Date		: 09-Nov-01
	
This document proposes a number of changes to the Policy Core Information Model (PCIM, RFC 3060).  These changes include both extensions of PCIM into areas that it did not previously cover, and changes to the existing PCIM classes and associations.  Both sets of changes are done in a way that, to the extent possible, preserves interoperability with implementations of the original PCIM model.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-policy-pcim-ext-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-policy-pcim-ext-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-policy-pcim-ext-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011109132641.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-policy-pcim-ext-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-policy-pcim-ext-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011109132641.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Mon Nov 12 07:33:12 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26250
	for <policy-archive@odin.ietf.org>; Mon, 12 Nov 2001 07:33:12 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA01624
	for policy-archive@odin.ietf.org; Mon, 12 Nov 2001 07:33:14 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00834;
	Mon, 12 Nov 2001 07:14:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00804
	for <policy@optimus.ietf.org>; Mon, 12 Nov 2001 07:14:04 -0500 (EST)
Received: from comex1.hkcg.com (comex1.hkcg.com [202.84.208.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25606
	for <policy@ietf.org>; Mon, 12 Nov 2001 07:14:01 -0500 (EST)
Received: by COMEX1 with Internet Mail Service (5.5.2653.19)
	id <V7T1VK5L>; Mon, 12 Nov 2001 20:13:59 +0800
Message-ID: <B3C3D3ED61A3D511B6FA00508B5EEDC8587CB8@comex4>
From: System Attendant <COMEX4-SA@hkcg.com>
To: "'policy@ietf.org'" <policy@ietf.org>
Date: Mon, 12 Nov 2001 20:13:52 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [Policy] ScanMail Message: To Recipient virus found and action taken.
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

ScanMail for Microsoft Exchange has detected virus-infected attachment(s).

Sender = Internet-Drafts@ietf.org
Recipient(s) = policy@ietf.org
Subject = [Policy] I-D ACTION:draft-ietf-policy-pcim-ext-06.txt
Scanning Time = 11/12/2001 20:13:51

Action on virus found:
The attachment draft-ietf-policy-pcim-ext-06.url matched file blocking
settings. ScanMail has Deleted it. 

Warning to recipient. ScanMail has removed an attachment which contains
virus or blocked file type!  If this mail is from Internet, the sender don't
know his/her attachment has been removed.  Please ask the sender to clean
and re-send or remove the blocked attachment.

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



From daemon@optimus.ietf.org  Wed Nov 14 01:37:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03805
	for <policy-archive@odin.ietf.org>; Wed, 14 Nov 2001 01:37:23 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA14530
	for policy-archive@odin.ietf.org; Wed, 14 Nov 2001 01:37:24 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA13691;
	Wed, 14 Nov 2001 01:22:15 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA13655
	for <policy@optimus.ietf.org>; Wed, 14 Nov 2001 01:22:12 -0500 (EST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01712;
	Wed, 14 Nov 2001 01:22:10 -0500 (EST)
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fAE6Lfn12278;
	Tue, 13 Nov 2001 22:21:41 -0800 (PST)
Received: from ANDREAWW2K ([128.107.131.45])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with SMTP id AAT55617;
	Tue, 13 Nov 2001 22:21:38 -0800 (PST)
From: "Andrea Westerinen" <andreaw@cisco.com>
To: <dan@dma.isg.mot.com>, "Diffserv@Ietf. Org" <diffserv@ietf.org>
Cc: "Policy@Ietf. Org" <policy@ietf.org>,
        "Bert Wijnen \(Bert\)" <bwijnen@lucent.com>
Date: Tue, 13 Nov 2001 22:24:17 -0800
Message-ID: <GGEOLLMKEOKMFKADFNHOOEKMEFAA.andreaw@cisco.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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Policy] FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org
Content-Transfer-Encoding: 7bit

Dan, I was asked to do a review of the "new-terms" draft wrt PolTerm.  In
general, there is good correspondence, but I have a few minor comments.

1. In Section 2, in the second paragraph, it would be helpful to reference
the Policy Terminology RFC XXX (draft-ietf-policy-terminology-04.txt,
waiting in the editor's queue) explicitly, since that supports your
conclusions of SLAs being of a contractual nature.

2. The SLS definition in "new-terms" is a bit different (more restrictive)
than the definition in PolTerm.  The PolTerm definition tries to straddle
the contractual versus service/conditioning aspects of an SLS.  PolTerm
states that an SLS ...
        Specifies handling of customer's traffic by a network
        provider. It is negotiated between a customer and the
        provider, and (for example) in a DiffServ environment,
        defines parameters such as specific Code Points and the
        Per-Hop-Behavior, profile characteristics and treatment of
        the traffic for those Code Points. An SLS is a specific SLA
        (a negotiated agreement) and its SLOs (the individual
        metrics and operational data to enforce) to guarantee
        quality of service for network traffic.
It might be valuable to mention that the "new-terms" definition further
restricts that specified in PolTerm, for the DiffServ environment.

3. In the last paragraph of Section 2, where you quote from the PolTerm RFC,
could you make this a normative reference?

4. In the last sentence of Section 2, you say "Therefore, the relationship
between an SLS and a service provisioning policy is that the latter is, in
part, the set of rules that define the parameters and range of values that
may be in the former."  Would it be reasonable to say "... define and manage
to the parameters and range of values ..."?  The word "define" seems too
restrictive.

And, a few nits:
5. There are several weird quotation marks in the Status (``work in
progress'' and ``1id-abstracts.txt'').

6. In Section 6, there are a few typos...
'Hence the imperitive was"SHOULD" rather than "SHALL"' - should be
"imperative" and needs a space after "was"
'An egress DS-node at the edge of one DS-domain forwards packets an ingress
DS-node at the edge of another DS domain.' - needs a "to" after "forwards
packets"

7. Is there a reason for the last paragraph of Section 8 to look different
than the previous RFC summaries?  The grammar is written to correspond, but
the missing ":" makes the paragraph difficult to read.

Thanks for considering these.
Andrea

-----Original Message-----
From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
Sent: Wednesday, November 07, 2001 3:20 PM
To: Diff Serv
Cc: Kathleen Nichols
Subject: [Diffserv] Informal WG last call for
draft-ietf-diffserv-new-terms-06.txt


It is proposed to forward draft-ietf-diffserv-new-terms-06.txt
for publication as an Informational RFC. This is an informal
working group last call - please make any last comments
on this document by Wednesday, November 21.

N.B. This is an "informal" call because this is not a
standards track document. Nevertheless, the clarification
in Section 7 does refer to standards track issues.

  Brian Carpenter
  Kathie Nichols
   diffserv co-chairs

-------- Original Message --------
Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-06.txt
Date: Wed, 07 Nov 2001 07:04:57 -0500
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
To: IETF-Announce: ;
CC: diffserv@ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Differentiated Services Working Group of
the IETF.

	Title		: New Terminology for Diffserv
	Author(s)	: D. Grossman
	Filename	: draft-ietf-diffserv-new-terms-06.txt
	Pages		: 9
	Date		: 06-Nov-01

This memo captures Diffserv working group agreements concerning new
and improved terminology, and also provides minor technical
clarifications.  It is intended to update RFC 2474, RFC 2475 and RFC
2597.   When RFCs 2474 and 2597 advance on the standards track, and
RFC 2475 is updated, it is intended that the revisions in this memo
will be incorporated, and that this memo will be obsoleted by the new
RFCs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-diffserv-new-terms-06.txt



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



From daemon@optimus.ietf.org  Wed Nov 14 07:19:56 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19336
	for <policy-archive@odin.ietf.org>; Wed, 14 Nov 2001 07:19:56 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA22018
	for policy-archive@odin.ietf.org; Wed, 14 Nov 2001 07:19:59 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21682;
	Wed, 14 Nov 2001 07:03:05 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21652
	for <policy@optimus.ietf.org>; Wed, 14 Nov 2001 07:03:03 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18723;
	Wed, 14 Nov 2001 07:02:59 -0500 (EST)
Message-Id: <200111141202.HAA18723@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: policy@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 14 Nov 2001 07:02:59 -0500
Subject: [Policy] I-D ACTION:draft-ietf-policy-qos-info-model-04.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Policy Framework Working Group of the IETF.

	Title		: Policy Framework QoS Information Model
	Author(s)	: Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, B. Moore
	Filename	: draft-ietf-policy-qos-info-model-04.txt
	Pages		: 49
	Date		: 13-Nov-01
	
This document presents an object-oriented information model for 
representing policies that administer, manage, and control access to 
network QoS resources. This document is based on the IETF Policy Core 
Information Model and its extensions as specified by [PCIM] and [PCIMe]. 
This draft builds upon these two documents to define an information 
model for QoS enforcement for differentiated and integrated services 
using policy. It is important to note that this document defines an 
information model, which by definition is independent of any particular 
data storage mechanism and access protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info-model-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-policy-qos-info-model-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-policy-qos-info-model-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011113143937.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-policy-qos-info-model-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-policy-qos-info-model-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011113143937.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Wed Nov 14 07:28:13 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19537
	for <policy-archive@odin.ietf.org>; Wed, 14 Nov 2001 07:28:12 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA22158
	for policy-archive@odin.ietf.org; Wed, 14 Nov 2001 07:28:15 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21865;
	Wed, 14 Nov 2001 07:13:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21837
	for <policy@optimus.ietf.org>; Wed, 14 Nov 2001 07:12:58 -0500 (EST)
Received: from comex1.hkcg.com (comex1.hkcg.com [202.84.208.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19082
	for <policy@ietf.org>; Wed, 14 Nov 2001 07:12:54 -0500 (EST)
Received: by COMEX1 with Internet Mail Service (5.5.2653.19)
	id <V7T1VPD2>; Wed, 14 Nov 2001 20:13:06 +0800
Message-ID: <B3C3D3ED61A3D511B6FA00508B5EEDC8587DC5@comex4>
From: System Attendant <COMEX4-SA@hkcg.com>
To: "'policy@ietf.org'" <policy@ietf.org>
Date: Wed, 14 Nov 2001 20:13:04 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [Policy] ScanMail Message: To Recipient virus found and action taken.
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

ScanMail for Microsoft Exchange has detected virus-infected attachment(s).

Sender = Internet-Drafts@ietf.org
Recipient(s) = policy@ietf.org
Subject = [Policy] I-D ACTION:draft-ietf-policy-qos-info-model-04.txt
Scanning Time = 11/14/2001 20:13:03

Action on virus found:
The attachment draft-ietf-policy-qos-info-model-04.url matched file blocking
settings. ScanMail has Deleted it. 

Warning to recipient. ScanMail has removed an attachment which contains
virus or blocked file type!  If this mail is from Internet, the sender don't
know his/her attachment has been removed.  Please ask the sender to clean
and re-send or remove the blocked attachment.

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



From daemon@optimus.ietf.org  Wed Nov 14 11:29:51 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01625
	for <policy-archive@odin.ietf.org>; Wed, 14 Nov 2001 11:29:51 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA29565
	for policy-archive@odin.ietf.org; Wed, 14 Nov 2001 11:29:54 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28187;
	Wed, 14 Nov 2001 11:09:16 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28149
	for <policy@optimus.ietf.org>; Wed, 14 Nov 2001 11:09:13 -0500 (EST)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00348;
	Wed, 14 Nov 2001 11:09:09 -0500 (EST)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA25659; Wed, 14 Nov 2001 09:09:10 -0700 (MST)]
Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA18287; Wed, 14 Nov 2001 09:09:09 -0700 (MST)]
Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46])
	by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA22715;
	Wed, 14 Nov 2001 11:09:09 -0500 (EST)
Message-Id: <200111141609.LAA22715@noah.dma.isg.mot.com>
X-Mailer: exmh version 1.6.7 5/3/96
To: "Andrea Westerinen" <andreaw@cisco.com>
cc: "Diffserv@Ietf. Org" <diffserv@ietf.org>,
        "Policy@Ietf. Org" <policy@ietf.org>,
        "Bert Wijnen \(Bert\)" <bwijnen@lucent.com>
In-reply-to: Your message of "Tue, 13 Nov 2001 22:24:17 EST."
             <GGEOLLMKEOKMFKADFNHOOEKMEFAA.andreaw@cisco.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 14 Nov 2001 11:09:08 -0500
From: Dan Grossman <dan@dma.isg.mot.com>
Subject: [Policy] Re: FW: [Diffserv] Informal WG last call for
 draft-ietf-diffserv-new-terms-06.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

Andrea,
Thanks for the careful review.
> Dan, I was asked to do a review of the "new-terms" draft wrt PolTerm.  In
> general, there is good correspondence, but I have a few minor comments.
> 
> 1. In Section 2, in the second paragraph, it would be helpful to reference
> the Policy Terminology RFC XXX (draft-ietf-policy-terminology-04.txt,
> waiting in the editor's queue) explicitly, since that supports your
> conclusions of SLAs being of a contractual nature.

Agreed.

> 
> 2. The SLS definition in "new-terms" is a bit different (more restrictive)
> than the definition in PolTerm.  The PolTerm definition tries to straddle
> the contractual versus service/conditioning aspects of an SLS.  PolTerm
> states that an SLS ...
>         Specifies handling of customer's traffic by a network
>         provider. It is negotiated between a customer and the
>         provider, and (for example) in a DiffServ environment,
>         defines parameters such as specific Code Points and the
>         Per-Hop-Behavior, profile characteristics and treatment of
>         the traffic for those Code Points. An SLS is a specific SLA
>         (a negotiated agreement) and its SLOs (the individual
>         metrics and operational data to enforce) to guarantee
>         quality of service for network traffic.
> It might be valuable to mention that the "new-terms" definition further
> restricts that specified in PolTerm, for the DiffServ environment.

I'd be hesitant to alter the Diffserv definition, since this was subject of a 
great deal of working group debate.  However, some words to the effect that 
you suggest would be appropriate.
> 
> 3. In the last paragraph of Section 2, where you quote from the PolTerm RFC,
> could you make this a normative reference?

Ok. I'd lost track of the Polterm draft, and frankly forgot to check the RFC 
Editors queue for its status.  The way this was done reflected a concern that 
this draft would get hung up behind the Polterm draft indefinitely.  Since the 
Polterm draft is ahead, it makes perfect sense to make the Polterm RFC 
normative.

> 
> 4. In the last sentence of Section 2, you say "Therefore, the relationship
> between an SLS and a service provisioning policy is that the latter is, in
> part, the set of rules that define the parameters and range of values that
> may be in the former."  Would it be reasonable to say "... define and manage
> to the parameters and range of values ..."?  The word "define" seems too
> restrictive.
>
I'm having problems parsing your proposed sentence.   How can a set of rules 
"manage to" parameters and and a range of values?  

> And, a few nits:
> 5. There are several weird quotation marks in the Status (``work in
> progress'' and ``1id-abstracts.txt'').
There's some wierd character mappings in my HPUX workstation.  I'll move it 
back to a windows platform and spot clean when this goes to the RFC editor.

> 
> 6. In Section 6, there are a few typos...
> 'Hence the imperitive was"SHOULD" rather than "SHALL"' - should be
> "imperative" and needs a space after "was"
oops... 

> 'An egress DS-node at the edge of one DS-domain forwards packets an ingress
> DS-node at the edge of another DS domain.' - needs a "to" after "forwards
> packets"

well spotted.
> 
> 7. Is there a reason for the last paragraph of Section 8 to look different
> than the previous RFC summaries?  The grammar is written to correspond, but
> the missing ":" makes the paragraph difficult to read.

Will look into, thanks.
> 
> Thanks for considering these.

Thanks again for the review.  
> Andrea
> 
Dan


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



From daemon@optimus.ietf.org  Wed Nov 14 11:30:11 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01667
	for <policy-archive@odin.ietf.org>; Wed, 14 Nov 2001 11:30:11 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA29685
	for policy-archive@odin.ietf.org; Wed, 14 Nov 2001 11:30:14 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28449;
	Wed, 14 Nov 2001 11:14:31 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28410
	for <policy@optimus.ietf.org>; Wed, 14 Nov 2001 11:14:29 -0500 (EST)
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00636;
	Wed, 14 Nov 2001 11:14:25 -0500 (EST)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fAEGDv607593;
	Wed, 14 Nov 2001 11:13:58 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21)
	id <WNHBYHXS>; Wed, 14 Nov 2001 17:13:52 +0100
Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0DF1FF42@nl0006exch002u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Dan Grossman <dan@dma.isg.mot.com>,
        Andrea Westerinen
	 <andreaw@cisco.com>
Cc: "Diffserv@Ietf. Org" <diffserv@ietf.org>,
        "Policy@Ietf. Org"
	 <policy@ietf.org>,
        "Bert Wijnen (Bert)" <bwijnen@lucent.com>
Date: Wed, 14 Nov 2001 17:13:51 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: [Policy] RE: FW: [Diffserv] Informal WG last call for  draft-ietf-diffserv
 -new-terms-06.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

Thanks Andrea for the detailed review
And I see we have a discussion going with some agrrements
comiung out already. Looks like we may expect one more 
revision.

Bert 

> -----Original Message-----
> From: Dan Grossman [mailto:dan@dma.isg.mot.com]
> Sent: Wednesday, November 14, 2001 5:09 PM
> To: Andrea Westerinen
> Cc: Diffserv@Ietf. Org; Policy@Ietf. Org; Bert Wijnen (Bert)
> Subject: Re: FW: [Diffserv] Informal WG last call for
> draft-ietf-diffserv-new-terms-06.txt 
> 
> 
> Andrea,
> Thanks for the careful review.
> > Dan, I was asked to do a review of the "new-terms" draft 
> wrt PolTerm.  In
> > general, there is good correspondence, but I have a few 
> minor comments.
> > 
> > 1. In Section 2, in the second paragraph, it would be 
> helpful to reference
> > the Policy Terminology RFC XXX 
> (draft-ietf-policy-terminology-04.txt,
> > waiting in the editor's queue) explicitly, since that supports your
> > conclusions of SLAs being of a contractual nature.
> 
> Agreed.
> 
> > 
> > 2. The SLS definition in "new-terms" is a bit different 
> (more restrictive)
> > than the definition in PolTerm.  The PolTerm definition 
> tries to straddle
> > the contractual versus service/conditioning aspects of an 
> SLS.  PolTerm
> > states that an SLS ...
> >         Specifies handling of customer's traffic by a network
> >         provider. It is negotiated between a customer and the
> >         provider, and (for example) in a DiffServ environment,
> >         defines parameters such as specific Code Points and the
> >         Per-Hop-Behavior, profile characteristics and treatment of
> >         the traffic for those Code Points. An SLS is a specific SLA
> >         (a negotiated agreement) and its SLOs (the individual
> >         metrics and operational data to enforce) to guarantee
> >         quality of service for network traffic.
> > It might be valuable to mention that the "new-terms" 
> definition further
> > restricts that specified in PolTerm, for the DiffServ environment.
> 
> I'd be hesitant to alter the Diffserv definition, since this 
> was subject of a 
> great deal of working group debate.  However, some words to 
> the effect that 
> you suggest would be appropriate.
> > 
> > 3. In the last paragraph of Section 2, where you quote from 
> the PolTerm RFC,
> > could you make this a normative reference?
> 
> Ok. I'd lost track of the Polterm draft, and frankly forgot 
> to check the RFC 
> Editors queue for its status.  The way this was done 
> reflected a concern that 
> this draft would get hung up behind the Polterm draft 
> indefinitely.  Since the 
> Polterm draft is ahead, it makes perfect sense to make the 
> Polterm RFC 
> normative.
> 
> > 
> > 4. In the last sentence of Section 2, you say "Therefore, 
> the relationship
> > between an SLS and a service provisioning policy is that 
> the latter is, in
> > part, the set of rules that define the parameters and range 
> of values that
> > may be in the former."  Would it be reasonable to say "... 
> define and manage
> > to the parameters and range of values ..."?  The word 
> "define" seems too
> > restrictive.
> >
> I'm having problems parsing your proposed sentence.   How can 
> a set of rules 
> "manage to" parameters and and a range of values?  
> 
> > And, a few nits:
> > 5. There are several weird quotation marks in the Status (``work in
> > progress'' and ``1id-abstracts.txt'').
> There's some wierd character mappings in my HPUX workstation. 
>  I'll move it 
> back to a windows platform and spot clean when this goes to 
> the RFC editor.
> 
> > 
> > 6. In Section 6, there are a few typos...
> > 'Hence the imperitive was"SHOULD" rather than "SHALL"' - should be
> > "imperative" and needs a space after "was"
> oops... 
> 
> > 'An egress DS-node at the edge of one DS-domain forwards 
> packets an ingress
> > DS-node at the edge of another DS domain.' - needs a "to" 
> after "forwards
> > packets"
> 
> well spotted.
> > 
> > 7. Is there a reason for the last paragraph of Section 8 to 
> look different
> > than the previous RFC summaries?  The grammar is written to 
> correspond, but
> > the missing ":" makes the paragraph difficult to read.
> 
> Will look into, thanks.
> > 
> > Thanks for considering these.
> 
> Thanks again for the review.  
> > Andrea
> > 
> Dan
> 

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



From daemon@optimus.ietf.org  Wed Nov 14 17:07:31 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19086
	for <policy-archive@odin.ietf.org>; Wed, 14 Nov 2001 17:07:31 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA12275
	for policy-archive@odin.ietf.org; Wed, 14 Nov 2001 17:07:34 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11184;
	Wed, 14 Nov 2001 16:51:18 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11149
	for <policy@optimus.ietf.org>; Wed, 14 Nov 2001 16:51:16 -0500 (EST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18128;
	Wed, 14 Nov 2001 16:51:07 -0500 (EST)
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fAELobl02053;
	Wed, 14 Nov 2001 13:50:39 -0800 (PST)
Received: from ANDREAWW2K ([128.107.131.45])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with SMTP id AAT74861;
	Wed, 14 Nov 2001 13:50:28 -0800 (PST)
From: "Andrea Westerinen" <andreaw@cisco.com>
To: "Dan Grossman" <dan@dma.isg.mot.com>
Cc: "Diffserv@Ietf. Org" <diffserv@ietf.org>,
        "Policy@Ietf. Org" <policy@ietf.org>,
        "Bert Wijnen \(Bert\)" <bwijnen@lucent.com>
Date: Wed, 14 Nov 2001 13:53:08 -0800
Message-ID: <GGEOLLMKEOKMFKADFNHOCELGEFAA.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.50.4133.2400
In-Reply-To: <200111141609.LAA22715@noah.dma.isg.mot.com>
Content-Transfer-Encoding: 7bit
Subject: [Policy] RE: FW: [Diffserv] Informal WG last call for  draft-ietf-diffserv-new-terms-06.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org
Content-Transfer-Encoding: 7bit

Pulling everything up here.  It looks like #4 needs a bit more discussion -
however, it is not a major issue for me.

1. PolTerm supports SLAs as contractual - Agreed to document this alignment.
2. Dan said, "I'd be hesitant to alter the Diffserv definition, since this
was subject of a great deal of working group debate.  However, some words to
the effect that
you suggest would be appropriate."
	- This is all that I was suggesting.  I totally understand how painful
these things can be - and I think that the definitions are aligned.  PolTerm
is just broader and this was intentional.
3. Normative reference to PolTerm - OK.
4. Service provisioning policy "defines and manages to parameters and range
of values" in an SLS.  Dan asked how rules can manage to parameters and
ranges.
	- This really depends on your rules.  For static "preconfiguration" rules,
then all that you are doing is defining what you want, and making it so.  In
the more general case of provisioning rules, you might have
"preconfiguration" rules, and other "runtime" rules that are invoked "if
<something happens>."  If/when something happens, then the actions of the
other rules might manipulate the environment to maintain (ie, "manage to")
the parameters and ranges, or switch to new parameters, or ignore
parameters/ranges, etc.  I was asking about whether we should generalize
what a "provisioning rule" might do.
5-7. Nits and typos - Will be cleaned up.

Andrea

-----Original Message-----
From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf
Of Dan Grossman
Sent: Wednesday, November 14, 2001 8:09 AM
To: Andrea Westerinen
Cc: Diffserv@Ietf. Org; Policy@Ietf. Org; Bert Wijnen (Bert)
Subject: Re: FW: [Diffserv] Informal WG last call for
draft-ietf-diffserv-new-terms-06.txt


Andrea,
Thanks for the careful review.
> Dan, I was asked to do a review of the "new-terms" draft wrt PolTerm.  In
> general, there is good correspondence, but I have a few minor comments.
>
> 1. In Section 2, in the second paragraph, it would be helpful to reference
> the Policy Terminology RFC XXX (draft-ietf-policy-terminology-04.txt,
> waiting in the editor's queue) explicitly, since that supports your
> conclusions of SLAs being of a contractual nature.

Agreed.

>
> 2. The SLS definition in "new-terms" is a bit different (more restrictive)
> than the definition in PolTerm.  The PolTerm definition tries to straddle
> the contractual versus service/conditioning aspects of an SLS.  PolTerm
> states that an SLS ...
>         Specifies handling of customer's traffic by a network
>         provider. It is negotiated between a customer and the
>         provider, and (for example) in a DiffServ environment,
>         defines parameters such as specific Code Points and the
>         Per-Hop-Behavior, profile characteristics and treatment of
>         the traffic for those Code Points. An SLS is a specific SLA
>         (a negotiated agreement) and its SLOs (the individual
>         metrics and operational data to enforce) to guarantee
>         quality of service for network traffic.
> It might be valuable to mention that the "new-terms" definition further
> restricts that specified in PolTerm, for the DiffServ environment.

I'd be hesitant to alter the Diffserv definition, since this was subject of
a
great deal of working group debate.  However, some words to the effect that
you suggest would be appropriate.
>
> 3. In the last paragraph of Section 2, where you quote from the PolTerm
RFC,
> could you make this a normative reference?

Ok. I'd lost track of the Polterm draft, and frankly forgot to check the RFC
Editors queue for its status.  The way this was done reflected a concern
that
this draft would get hung up behind the Polterm draft indefinitely.  Since
the
Polterm draft is ahead, it makes perfect sense to make the Polterm RFC
normative.

>
> 4. In the last sentence of Section 2, you say "Therefore, the relationship
> between an SLS and a service provisioning policy is that the latter is, in
> part, the set of rules that define the parameters and range of values that
> may be in the former."  Would it be reasonable to say "... define and
manage
> to the parameters and range of values ..."?  The word "define" seems too
> restrictive.
>
I'm having problems parsing your proposed sentence.   How can a set of rules
"manage to" parameters and and a range of values?

> And, a few nits:
> 5. There are several weird quotation marks in the Status (``work in
> progress'' and ``1id-abstracts.txt'').
There's some wierd character mappings in my HPUX workstation.  I'll move it
back to a windows platform and spot clean when this goes to the RFC editor.

>
> 6. In Section 6, there are a few typos...
> 'Hence the imperitive was"SHOULD" rather than "SHALL"' - should be
> "imperative" and needs a space after "was"
oops...

> 'An egress DS-node at the edge of one DS-domain forwards packets an
ingress
> DS-node at the edge of another DS domain.' - needs a "to" after "forwards
> packets"

well spotted.
>
> 7. Is there a reason for the last paragraph of Section 8 to look different
> than the previous RFC summaries?  The grammar is written to correspond,
but
> the missing ":" makes the paragraph difficult to read.

Will look into, thanks.
>
> Thanks for considering these.

Thanks again for the review.
> Andrea
>
Dan


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



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



From daemon@optimus.ietf.org  Wed Nov 14 17:41:45 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20094
	for <policy-archive@odin.ietf.org>; Wed, 14 Nov 2001 17:41:45 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA14175
	for policy-archive@odin.ietf.org; Wed, 14 Nov 2001 17:41:48 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12908;
	Wed, 14 Nov 2001 17:22:54 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12875
	for <policy@optimus.ietf.org>; Wed, 14 Nov 2001 17:22:52 -0500 (EST)
Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19436;
	Wed, 14 Nov 2001 17:22:46 -0500 (EST)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id PAA03002; Wed, 14 Nov 2001 15:13:38 -0700 (MST)]
Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA02417; Wed, 14 Nov 2001 15:22:46 -0700 (MST)]
Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46])
	by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id RAA08649;
	Wed, 14 Nov 2001 17:22:10 -0500 (EST)
Message-Id: <200111142222.RAA08649@noah.dma.isg.mot.com>
X-Mailer: exmh version 1.6.7 5/3/96
To: "Andrea Westerinen" <andreaw@cisco.com>
cc: "Diffserv@Ietf. Org" <diffserv@ietf.org>,
        "Policy@Ietf. Org" <policy@ietf.org>,
        "Bert Wijnen \(Bert\)" <bwijnen@lucent.com>
In-reply-to: Your message of "Wed, 14 Nov 2001 13:53:08 EST."
             <GGEOLLMKEOKMFKADFNHOCELGEFAA.andreaw@cisco.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 14 Nov 2001 17:22:08 -0500
From: Dan Grossman <dan@dma.isg.mot.com>
Subject: [Policy] Re: FW: [Diffserv] Informal WG last call for
 draft-ietf-diffserv-new-terms-06.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

> Pulling everything up here.  It looks like #4 needs a bit more discussion -
> however, it is not a major issue for me.
> 
<snip>
> 4. Service provisioning policy "defines and manages to parameters and range
> of values" in an SLS.  Dan asked how rules can manage to parameters and
> ranges.
> 	- This really depends on your rules.  For static "preconfiguration" rules,
> then all that you are doing is defining what you want, and making it so.  In
> the more general case of provisioning rules, you might have
> "preconfiguration" rules, and other "runtime" rules that are invoked "if
> <something happens>."  If/when something happens, then the actions of the
> other rules might manipulate the environment to maintain (ie, "manage to")
> the parameters and ranges, or switch to new parameters, or ignore
> parameters/ranges, etc.  I was asking about whether we should generalize
> what a "provisioning rule" might do.

Wow!  I'm struggling with the implications of that.  I'd assumed that to the 
extent that an SLS had dynamic ("runtime") elements, the new parameter/value 
tuples would be within the constraints of the same rules as the old SLS (that 
is, the rules are simple, static and non-dependent).

In any event, this seems like  a difficult construct to explain (both as 
sentence structure and as a concept).  If we were to put something like this 
in, it would need some explanation.  Otherwise, I'll be bombarded with the 
same newbie questions about this sentence until I'm 80.  Is this important 
enough to provide more text around?     

Dan



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



From daemon@optimus.ietf.org  Thu Nov 15 07:28:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19467
	for <policy-archive@odin.ietf.org>; Thu, 15 Nov 2001 07:28:05 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA11608
	for policy-archive@odin.ietf.org; Thu, 15 Nov 2001 07:28:07 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11097;
	Thu, 15 Nov 2001 07:07:04 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11067
	for <policy@optimus.ietf.org>; Thu, 15 Nov 2001 07:07:02 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18795;
	Thu, 15 Nov 2001 07:06:59 -0500 (EST)
Message-Id: <200111151206.HAA18795@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: policy@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 15 Nov 2001 07:06:59 -0500
Subject: [Policy] I-D ACTION:draft-ietf-policy-core-schema-13.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Policy Framework Working Group of the IETF.

	Title		: Policy Core LDAP Schema
	Author(s)	: J. Strassner, E. Ellesson, R. Moore, R. Moats
	Filename	: draft-ietf-policy-core-schema-13.txt
	Pages		: 53
	Date		: 14-Nov-01
	
This document defines a mapping of the Policy Core Information Model [1] 
to a form that can be implemented in a directory that uses LDAP as its 
access protocol.  This model defines two hierarchies of object classes: 
structural classes representing information for representing and 
controlling policy data as specified in [1], and relationship classes 
that indicate how instances of the structural classes are related to 
each other. Classes are also added to the LDAP schema to improve the 
performance of a client's interactions with an LDAP server when the 
client is retrieving large amounts of policy-related information.  These 
classes exist only to optimize LDAP retrievals: there are no classes in 
the information model that correspond to them.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-policy-core-schema-13.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-policy-core-schema-13.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-policy-core-schema-13.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011114151136.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-policy-core-schema-13.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-policy-core-schema-13.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011114151136.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Thu Nov 15 07:39:08 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19805
	for <policy-archive@odin.ietf.org>; Thu, 15 Nov 2001 07:39:07 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA12129
	for policy-archive@odin.ietf.org; Thu, 15 Nov 2001 07:39:10 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11445;
	Thu, 15 Nov 2001 07:22:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11414
	for <policy@optimus.ietf.org>; Thu, 15 Nov 2001 07:22:04 -0500 (EST)
Received: from comex2.hkcg.com ([202.84.208.5])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19348
	for <policy@ietf.org>; Thu, 15 Nov 2001 07:22:00 -0500 (EST)
Received: by COMEX2 with Internet Mail Service (5.5.2653.19)
	id <V7TGBPXL>; Thu, 15 Nov 2001 20:22:13 +0800
Message-ID: <B3C3D3ED61A3D511B6FA00508B5EEDC8587E36@comex4>
From: System Attendant <COMEX4-SA@hkcg.com>
To: "'policy@ietf.org'" <policy@ietf.org>
Date: Thu, 15 Nov 2001 20:22:04 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [Policy] ScanMail Message: To Recipient virus found and action taken.
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

ScanMail for Microsoft Exchange has detected virus-infected attachment(s).

Sender = Internet-Drafts@ietf.org
Recipient(s) = policy@ietf.org
Subject = [Policy] I-D ACTION:draft-ietf-policy-core-schema-13.txt
Scanning Time = 11/15/2001 20:22:04

Action on virus found:
The attachment draft-ietf-policy-core-schema-13.url matched file blocking
settings. ScanMail has Deleted it. 

Warning to recipient. ScanMail has removed an attachment which contains
virus or blocked file type!  If this mail is from Internet, the sender don't
know his/her attachment has been removed.  Please ask the sender to clean
and re-send or remove the blocked attachment.

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



From daemon@optimus.ietf.org  Thu Nov 15 07:58:51 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20568
	for <policy-archive@odin.ietf.org>; Thu, 15 Nov 2001 07:58:51 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA12524
	for policy-archive@odin.ietf.org; Thu, 15 Nov 2001 07:58:51 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12267;
	Thu, 15 Nov 2001 07:44:32 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12237
	for <policy@optimus.ietf.org>; Thu, 15 Nov 2001 07:44:30 -0500 (EST)
Received: from dominio_gestao.intra.cet.pt ([194.65.138.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20020
	for <policy@ietf.org>; Thu, 15 Nov 2001 07:44:28 -0500 (EST)
Received: by ns.ptinovacao.pt with Internet Mail Service (5.5.2653.19)
	id <W7QHWJ7D>; Thu, 15 Nov 2001 12:51:01 -0000
Message-ID: <D397A7FACCC45A44A0A207FD892961EA088B87@RIOVOUGA>
From: Carla Paiva <carla-m-paiva@ptinovacao.pt>
To: "'policy@ietf.org'" <policy@ietf.org>
Date: Thu, 15 Nov 2001 12:41:12 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C16DD2.CE9EADF0"
Subject: [Policy] unsubscribe
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

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_01C16DD2.CE9EADF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

unsubscribe
  _____ =20

Carla Paiva
=20
Multim=E9dia e Servi=E7os IP
Portugal Telecom Inova=E7=E3o, S.A
Rua Jos=E9 Ferreira Pinto Basto - 3810 Aveiro
=20
Telefone +351 234 403522  Fax +351 234420722
E-mail  <mailto:carla-m-paiva@ptinovacao.pt> =
carla-m-paiva@ptinovacao.pt
=20

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D966004512-15112001><FONT face=3DVerdana=20
size=3D2>unsubscribe</FONT></SPAN></DIV>
<DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#000080 size=3D2><STRONG>
<HR>
</STRONG></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#000080 =
size=3D2><STRONG>Carla=20
Paiva</STRONG></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#000080 size=3D1>Multim=E9dia =
e Servi=E7os=20
IP</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#000080 size=3D1>Portugal =
Telecom Inova=E7=E3o,=20
S.A</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#000080 size=3D1>Rua Jos=E9 =
Ferreira Pinto=20
Basto - 3810 Aveiro</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV><FONT color=3D#000080><FONT face=3D"Comic Sans MS"><FONT=20
size=3D1><STRONG>Telefone +351 234&nbsp;<SPAN=20
class=3D786073910-24012001>403522&nbsp; =
</SPAN></STRONG></FONT></FONT></FONT><FONT=20
face=3D"Comic Sans MS" color=3D#000080 size=3D1><STRONG><SPAN=20
class=3D786073910-24012001>Fax +351 =
234420722</SPAN></STRONG></FONT></DIV>
<DIV><STRONG><FONT face=3D"Comic Sans MS" color=3D#000080 =
size=3D1>E-mail </FONT><A=20
href=3D"mailto:carla-m-paiva@ptinovacao.pt"><FONT color=3D#000080><FONT =

face=3D"Comic Sans MS"><FONT=20
size=3D1><STRONG>carla-m-paiva@ptinovacao.</STRONG>pt</FONT></FONT></FON=
T></A></STRONG></DIV></DIV></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C16DD2.CE9EADF0--

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



From daemon@optimus.ietf.org  Thu Nov 15 08:59:44 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23620
	for <policy-archive@odin.ietf.org>; Thu, 15 Nov 2001 08:59:40 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA15139
	for policy-archive@odin.ietf.org; Thu, 15 Nov 2001 08:59:41 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14190;
	Thu, 15 Nov 2001 08:40:30 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14152
	for <policy@optimus.ietf.org>; Thu, 15 Nov 2001 08:40:26 -0500 (EST)
Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22509;
	Thu, 15 Nov 2001 08:40:24 -0500 (EST)
Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id OAA16246; Thu, 15 Nov 2001 14:39:52 +0100
Received: from dhcp22-51.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA74726 from <brian@hursley.ibm.com>; Thu, 15 Nov 2001 14:39:51 +0100
Message-Id: <3BF3C49D.A6FC5DB8@hursley.ibm.com>
Date: Thu, 15 Nov 2001 14:35:25 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
Mime-Version: 1.0
To: Dan Grossman <dan@dma.isg.mot.com>
Cc: Andrea Westerinen <andreaw@cisco.com>,
        "Diffserv@Ietf. Org" <diffserv@ietf.org>,
        "Policy@Ietf. Org" <policy@ietf.org>,
        "Bert Wijnen (Bert)" <bwijnen@lucent.com>
References: <200111142222.RAA08649@noah.dma.isg.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Policy] Re: FW: [Diffserv] Informal WG last call for
 draft-ietf-diffserv-new-terms-06.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org
Content-Transfer-Encoding: 7bit

Given that new-terms will be Informational, I don't think we have to
beat this to death- Dan could perhaps craft some disclaimer text.

(Also, by the way, Informational RFCs don't have to worry about
the difference between normative and non-normative references.)

  Brian

Dan Grossman wrote:
> 
> > Pulling everything up here.  It looks like #4 needs a bit more discussion -
> > however, it is not a major issue for me.
> >
> <snip>
> > 4. Service provisioning policy "defines and manages to parameters and range
> > of values" in an SLS.  Dan asked how rules can manage to parameters and
> > ranges.
> >       - This really depends on your rules.  For static "preconfiguration" rules,
> > then all that you are doing is defining what you want, and making it so.  In
> > the more general case of provisioning rules, you might have
> > "preconfiguration" rules, and other "runtime" rules that are invoked "if
> > <something happens>."  If/when something happens, then the actions of the
> > other rules might manipulate the environment to maintain (ie, "manage to")
> > the parameters and ranges, or switch to new parameters, or ignore
> > parameters/ranges, etc.  I was asking about whether we should generalize
> > what a "provisioning rule" might do.
> 
> Wow!  I'm struggling with the implications of that.  I'd assumed that to the
> extent that an SLS had dynamic ("runtime") elements, the new parameter/value
> tuples would be within the constraints of the same rules as the old SLS (that
> is, the rules are simple, static and non-dependent).
> 
> In any event, this seems like  a difficult construct to explain (both as
> sentence structure and as a concept).  If we were to put something like this
> in, it would need some explanation.  Otherwise, I'll be bombarded with the
> same newbie questions about this sentence until I'm 80.  Is this important
> enough to provide more text around?
> 
> Dan

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



From daemon@optimus.ietf.org  Thu Nov 15 10:02:46 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26620
	for <policy-archive@odin.ietf.org>; Thu, 15 Nov 2001 10:02:46 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA17277
	for policy-archive@odin.ietf.org; Thu, 15 Nov 2001 10:02:34 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16643;
	Thu, 15 Nov 2001 09:45:13 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16575
	for <policy@optimus.ietf.org>; Thu, 15 Nov 2001 09:45:10 -0500 (EST)
Received: from dominio_gestao.intra.cet.pt ([194.65.138.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25796;
	Thu, 15 Nov 2001 09:45:07 -0500 (EST)
Received: by ns.ptinovacao.pt with Internet Mail Service (5.5.2653.19)
	id <W7QHWJ69>; Thu, 15 Nov 2001 12:50:10 -0000
Message-ID: <D397A7FACCC45A44A0A207FD892961EA088B86@RIOVOUGA>
From: Carla Paiva <carla-m-paiva@ptinovacao.pt>
To: "Diffserv@Ietf. Org" <diffserv@ietf.org>,
        "Policy@Ietf. Org"
	 <policy@ietf.org>
Date: Thu, 15 Nov 2001 12:40:21 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C16DD2.B0639300"
Subject: [Policy] unsubscribe
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

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_01C16DD2.B0639300
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

unsubscribe
  _____ =20

Carla Paiva
=20
Multim=E9dia e Servi=E7os IP
Portugal Telecom Inova=E7=E3o, S.A
Rua Jos=E9 Ferreira Pinto Basto - 3810 Aveiro
=20
Telefone +351 234 403522  Fax +351 234420722
E-mail  <mailto:carla-m-paiva@ptinovacao.pt> =
carla-m-paiva@ptinovacao.pt
=20

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DVerdana size=3D2><SPAN=20
class=3D236444312-15112001>unsubscribe</SPAN></FONT></DIV>
<DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#000080 size=3D2><STRONG>
<HR>
</STRONG></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#000080 =
size=3D2><STRONG>Carla=20
Paiva</STRONG></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#000080 size=3D1>Multim=E9dia =
e Servi=E7os=20
IP</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#000080 size=3D1>Portugal =
Telecom Inova=E7=E3o,=20
S.A</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#000080 size=3D1>Rua Jos=E9 =
Ferreira Pinto=20
Basto - 3810 Aveiro</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV><FONT color=3D#000080><FONT face=3D"Comic Sans MS"><FONT=20
size=3D1><STRONG>Telefone +351 234&nbsp;<SPAN=20
class=3D786073910-24012001>403522&nbsp; =
</SPAN></STRONG></FONT></FONT></FONT><FONT=20
face=3D"Comic Sans MS" color=3D#000080 size=3D1><STRONG><SPAN=20
class=3D786073910-24012001>Fax +351 =
234420722</SPAN></STRONG></FONT></DIV>
<DIV><STRONG><FONT face=3D"Comic Sans MS" color=3D#000080 =
size=3D1>E-mail </FONT><A=20
href=3D"mailto:carla-m-paiva@ptinovacao.pt"><FONT color=3D#000080><FONT =

face=3D"Comic Sans MS"><FONT=20
size=3D1><STRONG>carla-m-paiva@ptinovacao.</STRONG>pt</FONT></FONT></FON=
T></A></STRONG></DIV></DIV></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C16DD2.B0639300--

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



From daemon@optimus.ietf.org  Thu Nov 15 10:33:28 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28428
	for <policy-archive@odin.ietf.org>; Thu, 15 Nov 2001 10:33:28 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA19250
	for policy-archive@odin.ietf.org; Thu, 15 Nov 2001 10:33:30 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17725;
	Thu, 15 Nov 2001 10:17:14 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17686
	for <policy@optimus.ietf.org>; Thu, 15 Nov 2001 10:17:11 -0500 (EST)
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27398;
	Thu, 15 Nov 2001 10:17:09 -0500 (EST)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.10.2/8.10.2) id fAFFGNp00837;
	Thu, 15 Nov 2001 10:16:23 -0500 (EST)
Date: Thu, 15 Nov 2001 10:16:23 -0500 (EST)
From: Scott  Bradner <sob@harvard.edu>
Message-Id: <200111151516.fAFFGNp00837@newdev.harvard.edu>
To: brian@hursley.ibm.com, dan@dma.isg.mot.com
Cc: andreaw@cisco.com, bwijnen@lucent.com, diffserv@ietf.org, policy@ietf.org
Subject: [Policy] Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

Given that new-terms will be Informational, I don't think we have to
> Given that new-terms will be Informational, I don't think we have to
> the difference between normative and non-normative references.)

see http://www.rfc-editor.org/policy.html

in general and in specific about references

Scott

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



From daemon@optimus.ietf.org  Thu Nov 15 11:21:59 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01253
	for <policy-archive@odin.ietf.org>; Thu, 15 Nov 2001 11:21:59 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA22568
	for policy-archive@odin.ietf.org; Thu, 15 Nov 2001 11:22:02 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21244;
	Thu, 15 Nov 2001 11:07:28 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21196
	for <policy@optimus.ietf.org>; Thu, 15 Nov 2001 11:07:25 -0500 (EST)
Received: from e22.nc.us.ibm.com (e22.nc.us.ibm.com [32.97.136.228])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00119;
	Thu, 15 Nov 2001 11:07:21 -0500 (EST)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA17330;
	Thu, 15 Nov 2001 10:04:42 -0600
Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62])
	by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fAFG7Kv132400;
	Thu, 15 Nov 2001 11:07:20 -0500
Subject: Re: [Policy] Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt
To: Scott Bradner <sob@harvard.edu>
Cc: andreaw@cisco.com, brian@hursley.ibm.com, bwijnen@lucent.com,
        dan@dma.isg.mot.com, diffserv@ietf.org, policy@ietf.org,
        policy-admin@ietf.org
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OFDCA20253.4520B794-ON85256B05.0057F3C1@raleigh.ibm.com>
From: "Robert Moore" <remoore@us.ibm.com>
Date: Thu, 15 Nov 2001 11:08:40 -0500
X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.8 |June 18, 2001) at
 11/15/2001 11:07:19 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org


Sorry, Scott, but I looked at the page you referred
us to, and I still can't tell which of the following
is the message I'm supposed to take away from it:

A. No, Brian, that's not right - there *is* a
   distinction in an Informational RFC between
   normative and non-normative references.

B. Yes, Brian, you're correct - there is no
   distinction in an Informational RFC between
   normative and non-normative references.

C. Brian, it's more complicated than that.  For some
   Informational RFCs, there is a distinction, and
   for others there isn't.  For a particular
   Informational RFC, <????> tells you whether it needs
   to distinguish between normative and non-normative
   references.  [I have no idea how to fill in the
   <????> here, by the way.]

Can you say whether you meant A, B, or C, or even a D
that hasn't occurred to me?  Thanks.

Regards,
Bob

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



                                                                                            
                    Scott  Bradner                                                          
                    <sob@harvard.e       To:     brian@hursley.ibm.com, dan@dma.isg.mot.com 
                    du>                  cc:     andreaw@cisco.com, bwijnen@lucent.com,     
                    Sent by:              diffserv@ietf.org, policy@ietf.org                
                    policy-admin@i       Subject:     [Policy] Re: FW: [Diffserv] Informal  
                    etf.org               WG last call for                                  
                                          draft-ietf-diffserv-new-terms-06.txt              
                                                                                            
                    11/15/01 10:16                                                          
                    AM                                                                      
                                                                                            
                                                                                            



Given that new-terms will be Informational, I don't think we have to
> Given that new-terms will be Informational, I don't think we have to
> the difference between normative and non-normative references.)

see http://www.rfc-editor.org/policy.html

in general and in specific about references

Scott

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





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



From daemon@optimus.ietf.org  Thu Nov 15 11:22:08 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01269
	for <policy-archive@odin.ietf.org>; Thu, 15 Nov 2001 11:22:07 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA22584
	for policy-archive@odin.ietf.org; Thu, 15 Nov 2001 11:22:10 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20838;
	Thu, 15 Nov 2001 11:02:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20802
	for <policy@optimus.ietf.org>; Thu, 15 Nov 2001 11:01:58 -0500 (EST)
Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29832;
	Thu, 15 Nov 2001 11:01:54 -0500 (EST)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA17133; Thu, 15 Nov 2001 08:52:44 -0700 (MST)]
Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA13008; Thu, 15 Nov 2001 09:01:53 -0700 (MST)]
Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46])
	by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA05002;
	Thu, 15 Nov 2001 11:01:50 -0500 (EST)
Message-Id: <200111151601.LAA05002@noah.dma.isg.mot.com>
X-Mailer: exmh version 1.6.7 5/3/96
To: Brian E Carpenter <brian@hursley.ibm.com>
cc: Andrea Westerinen <andreaw@cisco.com>,
        "Diffserv@Ietf. Org" <diffserv@ietf.org>,
        "Policy@Ietf. Org" <policy@ietf.org>,
        "Bert Wijnen (Bert)" <bwijnen@lucent.com>
In-reply-to: Your message of "Thu, 15 Nov 2001 14:35:25 EST."
             <3BF3C49D.A6FC5DB8@hursley.ibm.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 15 Nov 2001 11:01:49 -0500
From: Dan Grossman <dan@dma.isg.mot.com>
Subject: [Policy] Re: FW: [Diffserv] Informal WG last call for
 draft-ietf-diffserv-new-terms-06.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org


> Given that new-terms will be Informational, I don't think we have to
> beat this to death- Dan could perhaps craft some disclaimer text.

My inclination at this point is to leave it as it is, unless Andrea can come 
up with a concise sentence or two that can be dropped in.  I think that policy 
aware readers will understand that we don't intend to be restrictive, and 
non-policy aware readers won't be confused.

> 
> (Also, by the way, Informational RFCs don't have to worry about
> the difference between normative and non-normative references.)
It appears that all the references are normative.
> 
>   Brian
> 
Dan


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



From daemon@optimus.ietf.org  Thu Nov 15 11:34:21 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02268
	for <policy-archive@odin.ietf.org>; Thu, 15 Nov 2001 11:34:21 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA24235
	for policy-archive@odin.ietf.org; Thu, 15 Nov 2001 11:34:23 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22178;
	Thu, 15 Nov 2001 11:18:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22132
	for <policy@optimus.ietf.org>; Thu, 15 Nov 2001 11:18:39 -0500 (EST)
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01054;
	Thu, 15 Nov 2001 11:18:34 -0500 (EST)
Received: (from sob@localhost)
	by newdev.harvard.edu (8.10.2/8.10.2) id fAFGI8a00719;
	Thu, 15 Nov 2001 11:18:08 -0500 (EST)
Date: Thu, 15 Nov 2001 11:18:08 -0500 (EST)
From: Scott  Bradner <sob@harvard.edu>
Message-Id: <200111151618.fAFGI8a00719@newdev.harvard.edu>
To: remoore@us.ibm.com, sob@harvard.edu
Subject: Re: [Policy] Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt
Cc: andreaw@cisco.com, brian@hursley.ibm.com, bwijnen@lucent.com,
        dan@dma.isg.mot.com, diffserv@ietf.org, policy-admin@ietf.org,
        policy@ietf.org
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

the aim is to have all RFCs distinguish between normative and non-normative
references

Scott

---
From remoore@us.ibm.com  Thu Nov 15 11:07:44 2001
Subject: Re: [Policy] Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt
To: Scott Bradner <sob@harvard.edu>
Cc: andreaw@cisco.com, brian@hursley.ibm.com, bwijnen@lucent.com,
   dan@dma.isg.mot.com, diffserv@ietf.org, policy@ietf.org,
   policy-admin@ietf.org
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
From: "Robert Moore" <remoore@us.ibm.com>
Date: Thu, 15 Nov 2001 11:08:40 -0500
X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.8 |June 18, 2001) at
 11/15/2001 11:07:19 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii


Sorry, Scott, but I looked at the page you referred
us to, and I still can't tell which of the following
is the message I'm supposed to take away from it:

A. No, Brian, that's not right - there *is* a
   distinction in an Informational RFC between
   normative and non-normative references.

B. Yes, Brian, you're correct - there is no
   distinction in an Informational RFC between
   normative and non-normative references.

C. Brian, it's more complicated than that.  For some
   Informational RFCs, there is a distinction, and
   for others there isn't.  For a particular
   Informational RFC, <????> tells you whether it needs
   to distinguish between normative and non-normative
   references.  [I have no idea how to fill in the
   <????> here, by the way.]

Can you say whether you meant A, B, or C, or even a D
that hasn't occurred to me?  Thanks.

Regards,
Bob

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



                                                                                            
                    Scott  Bradner                                                          
                    <sob@harvard.e       To:     brian@hursley.ibm.com, dan@dma.isg.mot.com 
                    du>                  cc:     andreaw@cisco.com, bwijnen@lucent.com,     
                    Sent by:              diffserv@ietf.org, policy@ietf.org                
                    policy-admin@i       Subject:     [Policy] Re: FW: [Diffserv] Informal  
                    etf.org               WG last call for                                  
                                          draft-ietf-diffserv-new-terms-06.txt              
                                                                                            
                    11/15/01 10:16                                                          
                    AM                                                                      
                                                                                            
                                                                                            



Given that new-terms will be Informational, I don't think we have to
> Given that new-terms will be Informational, I don't think we have to
> the difference between normative and non-normative references.)

see http://www.rfc-editor.org/policy.html

in general and in specific about references

Scott

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





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



From daemon@ns.ietf.org  Thu Nov 15 15:47:49 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19100
	for <policy-archive@odin.ietf.org>; Thu, 15 Nov 2001 15:47:49 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA05121
	for policy-archive@odin.ietf.org; Thu, 15 Nov 2001 15:47:50 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04681;
	Thu, 15 Nov 2001 15:31:45 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04649
	for <policy@ns.ietf.org>; Thu, 15 Nov 2001 15:31:43 -0500 (EST)
Received: from dominio_gestao.intra.cet.pt ([194.65.138.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17988
	for <policy@ietf.org>; Thu, 15 Nov 2001 15:31:41 -0500 (EST)
Received: by ns.ptinovacao.pt with Internet Mail Service (5.5.2653.19)
	id <W7QHWKMT>; Thu, 15 Nov 2001 14:42:01 -0000
Message-ID: <D397A7FACCC45A44A0A207FD892961EA088B8A@RIOVOUGA>
From: Carla Paiva <carla-m-paiva@ptinovacao.pt>
To: "'policy@ietf.org'" <policy@ietf.org>
Date: Thu, 15 Nov 2001 14:32:04 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C16DE2.4BCF5540"
Subject: [Policy] subscribe
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

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_01C16DE2.4BCF5540
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

subscribe
  _____ =20

Carla Paiva
=20
Multim=E9dia e Servi=E7os IP
Portugal Telecom Inova=E7=E3o, S.A
Rua Jos=E9 Ferreira Pinto Basto - 3810 Aveiro
=20
Telefone +351 234 403522  Fax +351 234420722
E-mail  <mailto:carla-m-paiva@ptinovacao.pt> =
carla-m-paiva@ptinovacao.pt
=20

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DVerdana size=3D2><SPAN=20
class=3D617493514-15112001>subscribe</SPAN></FONT></DIV>
<DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#000080 size=3D2><STRONG>
<HR>
</STRONG></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#000080 =
size=3D2><STRONG>Carla=20
Paiva</STRONG></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#000080 size=3D1>Multim=E9dia =
e Servi=E7os=20
IP</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#000080 size=3D1>Portugal =
Telecom Inova=E7=E3o,=20
S.A</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" color=3D#000080 size=3D1>Rua Jos=E9 =
Ferreira Pinto=20
Basto - 3810 Aveiro</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV><FONT color=3D#000080><FONT face=3D"Comic Sans MS"><FONT=20
size=3D1><STRONG>Telefone +351 234&nbsp;<SPAN=20
class=3D786073910-24012001>403522&nbsp; =
</SPAN></STRONG></FONT></FONT></FONT><FONT=20
face=3D"Comic Sans MS" color=3D#000080 size=3D1><STRONG><SPAN=20
class=3D786073910-24012001>Fax +351 =
234420722</SPAN></STRONG></FONT></DIV>
<DIV><STRONG><FONT face=3D"Comic Sans MS" color=3D#000080 =
size=3D1>E-mail </FONT><A=20
href=3D"mailto:carla-m-paiva@ptinovacao.pt"><FONT color=3D#000080><FONT =

face=3D"Comic Sans MS"><FONT=20
size=3D1><STRONG>carla-m-paiva@ptinovacao.</STRONG>pt</FONT></FONT></FON=
T></A></STRONG></DIV></DIV></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C16DE2.4BCF5540--

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



From daemon@optimus.ietf.org  Sat Nov 17 21:10:21 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01953
	for <policy-archive@odin.ietf.org>; Sat, 17 Nov 2001 21:10:21 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA00390
	for policy-archive@odin.ietf.org; Sat, 17 Nov 2001 21:10:22 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29481;
	Sat, 17 Nov 2001 20:53:29 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29446
	for <policy@optimus.ietf.org>; Sat, 17 Nov 2001 20:53:26 -0500 (EST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01774;
	Sat, 17 Nov 2001 20:53:24 -0500 (EST)
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fAI1qsW27060;
	Sat, 17 Nov 2001 17:52:54 -0800 (PST)
Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with SMTP id AAU52255;
	Sat, 17 Nov 2001 17:52:51 -0800 (PST)
From: "Andrea Westerinen" <andreaw@cisco.com>
To: "Dan Grossman" <dan@dma.isg.mot.com>
Cc: "Diffserv@Ietf. Org" <diffserv@ietf.org>,
        "Policy@Ietf. Org" <policy@ietf.org>,
        "Bert Wijnen \(Bert\)" <bwijnen@lucent.com>
Date: Sat, 17 Nov 2001 17:55:31 -0800
Message-ID: <GGEOLLMKEOKMFKADFNHOMENLEFAA.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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <GGEOLLMKEOKMFKADFNHOCELGEFAA.andreaw@cisco.com>
Content-Transfer-Encoding: 7bit
Subject: [Policy] RE: FW: [Diffserv] Informal WG last call for  draft-ietf-diffserv-new-terms-06.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org
Content-Transfer-Encoding: 7bit

Focusing on #4.

The text says ... "Therefore, the relationship between an SLS and a service
provisioning policy is that the latter is, in part, the set of rules that
define the parameters and range of values that may be in the former."

<Dan> My inclination at this point is to leave it as it is, unless Andrea
can come
up with a concise sentence or two that can be dropped in.  I think that
policy
aware readers will understand that we don't intend to be restrictive, and
non-policy aware readers won't be confused.

Can we say "the set of rules that IMPLEMENT the parameters and range of
values ..."?  My problem is with the word DEFINES.

Andrea

-----Original Message-----
From: Andrea Westerinen [mailto:andreaw@cisco.com]
Sent: Wednesday, November 14, 2001 1:53 PM
To: Dan Grossman
Cc: Diffserv@Ietf. Org; Policy@Ietf. Org; Bert Wijnen (Bert)
Subject: RE: FW: [Diffserv] Informal WG last call for
draft-ietf-diffserv-new-terms-06.txt


Pulling everything up here.  It looks like #4 needs a bit more discussion -
however, it is not a major issue for me.

1. PolTerm supports SLAs as contractual - Agreed to document this alignment.
2. Dan said, "I'd be hesitant to alter the Diffserv definition, since this
was subject of a great deal of working group debate.  However, some words to
the effect that
you suggest would be appropriate."
	- This is all that I was suggesting.  I totally understand how painful
these things can be - and I think that the definitions are aligned.  PolTerm
is just broader and this was intentional.
3. Normative reference to PolTerm - OK.
4. Service provisioning policy "defines and manages to parameters and range
of values" in an SLS.  Dan asked how rules can manage to parameters and
ranges.
	- This really depends on your rules.  For static "preconfiguration" rules,
then all that you are doing is defining what you want, and making it so.  In
the more general case of provisioning rules, you might have
"preconfiguration" rules, and other "runtime" rules that are invoked "if
<something happens>."  If/when something happens, then the actions of the
other rules might manipulate the environment to maintain (ie, "manage to")
the parameters and ranges, or switch to new parameters, or ignore
parameters/ranges, etc.  I was asking about whether we should generalize
what a "provisioning rule" might do.
5-7. Nits and typos - Will be cleaned up.

Andrea


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



From daemon@optimus.ietf.org  Sun Nov 18 18:03:20 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29590
	for <policy-archive@odin.ietf.org>; Sun, 18 Nov 2001 18:03:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA29008
	for policy-archive@odin.ietf.org; Sun, 18 Nov 2001 18:03:24 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27929;
	Sun, 18 Nov 2001 17:45:31 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27901
	for <policy@optimus.ietf.org>; Sun, 18 Nov 2001 17:45:29 -0500 (EST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29392;
	Sun, 18 Nov 2001 17:45:23 -0500 (EST)
Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fAIMitE10179;
	Sun, 18 Nov 2001 14:44:55 -0800 (PST)
Received: from SBRIM-W2K (sjc-vpn2-593.cisco.com [10.21.114.81])
	by airborne.cisco.com (Mirapoint)
	with SMTP id AAF21412;
	Sun, 18 Nov 2001 14:44:50 -0800 (PST)
Received: by SBRIM-W2K (sSMTP sendmail emulation); Sun, 18 Nov 2001 17:44:53 -0500
Date: Sun, 18 Nov 2001 17:44:53 -0500
From: Scott Brim <swb@employees.org>
To: Andrea Westerinen <andreaw@cisco.com>
Cc: Dan Grossman <dan@dma.isg.mot.com>,
        "Diffserv@Ietf. Org" <diffserv@ietf.org>,
        "Policy@Ietf. Org" <policy@ietf.org>,
        "Bert Wijnen (Bert)" <bwijnen@lucent.com>
Message-ID: <20011118174452.A1544@SBRIM-W2K>
Mail-Followup-To: Scott Brim <swb@employees.org>,
	Andrea Westerinen <andreaw@cisco.com>,
	Dan Grossman <dan@dma.isg.mot.com>,
	"Diffserv@Ietf. Org" <diffserv@ietf.org>,
	"Policy@Ietf. Org" <policy@ietf.org>,
	"Bert Wijnen (Bert)" <bwijnen@lucent.com>
References: <GGEOLLMKEOKMFKADFNHOCELGEFAA.andreaw@cisco.com> <GGEOLLMKEOKMFKADFNHOMENLEFAA.andreaw@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <GGEOLLMKEOKMFKADFNHOMENLEFAA.andreaw@cisco.com>; from andreaw@cisco.com on Sat, Nov 17, 2001 at 05:55:31PM -0800
Subject: [Policy] Re: FW: [Diffserv] Informal WG last call for  draft-ietf-diffserv-new-terms-06.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

On Sat, Nov 17, 2001 05:55:31PM -0800, Andrea Westerinen wrote:
> Focusing on #4.
> 
> The text says ... "Therefore, the relationship between an SLS and a service
> provisioning policy is that the latter is, in part, the set of rules that
> define the parameters and range of values that may be in the former."
> 
> <Dan> My inclination at this point is to leave it as it is, unless Andrea
> can come
> up with a concise sentence or two that can be dropped in.  I think that
> policy
> aware readers will understand that we don't intend to be restrictive, and
> non-policy aware readers won't be confused.
> 
> Can we say "the set of rules that IMPLEMENT the parameters and range of
> values ..."?  My problem is with the word DEFINES.

"Implements" is worse because the rules have nothing to do with
implementation (a standardization absolute).  If you think "defines"
crosses a boundary, I suggest "specifies".

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



From daemon@optimus.ietf.org  Sun Nov 18 22:04:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02286
	for <policy-archive@odin.ietf.org>; Sun, 18 Nov 2001 22:04:10 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id WAA04285
	for policy-archive@odin.ietf.org; Sun, 18 Nov 2001 22:04:10 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03050;
	Sun, 18 Nov 2001 21:43:58 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03016
	for <policy@optimus.ietf.org>; Sun, 18 Nov 2001 21:43:55 -0500 (EST)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02054;
	Sun, 18 Nov 2001 21:43:51 -0500 (EST)
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fAJ2hGH08561;
	Sun, 18 Nov 2001 18:43:16 -0800 (PST)
Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with SMTP id AAU58462;
	Sun, 18 Nov 2001 18:43:15 -0800 (PST)
From: "Andrea Westerinen" <andreaw@cisco.com>
To: "Scott Brim" <swb@employees.org>
Cc: "Dan Grossman" <dan@dma.isg.mot.com>,
        "Diffserv@Ietf. Org" <diffserv@ietf.org>,
        "Policy@Ietf. Org" <policy@ietf.org>,
        "Bert Wijnen \(Bert\)" <bwijnen@lucent.com>
Date: Sun, 18 Nov 2001 18:45:54 -0800
Message-ID: <GGEOLLMKEOKMFKADFNHOIENPEFAA.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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <20011118174452.A1544@SBRIM-W2K>
Content-Transfer-Encoding: 7bit
Subject: [Policy] RE: FW: [Diffserv] Informal WG last call for  draft-ietf-diffserv-new-terms-06.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org
Content-Transfer-Encoding: 7bit

But, my issue is with the word, "define" or "specify".  IMHO, the SLS
"defines" the values or behavior, and the rules "act on" or "realize" the
definition.  I didn't equate "implement" with "implementation", but I can
see the problem with that word.

Does "realize" make it better or worse ("... the set of rules that realize
the parameters and range ...")?

Andrea

-----Original Message-----
From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf
Of Scott Brim
Sent: Sunday, November 18, 2001 2:45 PM
To: Andrea Westerinen
Cc: Dan Grossman; Diffserv@Ietf. Org; Policy@Ietf. Org; Bert Wijnen
(Bert)
Subject: Re: FW: [Diffserv] Informal WG last call for
draft-ietf-diffserv-new-terms-06.txt


On Sat, Nov 17, 2001 05:55:31PM -0800, Andrea Westerinen wrote:
> Focusing on #4.
>
> The text says ... "Therefore, the relationship between an SLS and a
service
> provisioning policy is that the latter is, in part, the set of rules that
> define the parameters and range of values that may be in the former."
>
> <Dan> My inclination at this point is to leave it as it is, unless Andrea
> can come
> up with a concise sentence or two that can be dropped in.  I think that
> policy
> aware readers will understand that we don't intend to be restrictive, and
> non-policy aware readers won't be confused.
>
> Can we say "the set of rules that IMPLEMENT the parameters and range of
> values ..."?  My problem is with the word DEFINES.

"Implements" is worse because the rules have nothing to do with
implementation (a standardization absolute).  If you think "defines"
crosses a boundary, I suggest "specifies".

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



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



From daemon@optimus.ietf.org  Mon Nov 19 03:58:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22785
	for <policy-archive@odin.ietf.org>; Mon, 19 Nov 2001 03:58:25 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA22656
	for policy-archive@odin.ietf.org; Mon, 19 Nov 2001 03:58:27 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21373;
	Mon, 19 Nov 2001 03:45:05 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21343
	for <policy@optimus.ietf.org>; Mon, 19 Nov 2001 03:45:03 -0500 (EST)
Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22435;
	Mon, 19 Nov 2001 03:44:59 -0500 (EST)
Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id JAA07332; Mon, 19 Nov 2001 09:44:27 +0100
Received: from dhcp22-51.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03)
          id AA45898 from <brian@hursley.ibm.com>; Mon, 19 Nov 2001 09:44:25 +0100
Message-Id: <3BF8C67D.9FF00C46@hursley.ibm.com>
Date: Mon, 19 Nov 2001 09:44:45 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
Mime-Version: 1.0
To: Andrea Westerinen <andreaw@cisco.com>
Cc: Scott Brim <swb@employees.org>, Dan Grossman <dan@dma.isg.mot.com>,
        "Diffserv@Ietf. Org" <diffserv@ietf.org>,
        "Policy@Ietf. Org" <policy@ietf.org>,
        "Bert Wijnen (Bert)" <bwijnen@lucent.com>
References: <GGEOLLMKEOKMFKADFNHOIENPEFAA.andreaw@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Policy] Re: FW: [Diffserv] Informal WG last call for
 draft-ietf-diffserv-new-terms-06.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org
Content-Transfer-Encoding: 7bit

The way we have taken to using the word "policy" in our technology is
a bit strange - in normal English, "policy" is more abstract and general
than a specific set of rules. Hence the problem, I think.

How about "express" instead of "define"?

   Brian 

Andrea Westerinen wrote:
> 
> But, my issue is with the word, "define" or "specify".  IMHO, the SLS
> "defines" the values or behavior, and the rules "act on" or "realize" the
> definition.  I didn't equate "implement" with "implementation", but I can
> see the problem with that word.
> 
> Does "realize" make it better or worse ("... the set of rules that realize
> the parameters and range ...")?
> 
> Andrea
> 
> -----Original Message-----
> From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf
> Of Scott Brim
> Sent: Sunday, November 18, 2001 2:45 PM
> To: Andrea Westerinen
> Cc: Dan Grossman; Diffserv@Ietf. Org; Policy@Ietf. Org; Bert Wijnen
> (Bert)
> Subject: Re: FW: [Diffserv] Informal WG last call for
> draft-ietf-diffserv-new-terms-06.txt
> 
> On Sat, Nov 17, 2001 05:55:31PM -0800, Andrea Westerinen wrote:
> > Focusing on #4.
> >
> > The text says ... "Therefore, the relationship between an SLS and a
> service
> > provisioning policy is that the latter is, in part, the set of rules that
> > define the parameters and range of values that may be in the former."
> >
> > <Dan> My inclination at this point is to leave it as it is, unless Andrea
> > can come
> > up with a concise sentence or two that can be dropped in.  I think that
> > policy
> > aware readers will understand that we don't intend to be restrictive, and
> > non-policy aware readers won't be confused.
> >
> > Can we say "the set of rules that IMPLEMENT the parameters and range of
> > values ..."?  My problem is with the word DEFINES.
> 
> "Implements" is worse because the rules have nothing to do with
> implementation (a standardization absolute).  If you think "defines"
> crosses a boundary, I suggest "specifies".
> 
> _______________________________________________

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



From daemon@optimus.ietf.org  Mon Nov 19 04:05:20 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22930
	for <policy-archive@odin.ietf.org>; Mon, 19 Nov 2001 04:05:20 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA23393
	for policy-archive@odin.ietf.org; Mon, 19 Nov 2001 04:05:21 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22067;
	Mon, 19 Nov 2001 03:52:22 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22032
	for <policy@optimus.ietf.org>; Mon, 19 Nov 2001 03:52:19 -0500 (EST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22652;
	Mon, 19 Nov 2001 03:52:13 -0500 (EST)
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fAJ8phE08479;
	Mon, 19 Nov 2001 00:51:43 -0800 (PST)
Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with SMTP id AAU61230;
	Mon, 19 Nov 2001 00:51:41 -0800 (PST)
From: "Andrea Westerinen" <andreaw@cisco.com>
To: "Brian E Carpenter" <brian@hursley.ibm.com>
Cc: "Scott Brim" <swb@employees.org>, "Dan Grossman" <dan@dma.isg.mot.com>,
        "Diffserv@Ietf. Org" <diffserv@ietf.org>,
        "Policy@Ietf. Org" <policy@ietf.org>,
        "Bert Wijnen \(Bert\)" <bwijnen@lucent.com>
Date: Mon, 19 Nov 2001 00:54:20 -0800
Message-ID: <GGEOLLMKEOKMFKADFNHOEEODEFAA.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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <3BF8C67D.9FF00C46@hursley.ibm.com>
Content-Transfer-Encoding: 7bit
Subject: [Policy] RE: FW: [Diffserv] Informal WG last call for   draft-ietf-diffserv-new-terms-06.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org
Content-Transfer-Encoding: 7bit

"Express" is better.  I am ok with that.
Thanks.
Andrea

-----Original Message-----
From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf
Of Brian E Carpenter
Sent: Monday, November 19, 2001 12:45 AM
To: Andrea Westerinen
Cc: Scott Brim; Dan Grossman; Diffserv@Ietf. Org; Policy@Ietf. Org; Bert
Wijnen (Bert)
Subject: Re: FW: [Diffserv] Informal WG last call for
draft-ietf-diffserv-new-terms-06.txt


The way we have taken to using the word "policy" in our technology is
a bit strange - in normal English, "policy" is more abstract and general
than a specific set of rules. Hence the problem, I think.

How about "express" instead of "define"?

   Brian

Andrea Westerinen wrote:
>
> But, my issue is with the word, "define" or "specify".  IMHO, the SLS
> "defines" the values or behavior, and the rules "act on" or "realize" the
> definition.  I didn't equate "implement" with "implementation", but I can
> see the problem with that word.
>
> Does "realize" make it better or worse ("... the set of rules that realize
> the parameters and range ...")?
>
> Andrea
>
> -----Original Message-----
> From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf
> Of Scott Brim
> Sent: Sunday, November 18, 2001 2:45 PM
> To: Andrea Westerinen
> Cc: Dan Grossman; Diffserv@Ietf. Org; Policy@Ietf. Org; Bert Wijnen
> (Bert)
> Subject: Re: FW: [Diffserv] Informal WG last call for
> draft-ietf-diffserv-new-terms-06.txt
>
> On Sat, Nov 17, 2001 05:55:31PM -0800, Andrea Westerinen wrote:
> > Focusing on #4.
> >
> > The text says ... "Therefore, the relationship between an SLS and a
> service
> > provisioning policy is that the latter is, in part, the set of rules
that
> > define the parameters and range of values that may be in the former."
> >
> > <Dan> My inclination at this point is to leave it as it is, unless
Andrea
> > can come
> > up with a concise sentence or two that can be dropped in.  I think that
> > policy
> > aware readers will understand that we don't intend to be restrictive,
and
> > non-policy aware readers won't be confused.
> >
> > Can we say "the set of rules that IMPLEMENT the parameters and range of
> > values ..."?  My problem is with the word DEFINES.
>
> "Implements" is worse because the rules have nothing to do with
> implementation (a standardization absolute).  If you think "defines"
> crosses a boundary, I suggest "specifies".
>
> _______________________________________________

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



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



From daemon@optimus.ietf.org  Mon Nov 19 08:57:05 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28760
	for <policy-archive@odin.ietf.org>; Mon, 19 Nov 2001 08:57:05 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA01734
	for policy-archive@odin.ietf.org; Mon, 19 Nov 2001 08:57:05 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01194;
	Mon, 19 Nov 2001 08:42:51 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01162
	for <policy@optimus.ietf.org>; Mon, 19 Nov 2001 08:42:49 -0500 (EST)
Received: from mail2.orchestream.com (mail2.orchestream.com [195.153.64.126])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28059
	for <policy@ietf.org>; Mon, 19 Nov 2001 08:42:48 -0500 (EST)
Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc0a83ffa57514317d9@mail2.orchestream.com> for <policy@ietf.org>;
 Mon, 19 Nov 2001 13:45:06 +0000
Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16])
	by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id NAA19711
	for <policy@ietf.org>; Mon, 19 Nov 2001 13:35:52 GMT
Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19)
	id <WX063JNY>; Mon, 19 Nov 2001 13:37:13 -0000
Message-ID: <CB1E59E84CE5D3118E5C00508B6D755501779FD7@s1000.orchestream.com>
From: "Da Silva, Pedro" <pdasilva@orchestream.com>
To: "'policy@ietf.org'" <policy@ietf.org>
Date: Mon, 19 Nov 2001 13:37:03 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Policy] managed element definition [sic]
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org


I can't seem to find a definition for the term 'managed element'. Most docs
mention 'e.g. interface' but I would imagine that a managed element is not
restricted to being something physical and specially not restricted to an
interface.
Can it be a logical element such as 'interface and direction' or a broader
physical/logical entity?

thanks,
Pedro

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



From daemon@optimus.ietf.org  Mon Nov 19 10:05:20 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02953
	for <policy-archive@odin.ietf.org>; Mon, 19 Nov 2001 10:05:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA04776
	for policy-archive@odin.ietf.org; Mon, 19 Nov 2001 10:05:20 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03899;
	Mon, 19 Nov 2001 09:48:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03873
	for <policy@optimus.ietf.org>; Mon, 19 Nov 2001 09:48:41 -0500 (EST)
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01855
	for <policy@ietf.org>; Mon, 19 Nov 2001 09:48:35 -0500 (EST)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA32668
	for <policy@ietf.org>; Mon, 19 Nov 2001 08:45:43 -0600
Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62])
	by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fAJEmWk258860
	for <policy@ietf.org>; Mon, 19 Nov 2001 09:48:32 -0500
Subject: Re: [Policy] managed element definition [sic]
To: policy@ietf.org
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OFF4EEDDC8.2EA59E72-ON85256B09.00516058@raleigh.ibm.com>
From: "Robert Moore" <remoore@us.ibm.com>
Date: Mon, 19 Nov 2001 09:50:04 -0500
X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.8 |June 18, 2001) at
 11/19/2001 09:48:32 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

(I had intended to copy the list on this reply to Pedro.)

Regards,
Bob

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

----- Forwarded by Robert Moore/Raleigh/IBM on 11/19/01 09:48 AM -----
                                                                                           
                    Robert Moore                                                           
                                         To:     "Da Silva, Pedro"                         
                    11/19/01 09:48       <pdasilva@orchestream.com>                        
                    AM                   cc:                                               
                                         From:   Robert Moore/Raleigh/IBM@IBMUS            
                                         Subject:     Re: [Policy] managed element         
                                         definition [sic](Document link: Robert Moore)     
                                                                                           
                                                                                           
                                                                                           
                                                                                           
                                                                                           
                                                                                           



Pedro,

The short answer to any of these "Can it be ...?" questions
is "Yes, it can."  Pardoning the MOF format, here's the
definition of ManagedElement from the CIM spec:

// ==================================================================
// ManagedElement
// ==================================================================
   [Abstract, Description (
     "ManagedElement is an abstract class that provides a common "
     "superclass (or top of the inheritance tree) for the "
     "non-association classes in the CIM Schema.")]
class CIM_ManagedElement {
      [MaxLen (64), Description (
        "The Caption property is a short textual description (one-"
        "line string) of the object.") ]
   string Caption;
      [Description (
        "The Description property provides a textual description of "
        "the object.") ]
   string Description;
};

So ManagedElement abstracts out *everything*, leaving, for
reasons of convenience, only the two textual description
properties.  It is the superclass for logical elements,
physical elements, users, policies, and everything else in
the CIM model.

Regards,
Bob

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



                                                                                              
                    "Da Silva,                                                                
                    Pedro"                 To:     "'policy@ietf.org'" <policy@ietf.org>      
                    <pdasilva@orches       cc:                                                
                    tream.com>             Subject:     [Policy] managed element definition   
                    Sent by:                [sic]                                             
                    policy-admin@iet                                                          
                    f.org                                                                     
                                                                                              
                                                                                              
                    11/19/01 08:37                                                            
                    AM                                                                        
                                                                                              
                                                                                              




I can't seem to find a definition for the term 'managed element'. Most docs
mention 'e.g. interface' but I would imagine that a managed element is not
restricted to being something physical and specially not restricted to an
interface.
Can it be a logical element such as 'interface and direction' or a broader
physical/logical entity?

thanks,
Pedro

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







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



From daemon@optimus.ietf.org  Mon Nov 19 11:02:58 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06352
	for <policy-archive@odin.ietf.org>; Mon, 19 Nov 2001 11:02:58 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA07029
	for policy-archive@odin.ietf.org; Mon, 19 Nov 2001 11:02:59 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06002;
	Mon, 19 Nov 2001 10:48:30 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05900
	for <policy@optimus.ietf.org>; Mon, 19 Nov 2001 10:48:25 -0500 (EST)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05496;
	Mon, 19 Nov 2001 10:48:23 -0500 (EST)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA29876; Mon, 19 Nov 2001 08:48:09 -0700 (MST)]
Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA11253; Mon, 19 Nov 2001 08:48:09 -0700 (MST)]
Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46])
	by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id KAA08931;
	Mon, 19 Nov 2001 10:48:06 -0500 (EST)
Message-Id: <200111191548.KAA08931@noah.dma.isg.mot.com>
X-Mailer: exmh version 1.6.7 5/3/96
To: "Andrea Westerinen" <andreaw@cisco.com>
cc: "Brian E Carpenter" <brian@hursley.ibm.com>,
        "Scott Brim" <swb@employees.org>,
        "Diffserv@Ietf. Org" <diffserv@ietf.org>,
        "Policy@Ietf. Org" <policy@ietf.org>,
        "Bert Wijnen \(Bert\)" <bwijnen@lucent.com>
In-reply-to: Your message of "Mon, 19 Nov 2001 00:54:20 EST."
             <GGEOLLMKEOKMFKADFNHOEEODEFAA.andreaw@cisco.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 19 Nov 2001 10:48:05 -0500
From: Dan Grossman <dan@dma.isg.mot.com>
Subject: [Policy] Re: FW: [Diffserv] Informal WG last call for
 draft-ietf-diffserv-new-terms-06.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

Express it will be.

> "Express" is better.  I am ok with that.
> Thanks.
> Andrea
> 
> -----Original Message-----
> From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf
> Of Brian E Carpenter
> Sent: Monday, November 19, 2001 12:45 AM
> To: Andrea Westerinen
> Cc: Scott Brim; Dan Grossman; Diffserv@Ietf. Org; Policy@Ietf. Org; Bert
> Wijnen (Bert)
> Subject: Re: FW: [Diffserv] Informal WG last call for
> draft-ietf-diffserv-new-terms-06.txt
> 
> 
> The way we have taken to using the word "policy" in our technology is
> a bit strange - in normal English, "policy" is more abstract and general
> than a specific set of rules. Hence the problem, I think.
> 
> How about "express" instead of "define"?
> 
>    Brian
> 
> Andrea Westerinen wrote:
> >
> > But, my issue is with the word, "define" or "specify".  IMHO, the SLS
> > "defines" the values or behavior, and the rules "act on" or "realize" the
> > definition.  I didn't equate "implement" with "implementation", but I can
> > see the problem with that word.
> >
> > Does "realize" make it better or worse ("... the set of rules that realize
> > the parameters and range ...")?
> >
> > Andrea
> >
> > -----Original Message-----
> > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf
> > Of Scott Brim
> > Sent: Sunday, November 18, 2001 2:45 PM
> > To: Andrea Westerinen
> > Cc: Dan Grossman; Diffserv@Ietf. Org; Policy@Ietf. Org; Bert Wijnen
> > (Bert)
> > Subject: Re: FW: [Diffserv] Informal WG last call for
> > draft-ietf-diffserv-new-terms-06.txt
> >
> > On Sat, Nov 17, 2001 05:55:31PM -0800, Andrea Westerinen wrote:
> > > Focusing on #4.
> > >
> > > The text says ... "Therefore, the relationship between an SLS and a
> > service
> > > provisioning policy is that the latter is, in part, the set of rules
> that
> > > define the parameters and range of values that may be in the former."
> > >
> > > <Dan> My inclination at this point is to leave it as it is, unless
> Andrea
> > > can come
> > > up with a concise sentence or two that can be dropped in.  I think that
> > > policy
> > > aware readers will understand that we don't intend to be restrictive,
> and
> > > non-policy aware readers won't be confused.
> > >
> > > Can we say "the set of rules that IMPLEMENT the parameters and range of
> > > values ..."?  My problem is with the word DEFINES.
> >
> > "Implements" is worse because the rules have nothing to do with
> > implementation (a standardization absolute).  If you think "defines"
> > crosses a boundary, I suggest "specifies".
> >
> > _______________________________________________
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> https://www1.ietf.org/mailman/listinfo/diffserv
> Archive:
> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
> tml
> 
> 



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



From daemon@optimus.ietf.org  Mon Nov 19 11:34:07 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08309
	for <policy-archive@odin.ietf.org>; Mon, 19 Nov 2001 11:34:07 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA08428
	for policy-archive@odin.ietf.org; Mon, 19 Nov 2001 11:34:09 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07495;
	Mon, 19 Nov 2001 11:13:29 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07466
	for <policy@optimus.ietf.org>; Mon, 19 Nov 2001 11:13:28 -0500 (EST)
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07117
	for <policy@ietf.org>; Mon, 19 Nov 2001 11:13:19 -0500 (EST)
Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208])
	by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA207958
	for <policy@ietf.org>; Mon, 19 Nov 2001 10:10:06 -0600
Received: from lrafalow (dyn9-27-58-155.raleigh.ibm.com [9.27.58.155])
	by southrelay01.raleigh.ibm.com (8.11.1m3/NCO v5.01) with SMTP id fAJGCso211560
	for <policy@ietf.org>; Mon, 19 Nov 2001 11:12:54 -0500
Message-ID: <005501c17115$23d57c50$9b3a1b09@lrafalow>
Reply-To: "Lee Rafalow" <rafalow@watson.ibm.com>
From: "Lee Rafalow" <rafalow@watson.ibm.com>
To: <policy@ietf.org>
References: <OFF4EEDDC8.2EA59E72-ON85256B09.00516058@raleigh.ibm.com>
Subject: Re: [Policy] managed element definition [sic]
Date: Mon, 19 Nov 2001 11:13:33 -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.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org
Content-Transfer-Encoding: 7bit

Pedro, Since you mention "e.g., interface," I assume you're refering to
managed element as used in the PCIMe aggregation into PolicyRoleCollection;
that is, managed elements that have a role in administering the
policies--the policy consumers.  If that's the case, then there's a subset
of the "any" that Bob referred to in his response.  To my knowledge, we have
not defined that subset in any document, but I find it useful to think of
resource managers.  So, for example, you may well have a resource manager
that has the roles of: "10/100 ethernet, "intranet," and "ingress," but the
resource manager itself (the managed element, e.g., interface, that has the
roles) may not have a property that specifies it is only for ingress.

IHTH, Lee

----- Original Message -----
From: "Robert Moore" <remoore@us.ibm.com>
To: <policy@ietf.org>
Sent: Monday, November 19, 2001 9:50 AM
Subject: Re: [Policy] managed element definition [sic]


> (I had intended to copy the list on this reply to Pedro.)
>
> Regards,
> Bob
>
> Bob Moore
> Advanced Design and Technology
> Application Integration Middleware Division
> IBM Software Group
> +1-919-254-4436
> remoore@us.ibm.com
>
> ----- Forwarded by Robert Moore/Raleigh/IBM on 11/19/01 09:48 AM -----
>
>                     Robert Moore
>                                          To:     "Da Silva, Pedro"
>                     11/19/01 09:48       <pdasilva@orchestream.com>
>                     AM                   cc:
>                                          From:   Robert
Moore/Raleigh/IBM@IBMUS
>                                          Subject:     Re: [Policy] managed
element
>                                          definition [sic](Document link:
Robert Moore)
>
>
>
>
>
>
>
>
>
> Pedro,
>
> The short answer to any of these "Can it be ...?" questions
> is "Yes, it can."  Pardoning the MOF format, here's the
> definition of ManagedElement from the CIM spec:
>
> // ==================================================================
> // ManagedElement
> // ==================================================================
>    [Abstract, Description (
>      "ManagedElement is an abstract class that provides a common "
>      "superclass (or top of the inheritance tree) for the "
>      "non-association classes in the CIM Schema.")]
> class CIM_ManagedElement {
>       [MaxLen (64), Description (
>         "The Caption property is a short textual description (one-"
>         "line string) of the object.") ]
>    string Caption;
>       [Description (
>         "The Description property provides a textual description of "
>         "the object.") ]
>    string Description;
> };
>
> So ManagedElement abstracts out *everything*, leaving, for
> reasons of convenience, only the two textual description
> properties.  It is the superclass for logical elements,
> physical elements, users, policies, and everything else in
> the CIM model.
>
> Regards,
> Bob
>
> Bob Moore
> Advanced Design and Technology
> Application Integration Middleware Division
> IBM Software Group
> +1-919-254-4436
> remoore@us.ibm.com
>
>
>
>

>                     "Da Silva,
>                     Pedro"                 To:     "'policy@ietf.org'"
<policy@ietf.org>
>                     <pdasilva@orches       cc:
>                     tream.com>             Subject:     [Policy] managed
element definition
>                     Sent by:                [sic]
>                     policy-admin@iet
>                     f.org
>
>
>                     11/19/01 08:37
>                     AM
>
>
>
>
>
>
> I can't seem to find a definition for the term 'managed element'. Most
docs
> mention 'e.g. interface' but I would imagine that a managed element is not
> restricted to being something physical and specially not restricted to an
> interface.
> Can it be a logical element such as 'interface and direction' or a broader
> physical/logical entity?
>
> thanks,
> Pedro
>
> _______________________________________________
> Policy mailing list
> Policy@ietf.org
> http://www1.ietf.org/mailman/listinfo/policy
>
>
>
>
>
>
>
> _______________________________________________
> Policy mailing list
> Policy@ietf.org
> http://www1.ietf.org/mailman/listinfo/policy


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



From daemon@optimus.ietf.org  Mon Nov 19 16:14:14 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25656
	for <policy-archive@odin.ietf.org>; Mon, 19 Nov 2001 16:14:14 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA16538
	for policy-archive@odin.ietf.org; Mon, 19 Nov 2001 16:14:15 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15806;
	Mon, 19 Nov 2001 15:56:37 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15775
	for <policy@optimus.ietf.org>; Mon, 19 Nov 2001 15:56:35 -0500 (EST)
Received: from longmail2.lboard.com ([63.109.116.89])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24629
	for <policy@ietf.org>; Mon, 19 Nov 2001 15:56:30 -0500 (EST)
Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21)
	id <XDBXANXN>; Mon, 19 Nov 2001 15:55:12 -0500
Message-ID: <F2F760C942EBD411B98800A0CC733FCF2FCB82@longmail2.lboard.com>
From: Ed Ellesson <eellesson@lboard.com>
To: "'policy@ietf.org'" <policy@ietf.org>
Cc: "'Joel M. Halpern'" <joel@stevecrocker.com>
Date: Mon, 19 Nov 2001 15:55:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Policy] Call for Agenda Items
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

Policy Enthusiasts:

Please reply this week with your requests for agenda time for our meeting in
Salt Lake City.

Please keep in mind that we have scheduled only one one-hour session this
time. 
(Tuesday, Dec. 11, 1700 - 1800)

Any agenda items should be oriented toward outstanding issue discussion and
resolution.  

We are expecting discussion on QPIM and QDDIM.  

QPIM: 

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

QDDIM: 

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

Authors, please let us know who you plan to have present on outstanding
issues, and how much time you need. 

Thanks, 
Ed and Joel
co-chairs, Policy Framework WG






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



From daemon@optimus.ietf.org  Mon Nov 19 16:47:19 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27732
	for <policy-archive@odin.ietf.org>; Mon, 19 Nov 2001 16:47:19 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA17453
	for policy-archive@odin.ietf.org; Mon, 19 Nov 2001 16:47:20 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16807;
	Mon, 19 Nov 2001 16:29:38 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16779
	for <policy@optimus.ietf.org>; Mon, 19 Nov 2001 16:29:36 -0500 (EST)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26553
	for <policy@ietf.org>; Mon, 19 Nov 2001 16:29:34 -0500 (EST)
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fAJLT6l17783;
	Mon, 19 Nov 2001 13:29:06 -0800 (PST)
Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with SMTP id AAU76632;
	Mon, 19 Nov 2001 13:29:03 -0800 (PST)
From: "Andrea Westerinen" <andreaw@cisco.com>
To: "Da Silva, Pedro" <pdasilva@orchestream.com>, <policy@ietf.org>
Subject: RE: [Policy] managed element definition [sic]
Date: Mon, 19 Nov 2001 13:31:41 -0800
Message-ID: <GGEOLLMKEOKMFKADFNHOMEPFEFAA.andreaw@cisco.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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <CB1E59E84CE5D3118E5C00508B6D755501779FD7@s1000.orchestream.com>
Content-Transfer-Encoding: 7bit
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org
Content-Transfer-Encoding: 7bit

Pedro, If you look at the Policy Terminology draft
(http://search.ietf.org/internet-drafts/draft-ietf-policy-terminology-04.txt
), it uses the term, "managed element", in several places.  It is always
used in the generic context of an element that is managed (such as an
interface, network device or service/functionality).  This is in line with
Bob's reply.

Andrea

-----Original Message-----
From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of
Da Silva, Pedro
Sent: Monday, November 19, 2001 5:37 AM
To: 'policy@ietf.org'
Subject: [Policy] managed element definition [sic]



I can't seem to find a definition for the term 'managed element'. Most docs
mention 'e.g. interface' but I would imagine that a managed element is not
restricted to being something physical and specially not restricted to an
interface.
Can it be a logical element such as 'interface and direction' or a broader
physical/logical entity?

thanks,
Pedro

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


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



From daemon@optimus.ietf.org  Wed Nov 21 08:17:25 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12792
	for <policy-archive@odin.ietf.org>; Wed, 21 Nov 2001 08:17:25 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA06278
	for policy-archive@odin.ietf.org; Wed, 21 Nov 2001 08:17:25 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05596;
	Wed, 21 Nov 2001 07:54:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05565
	for <policy@optimus.ietf.org>; Wed, 21 Nov 2001 07:54:24 -0500 (EST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11865
	for <policy@ietf.org>; Wed, 21 Nov 2001 07:54:24 -0500 (EST)
Received: from kaspit.cisco.com (kaspit.cisco.com [144.254.91.49])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fALCrs818527
	for <policy@ietf.org>; Wed, 21 Nov 2001 04:53:54 -0800 (PST)
Received: from YSNIRW2K (dhcp-net-sup-64-103-112-161.cisco.com [64.103.112.161])
	by kaspit.cisco.com (Mirapoint)
	with SMTP id ACB19261;
	Wed, 21 Nov 2001 15:53:52 +0300 (GMT-3)
Reply-To: <ysnir@cisco.com>
From: "Yoram Snir" <ysnir@cisco.com>
To: <policy@ietf.org>
Date: Wed, 21 Nov 2001 14:54:29 +0200
Message-ID: <005201c1728b$a9250200$a1706740@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 CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Policy] (no subject)
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org
Content-Transfer-Encoding: 7bit

Policy WG members
The QPIM-04 draft is available from the IETF repository
[http://search.ietf.org/internet-drafts/draft-ietf-policy-qos-info-model-04.
txt].

The draft includes clarifications and fixes to all the comments received
from the working group. The draft also includes minor changes to be
compatible with the latest PCIMe draft.
Following are the changes and clarifications from QPIM-03 to QPIM-04:
1.	Required updates as a result from the latest changes in PCIMe (v6).
2.	Clarification on the relationships between PCIMe and QPIM in regard with
Policy Roles. QPIM does not add to PCIMe resources tagging, using roles. It
only provides and example of usage.
3.	Clarifications on what QPIM covers in relation with PCIM, PCIMe and other
Policy drafts.
4.	Rule hierarchy was explained in order to answer the WG comments and
concerns.
5.	Clarifications were added regarding the use of the SimplePolicyCondition
and theSimplePolicyAction classes.
6.	The relationships between "high level" policy information models like
PCIM & QPIM and "low level" information models like QDDIM and PIB were
explained.
7.	Usage of CIM, PCIMe and QPIM as an information model for QoS policy was
explained.
8.	Clarification and rewriting of the QoS policy action sections including
examples of usage.
9.	Threshold hierarchy example added to the action section.
10.	Fixes of typos in the inheritance class hierarchy.
11.	PCIMe execution strategies used in examples were explicitly defined. It
was not done so in previous versions since this issue was still debated at
that time, in the context of PCIMe.
12.	The relationship between a zero excess burst size and the three action
associations was clarified.
13.	Clarifying text was added to the section about the admission decision of
RSVP flows.
14.	Associations' cardinality cleanup as well as other typos in class
definitions fixed.
15.	Alignment with PCIMe values/variables
16.   Alignment with PCIMe value types
17.   Cosmetic changes including terminology, editing and spelling mistakes.

Summary: There are no known outstanding issues. We propose to move the draft
to 'last call'.

Yoram et al.


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



From daemon@optimus.ietf.org  Wed Nov 21 08:30:29 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13383
	for <policy-archive@odin.ietf.org>; Wed, 21 Nov 2001 08:30:29 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA06763
	for policy-archive@odin.ietf.org; Wed, 21 Nov 2001 08:30:29 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06238;
	Wed, 21 Nov 2001 08:14:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06199
	for <policy@optimus.ietf.org>; Wed, 21 Nov 2001 08:14:23 -0500 (EST)
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12701;
	Wed, 21 Nov 2001 08:14:22 -0500 (EST)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA63918;
	Wed, 21 Nov 2001 07:11:24 -0600
Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62])
	by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fALDEKM73538;
	Wed, 21 Nov 2001 08:14:20 -0500
Subject: Re: [Policy] Call for Agenda Items
To: Ed Ellesson <eellesson@lboard.com>
Cc: "'Joel M. Halpern'" <joel@stevecrocker.com>,
        "'policy@ietf.org'" <policy@ietf.org>, policy-admin@ietf.org
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OFC69820F2.531AE330-ON85256B0B.0048AC63@raleigh.ibm.com>
From: "Robert Moore" <remoore@us.ibm.com>
Date: Wed, 21 Nov 2001 08:15:54 -0500
X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.8 |June 18, 2001) at
 11/21/2001 08:14:20 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org


Ed,

A small correction: the document people should read
is QDDIM-06, not QDDIM-05.  I submitted QDDIM-06 to
the I-D repository yesterday afternoon, so it should
be available there by early next week.

Regards,
Bob

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



                                                                                            
                    Ed Ellesson                                                             
                    <eellesson@lbo       To:     "'policy@ietf.org'" <policy@ietf.org>      
                    ard.com>             cc:     "'Joel M. Halpern'"                        
                    Sent by:              <joel@stevecrocker.com>                           
                    policy-admin@i       Subject:     [Policy] Call for Agenda Items        
                    etf.org                                                                 
                                                                                            
                                                                                            
                    11/19/01 03:55                                                          
                    PM                                                                      
                                                                                            
                                                                                            



Policy Enthusiasts:

Please reply this week with your requests for agenda time for our meeting
in
Salt Lake City.

Please keep in mind that we have scheduled only one one-hour session this
time.
(Tuesday, Dec. 11, 1700 - 1800)

Any agenda items should be oriented toward outstanding issue discussion and
resolution.

We are expecting discussion on QPIM and QDDIM.

QPIM:

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

QDDIM:

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

05.txt

Authors, please let us know who you plan to have present on outstanding
issues, and how much time you need.

Thanks,
Ed and Joel
co-chairs, Policy Framework WG






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





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



From daemon@optimus.ietf.org  Mon Nov 26 11:27:07 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08341
	for <policy-archive@odin.ietf.org>; Mon, 26 Nov 2001 11:27:07 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA13782
	for policy-archive@odin.ietf.org; Mon, 26 Nov 2001 11:27:10 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13134;
	Mon, 26 Nov 2001 11:10:36 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13086
	for <policy@optimus.ietf.org>; Mon, 26 Nov 2001 11:10:33 -0500 (EST)
Received: from argyre.fr.uu.net (mail.fr.uu.net [194.98.0.9])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07121
	for <policy@ietf.org>; Mon, 26 Nov 2001 11:10:29 -0500 (EST)
From: annuaire@annuairefrancais.com
Received: from [213.11.39.71] ([213.11.39.71])
	by argyre.fr.uu.net (8.9.3/8.8.7) with SMTP id RAA25734
	for <policy@ietf.org>; Mon, 26 Nov 2001 17:17:09 +0100 (MET)
Message-Id: <200111261617.RAA25734@argyre.fr.uu.net>
Mime-Version: 1.0
Content-Type: text/plain;charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Mon, 26 Nov 2001 17:09:28 +0100
To: policy@ietf.org
Content-Transfer-Encoding: 7bit
Subject: [Policy] Info : L'Annuaire Francais par Departement facilite vos recherches
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org
Content-Transfer-Encoding: 7bit

Bonjour,

L'annuaire Francais Par departement http://www.annuairefrancais.com integre desormais un moteur de recherche pour affiner vos recherches sur le web.

L'inscription reste gratuite et la validation toujours manuelle. L'adresse d'inscription est desormais http://inscrip.annuairefrancais.com

Pour toutes suggestions contactez par mail :
direction : laurent@annuairefrancais.com
validation : validation@annuairefrancais.com
publicite : publicite@annuairefrancais.com
partenariat : partenariat@annuairefrancais.com

INFORMATIONS :
retrait de notre liste d'info : http://supressinfo.annuairefrancais.com
(L'annuaire francais envoi 2 infos par an)

L'annuaire Francais
119 Rue des Pyrenees
75020 PARIS
+33 (0)1 43 67 00 74

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



From daemon@optimus.ietf.org  Wed Nov 28 05:10:40 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27235
	for <policy-archive@odin.ietf.org>; Wed, 28 Nov 2001 05:10:40 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA17254
	for policy-archive@odin.ietf.org; Wed, 28 Nov 2001 05:10:43 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16547;
	Wed, 28 Nov 2001 04:51:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16514
	for <policy@optimus.ietf.org>; Wed, 28 Nov 2001 04:51:09 -0500 (EST)
Received: from mail.bigsale.com ([203.248.138.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27047
	for <policy@ietf.org>; Wed, 28 Nov 2001 04:51:04 -0500 (EST)
Received: from sslee ([211.171.1.156])
	by mail.bigsale.com (8.9.3/8.9.3) with SMTP id DAA07787
	for <policy@ietf.org>; Thu, 29 Nov 2001 03:18:56 +0900
Message-Id: <200111281818.DAA07787@mail.bigsale.com>
From: admin <admin@bojimolca.com>
To: policy@ietf.org
X-Mailer: Microsoft Outlook Express 5.00.2615.200
Reply-To: admin@bojimolca.com
Date: Wed, 28 Nov 2001 18:51:13 +0900
Mime-Version: 1.0
Content-Type: text/html; charset=ks_c_5601-1987
Subject: [Policy] [±ä±Þ°øÁö] µåµð¾î ¿ÀǵǾú½À´Ï´Ù.
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org


<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=ks_c_5601-1987">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>È­Á¦ÀÇ H¾çºñµð¿À</title>
</head>

<body>

<table align="center" bgColor="black" cellPadding="0" cellSpacing="0" width="477">
  <tbody>
    <tr>
      <td colSpan="2" vAlign="top" width="477">
        <table cellPadding="0" cellSpacing="0">
          <tbody>
            <tr>
              <td rowSpan="2" width="230">
                <p><b><font color="#FFFFFF" size="6"><a href="http://www.bojimolca.com" target="new">
                <font color="#FF0000">º¸Áö¸ôÄ«´åÄÄ</font></a></font></b></p>
              </td>
              <td width="230">
                <p><font color="red"><span style="FONT-SIZE: 9pt">&nbsp;&nbsp;</span></font><a href="http://www.bojimolca.com" target="new"><span style="FONT-SIZE: 9pt"><font color="red">È­Á¦ÀÇ
                H¾çºñµð¿À.¿©´ë»ýÀÇ ÇÏ·ç......</font></span></a></p>
              </td>
            </tr>
            <tr>
              <td width="230">
                <p><font color="red"><span style="FONT-SIZE: 9pt">&nbsp;&nbsp;</span></font><a href="http://www.bojimolca.com" target="new"><span style="FONT-SIZE: 9pt"><font color="red">ÆäƼ½¬.¸ôÄ«.XXXÀϺ»
                µ¿¿µ»ó,¼½½º¾ß»ç..</font></span></a></p>
              </td>
            </tr>
          </tbody>
        </table>
      </td>
    </tr>
    <tr>
      <td height="268" rowSpan="2" width="363">
        <p align="center"><a href="http://www.bojimolca.com" target="new"><img border="0" height="267" src="http://sexsextv.co.kr/img/Image1.gif" width="363"></a></p>
      </td>
      <td width="114">
        <p align="center"><a href="http://www.bojimolca.com" target="new"><img border="0" src="http://sexsextv.co.kr/img/Image7.gif" width="112" height="131"></a></p>
      </td>
    </tr>
    <tr>
      <td height="103" width="114">
        <p align="center"><a href="http://www.bojimolca.com" target="new"><img border="0" height="131" src="http://sexsextv.co.kr/img/Image6.gif" width="109"></a></p>
      </td>
    </tr>
    <tr>
      <td colSpan="2" height="76" width="477">
        <p align="center"><a href="http://www.bojimolca.com" target="new"><img border="0" src="http://sexsextv.co.kr/img/Image18.gif" width="475" height="74"></a></p>
      </td>
    </tr>
    <tr>
      <td colSpan="2" height="79" width="477">
        <p align="center" style="LINE-HEIGHT: 100%; MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px">¡¡
        <p style="LINE-HEIGHT: 100%; MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px">
        <marquee behavior="alternate"></marquee>
        <a href="http://www.bojimolca.com" target="new">
        <img border="0" src="http://img.69sexual.com/intro/photo_03.gif" width="152" height="110"><img border="0" src="http://img.69sexual.com/intro/photo_01.gif" width="154" height="110"><img border="0" src="http://img.69sexual.com/intro/photo_02.gif" width="152" height="110"><img border="0" src="http://img.69sexual.com/intro/photo_03.gif" width="152" height="110"><img border="0" src="http://img.69sexual.com/intro/photo_04.gif" width="152" height="110"><img border="0" src="http://img.69sexual.com/intro/photo_05.gif" width="148" height="110"><img border="0" height="110" src="http://img.69sexual.com/intro/photo_06.jpg" width="148"><img border="0" height="110" src="http://img.69sexual.com/intro/photo_07.jpg" width="152">
        <img border="0" src="http://img.69sexual.com/intro/photo_03.gif" width="152" height="110"><img border="0" height="110" src="http://img.69sexual.com/intro/photo_08.jpg" width="152"><img border="0" height="110" src="http://img.69sexual.com/intro/photo_09.jpg" width="152"><img border="0" src="http://img.69sexual.com/intro/photo_03.gif" width="152" height="110"></p>
        </a>
      </td>
    </tr>
  </tbody>
</table>
<p>¡¡</p>

</body>

</html>

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



From daemon@optimus.ietf.org  Wed Nov 28 06:25:09 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00461
	for <policy-archive@odin.ietf.org>; Wed, 28 Nov 2001 06:25:09 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA21339
	for policy-archive@odin.ietf.org; Wed, 28 Nov 2001 06:25:11 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19447;
	Wed, 28 Nov 2001 05:59:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19418
	for <policy@optimus.ietf.org>; Wed, 28 Nov 2001 05:59:40 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29122;
	Wed, 28 Nov 2001 05:59:35 -0500 (EST)
Message-Id: <200111281059.FAA29122@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: policy@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 28 Nov 2001 05:59:35 -0500
Subject: [Policy] I-D ACTION:draft-ietf-policy-qos-device-info-model-06.txt
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Policy Framework Working Group of the IETF.

	Title		: Information Model for Describing Network Device QoS 
                          Mechanisms
	Author(s)	: B. Moore, D. Durham, J. Strassner, A. Westerinen, 
                          W. Weiss, J. Halpern
	Filename	: draft-ietf-policy-qos-device-info-model-06.txt
	Pages		: 91
	Date		: 27-Nov-01
	
The purpose of this draft is to define an information model to
describe the quality of service (QoS) mechanisms inherent in
different network devices, including hosts.  Broadly speaking,
these mechanisms describe the attributes common to selecting and
conditioning traffic through the forwarding path (datapath) of a
network device.  This selection and conditioning of traffic in
the datapath spans both major QoS architectures: Differentiated
Services (see [R2475]) and Integrated Services (see [R1633]).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device-info-model-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-policy-qos-device-info-model-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-policy-qos-device-info-model-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20011127135557.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-policy-qos-device-info-model-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-policy-qos-device-info-model-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011127135557.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Wed Nov 28 06:40:33 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01194
	for <policy-archive@odin.ietf.org>; Wed, 28 Nov 2001 06:40:33 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA22071
	for policy-archive@odin.ietf.org; Wed, 28 Nov 2001 06:40:35 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21088;
	Wed, 28 Nov 2001 06:20:28 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21060
	for <policy@optimus.ietf.org>; Wed, 28 Nov 2001 06:20:25 -0500 (EST)
Received: from comex1.hkcg.com (comex1.hkcg.com [202.84.208.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00276
	for <policy@ietf.org>; Wed, 28 Nov 2001 06:20:22 -0500 (EST)
Received: by COMEX1 with Internet Mail Service (5.5.2653.19)
	id <V7T1WJPP>; Wed, 28 Nov 2001 19:20:32 +0800
Message-ID: <B3C3D3ED61A3D511B6FA00508B5EEDC885369B@comex4>
From: System Attendant <COMEX4-SA@hkcg.com>
To: "'policy@ietf.org'" <policy@ietf.org>
Date: Wed, 28 Nov 2001 19:20:29 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [Policy] ScanMail Message: To Recipient virus found and action taken.
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

ScanMail for Microsoft Exchange has detected virus-infected attachment(s).

Sender = Internet-Drafts@ietf.org
Recipient(s) = policy@ietf.org
Subject = [Policy] I-D ACTION:draft-ietf-policy-qos-device-info-model-06.txt
Scanning Time = 11/28/2001 19:20:28

Action on virus found:
The attachment draft-ietf-policy-qos-device-info-model-06.url matched file
blocking settings. ScanMail has Deleted it. 

Warning to recipient. ScanMail has removed an attachment which contains
virus or blocked file type!  If this mail is from Internet, the sender don't
know his/her attachment has been removed.  Please ask the sender to clean
and re-send or remove the blocked attachment.

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



From daemon@ns.ietf.org  Thu Nov 29 13:05:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27346
	for <policy-archive@odin.ietf.org>; Thu, 29 Nov 2001 13:05:26 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA23065
	for policy-archive@odin.ietf.org; Thu, 29 Nov 2001 13:05:27 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22040;
	Thu, 29 Nov 2001 12:34:16 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22008
	for <policy@ns.ietf.org>; Thu, 29 Nov 2001 12:34:10 -0500 (EST)
Received: from longmail2.lboard.com ([63.109.116.89])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24454
	for <policy@ietf.org>; Thu, 29 Nov 2001 12:34:09 -0500 (EST)
Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21)
	id <XDBXAPLF>; Thu, 29 Nov 2001 12:32:43 -0500
Message-ID: <F2F760C942EBD411B98800A0CC733FCF2FCBA0@longmail2.lboard.com>
From: Ed Ellesson <eellesson@lboard.com>
To: "'policy@ietf.org'" <policy@ietf.org>
Cc: "'Joel M. Halpern'" <joel@stevecrocker.com>
Date: Thu, 29 Nov 2001 12:32:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Policy] Policy WG Agenda
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

Salt Lake City Agenda for Policy Framework WG:

We are planning on submitting this to the agenda folks shortly:

(We are scheduled for one session, for 1 hour,  late Tuesday afternoon, 1700
- 1800)

1. Agenda Bash:  (Ed) 5 minutes

2. Review of document status (Joel)  5 minutes

http://www.ietf.org/internet-drafts/draft-ietf-policy-core-schema-13.txt
(pcls)
http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info-model-04.txt
(qpim)
http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device-info-model-
06.txt  (qddim)
http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-04.txt
(polterm)
http://www.ietf.org/internet-drafts/draft-ietf-policy-pcim-ext-06.txt
(pcime)

3. QDDIM Issues (Joel) 30 minutes  

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

4. QPIM Issues (Yoram)  10 minutes

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

5. Wrap-up (Ed)  5 minutes

Note: Marcus, we can give you some mic time to talk about experience in
applying these concepts to MPLS, perhaps during or after the appropriate
document issues presentation(s).  

Ed and Joel

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



From daemon@ns.ietf.org  Thu Nov 29 14:51:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06516
	for <policy-archive@odin.ietf.org>; Thu, 29 Nov 2001 14:51:10 -0500 (EST)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA26701
	for policy-archive@odin.ietf.org; Thu, 29 Nov 2001 14:51:12 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25573;
	Thu, 29 Nov 2001 14:24:02 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25544
	for <policy@ns.ietf.org>; Thu, 29 Nov 2001 14:24:00 -0500 (EST)
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04027
	for <policy@ietf.org>; Thu, 29 Nov 2001 14:23:31 -0500 (EST)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA88626
	for <policy@ietf.org>; Thu, 29 Nov 2001 13:20:24 -0600
Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62])
	by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fATJNTH287178
	for <policy@ietf.org>; Thu, 29 Nov 2001 14:23:29 -0500
To: policy@ietf.org
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OFAB955702.F8049290-ON85256B13.006A5A81@raleigh.ibm.com>
From: "Robert Moore" <remoore@us.ibm.com>
Date: Thu, 29 Nov 2001 14:25:20 -0500
X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.8 |June 18, 2001) at
 11/29/2001 02:23:28 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: [Policy] List of changes / open issues list for QDDIM-06
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Policy Framework <policy.ietf.org>
X-BeenThere: policy@ietf.org

The draft:

QDDIM-06: draft-ietf-policy-qos-device-info-model-06.txt

Technical changes since QDDIM-05:

1. PreambleFilter / PreambleMarkerService generalized
   (3.8.3, 4.3.13, 4.3.34).

2. Queue / Dropper updates (3.10, 3.10.2, 4.3.30, 4.4.6).

3. HeadTailDropQueueBinding clarified (3.10, 3.10.1).

4. Cardinality change for ElementInSchedulingService
   (4.4.28).

5. QoSService moved to inherit directly from Service
   (4.2, 4.3.23).

6. AllocationPercentage property added to the
   QueueAllocation association (4.4.10).

Issues to discuss in SLC (or on the list) for QDDIM-06:

1. Global: how do we apply here the lessons learned in
   PCLS and PCIMe related to specifying agent behavior
   in response to unexpected / illegal values?  We can
   use the new property AllocationPercentage as the
   basis for discussion:

       What is the agent supposed to do if, say, two
       or more queues are each supposed to get 100%
       of a pool?  Or three queues each get 40%, and
       one gets 20%?  Or what if one queue gets 60%,
       and no value at all is supplied for the
       remaining queues?

   The goal is to strike the right balance between
   saying too much to address these cases and saying
   too little. (Andrea?)

2. It would help scalability if we had a way to represent
   reusable combinations of ClassifierElements, very
   similar to CompoundPolicyConditions, which could be
   combined to form Classifiers.  It's not clear,
   though, what the best way might be to add these to
   the QDDIM model.  (Walter)

3. Alignment of QDDIM's BufferPool class with CIM's
   StoragePool class.  (Andrea)

4. QoSService subclasses: Why would anyone create a
   DSCP=4 DiffServService?  Why wouldn't you classify
   and then process using the ConditioningServices?
   A specific example is needed since the DiffServ MIB,
   PIB and model work without these classes, and they
   appear to overlap with the ClassifierElements.
   (Andrea)

Since I'm not going to be coming to SLC, Joel will be
leading this discussion during the WG meeting.

Regards,
Bob

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



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