RE: SNMP vs. RADIUS transport mappings

["Matt Holdrege" <Matt.Holdrege@strixsystems.com>]

SNMP had the full support of the IAB and IESG who pushed many years for
the full development of the protocol. RADIUS has been denigrated by a
long list of IAB and IESG leadership as something that never should have
been allowed to happen and should not have a place in any future IETF
protocol development. I don't know if it would be possible to get the
level of support needed to do what you are suggesting, but it would have
been nice to have done that work back in the 90's.

But all that is IETF politics and future RADIUS development shouldn't
worry too much about past politics.

-Matt

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of Joseph Salowey (jsalowey)
Sent: Tuesday, April 15, 2008 7:46 PM
To: Bernard Aboba; Glen Zorn; Alan DeKok
Cc: radext mailing list
Subject: RE: SNMP vs. RADIUS transport mappings

SNMPv3 made the effort to define an architecture that created abstract
interfaces between modules such as security and transport as is defined
in the architecture documents you cite.  This makes it possible to
implement new transport and security mechanisms within the SNMPv3
architecture (although the architecture has to be extended somewhat to
accommodate a transport security mechanism).  RADIUS has no such formal
modular architecture.  I suppose that one could be retro-fitted, but it
hasn't been done yet.  

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Monday, April 14, 2008 10:26 PM
> To: 'Glen Zorn'; 'Alan DeKok'
> Cc: 'radext mailing list'
> Subject: SNMP vs. RADIUS transport mappings
> 
> >UDP transport is forever enshrined in RFC 2865, however; 
> maybe that's a 
> >bad thing, but it's true nonetheless.
> 
> How is this different from say, SNMP? 
> 
> The original transport mappings for SNMP (RFC 1089, 1906) 
> were all datagram transports.
> 
> The logic for SNMP over UDP was quite well enshrined.  For 
> example, see the following discussion, which has some 
> parallels with RFC 2865 Section 2.4:
> http://www.unix.org.ua/orelly/networking_2ndEd/snmp/ch02_01.htm
> 
> Yet, RFC 3430 defined SNMP over TCP:
> http://www.ietf.org/rfc/rfc3430.txt
> 
> Normative references included the following:
> 
> Transport Mappings for SNMP:
> http://www.ietf.org/rfc/rfc3417.txt
> SNMP applications:
> http://www.ietf.org/rfc/rfc3413.txt
> An Architecture for Describing SNMP Management Frameworks:
> http://www.ietf.org/rfc/rfc3411.txt
> 
> 
> 
> 
> 
>  
> 
> 
> 
> 
> --
> 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/>