[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: MIB Doctor Last Call on 2 RADEXT MIB documents
Juergen, thanks ofr checking and commenting.
I certainly like your style better than what is in the
current document. But I think that at this time (after
WG Last Call, i.e. docs being on my AD plate) we
can only mention it to the WG, but add a note that
we are indeed very late with this.
We might actually just not say anything, because if
we look at all the MIB modules defined sofar, these
type of stylistic differences can be seen all over the
place.
And as you yourself once stated (I think): an OID is an OID.
Now, instead of sending this as part of my AD review comments,
maybe you can just post it to the radext WG as a gentle
suggestion, and that way it may be received much better.
Just thinking aloud here.
Bert
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]
> Sent: Wednesday, February 08, 2006 10:30
> To: Wijnen, Bert (Bert)
> Cc: Mreview (E-mail)
> Subject: Re: MIB Doctor Last Call on 2 RADEXT MIB documents
>
>
> 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
>