Subject: Re: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

From: Jari Arkko <[email-masked]>
Date: Sat, 01 May 2004 20:57:24 +0300

I agree with David on this one. In general, translation
between RADIUS and Diameter is dependent on the specific
application (such as NASREQ) that we are talking about.

--Jari

David Mitton wrote:
> On 4/30/2004 04:26 PM -0500, Christopher Richards wrote:
> 
>> Thanks Dave.
>>
>> Does the NASREQ draft apply to non-NASREQ Diameter applications?
>>
>> Specifically, RFC3588 does not say that RADIUS code 26 is prohibited.
>>
>> Should your description be added to the errata of RFC3588?
>>
>> Cheers,
>> Chris.
> 
> 
> No.
> 
> NASreq is intended to be the generic RADIUS "replacement" within Diameter.
> A RADIUS interaction such as VSAs is properly addressed there.
> 
> Even as it is, NASreq Section 9 does not explicitly address all 
> potential RADIUS interaction problems.  We are certainly not going to 
> backfill it into RFC 3588.
> 
> The Diameter drafts/RFCs are purposely segmented so that they may get 
> finished within our useful lifetimes.  Expect more application bolt-ons, 
> not less.
> 
> Dave. 
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 03 May 2004 22:55:30 +0300

Hmm... good question. Let me think... Well, it seems that
for this specific draft, the point is rather moot,
because there's currently nothing that DCC could be
translated into. When there is, then we can talk about
it, but as discussed previously on this list, the translation
would be in that other definition i.e. RADIUS prepaid and
not in DCC.

But your question is valid for other applications. Diameter
EAP, for instance, points to NASREQ for the general explanation
of the AVP mappings. This may be sufficient for other applications
as well.

--Jari

Christopher Richards wrote:
> Hi Jari,
> 
> OK. But does that mean that each application must describe how to handle 
> RADIUS VSA AVPs within the application? If so, DCC needs this description.
> 
> We could simply paste in the NASREQ statements into DCC.
> 
> Cheers,
> Chris.
> 
> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Saturday, May 01, 2004 12:57 PM
> To: David Mitton
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
> 
> 
> 
> between RADIUS and Diameter is dependent on the specific application 
> (such as NASREQ) that we are talking about.
> 
> --Jari
> 
> David Mitton wrote:
>  > NASreq is intended to be the generic RADIUS "replacement" within
>  > Diameter. A RADIUS interaction such as VSAs is properly addressed
>  > there.
>  >

---

From: "Christopher Richards" <[email-masked]>
Date: Mon, 3 May 2004 15:21:51 -0500

Hi Jari,

It's not just for translating AVPs on the fly, but also for how to re-use
existing RADIUS VSA AVPs.

I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that
I now want to use in Diameter. I want to avoid having to completely redefine
it.

From my reading of RFC3588, it says something along the lines that all AVP
codes 0 to 255 are reserved for RADIUS AVPs. From this I also took that
RADIUS AVP code 26 was included.

As an example, if you have access to 3GPP TS 29.061, take a look at the
RADIUS VSAs defined for 3GPP.

When I want to put this information into a Diameter AVP, do I set the
Vendor-ID flag or not?

Cheers,
Chris.

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Monday, May 03, 2004 2:56 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: David Mitton; [email-masked]
Subject: Re: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hmm... good question. Let me think... Well, it seems that
for this specific draft, the point is rather moot,
because there's currently nothing that DCC could be
translated into. When there is, then we can talk about
it, but as discussed previously on this list, the translation would be in
that other definition i.e. RADIUS prepaid and not in DCC.

But your question is valid for other applications. Diameter EAP, for
instance, points to NASREQ for the general explanation of the AVP mappings.
This may be sufficient for other applications as well.

--Jari

Christopher Richards wrote:
> I agree with David on this one. In general, translation between RADIUS 
> and Diameter is dependent on the specific application (such as NASREQ) 
> that we are talking about.
> 
> --Jari
> 
> David Mitton wrote:
> >>  >> Specifically, RFC3588 does not say that RADIUS code 26 is 
> prohibited.  >>

---

From: <[email-masked]>
Date: Tue, 4 May 2004 11:52:52 +0300

Hi Chris,

>It's not just for translating AVPs on the fly, but also for how to re-use existing RADIUS 
>VSA AVPs. 
>I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that I now want to 
>use in Diameter. I want avoid having to completely redefine it.
>From my reading of RFC3588, it says something along the lines that all AVP codes 0 to 255 
>are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26 was included.
>As an example, if you have access to 3GPP TS 29.061, take a look at the RADIUS VSAs defined >for 3GPP. 

>When I want to put this information into a Diameter AVP, do I set the Vendor-ID flag or not?

as Dave pointed out the NASREQ is intended to be the generic RADIUS replacement within Diameter. If you just use the NASREQ defined AVPs, that practically uses those AVP numbers from 1 through 255 you're talking about, you should be able to match the 3GPP TS 29.061 needs.

For those 3gpp vendor-specific attributes defined in TS 29.061 I think you should follow
the rules defined in NASREQ section 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit is to be set. 
I copied here sect. 9.4 of the NASREQ draft, that clearly state that attribute code 26 must not appear in Diameter messages.

Regards
Marco

9.4 Prohibited RADIUS Attributes

   The following RADIUS attributes MUST NOT appear in a Diameter
   message.  Instead, they are translated to other Diameter AVPs or
   handled in some special manner. The rules for the treatment of the
   attributes are discussed in Sections 9.1, 9.2 and 9.6.

   Attribute Description       Defined     Nearest Diameter AVP
   -----------------------------------------------------------------
    3 CHAP-Password            RFC 2865    CHAP-Auth Group
   26 Vendor-Specific          RFC 2865    Vendor Specific AVP
   29 Termination-Action       RFC 2865    Authorization-Lifetime
   40 Acct-Status-Type         RFC 2866    Accounting-Record-Type
   42 Acct-Input-Octets        RFC 2866    Accounting-Input-Octets
   43 Acct-Output-Octets       RFC 2866    Accounting-Output-Octets
   47 Acct-Input-Packets       RFC 2866    Accounting-Input-Packets
   48 Acct-Output-Packets      RFC 2866    Accounting-Output-Packets
   49 Acct-Terminate-Cause     RFC 2866    Termination-Cause
   52 Acct-Input-Gigawords     RFC 2869    Accounting-Input-Octets
   53 Acct-Output-Gigawords    RFC 2869    Accounting-Output-Octets
   80 Message-Authenticator    RFC 2869    none - check and discard

