Subject: RE: [AAA-WG]: Vendor Command Code resolution

From: <[email-masked]>
Date: Tue, 25 Jun 2002 18:21:50 +0300

Fredrik Johansson wrote:
> I can agree that it's a nice to have feature, but awfully 
> hard to get. E.g. it's hard to advertise support for Vendor A's VSA
> within the mobile ip application without saying that also all future
> VSA's from vendor A within mobile ip is also supported.

I think the vendor is responsible for specifying the application/extension
so that it is clear what VSAs and/or VSCs are included. If new VSAs/VSCs are
added the application-id should change too.

> but if someone can come up with a easy way of differentiate the VSA's
> available today from the ones defined in the future, I'm all for it.
> Perhaps having version numbers on the VSA within a specific 
> application, then one can say in the negotiation that I support vendor A's 
> mobile ip VSA up to version nr X. Hmm, gets complicated

My understanding has been that if the "version" of the application
changes it means new application-id is assigned. And if the "version"
of AVP changes it means new AVP-code is assigned.

BR,
Mikko

---

From: <[email-masked]>
Date: Thu, 27 Jun 2002 10:24:20 +0300

Hi Glenn,

> That depends upon how you define "manage communication".  At the risk of
> becoming tediously repetitive, I pointed out on this list more than two
> weeks ago (to thundering silence) that there already exists a well-defined
> method to handle unrecognized commands (vendor-specific or otherwise).  For
> convenience, I'll quote it here: "...if a vendor-specific request is sent to
> a box that doesn't support it, the resulting answer (same command code for
> easy identification) will have the E bit set and a result code of
> DIAMETER_COMMAND_UNSUPPORTED.  How much simpler (sic) can you get?".  

I've at least added the following text, based upon your suggestion:

  DIAMETER_COMMAND_UNSUPPORTED       3001

  The Request contained a Command-Code that the receiver did not recognize or support.  
  This MUST be used when when a Diameter node receives an experimental command that it 
  does not understand.

John

---

From: <[email-masked]>
Date: Thu, 27 Jun 2002 10:48:46 +0300

Hi Bernard,

> The problem is that some have interpretted the above text to mean that
> in order to use a new application ID, they MUST create a new Command
> Code, even if one wouldn't otherwise be needed. For example, if they
> define a new set of Vendor-Specific AVPs with the 'M' bit 
> set, and would
> like to only send those AVPs to a compatible peer. This requires a new
> Application ID, but the above text also indicates it requires a new
> Command Code. This doesn't make sense.

I have modified the text to state:

  Note that the creation of a new application should be viewed as a last resort.

  New Diameter applications MUST define one Command Code or set of mandatory AVPs. 
  The expected AVPs MUST be defined in an ABNF [ABNF] grammar (see section 3.2). 
  A new application MAY also define new AVPs. If the Diameter application has any 
  accounting requirements, it MUST also specify the AVPs that are to be present in 
  the Diameter Accounting messages (see section 9.3).

John

---

From: <[email-masked]>
Date: Thu, 27 Jun 2002 10:56:56 +0300

Hi Tony,

> > b. Carve out an "experimental" playpen space within the 
> existing command
> >    space, where vendors can create experimental commands.
> 
> So, with bullet a and b, we have replaced the VSCs with an experimental command
> code space. So, for this a small section needs to be added that defines the
> experimental command code space.

Yup, that is being done.

> > c. Allow use of Application IDs in a broader set of circumstances:
> >      1. To indicate support for a set of vendor-specific AVPs with the 'M'
> >         bit set
> >      2. To indicate support for an "experimental" command
> >
> > As a result, it will no longer be required that an application have a new
> > command (standard or vendor-specific) associated with it.
> 
> However, as been mention on the list, to create and use a new experimental
> command code you MUST also create a new application in which the new command
> code will be run. Thus, make the relationship between application and command
> code reciprocal.

I have modified the text, so I think that the above is covered.

> > Some implications of this:
> >
> > d. The CER/CEA exchange should prevent sending of 
> Vendor-Specific AVPs
> >    with the 'M' bit set to peers that do not support those 
> AVPs. This means
> >    that the Diameter peers won't need to retry without 'M' 
> bit AVPs after an
> >    "unrecognized AVP" error.
> >
> > e. Conflicts between "experimental" commands are avoided as 
> long as the
> >    application IDs are unique.
> 
> Since, this will be just a pool of experimental command codes, which means that
> the same experimental command code may be reused in several vendor specific
> application, we need application IDs and the Vendor ID in the Diameter header
> (as of today, i.e. let be as is) to guarantee avoiding conflict.

I see your point, but I am not sure we want to do this.  Changing the header
to support a limited, temporary value is not smart.  Further more, the 
experimental code will contain an Application ID.

John

---

From: <[email-masked]>
Date: Thu, 27 Jun 2002 12:31:30 +0300

Hi!

