Subject: RE: [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP

From: <[email-masked]>
Date: Tue, 2 Nov 2004 16:56:43 +0200

Hi Lionel,

> In the RFC 3588, the result-code DIAMETER_MISSING_AVP is ussed to indicate that a mandatory AVP 
> (required by the command code ABNF specification) is missing in the received command.
> 
> Is it possible to use the DIAMETER_MISSING_AVP result code along with the Failed-AVP AVP to indicate 
> that an optional AVP (from the ABNF point of view) is missing in the received command? If not, could 
> you identify some operational issues?

From 3588:

   DIAMETER_MISSING_AVP               5005
      The request did not contain an AVP that is required by the Command
      Code definition.  If this value is sent in the Result-Code AVP, a
      Failed-AVP AVP SHOULD be included in the message.  The Failed-AVP
      AVP MUST contain an example of the missing AVP complete with the
      Vendor-Id if applicable.  The value field of the missing AVP
      should be of correct minimum length and contain zeroes.

My guess is that if a particular implementation or application was expecting an
AVP to be included, this would be a reasonable way to do it.

John

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Tue, 2 Nov 2004 17:02:19 +0100

> My guess is that if a particular implementation or 
> application was expecting an AVP to be included, this would 
> be a reasonable way to do it.
> 

Based on this definition, it is only applicable to AVP "required by the
command code definition". It is not clear if we could reuse the same
result code for an optional AVP.
If there is a general consensus on this topic, maybe a modification to
the existing definition should be done.

Besides, if we could reuse the same result code for required or optional
AVP, should we state that "a Failed-AVP AVP MUST be included" instead of
"should be included"?
My assumption was that a "SHOULD" was possible here because you could
have relyed on the command code ABNF descritpion to find the missing
AVP. If the above assupmtion is correct, it is not possible anymore and
you have to use the Failed-AVP.

Lionel

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Wed, 3 Nov 2004 13:37:03 +0100

Hi John,

Another question:

what is the purpose of defining required/optional AVP in the command code ABNF description?
If DIAMETER_MISSING_AVP could be used for any missing AVP whatever its category (required/optional), there is no reason to define required AVP for a specific command code. Any AVP used in the command code ABNF definition could be defined as optional.

Is it correct?

Lionel

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> De la part de MORAND Lionel RD-CORE
> Envoyé : mardi 2 novembre 2004 17:02
> À : [email-masked]; [email-masked]
> Objet : RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP
> 
> 
> > From 3588:
> > 
> >       Code definition.  If this value is sent in the 
> Result-Code AVP,
> a

---

From: <[email-masked]>
Date: Wed, 3 Nov 2004 14:50:27 +0200

> result code for an optional AVP.

So, you were asking about Conditional AVPs.  There are no such things as
conditional AVPs in the base spec, that is why they are not mentioned.

I am aware that there are some 'vendors' making Diameter extensions to 
introduce this kind of 'feature.'  I don't see why those 'vendors' can't use
DIAMETER_MISSING_AVP to mean a conditional AVP as well.  

> the existing definition should be done.

Why?  Diameter has no notion of conditional AVPs.

> AVP, should we state that "a Failed-AVP AVP MUST be included" instead of

What is your reasoning for this?

> you have to use the Failed-AVP.

I'm sorry, could you restate what you mean, I am having a hard time understanding
your point.

thanks,
John

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Wed, 3 Nov 2004 14:22:23 +0100

Hi John,

I didn't say anything about "conditional" AVP ;-)

> application was 
> > > expecting an AVP to be included, this would be a 
> reasonable way to 
> > > do it.
> > > 
> > 
> > Based on this definition, it is only applicable to AVP "required by 
> > the command code definition". It is not clear if we could reuse the 
> > same result code for an optional AVP.
> 
> So, you were asking about Conditional AVPs.  There are no 
> such things as conditional AVPs in the base spec, that is why 
> they are not mentioned.
> 
> introduce this kind of 'feature.'  I don't see why those 
> 'vendors' can't use DIAMETER_MISSING_AVP to mean a 
> conditional AVP as well.  

[LM] The problem is not restricted to conditional AVPs. Based on your
response, you could use DIAMETER_MISSING_AVP for any optional AVP, based
on specific service logic using a given Diameter application.

> Why?  Diameter has no notion of conditional AVPs.

[LM] Because this would apply to any optional AVP used in the command
(whatever the use of this optional AVP).
 
> > Besides, if we could reuse the same result code for required or 
> > optional AVP, should we state that "a Failed-AVP AVP MUST 
> be included" 
> > instead of "should be included"?
> 
> > AVP. If the above assupmtion is correct, it is not possible anymore 
> > and you have to use the Failed-AVP.
> 
> I'm sorry, could you restate what you mean, I am having a 
> hard time understanding your point.

[LM] If DIAMETER_MISSING_AVP can be used for any missing AVP (required
or optional), a Failed-AVP AVP MUST be included in the message, to
indicate to the originator of the request what is the missing AVP. If
DIAMETER_MISSING_AVP is used alone, the originator would not be able to
rely on the command code ABNF definition to find the missing AVP.

Thanks,

Lionel

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Thu, 4 Nov 2004 09:51:08 +0100

Hi John,

I repeat that this mechanism is not restricted to conditional AVPs but
could be generalized to any optional AVP. 

> > 'vendors' can't use DIAMETER_MISSING_AVP to mean a 

About the last point:
Some 'vendors' try to design properly their Diameter extensions. The
philosophy is: If it's possible with the standard mecanisms, use the
standard specs; if not, define the suitable solution.
So here the question is not to know what it is possible to do within a
'vendor' specific implementation. The question is:

Does the RFC 3588 allow (or not prevent) to use DIAMETER_MISSING_AVP for
an optional AVP?

If not, It's up to the 'vendors' to decide how to solve this issue.

Lionel

---

From: <[email-masked]>
Date: Thu, 4 Nov 2004 12:38:57 +0200

Hi,

> Based on this definition, it is only applicable to AVP 
> "required by the command code definition". It is not clear if
> we could reuse the same result code for an optional AVP.

In my opinion here "command code definition" refers to the whole
definition of the command, not just the ABNF. Some parts of the
definition are often presented in "free" text. For example,
Diameter Application command definition might state that
Pet-Poodle AVP must be present in the message in case it
is Friday the 13th. :)

