Subject: [Dime] 3588bis: Vendor Ids in CER/CEA

From: "Mark Jones" <[email-masked]>
Date: Tue, 21 Aug 2007 11:45:24 -0400

The description for the Vendor-Id AVP in CER/CEA messages state it is to
identify the "vendor of the application" but in that case, it appears to
be redundant. The application vendor is already advertised within the
grouped Vendor-Specific-Application-Id AVP for a vendor-specific
application. 

Looking though my attic of draft-ietf-aaa-diameter-xx, I see this
Vendor-Id AVP was originally destined to identify the device vendor.
Hence the comment in 3588: "It is also envisioned that the combination
of the Vendor-Id, Product-Name (Section 5.3.7) and the Firmware-Revision
(Section 5.3.4) AVPs MAY provide very useful debugging information". I
think we should fix this in 3588bis but backwards compatibility is
likely an issue.

On a related noted, I assume that advertising support for a
vendor-specific application implies support for the vendor-specific AVPs
from that same vendor. If so, I couldn't find this explicitly stated in
3588 and it probably should not be left as an assumption.

Regards
Mark

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 21 Aug 2007 17:45:10 +0200

Hi Mark,

do you plan to propose specific text to make it easier to finish this 
issue?

Ciao
Hannes

---

From: "Mark Jones" <[email-masked]>
Date: Tue, 21 Aug 2007 11:55:49 -0400

> do you plan to propose specific text to make it easier to finish this 

Absolutely Hannes. But I wanted to use the list to poll for any
backwards compatibility concerns of changing the description back to
"device vendor". Any concerns?

I also wanted to check that my assumption on support of vendor-specific
AVPs was correct. Does it make sense to you?

Regards
Mark

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 21 Aug 2007 12:01:09 -0400

Hi Mark,

If certain vendor specific AVPs without M-bit set are added for a
command, it seems possible to use an existing application. In such a
case, it could be useful to signal which optional extensions are
supported by an endpoint. 

I think Supported-Vendor-Id could be used for the purpose I mentioned
above. I am aware of a few implementations which use Vendor-Id for this
purpose as well.

Actually, considering that advertising support for optional extensions
should be done end-to-end, using CER/CEA for that purpose is of limited
use. There could be intermediaries between client and servers. It could
be an idea to mention about this limitation and preferably address it.
Or we can just deprecate this functionality assuming that if an
extension is optional, it shouldn't matter much whether the server
supports it (and if the extension is really vital, it should be a new
application).

   Thanks,
   Tolga

> -----Original Message-----
> From: Mark Jones [mailto:[email-masked]]
> Sent: Tuesday, August 21, 2007 11:45 AM
> To: [email-masked]
> Subject: [Dime] 3588bis: Vendor Ids in CER/CEA
>

---

From: "Mark Jones" <[email-masked]>
Date: Tue, 21 Aug 2007 14:30:59 -0400

Thanks Tolga. Answers inline. 

> supported by an endpoint. 

Agreed but let me illustrate the ambiguity with an example:

A Diameter peer supports a 3GPP application with some optional
Bridgewater vendor-specific AVPs (no M-bit set). In the CER/CEA, 3GPP's
vendor id would go into the Vendor-Id AVP in the
Vendor-Specific-Application-Id AVP and Bridgewater's vendor id would go
into the Support-Vendor-Id AVP. So far so good.

But the 3GPP application uses 3GPP vendor-specific AVPs so should 3GPP's
vendor id also be advertised in a Supported-Vendor-Id AVP?

Non-IETF SDOs appear to disagree on the answer to this question. I think
3588bis should be opinionated otherwise interop will suffer on
convergence between SDOs. I propose appending the following to section
5.3.6 (Supported-Vendor-Id):

"If a peer advertises support of a vendor-specific application, it is
implied that the peer supports (a subset of) the vendor-specific AVPs of
that vendor. In this case, the CER/CEA SHOULD NOT contain a
Supported-Vendor-Id AVP with the IANA "SMI Network Management Private
Enterprise Codes" [RFC3232] value of the application vendor."

I don't think we can make that "SHOULD NOT" into a "SHALL NOT" due to
backwards compatibility concerns. Any objections?

Regards
Mark

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 21 Aug 2007 14:50:44 -0400

Hi Mark,

Please see below for comments/questions.

  Thanks,
  Tolga

> Sent: Tuesday, August 21, 2007 2:31 PM
> To: Asveren, Tolga; [email-masked]
> Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA
> 
[TOLGA] I would say "No" considering the existing text in RFC3588:
   "The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains
   the IANA "SMI Network Management Private Enterprise Codes" [ASSIGNNO]
   value assigned to the vendor of the Diameter application.  In
   combination with the Supported-Vendor-Id AVP (Section 5.3.6), this
   MAY be used in order to know which vendor specific attributes may be
   sent to the peer."

So, basically it seems Vendor-Id implies that AVPs for the corresponding
vendor are supported as well. There shouldn't be a need to re-specify
this with Supported-Vendor-Id AVP.
> backwards compatibility concerns. Any objections?
[TOLGA]Overall, I think embedding some end-to-end information into
capability exchange procedure is not a good idea. This seems to be an
oversight in RFC3588 (or a leftover from an early version, where there
wasn't support for intermediaries).

---

From: "Mark Jones" <[email-masked]>
Date: Tue, 21 Aug 2007 15:30:43 -0400

> this with Supported-Vendor-Id AVP.

And that was the first point in my original email: The original
intention of the Vendor-Id AVP in the CER/CEA was to communicate the
'device vendor' NOT the 'application vendor'. Admittedly this was a poor
choice of AVP name given all the vendor ids flying around in CER/CEA and
this vague name probably explains why the AVP description was later
(mistakenly?) changed from 'device vendor' to 'application vendor'.

So I also propose changing the first paragraph in section 5.3.3 to:

 The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains
 the IANA "SMI Network Management Private Enterprise Codes" [RFC3232]
 value assigned to the vendor of the Diameter device. It is 
 envisioned that the combination of the Vendor-Id, Product-Name 
 (Section 5.3.7) and the Firmware-Revision (Section 5.3.4) AVPs MAY
 provide very useful debugging information.

> wasn't support for intermediaries).

The 'very useful debugging information' here was only ever intended for
debugging a single hop. I agree that CER/CEA exchanges offer no help in
end-to-end debugging and that was never the intent of the
Vendor-Id/Product-Name/Firmware-Revision AVPs.

Regards
Mark

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 21 Aug 2007 15:43:05 -0400

Hi Mark,

Please see below for comments.

  Thanks,
  Tolga

> Sent: Tuesday, August 21, 2007 3:31 PM
[TOLGA]Except backward compatibility issues, IMHO this change makes more
sense than what is currently there in RFC3588. I don't know how serious
of a backward compatibility issue we are talking about here. I saw
people using Product-Name to indicate both the vendor and a specific
product, e.g. "Company-A Product-Y". I saw people populating Vendor-Id
AVP to advertise support for AVP extensions as well. Still, IMHO we
should be able to digest this level of a change in the bis document.
> Vendor-Id/Product-Name/Firmware-Revision AVPs.
[TOLGA]The same problem is there for Supported-Vendor-Id as well.

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 22 Aug 2007 08:36:34 -0400

Hi,

> should be able to digest this level of a change in the bis document.

Backward compatibility may not be an issue since people have been given 
free reign on the interpretations of vendor-id to begin with; i.e. 
there's not set value to be backward compatible to. The proposed change 
is ok with me ... maybe a little tighter text would be better if we 
really want to be clear on the per-hop context of vendor-id.

regards,
victor

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 22 Aug 2007 08:57:10 -0400

Hi Victor,

> From: Victor Fajardo [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2007 8:37 AM
> To: Asveren, Tolga
> Cc: Mark Jones; [email-masked]
> Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA
> 
> Hi,
> 
> 
[TOLGA] There is no set value, but consider the following situation:
There a RFC3588 compliant stack, expecting Vendor-Id AVP to contain the
vendor-Id of the corresponding application vendor. With RFC3588
compliant stacks, verifying this wouldn't cause a problem because
Vendor-Id AVP would contain the expected value. With a RFC3588-bis
compliant stack, such a check would fail because Vendor-Id would contain
the vendor-Id of the product vendor not the application vendor. Having
said that:
a) I am not sure whether many implementations perform such a check
b) I agree that the functionality defined in the proposed text is better
c) I think that we should have this change in the bis
d) It could be better to provide explanation for per-hop/end-to-end
issue for Supported-Vendor-Id AVP (or for both cases)

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 22 Aug 2007 09:09:33 -0400

Hi Tolga, 

Thank you for supporting the proposal to fix this Vendor-Id ambiguity in
3588bis.

After reviewing rfc3588bis-05 for impacts, here are the proposed
changes:

---

1) Update 1st paragraph in section 5.5.3 (Vendor-Id AVP)

 The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and
 contains the IANA "SMI Network Management Private Enterprise
 Codes" [RFC3232] value assigned to the vendor of the Diameter
 device. It is envisioned that the combination of the Vendor-Id,
 Product-Name (Section 5.3.7) and the Firmware-Revision (Section
 5.3.4) AVPs MAY provide very useful debugging information.

---

2) Add new paragraph to section 5.3.6 (Supported-Vendor-Id AVP)

 If a peer advertises support of a vendor-specific application
 in the Vendor-Specific-Application-Id AVP (Section 6.11), it is
 implied that the peer supports (a subset of) the vendor-
 specific AVPs of that vendor. In this case, the CER/CEA SHOULD 
 NOT contain a Supported-Vendor-Id AVP with the IANA "SMI 
 Network Management Private Enterprise Codes" [RFC3232] value of
 the application vendor."

---

3) Update 3rd paragraph in section 6.11 (Vendor-Specific-Application-Id
AVP)

 The Vendor-Id AVP in this context contains the IANA "SMI 
 Network Management Private Enterprise Codes" [RFC3232] value
 assigned to the vendor of the Diameter application advertised 
 in the Auth-Application-Id or Acct-Application-Id AVP. It 
 indicates that the peer supports (a subset of) the vendor-
 specific AVPs of the application vendor. It MUST NOT be used
 as a means of defining a completely separate vendor-specific
 application identifier space.

---

Regards
Mark

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 22 Aug 2007 09:25:31 -0400

Hi Tolga,

> a) I am not sure whether many implementations perform such a check

I think this is the main criteria why the bis should not be too 
concerned with backward compatibility. 3588 never mandated any 
validation/processing on the vendor-id so if extra functionality is 
added onto vendor-id then its already a risky implementation for any 
vendor despite of any changes we propose.

> issue for Supported-Vendor-Id AVP (or for both cases)

Ok.

regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 22 Aug 2007 09:44:05 -0400

Hi Mark,

Ok.

>  Network Management Private Enterprise Codes" [RFC3232] value of

I'm fine with this.

>  application identifier space.

1. We can remove "(a subset of)". Advertising support for an application 
does not provide hints on "subsets" of avps.
2. s/peer/node/

regards,
victor

---

From: "Harish R Prabhu" <[email-masked]>
Date: Wed, 22 Aug 2007 21:29:51 +0530

Does anyone perceive any impact of this discussion on Vendor-Id sub AVP in
Vendor-Specific-Application-Id AVP? As my understanding goes, Application-Id
is flat and there are no validation procedures for Vendor-Id sub-AVP (as it
is informational). Then why is it mandatory in the bis- draft?

thanks,
Harish

-- 
Harish R Prabhu
Bangalore, India.

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 22 Aug 2007 12:15:48 -0400

Victor, 

I'm fine with your proposed changes.

Thanks
Mark

> Sent: August 22, 2007 15:44
> To: Mark Jones
> Cc: Asveren, Tolga; [email-masked]

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 22 Aug 2007 12:18:43 -0400

Hi Harish,

What do you mean with "informational"? I assume you refer it being between [] and optional. OTOH, the minimum count was given as 1, so actually it was a mandatory AVP. Changing this could cause message verification errors as many implementation try to validate an incoming message based on command/Grouped AVP grammars.

   Thanks,
   Tolga

________________________________________
From: Harish R Prabhu [mailto:[email-masked]] 
Sent: Wednesday, August 22, 2007 12:00 PM
To: [email-masked]
Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA

Does anyone perceive any impact of this discussion on Vendor-Id sub AVP in Vendor-Specific-Application-Id AVP? As my understanding goes, Application-Id is flat and there are no validation procedures for Vendor-Id sub-AVP (as it is informational). Then why is it mandatory in the bis- draft? 

thanks,
Harish

Ok.

I'm fine with this.

regards,
victor

-- 
Harish R Prabhu 
Bangalore, India.

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 22 Aug 2007 12:29:29 -0400

Hi Harish,
 
The proposed update to section 6.11 means the Vendor-Id sub-AVP is no
longer informational. It does mean that a vendor applying for a
vendor-specific application will have to obtain a Private Enterprise
Code too but they'd need to do that anyway in order to define any
vendor-specific AVPs for their application.
 
Regards
Mark

________________________________

	From: Harish R Prabhu [mailto:[email-masked]] 
	Sent: August 22, 2007 18:00
	To: [email-masked]
	Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA

	Does anyone perceive any impact of this discussion on Vendor-Id
sub AVP in Vendor-Specific-Application-Id AVP? As my understanding goes,
Application-Id is flat and there are no validation procedures for
Vendor-Id sub-AVP (as it is informational). Then why is it mandatory in
the bis- draft? 
	
	thanks,
	Harish

		Hi Mark,

		Ok.

		I'm fine with this.
		
		>  application identifier space.
		
		1. We can remove "(a subset of)". Advertising support
for an application
		does not provide hints on "subsets" of avps.
		2. s/peer/node/
		
		regards,
		victor

	-- 
	Harish R Prabhu 
	Bangalore, India.

---

From: "Harish R Prabhu" <[email-masked]>
Date: Wed, 22 Aug 2007 22:07:05 +0530

This was the scenario I was trying to point out:

1. Application-IDs are allocated by IANA, and have to be obtained by a
vendor with a Private Enterprise Code.

2. 1 implies that its possible to implicitly derive the Vendor info from the
Application Id itself.

Consider a situation wherein a diameter implementation sends a
Vendor-Specific-Application-Id with an erroneous combination of (Vendor-Id,
Auth/Acct-Application-Id). Some implementations may choose to validate the
Vendor-Id and some may choose not to.

Wouldnt this be an interoperability issue? If so, why have Vendor-Id in
Vendor-Specific-Application-Id to create scope for this?

thanks,
Harish

On 8/22/07, Mark Jones <[email-masked]> wrote:
> vendor-specific application will have to obtain a Private Enterprise Code
> too but they'd need to do that anyway in order to define any vendor-specific
> AVPs for their application.
>
> Regards
> Mark
>
>
>
>  ------------------------------
> *From:* Harish R Prabhu [mailto:[email-masked]]
> *Sent:* August 22, 2007 18:00
> *To:* [email-masked]
> *Subject:* Re: [Dime] 3588bis: Vendor Ids in CER/CEA
>
> > > 3) Update 3rd paragraph in section 6.11(Vendor-Specific-Application-Id
> > > AVP)
> > >
> > >

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 22 Aug 2007 13:09:16 -0400

Just to make sure I've understood the validation part: Do you mean that
an implementation would have a map from application Id to vendor Id and
validate all incoming Vendor-Specific-Application-Id AVPs against this
map?
 
So your proposal would be to make this map 'mandatory to implement' and
remove the Vendor-Id sub-AVP altogether?
 
Regards
Mark

	From: Harish R Prabhu [mailto:[email-masked]] 
	Sent: August 22, 2007 18:37
	To: Mark Jones
	Cc: [email-masked]
	Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA

	1. Application-IDs are allocated by IANA, and have to be
obtained by a vendor with a Private Enterprise Code. 
	
	2. 1 implies that its possible to implicitly derive the Vendor
info from the Application Id itself. 
	
	Consider a situation wherein a diameter implementation sends a
Vendor-Specific-Application-Id with an erroneous combination of
(Vendor-Id, Auth/Acct-Application-Id). Some implementations may choose
to validate the Vendor-Id and some may choose not to. 
	
	Wouldnt this be an interoperability issue? If so, why have
Vendor-Id in Vendor-Specific-Application-Id to create scope for this?
	
	thanks,
	Harish

	On 8/22/07, Mark Jones <[email-masked]>
wrote: 

		Hi Harish,
		 
		The proposed update to section 6.11 means the Vendor-Id
sub-AVP is no longer informational. It does mean that a vendor applying
for a vendor-specific application will have to obtain a Private
Enterprise Code too but they'd need to do that anyway in order to define
any vendor-specific AVPs for their application.
		 
		Regards
		Mark

			From: Harish R Prabhu
[mailto:[email-masked]] 
			Sent: August 22, 2007 18:00
			To: [email-masked]
			Subject: Re: [Dime] 3588bis: Vendor Ids in
CER/CEA

			Does anyone perceive any impact of this
discussion on Vendor-Id sub AVP in Vendor-Specific-Application-Id AVP?
As my understanding goes, Application-Id is flat and there are no
validation procedures for Vendor-Id sub-AVP (as it is informational).
Then why is it mandatory in the bis- draft? 
			
			thanks,
			Harish

			On 8/22/07, Victor Fajardo
<[email-masked]> wrote: 

				Hi Mark,

				Ok.

				I'm fine with this.
				
				>  application identifier space.
				
				1. We can remove "(a subset of)".
Advertising support for an application
				does not provide hints on "subsets" of
avps.
				2. s/peer/node/
				
				regards,
				victor

	

			-- 
			Harish R Prabhu 
			Bangalore, India. 

	-- 
	Harish R Prabhu
	Bangalore, India.

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 22 Aug 2007 13:31:04 -0400

Hi Harish,

> Wouldnt this be an interoperability issue? If so, why have Vendor-Id 
> in Vendor-Specific-Application-Id to create scope for this?

First, I think the bis does not mandate that such validation should take 
place. If that needs to be made clear by saying that vendor-id is 
informational value that contains the vendor info authoring the app and 
that the value is relevant for debugging purpose only then that will be 
good enough. Second, if ever somebody decides to validate these values 
and generate an "erroneous combination" type of error (not sure how 
efficient that would be since now you have to map all these values 
together ...) , it becomes an implementation issue and not an 
interoperability problem. I know other folks are putting too much 
meaning into these types of AVPs so making the usage context clear will 
help avoid limit this problem. Revising the importance of vendor-id to 
accommodate the (not so good) decisions other folks have made would 
worsen the problem.

regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 22 Aug 2007 13:33:25 -0400

Hi,

> Just to make sure I've understood the validation part: Do you mean 
> that an implementation would have a map from application Id to vendor 
> Id and validate all incoming Vendor-Specific-Application-Id AVPs 
> against this map?
>  
> So your proposal would be to make this map 'mandatory to implement' 
> and remove the Vendor-Id sub-AVP altogether?

I suggest not doing this. From the base protocol perspective, the 
vendor-id should not give more meaning that it deserves.

regards,
victor

---

From: "Harish R Prabhu" <[email-masked]>
Date: Wed, 22 Aug 2007 23:21:32 +0530

Victor,

I think a clarification text would be good enough so that an implementation
would not validate Vendor-Id while updating its knowledge about
peer-advertised applications.

thanks,
Harish

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 22 Aug 2007 16:18:41 -0400

While we are at this, I propose to add the following as well:

(Text to replace in 5.3.6 Supported-Vendor-Id AVP)
   "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 AVPs
   defined by the vendor identified in this AVP."

(Proposed Text)
"This AVP can be used in CER, CEA or in any application command, which
has it defined in the corresponding message grammar. It informs the peer
that the sender supports (a subset of) the vendor-specific AVPs defined
by the vendor identified in this AVP.

It should be noted that CER/CEA messages are exchanged in a hop-by-hop
fashion. If there are intermediary nodes, e.g. a relay agent, between a
client and server, Supported-Vendor-Id AVP won't be exchanged between
the client and the server."

   Thanks,
   Tolga

> Sent: Wednesday, August 22, 2007 9:10 AM

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 22 Aug 2007 17:10:27 -0400

Hi Tolga,

> the client and the server."

I'm ok with the text. Some editorial notes, maybe to simplify:

"It should be noted that since CER/CEA messages are exchanged only 
between peers and
does not extend beyond the single hop, Supported-Vendor-Id AVPs carried 
in these messages
are relevant only between Diameter peers."