---

From: <[email-masked]>
Date: Fri, 7 May 2004 10:46:36 +0300

Hi Chris,
 
Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g.
 
When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute.
 
I better see this kind of text in section 4.1, perhaps slightly modified as follow:
 
When service specific documents include RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] ..........etc.
 
Regards
Marco

-----Original Message-----
From: ext Christopher Richards [mailto:[email-masked]]
Sent: 04 May, 2004 17:53
To: Stura Marco (Nokia-NET/Helsinki)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Marco, 

Thanks for the clarification. 

Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g.

When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute.

I think it will save confusion in the future. 

Cheers, 
Chris. 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]] 
Sent: Tuesday, May 04, 2004 3:53 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked] 
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs 

Hi Chris, 

For those 3gpp vendor-specific attributes defined in TS 29.061 I think you should follow the rules defined in NASREQ section 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit is to be set. 

Regards 
Marco

---

From: "Christopher Richards" <[email-masked]>
Date: Fri, 7 May 2004 14:51:09 -0500

Marco,
 
That sounds good. Thanks.

Cheers, 
Chris. 

Shasta Wireless Development 
Nortel Networks 

Telephone: 
+1 972 684 3281 
ESN 444 3281 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, May 07, 2004 2:47 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Chris,
 
Since it is not terribly clear that other Diameter applications should
follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I
think it would be beneficial if some statement was added to DCC section 8.
E.g.
 
When including RADIUS vendor specific attributes in a DCC message, the rules
described in [NASREQ] for formatting the Diameter AVP MUST be followed. For
example, the AVP code used is the vendor attribute type code, the
Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the
IANA Vendor identification value. The Diameter AVP data field contains only
the attribute value of the RADIUS attribute.
 
I better see this kind of text in section 4.1, perhaps slightly modified as
follow:
 
When service specific documents include RADIUS vendor specific attributes in
a DCC message, the rules described in [NASREQ] ..........etc.
 
Regards
Marco

-----Original Message-----
From: ext Christopher Richards [mailto:[email-masked]]
Sent: 04 May, 2004 17:53
To: Stura Marco (Nokia-NET/Helsinki)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Marco, 

Since it is not terribly clear that other Diameter applications should
follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I
think it would be beneficial if some statement was added to DCC section 8.
E.g.

When including RADIUS vendor specific attributes in a DCC message, the rules
described in [NASREQ] for formatting the Diameter AVP MUST be followed. For
example, the AVP code used is the vendor attribute type code, the
Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the
IANA Vendor identification value. The Diameter AVP data field contains only
the attribute value of the RADIUS attribute.

Cheers, 
Chris. 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, May 04, 2004 3:53 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH] 
Cc: [email-masked]; [email-masked]; [email-masked] 
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs 

Hi Chris, 

>I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that
I now want to 
>From my reading of RFC3588, it says something along the lines that all AVP
codes 0 to 255 
>As an example, if you have access to 3GPP TS 29.061, take a look at the
RADIUS VSAs defined >for 3GPP. 

>When I want to put this information into a Diameter AVP, do I set the 

as Dave pointed out the NASREQ is intended to be the generic RADIUS
replacement within Diameter. If you just use the NASREQ defined AVPs, that
practically uses those AVP numbers from 1 through 255 you're talking about,
you should be able to match the 3GPP TS 29.061 needs.

For those 3gpp vendor-specific attributes defined in TS 29.061 I think you
should follow the rules defined in NASREQ section 9.6.2, RADIUS
Interactions. According to the mentioned rules the V bit is to be set. 

I copied here sect. 9.4 of the NASREQ draft, that clearly state that
attribute code 26 must not appear in Diameter messages.

Regards 
Marco

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 24 May 2004 16:48:48 +0100

Hi all,
 
So, this rule will apply to NASREQ and DCC, but other applications are free
to do whatever they like ?
 
That is, the AVP code codespace when the Vendor-specific flag is set to 1 is
application-specific. The same code may mean different things in different
applications. This is unlike the AVP code codespace when the Vendor-specific
flag is 0, right ?
 
Would it be better to (also) have a rule for all applications, or at least
an 'opt out' rule such as 'unless otherwise specified in a specific
application....' ?
 
Regards...Mark

-----Original Message-----
From: Richards, Christopher [RICH2:2Q40:EXCH] 
Sent: 07 May 2004 20:51
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Marco,

Cheers, 
Chris. 

Telephone: 
+1 972 684 3281 
ESN 444 3281 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, May 07, 2004 2:47 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Chris,

 

Regards
Marco

-----Original Message-----
From: ext Christopher Richards [mailto:[email-masked]]
Sent: 04 May, 2004 17:53
To: Stura Marco (Nokia-NET/Helsinki)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Marco, 

Cheers, 
Chris. 

-----Original Message----- 

Hi Chris, 

I now want to 
codes 0 to 255 

Regards 
Marco

---

From: David Mitton <[email-masked]>
Date: Mon, 24 May 2004 12:49:52 -0400

On 5/24/2004 04:48 PM +0100, Mark Watson wrote:

Hi
all,

So, this rule will apply to
NASREQ and DCC, but other applications are free to do whatever they like
?

I would think, (subject to any dissent from the group) that any Diameter
application that interacts with RADIUS, would adhere to the
specifications in Diameter-NASreq as it's base.  Any exceptions
would have to be justified and dealt with when the specification was
reviewed.

The Diameter Base (RFC3588) specification would be too unwieldy to cover
all issues, and parts out certain problems to other specifications.
RADIUS interfacing is another one of these.

Dave.

That is, the AVP code
codespace when the Vendor-specific flag is set to 1 is
application-specific. The same code may mean different things in
different applications. This is unlike the AVP code codespace when the
Vendor-specific flag is 0, right ?

