Subject: RE: [[email-masked]: Re: [SIP] draft-calhoun-sip-aaa-req]

From: "Gross, Gerhard" <[email-masked]>
Date: Thu, 4 Jan 2001 12:43:01 -0800

Furthermore, concerning

> As for the question why XML/HTTP:

(paraphrasing one of my colleagues):

A major drawback of AVP is that it uses
a binary (non-textual) representation
requiring programmers and the appropriate
programming tools to use and understand it.

XML, on the other hand, is text based and
has DTDs and schemas that allow for its
text constructs to be formally described
(via a data definition language). This
makes it much easier to get a computer to
interpret and parse the data. In the case
of AVPs, there is no formal language for
describing the data, its understood
combinations or groupings, its formats, etc.
Thus, it is viewed by many as an
inferior/ancient way of describing data.
Like using two rocks to try to start a fire.
This makes interoperability much more
difficult and prone to errors.

Gery

        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        X                                         X
        X    Gerhard W. Gross, Ph.D.              X
        X    Intel                                X
        X    2111 NE 25th Ave                     X
        X    Hillsboro, OR 97124-5961, USA        X
        X    Policy Architecture Group            X
        X      - Internet and Communication Lab   X
        X    phone:    (503) 264-6389             X
        X    fax:      (503) 264-3483             X
        X    email:    [email-masked]    X
        X                                         X
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

> -----Original Message-----
> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Thursday, January 04, 2001 10:04 AM
> To: Pat Calhoun; Henning G. Schulzrinne
> Cc: Michael Thomas; SIP List; [email-masked];
> [email-masked]
> Subject: RE: [[email-masked]: Re: [SIP] 
> draft-calhoun-sip-aaa-req]
> 
> 
> >We are only trying to provide the infrastructure
> >required to support
> >them.
> 
> There have been a number of I-Ds on this list from people working for
> various carriers and I suggest vendors to look at them, such 
> as from AT&T,
> L3, Telia and WorldCom in alphabetical order, and others.
> 
> One of the papers mentioned here is
> http://ietf.org/internet-drafts/draft-gross-cops-sip-00.txt
> 
> and it is clearly focused (we hope) on the POLICY SERVER, NOT the AAA
> SERVER, in the DIAMETER sense, whose functions are actually 
> absorbed in the
> policy server and its constituents, such as directories (personal and
> corporate accounts), outsourced policy servers, clearinghouse 
> and other. So
> please do not assume that all ISP folks see the AAA server as 
> the center of
> the universe...
> 
> As for the question why XML/HTTP:
> 
> ISP services development and operations costs are minimized 
> by using the
> smallest number of protocols and data formats.
> HTTP clearly makes it to the top of the short list for transport.
> XML has countless tools for dummies (like me) and can be 
> displayed with the
> browser and is thus ideal for testing and prototyping in this 
> fast changing
> environment. It is has also a large field of applicability. 
> DIAMETER with
> its AVP data formats does not have these advantages - may 
> have its place as
> mentioned for network access, but is not in the center of the 
> AAA universe
> IMHO. Pushing DIAMETER to be the focus of AAA is not convincing.
> 
> Henry
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Pat Calhoun
> > Sent: Tuesday, January 02, 2001 5:00 PM
> > To: Henning G. Schulzrinne
> > Cc: Pat Calhoun; Michael Thomas; SIP List
> > Subject: Re: [[email-masked]: Re: [SIP] 
> draft-calhoun-sip-aaa-req]
> >
> >
> >
> > >
> > > I'm still trying to understand why the act of sending SIP 
> requests is
> > > subject to authorization. Will each new UDP port number 
> and service get
> > > its own AAA infrastructure? (I can see authorizing resource
> > > reservations, but that's completely orthogonal to SIP, as has been
> > > discussed here a few times...)
> >
> > Good question.
> >
> > The carriers want to control who has access to certain services
> > (say *traffic,
> > *911, etc.) Also in other cases, they want to get explicit
> > authorization for
> > certain services, since they will incur a surcharge.
> >
> > So when a request is received, say an invite to *traffic, a
> > request is sent
> > off to the AAA server to ensure that the user is authenticated,
> > and has access
> > to the said service. As far as *traffic is concerned, having traffic
> > information in the home network doesn't really do much good 
> when one is
> > roaming :)
> >
> > However, the actual services are still being worked out, 
> and are carrier
> > specific. We are only trying to provide the infrastructure
> > required to support
> > them.
> >
> > PatC
> >
> >
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 4 Jan 2001 13:17:02 -0800 (PST)

> difficult and prone to errors.
As much as I appreciate these statements that have no
foundation, and are purely religious in nature, I would
like to state that the RADIUS protocol does in fact
have an excellent history of interoperability, with
countless implementations deployed from many vendors. It's
countless problems have nothing to do with the fact that it is,
or not, binary.

btw, Mobile IP, L2TP, PPP, and many are other non text
based protocols, have have a high degree of interoperability.
There are plenty of interoperability reports available
for people to read, should they feel so inclined.

Now that we have diverged sufficiently from the original
intent of the I-D, perhaps we can better concentrate on
what the actual requirements are, and leave protocol bashing
and comparisons until the time when we have requirements to
compare them against?

PatC