Did I get your ideas correctly ?

regards,
victor

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 23 Aug 2007 04:50:39 -0400

Tolga, 

I understand the goal of end-to-end advertisement but it is not clear to
me how the Supported-Vendor-Id AVP would be interpreted in commands
other than CER/CEA. 

Would it be included to indicate to the peer that only the current
command contains AVP from the advertised vendor? 

Or is it intended to indicate to the peer that current and future
commands MAY contain AVPs from the advertised vendor?

Does it imply that the commands contain mandatory AVPs from the
advertised vendor? If so, how should a peer behave if it receives a
command advertising a vendor that it doesn't support? 

Could a relay node add/delete this AVP? Under what conditions?

Lots of other questions come to mind and I suspect that some of the
answers depend on the specific command or application. So I'd prefer to
leave it to the authors of the application which reuses this AVP to
define how the Supported-Vendor-Id AVP is used in their commands rather
than attempt to define a common set of required behavior in 3588bis.
Since reuse of all AVPs is encouraged, it is not necessary to mention
here that this particular AVP can be reused.

Regards
Mark

> Sent: August 22, 2007 23:10
> To: Asveren, Tolga
> Cc: [email-masked]

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 23 Aug 2007 07:47:56 -0400

Hi Victor,

> Sent: Wednesday, August 22, 2007 5:10 PM
> To: Asveren, Tolga
> Cc: [email-masked]
defined
> Did I get your ideas correctly ?
[TOLGA]Perfectly ! ! !

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 23 Aug 2007 07:50:40 -0400

Hi Mark,

Yes, I agree with your concerns. It would be difficult to define proper
semantics for generic use and probably bis is not the right place to do
so. Victor's version of the text mentions only about the hop-by-hop
nature of capability exchange and warns people about it; it leaves the
end-to-end part to applications.

   Thanks,
   Tolga

> Sent: Thursday, August 23, 2007 4:51 AM
> To: Asveren, Tolga
> Cc: [email-masked]

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 23 Aug 2007 11:26:40 -0400

It has been bought to my attention off the list that my proposal that a
peer assumes support of vendor-specific AVPs based on the Vendor-Id
sub-AVP would cause interop issues with existing implementations of
certain TISPAN applications. I therefore withdraw my previous proposal
and present a new one for your consideration.

Harish suggested making the Vendor-Id sub-AVP optional/informational
because it is not required to identify the application. This is true so
if the Vendor-Id sub-AVP is made optional, it then becomes mandatory to
identify support of the application vendor's AVPs in the
Supported-Vendor-Id AVP. This proposal keeps the TISPAN applications
happy.

So the proposed changes to 3588bis-06 are:

---

 A peer advertising support of a vendor-specific application
 does not imply that it also supports the vendor-specific
 AVPs of the application vendor. The Capabilities Exchange 
 message MUST instead include a Supported-Vendor-Id AVP with
 the IANA "SMI Network  Management Private Enterprise Codes" 
 [RFC3232] value of the application vendor.

---

3) Update 2nd paragraph in section 6.11 (Vendor-Specific-Application-Id
AVP)

 The Vendor-Id AVP is an informational AVP pertaining to
 the vendor who may have authorship of the vendor-specific 
 Diameter application. It MUST NOT be used as a means of 
 defining a completely separate vendor-specific application
 identifier space.

---

4) Update ABNF in section 6.11 (Vendor-Specific-Application-Id AVP)

 <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
                                      [ Vendor-Id ]
                                     ({ Auth-Application-Id } /
                                      { Acct-Application-Id })

---

These changes are in addition to the text suggested by Tolga/Victor to
clarify the hop-by-hop nature of CER/CEA. I also agree to that addition.

Regards
Mark

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 23 Aug 2007 11:31:03 -0400

Hi Mark,

So basically you are proposing to make Vendor-Id AVP in
Vendor-Specific-Application-Id Grouped AVP optional. This changes the
grammar of the Vendor-Specific-Application-Id. People verify incoming
messages according to that grammar. This breaks backward compatibility.

I also find it odd that people used Vendor-Id AVP in the
Vendor-Specific-Application-Id AVP to signal support for AVPs defined by
a vendor. They should have used Vendor-Id AVP in CER/CEA for that
purpose according to RFC3588.

Could you provide the text from the corresponding TISPAN specification,
which you think would cause a problem?

   Thanks,
   Tolga

> Sent: Thursday, August 23, 2007 11:27 AM
> To: [email-masked]

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 23 Aug 2007 11:59:10 -0400

Hi Mark,
> Supported-Vendor-Id AVP. This proposal keeps the TISPAN applications

I think the right term as I mentioned yesterday is that 'the content of 
vendor-id is deemed to be informational' from the base protocol point of 
view.
>  [RFC3232] value of the application vendor.

This text implies that the base protocol does some validity checking 
contrary to what I was mentioning yesterday. I'm beginning to think that 
these proposals are trying to cater to other SDOs rather than 
maintaining the sanity of the base protocol. I think extended text on 
how people treat Vendor-Id/Supported-Vendor-Id and what problems you 
need to deal with should be place in the app guide rather than bis.

regards,
victor

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 23 Aug 2007 12:11:23 -0400

Actually, after thinking a bit more, it started to make sense to me to
use different values for the Vendor-Id in CER/CEA and in
Vendor-Specific-Application-Id. 

In case of CER/CEA, it makes sense to use the Id of the device vendor.
For Vendor-Specific-Application-Id (although it is not really necessary
but for the sake of not changing the grammar) Id of the application
vendor can be used.

One approach could be 
a) Define Vendor-Id AVP itself lightly, i.e. "Vendor-Id AVP specifies
the identity of a vendor"
b) Provide information about what vendor identity needs to be used in
the corresponding messages/grouped AVPs, i.e.
i- CER/CEA, Vendor-Id AVP should contain vendor-Id of the device vendor
ii- Vendor-Specific-Application-Id, Vendor-Id AVP should contain
vendor-Id of the application vendor.

I agree with the general principle of considering anything in Vendor-Id
as informational. This should take care of any interoperability
problems, which could arise due to some checks etc...

   Thanks,
   Tolga

> Sent: Thursday, August 23, 2007 11:59 AM
> To: Mark Jones
> Cc: [email-masked]

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 23 Aug 2007 12:22:00 -0400

> messages according to that grammar. This breaks backward 

I read the Vendor-Id sub-AVP as being optional in the original 3588
ABNF:

  <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
                                     1* [ Vendor-Id ]
                                     0*1{ Auth-Application-Id }
                                     0*1{ Acct-Application-Id }

By contract, it is now a required, single value AVP in the latest
3588bis. 
Doesn't that break backwards compatibility?

> purpose according to RFC3588.

Looks like TISPAN actually assumed that this AVP was meant to indicate
"the manufacturer of the Diameter node". I don't follow TISPAN so can't
comment on why. Maybe it was the text about product, firmware and
debugging that tipped them off to its originally intended use.

> which you think would cause a problem?

As I mentioned, I don't follow TISPAN but here is the reference I was
passed:

ETSI TS 183 017: 6.6 Advertising application support

"Additonally, the AF and SPDF shall advertise the support of additional
Vendor-ID AVPs by including the value ETSI (13019) and 3GPP (10415) in
two different Supported-Vendor-Id AVPs of the CER and CEA commands."

So a peer implementing my previous proposal would not include the ETSI
vendor id in a Supported-Vendor-ID AVP and then existing Gq'
implementations would barf.

Regards
Mark

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 23 Aug 2007 12:30:08 -0400

Hi Mark,

> Sent: Thursday, August 23, 2007 12:22 PM
> To: Asveren, Tolga
> Cc: [email-masked]
[TOLGA]Please note the 1*. 1*[] actually means that to have at least a
single instance is mandatory. The change in the bis is just to use a
more appropriate notation for this.
> implementations would barf.
[TOLGA]Actually your real concern was about Vendor-Id AVP. Maybe we can
leave Supported-Vendor-Id AVP intact. For certain cases it could be
redundant but probably this is not a big deal.

---

From: "Harish R Prabhu" <[email-masked]>
Date: Thu, 23 Aug 2007 22:15:54 +0530

I think that *1 [Vendor-Id] is more appropriate than { Vendor-Id} in the
ABNF notation of the Vendor-Specific-Application-Id AVP. My understanding
and interpretation of Vendor-Specific-Appication-Id is that it is used to
identify an application which is authored by a specific Vendor (and not by
multiple vendors).

The Supported-Vendor-Id is used by a node to advertise to the peer that it
can support AVPs belonging to a specifi vendor (but does not imply any
applications from that vendor). In the light of this, its unrelated to this
discussion it should be left as-is.

My two cents.

regards,
Harish

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 23 Aug 2007 13:11:05 -0400

Tolga, Thanks for your continued input as we work through this.

> more appropriate notation for this.

Wouldn't *{} be the notation for "at least a single instance is
mandatory"?
To be honest, 1*[] looks like an oxymoron and [] means optional to me.

My notation confusion aside, if you insist that making Vendor-Id
optional will cause backwards compatibility reasons, I can live with it
being required as long as it is informational. 

> redundant but probably this is not a big deal.

There were two concerns in my original email. The second one concerns
where a peer would advertise support of the VSAs of the application
vendor: (a) Supported-Vendor-Id or (b) Vendor-Id sub-AVP. I still feel
this requires a normative statement in the 3588bis.

Regards
Mark

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 23 Aug 2007 13:11:09 -0400

Victor, Thanks for your continued input as we work through this.

> vendor-id is deemed to be informational' from the base 

I'm fine with that term. If changing it to optional creates backwards
compatibility issues then I'm OK if it remains required.

> need to deal with should be place in the app guide rather than bis.

I assume implementations would validate the Supported-Vendor-Id AVP
values against the vendor-specific dictionaries that they have
available. Wasn't that the intent?

I don't think this can go into the app design guide because it requires
a normative statement: either the application vendor's vendor-id goes in
the Vendor-Id sub-AVP or it goes in the Supported-Vendor-Id AVP. Sure
you can leave it undefined and let every vendor-specific application
specify their preferences but IMO this really is Base functionality so
it should be defined in 3588bis.

Regards
Mark

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 23 Aug 2007 13:30:07 -0400