Would it be better to (also)
have a rule for all applications, or at least an 'opt out' rule such as
'unless otherwise specified in a specific application....' ?

Regards...Mark

-----Original Message-----

Sent: 07 May 2004 20:51

Cc: [email-masked]; [email-masked];
[email-masked]

Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA
AVPs

Marco,

That sounds good.
Thanks.

Cheers,

Chris.

Nortel Networks

Telephone:

+1 972 684 3281

ESN 444 3281

-----Original Message-----

Hi Chris,

Regards

Marco

-----Original Message-----

Sent: 04 May, 2004 17:53

Hi Marco,

Cheers,

Chris.

-----Original Message-----

Hi Chris,

>It's not just for translating AVPs on the fly, but also for how to

>re-use existing RADIUS

Regards

Marco

---

From: David Mitton <[email-masked]>
Date: Mon, 24 May 2004 14:53:47 -0400

On 5/24/2004 06:04 PM +0100, Mark Watson wrote:

Hi
David,

I am not so much thinking of
applications which directly interact with RADIUS as cases where new
applications are defined and have a requirement to carry some information
for which a RADIUS VSA sub-attribute has already been defined (perhaps by
a standardisation organisation, rather than a specific
vendor).

VSAs were not intended to be used by other SDOs to extend the
protocol.

I'm not aware of such use being approved by an IETF WG.

RADIUS does not have an "application identifier".  Any VSA
encodings are assumed to be singular, that is not overlapped in any
way.  Most RADIUS server implementations use a flat static
dictionary to describe attributes including VSAs.

There's a difference between application dependent semantics, and the
actual message encoding.  While it may essential to treat the
contents of an AVP differently in different application contexts, the
parsing of the message fields must be mechanical for
interoperability.

I'm not sure why an application dependent transformation in Diameter is
desirable.   Certainly there is enough encoding space to work
around any legacy encodings.

I guess I could see some rationale, but it's not something that we'd want
to standardize.  These types of cases are to be avoided.  It
causes more complexity in proxy agents and gateways.  NASes might
need to deal with two types of responses or worse yet make two different
types of requests.

On the basis that re-use is
better than re-invention, it would be nice if such applications could
re-use the RADIUS VSA sub-attribute definition, even if there is no
actual RADIUS interaction involved.

In the development of Diameter, we choose to change a number of things
about RADIUS that were problematic.  VSAs were one of
these.   If you are going through the trouble of implementing a
Diameter application, why not use the native Diameter
encoding?

Likewise the purpose of having one encoding is for the interoperability
that results from not having to define/implement more
exceptions.   Even if that interoperability is not used..
initially.

Comments ?

Another way to put my
question would be, is it wise for a Diameter implementation to assume
that AVP x with Vendor-ID y always corresponds to the same AVP,
independent of the application.

It should.

Or
would it be wiser to assume that the meaning of (AVP x, Vendor y) is
application-dependent ? The current specification situation suggests the
latter, but I am not sure that is the intention.

...Mark

I'm not sure why, but we could put that on the errata/"bis"
list.

Even though the use of Diameter AVPs are application dependant, their
encoding is coordinated across the Diameter encoding space so there is no
overlap.

Could you point to the text in RFC 3588 that gave the impression that VSA
AVPs are different?

Dave.

-----Original Message-----

From: David Mitton
[mailto:[email-masked]]

Sent: 24 May 2004 17:50

To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher
[RICH2:2Q40:EXCH]; [email-masked]

Cc: [email-masked]; [email-masked]

Hi all,

So, this rule will apply
to NASREQ and DCC, but other applications are free to do whatever they
like ?

I would think, (subject to any dissent from the group) that any
Diameter application that interacts with RADIUS, would adhere to the
specifications in Diameter-NASreq as it's base.  Any exceptions
would have to be justified and dealt with when the specification was
reviewed.

The Diameter Base (RFC3588) specification would be too unwieldy to
cover all issues, and parts out certain problems to other
specifications.  RADIUS interfacing is another one of
these.

Dave.

That is, the AVP code

Would it be better to
(also) have a rule for all applications, or at least an 'opt out' rule
such as 'unless otherwise specified in a specific application....'
?

Regards...Mark

-----Original Message-----

Sent: 07 May 2004 20:51

Marco,

That sounds good.
Thanks.

Cheers,

Chris.

Nortel Networks

Telephone:

+1 972 684 3281

ESN 444 3281

-----Original Message-----

From: [email-masked]
[mailto:[email-masked]]

Hi Chris,

Since it is not terribly clear that other Diameter
applications should follow the NASREQ specification when encoding RADIUS
vendor specific AVPs, I think it would be beneficial if some statement
was added to DCC section 8. E.g.

When including RADIUS vendor specific attributes in a
DCC message, the rules described in [NASREQ] for formatting the Diameter
AVP MUST be followed. For example, the AVP code used is the vendor
attribute type code, the Vendor-Specific flag MUST be set to 1 and the
Vendor-ID MUST be set to the IANA Vendor identification value. The
Diameter AVP data field contains only the attribute value of the RADIUS
attribute.

I better see this kind of
text in section 4.1, perhaps slightly modified as follow:

When service specific
documents include RADIUS vendor specific attributes in a DCC message, the
rules described in [NASREQ] ..........etc.

Regards

Marco

-----Original Message-----

From: ext Christopher Richards
[mailto:[email-masked]]

Sent: 04 May, 2004 17:53

Hi Marco,

Since it is not terribly clear that other Diameter
applications should follow the NASREQ specification when encoding RADIUS
vendor specific AVPs, I think it would be beneficial if some statement
was added to DCC section 8. E.g.

When including RADIUS vendor specific attributes in a
DCC message, the rules described in [NASREQ] for formatting the Diameter
AVP MUST be followed. For example, the AVP code used is the vendor
attribute type code, the Vendor-Specific flag MUST be set to 1 and the
Vendor-ID MUST be set to the IANA Vendor identification value. The
Diameter AVP data field contains only the attribute value of the RADIUS
attribute.

Cheers,

Chris.

-----Original Message-----

Hi Chris,

