Subject: RE: Choice of Data Model SMI vs XML vs. UML

From: "Weiss, Walter" <[email-masked]>
Date: Fri, 12 Jan 2001 17:25:49 -0500

I am somewhat baffled by this whole discussion. There is a clear trend to
move service intelligence to the edges. The configuration is not limited to
user identity, but nearly every aspect network usage from Tunnels to QoS to
Security to service access and forwarding rules. Many or all of these will
be keyed off of a user profile.

With this in mind, what kind of framework do we want that will support all
these capabilities. I would submit that a vertical model that assumes that a
network edge device will be configured by a large cross-section of protocols
(User stuff with Diameter, QoS with COPS, Security with SNMP, and service
access with SIP) is doomed to failure because of the implicit
inter-relationships between these technologies and the complexity of
configuration and management.

If the argument is that Diameter is only going to support a very restrictive
set of functions, specified with a relatively small set of attributes, I
have to agree with sentiment that a data modeling exercise is not worth the
effort for this WG. I would also predict that the protocol will be obsolete
before it is deployed (per the previous paragraph).

If, in contrast, there is an implicit goal in AAA to (eventually) support an
extensible set of capabilities, including (but not limited to) those listed
above, we face an ever more complex set of relationships between existing
and newly defined attributes that MUST be facilitated by structured data
(such as objects), reuse (as with inheritance and encapsulation) and well
defined relationships between data structures (associations or pointers).

If the WG conclude that the previous paragraph is the preferred approach,
there have been numerous comments outlining XML's inability to support reuse
and relationships as well as other limitations. This leaves us with a two
alternatives, SPPI and SMIng. I actually don't have a preference between the
two, but I would say if that if this WG is willing to be gated by the
standardizing of SMIng than that would be the better choice. If not, SPPI is
the less optimal but more immediate alternative that SMIng is supposed to be
backward compatible with.

regards,

-Walter
 
> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Friday, January 05, 2001 10:04 AM
> To: David Spence
> Cc: AAA Working Group
> Subject: Re: Choice of Data Model SMI vs XML vs. UML
> 
> 
> > 1. SMI Derivative vs. XML
> > 
> >    An advantage of using some derivative of SMI over XML is 
> that the 
> >    "formal specification" can actually be implemented in the edge 
> >    device.  This improves interoperability and allows interworking 
> >    between tools that use different protocols.
> > 
> > 2. Which derivative of SMI to use
> >    
> >    I don't have strong feelings as to which SMI derivative 
> is best.  We 
> >    chose SPPI for draft-spence-aaa-nas-data-model-00.txt 
> because it was 
> >    designed for policy provisioning, is compatible with 
> COPS (more on 
> >    this at item 3, below),  and is somewhat more mature 
> than SMIng (has 
> >    passed WG last call and is ready for IETF last call).
> >    
> >    The AAA WG may prefer to be more forward looking and use 
> SMIng or to 
> >    opt for greater maturity and use SMI v2.
> > 
> 
> Whatever the WG decides, it MUST be something mature, and 
> currently work in
> progress. 
> 
> > 3. Interworking COPS and DIAMETER
> >    
> >    If the AAA WG chooses XML or chooses an SMI derivative 
> for formal 
> >    notation only without providing a protocol mapping, then the 
> >    following problem arises.
> >    
> >    Suppose an edge device wishes to provide both network access and 
> >    premium QoS.  It would be nice to be able to obtain a single 
> >    admission decision covering both the network access and 
> the premium 
> >    QoS with a single request.  It is troublesome to the ISP 
> to allocate 
> >    QoS resources and then deny access or to create an 
> access session and 
> >    then have to terminate it because the QoS request 
> failed.  If the 
> >    edge device has to use DIAMETER to obtain the network access 
> >    admission decision and COPS to obtain the QoS admission 
> decision, it 
> >    will be very difficult to coordinate the two decisions.  If this 
> >    happens, someone might be tempted to doubt the IETF's wisdom in 
> >    standardizing two protocols where one might have sufficed.
> >    
> >    Of course, if the two protocols use the same data model, 
> then the 
> >    problem goes away.  Either protocol could be used for 
> either type of 
> >    request, so the edge device could request the two 
> related services in 
> >    a single message using either protocol.
> >    
> >    But if the two protocols do not use the same data model, then it 
> >    might be a good idea to create an escape mechanism.  Could we at 
> >    least define a DIAMETER AVP type of COPS message or COPS 
> object which 
> >    means, "shell out to the part of the AAA server that understands 
> >    COPS, process this thing and then return"?  That way, at 
> least, the 
> >    two requests could be piggybacked onto the same message 
> so that a 
> >    sophisticated enough AAA server could process them together.
> 
> Just to be clear, I am not sure how allowing the dictionary 
> and other config
> files), and the documentation to specify message formats in 
> XML or SMI to
> really help interworking of protocols on the wire :(
> 
> The scenario you described above *will* happen, and in the 
> cases that I've
> seen, the local PDP will contact the local DIAMETER server to 
> retrieve user
> profile information, since the information is in the user's 
> home network and
> COPS doesn't do inter-domain. > 
> > 4. What combinations of attributes make sense?
> >    
> >    A problem which RADIUS leaves unaddressed and which so 
> far has not 
> >    been addressed by DIAMETER is the question of which 
> attributes can 
> >    and can not be meaningfully combined in a message.  Or, 
> to put it 
> >    another way, which attributes pertain to which services. 
>  Here's an 
> >    example.
> >    
> >    The description of the Termination-Action attribute in 
> RFC 2865 says 
> >    simply, 
> >    
> >       "This Attribute indicates what action the NAS should 
> take when the 
> >       specified service is completed.  It is only used in 
> Access-Accept 
> >       packets."
> >       
> >    The RFC does not specify which services the attribute 
> applies to.  I 
> >    assume it applies to the Login service.  Could it also 
> apply to the 
> >    Framed service?  If I combine it with attributes such as 
> >    Framed-Protocol, Framed-IP-Address, and 
> Framed-IP-Netmask, what am I 
> >    expecting the NAS to do?
> >    
> >    A data model provides an answer to this sort of question 
> by grouping 
> >    elementary attributes by service.  If an attribute applies to a 
> >    service it is included with the service, either directly or by 
> >    association.  If an attribute does not apply, then it is 
> not included 
> >    in that part of the model.  Ambiguities are resolved, and 
> >    interoperability is enhanced.
> 
> I agree that the specifications must be clear. If in theNAS 
> dial-up world
> certain ambiguities still exist, then let's fix them in the spec. One
> possibility is to make use of different command sets for PPP 
> and terminal
> server. In fact, this would REALLY clean up the extension IMHO.
> 
> PatC
> 
>