Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header

From: <[email-masked]>
Date: Fri, 5 Jul 2002 18:19:46 +0300

1) With or without Vendor-Id moving the Application-Id in the header helps the routing.

2) It seems to me that IESG position in the VSC discussion is consistent with its history. An analogy with TCP and UDP ports could help: one can play/experiment with any of the non-reserved ports and this doesn't create much trouble, but if a vendor wants to reserve a port for its wonderful application, then it must register it.

Imposing the Vendor-Id would make it difficult (maybe even from legal point of view) for a lot of organizations that are not registered with IANA to play/experiment with Diameter. I read the interoperability problem raised by IESG more like an equal chances problem.

3) Removing the Vendor-Id from the header and letting it in the AVP header is not a consistent solution. But if you remove it from the AVP header you must either forbid non-standard AVPs in the standard commands (thus dropping one of the ways of extending the base protocol, but avoiding the complications) or replace it with something else.

Adrian

-----Original Message-----
From: ext Daniel Warren [mailto:[email-masked]]
Sent: 05 July, 2002 15:57
To: Loughney John (NRC/Helsinki); [email-masked]; Constantin Adrian (NET/Helsinki)
Cc: [email-masked]
Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header

> Hi Dan, 
> 
> 
> > Not trying to be argumentative but can someone explain how this is better than;- 
> > 1) Vendor ID is needed in the Diameter header for efficient processing (servers 
>      that don't recognise the Vendor-Id dismiss the application/command). 
> > 2) Vendor ID is ALREADY unique and registered with IANA, and exists today 
> > 3) Application does not need to be unique and can be allocated by the vendor, 
>      because of point 1. 
> > ... which I think is what we have now... 
> 
> A single Vendor ID could be applicable for multiple application IDs. A vendor 
> might make multiple applications.  3GPP has at least 2 applications, 
> I think ... 
> 
If the device looks at the Vendor Id and doesn't recognise it, then it can dismiss the application and commands without further processing.  The point of having the Vendor Id is that (at the risk of stating the obvious) it identifies the vendor.  Vendor A's applications are associated with it's Vendor Id, so Vendor B's devices only need to look at the Vendor Id to decide how to handle VSE's.  I'm not saying it's better than your proposal, I'm just saying it's much the same and would require less work than your proposal since I believe this is what the intention of what was originally in Diameter was.
> Since the experimental command code could exist in multiple applications, 
> the Vendor ID in the header does not provide uniqueness for the experimental 
> command code. 
> 
It doesn't need to.  There is uniqueness though in the combination of Vendor Id and command code.  If a vendor wants to reuse a command code under it's own vendor id, then that is the vendor's problem since only it's devices would be affected because all other vendor's devices can dismiss the applications on the basis of the vendor id.
> Therefore, since the experimental command is tied to an application id, but 
> not to a vendor id, I see no way in which a vendor id would provide 
> any useful information for message routing. 
Evidently, from the above, I do. 
> John

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 5 Jul 2002 12:07:16 -0700 (PDT)

> 3) Removing the Vendor-Id from the header and letting it in the AVP header is not
> a consistent solution. But if you remove it from the AVP header you must
> either forbid non-standard AVPs in the standard commands (thus dropping
> one of the ways of extending the base protocol, but avoiding the
> complications) or replace it with something else.

Vendor-specific AVPs and Vendor-Specific commands are separable issues.

Since there has been no IESG objection to vendor-specific AVPs, and since
these have a long history (they are supported in RADIUS), and there is WG
consensus on keeping vendor-specific AVPs, we should assume that support
for vendor-specific AVPs will remain in Diameter, and we don't need to
revisit the issue.

Similarly, I don't believe that it makes sense to forbid VSAs within
standard commands. This is also something that has been supported in
RADIUS for a long time, and so I'd like to take that issue off the table
as well.

One thing that I do think is relevant is to have an explicit discussion of
the nature of the Diameter dictionary versus the RADIUS dictionary. The
RADIUS dictionary is assumed to enable definition of new AVPs,
vendor-specific or standard on a RADIUS server, as long as they correspond
to known types. There is typically no concept of a dictionary on the NAS
though, since while a RADIUS server can easily define a new AVP via a
dictionary addition, the NAS typically needs new code to be added to
support carrying out the function described by the new AVP.

Diameter has a similar dictionary capability, but it is more flexible,
since there are more attribute types, as well as support for grouped AVPs.
Also, Diameter dictionaries, while not standardized, can typically deal
with command extensions as well as AVP extensions, and can define the
required syntax via the ABNF. For example, it is possible to define a new
application and to make it clear what attributes are required and optional
within that application, so that a Diameter server can judge whether an
incoming command is syntactically correct, without necessarily requiring
any new code.

In principle, this might allow Diameter to more gracefully handle new
network access methods, particularly where some attributes required or
optional in a conventional command do not make sense. For example, in
xDSL provisioning, concepts from multi-link ISDN (e.g. Port-Limit) don't
make sense. In RADIUS, there is no way to express a grammar where when
NAS-Port-Type=16 (xDSL), a Port-Limit attribute is not permitted. The
Diameter ABNF can do this.

Ideally, it would be nice to be able to add support for xDSL access to
Diameter without having to change a line of code within the Diameter
server. The Diameter dictionary and ABNF get us most of the way there,
because it should be possible to define the new command and ABNF
describing what the command can contain.

The problem comes in interpretting the meaning of the command. A new
command could be essentially the same as a standard command with a
slightly different ABNF for a new access type; or it could imply
dramatically different functionality. In the latter case, a code change is
required on *both* the NAS and Diameter Server in order to support it. In
the former case, only the NAS requires a code change.

Thus, it seems to me that it would be valuable to define the two types of
experimental command:

1) One type of "experimental" command which implies "this
command is essentially the same as an existing standard command, but with
a new ABNF", and perhaps some new (or vendor-specific AVPs). With such a
command, the Diameter server can look for the ABNF corresponding to the
command code and know what to do with no code changes. The NAS will
typically need a code change though.

2) Another type of "experimental" command which implies "this command is a
new animal, and if you don't understand it, send an error message." This
kind of command requires new code on both the Diameter server and NAS.

Does this make sense?