RE: : ISSUE: Sections 4 & 5.10 appear to contradict each other

Miguel Garcia <mailto:[email protected]> supposedly scribbled:

...

>>>> Requested change: Make the document consistent; how this is done
>>>> is up to the authors. 
>>>> 
>>> 
>>> I think you didn't read carefully, because I don't find the
>>> contradiction.
>> 
>> 
>> OK, I'll try again: "one" != "one or more".
> 
> Ok, I understand now your concern. So you are saying that, because
> the data is stored in a single server, there should be exactly one
> Redirect-Host AVP in the LIA command.  
> 
> Initially I agreed... but then I check RFC 3588, and it allows to
> have multiple Redirect-Host AVPs. It actually says that the client
> selects one entry.  
> 
> I think that one could have a list of Diameter URIs in the
> Redirect-Host AVP. This enables to indicate "please select any of the
> n equivalent diameter servers" (that are configured with synchronized
> data).   
> 
> One can argue that we can do the same with DNS round robin and a
> single Diameter URI, which is true. The question is whether we want
> to put an artificial limit here or not.  
> 
> In other words: both the current specification and your proposal work.
> The current specification can accommmodate more use cases in my
> opinion, but if it is misleading, we can change it. 

The current specification is inconsistent because you say in one place that the user data is stored in one place but in another that multiple locations are returned.  If you want to allow direct access to the individual members of the virtual server, that's up to you (though it puts the burden of load-balancing on the Diameter server returning the Redirect-Host AVP).  One way or the other the spec needs to be consistent.

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel