Subject: Re: [Dime] Design Guideline on Command reuse and Application-Id

From: Victor Fajardo <[email-masked]>
Date: Mon, 01 Oct 2007 09:49:05 -0400

Hi Mark,

Sorry for the really late reply. Comments inline:

> When 3GPP reused NASREQ commands in the Gx application (TS 29.212), a
> question arose about which application id should populate the
> Auth-Application-Id AVP. Gx is a vendor-specific application (3GPP is
> the 'vendor') so it was initially thought that the
> Vendor-Specific-Application-Id AVP should be used instead of
> Auth-Application-Id. However, the Auth-Application-Id AVP is a required
> AVP in the NASREQ commands so the AVP could not be replaced without
> abandoning the command reuse. 3GPP decided to populate the
> Auth-Application-Id AVP with the Gx application id.
>
> I think it would be useful for the Design Guidelines draft to capture
> this scenario and suggest the following paragraph be added to section
> 5.3 (Use of Application-Id in a Message):
>
> "For historical reasons, some IETF applications specify commands that
> require application id AVPs (Auth-Application-Id or Acct-Application-Id)
> in the message body. When designing vendor-specific applications which
> reuse these IETF commands, designers should specify that the application
> id contained in these AVPs is that assigned to the vendor-specific
> application and not the original IETF application."
>   

I think this is a more general case if a command is being reused in a 
new application for which a new app-id has been assigned. So we may want 
to re-word it that way instead:

"In general, when a new application has been allocated with a new application id
and it also reuses existing commands with or without modifications (Sec 4.1), it must
use newly allocated application id in the header all relevant application id AVPs
(Auth-Application-Id or Acct-Application-Id) present in the commands message body."

Note that the rule should apply whether the imported command has been 
modified or not or whether its vendor specific or not.

regards,
victor

> Any concerns?
>
> Regards
> Mark
>
>
>
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
>
>
>
>   

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

---

From: "Mark Jones" <[email-masked]>
Date: Tue, 2 Oct 2007 09:38:54 -0400

Hi Victor,

Thanks for reviewing the proposed text. Comments below...

> (Auth-Application-Id or Acct-Application-Id) present in the 

I'm fine with the more general rule. I suggest a couple of minor changes
to your text; to fix a typo (missing 'and') and add
Vendor-Specific-Application-Id to your AVP list to cover the case where
commands from a vendor-specific application are re-used.

"When a new application has been allocated with a new application id
and it also reuses existing commands with or without modifications (Sec
4.1), it must use the newly allocated application id in the header and
all relevant application id AVPs (Auth-Application-Id,
Acct-Application-Id, Vendor-Specific-Application-Id) present in the
commands message body."

Work for you?

Regards
Mark

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 02 Oct 2007 09:52:58 -0400

Looks ok to me.

---

From: Aridaman Kaushik <[email-masked]>
Date: Wed, 3 Oct 2007 16:16:46 +0530

Hi Victor,
           NASReq RFC 4005 is contradicting with the given statement 
below. NASReq reuses STR/ASR/RAR commands from base.  Section 1.3 of RFC 
4005 mentions that STR/ASR/RAR is defined by base. So these message should 
use base application Id (header and auth-application-id avp).

Should it be modified.

Best regards
Aridaman kaushik. 

Victor Fajardo <[email-masked]> 
10/01/2007 07:19 PM

To
Mark Jones <[email-masked]>
cc

Subject
Re: [Dime] Design Guideline on Command reuse and Application-Id

Hi Mark,

"In general, when a new application has been allocated with a new 
application id
and it also reuses existing commands with or without modifications (Sec 
4.1), it must
use newly allocated application id in the header all relevant application 
id AVPs
(Auth-Application-Id or Acct-Application-Id) present in the commands 
message body."

regards,
victor

***********************  Aricent-Private   ***********************
"DISCLAIMER: This message is proprietary to Aricent  and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 03 Oct 2007 08:21:42 -0400

Hi Aridaman,

We had a discussion some time ago regarding this topic. 3588bis as it 
stands does specify using the app id of the application for these 
messages. Some of the discussion points can be found in:

http://www.tschofenig.priv.at:8080/diameter-interop/issue5

A repercussion of this discussion is that existing apps may need updating.

regards,
victor

> below. NASReq reuses STR/ASR/RAR commands from base.  Section 1.3 of 
> RFC 4005 mentions that STR/ASR/RAR is defined by base. So these 
> message should use base application Id (header and auth-application-id 
> avp).
>
> Should it be modified.
>
> Best regards
> Aridaman kaushik.  
>
>
> *Victor Fajardo <[email-masked]>*
>
> 10/01/2007 07:19 PM
>
> 	
> To