RE: RADEXT WG Last Call on draft-ietf-radext-dynauth-client-mib-01.txt

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

Now that you mention it, I think I remember this discussion. In any
case, assuming the warning can be ignored, I believe it's better to
define radiusDynamicAuthorization in one of the documents and IMPORT it
in the other. 

Regards,

Dan


> -----Original Message-----
> From: Nagi Reddy Jonnala (njonnala) [mailto:njonnala@cisco.com] 
> Sent: Thursday, July 28, 2005 3:00 PM
> To: Romascanu, Dan (Dan); Bernard Aboba; radiusext@ops.ietf.org
> Cc: Wijnen, Bert (Bert)
> Subject: RE: RADEXT WG Last Call on 
> draft-ietf-radext-dynauth-client-mib-01.txt
> 
> Dan,
> 
> Thanks for your review. Please see below a bit of history and 
> answers to your questions.
> 
> History:
> 
> Initially when we designed, we wanted to have conceptual 
> grouping i.e., radiusDynamicAuthorization stemmed from 
> radiusMIB (radiusMIB stems from from mib-2 and the DAC & DAS 
> MIBs under this root. 
> 
> After first MIB doctor's review:
> 
> As I understand, MIB doctor suggested to change the MIBs to 
> directly originate from mib-2(instead from radiusMIB). That's 
> how radiusDynamicAuthorization took origin from mib-2.
> 
> I'm not sure how the warning was not noticed. As I mentioned, 
> the reason to keep like this way is to have a conceptual 
> grouping. Though DAC & DAS MIBs could be directly orginated 
> from mib-2 if it is mandatory.
> 
> regards
> Nagi.
> 
> 
> 
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org]
> On Behalf Of Romascanu, Dan (Dan)
> Sent: Thursday, July 28, 2005 4:38 PM
> To: Bernard Aboba; radiusext@ops.ietf.org
> Cc: Wijnen, Bert (Bert)
> Subject: RE: RADEXT WG Last Call on
> draft-ietf-radext-dynauth-client-mib-01.txt
> 
> Both draft-ietf-radext-dynauth-client-mib-01.txt and 
> draft-ietf-radext-dynauth-server-mib-01.txt define 
> radiusDynamicAuthorization as 
> 
> radiusDynamicAuthorization    OBJECT IDENTIFIER ::= { mib-2 xxx } 
> 
> And then define the respective MODULE-IDENTITY under 
> radiusDynamicAuthorization. 
> 
> Defining the same node in two separate documents seems odd, 
> although it is IANA who is in charge with the xxx allocation. 
> Also, this results in smilint protesting with a level 4 warning:
> 
> Warning:     module-identity-registration (level 4)
> Message:     uncontrolled MODULE-IDENTITY registration
> Description: The identities of IETF MIB modules should be 
> registered below
>              mib-2, transmission, or snmpModules so that the 
> registration
>              space can be controlled by IANA.
> 
> I wonder what are the good reasons to break this 'should'
> recommendation. 
> 
> Regards,
> 
> Dan
> 
> 
> > -----Original Message-----
> > From: owner-radiusext@ops.ietf.org
> > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> > Sent: Thursday, July 07, 2005 5:02 PM
> > To: radiusext@ops.ietf.org
> > Subject: RADEXT WG Last Call on
> > draft-ietf-radext-dynauth-client-mib-01.txt
> > 
> > This is an announcement of RADEXT WG last call on the "Dynamic 
> > Authorization Client MIB", prior to sending this document 
> to the IESG 
> > for publication as an Informational RFC.
> >  The document will be available on the IETF archive at the following
> > location:
> > http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-
> > client-mib-01.txt
> > 
> > Until then, it is available for inspection at:
> > http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-dynauth
> > -client-mib-01.txt
> > 
> > RADEXT WG Last Call will last until July 28, 2005.  Please 
> send your 
> > comments to the RADEXT WG mailing list
> > (radiusext@ops.ietf.org) in the format described in the 
> RADEXT Issues 
> > List, located at:
> > 
> > http://www.drizzle.com/~aboba/RADEXT/
> > 
> > --
> > 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/>
> 

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