Subject: [Dime] "Fail unless processed successfully" Bit

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 2 Dec 2008 09:23:04 +0200

After we had the IETF#73 DIME meeting a few of us met at AAA doctors
Directorate lunch. 
What is the AAA doctors directorate? See here: 
http://trac.tools.ietf.org/wg/dime/trac/wiki/AaaDoctors

While there was agreement about the discussions regarding the M-bit
during the DIME meeting the question was raised how to implement the
following functionality:

Imagine that a Diameter server wants to convey an AVP with packet
filters to the Diameter client. The Diameter client, however, is unable
to fulfill the request. This can happen for multiple reasons. For
example, the packet filter states that packets with router alert options
have to be dropped but the firewalling module at the Diameter client
does not have the capability to filter router alert options. Another
example would be that the conflict resolution mechanism overrides the
policies that are being provided by the Diameter server and hence the
rules are not enforced. 

When setting this flag for an AVP there are no requirements regarding
the creation of a Diameter application. When an AVP has the flag set and
the receiving end cannot process it successfully then an error message
is returned. 

So, here are my questions: 

* Does my mail make sense to you? Is this a useful mechanism? 

* If so, where should it be added? 

Ciao
Hannes

PS: The M-bit cannot be used for this purpose because of several
reasons, including the fact that it requires a Diameter application to
be created when AVPs have the M-bit set. The semantic of the M-bit as we
define it today is very different from what is being asked here. We
define the M-bit as a way for the specification author to indicate that
the receiving side has to implement a certain AVP. 

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

---

From: Alan DeKok <[email-masked]>
Date: Tue, 02 Dec 2008 11:23:00 +0100

> * Does my mail make sense to you? Is this a useful mechanism? 

  Yes, and yes.

  Another way of phrasing the requirement is that it is an enforcement
bit.  Setting the enforcement bit on the AVP means "reject the session
if you cannot enforce the requirements of the AVP".

  Alan DeKok.

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 02 Dec 2008 08:34:17 -0500

Hi Hannes,

> * If so, where should it be added? 

Is there a lot of application interested in such mechanism that there is 
a need to generalize it ? Should'nt this mechanism be specified in the 
application requiring it ? Especially if you you want to convey more 
granular and context specific error messages/codes back to the server. 
In this case, we may not need an additional flag, just specify a well 
defined behavior in the doc.

regards,
victor

---

From: <[email-masked]>
Date: Tue, 2 Dec 2008 14:40:41 +0100

Hi Hannes, Victor,

It was exactly my understanding.
I'm not sure that it would be a good idea to describe all the possible error cases in the Diameter base and/or Diameter aplication level. The specific behavior of a given Diameter node will have to be anyway described in a specific document.
In that case, the document will just say: Diameter node A will reject the session if something is wrong..."

Lionel

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de Victor Fajardo
> Envoyé : mardi 2 décembre 2008 14:34
> À : Tschofenig, Hannes (NSN - FI/Espoo)
> Cc : [email-masked]
> Objet : Re: [Dime] "Fail unless processed successfully" Bit
> 
> Hi Hannes,
> 
> > the creation of a Diameter application. When an AVP has the 
> flag set 
> > and the receiving end cannot process it successfully then an error 
> > message is returned.
> >
> Is there a lot of application interested in such mechanism 
> that there is a need to generalize it ? Should'nt this 
> mechanism be specified in the application requiring it ? 
> Especially if you you want to convey more granular and 
> context specific error messages/codes back to the server. 
> In this case, we may not need an additional flag, just 
> specify a well defined behavior in the doc.
> 
> regards,
> victor
> 
> > Ciao
> > Hannes
> >
> > be created when AVPs have the M-bit set. The semantic of 
> the M-bit as 
> > we define it today is very different from what is being 
> asked here. We 
> > define the M-bit as a way for the specification author to indicate 
> > that the receiving side has to implement a certain AVP.
> >

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 2 Dec 2008 13:29:30 -0500

I agree that this is an application layer thing. IMHO it would be a
major abuse to use any message header bits for this purpose.

Thanks,
Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Victor Fajardo
> Sent: Tuesday, December 02, 2008 8:34 AM
> To: Tschofenig, Hannes (NSN - FI/Espoo)
> Cc: [email-masked]
> Subject: Re: [Dime] "Fail unless processed successfully" Bit
> 
> Hi Hannes,
> 
that

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 2 Dec 2008 22:26:19 +0200

