[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> 
> Dave Nelson writes...
> 
> Responding to my own reply.
> 
> > Bert Wijnen writes...
> >
> > > 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.
> 
> Would the fact that we now understand that these drafts will Obsolete
> their counterpart RFCs, and contain all the MIB objects from those RFCs,
> change the advice around issuing a new MIB branch directly under MIB-II
> for the extensions objects?  Would it be acceptable to use the original
> OIDs issues for the RADIUS MIBs as the [sole] root for their
> replacements?
> 

What we object to (and that is what Juergen and Dan probably
said or meant to say) is that we do not want something where
you define say

   radiusMIB  { mib-2 xx }

   radiusServerMIB { radiusMIB 1 }
   radiusClientMib { radiusMIB 2 }
   radiusSomeOtherMIB { radiusMIB 3 }
   etc

All those MIB modules would be possibly be in different MIB documents.
If you extend one MIB module then if you do it inside the MIB
module (say radiusSomeMIB) and the last OID you used was for let
us say

   lastObjectInVersion1  

       ::= { radiusSomeMIB 18 }

The newly added objects within the same MIB module would be
numbered

   firstNewObjectInVersion2  

       ::= { radiusSomeMIB 19 }

   secondNewObjectInVersion2  

       ::= { radiusSomeMIB 20 }

   etc.

It is if you were to do extension in anotehr MIB module that
you would do a new assignment under mib-2. You could
AUGMENT or EXTEND tables in the base MIB module still.

Hope this helps.

Bert

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

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