Subject: [Diffserv] yet another MIB

From: Fred Baker <[email-masked]>
Date: Mon, 17 Sep 2001 08:39:00 -0700

Please review

  ftp://ftpeng.cisco.com/fred/diffserv/draft-ietf-diffserv-mib-13.txt
  ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-13.txt

This has been sent off to internet-drafts for posting, and responds to 
comments from Harrie Hazewinkel and Bert Wijnen, as well as on the list.

There is another issue on the table, and as no consensus seems to be 
developing among the folks talking about it (there are some on each side, 
and one that has expressed a preference for both sides), I'm opening it to 
a wider audience.

This MIB has two compliance clauses: one for read only capability, and one 
for read/write. Some would like them named

         diffServMIBReadWriteCompliance
and     diffServMIBReadOnlyCompliance

and some would like them named

         diffServMIBFullCompliance
and     diffServMIBCompliance

The argument is basically a political one - shall we give them names that 
describe what they mean, or shall we give them names that indicate that 
this working group would like to see vendors pressured in the direction of 
read/write implementations? Compliance with either clause is indeed 
compliance: a vendor can claim full compliance to the compliance clause he 
chooses. But by naming it in the latter way, the vendor might be pushed by 
a customer to implement "diffServMIBFullCompliance" (read/write capability) 
even though the customer plans to use an SNMPv1 browser such as HP 
Openview, because the customer unknowledgably believes that full compliance 
has something to do with implementation of all of the objects.

I'd appreciate working group commentary and consensus.

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

---

From: "Andrew Smith" <[email-masked]>
Date: Thu, 13 Sep 2001 19:45:49 -0700

Fred wrote:
> Some would like them named
>

and some suggested the compromise of:

which, I believe, encapsulates the sentiment that, if you only implement
half the objects, you shouldn't get to claim "full" anything. I would
propose we adopt this naming.

I'll ignore Fred's rant about stupid customers which I do not think is
relevant to this discussion.

Andrew Smith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Fred Baker
Sent: Monday, September 17, 2001 8:39 AM
To: [email-masked]
Subject: [Diffserv] yet another MIB

Please review

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

---

From: Jon Saperia <[email-masked]>
Date: Sun, 16 Sep 2001 14:00:18 -0400

> has something to do with implementation of all of the objects.

The quick summary to my points below is that Andrew said it well. I

> and     diffServMIBReadOnlyCompliance

I agree that in some respects the issue is a political one. I can see
how Fred would put things the way he did. I have a different view
however, based on the following. 

        1. SNMP has been intended for configuration since the earliest
        days. A review of even the early SNMP RFCs reveals that more
        than monitoring was intended.

        2. One of the arguments that was made early on when 'writable'
        SNMP objects were objected to by the IESG is that security was
        not very good for SNMP, that argument is no longer true. I am
        aware of some of these objections since I have been on the
        receiving end of them from time to time.

        3. To properly manage a protocol, I think one needs to configure
        it as well, thus the desire for configuration objects. The MIB
        Modules that we have developed in the IETF to this point have
        been partial to my way of thinking since for the most part,
        write objects were fairly uncommon. A MIB Module that included
        read/write to facilitate configuration would be more in keeping
        with a fully specified management interface where a read only
        would be a partial one.

I am aware of the strong feelings for and against SNMP-based
configuration objects, but for the time being, as far as I know, we have
only one management standard. If the IETF would like to create a new
one, or create one for read and write that could be done. For now, I
think we do the community a disservice to not make clear what full
compliance with the standard for the management of our protocols
means. Full compliance means you support the full management interface
to the protocol/standard. 

One reason for providing the SNMP objects is that they can at least
expose what the protocol engineers think are reasonable 'knobs' to
control the standard aspects of a protocol even if the knobs are
implemented via proprietary CLI commands only. In a sense, the SNMP
configuration objects can have significant value by acting as a
canonical form for the community. Of course, I think of them as more
important than that, they should be implemented and some vendors do
that. We should not control them by not providing a standard set of
knobs. This makes everyone's job more difficult.

With this said, I am pleased that so much effort has been placed on
trying to get the right configuration and counter objects into the
document. That is the most important part, and is an improvement over
where we were.

/jon

> I'd appreciate working group commentary and consensus.

Thanks,
/jon
--

Jon Saperia		     [email-masked]
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/

---

From: Tom Irwin <[email-masked]>
Date: Mon, 17 Sep 2001 16:20:30 -0500

Hi Fred:

Your latest MIB file name indicates draft 13, but the file text
indicates draft 14.  Is this the correct MIB?

I get several MIB compile errors in the compliance section using the
industry standard Epilogue Technology "Emissary SNMP MIB Compiler,
version 9.1".

Here is an example error message:
processing object DIFFSERV-MIB:diffServMaxRateStatus
diffserv14.mi2:2704: A named number list may be applied only to the
INTEGER type itself, and not to a type derived from the INTEGER type.

Associated MIB text:
OBJECT diffServDataPathStatus
SYNTAX RowStatus { active(1) }
WRITE-SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) }
DESCRIPTION
   "Support for createAndWait and notInService is not required."

In order to compile the MIB, I had to comment out every similar
occurance.  Would you please correct these errors?

Thank you, 
Tom Irwin.

---

From: Fred Baker <[email-masked]>
Date: Mon, 17 Sep 2001 15:01:03 -0700

>    "Support for createAndWait and notInService is not required."

that text was produced by Bert Wijnen, who swears on a stack of 
appropriately holy books (all of them RFCs) that this is correct. It also 
passes Frank Strauss's smilint and Bert's copy of smicng.

dueling compilers :^)

---

From: Denton Gentry <[email-masked]>
Date: Fri, 28 Sep 2001 14:26:01 -0700

I hope I'm not about to make a fool out of myself, but I believe
there are several typos in Section 3.4.4 of draft13 of the diffServ
MIB. These are not substantive problems, merely editorial.
The last sentence of the second paragraph in section 3.4.4 reads:

"The action inspects the diffServQEntry that diffSeervAlgQMeasure
points to in to determine whether the packet should be dropped."

1. I believe "diffSeervAlgQMeasure" should be "diffServAlgDropQMeasure"
2. I believe "points to in to" should be "points to in order to"

--Denny