RE: : 3588 issue with Vendor-Specific-Application-Id

[email protected] Tue, 17 May 2005 16:29:50 +0200
Newsgroups gmane.ietf.aaa
Message-ID <OF78E96A3F.70A00C36-ONC1257004.004CFBBE-C1257004.004FA306@ip3k.de>
Hi Avi and Thomas,

There is also the fact that each message (command or answer) includes "the" application-id. This is without any Vendor-Id qualification and seems to rely on the uniqueness of application-ids granted to vendors, resulting from IANA control. So only one value for application-id is permissible for any one application.

RFC 3588 also says: The application-id in the header MUST be the same as what is

contained in any relevant AVPs contained in the message.

Accordingly it seems possible only to have ONE value i.e. EITHER Auth-Application-Id or Acct-Application-Id.

regards

Michael Hillier

[email protected]

Avi Lior <[email protected]>

Sent by: [email protected]

10.05.2005 18:25

To: "'Belling Thomas'" <[email protected]>, "'[email protected]'" <[email protected]>

cc:

Subject: RE: [AAA-WG]: 3588 issue with Vendor-Specific-Application-Id

Hi Thomas,

Actually I don't think you can have both Auth and Application Id. This is a

nother problem with the spec as it exists today. It allows for both.

So, if only one or the other is allowed then the following is better.

"Exactly one of the Auth-Application-Id or exactlly one of the

Acct-Application-Id AVPs MUST be present but not both."

If you want to allow both then:

"Exactly one or both of the Auth-Application-Id or Exactlly one of the

Acct-Application-Id AVPs MUST be present."

> -----Original Message-----

> From: Belling Thomas [mailto:[email protected]]

> Sent: Tuesday, May 10, 2005 12:03 PM

> To: 'Avi Lior'; '[email protected]'

> Subject: RE: [AAA-WG]: 3588 issue with Vendor-Specific-Application-Id

>

>

> Dear Avi,

>

> the proposed change rule out that you supply both one

> Auth-Application-Id and one Acct-Application-Id in the same

> Vendor-Specific-Application-Id AVP, although this makes sense.

>

> regards, Thomas Belling

>

>

> ----------------------------------

> Dr. Thomas Belling

> Siemens AG

> Sankt-Martin-Str. 76

> D-81541 München Germany

> Com MN PG NT MN 1

> MCH M 34 307

> Tel +49 89 636 75207

> Fax +49 89 636 75577

> Mobile +49 172 2974678

> Email [email protected]

>

>

>

>

> > -----Original Message-----

> > From: [email protected] [mailto:[email protected]]

> > On Behalf Of Avi Lior

> > Sent: Tuesday, May 10, 2005 5:57 PM

> > To: '[email protected]'

> > Subject: [AAA-WG]: 3588 issue with Vendor-Specific-Application-Id

> >

> >

> > Description of issue

> >

> > Submitter name: Avi Lior

> > Submitter email address: [email protected]

> > Date first submitted: May 10, 2005

> > Reference:

> > Document: 3%88

> > Comment type: T

> > Priority: S

> > Section: 6.11

> > Rationale/Explanation of issue:

> >

> > As the 3588 stands nowm Vendor-Specific-Application-Id AVP is

> > allowed to

> > have just a vendor-id element. This does not make any sense.

> >

> > Length description of problem

> >

> > The ABNF of the Vendor-Specific-Application-Id given below:

> >

> > <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >

> > 1* [ Vendor-Id ]

> > 0*1{ Auth-Application-Id }

> > 0*1{ Acct-Application-Id }

> >

> > And the following text from 3588 section 6.11:

> >

> > "Exactly one of the Auth-Application-Id and

> > Acct-Application-Id AVPs MAY be

> > present."

> >

> > Allows us to have a Vendor-Specific-Application-Id containing only

> > Vendor-Id.

> >

> > I don't think that that is the intent.

> >

> > Requested change:

> >

> > To fix this problem,

> >

> > Change:

> > "Exactly one of the Auth-Application-Id and

> > Acct-Application-Id AVPs MAY be

> > present."

> >

> > To:

> > "Exactly one of the Auth-Application-Id or

> > Acct-Application-Id AVPs MUST be

> > present."

> >

> >

> >

> >

> >

> > ------------------------------------------------

> > Avi Lior

> > Bridgewater Systems Corporation

> > Phone : (613) 591-9104 x6417

> > Cell : (613) 297-2177

> > E-mail : mailto:[email protected]

> www.bridgewatersystems.com

> >

> >

>