RFC Errata
Found 3 records.
Status: Verified (2)
RFC 3289, "Management Information Base for the Differentiated Services Architecture", May 2002
Source of RFC: diffserv (tsv)Errata ID: 300
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Irwin
Date Reported: 2002-08-08
Report Text:
In the process of implementing the RFC 3289 DiffServ MIB, the following errors and discrepancies were noted. 1. In the diffServClfrTable description (second paragraph), diffServClfrStatus should be diffServClfrStorage. This is an understandability issue. 2. The diffServClfrElementStatus description indicates that this entry cannot be deleted if there is a RowPointer pointing to it. A RowPointer is not used to select a classifier element, but rather the diffServClfrId and diffServClfrElementId index values. Consequently, the diffServClfrElementTable does not require a UsageCounter or a DestroyFlag. This is an understandability issue. 3. In the diffServActionSpecific description (third paragraph) erroneously references a meter. This is an understandability issue. 4. The diffServMinRateAbsolute description indicates that zero is a valid value. The SYNTAX range indicates (1..4294967295), but should be (0..4294967295). This is an understandability issue and a MIB implementation issue. 5. The diffServMinRateRelative description indicates that zero is a valid value and that the values are in units of 1/1000 of 1. The SYNTAX range indicates (1..4294967295), but should be (0..1000). This is an understandability issue and a MIB implementation issue. 6. The diffServMaxRateAbsolute description indicates that zero is a valid value. The SYNTAX range indicates (1..4294967295), but should be (0..4294967295). This is an understandability issue and a MIB implementation issue. 7. The diffServMaxRateRelative description indicates that zero is a valid value and that the values are in units of 1/1000 of 1. The SYNTAX range indicates (1..4294967295), but should be (0..1000). This is an understandability issue and a MIB implementation issue.
Errata ID: 301
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Irwin
Date Reported: 2002-08-27
Report Text:
1. During implementation, there has been some confusion on the "reuse
of structural elements" in section 2.2. It is clear from the comments
and the MIB that counters cannot be effectively reused. What appears
confusing is the case when an entire (or partial) DiffServ tree used for
a specific interface ifIndex and direction is reused. Is the DiffServ
tree in this case just a template such that all of the data path
elements are replicated (counters will not work properly) for another
interface? This seems reasonable since other data path elements such as
queues and schedulers are clearly interface dependent. It is important
to remove this ambiguity since the RowPointer usage does not prohibit
this "not generally recommended" application. What is the intent?
2. Minor update in section 3.2.2:
' Differentiated Services Code Point ' to
' Differentiated Services Code Point, including "any" '
3. Figure 9b in section 3.7.2.1 is somewhat difficult at first to follow
due to how the multiplexing is shown in the Yellow "Count Action" (an
action only has a single input).
Status: Held for Document Update (1)
RFC 3289, "Management Information Base for the Differentiated Services Architecture", May 2002
Source of RFC: diffserv (tsv)
Errata ID: 2976
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ina Singh
Date Reported: 2011-09-21
Held for Document Update by: Wesley Eddy
Section 3.4.5. says:
diffServRandomDropInvProbMax represents Pmax (inverse). This MIB does not represent Pmin (assumed to be zero unless otherwise represented). In addition, since message memory is finite, queues generally have some upper bound above which they are incapable of storing additional traffic. Normally this number is equal to Qclip, specified by diffServAlgDropQThreshold.
It should say:
The average queue depth beyond which traffic has a probability
indicated by diffServRandomDropProbMax of being dropped or
marked. Note that this differs from the physical queue limit,
which is stored in diffServAlgDropQThreshold.
Notes:
diffServRandomDropInvProbMax should be removed
Attaching the e-mail confirmation from Fred :
==============================================
From: Fred Baker (fred)
Sent: Tuesday, September 20, 2011 10:54 PM
To: Ina Singh (inasingh)
Subject: Re: RFC3289/DiffesrvMIB SFS
Thanks for pointing this out. Correct me if I'm wrong; it looks to me like diffServRandomDropInvProbMax only shows up in the comment in section 3.4.5, and diffServRandomDropProbMax is used throughout the MIB. Yes, the comment should be fixed, but the MIB is itself correct with diffServRandomDropProbMax. Correct?
The right thing to do is file an erratum against RFC 3289, so that if it is edited in the future the error can be picked up, and implementers can see it.
http://www.ietf.org/iesg/statement/errata-processing.html describes the process.
On Sep 20, 2011, at 6:50 PM, Ina Singh (inasingh) wrote:
> Hey Fred,
>
> While implementing RFC3289/DiffesrvMIB SFS recently on IOS, we noticed the following error :
> It would seem that diffServRandomDropInvProbMax was replaced by
> diffServRandomDropProbMax (?) , but the reference to “diffServRandomDropInvProbMax” was not removed on subsequent versions.
>
> Can you please confirm, if so, what’s the procedure to correct it ..
>
> Thanks in advance for your help in this and appreciate your time..
>
> Ina
>
> Definition of "diffServRandomDropInvProbMax" upto version 7, here is a link for draft version 6.
>
> http://tools.ietf.org/html/draft-ietf-diffserv-mib-06
>
> iffServRandomDropInvProbMax OBJECT-TYPE
> SYNTAX Unsigned32
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "The worst case random drop probability, expressed as
> the inverse of the drop probability. With special
> case of the value zero meaning zero probability of
> drop.
>
> For example, if every packet may be dropped in the
> worst case (100%), this has the value of
> 4,294,967,295."
> ::= { diffServRandomDropEntry 6 }
>
>
>
> In contrast to "diffServRandomDropProbMax" starting from version 8.
>
>
> diffServRandomDropProbMax OBJECT-TYPE
>
> SYNTAX Unsigned32 (0..1000)
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "The worst case random drop probability, expressed in drops per
> thousand packets.
>
> For example, if in the worst case every arriving packet may be
> dropped (100%) for a period, this has the value 1000.
> Alternatively, if in the worst case only one percent (1%) of
> traffic may be dropped, it has the value 10."
> ::= { diffServRandomDropEntry 6 }