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

["Romascanu, Dan \(Dan\)" <dromasca@avaya.com>]

Indeed, my comment in the review back in December 2004 was that distinct
MIB modules defined in distinct documents should rather be assigned (via
IANA)  under mib-2. This is also what the MIB review guidelines section
4.5 say. 

Regards,

Dan



 
 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wijnen, Bert (Bert)
> Sent: Thursday, September 15, 2005 6:24 PM


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