RE: AD review of: draft-ietf-policy-qos-device-info-mode l-08.txt

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?

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

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

.. 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" ??

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

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

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

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

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