Re: [MIB-DOCTORS] help with the ADSL-TDIM MIB

["Joan Cucchiara" <[e-mail]>]

Hi Folks,

I've looked at some of my old MIB reviews where the accessible-for-notify 
has been discussed.
Here are a few excerps:

1) VRRP-UNIFIED-MIB (now:  RFC6527)
" *) Concern on the use of accessible-for-notify:  it might be
a good idea to make these objects read-only, along with a
timestamp type of object.  Notifications are unreliable and
so, could be lost.  Also, some customers do not like to
enable a lot of notifications and prefer polling.
Would you consider making these objects read-only?"

OUTCOME:  The outcome looking at RFC6527 was to change one of the 
accessible-for-notify object to read-only
and have a Discontinuity object.
 In another case the accessible-for-notify became a readonly object
(which does duplicate information in an index).


2)  Another MIB, RFC5643  (OSPFv3-MIB)
There are accessible-for-notify objects and my recollection is that so much 
data would have been saved and timestamped
that it was far easier to do the accessible-for-notify objects. 
Notifications were sent to show specific packet info for errors.
Even though these errors were being counted, the MIB authors did not want to 
save all the information, so it was very
temporary and accessible-for-notify was a decent solution.   (Also, there 
was history here because this was in earlier versions
of OSPFv2-MIB.)


3)  TED-MIB (draft-ietf-ccamp-gmpls-ted-mib-10)
The accessible-for-notify was in earlier versions of this MIB, but was 
changed to include an object from the table,
rather than duplicate indices in accessible-for-notify objects.

--


Wrt to ADSL-TDIM-MIB

The claim that Management Stations have a difficult time parsing the OIDs to 
isolate indices doesn't seem completely plausible.
If an agent can code it, then shouldn't these be able to be decoded by a 
manager?   (maybe I'm just missing something.)

At any rate, getting to the original question:

I would prefer adding a read-only object which is duplicated information, 
rather than making an index read-only.  (This was done in the 
VRRP-UNIFIED-MIB, RFC6527)
(I agree with Bert,  and would have expected to see a read-only index 
flagged as an error.)

Also, I think Juergen raises some good points which my experience also 
suggestions, that accessible-for-notify objects can usually
be rewritten to something maybe more meaningful.   However, the use in the 
OSPFv3-MIB (RFC5643) of accessible-for-notify does seem to be an exception.

Thanks,
  -Joan









----- Original Message ----- 
From: "Juergen Schoenwaelder" <[e-mail]>
To: "Romascanu, Dan (Dan)" <[e-mail]>
Cc: "Michael MacFaden" <[e-mail]>; <[e-mail]>
Sent: Wednesday, March 07, 2012 9:36 AM
Subject: Re: [MIB-DOCTORS] help with the ADSL-TDIM MIB


> Well,
>
> it seems RFC 2578 is relatively clear that auxiliary objects (the
> INDEX objects that are columns of the same conceptual table) are
> not-accessible except in the situation where there are no other
> columns, in which case one of the columns becomes read-only. (The
> other exception is conversion from SMIv1 MIB modules to SMIv2, which
> does not seem to apply here.)
>
> Searching a bit, I found these:
>
> - There was a case where the prtAlertIndex of the Printer-MIB was
>  discussed, which was originally defined as not-accessible but used
>  also in a notification. This was not detected until the module was
>  up for revision and then the solution was to make prtAlertIndex
>  read-only with a MIN-ACCESS of accessible-for-notify.  We are not
>  facing the same situation here since our tools now spot such errors
>  before modules get published.
>
> - The T11-FC-FABRIC-ADDR-MGR-MIB seems to have a construction that is
>  interesting in the sense that they have an accessible-for-notify
>  object t11FamNotifyFabricIndex that they carry in notifications in
>  addition to t11FamLocalSwitchWwn, an object of a table indexed by
>  {fcmInstanceIndex,fcmSwitchIndex,t11FamFabricIndex}. Its hard to
>  understand the logic behind this (I am not a fibre channel guy)
>  because the t11FamNotifyFabricIndex only provides part of the index
>  and hence seems only marginally helpful.
>
> - The TRIP-MIB also has something interesting. They have a
>  notification carrying
>
>    tripOpenMessageError NOTIFICATION-TYPE
>        OBJECTS { tripNotifApplIndex,
>                  tripNotifPeerAddrInetType,
>                  tripNotifPeerAddr,
>                  tripNotifPeerErrCode,
>                  tripNotifPeerErrSubcode,
>                  tripPeerState
>                }
>  and tripPeerState is a column of a table indexed by
>
>        INDEX { applIndex,
>                tripPeerRemoteAddrInetType,
>                tripPeerRemoteAddr,
>                tripPeerRemotePort }
>
>  and again this leaves me puzzled as it again looks somewhat
>  incomplete and arbitrary (I am also not a TRIP guy).
>
> So we end up with "does it make sense to add additional
> accessible-for-notify objects to notifications that carry values of
> auxiliary objects"?
>
> I continue to believe it is a bad idea to do this except we write a
> document updating RFC 2578 that "says experience with RFC 2578's rule
> to force auxiliary objects to be not-accessible tells us that
> implementations still today find it too hard to 'unpack' information
> encoded in the instance identifiers and hence this rule does not apply
> anymore".
>
> The idea to add additional object definitions to work around this rule
> seems just a bad hack to me. In principle, one can also add additional
> read-only columns to tables that duplicate auxiliary objects and this
> would be syntactically be fine wrt. RFC 2578 but still be a violation
> of the intention of RFC 2578.
>
> /js
>
> PS: Working on some constrained platforms lately, I guess I am a bit
>    more sensitive to mandatory to implement redundant information
>    (and this is what it boils down to).
>
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
> _______________________________________________
> MIB-DOCTORS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mib-doctors