Re: [drinks] Following today's meeting

["Cartwright, Ken" <[e-mail]>]

Hi,

Thanks for these thoughts.  Very insightful.  My $.02 is as follows (sorry for any grammar/typos, putting this response together in a rush):

"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."

KJC:  I'd state it like this...The cardinality in the body of the framework document and in the XSD are already correct/whatWeIntended, 0..1.  But the diagram in the intro of the framework document incorrectly illustrates 0..n because it was a carry-over from the requirements document diagram, which was more notional (and was referring to the requirement that a given TN/TNRange/etc can be in one or more DGs, or not in a DG).  So we decided on the recent call that it would be best to change the diagram in the framework document to represent the implementation construct in the XSD that uses a PIType, rather than the notional concepts in the requirements document.  The operative point being that we are not really "changing" a cardinality, but are making a clerical correction to a diagram, albeit a good correction.  Good catch.

---

"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."

KJC:  Hierarchical relationships in REST URIs are "optional".  If the hierarchical relationship exists then it is in the URI, if it does not exist, then it is not in the URI.  So a reasonable approach to resolving your Rest URI question is to not implement the TNs/PIs->DG relationship as a mandatory hierarchy where the DG "contains" the TNs/PIs.  This can be accomplished in at least a couple ways as follows...


1)      Consider modeling the URI in a way that is analogous to the SOAP XSD;s approach, with an attribute of the TN/PI containing the DG relationship.    If you do that, then instead of having this: /rant/{rant}/TN/DGNAME/{dgName}/TN/{tn}
You'd have this:
/rant/{rant}/TN/{tn}/DG/{dgName}
Examples:
/rant/SomeCompany/TN/17039876543
/rant/SomeCompany/TN/13013456789/DG/NorthEast
In this approach your quandary goes away.  If there is no DG relationship, then that portion of the URI is just not necessary and is therefore not there.  Note that this is basically how the SOAP XSD design does it.


2)      You could alternatively do it like this:
/rant/{rant}/DG/{dgName}/TN/{tn}
Examples:
/rant/SomeCompany/DG/NorthEast/TN/17039876543
/rant/SomeCompany/TN/13019876543

Some TNs are "in" DGs and some are not.  There should be no issue with that approach either.

Imo, also adding in the concept of the PI to the URL may be a valid addition to the URIs, since they are all just types of PIs
/rant/{rant}/PI/{PIString}/DG/{dgName}
Examples:
/rant/SomeCompany/PI/Prefix/17039
/rant/SomeCompany/PI/TN/13019876543/DG/NorthEast
/rant/SomeCompany/PI/Range/13010000000-13019999999/DG/NorthEast
/rant/SomeCompany/PI/LRN/19059876543/DG/SouthEast

---


I also noticed that the text in section 3.1, bullet two, about Destination groups says "can be

      associated with one or more SED Groups".  That should say "can be associated with zero or more SED Groups"



---

"the corInfo element should be an attribute of the PI-DG association since it is not intrisic to the PI itself"



KJC:  I believe that the COR claim is intrinsic to the PI.  And putting it on an association between the PI and the DG would add further complexity to the XSD and the model.



In general, I think making this change would reduce the flexibility that is in the current model, while not reducing the complexity.



Thanks


From: [e-mail] [mailto:[e-mail]] On Behalf Of Mickael Marrache
Sent: Wednesday, April 24, 2013 2:51 PM
To: [e-mail]
Subject: [drinks] Following today's meeting

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

________________________________
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.