Subject: [Diffserv] RFC 3289 DiffServ MIB discrepancies

From: Tom Irwin <[email-masked]>
Date: Thu, 08 Aug 2002 09:33:09 -0500

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.

Thank you,
Tom

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

---

From: Fred Baker <[email-masked]>
Date: Fri, 16 Aug 2002 09:04:47 -0700

Tom has noted some issues, which sound like they call for an updated RFC. 
I'm wondering if any other issues need to be addressed in the update?

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Aug 2002 09:14:05 +0200

> I'm wondering if any other issues need to be addressed in the update?

Since nobody else raised any issues in over a week, I suggest that Fred
goes ahead with an update.

   Brian

---

From: Tom Irwin <[email-masked]>
Date: Tue, 27 Aug 2002 09:58:40 -0500

I have additional input if the DiffServ RFC is going to be updated.

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

Thank you for your work,
Tom Irwin

---

From: Fred Baker <[email-masked]>
Date: Tue, 27 Aug 2002 12:50:22 -0700

>I have additional input if the DiffServ RFC is going to be updated.

It appears that this set of comments were only submitted because Brian said 
"so we're going to do something about them." If anyone else has specific 
comments that should be addressed, the time to put them to the list is now.