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

From: <[email-masked]>
Date: Mon, 1 Jul 2002 16:26:26 +0300

Hi Pat,

> Your proposed text does not state how a vendor gets a vendor specific application 
> assigned by IANA. 

That would be added in my proposal, if there is support.

If we don't do this, then digging through this a bit more, I found a bug in the 
current base spec:

 2.7  Realm-Based Routing Table

  All Realm-Based routing lookups are performed against what is commonly known
  as the Realm Routing Table (see section 12). A Realm Routing Table
  Entry contains the following fields:

   - Realm Name. This is the field that is typically used as a primary key in 
     the routing table lookups. Note that some implementations perform their 
     lookups based on longest-match-from-the-right on the realm rather than 
     requiring an exact match.

   - Application Identifier. An application is identified by a vendor id and 
     an application id. For all IETF standards track Diameter applications, 
     the vendor id is zero . A route entry can have a different destination 
     based on the application identification avp of the message.  This is one 
     of Acct-Application-Id (for accounting messages), Auth-Application-Id (for 
     non-accounting messages) or Vendor-Specific-Application-Id (for vendor 
     specific messages). This field MUST be used as a secondary key field in 
     routing table lookups.

The text under Application ID seems to indicate that an Application ID is really 
64 bits (Vendor ID + Application ID), in the case of an IETF standard application,
the Vendor ID = 0.  

This is important to note, because currently, there is no provision to make Vendor
Application IDs unique.  Therefore, the realm routing table MUST keep track of the
Vendor ID.

Does it make sense to make this more explicit in the text?

John

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 1 Jul 2002 06:32:32 -0700 (PDT)

> That would be added in my proposal, if there is support.

I think it's worth discussing what the choices are. It could be allocated
by IANA on a first-come, first-served basis with no spec. This seems
like the most reasonable to me. "Expert review with spec" seems
inappropriate, since vendor-specific AVPs might be involved.

Similarly, I don't think we can rope off portions of a 32-bit application-ID
space for an SMI code. This is 24 bits, and so there would only be 8 bits
left for the application, which is too small.

> Application IDs unique.  Therefore, the realm routing table MUST keep track of the

I think that without making the Application ID unique, there is a problem,
because this would mean that App-ID + Command Code would not uniquely
identify the command.

> Does it make sense to make this more explicit in the text?

I think that some additional text is needed, yes.

---

From: Randy Bush <[email-masked]>
Date: Mon, 01 Jul 2002 07:35:42 -0700

an underlying assumption of vendor-specific command codes in the
3gpp environment seems to be that the hosts using them are all from
a single vendor.  if this is true, then there is no other vendor's
equipment interoperating.  hence, there should be no need to
identify a vendor-id, and the extended command codes should have no
problems with not being unique to that vendor.

and be careful not to tell me that they need to interoperate in a
multi-vendor environment, as that's what standards are all about.

randy

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 1 Jul 2002 17:25:36 -0700

Randy Bush [mailto://[email-masked]] writes:

> a single vendor.

I'm not sure where you that that idea from.  The proposed VSCs of which I'm
aware are 3GPP-specific; that is to say, they would only be used in a 3GPP
environment.  However, the 3GPP environment will certainly include equipment
from many different vendors.

> if this is true, then there is no other vendor's

Let's try for a little clarity here: the 3GPP VSCs would only be used in a
3GPP environment, and any equipment vendor wishing to sell into the 3GPP
market would presumably need to demonstrate interoperability w/other vendors
in that environment.  In this case the "vendor" is an SDO (why, I'm not
sure; maybe they believe that their app is very unique, maybe there is
despair at getting what they need standardized in the IETF before 3G is
obsolete).

---

From: Randy Bush <[email-masked]>
Date: Mon, 01 Jul 2002 17:32:12 -0700

> from many different vendors.

sounds like a need for standards.

> despair at getting what they need standardized in the IETF before 3G is

i doubt it is productibe to get into a slanging match with 3gpp about
deployment and takeup rates vs. ietf document production rates.  so let's
all just do our jobs and chill.

randy

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 1 Jul 2002 18:49:02 -0700

> sounds like a need for standards.

Agreed, but whose?  3GPP writes standards, too, and it's their standard that
the vendors would need to follow (this may imply by reference IETF standards
as well, of course).

> deployment and takeup rates vs. ietf document production rates.

I don't know too much about 3GPP, but I am quite familiar w/3GPP2.  They
have basically designed their network infrastructure around the
functionality present in Diameter, including VSEs, having come to the wise
conclusion that RADIUS was insufficient for the job.  It's hard to deploy if
you don't have the tools to do it.

> so let's