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

From: Daser Martin ICM N PG U ID A 3 <[email-masked]>
Date: Tue, 11 Jun 2002 09:29:07 +0200

Hi,

we have been following this discussion for a while.
We think that the removal of vendor specific support from the base draft
would certainly be very disruptive for the standards process.
Eliminating parts parts of the draft and setting up a new one with the
eliminated contents will take a lot of time and some more iterations in the
standards process.

What would be the benefit of removing vendor support from the base draft?

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Dienstag, 11. Juni 2002 09: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: "Daniel Warren" <[email-masked]>
Date: Tue, 11 Jun 2002 15:23:50 +0100

Agreed.  Which is why vendor specific extensions of protocols should be
defined by the vendor concerned and NOT be part of a standards process.

It is also why vendor specific extensions should be defined in an entirely
optional way so that they do not break the multi-vendor interoperability
should they 'leak' into a multi-vendor environment.  The text in the
Diameter Base right now allows for both of the above statements to hold
true.

So isn't the solution to allow extensibility with that understanding rather
than to restrict it?

Dan

-----Original Message-----
From: Randy Bush [mailto:[email-masked]]
Sent: 11 June 2002 15:18
To: Warren, Daniel [MDN05:EP10:EXCH]
Cc: [email-masked]
Subject: RE: [AAA-WG]: Issue: Removal of vendor-specific Diameter
command- codes

> 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.

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

randy