Re: [drinks] Why is the dgName part of the key for public identities?

This is a great find. Thanks for bringing this up. Other authors of the
document are welcome to comment. Though I will try to look into 0..1 and
0..n collision issue and respond a little later, along with suggestions on
what constitutes a fix.

Either way, I feel that the grouping of TNs by destination group allows for
more granular control over the configuration as to which pathways are more
appropriate for establishing the session. Let's say that there are ten
different regions with large concentration of subscribers. Use of
destination groups allows for greater flexibility in isolating select paths
to attempt session establishment at resolution time than would have
otherwise been possible. Using your example, DG1 and DG2 selectors will
allow for different path associations to the TN 1234 or else an aggregate
of the two session data information would be returned.

And I think the basic premise of your suggestion is evident in the examples
where the read-back/get of the record doesn't require the name of the
destination group as an input parameter. Though if the 0..n cardinality is
enforced, dest group name should be a consideration for optional parameter.
To be clear, the intent of the read-back/get function in the SPP context is
to retrieve the full record in its current state since the last update.

-Syed

On Tue, Apr 16, 2013 at 10:43 AM, Mickael Marrache <
mickaelmarrache@gmail.com> wrote:

> Hi,
>
> According to the requirements document (RFC6461), a public identifier
> object can be contained in exactly one destination group object. Figure 3
> explicitly shows this intent by the 0...1 cardinality on the destination
> group side in the DG-PI association. In the framework document (section
> 3.1), this cardinality is different (0...n instead of 0...1).
> Is the real intention the one defined in the requirements document or in
> the framework document?
>
> Also, according to the framework document, a public identity is uniquely
> identified by its type, rant, dgName and value (e.g. tn for telephone
> numbers). The only motivation to include the dgName as part of the key is
> to allow a public identity to be associated with multiple destination
> groups. If the right intention is the one defined in the requirements
> document, it's an error to include the dgName as part of the key. Following
> this way, we would be allowed to associate the same public identity to
> multiple destination groups. If the right intention if the one defined in
> the framework document, there is still an issue since there is duplication
> of information. For example, if registrant Org-1 wants to associate the
> telephone number 1234 to two of its destination groups DG-1 and DG-2, he
> would need to specify two objects in the spppAddRequest. These two objects
> will contain exactly the same data, except that the dgNames will be
> different (i.e. DG-1 for the first object and DG-2 for the second one).
>
> Thus, regardless which intention is the right one, I think the dgName
> should not be part of the key. A public identity should then be identified
> by its type, rant and value only. Then, according to which is the right
> intention, the dgName field should be declared with maxOccurs=1 (i.e. from
> requirements) or maxOccurs=unbounded (i.e. for framework).
>
> The fact that a field that composes the key may be optional is a symptom
> of this design issue. In this case, this field is dgName.
>
> Regards,
> Mickael
>
>
>
>
>
> _______________________________________________
> drinks mailing list
> drinks@ietf.org
> https://www.ietf.org/mailman/listinfo/drinks
>
>