RE: REMINDER: Call for review of RFC 2618bis-2621bis

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

Bert Wijnen writes...

> I also do not understand this
>    radiusMIB OBJECT-IDENTITY
>           STATUS  current
>           DESCRIPTION
>                 "The OID assigned to RADIUS MIB work by the IANA."
>            ::= { mib-2 67 }
> 
>    radiusAuthClientExtMIB OBJECT-IDENTITY
>           STATUS  current
>           DESCRIPTION
>                 "The OID assigned to RADIUS Extensions MIB work by
>                  the IANA."
>            ::= { mib-2 TBA }
> 
>    -- RFC Editor: replace TBA with IANA assigned OID value, and
>    -- remove this note.
> 
> Why do we need/want 2 OID branches underneath mib-2?
> Why can the extensions not be made just within the
> radiusAuthClientMIB branch itself?

That question was raised and answered at IETF-63.  The answer was that
all MIB extension work was to be rooted directly under MIB-II, as that
is the only registry that IANA controls.  I believe it was Juergen
Schoenwaelder who provided that guidance.  I believe that Dan Romascanu
has given similar advice previously.

Is that not the correct answer?  I tend to think that the approach you
suggest makes more sense, but I was previously corrected for doing it
that way.


--
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/>