>  Another way of phrasing the requirement is that it is an 
>enforcement bit.  Setting the enforcement bit on the AVP means 
>"reject the session if you cannot enforce the requirements of the AVP".
>
>  Alan DeKok.

That's a better way to phrase it.  
Thanks, Alan.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 2 Dec 2008 22:26:19 +0200

One can clearly define a new application for every new piece of
functionality. No doubt. 

The idea in this specific case, however, was not to define a new application
but rather to have support for it at the AVP level with a new flag. 

When we clarified the semantic of the M-bit we also lost some functionality,
I believe. 

Now, my question was whether we are able to get some of this functionality
back. 

Ciao
Hannes

>From: ext Victor Fajardo [mailto:[email-masked]] 
>Sent: 02 December, 2008 15:34
>> the creation of a Diameter application. When an AVP has the flag set 
>Especially if you you want to convey more granular and context 
>specific error messages/codes back to the server. 
>In this case, we may not need an additional flag, just specify 
>a well defined behavior in the doc.
>
>regards,
>victor
>
>> Ciao
>> Hannes
>>
>> be created when AVPs have the M-bit set. The semantic of the 
>M-bit as

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 2 Dec 2008 15:31:43 -0500

Hi Hannes,

IMHO the functionality we lost is about understanding/taking action
about an AVP. It never was about the outcome of the action AFAIK.

M-bit marked as MAY just was telling that the sender can decide whether
the receiver has to understand the AVP by setting/not-setting the M-bit.

Thanks,
Tolga

Of
> Hannes Tschofenig
> Sent: Tuesday, December 02, 2008 3:26 PM
> To: 'ext Victor Fajardo'
> Cc: [email-masked]

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 2 Dec 2008 22:26:19 +0200

Lionel is right. The Diameter Base specification would only provide a
high-level error message in context of this new flag rather than a full list
of possible error cases. Further information about the type of error could
be provided in other documents. 

Ciao
Hannes 

>From: ext [email-masked] 
>[mailto:[email-masked]] 
>Sent: 02 December, 2008 15:41
>To: [email-masked]; Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: [email-masked]
>Subject: RE: [Dime] "Fail unless processed successfully" Bit
>
>Hi Hannes, Victor,
>
>I'm not sure that it would be a good idea to describe all the 
>possible error cases in the Diameter base and/or Diameter 
>aplication level. The specific behavior of a given Diameter 
>node will have to be anyway described in a specific document.
>In that case, the document will just say: Diameter node A will 
>reject the session if something is wrong..."
>
>Lionel
>
>> De : [email-masked] [mailto:[email-masked]] De la part 
>> de Victor Fajardo Envoyé : mardi 2 décembre 2008 14:34 À : 
>Tschofenig, 
>> Hannes (NSN - FI/Espoo) Cc : [email-masked] Objet : Re: [Dime] "Fail 
>> unless processed successfully" Bit
>> 
>> Hi Hannes,
>> 
>that there 
>> is a need to generalize it ? Should'nt this mechanism be 
>specified in 
>> the application requiring it ?

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 02 Dec 2008 16:12:09 -0500

I have the same opinion as Tolga. Additionally, its a little bit scary 
to me when we try to revive a feature/functionality that few seem to 
understand or care about. If we really want to revive it, we may not 
want to use yet another bit flag that has some similarities in meaning 
to the E-bit but has a very loose definition ...

regards,
victor

>> Now, my question was whether we are able to get some of this
>>     
> functionality
>   
>> back.
>>
>> Ciao
>> Hannes
>>
>>     
>>>> When setting this flag for an AVP there are no requirements
>>>>         
>>> regarding
>>>       
>>>> the creation of a Diameter application. When an AVP has the flag
>>>>         
> set
>   
>>>> reasons, including the fact that it requires a Diameter
>>>>         
>>> application to
>>>

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 2 Dec 2008 23:12:11 +0200

I would echo what Tolga/Lionel/Victor said.

Cheers,
	Jouni

On Dec 2, 2008, at 8:29 PM, Asveren, Tolga wrote:

> and