The "experimental" command-codes should stay available longer.
Unless we want to create interoperability problems. Not all
equipment in the network is updated overnight after the
suitable IETF standardized Diameter Applications become available
to replace the vendor-specific apps.

I'd also like to state for the record that VSCs are a much better,
formal, and controlled way to avoid interoperability problems
compared to "experimental" command-codes. I guess the decision is
already made, but I still hope everybody who is honestly concerned
about interoperability considers this.

BR,
Mikko

> -----Original Message-----
> From: ext Randy Bush [mailto:[email-masked]]
> Sent: 27 June, 2002 09:42
> To: Tony Johansson
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: Vendor Command Code resolution
> 
> 
> > Okay, so if the conclusion with IESG is that we cannot keep 
> the VSCs and
> > should instead have an experimental command code space
>                         ^ temmporary
> that will go away in a year or so.  it's just a kindness to 
> help release
> 5
> 
> randy
>

---

From: "Miguel-Angel Pallares-Lopez (ECE)" <[email-masked]>
Date: Thu, 27 Jun 2002 11:43:41 +0200

Hi,

I must agree with both points expressed by Mikko.

If we introduce experimental command codes as a replacement of VSCs, we must do it as a feature of the protocol that will be stable over time as any other feature. Even when an IETF standardized application become available to replace a vendor-specific one, there will be nodes that are not upgraded.

I share Mikko's concern about interoperability. I still don't understand what interoperability problems the VSCs create and what are these experimental codes adding to solve them. The inclusion of a higher granularity in the meaning of an Application-Id seems a good idea. This, together with the clarification suggested by John:

"

"

but talking about VSCs seems more than enough.

BR/Miguel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: jueves, 27 de junio de 2002 11:32
To: [email-masked]
Subject: RE: [AAA-WG]: Vendor Command Code resolution

Hi!

BR,
Mikko

---

From: <[email-masked]>
Date: Thu, 27 Jun 2002 14:52:01 +0300

Hi all,

> one suggestion in order to solve this problem: Would it be OK 
> for the IESG to forbid VSCs in *standard* applications, but 
> allow them in Vendor-specific applications?

The IESG has been asking for the removal of VSCs since spring of 2001.
I would not bet on this at all.  Actually, I think that they say this
would be a bigger problem.  I've been told that inclusion of VSCs is
a showstopper for the IESG.

John

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Thu, 27 Jun 2002 05:31:47 -0700

> the Diameter Accounting messages (see section 9.3).

Strange... we seem to go back to what the protocol had prior to the interim
meeting
at Nortel's facility a couple of years ago. At that time, the IESG, and
others, 
voiced concern about having too many applications to standardize, where each
app
would include a single AVP defined by a vendor for a specific application.
THen end
result is like a menu where one has to find the right "set" of applications
in order
to get the peer to communicate.

For that matter, it was decided that an app required a command code.

PatC

---

From: <[email-masked]>
Date: Fri, 28 Jun 2002 13:27:44 +0300

Hi Pete,

One more small change that is needed to be made is that the following
ABNF:

3.2  Command Code ABNF specification

  header           = "<" Diameter-Header:" [vendor-id] command-id 
                     [r-bit] [p-bit] [e-bit] ">"

  vendor-id        = 1*DIGIT ":"

should become:

  header           = "<" Diameter-Header:" command-id 
                     [r-bit] [p-bit] [e-bit] ">"

and I think that should be enough.

John

---

From: <[email-masked]>
Date: Fri, 28 Jun 2002 16:41:06 +0300

Hi Bernard,

> > > different (vendor, application) pairs.  This approach would be pretty
> > > non-optimal in terms of processing required for vendor specific
> > > commands, but might be much more likely to answer Randy's 
> concerns.
> 
> Question: do changes need to be made to routing in order for this to
> work?

My assumption would be that this is fairly transparent, but I will check 
into this.

John

---

From: <[email-masked]>
Date: Sat, 29 Jun 2002 16:13:29 +0300

Hi Bernard,

> Question: do changes need to be made to routing in order for this to

Looking over this, I don't think it would matter.  Essentially, it
would be the same as for any other application (NASREQ, MIP).  The
experimental code would be in a vendor-specific application, so
it has no new needs for routing - just the same as any other 
application.

John

---

From: <[email-masked]>
Date: Sun, 30 Jun 2002 21:03:29 +0300

Hi Bernard,

> The comment still stands, though -- that it is very awkward to be unable
> to interpret the command without parsing AVPs. Perhaps the application
> ID should go in the header?

I've been debating this myself.  Currently, Application ID is in the ACR,
ACA and the CER, CEA messages.  

We have 3 types of Application IDs:
	Authorization 
	Accounting
	Vendor Specific

If we allow 32 bits for the Application ID that should be enough, if
we make a generic Application ID.  

I'm going to make a test edit of the doc and see if it makes sense
to move this into the header.

John