Subject: RE: [AAA-WG]: Issue: Removal of vendor-specific Diameter command- codes

From: "Daniel Warren" <[email-masked]>
Date: Tue, 11 Jun 2002 09:54:37 +0100

All

I have to say that I am concerned by the proposal that John Loughney has
communicated here.  It was my understanding that vendor specific extension
was exactly that - a facility whereby a vendor can include additional
commands to facilitate the extension of Diameter Base Protocol or Diameter
Applications to enhance their specific implementation.  Vendors are given a
vendor id and using that, they may identify that something is a specific
extension and defined command codes under that vendor id as they see fit.
The fact that the vendor id is present should be enough to separate the
standardised commands in IETF applications and those which are, for want of
a better word, 'proprietary'.

Having looked at Randy's comments, it strikes me that he is not concerned
about the proposals as a whole but more concerned about 'mandatory'
extensions.  My feeling on this is that if an extension is vendor specific,
it is implicitly optional.  If it were not optional then all vendors'
implementations would have to support it, and then it is not vendor specific
anymore.

I really do not see the need to change what is in the text right now.

Regards

Dan Warren

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 11 June 2002 08:06
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Issue: Removal of vendor-specific Diameter
command-codes

Hi,

I fully support the Pete's view.

In 3GPP the vendor-specific-application-Id AVP is widely
used.
In my understanding 3GPP has already been assigned the
vendor-id 10415.
Removing vendor-specific support from the Diameter base
it would actually be very disruptive.

BR
Marco

> -----Original Message-----
> From: ext Pete McCann [mailto:[email-masked]]
> Sent: 10. June 2002 21:42
> To: Loughney John (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [AAA-WG]: Issue: Removal of vendor-specific Diameter
> command-codes
> 
> 
> 
> Hi,
> 
> As I understand it 3GPP is currently planning to define several
> 3GPP-specific Diameter applications.  These include their Cx
> interface, for SIP authentication/authorization, the Sh interface, for
> SIP application authentication/authorization, and the Charging
> application for IMS.  I believe they plan to make extensive use of
> 3GPP-specific Vendor/Organization codes in these applications, and to
> proceed on these applications without standards action in the IETF.
> Removing vendor-specific support from the Diameter base protocol would
> be quite disruptive to these plans.
> 
> -Pete
> 
> [email-masked] writes:
>  > Hi all,
>  > 
>  > If I have understood Randy Bush correctly, the IESG strongly
>  > objects to the inclusion of support for vendor-specific 
> command-codes
>  > in the Diameter Base Protocol.
>  > 
>  > The modifications needed to remove these are as follows:
>  > 
>  > 1) removal of Vendor-ID from the Diameter Header.
>  > 2) removal vendor-specific command-codes from 5.3.6
>  > 3) vendor-specific Diameter command-codes from 6.11 
>  > 4) Discussion of vendor-specific Diameter command-codes in 
> section 11.2.1
>  > 
>  > Below is the current text from Diameter 11 that discusses 
> vendor-specific command-codes.
>  > 
>  > Again, the proposal is that all mention of vendor-specific 
> command-codes 
>  > would be removed.
>  > 
>  > Please comment on the list.
>  > 
>  > thanks,
>  > John
>  > 
>  > ============
>  > 
>  > 3  Diameter Header
>  > 
>  > [text clipped]
>  > 
>  >    Vendor-ID
>  >       In the event that the Command-Code field contains a vendor
>  >       specific command, the four-octet Vendor-ID field 
> contains the IANA
>  >       assigned "SMI Network Management Private Enterprise Codes"
>  >       [ASSIGNNO] value. If the Command-Code field contains an IETF
>  >       standard Command, the Vendor-ID field MUST be set to 
> zero (0). Any
>  >       vendor wishing to implement a vendor-specific 
> Diameter command
>  >       MUST use their own Vendor-ID along with their 
> privately managed
>  >       Command-Code address space, guaranteeing that they will not
>  >       collide with any other vendor's vendor-specific 
> command, nor with
>  >       future IETF applications. All vendor-specific 
> Diameter commands
>  >       require Informational RFCs documenting the command unless for
>  >       Private Use as described in Section 11.1.1.
>  > 
>  > -> (11.1.1 needs to be changed to 11.2.1)
>  > 
>  > =====
>  > 
>  > 5.3.6  Supported-Vendor-Id AVP
>  > 
>  >    The Supported-Vendor-Id AVP (AVP Code 265) is of type 
> Unsigned32 and
>  >    contains the IANA "SMI Network Management Private 
> Enterprise Codes"
>  >    [ASSIGNNO] value assigned to a vendor other than the 
> device vendor.
>  >    This is used in the CER and CEA messages in order to 
> inform the peer
>  >    that the sender supports a subset of the 
> vendor-specific commands
>  >    and/or AVPs defined by the vendor identified in this AVP.
>  > 
>  > =====
>  > 
>  > 6.11  Vendor-Specific-Application-Id AVP
>  > 
>  >    The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
>  >    Grouped and is used to advertise support of a vendor-specific
>  >    Diameter Application. Exactly one of the Auth-Application-Id and
>  >    Acct-Application-Id AVPs MAY be present.
>  > 
>  >    This AVP MUST also be present in all vendor-specific 
> commands defined
>  >    in the vendor-specific application.
>  > 
>  >    This AVP SHOULD be placed as close to the Diameter header as
>  >    possible.
>  > 
>  >    AVP Format
>  > 
>  >       <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
>  >                                         1* [ Vendor-Id ]
>  >                                         0*1{ Auth-Application-Id }
>  >                                         0*1{ Acct-Application-Id }
>  > 
>  > =====
>  > 
>  > 
>  > 11.2.1  Command Codes
>  > 
>  >    The Command Code namespace is used to identify Diameter 
> commands. The
>  >    values 0-255 are reserved for RADIUS backward 
> compatibility, and are
>  >    defined as "RADIUS Packet Type Codes" in [RADTYPE]. The 
> remaining
>  >    values are available via Standards Action [IANA].
>  > 
>  >    Vendor-Specific Command Codes, where the Vendor-Id field in the
>  >    Diameter header is set to a non-zero value, are for Private Use.
> 
>

---

From: Sakthidaran V <[email-masked]>
Date: Tue, 11 Jun 2002 14:41:31 +0530

Hi ,

>  My feeling on this is that if an extension is vendor specific, it is implicitly optional.  If it were not
> optional then all vendors' implementations would have to support it, and then it is not vendor specific anymore.
>

I too agree with Daniel .

Thank you for your time .

Regds
Shakthi
[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Jun 2002 07:17:31 -0700

> Applications to enhance their specific implementation.

like most standards organizations, the ietf is about users' needs for
multi-vendor inter-operability

randy