From mailnull@www1.ietf.org Tue Jun 3 09:21:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03547 for ; Tue, 3 Jun 2003 09:21:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53DLKN13382 for policy-archive@odin.ietf.org; Tue, 3 Jun 2003 09:21:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53DH5B13071; Tue, 3 Jun 2003 09:17:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53DFgB12976 for ; Tue, 3 Jun 2003 09:15:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03330 for ; Tue, 3 Jun 2003 09:15:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NBbq-0005pc-00 for policy@ietf.org; Tue, 03 Jun 2003 09:13:50 -0400 Received: from mx-relay21.treas.gov ([199.196.132.5]) by ietf-mx with esmtp (Exim 4.12) id 19NBbq-0005pY-00 for policy@ietf.org; Tue, 03 Jun 2003 09:13:50 -0400 Received: from TIAS24.net.treas.gov (tias24.treas.gov [199.196.132.24]) by mx-relay21.treas.gov (8.12.9/8.12.9) with SMTP id h53D1fRf010041; Tue, 3 Jun 2003 09:01:43 -0400 (EDT) Received: from no.name.available by TIAS24.net.treas.gov via smtpd (for [199.196.132.5]) with SMTP; 3 Jun 2003 13:15:34 UT Received: from irsbd1.net.treas.gov (localhost [127.0.0.1]) by mailhub-23.net.treas.gov (8.12.9/8.12.9) with ESMTP id h53DFSZo023900; Tue, 3 Jun 2003 09:15:28 -0400 (EDT) Received: from no.name.available by irsbd1.net.treas.gov via smtpd (for mailhub.net.treas.gov [10.13.252.13]) with ESMTP; Tue, 3 Jun 2003 13:15:28 +0000 Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1]) by big-al.indy.cr.irs.gov (8.11.2/8.9.3) with ESMTP id h53DFRb19729; Tue, 3 Jun 2003 08:15:27 -0500 Message-ID: <3EDC9F6F.6090802@parnelli.indy.cr.irs.gov> Date: Tue, 03 Jun 2003 08:15:27 -0500 From: "Larry S. Bartz" Organization: Internal Revenue Service User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Joel M. Halpern" CC: policy@ietf.org, Randy Bush , Ed Ellesson , "Wijnen, Bert (Bert)" Subject: Re: PCLS when? [was: Re: [Policy] Approved: draft-ietf-policy-core-schema-16.txt] References: <3EB7DEC4.3000600@parnelli.indy.cr.irs.gov> <3EB7DEC4.3000600@parnelli.indy.cr.irs.gov> <5.1.0.14.0.20030514101359.0228a158@mail.stevecrocker.com> In-Reply-To: <5.1.0.14.0.20030514101359.0228a158@mail.stevecrocker.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Joel M. Halpern wrote, On 05/14/03 09:15: > At the moment I am still operating on the assumption that the IESG will > get the user schema document unstuck. We went through a lot of > discussion in earlier reviews to arrive at the agreement that we would > use that document as the basis for those aspects of our LDAP work. > I am loath to attempt to change that conclusion unless the AD informs us > that the zeilenga document will not be going forward. > > Yours, > Joel M. Halpern Joel, all, It has now been nearly seven months since we were advised that the PCLS (Policy Core LDAP Schema) was approved by the IESG. Why can't the RFC be published? How long must PCLS wait for the draft (draft-zeilenga-ldap-user-schema) upon which it unnecessarily depends? According to the IETF's Internet Draft Status Tracker facility, the status of draft-zeilenga- ldap-user-schema has not changed since April 17. Is it reasonable for PCLS to wait upon an activity which is apparently not making progress? I have reviewed the archives of this (Policy WG) list and cannot find any of the discussion to which Joel refers, above. I could have simply missed it. Is there some documentation of "a lot of discussion in earlier reviews..."? I reiterate: I haven't seen a convincing argument for retaining PCLS's dependency upon draft-zeilenga-ldap-user-schema. Please see my note of 05/06/03, included below. For real, Larry > > At 07:57 AM 5/14/2003 -0500, Larry S. Bartz wrote: > >> Now it has been *six* months since the PCLS (Policy Core LDAP Schema) >> draft entered the RFC Editor's Queue. When will the RFC be published? >> >> I haven't seen a convincing argument for retaining PCLS's dependency >> upon draft-zeilenga-ldap-user-schema. >> >> Larry >> >> >> Larry S. Bartz wrote, On 05/06/03 11:11: >> >>> Mircea, all, >>> Reference to X.520 (for which there is already a normative reference >>> in the draft) is the *only* normative reference which is necessary to >>> cover the three matching rules. >>> X.520 defines booleanMatch, octetStringOrderingMatch, and >>> integerOrderingMatch. >>> Where draft-zeilenga-ldap-user-schema speaks of these three matching >>> rules, it does little more than re-state X.520. There is no doubt >>> about consensus regarding the origins and semantics of booleanMatch, >>> octetStringOrderingMatch, and integerOrderingMatch. >>> To remove the normative reference to draft-zeilenga-ldap-user-schema >>> is simply to remove a redundancy. Removing the normative reference to >>> draft-zeilenga-ldap-user-schema does not leave draft-ietf-policy-core >>> -schema-16 without a normative reference for the three matching rules. >>> Larry >>> >>> Pana, Mircea wrote, On 05/06/03 10:36: >>> >>>> Larry, >>>> >>>> I don't have a strong opinion about the booleanMatch and wrt. the >>>> octetStringOrderingMatch I don't even see where it might be necessary. >>>> However, the integerOrderingMatch might be critical to some policy >>>> aplications. Therefore, as much as I'd like to see this ID progress >>>> to RFC, >>>> I believe that the removal of the normative reference is detrimental >>>> to this >>>> document. >>>> >>>> I know that some Directory vendors already implement these matching >>>> rules. >>>> The problem is that, without a normative document, each vendor might >>>> implement different behavior for the same rule... >>>> >>>> Mircea. >>>> >>>> >>>> -----Original Message----- >>>> From: Larry S. Bartz [mailto:lbartz@parnelli.indy.cr.irs.gov] >>>> Sent: Monday, May 05, 2003 2:33 PM >>>> To: Wijnen, Bert (Bert) >>>> Cc: RFC Editor; Randy Bush; policy@ietf.org; Joel M. Halpern; Ed >>>> Ellesson >>>> Subject: Re: [Policy] Approved: draft-ietf-policy-core-schema-16.txt >>>> >>>> >>>> I raised the following points last week, but didn't get a rise >>>> out of anybody... >>>> >>>> draft-ietf-policy-core-schema-16 uses three matching rules which >>>> haven't been explicitly defined as standard LDAP matching rules. They >>>> are booleanMatch, integerOrderingMatch, and octetStringOrderingMatch. >>>> These matching rules are the subject of draft-ietf-policy-core-schema- >>>> 16's dependence upon draft-zeilenga-ldap-user-schema. >>>> >>>> What does "adapted for use in LDAP" mean for those matching rules? >>>> According to draft-zeilenga-ldap-user-schema, the "adaptation" is >>>> little more than a restatement of the X.520 definitions. Obviously, >>>> X.520 provides the consensus-supported definitions for booleanMatch, >>>> integerOrderingMatch, and octetStringOrderingMatch. >>>> >>>> Some LDAP-conformant server implementations already support >>>> booleanMatch, integerOrderingMatch, and octetStringOrderingMatch in >>>> conformance with their X.520 definitions. Does it matter that these >>>> X.520-defined matching rules are not yet defined in an LDAP-specific >>>> RFC? The server doesn't care. The schema doesn't care. The applications >>>> which use the server and the schema don't care, either. >>>> >>>> Rough consensus and working code, right? How could consensus get any >>>> better for these three matching rules than it already is? I realize >>>> that >>>> Kurt, the ldapbis WG, and the IETF are working very hard to make LDAP >>>> more concise, precise, and complete. This is Good Work. But in the case >>>> of draft-ietf-policy-core-schema-16 and these three matching rules, if >>>> the subject of the normative reference at issue here isn't immediately >>>> forthcoming, there really isn't a good reason for draft-ietf-policy- >>>> core-schema-16 to wait any longer. >>>> >>>> If draft-zeilenga-ldap-user-schema still has serious issues, why not >>>> defer to pragmatism, drop the reference, and move on? >>>> >>>> Larry >>>> >>>> >>>> Wijnen, Bert (Bert) wrote, On 05/05/03 12:59: >>>> >>>>> RFC-Editor (and policy FW WG) >>>>> >>>>> As far as my current understanding of the issues, it is NOT >>>>> acceptable to remove this normative reference. >>>>> >>>>> I am working in the IESG to try and get that normative document >>>>> approved. But there are still serious issues with it, so things >>>>> are not going smooth/fast. >>>>> >>>>> Thanks, >>>>> Bert >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: RFC Editor [mailto:rfc-editor@rfc-editor.org] >>>>>> Sent: maandag 5 mei 2003 19:35 >>>>>> To: Bert Wijnen; Randy Bush >>>>>> Cc: policy@ietf.org; Joel M. Halpern; Ed Ellesson; RFC Editor; >>>>>> lbartz@parnelli.indy.cr.irs.gov >>>>>> Subject: Re: [Policy] Approved: draft-ietf-policy-core-schema-16.txt >>>>>> >>>>>> >>>>>> Bert and Randy, >>>>>> >>>>>> Could you please let us know if removal of the normative reference is >>>>>> an acceptable resolution to unblocking >>>>>> ? >>>>>> Thanks, >>>>>> >>>>>> RFC Editor >>>>>> >>>>>> >>>>>> On Mon, Apr 21, 2003 at 09:38:43AM -0500, Larry S. Bartz wrote: >>>>>> >>>>>> >>>>>>> Larry S. Bartz wrote, On 04/10/03 07:26: >>>>>>> >>>>>>> >>>>>>>> It has been more than five months since we were advised that the >>>>>>>> PCLS was approved by the IESG. Why hasn't the RFC been published? >>>> >>>> >> >> > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Tue Jun 3 09:33:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03952 for ; Tue, 3 Jun 2003 09:33:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53DWtB14037 for policy-archive@odin.ietf.org; Tue, 3 Jun 2003 09:32:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53DT8B13850; Tue, 3 Jun 2003 09:29:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53DSKB13756 for ; Tue, 3 Jun 2003 09:28:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03823 for ; Tue, 3 Jun 2003 09:28:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NBo4-0005xl-00 for policy@ietf.org; Tue, 03 Jun 2003 09:26:28 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19NBo4-0005xd-00 for policy@ietf.org; Tue, 03 Jun 2003 09:26:28 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h53DRgg18476 for ; Tue, 3 Jun 2003 08:27:42 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10NZ2D>; Tue, 3 Jun 2003 15:27:41 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501BC2230@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Larry S. Bartz" , "Joel M. Halpern" Cc: policy@ietf.org, Randy Bush , Ed Ellesson , "Wijnen, Bert (Bert)" , "Ted Hardie (E-mail)" Subject: RE: PCLS when? [was: Re: [Policy] Approved: draft-ietf-policy-co re-schema-16.txt] Date: Tue, 3 Jun 2003 15:27:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , > Joel, all, > > It has now been nearly seven months since we were advised that > the PCLS (Policy Core LDAP Schema) was approved by the IESG. Why > can't the RFC be published? > Larry, we have explained MULTIPLE times now why it cannot be published. And if the situation does not change, then the explanation will remain the same, and we can NOT publish. > How long must PCLS wait for the draft > (draft-zeilenga-ldap-user-schema) > upon which it unnecessarily depends? You seem to be the only one who believes that it is not a normative reference. The IESG approved the PCLS with the normative reference present, and so the doc MUST wait till that normative reference shows up as an RFC. > According to the IETF's Internet Draft Status Tracker facility, > the status of draft-zeilenga-ldap-user-schema has not changed since > April 17. Is it reasonable for PCLS to wait upon an activity which > is apparently not making progress? > I can tell you that that doc has been discussed a few times in the IESG lately and that the responsible AD (Ted Hardie) is trying to work out a resolution. Ted... any more you want to add? Bert AD-hat on. _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Tue Jun 3 10:17:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06663 for ; Tue, 3 Jun 2003 10:17:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53EHKv18367 for policy-archive@odin.ietf.org; Tue, 3 Jun 2003 10:17:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53EDKB18049; Tue, 3 Jun 2003 10:13:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53ECJB17995 for ; Tue, 3 Jun 2003 10:12:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06128 for ; Tue, 3 Jun 2003 10:12:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NCUd-0006N5-00 for policy@ietf.org; Tue, 03 Jun 2003 10:10:27 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19NCUc-0006MN-00 for policy@ietf.org; Tue, 03 Jun 2003 10:10:26 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h53EBdB13656 for ; Tue, 3 Jun 2003 10:11:40 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10N53L>; Tue, 3 Jun 2003 16:11:38 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501BC226F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ellesson@mindspring.com, joel@stevecrocker.com Cc: policy@ietf.org Subject: RE: [Policy] AD review of: draft-ietf-policy-qos-device-info-mod el-10.txt Date: Tue, 3 Jun 2003 16:11:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , WG chairs, may I assume that the revision 10 document is now OK with the WG and that I can issue IETF Last Call for it? For those who want to check, I have colored diffs between rev8 and rev10 and between rev 9 and rev 10 at: http://www.psg.com/~bwijnen/qddim0810.html http://www.psg.com/~bwijnen/qddim0910.html One nit (can be fixed at later point): Walter Weiss has a new email address/affiliation Thanks, Bert > -----Original Message----- > From: Robert Moore [mailto:remoore@us.ibm.com] > Sent: vrijdag 23 mei 2003 21:20 > To: policy@ietf.org > Cc: bwijnen@lucent.com; ellesson@mindspring.com; joel@stevecrocker.com > Subject: RE: [Policy] AD review of: > draft-ietf-policy-qos-device-info-mode l-08.txt > > > > > > > I've submitted QDDIM-10 to the I-D's repository. The major > change from > QDDIM-09 is that I've reversed the inadvertent backouts from > QDDIM-08 that > I mentioned before. Sorry for that confusion -- QDDIM-10 now > represents > what I *thought* I was publishing in QDDIM-09. > > I've also made some changes, based on Walter's response to > the list, to > address many of Bert's latest comments. Here's Bert's note, with the > details of the QDDIM-10 changes tagged with 's: > > *******Begin Bert's note: > Thanks. Looks good... a few questions remain: > > - Those places where you answer that my comment hits the > model itself... it seems you did not make (or want to make) > changes. In some of my comments, I think I was just looking for > and answer (possibly add some explanatory text, so that the > answer is also in the document). If the WG has consensus on > something, then that is probably OK... but if it is a consensus > that is not clear from what is described, then some extra > explanatiory text may help. > > - Thanks for explaining why you want this stds track.. helps. > > I have detailed comments/questions below. > > Thanks, > Bert > > > -----Original Message----- > > From: Robert Moore [mailto:remoore@us.ibm.com] > > Sent: maandag 19 mei 2003 2:15 > > To: Wijnen, Bert (Bert) > > Cc: policy@ietf.org > > Subject: Re: [Policy] AD review of: > > draft-ietf-policy-qos-device-info-model-08.txt > > > .. snip .. > > > > - is the reference to cim 2.5 correct? > > > CIM 2.5 is there to be referenced, permanently and immutably> > > My concern was if there is an issue if the base PCIM (RFC3060) > refers to CIM 2.2, namely: > [2] Distributed Management Task Force, Inc., "Common Information > Model (CIM) Specification, version 2.2, June 1999. This > document is available on the following DMTF web page: > http://www.dmtf.org/spec/cims.html. > And PCIMe als refers to CIM 2.2, namely > [3] Distributed Management Task Force, Inc., "Common Information > Model (CIM) Specification: Version 2.2", June 14, 1999, > available at > http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf. > So is it then OK for this QDDIM to refer to extend on PCIM and PCIMe > which refer to an older CIM version? Or am I confused here between > the COM and the CIM Schema? > Where I think you're confused is between the CIM spec and the > CIM Schema. In fact, PCIMe refers to exactly the same version of the > CIM Schema as QDDIM does: CIM Schema 2.5. > .. snip .. > > > - I see some Msoft characters in the doc (page 12 and 64 are > > examples) > > > however, I'm finding these solely by eyeball, so I may have > > missed some> > > Your rev 9 does not have any non-ASCII characters according to my > checking-script. It does however have: > -: 311 lines longer than 72 characters, max 74 > RFC-Editor will fix if you don't. > In case it was the headers/footers doing this, I shortened them > a bit - but the RFC Editor is definitely going to change these > anyway. > > > > > - I suspect that security area is too weak. > > Specifically if you tell people to use IPSEC, you have to > > explain how that is done. But... maybe you can refer to > > PCIM and PCIMe, similar to how you did it for QPIM. > > Maybe there are some extra concerns since you also derive > > a lot directly from CIM ?? > > > if the Security Area has some specific text, we can certainly > > include it> > > > Mmm... I wonder if you cannot build on what you have in RFC3060 and > RFC3460. This is (after all) an Information Model, and such a model > itself should not have a security impact (does it?). Instead, when > the model is translated into a LDAP Schema or such, then once > such data is used, it needs to be transported securely. > > In any event, if you DO specify that IPsec SHOULD be used, I believe > that the security ADs then want you to explain more about HOW to use > it. A good document to check is: > http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-00.txt > Based on that, you can see a good Security COnsiderations section > for the use of IPsec in RFC3474, which was created with the help > of Steve Bellovin. > Based on your comments and those from Joel and Walter, I > took a shot at a shorter Security Considerations section that > expresses > two ideas: (1) we're just an information model, and (2) for > some security- > related thoughts for specific objects in the model, take a look at the > DiffServ MIB (since it's already been approved as a PS, and hence is > available for us to reference). > .. snip .. > > > - Page 11. > > It might help if in the figure you indicate where we find > > CIM, PCIM, PCIMe, QPIM, QDDIM. etc > > > the bottom of; since I don't think that it's crucial to have > > these labels here, I made no changes.> > > > Indeed not crucial... so I can pass if it is too difficult. > Intersting that even the experts in this field would not be able > to fill them in. Oh well. > > .. snip .. > > > - The figures on pages 26 to 32 are not consistent in their use of > > class names and such. I can understand that you need to abbreviate > > becuase of space constraints, but it might be good to do so in a > > consistent manner, and to list the abbreviations and explain which > > exact Class they represent. > > > quite easily which class an abbreviation is referring to.> > > > Mmmm... wil will live with it. > > .. snip .. > > > - I am a bit surprised to see how the descriptions of Properties is > > done. In the PCIM (RFC3060) it was done pretty formal, > for example: > > > > NAME CN > > DESCRIPTION A user-friendly name of a > policy-related object. > > SYNTAX string > > > > Another one: > > > > NAME Mandatory > > DESCRIPTION A flag indicating that the evaluation of the > > PolicyConditions and execution of > PolicyActions > > (if the condition list evaluates to TRUE) is > > required. > > SYNTAX boolean > > DEFAULT VALUE TRUE > > > > Or yet anbother one: > > > > NAME SequencedActions > > DESCRIPTION An enumeration indicating how to > interpret the > > action ordering indicated via the > > PolicyActionInPolicyRule aggregation. > > SYNTAX uint16 > > VALUES mandatory(1), recommended(2), dontCare(3) > > DEFAULT VALUE dontCare(3) > > > > In RFC3460 I see it done in a similar way: > > > > > > NAME PolicyDecisionStrategy > > DESCRIPTION The evaluation method used for policies > contained in > > the PolicySet. FirstMatching enforces > the actions > > of the first rule that evaluates to TRUE; > > All Matching enforces the actions of all rules > > that evaluate to TRUE. > > SYNTAX uint16 > > VALUES 1 [FirstMatching], 2 [AllMatching] > > DEFAULT VALUE 1 [FirstMatching] > > > > So why is that not followed in this document? > > > CIM MOF files. In many cases these files weren't there when QDDIM > > was being written. I believe that the necessary modeling information > > is all here in QDDIM; as always, though, implementation experience > > may prove me wrong.> > > > > So... what you are telling me is that all the info is in the document > (which I believe is indeed the case, at least in the new rev), > but that we do NOT specify it in such a formal way in this QDDIM > doc as we did in PCIM and PCIMe. > Did I get that correctly? > And if so... why would we be so "lazy" ?? > I'd prefer "otherwise focused" here:-) > > > - Does Class TockenBucketMeterService not need a > deltaInterval property? > > Otherwise what does the AverageRate property mean? > > model itself. > > I've made no changes in response to these comments, because > what's in the > > document now reflects a consensus reached after *long* > debates among the > > authors and other in the WG. If anyone wants to reopen the > debates, feel > > free. But I'm going to pass.> > > > So can you answer the question what the AverageRate property means? > Or is the answer fuzzy? > This one is still unresolved -- Walter said that this probably > "deserves" additional text, but he didn't provide it. > > > - Do we still want/need a class TosMarkerService and a property of > ToSValue? > > Has ToS not been obsoleted? > > > > > is there no answer to my question, though? > Walter has answered the question, but I'm not sure this > answer needs to be reflected in the document itself. When > historians read the QDDIM RFC 100 years from now, won't > they conclude "Oh, this must have been right at the end of > the ToS era," without any further help from us? > .. snip .. > > > - sect 4.3.37.2 > > Would it not be better to use a 32bit unsigned? > > > > > No answer? You understand that I can live with the 16bit value. > But I wonder how future proof a 16bit value is when it needs to > express the number of bytes for a bufferpool. > Based on Walter's response, I've change this to a uint32. > > .. snip .. > > > > > - sect 4.3.4.2 > > Does this property not add just extra complexity? Or is > that just me > > thinking so? > > And... what happens if both WeightingFactor and Priority > are equal? > > > > > Could you suggest an answer to my question? > Like: hey Bert cool off... > Oh well > I added some text based on Walter's response -- and as > requested, it's a little more concise than his:-) > > > > 4.4.17 that I had missed in -08. It's fixed now.> > > > OK thanks > > Bert > *******End Bert's note: > > Regards, > Bob > > Bob Moore > WebSphere Advanced Design and Technology > WebSphere Platform System House > IBM Software Group > +1-919-254-4436 > remoore@us.ibm.com > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Tue Jun 3 11:40:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10358 for ; Tue, 3 Jun 2003 11:40:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53Fe1p26487 for policy-archive@odin.ietf.org; Tue, 3 Jun 2003 11:40:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FZpB25222; Tue, 3 Jun 2003 11:35:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FXAB25047 for ; Tue, 3 Jun 2003 11:33:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09927 for ; Tue, 3 Jun 2003 11:33:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NDku-0007DR-00 for policy@ietf.org; Tue, 03 Jun 2003 11:31:20 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 19NDkt-0007DF-00 for policy@ietf.org; Tue, 03 Jun 2003 11:31:19 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4771464; Tue, 03 Jun 2003 11:33:02 -0400 Message-Id: <5.1.0.14.0.20030603113137.02901bb0@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Jun 2003 11:31:45 -0400 To: "Wijnen, Bert (Bert)" , ellesson@mindspring.com From: "Joel M. Halpern" Subject: RE: [Policy] AD review of: draft-ietf-policy-qos-device-info-mod el-10.txt Cc: policy@ietf.org In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501BC226F@nl0006exch001u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Yes. Thank you, Joel At 04:11 PM 6/3/2003 +0200, Wijnen, Bert (Bert) wrote: >WG chairs, may I assume that the revision 10 document is now >OK with the WG and that I can issue IETF Last Call for it? > >For those who want to check, I have colored diffs between rev8 and rev10 >and between rev 9 and rev 10 at: > > http://www.psg.com/~bwijnen/qddim0810.html > http://www.psg.com/~bwijnen/qddim0910.html > >One nit (can be fixed at later point): Walter Weiss has a new >email address/affiliation > >Thanks, >Bert > > > -----Original Message----- > > From: Robert Moore [mailto:remoore@us.ibm.com] > > Sent: vrijdag 23 mei 2003 21:20 > > To: policy@ietf.org > > Cc: bwijnen@lucent.com; ellesson@mindspring.com; joel@stevecrocker.com > > Subject: RE: [Policy] AD review of: > > draft-ietf-policy-qos-device-info-mode l-08.txt > > > > > > > > > > > > > > I've submitted QDDIM-10 to the I-D's repository. The major > > change from > > QDDIM-09 is that I've reversed the inadvertent backouts from > > QDDIM-08 that > > I mentioned before. Sorry for that confusion -- QDDIM-10 now > > represents > > what I *thought* I was publishing in QDDIM-09. > > > > I've also made some changes, based on Walter's response to > > the list, to > > address many of Bert's latest comments. Here's Bert's note, with the > > details of the QDDIM-10 changes tagged with 's: > > > > *******Begin Bert's note: > > Thanks. Looks good... a few questions remain: > > > > - Those places where you answer that my comment hits the > > model itself... it seems you did not make (or want to make) > > changes. In some of my comments, I think I was just looking for > > and answer (possibly add some explanatory text, so that the > > answer is also in the document). If the WG has consensus on > > something, then that is probably OK... but if it is a consensus > > that is not clear from what is described, then some extra > > explanatiory text may help. > > > > - Thanks for explaining why you want this stds track.. helps. > > > > I have detailed comments/questions below. > > > > Thanks, > > Bert > > > > > -----Original Message----- > > > From: Robert Moore [mailto:remoore@us.ibm.com] > > > Sent: maandag 19 mei 2003 2:15 > > > To: Wijnen, Bert (Bert) > > > Cc: policy@ietf.org > > > Subject: Re: [Policy] AD review of: > > > draft-ietf-policy-qos-device-info-model-08.txt > > > > > .. snip .. > > > > > > - is the reference to cim 2.5 correct? > > > > > CIM 2.5 is there to be referenced, permanently and immutably> > > > > My concern was if there is an issue if the base PCIM (RFC3060) > > refers to CIM 2.2, namely: > > [2] Distributed Management Task Force, Inc., "Common Information > > Model (CIM) Specification, version 2.2, June 1999. This > > document is available on the following DMTF web page: > > http://www.dmtf.org/spec/cims.html. > > And PCIMe als refers to CIM 2.2, namely > > [3] Distributed Management Task Force, Inc., "Common Information > > Model (CIM) Specification: Version 2.2", June 14, 1999, > > available at > > http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf. > > So is it then OK for this QDDIM to refer to extend on PCIM and PCIMe > > which refer to an older CIM version? Or am I confused here between > > the COM and the CIM Schema? > > Where I think you're confused is between the CIM spec and the > > CIM Schema. In fact, PCIMe refers to exactly the same version of the > > CIM Schema as QDDIM does: CIM Schema 2.5. > > .. snip .. > > > > > - I see some Msoft characters in the doc (page 12 and 64 are > > > examples) > > > > > however, I'm finding these solely by eyeball, so I may have > > > missed some> > > > > Your rev 9 does not have any non-ASCII characters according to my > > checking-script. It does however have: > > -: 311 lines longer than 72 characters, max 74 > > RFC-Editor will fix if you don't. > > In case it was the headers/footers doing this, I shortened them > > a bit - but the RFC Editor is definitely going to change these > > anyway. > > > > > > > > - I suspect that security area is too weak. > > > Specifically if you tell people to use IPSEC, you have to > > > explain how that is done. But... maybe you can refer to > > > PCIM and PCIMe, similar to how you did it for QPIM. > > > Maybe there are some extra concerns since you also derive > > > a lot directly from CIM ?? > > > > > if the Security Area has some specific text, we can certainly > > > include it> > > > > > Mmm... I wonder if you cannot build on what you have in RFC3060 and > > RFC3460. This is (after all) an Information Model, and such a model > > itself should not have a security impact (does it?). Instead, when > > the model is translated into a LDAP Schema or such, then once > > such data is used, it needs to be transported securely. > > > > In any event, if you DO specify that IPsec SHOULD be used, I believe > > that the security ADs then want you to explain more about HOW to use > > it. A good document to check is: > > http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-00.txt > > Based on that, you can see a good Security COnsiderations section > > for the use of IPsec in RFC3474, which was created with the help > > of Steve Bellovin. > > Based on your comments and those from Joel and Walter, I > > took a shot at a shorter Security Considerations section that > > expresses > > two ideas: (1) we're just an information model, and (2) for > > some security- > > related thoughts for specific objects in the model, take a look at the > > DiffServ MIB (since it's already been approved as a PS, and hence is > > available for us to reference). > > .. snip .. > > > > > - Page 11. > > > It might help if in the figure you indicate where we find > > > CIM, PCIM, PCIMe, QPIM, QDDIM. etc > > > > > the bottom of; since I don't think that it's crucial to have > > > these labels here, I made no changes.> > > > > > Indeed not crucial... so I can pass if it is too difficult. > > Intersting that even the experts in this field would not be able > > to fill them in. Oh well. > > > > .. snip .. > > > > > - The figures on pages 26 to 32 are not consistent in their use of > > > class names and such. I can understand that you need to abbreviate > > > becuase of space constraints, but it might be good to do so in a > > > consistent manner, and to list the abbreviations and explain which > > > exact Class they represent. > > > > > quite easily which class an abbreviation is referring to.> > > > > > Mmmm... wil will live with it. > > > > .. snip .. > > > > > - I am a bit surprised to see how the descriptions of Properties is > > > done. In the PCIM (RFC3060) it was done pretty formal, > > for example: > > > > > > NAME CN > > > DESCRIPTION A user-friendly name of a > > policy-related object. > > > SYNTAX string > > > > > > Another one: > > > > > > NAME Mandatory > > > DESCRIPTION A flag indicating that the evaluation of the > > > PolicyConditions and execution of > > PolicyActions > > > (if the condition list evaluates to TRUE) is > > > required. > > > SYNTAX boolean > > > DEFAULT VALUE TRUE > > > > > > Or yet anbother one: > > > > > > NAME SequencedActions > > > DESCRIPTION An enumeration indicating how to > > interpret the > > > action ordering indicated via the > > > PolicyActionInPolicyRule aggregation. > > > SYNTAX uint16 > > > VALUES mandatory(1), recommended(2), dontCare(3) > > > DEFAULT VALUE dontCare(3) > > > > > > In RFC3460 I see it done in a similar way: > > > > > > > > > NAME PolicyDecisionStrategy > > > DESCRIPTION The evaluation method used for policies > > contained in > > > the PolicySet. FirstMatching enforces > > the actions > > > of the first rule that evaluates to TRUE; > > > All Matching enforces the actions of all rules > > > that evaluate to TRUE. > > > SYNTAX uint16 > > > VALUES 1 [FirstMatching], 2 [AllMatching] > > > DEFAULT VALUE 1 [FirstMatching] > > > > > > So why is that not followed in this document? > > > > > CIM MOF files. In many cases these files weren't there when QDDIM > > > was being written. I believe that the necessary modeling information > > > is all here in QDDIM; as always, though, implementation experience > > > may prove me wrong.> > > > > > > > So... what you are telling me is that all the info is in the document > > (which I believe is indeed the case, at least in the new rev), > > but that we do NOT specify it in such a formal way in this QDDIM > > doc as we did in PCIM and PCIMe. > > Did I get that correctly? > > And if so... why would we be so "lazy" ?? > > I'd prefer "otherwise focused" here:-) > > > > > - Does Class TockenBucketMeterService not need a > > deltaInterval property? > > > Otherwise what does the AverageRate property mean? > > > > model itself. > > > I've made no changes in response to these comments, because > > what's in the > > > document now reflects a consensus reached after *long* > > debates among the > > > authors and other in the WG. If anyone wants to reopen the > > debates, feel > > > free. But I'm going to pass.> > > > > > So can you answer the question what the AverageRate property means? > > Or is the answer fuzzy? > > This one is still unresolved -- Walter said that this probably > > "deserves" additional text, but he didn't provide it. > > > > > - Do we still want/need a class TosMarkerService and a property of > > ToSValue? > > > Has ToS not been obsoleted? > > > > > > > > is there no answer to my question, though? > > Walter has answered the question, but I'm not sure this > > answer needs to be reflected in the document itself. When > > historians read the QDDIM RFC 100 years from now, won't > > they conclude "Oh, this must have been right at the end of > > the ToS era," without any further help from us? > > .. snip .. > > > > > - sect 4.3.37.2 > > > Would it not be better to use a 32bit unsigned? > > > > > > > > No answer? You understand that I can live with the 16bit value. > > But I wonder how future proof a 16bit value is when it needs to > > express the number of bytes for a bufferpool. > > Based on Walter's response, I've change this to a uint32. > > > > .. snip .. > > > > > > > > - sect 4.3.4.2 > > > Does this property not add just extra complexity? Or is > > that just me > > > thinking so? > > > And... what happens if both WeightingFactor and Priority > > are equal? > > > > > > > > Could you suggest an answer to my question? > > Like: hey Bert cool off... > > Oh well > > I added some text based on Walter's response -- and as > > requested, it's a little more concise than his:-) > > > > > > > 4.4.17 that I had missed in -08. It's fixed now.> > > > > > OK thanks > > > > Bert > > *******End Bert's note: > > > > Regards, > > Bob > > > > Bob Moore > > WebSphere Advanced Design and Technology > > WebSphere Platform System House > > IBM Software Group > > +1-919-254-4436 > > remoore@us.ibm.com > > >_______________________________________________ >Policy mailing list >Policy@ietf.org >https://www1.ietf.org/mailman/listinfo/policy _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Tue Jun 3 11:55:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11530 for ; Tue, 3 Jun 2003 11:55:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53FtNb27683 for policy-archive@odin.ietf.org; Tue, 3 Jun 2003 11:55:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FpFB27359; Tue, 3 Jun 2003 11:51:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53FoSB27324 for ; Tue, 3 Jun 2003 11:50:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11198 for ; Tue, 3 Jun 2003 11:50:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NE1e-0007VP-00 for policy@ietf.org; Tue, 03 Jun 2003 11:48:38 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19NE1c-0007Ut-00 for policy@ietf.org; Tue, 03 Jun 2003 11:48:36 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h53FnoP18118 for ; Tue, 3 Jun 2003 10:49:51 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10N77H>; Tue, 3 Jun 2003 17:49:49 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501BC22CA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Joel M. Halpern" , ellesson@mindspring.com Cc: policy@ietf.org Subject: RE: [Policy] AD review of: draft-ietf-policy-qos-device-info-mod el-10.txt Date: Tue, 3 Jun 2003 17:49:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , IETF Las Call has been requested for both documents as Proposed Standard Thanks, Bert > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > Sent: dinsdag 3 juni 2003 17:32 > To: Wijnen, Bert (Bert); ellesson@mindspring.com > Cc: policy@ietf.org > Subject: RE: [Policy] AD review of: > draft-ietf-policy-qos-device-info-mod el-10.txt > > > Yes. > Thank you, > Joel > > At 04:11 PM 6/3/2003 +0200, Wijnen, Bert (Bert) wrote: > >WG chairs, may I assume that the revision 10 document is now > >OK with the WG and that I can issue IETF Last Call for it? > > > >For those who want to check, I have colored diffs between > rev8 and rev10 > >and between rev 9 and rev 10 at: > > > > http://www.psg.com/~bwijnen/qddim0810.html > > http://www.psg.com/~bwijnen/qddim0910.html > > > >One nit (can be fixed at later point): Walter Weiss has a new > >email address/affiliation > > > >Thanks, > >Bert > > > > > -----Original Message----- > > > From: Robert Moore [mailto:remoore@us.ibm.com] > > > Sent: vrijdag 23 mei 2003 21:20 > > > To: policy@ietf.org > > > Cc: bwijnen@lucent.com; ellesson@mindspring.com; > joel@stevecrocker.com > > > Subject: RE: [Policy] AD review of: > > > draft-ietf-policy-qos-device-info-mode l-08.txt > > > > > > > > > > > > > > > > > > > > > I've submitted QDDIM-10 to the I-D's repository. The major > > > change from > > > QDDIM-09 is that I've reversed the inadvertent backouts from > > > QDDIM-08 that > > > I mentioned before. Sorry for that confusion -- QDDIM-10 now > > > represents > > > what I *thought* I was publishing in QDDIM-09. > > > > > > I've also made some changes, based on Walter's response to > > > the list, to > > > address many of Bert's latest comments. Here's Bert's > note, with the > > > details of the QDDIM-10 changes tagged with 's: > > > > > > *******Begin Bert's note: > > > Thanks. Looks good... a few questions remain: > > > > > > - Those places where you answer that my comment hits the > > > model itself... it seems you did not make (or want to make) > > > changes. In some of my comments, I think I was just looking for > > > and answer (possibly add some explanatory text, so that the > > > answer is also in the document). If the WG has consensus on > > > something, then that is probably OK... but if it is a consensus > > > that is not clear from what is described, then some extra > > > explanatiory text may help. > > > > > > - Thanks for explaining why you want this stds track.. helps. > > > > > > I have detailed comments/questions below. > > > > > > Thanks, > > > Bert > > > > > > > -----Original Message----- > > > > From: Robert Moore [mailto:remoore@us.ibm.com] > > > > Sent: maandag 19 mei 2003 2:15 > > > > To: Wijnen, Bert (Bert) > > > > Cc: policy@ietf.org > > > > Subject: Re: [Policy] AD review of: > > > > draft-ietf-policy-qos-device-info-model-08.txt > > > > > > > .. snip .. > > > > > > > > - is the reference to cim 2.5 correct? > > > > > > > CIM 2.5 is there to be referenced, permanently and immutably> > > > > > > My concern was if there is an issue if the base PCIM (RFC3060) > > > refers to CIM 2.2, namely: > > > [2] Distributed Management Task Force, Inc., "Common > Information > > > Model (CIM) Specification, version 2.2, June 1999. This > > > document is available on the following DMTF web page: > > > http://www.dmtf.org/spec/cims.html. > > > And PCIMe als refers to CIM 2.2, namely > > > [3] Distributed Management Task Force, Inc., "Common > Information > > > Model (CIM) Specification: Version 2.2", June 14, 1999, > > > available at > > > http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf. > > > So is it then OK for this QDDIM to refer to extend on > PCIM and PCIMe > > > which refer to an older CIM version? Or am I confused here between > > > the COM and the CIM Schema? > > > Where I think you're confused is between the CIM > spec and the > > > CIM Schema. In fact, PCIMe refers to exactly the same > version of the > > > CIM Schema as QDDIM does: CIM Schema 2.5. > > > .. snip .. > > > > > > > - I see some Msoft characters in the doc (page 12 and 64 are > > > > examples) > > > > one on p.64; > > > > however, I'm finding these solely by eyeball, so I may have > > > > missed some> > > > > > > Your rev 9 does not have any non-ASCII characters according to my > > > checking-script. It does however have: > > > -: 311 lines longer than 72 characters, max 74 > > > RFC-Editor will fix if you don't. > > > In case it was the headers/footers doing this, I > shortened them > > > a bit - but the RFC Editor is definitely going to change these > > > anyway. > > > > > > > > > > > - I suspect that security area is too weak. > > > > Specifically if you tell people to use IPSEC, you have to > > > > explain how that is done. But... maybe you can refer to > > > > PCIM and PCIMe, similar to how you did it for QPIM. > > > > Maybe there are some extra concerns since you also derive > > > > a lot directly from CIM ?? > > > > what to say; > > > > if the Security Area has some specific text, we can certainly > > > > include it> > > > > > > > Mmm... I wonder if you cannot build on what you have in > RFC3060 and > > > RFC3460. This is (after all) an Information Model, and > such a model > > > itself should not have a security impact (does it?). Instead, when > > > the model is translated into a LDAP Schema or such, then once > > > such data is used, it needs to be transported securely. > > > > > > In any event, if you DO specify that IPsec SHOULD be > used, I believe > > > that the security ADs then want you to explain more about > HOW to use > > > it. A good document to check is: > > > > http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-00.txt > > > Based on that, you can see a good Security COnsiderations section > > > for the use of IPsec in RFC3474, which was created with the help > > > of Steve Bellovin. > > > Based on your comments and those from Joel and Walter, I > > > took a shot at a shorter Security Considerations section that > > > expresses > > > two ideas: (1) we're just an information model, and (2) for > > > some security- > > > related thoughts for specific objects in the model, take > a look at the > > > DiffServ MIB (since it's already been approved as a PS, > and hence is > > > available for us to reference). > > > .. snip .. > > > > > > > - Page 11. > > > > It might help if in the figure you indicate where we find > > > > CIM, PCIM, PCIMe, QPIM, QDDIM. etc > > > > > > > the bottom of; since I don't think that it's crucial to have > > > > these labels here, I made no changes.> > > > > > > > Indeed not crucial... so I can pass if it is too difficult. > > > Intersting that even the experts in this field would not be able > > > to fill them in. Oh well. > > > > > > .. snip .. > > > > > > > - The figures on pages 26 to 32 are not consistent in > their use of > > > > class names and such. I can understand that you need > to abbreviate > > > > becuase of space constraints, but it might be good to > do so in a > > > > consistent manner, and to list the abbreviations and > explain which > > > > exact Class they represent. > > > > > > > quite easily which class an abbreviation is referring to.> > > > > > > > Mmmm... wil will live with it. > > > > > > .. snip .. > > > > > > > - I am a bit surprised to see how the descriptions of > Properties is > > > > done. In the PCIM (RFC3060) it was done pretty formal, > > > for example: > > > > > > > > NAME CN > > > > DESCRIPTION A user-friendly name of a > > > policy-related object. > > > > SYNTAX string > > > > > > > > Another one: > > > > > > > > NAME Mandatory > > > > DESCRIPTION A flag indicating that the > evaluation of the > > > > PolicyConditions and execution of > > > PolicyActions > > > > (if the condition list evaluates > to TRUE) is > > > > required. > > > > SYNTAX boolean > > > > DEFAULT VALUE TRUE > > > > > > > > Or yet anbother one: > > > > > > > > NAME SequencedActions > > > > DESCRIPTION An enumeration indicating how to > > > interpret the > > > > action ordering indicated via the > > > > PolicyActionInPolicyRule aggregation. > > > > SYNTAX uint16 > > > > VALUES mandatory(1), recommended(2), dontCare(3) > > > > DEFAULT VALUE dontCare(3) > > > > > > > > In RFC3460 I see it done in a similar way: > > > > > > > > > > > > NAME PolicyDecisionStrategy > > > > DESCRIPTION The evaluation method used for policies > > > contained in > > > > the PolicySet. FirstMatching enforces > > > the actions > > > > of the first rule that evaluates to TRUE; > > > > All Matching enforces the actions > of all rules > > > > that evaluate to TRUE. > > > > SYNTAX uint16 > > > > VALUES 1 [FirstMatching], 2 [AllMatching] > > > > DEFAULT VALUE 1 [FirstMatching] > > > > > > > > So why is that not followed in this document? > > > > pre-existing > > > > CIM MOF files. In many cases these files weren't there > when QDDIM > > > > was being written. I believe that the necessary > modeling information > > > > is all here in QDDIM; as always, though, implementation > experience > > > > may prove me wrong.> > > > > > > > > > > So... what you are telling me is that all the info is in > the document > > > (which I believe is indeed the case, at least in the new rev), > > > but that we do NOT specify it in such a formal way in this QDDIM > > > doc as we did in PCIM and PCIMe. > > > Did I get that correctly? > > > And if so... why would we be so "lazy" ?? > > > I'd prefer "otherwise focused" here:-) > > > > > > > - Does Class TockenBucketMeterService not need a > > > deltaInterval property? > > > > Otherwise what does the AverageRate property mean? > > > > > > model itself. > > > > I've made no changes in response to these comments, because > > > what's in the > > > > document now reflects a consensus reached after *long* > > > debates among the > > > > authors and other in the WG. If anyone wants to reopen the > > > debates, feel > > > > free. But I'm going to pass.> > > > > > > > So can you answer the question what the AverageRate > property means? > > > Or is the answer fuzzy? > > > This one is still unresolved -- Walter said that > this probably > > > "deserves" additional text, but he didn't provide it. > > > > > > > - Do we still want/need a class TosMarkerService and a > property of > > > ToSValue? > > > > Has ToS not been obsoleted? > > > > > > > > > > > is there no answer to my question, though? > > > Walter has answered the question, but I'm not sure this > > > answer needs to be reflected in the document itself. When > > > historians read the QDDIM RFC 100 years from now, won't > > > they conclude "Oh, this must have been right at the end of > > > the ToS era," without any further help from us? > > > .. snip .. > > > > > > > - sect 4.3.37.2 > > > > Would it not be better to use a 32bit unsigned? > > > > > > > > > > > No answer? You understand that I can live with the 16bit value. > > > But I wonder how future proof a 16bit value is when it needs to > > > express the number of bytes for a bufferpool. > > > Based on Walter's response, I've change this to a > uint32. > > > > > > .. snip .. > > > > > > > > > > > - sect 4.3.4.2 > > > > Does this property not add just extra complexity? Or is > > > that just me > > > > thinking so? > > > > And... what happens if both WeightingFactor and Priority > > > are equal? > > > > > > > > > > > Could you suggest an answer to my question? > > > Like: hey Bert cool off... > > > Oh well > > > I added some text based on Walter's response -- and as > > > requested, it's a little more concise than his:-) > > > > > > > > > > 4.4.17 that I had missed in -08. It's fixed now.> > > > > > > > OK thanks > > > > > > Bert > > > *******End Bert's note: > > > > > > Regards, > > > Bob > > > > > > Bob Moore > > > WebSphere Advanced Design and Technology > > > WebSphere Platform System House > > > IBM Software Group > > > +1-919-254-4436 > > > remoore@us.ibm.com > > > > >_______________________________________________ > >Policy mailing list > >Policy@ietf.org > >https://www1.ietf.org/mailman/listinfo/policy > > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Tue Jun 3 15:27:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21373 for ; Tue, 3 Jun 2003 15:27:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53JRHn20492 for policy-archive@odin.ietf.org; Tue, 3 Jun 2003 15:27:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53JMuB20260; Tue, 3 Jun 2003 15:22:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53JL6B20100 for ; Tue, 3 Jun 2003 15:21:06 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21248; Tue, 3 Jun 2003 15:21:04 -0400 (EDT) Message-Id: <200306031921.PAA21248@ietf.org> To: IETF-Announce: ; Cc: policy@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Tue, 03 Jun 2003 15:21:04 -0400 Subject: [Policy] Last Call: Information Model for Describing Network Device QoS Datapath Mechanisms to Proposed Standard Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Policy Framework Working Group to consider Information Model for Describing Network Device QoS Datapath Mechanisms as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-17. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device-info-model-10.txt _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Tue Jun 3 15:29:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21418 for ; Tue, 3 Jun 2003 15:29:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53JT8l20580 for policy-archive@odin.ietf.org; Tue, 3 Jun 2003 15:29:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53JPBB20407; Tue, 3 Jun 2003 15:25:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53JLNB20111 for ; Tue, 3 Jun 2003 15:21:23 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21263; Tue, 3 Jun 2003 15:21:20 -0400 (EDT) Message-Id: <200306031921.PAA21263@ietf.org> To: IETF-Announce: ; Cc: policy@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Tue, 03 Jun 2003 15:21:20 -0400 Subject: [Policy] Last Call: Policy QoS Information Model to Proposed Standard Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Policy Framework Working Group to consider Policy QoS Information Model as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-17. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info-model-05.txt _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Tue Jun 3 21:35:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03278 for ; Tue, 3 Jun 2003 21:35:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h541Yd716104 for policy-archive@odin.ietf.org; Tue, 3 Jun 2003 21:34:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h541UfB15832; Tue, 3 Jun 2003 21:30:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53IPAB12514 for ; Tue, 3 Jun 2003 14:25:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18206 for ; Tue, 3 Jun 2003 14:25:05 -0400 (EDT) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NGRJ-0001Sd-00 for policy@ietf.org; Tue, 03 Jun 2003 14:23:17 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 19NGRI-0001SY-00 for policy@ietf.org; Tue, 03 Jun 2003 14:23:16 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h53IOwXF013318 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 Jun 2003 11:24:58 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h53IOpix017518; Tue, 3 Jun 2003 11:24:51 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501BC2230@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15501BC2230@nl0006exch001u.nl.lucent.com> Date: Tue, 3 Jun 2003 11:24:50 -0700 To: "Wijnen, Bert (Bert)" , "Larry S. Bartz" , "Joel M. Halpern" Subject: RE: PCLS when? [was: Re: [Policy] Approved: draft-ietf-policy-co re-schema-16.txt] Cc: policy@ietf.org, Randy Bush , Ed Ellesson , "Wijnen, Bert (Bert)" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , > > > According to the IETF's Internet Draft Status Tracker facility, >> the status of draft-zeilenga-ldap-user-schema has not changed since >> April 17. Is it reasonable for PCLS to wait upon an activity which >> is apparently not making progress? >> > >I can tell you that that doc has been discussed a few times in the IESG >lately and that the responsible AD (Ted Hardie) is trying to work out >a resolution. Ted... any more you want to add? After the review comments, Kurt has come to believe that the current document is actually too much of a grab bag, and that it probably needs to be split to make progress. We have had some discussion on where those splits should be, and it does look likely that one of the "daughter" documents will contain just the matching rules, which will enable this to unstick. We're working through right now where that leaves in terms of process (e.g., do we need to have a new IETF last call, since all of the text in this has previously been last called?). I've updated the tracker to reflect the "new ID needed" state, which is as close as we can come in the current system. Sorry that hadn't been done before, things were in flux enough that I haven't been sure how to mark this. regards, Ted Hardie _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From mailnull@www1.ietf.org Tue Jun 3 21:37:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03333 for ; Tue, 3 Jun 2003 21:37:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h541b7Q16351 for policy-archive@odin.ietf.org; Tue, 3 Jun 2003 21:37:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h541X7B16023; Tue, 3 Jun 2003 21:33:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h541WbB15993 for ; Tue, 3 Jun 2003 21:32:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03220 for ; Tue, 3 Jun 2003 21:32:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NN6z-0004v1-00 for policy@ietf.org; Tue, 03 Jun 2003 21:30:45 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 19NN6y-0004uy-00 for policy@ietf.org; Tue, 03 Jun 2003 21:30:44 -0400 Received: from user-0c8hq12.cable.mindspring.com ([24.136.232.34] helo=[192.168.0.4]) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19NN8c-0005hR-00; Tue, 03 Jun 2003 18:32:26 -0700 Subject: RE: [Policy] AD review of: draft-ietf-policy-qos-device-info-mod el-10.txt From: Ed Ellesson To: "Bert (Bert) Wijnen" Cc: "Joel M. Halpern" , policy@ietf.org In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501BC226F@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15501BC226F@nl0006exch001u.nl.lucent.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-9.7x.1) Date: 03 Jun 2003 21:35:10 -0400 Message-Id: <1054690514.1919.0.camel@vegan> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Yes, thanks! Ed On Tue, 2003-06-03 at 10:11, Wijnen, Bert (Bert) wrote: > WG chairs, may I assume that the revision 10 document is now > OK with the WG and that I can issue IETF Last Call for it? > > For those who want to check, I have colored diffs between rev8 and rev10 > and between rev 9 and rev 10 at: > > http://www.psg.com/~bwijnen/qddim0810.html > http://www.psg.com/~bwijnen/qddim0910.html > > One nit (can be fixed at later point): Walter Weiss has a new > email address/affiliation > > Thanks, > Bert > > > -----Original Message----- > > From: Robert Moore [mailto:remoore@us.ibm.com] > > Sent: vrijdag 23 mei 2003 21:20 > > To: policy@ietf.org > > Cc: bwijnen@lucent.com; ellesson@mindspring.com; joel@stevecrocker.com > > Subject: RE: [Policy] AD review of: > > draft-ietf-policy-qos-device-info-mode l-08.txt > > > > > > > > > > > > > > I've submitted QDDIM-10 to the I-D's repository. The major > > change from > > QDDIM-09 is that I've reversed the inadvertent backouts from > > QDDIM-08 that > > I mentioned before. Sorry for that confusion -- QDDIM-10 now > > represents > > what I *thought* I was publishing in QDDIM-09. > > > > I've also made some changes, based on Walter's response to > > the list, to > > address many of Bert's latest comments. Here's Bert's note, with the > > details of the QDDIM-10 changes tagged with 's: > > > > *******Begin Bert's note: > > Thanks. Looks good... a few questions remain: > > > > - Those places where you answer that my comment hits the > > model itself... it seems you did not make (or want to make) > > changes. In some of my comments, I think I was just looking for > > and answer (possibly add some explanatory text, so that the > > answer is also in the document). If the WG has consensus on > > something, then that is probably OK... but if it is a consensus > > that is not clear from what is described, then some extra > > explanatiory text may help. > > > > - Thanks for explaining why you want this stds track.. helps. > > > > I have detailed comments/questions below. > > > > Thanks, > > Bert > > > > > -----Original Message----- > > > From: Robert Moore [mailto:remoore@us.ibm.com] > > > Sent: maandag 19 mei 2003 2:15 > > > To: Wijnen, Bert (Bert) > > > Cc: policy@ietf.org > > > Subject: Re: [Policy] AD review of: > > > draft-ietf-policy-qos-device-info-model-08.txt > > > > > .. snip .. > > > > > > - is the reference to cim 2.5 correct? > > > > > CIM 2.5 is there to be referenced, permanently and immutably> > > > > My concern was if there is an issue if the base PCIM (RFC3060) > > refers to CIM 2.2, namely: > > [2] Distributed Management Task Force, Inc., "Common Information > > Model (CIM) Specification, version 2.2, June 1999. This > > document is available on the following DMTF web page: > > http://www.dmtf.org/spec/cims.html. > > And PCIMe als refers to CIM 2.2, namely > > [3] Distributed Management Task Force, Inc., "Common Information > > Model (CIM) Specification: Version 2.2", June 14, 1999, > > available at > > http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf. > > So is it then OK for this QDDIM to refer to extend on PCIM and PCIMe > > which refer to an older CIM version? Or am I confused here between > > the COM and the CIM Schema? > > Where I think you're confused is between the CIM spec and the > > CIM Schema. In fact, PCIMe refers to exactly the same version of the > > CIM Schema as QDDIM does: CIM Schema 2.5. > > .. snip .. > > > > > - I see some Msoft characters in the doc (page 12 and 64 are > > > examples) > > > > > however, I'm finding these solely by eyeball, so I may have > > > missed some> > > > > Your rev 9 does not have any non-ASCII characters according to my > > checking-script. It does however have: > > -: 311 lines longer than 72 characters, max 74 > > RFC-Editor will fix if you don't. > > In case it was the headers/footers doing this, I shortened them > > a bit - but the RFC Editor is definitely going to change these > > anyway. > > > > > > > > - I suspect that security area is too weak. > > > Specifically if you tell people to use IPSEC, you have to > > > explain how that is done. But... maybe you can refer to > > > PCIM and PCIMe, similar to how you did it for QPIM. > > > Maybe there are some extra concerns since you also derive > > > a lot directly from CIM ?? > > > > > if the Security Area has some specific text, we can certainly > > > include it> > > > > > Mmm... I wonder if you cannot build on what you have in RFC3060 and > > RFC3460. This is (after all) an Information Model, and such a model > > itself should not have a security impact (does it?). Instead, when > > the model is translated into a LDAP Schema or such, then once > > such data is used, it needs to be transported securely. > > > > In any event, if you DO specify that IPsec SHOULD be used, I believe > > that the security ADs then want you to explain more about HOW to use > > it. A good document to check is: > > http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-00.txt > > Based on that, you can see a good Security COnsiderations section > > for the use of IPsec in RFC3474, which was created with the help > > of Steve Bellovin. > > Based on your comments and those from Joel and Walter, I > > took a shot at a shorter Security Considerations section that > > expresses > > two ideas: (1) we're just an information model, and (2) for > > some security- > > related thoughts for specific objects in the model, take a look at the > > DiffServ MIB (since it's already been approved as a PS, and hence is > > available for us to reference). > > .. snip .. > > > > > - Page 11. > > > It might help if in the figure you indicate where we find > > > CIM, PCIM, PCIMe, QPIM, QDDIM. etc > > > > > the bottom of; since I don't think that it's crucial to have > > > these labels here, I made no changes.> > > > > > Indeed not crucial... so I can pass if it is too difficult. > > Intersting that even the experts in this field would not be able > > to fill them in. Oh well. > > > > .. snip .. > > > > > - The figures on pages 26 to 32 are not consistent in their use of > > > class names and such. I can understand that you need to abbreviate > > > becuase of space constraints, but it might be good to do so in a > > > consistent manner, and to list the abbreviations and explain which > > > exact Class they represent. > > > > > quite easily which class an abbreviation is referring to.> > > > > > Mmmm... wil will live with it. > > > > .. snip .. > > > > > - I am a bit surprised to see how the descriptions of Properties is > > > done. In the PCIM (RFC3060) it was done pretty formal, > > for example: > > > > > > NAME CN > > > DESCRIPTION A user-friendly name of a > > policy-related object. > > > SYNTAX string > > > > > > Another one: > > > > > > NAME Mandatory > > > DESCRIPTION A flag indicating that the evaluation of the > > > PolicyConditions and execution of > > PolicyActions > > > (if the condition list evaluates to TRUE) is > > > required. > > > SYNTAX boolean > > > DEFAULT VALUE TRUE > > > > > > Or yet anbother one: > > > > > > NAME SequencedActions > > > DESCRIPTION An enumeration indicating how to > > interpret the > > > action ordering indicated via the > > > PolicyActionInPolicyRule aggregation. > > > SYNTAX uint16 > > > VALUES mandatory(1), recommended(2), dontCare(3) > > > DEFAULT VALUE dontCare(3) > > > > > > In RFC3460 I see it done in a similar way: > > > > > > > > > NAME PolicyDecisionStrategy > > > DESCRIPTION The evaluation method used for policies > > contained in > > > the PolicySet. FirstMatching enforces > > the actions > > > of the first rule that evaluates to TRUE; > > > All Matching enforces the actions of all rules > > > that evaluate to TRUE. > > > SYNTAX uint16 > > > VALUES 1 [FirstMatching], 2 [AllMatching] > > > DEFAULT VALUE 1 [FirstMatching] > > > > > > So why is that not followed in this document? > > > > > CIM MOF files. In many cases these files weren't there when QDDIM > > > was being written. I believe that the necessary modeling information > > > is all here in QDDIM; as always, though, implementation experience > > > may prove me wrong.> > > > > > > > So... what you are telling me is that all the info is in the document > > (which I believe is indeed the case, at least in the new rev), > > but that we do NOT specify it in such a formal way in this QDDIM > > doc as we did in PCIM and PCIMe. > > Did I get that correctly? > > And if so... why would we be so "lazy" ?? > > I'd prefer "otherwise focused" here:-) > > > > > - Does Class TockenBucketMeterService not need a > > deltaInterval property? > > > Otherwise what does the AverageRate property mean? > > > > model itself. > > > I've made no changes in response to these comments, because > > what's in the > > > document now reflects a consensus reached after *long* > > debates among the > > > authors and other in the WG. If anyone wants to reopen the > > debates, feel > > > free. But I'm going to pass.> > > > > > So can you answer the question what the AverageRate property means? > > Or is the answer fuzzy? > > This one is still unresolved -- Walter said that this probably > > "deserves" additional text, but he didn't provide it. > > > > > - Do we still want/need a class TosMarkerService and a property of > > ToSValue? > > > Has ToS not been obsoleted? > > > > > > > > is there no answer to my question, though? > > Walter has answered the question, but I'm not sure this > > answer needs to be reflected in the document itself. When > > historians read the QDDIM RFC 100 years from now, won't > > they conclude "Oh, this must have been right at the end of > > the ToS era," without any further help from us? > > .. snip .. > > > > > - sect 4.3.37.2 > > > Would it not be better to use a 32bit unsigned? > > > > > > > > No answer? You understand that I can live with the 16bit value. > > But I wonder how future proof a 16bit value is when it needs to > > express the number of bytes for a bufferpool. > > Based on Walter's response, I've change this to a uint32. > > > > .. snip .. > > > > > > > > - sect 4.3.4.2 > > > Does this property not add just extra complexity? Or is > > that just me > > > thinking so? > > > And... what happens if both WeightingFactor and Priority > > are equal? > > > > > > > > Could you suggest an answer to my question? > > Like: hey Bert cool off... > > Oh well > > I added some text based on Walter's response -- and as > > requested, it's a little more concise than his:-) > > > > > > > 4.4.17 that I had missed in -08. It's fixed now.> > > > > > OK thanks > > > > Bert > > *******End Bert's note: > > > > Regards, > > Bob > > > > Bob Moore > > WebSphere Advanced Design and Technology > > WebSphere Platform System House > > IBM Software Group > > +1-919-254-4436 > > remoore@us.ibm.com > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Sun Jun 29 14:10:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03190 for ; Sun, 29 Jun 2003 14:10:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5TIA6n18702 for policy-archive@odin.ietf.org; Sun, 29 Jun 2003 14:10:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wgcj-0004rI-AD; Sun, 29 Jun 2003 14:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wgc1-0004qs-4P for policy@optimus.ietf.org; Sun, 29 Jun 2003 14:09:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03160 for ; Sun, 29 Jun 2003 14:08:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wgbe-0003VE-00 for policy@ietf.org; Sun, 29 Jun 2003 14:08:54 -0400 Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net ident=root) by ietf-mx with esmtp (Exim 4.12) id 19WgbT-0003V4-00 for policy@ietf.org; Sun, 29 Jun 2003 14:08:44 -0400 Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h5TI8Xc6037396 for ; Sun, 29 Jun 2003 18:08:33 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030629110432.01b7c5e0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 29 Jun 2003 11:05:31 -0700 To: policy@ietf.org From: "Kurt D. Zeilenga" Subject: [Policy] OIDs for PCIMe LDAP schema (was: no subject) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Mircea, I believe 1) (new OID) is the most appropriate option. draft-ietf-policy-core requests an OID be assigned to it for schema elements it specifies. It does not detail considerations for how other documents my make sub-delegations, hence other documents need to get their own delegation from IANA. Kurt _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Jun 30 08:11:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15149 for ; Mon, 30 Jun 2003 08:11:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UCB7b13330 for policy-archive@odin.ietf.org; Mon, 30 Jun 2003 08:11:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WxUr-0003Sd-CW; Mon, 30 Jun 2003 08:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WxUC-0003Ri-Kw for policy@optimus.ietf.org; Mon, 30 Jun 2003 08:10:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15035; Mon, 30 Jun 2003 08:10:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WxTw-0006Nw-00; Mon, 30 Jun 2003 08:10:04 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 19WxTb-0006KY-00; Mon, 30 Jun 2003 08:09:43 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5UC6M8w107262; Mon, 30 Jun 2003 08:06:23 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5UC6M6V043150; Mon, 30 Jun 2003 06:06:22 -0600 Subject: Re: [Policy] OIDs for PCIMe LDAP schema (was: no subject) To: "Kurt D. Zeilenga" Cc: policy@ietf.org, policy-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Robert Moore Date: Mon, 30 Jun 2003 08:06:20 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 06/30/2003 06:06:22 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , Mircea, I have to agree with Kurt here, especially since he played a key role in developing the IANA practices for LDAP. When we got the root OID for PCLS, we definitely thought of it as belonging to the document. If PCeLS were just PCLSv2, we *might* (or might not) decide that it's "the same document," and hence that it should continue registering OIDs under the same root. But if PCeLS really corresponds to PCIMe, then it's not PCLSv2: it *extends* PCLS, rather than updating it. By this reasoning, it's not the same document as PCLS, and thus should get a new root OID from IANA. Regards, Bob Bob Moore WebSphere Advanced Design and Technology WebSphere Platform System House IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Kurt D. Zeilenga" To: policy@ietf.org Subject: [Policy] OIDs for PCIMe LDAP schema (was: no subject) Sent by: policy-admin@ietf .org 06/29/2003 02:05 PM Mircea, I believe 1) (new OID) is the most appropriate option. draft-ietf-policy-core requests an OID be assigned to it for schema elements it specifies. It does not detail considerations for how other documents my make sub-delegations, hence other documents need to get their own delegation from IANA. Kurt _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Jun 30 10:06:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25514 for ; Mon, 30 Jun 2003 10:06:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UE67102835 for policy-archive@odin.ietf.org; Mon, 30 Jun 2003 10:06:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WzI9-0000jN-SO; Mon, 30 Jun 2003 10:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WzHv-0000j2-2y for policy@optimus.ietf.org; Mon, 30 Jun 2003 10:05:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25290; Mon, 30 Jun 2003 10:05:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WzHN-0000x0-00; Mon, 30 Jun 2003 10:05:13 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 19WzH8-0000w8-00; Mon, 30 Jun 2003 10:04:58 -0400 Received: by mail.metasolv.com with Internet Mail Service (5.5.2655.55) id ; Mon, 30 Jun 2003 08:40:35 -0500 Message-ID: From: "Pana, Mircea" To: "'Robert Moore'" , "Kurt D. Zeilenga" Cc: policy@ietf.org, policy-admin@ietf.org Subject: RE: [Policy] OIDs for PCIMe LDAP schema (was: no subject) Date: Mon, 30 Jun 2003 08:38:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33F0C.DA664A00" Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , 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_01C33F0C.DA664A00 Content-Type: text/plain Kurt, Bob, Thank you both for the clarifications. Since I received your messages shortly after having submitted PCELS-02, this revision does not reflect your recommendation. I'll make the changes and submit a new ID as soon as that will be possible again after the IETF meetings. Regards, Mircea. > -----Original Message----- > From: Robert Moore [mailto:remoore@us.ibm.com] > Sent: Monday, June 30, 2003 8:06 AM > To: Kurt D. Zeilenga > Cc: policy@ietf.org; policy-admin@ietf.org > Subject: Re: [Policy] OIDs for PCIMe LDAP schema (was: no subject) > > > > > > > Mircea, > > I have to agree with Kurt here, especially since he played a > key role in > developing the IANA practices for LDAP. When we got the root > OID for PCLS, > we definitely thought of it as belonging to the document. If > PCeLS were > just PCLSv2, we *might* (or might not) decide that it's "the same > document," and hence that it should continue registering OIDs > under the > same root. But if PCeLS really corresponds to PCIMe, then > it's not PCLSv2: > it *extends* PCLS, rather than updating it. By this > reasoning, it's not > the same document as PCLS, and thus should get a new root OID > from IANA. > > Regards, > Bob > > Bob Moore > WebSphere Advanced Design and Technology > WebSphere Platform System House > IBM Software Group > +1-919-254-4436 > remoore@us.ibm.com > > > > > > > "Kurt D. > > > Zeilenga" To: > policy@ietf.org > > > > g> Subject: > [Policy] OIDs for PCIMe LDAP schema (was: no subject) > > Sent by: > > > policy-admin@ietf > > > .org > > > > > > > > > 06/29/2003 02:05 > > > PM > > > > > > > > > > > > > Mircea, > > I believe 1) (new OID) is the most appropriate option. > draft-ietf-policy-core requests an OID be assigned to > it for schema elements it specifies. It does not detail > considerations for how other documents my make sub-delegations, > hence other documents need to get their own delegation > from IANA. > > Kurt > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > > > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > ------_=_NextPart_001_01C33F0C.DA664A00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Policy] OIDs for PCIMe LDAP schema (was: no = subject)

