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

From: Mickael Marrache <[email-masked]>
Date: Tue, 16 Apr 2013 17:43:10 +0300

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

---

From: Syed W Ali <[email-masked]>
Date: Tue, 16 Apr 2013 12:19:06 -0400

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 <
[email-masked]> wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/drinks
>
>