Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header

From: "Miguel-Angel Pallares-Lopez (ECE)" <[email-masked]>
Date: Mon, 1 Jul 2002 09:00:40 +0200

Hi John,

Isn't it simpler to leave it as it is, with the Vendor-ID in the header? Now, instead of a range of experimental command-codes, is the proposal to create a range of experimental application ids?

With this change, we need interaction with IANA for something that won't be of general interest (vendor-specific extensions).

BR/Miguel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: domingo, 30 de junio de 2002 21:16
To: [email-masked]; [email-masked]
Subject: [AAA-WG]: Text needed for: Applicaiton ID in the header

Hi all,

Here is the text that I think is needed.  There are some other
places that need to be cleaned up as well.

John

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      Ver      |                 Message Length                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |R P E r r r r r|                  Command-Code                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Application-ID                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      Hop-by-Hop Identifier                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      End-to-End Identifier                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  AVPs ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-

[some text]

   Application-ID

	Application-ID is four octets and is used to identify to which 
	application the message is applicable for.  The application can 
 	be an authentication application, an accounting application or a 
	vendor specific application.  See section 11.3 for the possible 
	values that the application-id may use.  

	The application-id in the header MUST be the same as what is contained
	in any relevant AVPs contained in the message.

11.3  Application Identifiers

  As defined in section 2.4, the Application Identifier is used to identify 
  a specific Diameter Application. There are standards-track application ids 
  and vendor specific application ids.

  IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for standards-track 
  applications; and 0xff00000000 - 0xfffffffe for vendor specific applications.

  Both Application-Id and Acct-Application-Id AVPs use the same Application Identifier 
  space.

  Vendor-Specific Application Identifiers, encoded in the Vendor-Specific-Application-Id 
  Grouped AVP, with the Vendor-Id AVP set to the vendor's enterprise number, is for 
  Private Use.

  Note that the Diameter protocol is not intended to be extended for any purpose. 
  Any applications defined MUST ensure that they fit within the existing framework, 
  and that no changes to the base protocol are required.

---

From: <[email-masked]>
Date: Mon, 1 Jul 2002 10:12:12 +0300

Hi Miguel,

> Isn't it simpler to leave it as it is, with the Vendor-ID in 
> the header? Now, instead of a range of experimental 
> command-codes, is the proposal to create a range of 
> experimental application ids?

One of the problems is that if we leave it the way it is, parsing
of the Diameter messages will be quite hard, because you will
need to dig into the AVP to find out what application the experimental
command code is meant for.  
 
> With this change, we need interaction with IANA for something 
> that won't be of general interest (vendor-specific extensions).

There is no way to ensure that any vendor-specific extenstion does
not end up on the open Internet.  The intent of the IETF is not to
create seperate networks, but one network (i.e. - the Internet).
Therefore, I think that the IESG feels that we to have mechanisms
to ensure that when vendors extend protocols, there is at least some
way to ensure some way to track what is being done.

John

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Mon, 1 Jul 2002 06:18:49 -0700

Your proposed text does not state how a vendor gets a vendor specific
application
assigned by IANA.

PatC

-----Original Message-----
From: [email-masked]
To: [email-masked]; [email-masked]
Sent: 6/30/2002 12:15 PM
Subject: [AAA-WG]: Text needed for: Applicaiton ID in the header

Hi all,

John

  0                   1                   2                   3

[some text]

   Application-ID

	The application-id in the header MUST be the same as what is
contained
	in any relevant AVPs contained in the message.

  As defined in section 2.4, the Application Identifier is used to
identify 
  a specific Diameter Application. There are standards-track application
ids 
  and vendor specific application ids.

  IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for
standards-track 
  applications; and 0xff00000000 - 0xfffffffe for vendor specific
applications.

  Both Application-Id and Acct-Application-Id AVPs use the same
Application Identifier 
  space.

  Vendor-Specific Application Identifiers, encoded in the
Vendor-Specific-Application-Id 
  Grouped AVP, with the Vendor-Id AVP set to the vendor's enterprise
number, is for 
  Private Use.

  Note that the Diameter protocol is not intended to be extended for any
purpose. 
  Any applications defined MUST ensure that they fit within the existing