Regards

Marco

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 24 May 2004 20:18:18 +0100

Hi Dave,
 
Ok, so you have answered my question: you think the AVP codes for use with a
given vendor id are taken from a single codespace, which is independent of
application. Therefore values 0-255 are identified with RADIUS VSA
sub-attributes for the same vendor id. Someone could think differently
because the identity between the Diameter vendor-specific AVP codespace and
the RADIUS VSA sub-attribute codespace is only defined in Diameter NASREQ
and CC, not base.
 
Personally, I think your view is the simplest. But now I know of at least
one 'vendor' which has a problem.
 
3GPP has been allocated a vendor ID by IANA and has defined a number of
RADIUS VSA sub-attributes and Diameter AVPs in the resulting codespace.

Regards...Mark

-----Original Message-----
From: David Mitton [mailto:[email-masked]] 
Sent: 24 May 2004 19:54
To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher [RICH2:2Q40:EXCH];
[email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi David,
 
I am not so much thinking of applications which directly interact with
RADIUS as cases where new applications are defined and have a requirement to
carry some information for which a RADIUS VSA sub-attribute has already been
defined (perhaps by a standardisation organisation, rather than a specific
vendor).

VSAs were not intended to be used by other SDOs to extend the protocol.
I'm not aware of such use being approved by an IETF WG.

RADIUS does not have an "application identifier".  Any VSA encodings are
assumed to be singular, that is not overlapped in any way.  Most RADIUS
server implementations use a flat static dictionary to describe attributes
including VSAs.  

There's a difference between applicati  on dependent semantics, and the
actual message encoding.  While it may essential to treat the contents of an
AVP differently in different application contexts, the parsing of the
message fields must be mechanical for interoperability.

I'm not sure why an application dependent transformation in Diameter is
desirable.   Certainly there is enough encoding space to work around any
legacy encodings.

I guess I could see some rationale, but it's not something that we'd want to
standardize.  These types of cases are to be avoided.  It causes more
complexity in proxy agents and gateways.  NASes might need to deal with two
types of responses or worse yet make two different types of requests.

On the basis that re-use is better than re-invention, it would be nice if
such applications could re-use the RADIUS VSA sub-attribute definition, even
if there is no actual RADIUS interaction involved.

In the development of Diameter, we choose to change a number of things about
RADIUS that were problematic.  VSAs were one of these.   If you are going
through the trouble of implementing a Diameter application, why not use the
native Diameter encoding?   

Likewise the purpose of having one encoding is for the interoperability that
results from not having to define/implement more exceptions.   Even if that
interoperability is not used.. initially.

Comments ?
 
Another way to put my question would be, is it wise for a Diameter
implementation to assume that AVP x with Vendor-ID y always corresponds to
the same AVP, independent of the application. 

It should.  

Or would it be wiser to assume that the meaning of (AVP x, Vendor y) is
application-dependent ? The current specification situation suggests the
latter, but I am not sure that is the intention.
 
...Mark

I'm not sure why, but we could put that on the errata/"bis" list.

Dave.

-----Original Message-----

From: David Mitton [mailto:[email-masked] <mailto:[email-masked]> ] 

Sent: 24 May 2004 17:50

To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher [RICH2:2Q40:EXCH];
[email-masked]

Hi all,

I would think, (subject to any dissent from the group) that any Diameter
application that interacts with RADIUS, would adhere to the specifications
in Diameter-NASreq as it's base.  Any exceptions would have to be justified
and dealt with when the specification was reviewed.

The Diameter Base (RFC3588) specification would be too unwieldy to cover all
issues, and parts out certain problems to other specifications.  RADIUS
interfacing is another one of these.

Dave.

  

  

Regards...Mark

-----Original Message----- 

Sent: 07 May 2004 20:51 

Marco,

Cheers, 

Chris. 

Nortel Networks 

Telephone: 

+1 972 684 3281 

ESN 444 3281 

-----Original Message----- 

Hi Chris,

Regards 

Marco 

-----Original Message----- 

From: ext Christopher Richards [mailto:[email-masked]
<mailto:[email-masked]> ] 

Sent: 04 May, 2004 17:53 

Hi Marco, 

Cheers, 

Chris. 

-----Original Message----- 

Hi Chris, 

I now want to 

codes 0 to 255 

Regards 

Marco

---

From: <[email-masked]>
Date: Tue, 25 May 2004 09:18:33 +0300

> Perhaps it would make sense to more clearly label the 
> universal aspects
> within the NASREQ specification, and maybe even note that it 
> "updates RFC
> 3588" in those respects.

I support this approach, it would certainly help.

Marco

> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 24 May, 2004 21:32
> To: Mark Watson
> Cc: 'David Mitton'; Christopher Richards; Stura Marco
> (Nokia-NET/Helsinki); [email-masked]'; [email-masked]'
> Certain aspects of RADIUS/Diameter gateway interaction are valid for
> *all* Diameter applications.  Others are specific to a given 
> application.
> 
> Perhaps it would make sense to more clearly label the 
> universal aspects
> within the NASREQ specification, and maybe even note that it 
> "updates RFC
> 3588" in those respects.
> 
> 
> On Mon, 24 May 2004, Mark Watson wrote:
> 
> > Hi David,
> >
> > the same AVP, independent of the application. Or would it 
> be wiser to assume
> > that the meaning of (AVP x, Vendor y) is 
> application-dependent ? The current
> > specification situation suggests the latter, but I am not 
> sure that is the
> > intention.
> >
> > ...Mark
> >
> specifications
> applications should
> applications should
> > >are reserved for RADIUS AVPs. From this I also took that 
> RADIUS AVP code 26
> > was included.
> >
> >

---

From: <[email-masked]>
Date: Tue, 25 May 2004 09:23:07 +0300

>Or would it be wiser to assume that the meaning of (AVP x, Vendor y) is application-dependent ? The current
 >specification situation suggests the latter, but I am not sure that is the intention.

>Even though the use of Diameter AVPs are application dependant, their encoding is coordinated across the Diameter 
>encoding space so there is no overlap.
>Could you point to the text in RFC 3588 that gave the impression that VSA AVPs are different?
 
Personally I cannot find such a text that causes this kind of confusion.
If we take the approach suggested by Bernard (i.e. clearly label the universal aspects within the NASREQ specification),
perhaps we could clarify this apsect in NASREQ as well.
 
Marco

-----Original Message-----
From: ext David Mitton [mailto:[email-masked]]
Sent: 24 May, 2004 21:54
To: Mark Watson; Christopher Richards; Stura Marco (Nokia-NET/Helsinki)
Cc: [email-masked]'; [email-masked]'
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi David,
 
I am not so much thinking of applications which directly interact with RADIUS as cases where new applications are defined and have a requirement to carry some information for which a RADIUS VSA sub-attribute has already been defined (perhaps by a standardisation organisation, rather than a specific vendor).

RADIUS does not have an "application identifier".  Any VSA encodings are assumed to be singular, that is not overlapped in any way.  Most RADIUS server implementations use a flat static dictionary to describe attributes including VSAs.  

There's a difference between application dependent semantics, and the actual message encoding.  While it may essential to treat the contents of an AVP differently in different application contexts, the parsing of the message fields must be mechanical for interoperability.

I'm not sure why an application dependent transformation in Diameter is desirable.   Certainly there is enough encoding space to work around any legacy encodings.

I guess I could see some rationale, but it's not something that we'd want to standardize.  These types of cases are to be avoided.  It causes more complexity in proxy agents and gateways.  NASes might need to deal with two types of responses or worse yet make two different types of requests.

On the basis that re-use is better than re-invention, it would be nice if such applications could re-use the RADIUS VSA sub-attribute definition, even if there is no actual RADIUS interaction involved.

In the development of Diameter, we choose to change a number of things about RADIUS that were problematic.  VSAs were one of these.   If you are going through the trouble of implementing a Diameter application, why not use the native Diameter encoding?   

Likewise the purpose of having one encoding is for the interoperability that results from not having to define/implement more exceptions.   Even if that interoperability is not used.. initially.

Comments ?
 
Another way to put my question would be, is it wise for a Diameter implementation to assume that AVP x with Vendor-ID y always corresponds to the same AVP, independent of the application. 

It should.  

Or would it be wiser to assume that the meaning of (AVP x, Vendor y) is application-dependent ? The current specification situation suggests the latter, but I am not sure that is the intention.
 
...Mark

Even though the use of Diameter AVPs are application dependant, their encoding is coordinated across the Diameter encoding space so there is no overlap.
Could you point to the text in RFC 3588 that gave the impression that VSA AVPs are different?

Dave.

-----Original Message-----

From: David Mitton [ mailto:[email-masked]] 

Sent: 24 May 2004 17:50

To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]

