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

From: "Carolina Canales Valenzuela (ECE)" <[email-masked]>
Date: Thu, 27 Jun 2002 13:42:23 +0200

Hi, 
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?

My understanding of the interoperability problem is that it arises mainly when an VSC is used inside a *standard* application. The peer has announced the support of the standard application, but of course it could happen that it doesn't understand the VSC. I think that this is the most problematic issue. The solution might be to forbid the use of VSCs in standard applications, and use the experimental command codes for such purposes. If, even though, the peer does not support such experimental command, then it would answer back with an error, and the Result Code DIAMETER_COMMAND_UNSUPPORTED.

However, for Vendor Specific Applications, once that the vendor has obtained the Vendor-Id from IANA, it could be the own vendor the one in charged of assigning the command codes inside the Vendor-Specific-App (i.e., leave the base as it used to be regarding this). There are no interoperability problems in this case, because such codes will be just sent to the peers that through CER/CEA advertised the support of the Vendor-Specific-App, and such command codes will always be marked with the Vendor-Specific-Application-Id (Vendor-Id + Vendor-App-Id), plus the Vendor-Id in the header, in case it is maintained.  
Like this, the feature would be stable over time, specially for the legacy R5 nodes.

Comments?

Carolina

>-----Original Message-----
>From: Miguel-Angel Pallares-Lopez (ECE)
>[mailto:[email-masked]]
>Sent: Thursday, June 27, 2002 11:44 AM
>To: [email-masked]'; [email-masked]
>Subject: RE: [AAA-WG]: Vendor Command Code resolution
>
>
>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:
>
>"
>  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.
>
>"
>
>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!
>
>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: "Fredrik Johansson" <[email-masked]>
Date: Thu, 27 Jun 2002 15:56:50 +0200

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Carolina Canales Valenzuela (ECE)
> Sent: den 27 juni 2002 13:42
> To: Miguel-Angel Pallares-Lopez (ECE); [email-masked]
> Cc: [email-masked]'
> 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?
>
> My understanding of the interoperability problem is that it
> arises mainly when an VSC is used inside a *standard*
> application.

That's why Glen suggested that a VSC required a new application-id. i.e. you
can't send a VSC in a standard application, the only thing you can do is to
send vendor specific avps.

/fredrik

The peer has announced the support of the standard
> application, but of course it could happen that it doesn't
> understand the VSC. I think that this is the most problematic
> issue. The solution might be to forbid the use of VSCs in
> standard applications, and use the experimental command codes for
> such purposes. If, even though, the peer does not support such
> experimental command, then it would answer back with an error,
> and the Result Code DIAMETER_COMMAND_UNSUPPORTED.
>
> However, for Vendor Specific Applications, once that the vendor
> has obtained the Vendor-Id from IANA, it could be the own vendor
> the one in charged of assigning the command codes inside the
> Vendor-Specific-App (i.e., leave the base as it used to be
> regarding this). There are no interoperability problems in this
> case, because such codes will be just sent to the peers that
> through CER/CEA advertised the support of the
> Vendor-Specific-App, and such command codes will always be marked
> with the Vendor-Specific-Application-Id (Vendor-Id +
> Vendor-App-Id), plus the Vendor-Id in the header, in case it is
> maintained.

I agree, I would much more prefer to keep the vendor specific than having
some experimental stuff. the vendor specific has been thought thru and it
works. Why change to something new that has not been carefully reviewed?

/fredrik