Subject: Re: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR

From: Jaya Kumar Satri <[email-masked]>
Date: Wed, 16 Jul 2008 11:47:39 +0100 (BST)

Hi Gowda, 
                   If the User-Name is specified and it is not recognised by Server, only then can the resultcode - 'DIAMETER_USER_UNKNOWN' be used.
   
  Thanks & Regds.,
  Jaya Kumar
  
"Gowda, Avinash" <[email-masked]> wrote:
  Even I have found in RFC4006 Section 9.2 that there is an error code to
convey if user is not identified.

DIAMETER_USER_UNKNOWN 5030 - The specified end user is unknown in the
credit-control server.

I was referring SIP RFC also. In that also they send similar kind of
error message for URA message not containing User-Name AVP. (RFC4740
Section 8.2).

Thanks,
Avinash Gowda

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, July 16, 2008 3:48 PM
To: Jaya Kumar Satri
Cc: Gowda, Avinash; [email-masked]
Subject: Re: [Dime] Absence of User-Name/ Subscription-Id AVP in the
Initial CCR

Hi Jaya,

a briefly look at RFC 4006 and searched for Subscription-Id AVP.

This AVP is optional in the ABNF but it has the M-bit set, see Section 8

of RFC 4006.

Optional in the ABNF just means that the sender can decide whether it 
wants to place it in there. This makes a lot of sense if you actually 
have 2 options like here, namely Subscription-Id and User-Name.

However, the M-bit indicates what is mandatory to understand for the 
receiving side (with respect to a specific Command in a specific 
Diameter application).

The ABNF has some limits in describing options, I agree, and a protocol 
designer does not want to describe every combination as a separate 
Command. As such, when the Diameter client sents nothing then the 
Diameter server will be puzzled and return an error message. I would 
have to read through the text carefully to find text indicating that 
some form of user identification has to be provided.

Ciao
Hannes

Jaya Kumar Satri wrote:
> Hi Avinash,
> Thanks for the reply, but it does not answer my
question.
> Thanks & Regds.,
> Jaya Kumar.
>
> */"Gowda, Avinash" /* wrote:
>
> Hi Jaya Kumar,
> 
> Please refer RFC3588 Section 9.5. This may answer your question.
> 
> Even I am new to RFC4006. So this is just an attempt to discuss
> the things.
> 
> Thanks,
> Avinash Gowda
>
------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Jaya Kumar Satri
> *Sent:* Wednesday, July 16, 2008 3:23 PM
> *To:* [email-masked]
> *Subject:* [Dime] Absence of User-Name/ Subscription-Id AVP in the
> Initial CCR
> 
> Hi,
> 
> 1) The AVPs 'User-Name' and 'Subscription-Id' are optional AVPs
> according to the ABNF of CCR in rfc 4006. These are the AVPs
> required to identify the end user.
> 
> 2) If in the initial CCR, these AVPs are absent. The behaviour of
> the CC application is not specifed.
> 
> 3) Had those AVPs been Mandatory, the resultcode
> 'DIAMETER_MISSING_AVP' can be given in the Answer Message. But as
> those are optional, what should be done.
> 
> How should Application behave in this scenario?
> 
> Thanks & Regds.,
> Jaya Kumar.
> "This email message and any attachments are confidential
> information of Starent Networks, Corp. The information transmitted
> may not be used to create or change any contractual obligations of
> Starent Networks, Corp. Any review, retransmission, dissemination
> or other use of, or taking of any action in reliance upon this
> e-mail and its attachments by persons or entities other than the
> intended recipient is prohibited. If you are not the intended
> recipient, please notify the sender immediately -- by replying to
> this message or by sending an email to
> [email-masked] -- and destroy all copies of this
> message and any attachments without reading or disclosing their
> contents. Thank you."
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
> 

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

---

From: "Gowda, Avinash" <[email-masked]>
Date: Wed, 16 Jul 2008 16:51:46 +0530

Correct. If User-Name is not present and if we are expecting that AVP to
be present in the message then this Result-Code sounds good. No other
Result-Code matches this scenario in RFC4006. :-)

Thanks,

Avinash Gowda

________________________________

From: Jaya Kumar Satri [mailto:[email-masked]] 
Sent: Wednesday, July 16, 2008 4:18 PM
To: Gowda, Avinash
Cc: [email-masked]
Subject: RE: [Dime] Absence of User-Name/ Subscription-Id AVP in the
Initial CCR

Hi Gowda, 

                 If the User-Name is specified and it is not recognised
by Server, only then can the resultcode - 'DIAMETER_USER_UNKNOWN' be
used.

Thanks & Regds.,

Jaya Kumar

	Even I have found in RFC4006 Section 9.2 that there is an error
code to
	convey if user is not identified.
	
	DIAMETER_USER_UNKNOWN 5030 - The specified end user is unknown
in the
	credit-control server.
	
	I was referring SIP RFC also. In that also they send similar
kind of
	error message for URA message not containing User-Name AVP.
(RFC4740
	Section 8.2).
	
	Thanks,
	Avinash Gowda
	
	-----Original Message-----
	From: Hannes Tschofenig [mailto:[email-masked]] 
	Sent: Wednesday, July 16, 2008 3:48 PM
	To: Jaya Kumar Satri
	Cc: Gowda, Avinash; [email-masked]
	Subject: Re: [Dime] Absence of User-Name/ Subscription-Id AVP in
the
	Initial CCR
	
	Hi Jaya,

	This AVP is optional in the ABNF but it has the M-bit set, see
Section 8
	
	of RFC 4006.
	
	Optional in the ABNF just means that the sender can decide
whether it 
	wants to place it in there. This makes a lot of sense if you
actually 
	have 2 options like here, namely Subscription-Id and User-Name.
	
	However, the M-bit indicates what is mandatory to understand for
the 
	receiving side (with respect to a specific Command in a specific

	Diameter application).
	
	The ABNF has some limits in describing options, I agree, and a
protocol 
	designer does not want to describe every combination as a
separate 
	Command. As such, when the Diameter client sents nothing then
the 
	Diameter server will be puzzled and return an error message. I
would 
	have to read through the text carefully to find text indicating
that 
	some form of user identification has to be provided.
	
	Ciao
	Hannes

	question.