RE: RFC3576 MIBs

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

I note that these new MIB modules are not anchored under mib-2
but under subtrees of radiusMIB.

That means these assignments are not controlled/made by IANA
as is the normal process for new MIB modules.

In other WGs this approach has caused overlapping assigments
in the past, and so I would like to see one of 2 things
happen:

- assigne the MIB modules directly under mib-2
  This is the prefered action
- create a registry that IANA maintains and create the rules
  for them to make new assignments.
  In these documents you then have to request IANA to assign
  values under that registry.

See draft-ietf-ops-mib-review-guidelines-03.txt sections 3.7.2 and
3rd bullet sect 4.5

If you want to go for the first approach above, then RFC3737 may serve
as an example.

Bert

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org]On Behalf Of
> stefaan.de_cnodder@alcatel.be
> Sent: Tuesday, November 30, 2004 10:16
> To: radiusext@ops.ietf.org
> Subject: RFC3576 MIBs
> 
> 
> 
> Hi,
> 
> You find updated versions of the RFC3576 MIB drafts at
> 
> http://www.ietf.org/internet-drafts/draft-decnodder-radext-dyn
> auth-client-mib-02.txt
> 
> and
> 
> http://www.ietf.org/internet-drafts/draft-decnodder-radext-dyn
> auth-server-mib-02.txt
> 
> All comments would be highly appreciated.
> 
> Thanks,
> 
> Stefaan
> 
> --
> 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/>