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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 6 Mar 2012 15:36:49 +0100

Hi MIB Doctors,

With Bert's help we checked the ADSL MIB modules in the 4 documents now
in IETF LC. 

We encountered a potential problem with
http://www.ietf.org/id/draft-ietf-adslmib-gbond-tdim-mib-07.txt

Quoting Bert: 

With SMICNG STRICT checking I get these additional warning for
gbond-tdim:

W: f(gbond-tdim.mi2), (169,8) Variable "gBondTdimOperSvcPosition" in
notification "gBondTdi mSvcUp" is an index for a table
W: f(gbond-tdim.mi2), (196,8) Variable "gBondTdimOperSvcPosition" in
notification "gBondTdi mSvcDown" is an index for a table

And then looking into the gbond-atm MIB file, I am surprised to see:

   gBondTdimOperSvcEntry OBJECT-TYPE
     SYNTAX      GBondTdimOperSvcEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
       "An entry in the G.Bond/TDIM Port Operational Service table,
       containing the index of an active Service entry in the
       gBondTdimSvcTable. The entry is indexed by ifIndex,
       indicating corresponding G.Bond/TDIM port, and by
       gBondTdimOperSvcPosition (1..60), indicating the
       corresponding service position in the G.Bond/TDIM frame."
     INDEX  { ifIndex, gBondTdimOperSvcPosition }
     ::= { gBondTdimOperSvcTable 1 }

   GBondTdimOperSvcEntry ::=
     SEQUENCE {
       gBondTdimOperSvcPosition          GBondTdimSvcOrderIndex,
       gBondTdimOperSvcIdx               GBondTdimSvcIndex,
       gBondTdimOperSvcState             INTEGER
     }

   gBondTdimOperSvcPosition OBJECT-TYPE
     SYNTAX      GBondTdimSvcOrderIndex
     MAX-ACCESS  read-only
     STATUS      current

This means that the object is indeed an index object and so does not
need to be included in this object clause:

   gBondTdimSvcUp NOTIFICATION-TYPE

     OBJECTS {
       -- ifIndex is not needed here since we are under specific GBS
       gBondTdimOperSvcPosition,
       gBondTdimSvcIfIdx,
       gBondTdimOperSvcState
     }

because it is already part of the OID for gbindTdimSvcIfIdx

But I am also surprised that the object
   gBondTdimOperSvcPosition OBJECT-TYPE
     SYNTAX      GBondTdimSvcOrderIndex
     MAX-ACCESS  read-only
     STATUS      current

is read-only! Index objects should (normally) be not-accessible.
I suspect they did that because otherwise the inclusion in the
NOTIFICATION-TYPE OBJECTS clause causes and error and not just a
warning.

I had actually expected a warning/error from SMICng for the fact that
the index object is read-only !!??

Now my reading is that they made the index object readable in order to
ease the work of the management applications - some have a hard time
separating an index with meaningful information. As no critical error is
shouted I am inclined to let it pass. 

Any opinions? 

Thanks and Regards,

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Mar 2012 16:22:21 +0100

On Tue, Mar 06, 2012 at 03:36:49PM +0100, Romascanu, Dan (Dan) wrote:

[...]
 
> shouted I am inclined to let it pass. 

We have insisted for more than a decade on the rule that index objects
are not-accessible and I think changing the policy should not be done
that easily or arbitrarily. If we want to change this policy, we
should discuss it and then document it to ensure fair treatment of all
MIB modules. (And a quick look suggests that the tables in the
ADSL2-MIB for example have not-accessible index objects - so allowing
read-only in the ADSL-TDIM MIB hardly helps the ADSL people in general.)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Michael MacFaden <[email-masked]>
Date: Tue, 6 Mar 2012 23:43:19 -0800

I agree with Juergen. They could create another object in the notification
with accessible for notify.

Mike
On Mar 6, 2012 7:22 AM, "Juergen Schoenwaelder" <
[email-masked]> wrote:

> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 7 Mar 2012 12:10:05 +0100

I accept the suggestions from Juergen and Mike, thanks!

I will ask the editor to re-spin the TDM-MIB, making the index object
not-accessible and introducing a corresponding object
accessible-for-notify for notifications. 

Regards,

Dan

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael MacFaden
Sent: Wednesday, March 07, 2012 9:43 AM
To: [email-masked]; Romascanu, Dan (Dan); Juergen Schoenwaelder
Subject: Re: [MIB-DOCTORS] help with the ADSL-TDIM MIB

I agree with Juergen. They could create another object in the
notification with accessible for notify. 

Mike 

On Mar 6, 2012 7:22 AM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

[...]

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 <tel:%2B49%20421%20200%203587>          Campus
Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103 <tel:%2B49%20421%20200%203103>
<http://www.jacobs-university.de/>
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Mar 2012 13:13:05 +0100

> accessible-for-notify for notifications. 

The accessible-for-notify object is not strictly needed with the same
logic that applies to index objects of ordinary tables. I think I
recall a case where once someone wanted to make a table index
accessible-for-notify for such a reason - I have to search what the
outcome of that discussion was. In general, we do not have special
accessible-for-notify objects for index objects just to carry them in
notifications. (After all, this is all redundant information.)

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 7 Mar 2012 13:56:19 +0100

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Wednesday, March 07, 2012 2:13 PM
> To: Romascanu, Dan (Dan)
> Cc: Michael MacFaden; [email-masked]

Yes, please - if you can find that discussion it would be useful. 

Thanks, 

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Mar 2012 15:36:28 +0100

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

---

From: "Joan Cucchiara" <[email-masked]>
Date: Thu, 8 Mar 2012 11:27:29 -0500

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Mar 2012 17:56:27 +0100

On Thu, Mar 08, 2012 at 11:27:29AM -0500, Joan Cucchiara wrote:
 
> 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.)

Which object in RFC 6527 shall I look at in order understand what
you have in mind?

/js

---

From: "Joan Cucchiara" <[email-masked]>
Date: Thu, 8 Mar 2012 12:43:10 -0500

Juergen,

I am incorrect.  The DESCRIPTION of the following object:

 vrrpv3OperationsVirtualMacAddr OBJECT-TYPE
           SYNTAX       MacAddress
           MAX-ACCESS   read-only
           STATUS       current
           DESCRIPTION
              "The virtual MAC address of the virtual router.
              Although this object can be derived from the
              'vrrpv3OperationsVrId' object, it is defined so that it
              is easily obtainable by a management application and
              can be included in VRRP-related SNMP notifications."
           ::= { vrrpv3OperationsEntry 5 }

let me to believe this object was in a notification, but I can't find it in 
a notification, thus, the DESCRIPTION
is misleading/wrong.

Thanks,
  -Joan

----- Original Message ----- 
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>
Cc: "Romascanu, Dan (Dan)" <[email-masked]>; "Michael MacFaden" 
<[email-masked]>; <[email-masked]>
Sent: Thursday, March 08, 2012 11:56 AM
Subject: Re: [MIB-DOCTORS] help with the ADSL-TDIM MIB