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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 19 May 2003 16:45:51 +0200

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

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 19 May 2003 23:47:29 +0200

Taking another look at the doc (rev 9) and checking for
changes since rev 08, I see that you did not list
that you removed section 4.3.20.2. That was not based
on my comments but for some other reason I guess.
So I am listing it just so thw WG knows and maybe Bob
can explain why it was removed.

In Sect 4.3.41 you changed  PrioritySchedulingElement
into PrioritySchedulerElement. Is that correct?
I wonder cause I do not see PrioritySchedulerElement
anywhere else in the document.

In sect 4.4.5 You changed cardinality 1..n into 1..1
Good for people to know that too. And why was it done?
Not based on my comments I assume.

In sect 4.4.6 you changed cardinality 1..1 into 0..1.
Explanation?

In sect 4.4.9 You changed cardinality 1..n into 1..1

people who want to see all the changes colored in the text
can take a look at: http://psg.com/~bwijnen/qddim.html

Thanks,
Bert 

> I've submitted QDDIM09 to the I-Ds repository, so it should 
> be published in
> a day or two. I've summarized below what I did to address 
> each of Bert's
> points.
> 
> In a separate note, Bert asked whether QDDIM should still be standards
> track.  I'm not sure how to answer that question.  My 
> inclination, though,
> would be to say that it should remain a standards track 
> document, since (1)
> we've established the precedent that Information Models 
> (specifically, PCIM
> and PCIMe) are standards track documents, and (2) of the two 
> Data Models
> corresponding to QDDIM, the DiffServ MIB is a proposed 
> standard, and the
> DiffServ PIB is informational because of SPPI / COPS reasons, 
> not because
> of DiffServ reasons.
> 
> Regards,
> Bob
> 
> Bob Moore
> WebSphere Advanced Design and Technology
> WebSphere Platform System House
> IBM Software Group
> +1-919-254-4436
> [email-masked]
> 
> 
> 
>                                                               
>                                                               
>            
>                       "Wijnen, Bert                           
>                                                               
>            
>                       (Bert)"                  To:       
> [email-masked]                                               
>                 
>                       <[email-masked]        cc:            
>                                                               
>            
>                       om>                      Subject:  
> [Policy] AD review of: 
>                       Sent by:                                
>                       policy-admin@ietf                       
>                       .org                                    
>                       04/09/2003 12:42                        
>                       PM                                      
> OK, here is my review (finally... blush)
> 
> - Needs to be checked against ID-NITS,
>   see: http://www.ietf.org/ID-nits.html
>   Also pls check against RFC2223bis
>   see draft-rfc-editor-rfc2223bis-04.txt
>   Things that fall under this category:
>   - no citations in abstract
> <fixed>
>   - split references in normative and informative
> <fixed>
>   - expand Acronyms when used for the first time
> <fixed>
>   - use proper references in the references section
> <fixed>
>   - not sure if the IP address as on page 7 is allowed
>     according to ID-NITs
> <I changed these>
>   - many referenced documents have become RFCs now. You may want
>     to update those.
> <done>
> 
> - In the abstract, I think that the last piece needs to
>   be removed. That is:
> 
>                       A separate draft could be written to provide
>      a mapping of the data contained in this document to a form
>      suitable for implementation in a directory that uses (L)DAP as
>      its access protocol.  Similarly, a draft could be written to
>      provide a mapping of the data in [QPIM] to a directory.
>      Together, these four drafts (information models and directory
>      schema mappings) would then describe how to write QoS policy
>      rules that can be used to store information in directories to
>      configure device QoS mechanisms.
> 
>   Cause that tells what "could be done" but that cannot be the
>   "abstract" for this document, can it?
> <fixed>
> 
> - The document speaks about "this draft" a lot. I think it should
>   be changed throughout the document into "this document". So that
>   once it is published we do not see "this draft" anymore.
> <fixed>
> 
> - Page 11.
> - I see (as an example on page 16/17) QoSService as a class.
>   Then the doc talks about the plural QoSServices, and I am not
>   sure if it always means QoSService Instances or subclasses of
>   QoSService. At other places it talks about "QoS services"
>   which seems better to me
> <fixed>
> 
> - Page 17 I see:
>     Note that this work is not yet completely aligned, as there are
>     differences among the DiffServ Informal Management Model, the
>     DiffServ MIB, the DiffServ PIB, and this draft.  Work to finish
>     aligning these drafts is in progress, and will be reflected in
>     the next revision of this draft.
>   Does this mean you were expecting a new rev of QDDIM anyway?
>   Anyway, such text probably does not belong in a doc that goes
>   for RFC publication.
> <I removed this text>
> 
> - AS an example: I see on page 21
>     Implementations may recognize other <type>'s in addition to
>     these.  If collisions of implementation-specific <type>'s become
>     a problem, it is possible that <type>'s may become an IANA-
>     administered range in a future revision of this standard.
>   This document itself should not claim that it is a standard. Or
>   at least not in the text. If it gets approved as stds track then
>   RFC-Editor will add that in the footing. I suggest to use
>   "this document" instead of "this standard".
>   Pls check if there are more occurences.
> <fixed -- the document no longer refers to itself as a standard>
> 
> - On page 37 you claim (at top) that "is shown in figure 9" but
>   I think it is actually figure 10.
>   On page 38 it should be figure 11 instead of 10 (or so I think)
> <fixed>
> 
> - Class REDDropperService derives from DropperService.
>   Does the ingeritedDropperType always have the value "Random" ??
> <yes>
> 
> - sect 4.3.21.2 does not even tell the datatype of the property
> <fixed>
> 
> - Sect 4.3.26
>   I am being told that the proper name for a flow label is FlowLabel
>   and not FlowID. Not sure how serious this is.
> <I've left the property name as it was, but inserted descriptive text
> that talks about "FlowLabel".>
> 
> - Section 4.3.34
>   I do not see any of the properties described, do I?
> <I've removed the definition from this section, and referred 
> the reader
> to CIM for the definition. This is how it should have been all along,
> just as it is for the other CIM classes that QDDIM references.>
> 
> - sect 4.3.37.2
> - sect 4.3.37.5
>   May I assume that the buffers are being shared?
>   That is not so clear from the description (at least not to me).
> <I'm not sure I understand your point here, since the name of
> the property is "SharedBuffers".>
> 
> - Sect 4.3.40
>   Explain what WRR stands for
> <fixed>
> 
> - sect 4.3.40.1
>   Here I wonder if a 16 bit unsigned would not be more than sufficient
>   Its units are "thousands" ?? Thousands of what?
> <it's thousandths, not thousands.  Since it's just a 
> multiplier, it has
>               ^^
> no units>
> 
> - sect 4.3.4.2
> - Sect 4.4.18 and 4.4.19
>   Am I missing Property descriptions?
> <fixed>
> 
> - sec 4.4.28
>   Am I missing Property descriptions?
> <fixed>
> 
> Thanks,
> Bert