> have relyed on the command code ABNF descritpion to find the missing AVP.

So if the command-code ABNF definition defines three required AVPs
and you receive DIAMETER_MISSING_AVP without Failed-AVP how do you know
which one was missing? You need to know the message contents and the
command-code definition (including the rules for "conditional" AVPs) if
you want to know what AVP was missing. It doesn't matter at all whether
the missing AVP is required or optional.

BR,
Mikko

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext MORAND Lionel RD-CORE-ISS
> Sent: 02 November, 2004 18:02
> To: Loughney John (Nokia-NRC/Helsinki); [email-masked]
> Subject: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP
> 
> 
> > From 3588:
> >

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Thu, 4 Nov 2004 14:17:07 +0100

Hi Mikko,

> In my opinion here "command code definition" refers to the 
> whole definition of the command, not just the ABNF. Some 
> parts of the definition are often presented in "free" text. 
> For example, Diameter Application command definition might 
> state that Pet-Poodle AVP must be present in the message in 
> case it is Friday the 13th. :)

[LM] Maybe but it is not clear in the RFC3588
 
> > AVP.
> So if the command-code ABNF definition defines three required 
> AVPs and you receive DIAMETER_MISSING_AVP without Failed-AVP 
> how do you know which one was missing? You need to know the 
> message contents and the command-code definition (including 
> the rules for "conditional" AVPs) if you want to know what 
> AVP was missing. It doesn't matter at all whether the missing 
> AVP is required or optional.

[LM] Based on the RFC 3588:

6.1.2.  Sending a Request

   When sending a request, originated either locally, or as the result
   of a forwarding or routing operation, the following procedures MUST
   be followed:

   -  the Hop-by-Hop Identifier should be set to a locally unique value

   -  The message should be saved in the list of pending requests.

Receivig DIAMETER_MISSING_AVP without any Failed_AVP AVP, I'm able to
know what AVP is missing just by comparing the pending request with the
command code ABNF description. I don't need extra information if this
error message is only sent for missing "required" AVP.