Hi all,

So, this rule will apply to NASREQ and DCC, but other applications are free to do whatever they like ?

I would think, (subject to any dissent from the group) that any Diameter application that interacts with RADIUS, would adhere to the specifications in Diameter-NASreq as it's base.  Any exceptions would have to be justified and dealt with when the specification was reviewed.

The Diameter Base (RFC3588) specification would be too unwieldy to cover all issues, and parts out certain problems to other specifications.  RADIUS interfacing is another one of these.

Dave.

That is, the AVP code codespace when the Vendor-specific flag is set to 1 is application-specific. The same code may mean different things in different applications. This is unlike the AVP code codespace when the Vendor-specific flag is 0, right ?

Would it be better to (also) have a rule for all applications, or at least an 'opt out' rule such as 'unless otherwise specified in a specific application....' ?

Regards...Mark

-----Original Message----- 

Sent: 07 May 2004 20:51 

Marco,

Cheers, 

Chris. 

Nortel Networks 

Telephone: 

+1 972 684 3281 

ESN 444 3281 

-----Original Message----- 

Hi Chris,

Regards 

Marco 

-----Original Message----- 

From: ext Christopher Richards [ mailto:[email-masked]] 

Sent: 04 May, 2004 17:53 

Hi Marco, 

Cheers, 

Chris. 

-----Original Message----- 

Hi Chris, 

Regards 

Marco

---

From: Avi Lior <[email-masked]>
Date: Tue, 25 May 2004 10:40:00 -0400

David,
 
Where does it say that VSAs were not intended to be used by other SDOs to
extend the protocol?
 
Some folks even talked about using Type 26 with Vendor Id of  0 to allow the
IETF to extend RADIUS attributes just in case we ran out of RADIUS
attributes.
 
IMO it make alot of sense to allow SDOs to extend RADIUS or even Diameter in
cases where they dont care about interoperability and thus don't need to cut
RFCs for their work.
 
Avi. 

