Subject: RE: [Policy] AD review of: draft-ietf-policy-qos-device-info-mod el-10.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 03 Jun 2003 11:31:45 -0400

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:[email-masked]]
> > Sent: vrijdag 23 mei 2003 21:20
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > 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 <bob>'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:[email-masked]]
> > > Sent: maandag 19 mei 2003 2:15
> > > To: Wijnen, Bert (Bert)
> > > Cc: [email-masked]
> > > Subject: Re: [Policy] AD review of:
> > > draft-ietf-policy-qos-device-info-model-08.txt
> > >
> > .. snip ..
> > >
> > >   - is the reference to cim 2.5 correct?
> > > <yes, I believe that it is; certainly, on the DMTF side,
> > > 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?
> > <bob> 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.</bob>
> > .. snip ..
> >
> > >   - I see some Msoft characters in the doc (page 12 and 64 are
> > >     examples)
> > > <I found and fixed the on on p. 12, but I couldn't find 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.
> > <bob> 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.</bob>
> >
> > >
> > > - 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 ??
> > > <I did not change anything here, since I wasn't sure 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.
> > <bob>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).</bob>
> > .. snip ..
> >
> > > - Page 11.
> > >   It might help if in the figure you indicate where we find
> > >   CIM, PCIM, PCIMe, QPIM, QDDIM. etc
> > > <this is actually a fairly deep question that we never got to
> > > 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.
> > > <I didn't change anything here -- I think the reader can tell
> > > 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?
> > > <in PCIM and PCIMe, many of the descriptions came from 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" ??
> > <bob>I'd prefer "otherwise focused" here:-)</bob>
> >
> > > - Does Class TockenBucketMeterService not need a
> > deltaInterval property?
> > >   Otherwise what does the AverageRate property mean?
> > > <this is the first comment that really touches on the QDDIM
> > 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?
> > <bob>This one is still unresolved -- Walter said that this probably
> > "deserves" additional text, but he didn't provide it.</bob>
> >
> > > - Do we still want/need a class TosMarkerService and a property of
> > ToSValue?
> > >   Has ToS not been obsoleted?
> > > <another comment on the model itself>
> > >
> > is there no answer to my question, though?
> > <bob>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?</bob>
> > .. snip ..
> >
> > > - sect 4.3.37.2
> > >   Would it not be better to use a 32bit unsigned?
> > > <another comment on the model itself>
> > >
> > 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.
> > <bob>Based on Walter's response, I've change this to a uint32.</bob>
> >
> > .. 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?
> > > <another comment on the model>
> > >
> > Could you suggest an answer to my question?
> > Like: hey Bert cool off...
> > Oh well
> > <bob>I added some text based on Walter's response -- and as
> > requested, it's a little more concise than his:-)</bob>
> >
> > > <you missed it, but there was some editorial cleanup in section
> > > 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
> > [email-masked]
> >
>_______________________________________________
>Policy mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/policy

_______________________________________________
Policy mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/policy

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 3 Jun 2003 17:49:46 +0200

IETF Las Call has been requested for both documents
as Proposed Standard

Thanks,
Bert 

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: dinsdag 3 juni 2003 17:32
> To: Wijnen, Bert (Bert); [email-masked]
> Cc: [email-masked]
> draft-ietf-policy-qos-device-info-mod el-10.txt
> 
> 
> Yes.
> Thank you,
> Joel
>