Re: [Dime] Capabilities update draft

[Niklas Neumann <niklas.neumann at cs.uni-goettingen.de>]

Hello everybody,

I was wondering if there should be some implementation considerations 
included. I see the following problem:

A Diameter client has a list of potential Diameter servers. When the 
client starts it picks a random server from this list and tries to 
initialize its applications. If there is an error the client picks the 
next server until a working server is found or the list is exhausted. 
Now if during operation the Diameter server "retracts" one of its 
applications the draft says that the client should disconnect the 
transport layer connections. Unfortunately from the point of view of the 
application it is not clear what to do because such a behavior was not 
anticipated before the capabilities-update app.

I see a couple of options:
a) The client can try to re-initialize the application as if the client 
was restarted.
b) The client can handle this like it would handle a Disconnect-Peer-Request
c) The client can signal a Diameter error to the application (e.g. 
DIAMETER_APPLICATION_UNSUPPORTED)
d) The client can ignore the application and hope that it has 
implemented an error handling which can cope with this.

My point is that a capabilities-update can set a Diameter application 
into a state that might not have been anticipated by the particular 
application implementation. Therefore it might be a good idea to give 
implementors some guidelines on what to keep in mind when extending a 
Diameter client without regarding the applications.

Also, I am probably late to the party and missed the initial discussion 
about the document but the motivation is not clear to me. Maybe some 
examples or use-cases can help to understand in which scenarios you 
envision the capability-updates to be used.

Best regards
  Niklas



Victor Fajardo wrote:
> Hi Folks,
>
>  
>
> We would like to progress the capabilities-update draft 
> (http://tools.ietf.org/html/draft-ietf-dime-capablities-update-00). Ravi 
> and other folks have commented on this work but its best if we get some 
> more feedback especially from folks who work on diameter 
> implementations. It’s a short document and fairly easy reading. We plan 
> to let this cook in the WG for about a month or so and then take the 
> next step. If you have concerns, pls state so as well.
>
>  
>
> Regards,
>
> victor//
>
>  
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> DiME mailing list
> DiME at ietf.org
> https://www.ietf.org/mailman/listinfo/dime



--
Niklas Neumann - University of Goettingen, Institute of Computer Science
http://user.informatik.uni-goettingen.de/~nneuman1/
Tel: +49 551 39-172053