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

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

Thanks,
Bert 

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email protected]]
> Sent: dinsdag 3 juni 2003 17:32
> To: Wijnen, Bert (Bert); [email protected]
> Cc: [email protected]
> 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:[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
> 
>