---

From: Robert Moore <[email-masked]>
Date: Tue, 20 May 2003 12:35:44 -0400

Hi Bert,

I didn't list these changes because I wasn't aware I had made them!
Checking back, it appears that I started the -09 edits on a slightly
out-of-date version of the -08 source file.  So I did an inadvertent
rollback on the very last changes that were made for -08.  I'm pretty sure
the set of such changes exactly matches these you've identified here.

I'll do a quick update to fix these items, and publish a -10.  Meanwhile,
if any of the authors who still do QoS for a living want to respond to your
other set of comments, I'll factor in any changes they propose.  I'm afraid
that network QoS is now so far in my past that it would be a bad idea for
me to even try to make any substantive changes to the document at this
point.

Regards,
Bob

Bob Moore

                      "Wijnen, Bert                                                                                                    
                      (Bert)"                  To:       Robert Moore/Raleigh/IBM@IBMUS                                                
                      <[email-masked]        cc:       [email-masked]                                                               
                      om>                      Subject:  RE: [Policy] AD review of: draft-ietf-policy-qos-device-info-mode             
                                                l-08.txt                                                                               
                      05/19/03 05:47 PM                                                                                                

Thanks,
Bert

---

From: Robert Moore <[email-masked]>
Date: Fri, 23 May 2003 15:19:50 -0400

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:

Thanks,
Bert

.. snip ..

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

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>

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

.. snip ..

.. snip ..

<bob>I'd prefer "otherwise focused" here:-)</bob>

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>

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

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

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>

OK thanks

Bert
*******End Bert's note:

Regards,
Bob

Bob Moore