Subject: [AAA-WG]: Diameter Base: Application ID proposal

From: <[email-masked]>
Date: Wed, 3 Jul 2002 14:35:01 +0300

Hi all,

Reviewing the current spec, I think it is important to make
the Application ID unique, across IETF standards and 
Vendor Applications.  What this means is that there would
be an IANA registry which would work on a first come, first
serve basis.  In the IANA registry, there would be a field
to state the vendor and contact person.  In the case of an
IETF standard application, this would reduce down to IETF &
the RFC number.   Does this sound reasonable?
This would be aid message routing greatly.  

Comments?

John

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 01 July, 2002 16:33
> To: Loughney John (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header
> 
> 
> > 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.
> 
> > 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.
> 
> 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: Yoshihiro Ohba <[email-masked]>
Date: Wed, 3 Jul 2002 09:32:40 -0400

> This would be aid message routing greatly.  

I think it's necessary, but I'm not sure it's sufficient.

When a vendor uses a Vendor-Specific-Application-ID with specifying
their Vendor-ID and a standard Auth-Application-Id, e.g., (NASREQ), it
would be problematic if that vendor application could be something
different from the Diameter NASREQ application and that is going to be
widely used for a long time without being standardized.

Instead of that, is it possible to eliminate
Vendor-Specific-Application-ID (i.e., just using
{Auth,Acct}-Application-Id without accompaning a Vendor-ID) and
partition the Application Identifier number space into three
categories for which different number assignment policy is applied,
i.e., "standard", "temporary" and "private use", like I suggested for
Command-Code?

What do you think?

Yoshihiro Ohba

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Jul 2002 05:44:45 -0700 (PDT)

There are two distinct issues here:

a) Desire to make the app-ID unique for capabilities negotiation.
b) Desire to make command + ? unique in the case of "experimental"
commands.

So based on problem a) alone, it would seem that making the app-ID unique
makes sense.

Problem b) is somewhat distinct, and whether ? = app-ID depends on how
"experimental" commands are allocated. For example, if the "experimental"
commands are allocated uniquely by IANA, then I think we don't also need
the app-ID to uniquify the command code. However, if there is a small
experimental command space that can be reused for multiple uses, then to
prevent conflicts, then command + app-ID needs to be unique.

Note that whatever uniquifies the command needs to be put into the
Diameter header, so that it won't be necessary to parse AVPs to figure out
what the command is.

I'd also note that making app-id + command unique implies that a new
application reusing standard commands could change the definition of
standard commands. That might argue for allocation of "experimental"
commands by IANA, so that the command alone would be unique, the app-ID
wouldn't be needed in the header, and a new application couldn't redefine
the meaning of existing standard commands.

---

From: Pete McCann <[email-masked]>
Date: Mon, 8 Jul 2002 17:44:32 -0500

> This would be aid message routing greatly.  

I think this approach makes sense.

I am a bit confused about the current status of the discussions - I
read draft-12 and I see the Vendor-ID is there in the header.  Is the
current consensus to keep it there or remove it?  With the above, I
guess it doesn't really need to be there, although it could be an aid
to certain implementations.

Also, will the experimental assignments for application IDs be
permanent or temporary?  John, I liked the text you proposed in email
on 6/30 but which I don't see in the current draft-12.  It allocated
24 bits worth of vendor-specific application IDs, which should easily
be large enough.  I would hope that we can make the assignments
permanent, but if even the existence of this space is only temporary
in order to satisfy the IESG concerns, then we essentially have an
expiration date for all of 3GPP's specification work.  It sounds like
some people want that (scenario 4 from Jari's mail), but is that
really what we are headed for?

I think a lot of the text in draft-12 is still a bit schizophrenic
with respect to "vendor-specific" vs. "experimental."  Do we now have
both "Experimental Applications" and within those, "Experimental
Commands?"  Are these equivalent to the terms "Vendor-Specific
Application" and "Vendor-Specific Command"?

The text I supplied for section 3 may need to be changed, as I don't
think the AVP needs to be parsed anymore just to dispatch the command:

      Command-Code values in the range 0xfffff0 through 0xffffff are
      reserved for experimental use.  Commands in this range MUST
      include a Vendor-Specific Application ID (see section 6.11) as the
      first AVP.  The Vendor-Specific Application ID, together with the
      Command-Code value, determines the meaning of the experimental
      command.

Change to:

      Command-Code values in the range 0xfffff0 through 0xffffff are
      reserved for experimental use.  Commands in this range MUST use
      an IANA-assigned Application ID from the range 0xff00000000 -
      0xfffffffe (see Section 11.3).  Commands in this range MUST also
      include a Vendor-Specific Application ID  AVP (see section 6.11).

This is assuming that your e-mail text for Section 11.3 is adopted.

Finally, I wonder if the following is really what we want:

   Experimental Command Codes, where the Vendor-Id field in the Diameter
   header is set to a non-zero value, are for private, experimental
   usage. These codes are only for experimental purposes, no guarentee
   is made for interoperability between Diameter peers using
   experimental commands.  The range of values will have a limited
   lifetime, and will eventually be reconsumed into the range available
   for standardization.

I personally think that the experimental command range is useful to
keep around for the forseeable future, in case vendors or groups other
than 3GPP want to carry out Diameter experiments.  So, I would strike
the last sentence from the above.  We still would have the "control"
of the Application ID assignment, which could be temporary if desired.
This could even be determined on a case-by-case basis, depending on
the deployment of a particular application and its timeline for
standardization in the IETF.  However, I can't imagine documenting a
particular policy for how to set this lifetime and the whole idea of
temporary assignments seems like a quagmire that we should avoid.

-Pete