-----Original Message-----
From: David Mitton [mailto:[email-masked]] 
Sent: Monday, May 24, 2004 2:54 PM
To: Mark Watson; Christopher Richards; [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi David,

There's a difference between application dependent semantics, and the actual
message encoding.  While it may essential to treat the contents of an AVP
differently in different application contexts, the parsing of the message
fields must be mechanical for interoperability.

Comments ?

It should.  

...Mark

Dave.

-----Original Message-----

Sent: 24 May 2004 17:50

Hi all,

Dave.

  

  

Regards...Mark

-----Original Message----- 

Sent: 07 May 2004 20:51 

Marco,

Cheers, 

Chris. 

Nortel Networks 

Telephone: 

+1 972 684 3281 

ESN 444 3281 

-----Original Message----- 

Hi Chris,

Regards 

Marco 

-----Original Message----- 

Sent: 04 May, 2004 17:53 

Hi Marco, 

Cheers, 

Chris. 

-----Original Message----- 

Hi Chris, 

I now want to 

codes 0 to 255 

Regards 

Marco

---

From: <[email-masked]>
Date: Tue, 25 May 2004 20:03:50 +0300

Avi,

> Where does it say that VSAs were not intended to be used by other SDOs to extend the protocol?

clip ..

> IMO it make alot of sense to allow SDOs to extend RADIUS or even Diameter in cases where they dont 
> care about interoperability and thus don't need to cut RFCs for their work.

SDO I thought stood for Standardization Developement Organzition - the reason behind SDOs
were for creating interoperation between vendors.  Vendors, last time I checked, were
generally classified as "someone who exchanges goods or services for money" - which seems
to be different than what an SDO is. 

YMMV,
John

---

From: Avi Lior <[email-masked]>
Date: Tue, 25 May 2004 13:11:10 -0400

Interoperability between other SDOs that is.

At the SDOs vendors get together and agree on how to interoperate amognst
themselves.  In the case of 3GPP2 they develop 3GPP2 specific VSAs.  In this
case 3GPP2 can be viewed as super-vendor.

The alternative is not to do this and take everything to the IETF.  So do
you really think that the IETF has the cycles to address all the AAA
requirements of all SDOs?  Cause I don't.

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, May 25, 2004 1:04 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> > Where does it say that VSAs were not intended to be used by 
> other SDOs 
> > to extend the protocol?
> 
> clip ..
> 
> SDO I thought stood for Standardization Developement 
> Organzition - the reason behind SDOs were for creating 
> interoperation between vendors.  Vendors, last time I 
> checked, were generally classified as "someone who exchanges 
> goods or services for money" - which seems to be different 
> than what an SDO is. 
> 
> YMMV,
> John
>

---

From: "Adrangi, Farid" <[email-masked]>
Date: Tue, 25 May 2004 13:31:47 -0700

Sorry for jumping in this ...  

IMO, taking all VSAs defined within an SDO to IETF for standardization
may not be a practical thing to do as Avi stated. Rather, the idea
should be to identify VSAs that are commonly defined across SDOs (same
in concept, but different in format/syntax and perhaps content) or VSAs
that can be used by other SDOs and standardize them at IETF.  To best of
my knowledge, VSAs defined within an SDO are intended to provide "intra"
interoperability (i.e., amongst the SDO's vendors).
BR,
Farid

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Avi Lior
> Sent: Tuesday, May 25, 2004 10:11 AM
> To: [email-masked]'; Avi Lior; [email-masked]; 
> At the SDOs vendors get together and agree on how to 
> interoperate amognst themselves.  In the case of 3GPP2 they 
> develop 3GPP2 specific VSAs.  In this case 3GPP2 can be 
> viewed as super-vendor.
> 
> The alternative is not to do this and take everything to the 
> IETF.  So do you really think that the IETF has the cycles to 
> address all the AAA requirements of all SDOs?  Cause I don't.
>

---

From: <[email-masked]>
Date: Wed, 26 May 2004 13:34:22 +0300

Jari & Bernard,

> I believe this is the crux of the problem -- the bits are
> different, and not just the official status of the extension.
> If you add a difference in expressive power (in either
> direction) and significant timeliness differences, this
> brings even greater problems.
> 
> Where does that leave us? I think we need
> 
>    (a) Vendors and SDOs doing their own things in
>        an easy manner, without having to bring everything
>        to the IETF.
> 
>    (b) IETF specialist assistance in the above, where
>        needed.
> 
>    (c) Migration towards the same expressive power and
>        technical solutions whether its IETF standard,
>        other SDO standard, or vendor specific solution.
> 
>    (d) Recognition that some of the solutions originally
>        intended as an SDO-internal mechanism end up being
>        a global interoperability issue. Example: replacement
>        of FOOBAR SDO radio with wireless LANs, and expecting
>        mobility or something like that to still work. Another
>        example: developing a SDO specific multimedia network,
>        and then later realizing the need for that network
>        to interoperate with another SDO's multimedia network.

We probably need one (or two things) more:

	(e) Guidelines on Diameter & RADIUS extensiblitity.  I think
  	    someone already mentioned that a guideline (or BCP) on how
 	    to define Diameter applications would be a good thing.

John

---

From: Avi Lior <[email-masked]>
Date: Wed, 26 May 2004 16:34:27 -0400

>  	    to define Diameter applications would be a good thing.

I agree (and it was me)
Avi

---

From: "Nelson, David" <[email-masked]>
Date: Thu, 27 May 2004 12:02:10 -0400

Avi Lior writes...
 
> by other SDOs to extend the protocol?

This is a discussion that we have been holding on the RADEXT mailing list.  Unfortunately, it doesn't explicitly say this anywhere that I'm aware of.  I say unfortunately, since it has caused some problems.  If anyone is interested, peruse the archives of the RADEXT list.  IMHO, it is implicit in the term "Vendor Specific", meaning specific to a particular implementation of a particular vendor.  The context for this interpretation exists in the history of the RADIUS WG.  It was always intended that attributes for general usage (i.e. multi-vendor interoperability) would be in the standard attribute ID space.  I don't believe there was ever consensus in the RADIUS WG that VSAs would be a "standard" method to extend the protocol.

> Some folks even talked about using Type 26 with Vendor Id of 
> 0 to allow the IETF to extend RADIUS attributes just in case 
> we ran out of RADIUS attributes.

That has been suggested.  I don't know if there is any substantial support at this point.
 
> IMO it make a lot of sense to allow SDOs to extend RADIUS or 
> even Diameter in cases where they don't care about interoperability
> and thus don't need to cut RFCs for their work.

IMHO, the phrases "SDO" and "don't care about interoperability" are oxymoronic.  I would have expected that interoperability would have been one of the primary objectives of any standard, no?  :-)

-- Dave

---

From: Avi Lior <[email-masked]>
Date: Thu, 27 May 2004 13:33:31 -0400

> From: Nelson, David [mailto:[email-masked]] 
> Sent: Thursday, May 27, 2004 12:02 PM
> To: [email-masked]
> David Nelson wrote:

>I don't believe there was ever consensus 
> in the RADIUS WG that VSAs would be a "standard" method to 
> extend the protocol.

Can you show me where this was even discussed in the RADIUS WG? 
If you can't then you would be misleading the crowd.
  
> IMHO, the phrases "SDO" and "don't care about 
> interoperability" are oxymoronic.  I would have expected that 
> interoperability would have been one of the primary 
> objectives of any standard, no?  :-)

Obviously SDO care about standards.

But perhaps there are several scopes for interoperability.  One scope is
global scope, another is within a domain such as a domain controlled by an
SDO.

Avi

---

From: Avi Lior <[email-masked]>
Date: Thu, 27 May 2004 16:26:36 -0400

I think when someone makes a statement such as: "... there was ever
consensus in the RADIUS WG"  that statement should not be based on someone's
"personal experience".

To me the above statement implies that there was official discussion in an
open forum (mail list, in the meetings). But maybe my interpretation is
wrong.

> On the other hand, I think that the 
> term "Vendor-Specific" is sufficiently self-describing.  You 
> have alluded to SDOs as "Super-Vendors", and I think that 
> stretches the notion of "vendor" to the point of being meaningless.

Vendor could be an organization right?

Avi

> Sent: Thursday, May 27, 2004 3:43 PM
> To: [email-masked]
> > > in the RADIUS WG that VSAs would be a "standard" method 
> to  extend 
> > >the protocol.
> > 
> Well, I haven't undertaken a search of the RADIUS WG 
> archives, but my statements are not based on the "written 
> history".  My statements are based on my personal experience. 
>  I was active in the RADIUS WG from the initial BOFs.  I have 
> already stipulated that these items of context never made 
> their way into the RFCs.  On the other hand, I think that the 
> term "Vendor-Specific" is sufficiently self-describing.  You 
> have alluded to SDOs as "Super-Vendors", and I think that 
> stretches the notion of "vendor" to the point of being meaningless.
> 
> That's a rather unfounded assertion.  I am providing historic 
> context, from first hand personal observation.  I have not 
> represented it as documented fact.  However, first hand 
> personal observation is permissible under the rules of 
> evidence in a court of law.  I therefore take exception to 
> the assertion that my intent is to mislead.  You are 
> certainly free to question the accuracy of my memory, if you 
> so choose.
> 
> -- Dave
> 
>

---

From: "Nelson, David" <[email-masked]>
Date: Thu, 27 May 2004 17:06:14 -0400

Avi Lior writes...
 
> open forum (mail list, in the meetings).

I'm giving you my recollection of discussion that took place during
meetings and/or on the mailing list.  Please don't attempt to pin me
down to names and dates.  :-(

> Vendor could be an organization right?

I would not have thought so.  There exceptional cases, of course, with
"Open Source" consortia being the most obvious, but I can't think of any
organization (read SDO or consortium) from which I can purchase product
(my definition of "vendor").

At this point, I'll offer two observations.

1.) This thread is duplicating discussions we've held (and will continue
to hold) on the RADEXT mailing list.

2.) There are unresolved interoperability issues here, and all the
debate just underscores the need for some more specific "rules" or
guidance in this area.  Legalistic wrangling about why a given design
approach "isn't prohibited" is not nearly as productive as pointing out
why that design approach has technical merit that other approaches do
not have.

-- Dave

---

From: Avi Lior <[email-masked]>
Date: Thu, 27 May 2004 19:32:25 -0400

> That said, it seems fairly clear to me that the IETF needs to 
> provide a means by which SDOs can create their own 
> SDO-specific attributes in a way that will be compatible with 
> future standardization, if necessary.

I agree

SDOs will standerdize what they need without going to a "Global" review
unless they deem that they need interoperability outside their domain.

VSAs fit that definition today - minus the discussion of what exactly a
vendor is.  Perhaps you can explain how creating a new class of attributes
would actually change anything other than satisfy those that insist that an
SDO is not a Vendor.  That is really my point.

Finally, regardless of how some define what a Vendor is - the fact is that
SDOs already have Vendor Ids.  So that defintion has already be accepted by
IANA.

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, May 27, 2004 6:44 PM
> To: Nelson, David
> Cc: [email-masked]
> RFC 2865 Section 6.2 states:
> 
> "   Note that RADIUS defines a mechanism for Vendor-Specific 
> extensions
>    (Attribute 26) and the use of that should be encouraged instead of
>    allocation of global attribute types, for functions 
> specific only to
>    one vendor's implementation of RADIUS, where no interoperability is
>    deemed useful."
> 
> An SDO is not a vendor, and typically requires 
> interoperability between vendors, so that this language does 
> not apply to use by SDOs.
> 
> That said, it seems fairly clear to me that the IETF needs to 
> provide a means by which SDOs can create their own 
> SDO-specific attributes in a way that will be compatible with 
> future standardization, if necessary.
>

---

From: "Puthenkulam, Jose P" <[email-masked]>
Date: Thu, 27 May 2004 17:04:49 -0700

A VSA is intended for use in the standard for vendor specific secret
sauce and NOT intended to promote interoperability for systems within an
SDO domain except between systems from the same vendor. (Having said
this reality lies elsewhere ;)

An SDO attribute is intended to promote interoperability within an SDO
domain while being able distinguish namespaces for attributes between
SDOs when standards are re-used by other SDOs.

My 2 cents...

Best regards,
jose

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Avi Lior
Sent: Thursday, May 27, 2004 4:32 PM
To: 'Bernard Aboba'; Nelson, David
Cc: [email-masked]
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

I agree

VSAs fit that definition today - minus the discussion of what exactly a
vendor is.  Perhaps you can explain how creating a new class of
attributes
would actually change anything other than satisfy those that insist that
an
SDO is not a Vendor.  That is really my point.

Finally, regardless of how some define what a Vendor is - the fact is
that
SDOs already have Vendor Ids.  So that defintion has already be accepted
by
IANA.

---

From: "Nelson, David" <[email-masked]>
Date: Fri, 28 May 2004 08:50:53 -0400

Bernard Aboba writes...

> To date we have several proposals on how to handle SDO Specific
Attributes
> (SSAs):
> 
> a. Allow SDOs to continue to use the existing RADIUS VSA space, but
> perhaps provide updated guidance on the design of SDO-specific
attributes
> within that space.
> 
> b. Create a new SSA space with a fixed attribute format, so as to
> enable more uniform behavior.
> 
> My sense is that a) is probably most appropriate for SDO work not done
in
> cooperation with IETF.  SDOs already are using the existing VSA space
and
> are unlikely to abandon it.
> 
> But choice b) may be workable for attributes done in SDOs with the
> cooperation of the IETF, particularly where it is desired to
standardize
> attributes that have previously been implemented in the VSA space.

I agree.  One additional factor to consider is the potential for re-use.
Let's assume that an attribute is created within one SDO, initially for
use within an application scope of that SDO, and is later adopted for
use by another SDO (potentially the IETF) for a broader or different
application scope.  It would better to have chosen the (b) option, to
promote the re-usability and greater global interoperability.  Of
course, the problem is that making the right decision when the attribute
is initially developed will require some amount foresight into future
areas of applicability.  That won't always be easy to determine.

-- Dave

---

From: "Christopher Richards" <[email-masked]>
Date: Fri, 28 May 2004 09:50:02 -0400

Hi All,

So, back to the original question that started this whole discussion. Can
the DCCA authors confirm that the encoding of RADIUS VSAs in Diameter is a
closed issue?

---- Original email showing incorrect encoding of RADIUS VSA in Diameter
-------->

Hi All, 

Quick question I'm sure has been answered before. 

When sending a RADIUS VSA AVP (code 26) in a Diameter message, should the
Diameter AVP header have the Vendor-Specific bit set (and so include the
Vendor-Id field)? Or should the vendor-id be part of the AVP data (As it is
in RADIUS)?

My interpretation is that since AVP code 26 is not a Diameter vendor
specific AVP code - but is a RADIUS defined AVP, so that the Vendor-Specific
bit is NOT set in the Diameter AVP header.

RADIUS encoding of AVP code 26:- 

    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Type      |  Length       |            Vendor-Id 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        Vendor-Id (cont)           |  String... 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

Diameter encoding of a RADIUS VSA AVP (code 26):- 

    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Type = 26                                                     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Flags = 0     |      Length                                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Diameter AVP Data field... 
   +-+-+-+-+-+-+-+-+-+-+-+..... 

Where the Diameter AVP data field is:- 

    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Vendor-Id                                                     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Vendor type   | Vendor length | Vendor Data field.... 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...... 

Is this the intention of RFC3588? 

Best Regards, 
Chris. 

Response ------------->

Cheers,
Chris.

Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
From: "Richards, Christopher [RICH2:2Q40:EXCH]" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Date: Tue, 4 May 2004 10:52:58 -0400

Hi Marco, 

Cheers, 
Chris. 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]

Hi Chris, 

I now want to 
codes 0 to 255 

Regards 
Marco

---

From: Avi Lior <[email-masked]>
Date: Fri, 28 May 2004 10:18:08 -0400

But actually.....

I think realisticaly, if an SDO wants to have something interoperate
globally it must reliquish control of that attribute to some other entity.
The work has got to be handed off to someone else.  You can't expect an SDO
to address all requirements in other domains.  They tend to do a good job
addressing their domain. Also, you can't expect them to guarnatee the
stability of the attribute. The SDO could make changes not realizing it's
impacts on external entities that adopted the attribute in the first place.
They may not even know who if anyone has adopted the attribute. 

I agree with David, preferably it should relinquish control of the attribute
early in the game rather then later.

But this is what SDOs do today.  They use VSA for their local attributes and
they handoff work to the IETF when they desire global interoperability.  Or
they adopt IETF standards.  The attributes therefore are IETF attributes. 

So I don't know what the benefit of having a new class of attribute.  What
are we really fixing here?

Avi

> Sent: Friday, May 28, 2004 1:19 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> > I completely agree.  It seems that the IETF generally works 
> from the 
> > 'not invented here' syndrome, and wants to see everything done 
> > completely within the IETF, which is not scalable.
> 
> It has become increasingly apparent that the IETF cannot 
> handle the volume of SNMP MIB work required by SDOs such as 
> IEEE 802.1.  Increasingly companies are not willing to foot 
> the travel bill for attending multiple SDO meetings in order 
> to progress the same work item, and the IETF has often become 
> the "odd man out".
> 
> This argues to moving toward a model where the work is done 
> within the SDO that needs it, with review from IETF "Doctor" 
> teams based on guidelines documents.  This is more or less 
> the model we are moving toward with SNMP.
> 
> To get there with AAA we will need to articulate the 
> application design guidelines for RADIUS and Diameter (and 
> interoperation between them), build up a AAA Doctor team, and 
> iron out differences between the data models in the 
> enterprise and standards space within RADIUS (thankfully, 
> Diameter does not have such a discrepancy).
> 
> > I think there should be a difference
> > between vendor-specific attributes / extensions and ones 
> done in SDOs, 
> > especially ones that have cooperation with the IETF.
> 
> We will have to work through what the difference is and how 
> it is handled. To date we have several proposals on how to 
> handle SDO Specific Attributes
> (SSAs):
> 
> a. Allow SDOs to continue to use the existing RADIUS VSA 
> space, but perhaps provide updated guidance on the design of 
> SDO-specific attributes within that space.
> 
> b. Create a new SSA space with a fixed attribute format, so 
> as to enable more uniform behavior.
> 
> My sense is that a) is probably most appropriate for SDO work 
> not done in cooperation with IETF.  SDOs already are using 
> the existing VSA space and are unlikely to abandon it.
> 
> But choice b) may be workable for attributes done in SDOs 
> with the cooperation of the IETF, particularly where it is 
> desired to standardize attributes that have previously been 
> implemented in the VSA space.
> 
> However, if choice b) is really only about IETF work, then 
> perhaps it makes more sense to think of it as an "IETF 
> Extended Attribute Space" rather than an SDO-specific space.  
> The difference between the two comes from whether we think 
> that SDOs will use the SSA space *in addition* to their 
> existing VSA space.
> 
> And of course in all of this we will need to understand the 
> implications for Diameter-RADIUS translation.
>

---

From: <[email-masked]>
Date: Mon, 31 May 2004 17:43:54 +0300

Bernard,

> What about if the Vendor-Specific attribute includes *multiple*
> attributes?  This is allowed in RFC 2865.

I think the rule is also defined in NASREQ. We perhaps don't
need to repeat it in DCC since there is a reference to NASREQ.

From NASREQ sect. 9.6.2

Nested Multiple vendor data fields MUST be expanded into multiple
   Diameter AVPs.

Regards
Marco