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