framework, 
  and that no changes to the base protocol are required.

---

From: "Miguel-Angel Pallares-Lopez (ECE)" <[email-masked]>
Date: Tue, 2 Jul 2002 09:05:36 +0200

> >> an underlying assumption of vendor-specific command codes in the
> >> 3gpp environment seems to be that the hosts using them are all from
> >> a single vendor.  if this is true, then there is no other vendor's
> >> equipment interoperating.  hence, there should be no need to
> >> identify a vendor-id, and the extended command codes should have no
> >> problems with not being unique to that vendor.
> > 
> > If life was only so simple.  It seems that in the 3GPP case, the
> > vendor is '3GPP'.  All members implementing the 3GPP AAA application
> > MUST conform to the 3GPP specs.
> 
> ok.  but i do not see how this alters my argument.  s/vendor/3gpp/
> 

3GPP has been granted a "SMI Network Management Private Enterprise Codes" value by IANA. From the point of view of the protocol, a message carrying a Vendor-Id will allow a peer to know in which scope the received command should be processed.

> > As vendors & carriers are all involved in this process in 3GPP, it
> > may be enough for 3GPP specific networks - but I think we need to
> > bring the 3GPP specifications into the IETF to ensure 
> interoperability
> > with the Internet.  I think we just need a good plan on how 
> to do this.
> 
> agreed.

You know this, this is just for the record.

The effort that 3GPP did during year 2001 was to put in place, better, to introduce in an existing draft (draft-calhoun-sip-aaa-reqs-03), the requirements that the 3GPP architecture were imposing for the interactions between SIP servers and a AAA infrastruture. Comments were given by the AD to that draft in the sense that it was too solution oriented.

In paralell, draft-johansson-diameter-mm-app implemented the requirements compiled in that draft as an extension to Diameter. The work load in AAA WG at that time (early year 2002) and the fact that the requirements draft was not yet a working group item in SIPPING prevented this draft to progress further in the AAA WG. 3GPP's final intention was to refer to this draft (once RFCed).

As close as we were to the closure of the Release-5 in 3GPP, considering that 3GPP already had a "Vendor-Id" we had no choice but to make use of the feature of the base protocol an implement our extension as a VSE, being respectful with the base protocol as we had done during the preparation of the rest of the drafts.

Currently, and following ADs advice of not producing a requirements draft so solution oriented, a new one has been prepared, draft-loughney-sip-aaa-req. It will be 3GPP's intention that this draft includes 3GPP's requirements.

3GPP are aware that the functionality offered by the protocol obtained as a result of this work may not be identical to the current 3GPP VSE. As a result of the IETF, it is expected that this protocol will solve problems more generic than the ones that the 3GPP VSE deals with. It is assumed that some of the requirements from 3GPP may not be of general interest and may not be part of the final protocol implementation. Only in that situation may 3GPP eventually require some mechanism to perform some vendor-specific adaptations.

However, this doesn't mean that the mechanism that the base protocol currently offers to create VSEs can be something provisional, as has been discussed in the list these days. The protocol has to be robust enough to cope with the potential interoperability problems that the introduction of this mechanism may create - some of us think that it is already good enough.

BR/Miguel

---

From: <[email-masked]>
Date: Thu, 4 Jul 2002 16:47:44 +0300

If the Application-Id is unique and in the header, is the Vendor-Id needed anymore in the header?

Adrian

-----Original Message-----
From: ext [mailto:[email-masked]]
Sent: 04 July, 2002 11:29
To: [email-masked]
Cc: [email-masked]
Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header

Hi Yoshihiro,

> I have a transition plan in my mind.  During the transition period,
> just assigning two different values for the same command name, i.e.,
> one is assigned from the temporal space and another is assigned from
> the standard space, and the implementation interprets both values 
> as that command name.  Very simple.  An issue is how long the 
> transition period should be.  Not too long not to short.
> 
> I believe this is the win-win solution between IETF and other SDOs,
> and the VSC approach does not outperform this approach in terms of
> interoperability.  (VSA is different, I agree that we need VSA to
> carry vendor-specific information and does not affect interoperability
> so much.)

