Subject: RE: [Diffserv] yet another MIB

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 17 Sep 2001 17:48:02 +0200

Sure, no problem with that.

Bert 

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: maandag 17 september 2001 17:30
> To: Wijnen, Bert (Bert)
> Cc: Fred Baker; [email-masked]
> Subject: Re: [Diffserv] yet another MIB
> 
> 
> Let's treat this as an early Last Call comment.
> 
>    Brian
> 
> "Wijnen, Bert (Bert)" wrote:
> > 
> > Fred, when I do a syntax check with SMICng, I get
> > 
> >    C:\smicng\work>smicng diffserv.inc
> >    W: f(diffserv.mi2), (1189,1) Item "diffServActionInterface"
> >       is not contained in any group defined in the current module
> >    W: f(diffserv.mi2), (8,48) "TimeStamp" imported but not used
> > 
> > Can you pls fix those in the next go around.
> > 
> > Bert
> 

_______________________________________________
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: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 18 Sep 2001 00:21:07 +0200

Tom,

We have had this discussion quite a while ago.
The SMIv2 authors/editors agree that the constructs 
are valid. I believe we have discussed this on the 
[email-masked] mailing list too, but certainly we have
discussed it in the disman mailing list. RFC2925 has
similar constructs, and that is when the discussion
first came up.
For all I know, at least one of the authors of the 
Epilogue code is a participating/contributing member to
the disman wg, so he is aware of this. I will check with 
him.... or you can do so too.

Bert 

> From: Tom Irwin [mailto:[email-masked]]
> Sent: maandag 17 september 2001 23:21
> To: Fred Baker
> Cc: [email-masked]
> 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.
> 
> 
> Fred Baker wrote:
> > 
> > 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.
>