Re: MIB Doctor Last Call on 2 RADEXT MIB documents

[Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>]

On Wed, Feb 08, 2006 at 03:22:54AM +0100, Wijnen, Bert (Bert) wrote:
> These 2 documents:
> 
>   draft-ietf-radext-dynauth-client-mib-03.txt
>   draft-ietf-radext-dynauth-server-mib-03.txt
> 
> are on my plate for publication as Informational documents.
> I do not plan to do IETF Last Call (since they are
> informational). I'd like to do a 2 week MIB Doctor Last Call
> instead, so that any of you who is interested can check if 
> they have any serious issues.

Not really a serious issue or concern and perhaps I should not send
this message in the first place. I encourage those who dislike
discussions about style issues to please presse delete now. Thanks.

For those curious folks still reading: The OID tree of the two MIBs
basically looks like this (details of the tables and conformance nodes
deleted):

--radiusDynAuthServerMIB(1.3.6.1.2.1.xxx)
  |
  +--radiusDynAuthServerMIBObjects(1)
  |  |
  |  +--radiusDynAuthServer(1)
  |     |
  |     +--radiusDynAuthServerDisconInvalidClientAddresses(1)
  |     +--radiusDynAuthServerCoAInvalidClientAddresses(2)
  |     +--adiusDynAuthServerIdentifier(3)
  |     |
  |     +--radiusDynAuthClientTable(4)
  |
  +--radiusDynAuthServerMIBConformance(2)

--radiusDynAuthClientMIB(1.3.6.1.2.1.yyy)
  |
  +--radiusDynAuthClientMIBObjects(1)
  |  |
  |  +--radiusDynAuthClient(1)
  |     |
  |     +--radiusDynAuthClientDisconInvalidServerAddresses(1)
  |     +--radiusDynAuthClientCoAInvalidServerAddresses(2)
  |     |
  |     +--radiusDynAuthServerTable(3)
  |
  +--radiusDynAuthClientMIBConformance(2)

I am wondering what the added value of having radiusDynAuthServer and
radiusDynAuthClient nodes is. I do understand if people like to group
related scalars together (so additions are numbered using consecutive
identifiers), but then the OID structure should more look like the
following:

--radiusDynAuthServerMIB(1.3.6.1.2.1.xxx)
  |
  +--radiusDynAuthServerMIBObjects(1)
  |  |
  |  +--radiusDynAuthServerScalars(1)
  |  |  |
  |  |  +--radiusDynAuthServerDisconInvalidClientAddresses(1)
  |  |  +--radiusDynAuthServerCoAInvalidClientAddresses(2)
  |  |  +--adiusDynAuthServerIdentifier(3)
  |  |
  |  +--radiusDynAuthClientTable(2)
  |
  +--radiusDynAuthServerMIBConformance(2)

--radiusDynAuthClientMIB(1.3.6.1.2.1.yyy)
  |
  +--radiusDynAuthClientMIBObjects(1)
  |  |
  |  +--radiusDynAuthClientScalars(1)
  |  |  |
  |  |  +--radiusDynAuthClientDisconInvalidServerAddresses(1)
  |  |  +--radiusDynAuthClientCoAInvalidServerAddresses(2)
  |  |
  |  +--radiusDynAuthServerTable(2)
  |
  +--radiusDynAuthClientMIBConformance(2)

Again, there is nothing technically wrong with the MIBs as they
are. My question is a purely stylistic one (even though I think that
grouping scalars has some readability benefits when you add scalars
over time).

It is not my intend to establish new CLRs (and those who think I do
should have pressed "delete" at the beginning of the message). I am
just curious to learn what others think about this style issue.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany