Subject: [Diffserv] MIB Comments from Kwok

From: Fred Baker <[email-masked]>
Date: Fri, 20 Jul 2001 11:15:12 -0700

On the MIB I am posting today, Kwok has made a number of comments that I 
have not had the cycles to correct. These are comments on an interim 
document that I circulated among the authors, and some of them don't quite 
apply to the current draft. However, rather than making Kwok sort through 
them and reword for the posted draft, I simply post the comments.

You will see in a separate note that I have been scratching my head about 
the classifier table; several folks have complained about complexity in 
using the MIB as designed, and I think this particular table is a major 
contributor there. There are some comments in this list that apply if and 
only if we decide to remove the classifier table from the MIB, as I did in 
the interim draft.

>Title:     Review Results of draft-ietf-diffserv-mib-10.txt 06/12/2001 Version
>Author: Kwok Ho Chan
>Date:     07/02/2001
>
>
>Comments for the Text Sections:
>1.      Pg 3 Sec 2.1 Last Paragraph.  "The Data Path Start Table provides 
>a starting …", it should be "The Data Path Table provides…".
>2.      Pg 4 Sec 2.2 2nd Paragraph.  "Other MIBs and data structure 
>definitions … the model in other ways.", please change to "Other MIBs and 
>data structure … the model in other ways, for example, [DSPIB].
>3.      Pg 5 Sec 3 Last Paragraph, Last Sentence.  "Similarly, if a new 
>action is required, the "next" pointer of the previous functional datapath 
>element could point to an Entry defined in a proprietary MIB or one 
>defined in another standard." Is misleading.  If new Action is required, 
>new Action Parameterization Table/Entry can be defined in some other MIB, 
>and diffServActionTable/Entry does not need to be changed.  As I am 
>thinking for this part of the paragraph you are trying to express how a 
>new Data Path Functional Element (the first part of the paragraph already 
>gave a new parameterization table example) can be defined, I think using 
>the Queuing structure may be a better example.  Hence I propose to replace 
>the affect sentence with "Similarly, if a device uses a completely 
>different Queuing Architecture, the  "next" pointer of the previous 
>functional datapath element could point to a Queuing datapath functional 
>element table entry defined in a proprietary MIB or one defined in another 
>standard."
>4.      Pg 7 Sec 3.2.1 Second Paragraph.  Classifier.
>5.      Pg 8 Sec 3.2.1 Last Paragraph.  Classifier
>6.      Pg 8 Sec 3.2.2 First Paragraph.  "This classifier 
>matches:",  should we use "This filter matches:" ??
>7.      Pg 9 Sec 3.3 First Paragraph.  "However, various factors ... 
>multiple classes of traffic may occasionally schedule their traffic and 
>the same time," typo, should be "schedule their traffic at the same 
>time,".  Also need consistent usage of quoting "meter" and "shaper".
>8.      Pg 11 Sec 3.3.2.  Spelling error "montonically" should be 
>"monotonically".
>9.      Pg 12 Sec 3.4.  "create-and-go" and "create-and-wait" sometimes 
>have extra space after the "-".  There are other instances of this in 
>other parts of the text using "create-and-XXX".  This is a nroff feature, 
>correct?
>10.     Pg 13 Sec 3.4.3.  "I might be viewed not …" should be "It might be 
>viewed not …".
>11.     Pg 14 Bottom.  Numbering the picture Figure 1.
>12.     Pg 15 Sec 3.4.5.  Usage of DiffServRandomDropInvWeight, should use 
>diffServRandomDropWeight as in the MIB module.  Also uppercase MIB 
>attribute name "DiffServ.." should be changed back to lowercase 
>"diffServ…" in multiple places.
>13.     Pg 16 Sec 3.5.1 Third Paragraph.  "… as in Section .sh 4 " The 
>parameter is associated with the queue, however, using the Assured or 
>Shaping Rate Parameter Table." need some fixing.
>14.     Pg 16 Sec 3.5.1 Last Paragraph.  "agent- specific" extra space 
>after the dash.
>15.     Pg 17 Sec 3.5.3 First Paragraph. How about replacing "This MIB 
>assumes excess capacity is distributed proportionally among the inputs to 
>a scheduler." with "This MIB assumes excess capacity is distributed 
>proportionally among the inputs to a scheduler using the assured 
>rate.  More complex excess capacity handling may be described by 
>augmenting this MIB."
>16.     Pg 17 Sec 3.5.3 Second Paragraph. "The effect of combining 
>priority and rate …" paragraph is not very clear, may need more explanation.
>17.     Pg 18 Sec 3.5.4 Second Paragraph. "In this case, an algorithm such 
>as SHAPING" should be "In this case, an algorithm such as [SHAPER]".
>18.     Pg 18 Sec 3.5.5 Second Paragraph. "For Weighed Queuing methods", 
>should we use "For Weighted Scheduling methods"?
>19.     Pg 18 Bottom.  Numbering the picture Figure 2.
>20.     Pg 19 Sec 3.5.5 at top of page.  "The rate may be represented by a 
>relative value, as a fraction of the interface's current line 
>rate.  DiffServAssuredRateRel to assist …" should be "The rate may be 
>represented by a relative value, diffServAssuredRateRel, as a fraction of 
>the interface's current line rate to assist …".
>21.     Pg 19 Sec 3.5.5 at top of page.  "An example is found in figure 
>4.".  Should this be changed to Figure 3?
>22.     Pg 19 Sec 3.5.5 Fourth Paragraph. "MODEL" should be 
>"[MODEL]".  Also in other places in the draft.
>23.     Pg 19 Bottom.  Numbering the picture Figure 3.
>24.     Pg 20 Bottom.  Numbering the top picture Figure 4, the bottom 
>picture Figure 5.  Should the terms Max Rate, Maximum Rate, Min Rate be 
>changed to Assured Rate and Shaping Rate as used in the MIB module?  Also 
>moving the Figures closer to where they are referenced will help, but may 
>do this as the last thing as moving pictures in nroff is not that fun.
>25.     Pg 21 First Two Paragraphs.  "Queue Table entries …" and "A common 
>requirement of a queue …" are extra cut and paste repeating Section 3.5.1 
>Paragraph 2.
>26.     Pg 21 Last sentence before Sec 3.6.  "See figure 4." should be 
>"See Figure 6."
>27.     Pg 21 Bottom. Number the picture Figure 6 and put it before 
>Section 3.6.
>28.     Pg 22 Sec 3.6.1.  "dealth" should be "dealt".
>29.     Pg 22 Sec 3.6.1.1.  The paragraph "An example of a classifier for 
>an AFm …" can also be described with "A single Classifier with 13 
>Classifier Elements:  1 EF Classifier Element, 12 AF Classifier Elements 
>(4 AFm with m={1,2,3}).  But this have to do with keeping 
>ClassfierTable/Entry or not.
>30.     Pg 22 Bottom.  Numbering the picture Figure 7 and moving it to 
>before Section 3.6.1.1.
>31.     Pg 23 Sec 3.6.1.1.  Third Paragraph.  "parameter blocks spedifying 
>individual telephone calls".  Not sure we want to make such a suggestion 
>or example.  I didn't think this is the right thing to do but there are a 
>lot of things I don't know of.
>32.     Pg 23 Sec 3.6.1.2 and 3.6.1.2.1.  "Each Afm" should be "Each AFm".
>33.     Pg 24 Sec 3.6.1.2.2 and 3.6.1.3.2.  "To indicate this, we set the 
>"SucceedNext" pointer of the Mark Action is left at ZeroDotZero." Should 
>be "To indicate this, the "SucceedNext" pointer of the Mark Action is left 
>at ZeroDotZero.".
>34.     Pg 25 Top.  Number the picture Figure 8.
>35.     Pg 26 Sec 3.7.1 Second and Third Paragraphs.  "An example of a 
>classifier for an AFm class would be a succession of three classifier 
>elements, …".   How does this works?  I think each classifier element of 
>an AFm class must have the same Classifier ID to indicate they are to be 
>evaluated together.  From outside of the box, the evaluation needs to look 
>like being done together, not in succession, hence the use of Classifier 
>Table/Entry (keeping it).
>36.     Pg 26 Sec 3.7.2 and 3.7.2.1.  "Each Afm" should be "Each AFm".
>37.     Pg 29 Sec 4.1 First Paragraph.  "One of the ways it this MIB" 
>should be "One of the ways this MIB".
>38.     Pg 29 Sec 4.1 Second, Third Paragraphs and in Note --.  "MODEL" 
>should be "[MODEL]".
>39.     Pg 29 Sec 4.1 Third Paragraph.  "that suchconfiguration" should be 
>"that such configureation".
>40.     Pg 30 Sec 5 Last Paragraph.  "one.  counter actions." cleanup.
>41.     Pg 104 Sec 9 Reference.  The spell checker 'in-corrected' 
>"draft-ietf-diffserv-…" into "draft-ietf-Differentiated Services-…".
>42.     Pg 105 Sec 9 Reference.  "MODEL" should be "[MODEL]".