By the way, this is not a discussion about 'conditional AVPs'. This
concept doesn't exist in the base protocol! We should only deal with
optional AVPs, whatever the use of these optional AVPs.

BR,

Lionel

---

From: <[email-masked]>
Date: Fri, 5 Nov 2004 15:51:08 +0200

Hi,

> know what AVP is missing just by comparing the pending 
> request with the command code ABNF description. I don't need extra
> information if this error message is only sent for missing "required" AVP.

I wonder what kind of implementation you're talking about.

Your example assumes that the implementation knows the correct contents
of the command (ABNF description etc.) so why would the implementation
send a command with missing AVP in the first place?

BR,
Mikko

> From: ext MORAND Lionel RD-CORE-ISS
> [mailto:[email-masked]]
> Sent: 04 November, 2004 15:17
> To: Aittola Mikko (Nokia-NET/Tampere); [email-masked]

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Wed, 10 Nov 2004 17:44:59 +0100

Any other thought on this thread?
The initial question was:

"Based on the RFC 3588, is it possible to use the DIAMETER_MISSING_AVP
result code along with the Failed-AVP AVP to indicate that an optional
AVP (from the ABNF point of view) is missing in the received command? If
not, could you identify some operational issues?"

BR,

Lionel

---

From: "STURA Marco Consultant" <[email-masked]>
Date: Thu, 11 Nov 2004 10:01:11 +0100

Sorry Lionel,

I forgot to add the essential part of my answer.

Also, if a server doesn't receives an AVP that a particular
implementation or application is expecting for the successful processing
of the request, although optional in the ABNF but e.g. defined to
present under certain conditions, the failed answer includes the
Failed-AVP AVP.

Br
Marco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of STURA Marco Consultant
Sent: Thursday, November 11, 2004 9:53 AM
To: MORAND Lionel RD-CORE-ISS
Cc: [email-masked]
Subject: RE: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP

Lionel,

I think the conclusion was "yes it is possible", and indeed it is.

If a server receives an AVP with M bit set that cannot recognize,
although the AVP is optional in the ABNF (i.e. in square brackets), the
Failed-AVP AVP is included in the failed answer.

Similarly, if the value of the AVP (which has the M bit set) is not
recognized the failed answer includes the Failed-AVP AVP.

Br
Marco
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of MORAND Lionel RD-CORE-ISS
Sent: Wednesday, November 10, 2004 5:45 PM
To: [email-masked]
Subject: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP

BR,

Lionel

---

From: "STURA Marco Consultant" <[email-masked]>
Date: Thu, 11 Nov 2004 14:11:32 +0100

I may agree on what you say, but after all it is always a missing AVP
what we are talking about. So, what suit best of an error of which
semantic is "missing AVP"?

Marco

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Thursday, November 11, 2004 1:55 PM
To: STURA Marco Consultant
Cc: MORAND Lionel RD-CORE-ISS; [email-masked]
Subject: RE: RE : [AAA-WG]: Using DIAMETER_MISSING_AVP for optional AVP

> I was thinking to similar case as you mentioned. But what value other
> than DIAMETER_MISSING_AVP should be used in this case?
>
> I don't see any other value available at the moment, that's why the
> DIAMETER_MISSING_AVP seems the most appropriate.

Looking through the error messages, it isn't clear that any of the
current
ones fit this circumstance.  Essentially, you would be saying that the
semantics of the request are invalid.  So a new error message is
probably
needed.

> Having said that, it is possible that some other AVP that *is*
mandatory
> may take on a value that implies the need for another optional AVP,
> which is missing.  That would be a terminal error, but a Result_Code
> other than DIAMETER_MISSING_AVP should be used to indicate that.

---

From: <[email-masked]>
Date: Sun, 14 Nov 2004 14:36:52 +0200

Hi,

I think DIAMETER_MISSING_AVP can be used to indicate
whatever missing AVP.

The actual definition of the error-code in RFC 3588 does not
limit the usage to mandatory AVPs only. What is described in
Section 7.11 (which is not the definition of the error-code)
is just one example how the error-code can be used.

BR,
Mikko

> ext STURA Marco Consultant
> Sent: 11 November, 2004 15:12
> To: Bernard Aboba