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

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]
>