Subject: RE: [Iptel] read-only compliance for TRIP MIB

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 15 Jan 2004 06:50:47 +0100

So, you did not specify that MIN-ACCESS of read-only is OK in 
your MODULE COMPLIANCE. That is fine by me, but if you do
so, then of course read-only implementation cannot claim
compliance. I think I said this before.

So, my understanding of what you want to do is to add an extra 
MODULE-COMPLIANCE, and that seems a very easy and simple way 
to address this.

I sort of expect then two compliance statements:

    tripMibFullCompliance MODULE-COMPLIANCE
        STATUS       current
        DESCRIPTION "The compliance statement for TRIP entities
                     that implement this MIB module in read-write
                     mode, such that it can be used for both 
                     monitoring and configuring the TRIP entity.
                    "
    ... here the stuff that you currently have in 
      tripCompliance MODULE-COMPLIANCE

    tripMibReadOnlyCompliance MODULE-COMPLIANCE
        STATUS       current
        DESCRIPTION "The compliance statement for TRIP entities
                     that implement this MIB module in read only mode.
                     Such TRIP entities can then only be monitored, but 
                     not be configured via this MIB module.
                    "
     ... here the stuff that you currently have in 
      tripCompliance MODULE-COMPLIANCE
     plus of course the OBJECT CLAUSES with MIN-ACCESS read-only 
     plus for some of them also the SYNTAX clauses to indicate
     that not all values need to be supported.

Hope this helps
Bert

_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 15 Jan 2004 17:15:37 +0200

This needs to be explained. Also, is there an aging / flushing mechanism? Routes are added by the routing application, but are they also deleted?

Thanks and Regards,

Dan

> -----Original Message-----
> From: David Zinman [mailto:[email-masked]]
> Sent: 15 January, 2004 5:15 AM
> To: Romascanu, Dan (Dan); [email-masked]
> Subject: Re: [Iptel] read-only compliance for TRIP MIB
> 
> 
> Dan,
> 
> I'm not sure I understand what you mean by "permanent". In a read-only
> implementation of the MIB, even though the (SNMP) manager 
> cannot add rows to
> a table, this does not preclude the TRIP application or other 
> source from
> adding rows to the table.
> 
> For example, in a read-only MIB representing a routing table, 
> even though
> the manager may not add a route (a row), a route might 
> possibly be added or
> removed dynamically by the routing application. In such a 
> case there may be
> no permanent rows at all.
> 
> DZ
> 
> ----- Original Message ----- 
> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "David Zinman" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, January 14, 2004 1:01 PM
> Subject: RE: [Iptel] read-only compliance for TRIP MIB
> 
> 
> David,
> 
> The TRIP MIB has RowStatus objects.  If you intent to provide 
> a read-only
> compliance version, does this mean that the tables with row creation
> capabilities will have a fixed number of rows, without the 
> manager being
> able to create or delete rows in this tables? Please have a 
> look and confirm
> that this is your intention, and take care to clarify in the 
> document what
> rows are supposed to be permanent in this situation for each table.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of David Zinman
> > Sent: 14 January, 2004 4:01 PM
> > To: [email-masked]
> > Subject: [Iptel] read-only compliance for TRIP MIB
> >
> >
> > There has been a request to include a "read-only" compliance
> > section in the TRIP MIB. If most implementations plan on
> > doing read-write support then it might not useful.
> > However, if there is enough support for read-only compliance,
> > another draft will be issued to support it.
> >
> > Comments, preferences??
> >
> > The decision will be made by Tuesday Jan 20.
> >
> > DZ
> >
> >
> >