Discussion of RADEXT Issue 148 (MIB review)

["Nelson, David" <dnelson@enterasys.com>]

Most of the comments and suggestions in RAREXT Issue 148 ( http://www.drizzle.com/~aboba/RADEXT/#Issue%20148 ) are editorial and/or straightforward, and I propose to accept those for inclusion in the next version of the drafts.  I would like to generate some discussion on the list of a few of the comment items.

The consensus of the WG (and of the MIB Doctors) was that the new objects should be rooted under the existing IANA OID assignments, using the next available OID.  The comments in Issue 148 suggest, however, that the top RADIUS MIB OID assignment (radiusMIB) be included in only one of the four documents and imported into the other three.  This changes the document organization, but would not change the resulting OID tree.  I have no strong opinion on this option, one way or the other.  Comments are solicited.

The text in Section 6, Deprecated Objects, intends to indicate that managed entities should only instantiate rows in the deprecated tables when the address objects in those rows can accurately be represented as IPv4 format addresses.  If the managed entity contains a mixture of IPv4 addresses and IPv6 addresses, then the new tables may contain row entries for both sets of addresses, while the deprecated tables may contain only row entries for the IPv4 addresses.  The question of whether there is a required relationship in the indexing of rows within the deprecated and new tables was not addressed, but it may be reasonable to do so.  I would solicit suggestions on whether this is a good idea, and if it is, then some suggested text regarding the synchronization of row indexes.

It would indeed be helpful to add UNITS clauses to the Counter32 objects.  I can take a stab at doing this, but review will be required to ensure that objects are not being effectively redefined by these additions.

It would also be useful to add REFERENCE clauses to objects that are specifically tied to sections of the base RFCs.  I can also take a stab at that.

While having a formal definition of "malformed" packets might be useful, since one has not heretofore existed I am concerned that creating such a definition at this point in time might in effect change the definition of existing objects.  If there is WG consensus on a definition of "malformed", and agreement that this consensus definition matches with existing implementations, then it may be desirable to add a definition of "malformed".  Comments are solicited.

Regards,
 
Dave Nelson


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>