>Title:     Review Results #2 of draft-ietf-diffserv-mib-10.txt 06/12/2001 
>Version
>Author: Kwok Ho Chan
>Date:     07/11/2001
>
>
>The Review Results in this memo is IN ADDITION to the Review Results dated 
>07/02/2001.  Hence the comments numbering continues with 43.
>
>More Comments for the Text Sections:
>43.     Pg 6 Sec 3.1.1 Last Paragraph.  Use of "ZeroDotZero" in the text 
>sections should be "zeroDotZero".  Also on Pg 7(twice), 11, 24(twice), 
>65(diffServAlgDropType).
>44.     Pg 6 Sec 3.2 End of 3rd Paragraph.  Current: "all classification 
>elements of one precedence are applied as if in parallel, and then all 
>classification elements of the next precedence."  Suggest new text: 
>"within a single classifier, all classification elements of one precedence 
>are applied as if in parallel (the logical AND operation), and then all 
>classification elements of the next precedence (the logical OR operation)."
>
>Comments for the MIB Module:
>45.     Usage of "Differentiated Services Functional Data Path Elements" 
>and "Differentiated Services Functional Data Path elements" be more consistent.
>46.     Pg 38 Classifier Table explanation text.  After removal of 
>diffServClfrTable/Entry, Classifier Table does not exist anymore, only the 
>concept remains with the use of diffServClfrElementClfrId.  The 
>explanation text at the top of the MIB classifier section (and the section 
>name itself) needs to be re-worded.
>47.     Pg 38 diffServClfrNextFree, Description Clause. "diffServClfrId" 
>should be "diffServClfrElementClfrId".  "diffServClfrTable" don't exist 
>anymore.
>48.     Pg 40 diffServClfrElementClfrId, Description Clause.  "… 
>enumerates the classifier entries", what entries?  (I want the entries.)
>49.     Pg 40 diffServClfrElementClfrId and diffServClfrElementId 
>attribute numbering swapped.
>50.     Pg 42 diffServClfrElementStatus, Description Clause.  "writ- able" 
>side effect of auto text formatting.  You may want to search for other 
>occurrence of "- ".
>51.     Pg 43-44 diffServSixTupleClfrEntry.  Attribute numbering need fixing.
>52.     Pg 47 Meters Section description, srTCM, trTCM, and tswTCM 
>writeups.  Can we change them to: "srTCM meters (RFC 2697) can be 
>specified using two sets of diffServMeterEntry and diffServTBParamEntry. 
>First set specifies the Committed Information Rate and Committed Burst 
>Size token-bucket.  Second set specifies the Excess Burst Size 
>token-bucket."   "trTCM meters (RFC 2698) can be specified using two sets 
>of diffServMeterEntry and diffServTBParamEntry. First set specifies the 
>Committed Information Rate and Committed Burst Size token-bucket.  Second 
>set specifies the Peak Information Rate and Peak Burst Size 
>token-bucket."  "tswTCM meters (RFC 2859) can be specified using two sets 
>of diffServMeterEntry and diffServTBParamEntry. First set specifies the 
>Committed Target Rate token-bucket.  Second set specifies the Peak Target 
>Rate token-bucket. diffServTBParamInterval in each token bucket reflects 
>the Average Interval."
>53.     Pg 47 Meters Section description.  the "" that ends the 
>descpription section (the line below "diffServMeter") needs to be moved to 
>before "diffServMeterNextFree".
>54.     Pg 48-51.  Since diffServShapingRateTable/Entry is introduced, 
>diffServMeter and diffServTBParamTable will not be used for shaping 
>purpose, hence removing any reference to shaping.  Specifically:
>Pg 48 diffServMeterTable Description Clause.  "may use to police, or 
>shape, a stream" should be "may use to police a stream".
>Pg 50 diffServTBParam Description Section.  "shared by multiple 
>diffServMeterTable and diffServSchedulerTable entries" should be "shared 
>by multiple diffServMeterTable entries".
>Page 51 diffServTBParamTable Description Clause.  "may use to police or 
>shape a stream" should be "may use to police a stream".
>55.     Pg 52 diffServTBParamType Description Clause.  "OBJECT-IDENTITYS" 
>should be "OBJECT-IDENTITYs".
>56.     Pg 52 diffServTBParamRate Description Clause.  "2. PIR and CIR in 
>RFC 2698…" should be "2. CIR and PIR in RFC 2698…".
>57.     Pg 53 diffServTBParamSimpleTokenBucket Description 
>Clause.  Replace "The value tokenBucket (2) indicates" with "Indicates".
>58.     Pg 53 diffServTBParamAvgRate Description Clause.  Replace "The 
>value avgRate (3) indicates" with "Indicates".
>59.     Pg 54 diffServTBParamSrTCMBlind Description Clause.  Replace "The 
>values srTCMBlind (4) and srTCMAware (5) indicate" with 
>"Indicates".  Replace "in either the 'Color Blind' and 'Color Aware' mode" 
>with "in the 'Color Blind' mode".
>60.     Pg 54 diffServTBParamSrTCMAware Description Clause.  Replace "The 
>values srTCMBlind (4) and srTCMAware (5) indicate" with 
>"Indicates".  Replace "in either the 'Color Blind' and 'Color Aware' mode" 
>with "in the 'Color Aware' mode".
>61.     Pg 54 diffServTBParamTrTCMBlind Description Clause.  Replace "The 
>values trTCMBlind (6) and trTCMAware (7) indicate" with 
>"Indicates".  Replace "in either the 'Color Blind' and 'Color Aware' mode" 
>with "in the 'Color Blind' mode".
>62.     Pg 54 diffServTBParamTrTCMAware Description Clause.  Replace "The 
>values trTCMBlind (6) and trTCMAware (7) indicate" with 
>"Indicates".  Replace "in either the 'Color Blind' and 'Color Aware' mode" 
>with "in the 'Color Aware' mode".
>63.     Pg 54 diffServTBParamTswTCM Description Clause.  Replace "The 
>value tswTCM (8) indicates" with "Indicates".
>64.     Pg 57 diffServActionNext Description 
>Clause.  "diffServAlgDropEntry" was removed, reasoning?  Let me try to 
>answer this: After removing AlwaysDrop Action and with counters in AlgDrop 
>, it will not make sense to put Action before AlgDrop. One will always 
>perform AlgDrop before MarkAct.  Correct?  Do we want to put such a limit 
>on linking Action before AlgDrop?
>65.     Pg 59 Count Action Table Description Section.  "for example before 
>a drop action", AlwaysDropAct don't exist anymore, hence this phase should 
>be removed.
>66.     Pg 65 diffServAlgDropType Description Clause.  "In the randomDrop 
>(4) … diffServAlgQThreshold" should be "diffServAlgDropQThreshold".  "The 
>alwaysDrop (5) … There is no useful the queue are not useful.  Therefore," 
>should be "In this case the queue is not used, therefore".  And some 
>typos: "diffServAlgQNext" should be "diffServAlgDropNext", 
>"diffServAlgQMeasure" should be "diffServAlgDropQMeasure", 
>"diffServAlgQSpecific" should be "diffServAlgDropSpecific".  Also 
>"ZeroDotZero" should be "zeroDotZero".
>67.     Pg 68 diffServAlgDropStatus.  "{ diffServAlgDropEntry 11 }" should 
>be "{ diffServAlgDropEntry 12 }".
>68.     Pg 78 diffServSchedulerPriority Description Clause.  "When the 
>next scheduler …" should be "For use with diffServSchedulerMethod when the 
>next scheduler …".
>69.     Pg 80 diffServAssuredRatePriority Description Clause.  How about 
>adding a phase "Higher Priority value indicates the associated 
>queue/scheduler will get service first before others with lower Priority 
>values.".
>70.     Pg 81 diffServAssuredRateRel Description Clause. "in units of 
>1/1000 of 1." should be "in units of 1/10,000 of 1" as in DSMIB-09.
>71.     Pg 81 diffServAssuredRateAbs/Rel and diffServShapingRateAbs/Rel 
>Description Clause.  IFMIB/RFC2233 have ifSpeed as Garge32 in units of 
>bits per second, and ifHighSpeed as Garge32 in units of 1,000,000 bits per 
>second.  This yields the following equations:
>RateRel = [ (RateAbs * 1000) / ifSpeed ] * 10,000
>Where 1000 is for converting kbps used by RateAbs to bps used by ifSpeed, 
>10,000 is for "in units of 1/10,000 of 1" for RateRel.
>And
>         RateRel = { [ (RateAbs * 1000) / 1,000,000 ] / ifHIghSpeed } * 10,000
>Where 1000 and 1,000,000 is for converting kbps used by RateAbs to 1 
>million bps used by ifHighSpeed, 10,000 is for "in units of 1/10,000 of 1" 
>for RateRel.
>Laying all the numbers out and with the explanation should minimize the 
>confusion.
>72.     Pg 83 Shaping Parameter Table Description Section Second 
>Paragraph.  "positing" do you mean "positioning"?

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html