This actually will be more complicated in reality.  What I think is a good
plan is to allow experimental command codes, which are not assumed
to be unique.  Use of these experimental commands do not guarantee 
interoperability and are meant for experimentation. See: http://www.ietf.org/internet-drafts/draft-narten-iana-experimental-allocations-01.txt for more detail.

John

---

From: "Daniel Warren" <[email-masked]>
Date: Fri, 5 Jul 2002 11:48:34 +0100

> Side affects are:  
> 	1) Application ID is needed in the Diameter header for efficient
processing
>	2) Application ID should be unique, even for vendor specific
applications
>	3) Vendor ID is not be needed in the Diameter Header then.
>
>Does this cause any technical problems for anyone?

Not trying to be argumentative but can someone explain how this is better
than;-
	1) Vendor ID is needed in the Diameter header for efficient
processing (servers that don't recognise the Vendor-Id dismiss the
application/command).
	2) Vendor ID is ALREADY unique and registered with IANA, and exists
today
	3) Application does not need to be unique and can be allocated by
the vendor, because of point 1.

... which I think is what we have now...

Dan

---

From: <[email-masked]>
Date: Fri, 5 Jul 2002 13:53:00 +0300

Hi Dan,

> Not trying to be argumentative but can someone explain how this is better than;- 
> 1) Vendor ID is needed in the Diameter header for efficient processing (servers 
     that don't recognise the Vendor-Id dismiss the application/command).
> 2) Vendor ID is ALREADY unique and registered with IANA, and exists today 
> 3) Application does not need to be unique and can be allocated by the vendor, 
     because of point 1. 
> ... which I think is what we have now... 

A single Vendor ID could be applicable for multiple application IDs. A vendor
might make multiple applications.  3GPP has at least 2 applications,
I think ... 

Since the experimental command code could exist in multiple applications,
the Vendor ID in the header does not provide uniqueness for the experimental
command code.

Therefore, since the experimental command is tied to an application id, but
not to a vendor id, I see no way in which a vendor id would provide
any useful information for message routing.

John

---

From: "Daniel Warren" <[email-masked]>
Date: Fri, 5 Jul 2002 13:57:23 +0100

today 
> might make multiple applications.  3GPP has at least 2 applications,

If the device looks at the Vendor Id and doesn't recognise it, then it can
dismiss the application and commands without further processing.  The point
of having the Vendor Id is that (at the risk of stating the obvious) it
identifies the vendor.  Vendor A's applications are associated with it's
Vendor Id, so Vendor B's devices only need to look at the Vendor Id to
decide how to handle VSE's.  I'm not saying it's better than your proposal,
I'm just saying it's much the same and would require less work than your
proposal since I believe this is what the intention of what was originally
in Diameter was.

> the Vendor ID in the header does not provide uniqueness for the
experimental
It doesn't need to.  There is uniqueness though in the combination of Vendor
Id and command code.  If a vendor wants to reuse a command code under it's
own vendor id, then that is the vendor's problem since only it's devices
would be affected because all other vendor's devices can dismiss the
applications on the basis of the vendor id.

> any useful information for message routing.

Evidently, from the above, I do.

---

From: <[email-masked]>
Date: Mon, 8 Jul 2002 09:02:02 +0300

Hi Dan,

> dismiss the application and commands without further processing.  The 
> point of having the Vendor Id is that (at the risk of stating the obvious)
> it identifies the vendor.  Vendor A's applications are associated with it's
> Vendor Id, so Vendor B's devices only need to look at the Vendor Id to decide
> how to handle VSE's.  I'm not saying it's better than your proposal, I'm
> just saying it's much the same and would require less work than your 

Currently, there is no text for the above behavior in the draft. That
is one problem.  The other problem is what is the behavior for relays
and proxies.  Do wee need to add text to say that messages must be
routed using vendor ids as well?  THis would be a problem.

An example scenario would be two operators who are using a 
vendor specific command.  In between them, there is a relay,
who knows nothing of this command.  If the relay would drop
all messages containing the vendor id, then there communication
between the two operators would broken.

Currently, diameter message routing is done on application id,
as a secondary key.  By moving the application id into the header,
message processing is simpler.  One problem, though is, if
the vendor-id + application id uniquely define an application,
then we need to route on one more field, the vendor id.  

John