Kurt, Bob,

Thank you both for the clarifications.

Since I received your messages shortly after having = submitted PCELS-02, this revision does not reflect your recommendation. = I'll make the changes and submit a new ID as soon as that will be = possible again after the IETF meetings.

Regards,
Mircea.

> -----Original Message-----
> From: Robert Moore [mailto:remoore@us.ibm.com]=
> Sent: Monday, June 30, 2003 8:06 AM
> To: Kurt D. Zeilenga
> Cc: policy@ietf.org; = policy-admin@ietf.org
> Subject: Re: [Policy] OIDs for PCIMe LDAP = schema (was: no subject)
>
>
>
>
>
>
> Mircea,
>
> I have to agree with Kurt here, especially = since he played a
> key role in
> developing the IANA practices for LDAP.  = When we got the root
> OID for PCLS,
> we definitely thought of it as belonging to the = document.  If
> PCeLS were
> just PCLSv2, we *might* (or might not) decide = that it's "the same
> document," and hence that it should = continue registering OIDs
> under the
> same root.  But if PCeLS really = corresponds to PCIMe, then
> it's not PCLSv2:
> it *extends* PCLS, rather than updating = it.  By this
> reasoning, it's not
> the same document as PCLS, and thus should get = a new root OID
> from IANA.
>
> Regards,
> Bob
>
> Bob Moore
> WebSphere Advanced Design and Technology
> WebSphere Platform System House
> IBM Software Group
> +1-919-254-4436
> remoore@us.ibm.com
>
>
>
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ; 
>          = ;            = ; "Kurt = D.           &nbs= p;           &nbs= p;       
>          = ;            = ;            = ;            = ;            = ;    
>          = ; 
>          = ;            = ; = Zeilenga"         &nbs= p;      = To:      
> = policy@ietf.org         &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;
>          = ;      
>          = ;            = ; <Kurt@OpenLDAP.or        = cc:            =
>          = ;            = ;            = ;            = ;            = ;    
>          = ; 
>          = ;            = ; = g>           &= nbsp;           = Subject: 
> [Policy] OIDs for PCIMe LDAP schema (was: no = subject)        
>          = ;      
>          = ;            = ; Sent = by:           &nb= sp;           &nb= sp;       
>          = ;            = ;            = ;            = ;            = ;    
>          = ; 
>          = ;            = ; = policy-admin@ietf         &= nbsp;           &= nbsp;
>          = ;            = ;            = ;            = ;            = ;    
>          = ; 
>          = ;            = ; = .org           &= nbsp;           &= nbsp;            =
>          = ;            = ;            = ;            = ;            = ;    
>          = ; 
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ; 
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ; 
>          = ;            = ; 06/29/2003 = 02:05           &= nbsp;            =
>          = ;            = ;            = ;            = ;            = ;    
>          = ; 
>          = ;            = ; = PM           &nbs= p;           &nbs= p;           &nbs= p; 
>          = ;            = ;            = ;            = ;            = ;    
>          = ; 
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ; 
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ; 
>
>
>
>
> Mircea,
>
> I believe 1) (new OID) is the most appropriate = option.
> draft-ietf-policy-core requests an OID be = assigned to
> it for schema elements it specifies. It does = not detail
> considerations for how other documents my make = sub-delegations,
> hence other documents need to get their own = delegation
> from IANA.
>
> Kurt
>
>
> = _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy
>
>
>
>
> = _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy
>

------_=_NextPart_001_01C33F0C.DA664A00-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy