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

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:[email protected]]
> > Sent: vrijdag 23 mei 2003 21:20
> > To: [email protected]
> > Cc: [email protected]; [email protected]; [email protected]
> > 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 protected]]
> > > Sent: maandag 19 mei 2003 2:15
> > > To: Wijnen, Bert (Bert)
> > > Cc: [email protected]
> > > 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 protected]
> > 
> _______________________________________________
> Policy mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/policy