Hi Mark,

> Sent: Thursday, August 23, 2007 1:11 PM
> To: Asveren, Tolga
> Cc: [email-masked]
[TOLGA]I agree that 1*[] isn't elegant, but this is the very reason why
it is changed to {}. Even with 1*[], what happens is that people check
for the existence of this AVP because of the 1*.
> this requires a normative statement in the 3588bis.
[TOLGA] Just to summarize (and to make sure that I didn't get anything
wrong), what we ideally want is:
CER
   Vendor-Id ==> device vendor
   Supported-Vendor-Id ==> vendor of the supported AVPs
   Vendor-Specific-Application-Id
               Vendor-Id ==> application vendor

IMHO, existing Supported-Vendor-Id AVP explanation in RFC3588 5.3.6
provides enough explanation for that type of usage. I asked whether it
makes sense to add some text to warn people about hop-by-hop nature of
CER/CEA but it is a different issue.

For Vendor-Id, with your proposed changes, the first use case of
Vendor-Id will be covered, we will use the Id of the device vendor.

For the second use case of Vendor-Id, we can either say 
that this information is anyhow redundant because application-Id space
is flat and there is no harm using Id of the device vendor 
OR
organize the text in a way where the content of the Vendor-Id is
specified at the sections where it is used, i.e. we can say that for
CER/CEA it is device vendor and when used in the
Vendor-Specific-Application-Id it is the application vendor.

And I think we shouldn't forget to mention that Vendor-Id is
informational, that would cover any type of interoperability issues.

So, AFAICS, we need to choose whether we want different values for
Vendor-Id depending on where it is used. I don't see any harm at doing
so.

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 23 Aug 2007 14:02:47 -0400

Hi Tolga,

Ok.

> vendor-Id of the application vendor.

I'm ok with this as long as ...

> problems, which could arise due to some checks etc...

... text meeting this criteria is meet. Beyond this, I don't think we 
need to add anything else in the bis.

regards,
victor

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 23 Aug 2007 14:11:02 -0400

Good summary Tolga, I think we're close. :)

 Vendor-Id ==> Device vendor
 Vendor-Specific-Application-Id
                Vendor-Id ==> not used during computation

So the Vendor-Id sub-AVP ABNF and text remain unchanged from 3588bis-06.

Now the ambiguous one: For TISPAN, the list of Supported-Vendor-Id AVPs
MUST include one containing the vendor id assigned to the application
vendor (ETSI in their case).

If we agree with TISPAN, we add a new paragraph to section 5.3.6:

If we disagree with TISPAN, where does the application vendor's
vendor-id go?

Regards
Mark

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 23 Aug 2007 14:10:23 -0400

Hi Mark,

> available. Wasn't that the intent?

Mmmm ... this is what I think should NOT be mandated in the bis. As I 
mentioned, the contents of this AVP is "for debugging and informational 
only" as far as the base protocol is concerned and therefore we should 
not assume anything.

> the Vendor-Id sub-AVP or it goes in the Supported-Vendor-Id AVP.

That's fine. Saying what the content should be is ok with me. Saying 
what processing would be done with the content is not ok.

regards,
victor

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 23 Aug 2007 14:29:50 -0400

Hi Mark,

> Sent: Thursday, August 23, 2007 2:11 PM
> To: Asveren, Tolga
> Cc: [email-masked]
[TOLGA]That is fine with me.
> If we disagree with TISPAN, where does the application vendor's
[TOLGA] Two points here:
a) If an application is advertised as supported, isn't it obvious that
the corresponding AVPs are supported as well? This makes me think that
Supported-Vendor-Id is more useful to signal support for optional vendor
specific AVPs, if the vendor is not the originator of the application.
b) What text does prevent people adding Supported-Vendor-Id AVP for such
a case? With the changes you proposed for the Vendor-Id, it will be
clear that it is supposed to contain the device vendor. And considering
the existing 5.3.6 text, people would use Supported-Vendor-Id to signal
support for vendor specific AVPs. Basically, I don't think the text you
propose for 5.3.6 is wrong, just it seems redundant to me (and MUST
seems to be strong for this case, current 5.3.6 text does not use any
IETF keywords).

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 23 Aug 2007 14:32:24 -0400

Hi Mark,

>    [RFC3232] value of the application vendor.

I'm still not convinced that putting this text in bis is proper. The bis 
is now starting to assume/imply some type validation processing between 
these AVPs, contradictory to its 'informational' status.

regards,
victor

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 23 Aug 2007 16:40:26 -0400

> these AVPs, contradictory to its 'informational' status.

I am not suggesting for a second that 3588bis should contain any hints
of what should be done with these AVPs. However, it also shouldn't leave
any doubt in the mind of an implementor about what value an AVP
contains. IMO it should be completely unnecessary for a vendor-specific
application specification to detail what vendor id values go into which
AVPs of the CER/CEA commands. Those are Base protocol commands and I
look to RFC3588 to define their content.

However, TISPAN had to describe that the ETSI vendor id goes in the
Supported-Vendor-Id AVP. IMO they should have been able to simply list
their application ids and vendor ids then refer implementors off to
RFC3588. This is not a 'design choice' so I don't think the Applications
Design Guidelines draft is the appropriate home for this.

It is also interesting to note Tolga's comment that "If an application
is advertised as supported, isn't it obvious that the corresponding AVPs
are supported as well". I thought so too but the answer doesn't get you
any closer to what goes in the Supported-Vendor-Id AVP. Maybe we think
it is obvious but ETSI didn't think so and other SDOs appear to be
divided on that question. 

Regards
Mark

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 23 Aug 2007 17:13:06 -0400

Hi Mark,

> Sent: Thursday, August 23, 2007 4:40 PM
> To: Victor Fajardo; Asveren, Tolga
> Cc: [email-masked]
[TOLGA] IMHO, a "Yes" answer provides some idea about what to put to
Supported-Vendor-Id AVP. In such a case, one would use
Supported-Vendor-Id to indicate support for optional vendor specific
AVPs, where vendor is not the vendor of the application, e.g. 3GPP
adding some optional AVPs to an IETF application. OTOH adding the Id of
the application vendor probably wouldn't hurt either, if one chooses to
do so.

I am also wondering what ETSI (and other SDOs) are planning to do with
Supported-Vendor-Id AVP. Do they define some semantics for it, e.g. if a
server does not support the extensions signaled in the
Supported-Vendor-Id it should reject the request. Any extension AVP has
to be optional, so what is the big deal about advertising support for
them in an AVP? What would be broken if it is not advertised or what
benefit does it provide to advertise it? Just include the optional AVPs
in the message and if they are not understood by the peer so be it (it
may be used only to save some bandwidth by not including certain vendor
defined optional AVPs AFAICS, and that is only after the first
transaction of the session). Overall I think Supported-Vendor-Id AVP is
not fit to enforce strong semantics. The more I think about it the more
it makes sense to emphasize its informational nature.

To me the explanation in RFC3588 5.3.6 is fine
    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 AVPs
   defined by the vendor identified in this AVP.

If there is a need for more explanation, that is O.K. IMHO as long as we
don't introduce strong rules about it.

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 23 Aug 2007 17:17:18 -0400

Hi Mark,

> look to RFC3588 to define their content.

This part is ok and your proposed changes to 5.5.3 and 6.11 should be 
enough.

> Design Guidelines draft is the appropriate home for this.

This is fine as well. But the proposed new paragraph in 5.3.6 is not 
related to this.

> divided on that question. 

Would'nt the proposed changes to 5.5.3 and 6.11 be enough ? IMHO, the 
proposed new paragraph in 5.3.6 goes beyond that since it requires which 
AVPs MUST be included in the CER/CEA.

My two cents,
-- victor

---

From: "Mark Jones" <[email-masked]>
Date: Fri, 24 Aug 2007 02:08:37 -0400

Hi Tolga,

>    defined by the vendor identified in this AVP.

But it doesn't clarify was whether the list of Supported-Vendor-Id AVPs
should include the vendor-id of the application vendor. That is all I'm
looking for.

> don't introduce strong rules about it.

Understood. My proposed text includes a MUST and I realize this is too
strong. I'll try to come up with new clause for the existing 5.3.6
paragraph (without any requirement keywords).

Regards
Mark

---

From: "Mark Jones" <[email-masked]>
Date: Fri, 24 Aug 2007 02:13:04 -0400

Hi Victor,

> This is fine as well. But the proposed new paragraph in 5.3.6 is not 

The 5.3.6 text was only meant to clarify was whether the list of
Supported-Vendor-Id AVPs should include the vendor-id of the
vendor-specific application vendor. It apparently has implications
beyond those I intended.
 
> AVPs MUST be included in the CER/CEA.

Now I think I understand your objection to my text: I have added a MUST
around presence of the Supported-Vendor-Id AVP in CER/CEA where none
existed before. Right?

So how about: 

   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 
   but including the vendor-specific application 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 AVPs defined by 
   the vendor identified in this AVP.

Regards
Mark

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 24 Aug 2007 08:02:43 -0400

Hi Mark,

>    the vendor identified in this AVP.

Looks much better :)

regards,
victor

---

From: "Mark Jones" <[email-masked]>
Date: Fri, 24 Aug 2007 08:31:39 -0400

> Looks much better :)

Thanks guys. 

Here is where we've ended up:

---

---

2) Update the first paragraph in section 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 
 but including the application 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 AVPs defined by the vendor 
 identified in this AVP.

---

---

Regards
Mark

---

From: Tom Taylor <[email-masked]>
Date: Fri, 24 Aug 2007 16:01:32 -0400

Just the tiniest nit: in that first paragraph the "may" in "may provide" is not 
an RFC 2119 "MAY": we're not telling anyone what they're allowed to do.  I'd 
also be happier to take out the "very" from "very useful" -- this is a standard 
rather than a sales brochure.

---

From: "Mark Jones" <[email-masked]>
Date: Fri, 24 Aug 2007 16:11:24 -0400

Thanks for reviewing the proposal Tom,

Both nits are with the original 3588 text but I'm ok with Tom's
suggestions.

Regards
Mark 

> From: Tom Taylor [mailto:[email-masked]] 
> Sent: August 24, 2007 22:02
> To: Mark Jones
> Cc: Victor Fajardo; Asveren, Tolga; [email-masked]