[drinks] Following today's meeting

[Mickael Marrache <[e-mail]>]

Hi,

During the call, we agreed that the cardinality on the DG side of the
PubId-DG association should be 0..1 instead of 0...n. We also agreed that
this cardinality should not be interpreted as limiting a PI to be
associated to at most one DG. However, this cardinality should be
interpreted as limiting a PI instance to be associated to at most one DG.
Thus, for example, the "same" telephone number may be associated to
multiple DGs by the use of multiple TN instances. This way is made possible
by including the dgName element as part of the key, so that for a given
registrant and a given value (e.g. tn, tnp, start/end...), different values
for the dgName element are allowed.

I think that the dgName element should not be part of the key because it is
optional. While it may be acceptable for a key attribute to be optional in
some cases, I think it's relatively rare. Also, it becomes more difficult
to define a URI for each public identifier concrete type. For example, an
obvious URI for a TN resource would represent the key attributes as path
parameters such as /rant/{rant}/TN/dgName/{dgName}/tn/{tn}. However, dgName
is optional and may not have a value. We can solve this problem by using a
special string to represent the absence of a value, or by using other types
of URI parameters (e.g. query parameters), but I don't think it's the right
way to go.

What I proposed during the call was to exclude the dgName element from the
key. So, there would be only one PI instance for a particular value, that
is identified by the registrant that owns the PI, and the value of the PI
(e.g. tn, tnp...). In order to allow a PI to be associated to multiple DGs,
the maxOccurs attribute of the dgName element should be set to unbounded.
The registrant organization would only deal with one instance for a given
PI value. The URI for the TN resource would then be /rant/{rant}/TN/{tn}.

Concerning the carrier-of-record concern, the question is: Is there a
meaning to let a registrant organization provision the same PI (in terms of
value) with different COR information? The current model allows such a
feature by the use of multiple PI instances (thus, allowing multiple
corInfos). If this is a real use case, the corInfo element should be an
attribute of the PI-DG association since it is not intrisic to the PI
itself but depends on an external factor (in this case, the association
with a particular DG). Creating a new complex type DestGrpRefType that
includes the DG key and the corInfo element would solve this issue. The
list of dgName (ObjNameType) would become a list of dgRefs (DestGrpRefType).

Not related to this question, there are two other points I raised in the
mailing list:

   1. The framework document states: "If the response to the Get operation
   includes object(s) that extend the BasicObjType, the Registry MUST include
   the 'cDate' and 'mDate', if applicable.". In the examples section in the
   SOAP document (section 10), for the Get examples, the elements cDate and
   mDate are not part of the returned responses.
   2. According to the framework document, an egress route is added by the
   originating SSP to the registry. The originating SSP must be a peering
   organization of the SED group to which the egress route is associated.
   Thus, an egress route is an element owned by the originating SSP. The rant
   field of the egress route would then identify the originating SSP and not
   the owner of the SED group. Also, in the SOAP document in section 10.17,
   the rant field has the value iana-en:111 as expected. There is an error in
   the SOAP document in section 10.11. The rant field has the value
   iana-en:222 where it should have the value iana-en:111 that identifies SSP1.


Also, a new version of the REST draft is available at
http://tools.ietf.org/html/draft-marrache-drinks-spp-protocol-rest-02. It
would be great if you can take a look at it and comment.

Thanks,
Mickael