Subject: RE: Diameter Saga - carifications was: [AAA-WG]: Diameter Base update

From: <[email-masked]>
Date: Sat, 27 Jul 2002 21:40:51 +0300

> I here you, and your request is a reasonable one.  That said, container
> protocols are in a very strong sense the worst kind -- to pick a very
> bad, egregiously unfair example, it's almost like saying that we don't
> have to worry about email transport, since we have this nice general
> transport mechanism called TCP.
 
Understood.  glad you brought up TCP.  I suspect there is a bigger issue
lurking here.  One could assume Diameter to be the transport protocol
for AAA, and as such, VSCs could potentially cause problems - similar
as if TCP had vendor message options. I imagine one of the successes
of IP could be attributed to the fact that the basic TCP/IP stack has been
fairly stable and has good interoperability.

> An answer that "we'll charter more working groups to design Diameter
> applications" is a good one.  But in that case, the extra command codes
> would be standardized in those WGs, not by vendors.

Actually, the more I think of it, the more I like having a small experimental
range for command codes, beyond the initial use.  I do think that allowing
for experimentation with protocols is useful & giving a sandbox for 
implementors to play in, is a useful thing.  Of couse, this can be abused,
but implememntations abuse TCP & IP anyway.
 
John

---

From: Johan Johansson <[email-masked]>
Date: Mon, 29 Jul 2002 13:16:54 +0000

>fairly stable and has good interoperability.

I guess it was inevitable that we would attempt to discuss this by 
analogy with TCP/IP. If you are trying for some reason to find 
similarities between Diameter base protcol and TCP/IP protocols it seems 
more reasonable to compare it to IP since it defines routing and how to 
mark contained data so that it can be interpreted, i.e. is a "container 
protocol". I'm not sure TCP/IP is a relevant comparison though, no 
matter how successful a protocol suite that is. And note that it *is* a 
suite defined within the framework of the container protocol IP.

I don't think I understand the email transport example. Email *is* 
almost exclusively transported using TCP, but of course with the help of 
a specific protocol that is embedded within TCP. I am not aware of SMTP 
being accused of creating interoperability problems and yet an SMTP 
client most certainly does not interoperate very well with an FTP or 
HTTP server.

It seems to me that one cause of the concern is a lack of understanding 
that you can't just toss in a few new VSCs at random times. They live in 
vendor specific applications and as such are orthogonal to the 
functionality of already defined commands. Being afraid of VSCs but 
accepting vendor specific avps seems strange to me.

Another cause seems to be that somehow the Diameter base protocol is 
expected to be "the protocol" but it performs no real work. That is the 
task of specific applications, such as NASREQ, MIP and CMS. These have 
not yet been submitted as far as I know.

>but implememntations abuse TCP & IP anyway.

And what better way to encourage implementors to experiment than by 
giving them their own namespace to play around in? In what way would it 
be better to merge all vendors' namespaces? Where is the improvement?

I have of course no problem with IETF chartering more working groups to 
design Diameter applications when they are needed, but I fail to see why 
they would want to standardize highly implementation specific things 
such as how to exchange node state within a cluster. Why forbid the 
vendors from solving this within the protocol?

j