From kcartwright@tnsi.com Thu May 9 05:57:02 2013 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE9E21F8E9A for ; Thu, 9 May 2013 05:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8H4vkK0U6Ad for ; Thu, 9 May 2013 05:56:57 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4B421F8B27 for ; Thu, 9 May 2013 05:56:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAKGbi1GsEQfn/2dsb2JhbABICoJDe7dUiDOBEnSCHwEBBScGOgcEFwIBCBEEAQEhAQYHMhQJCAEBBAESCIgQwRCNbAqBAQQbCBABBoJuYQOTXYR1kzqBVg X-IronPort-AV: E=Sophos;i="4.87,641,1363132800"; d="scan'208,217";a="2407166" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 09 May 2013 13:43:59 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 9 May 2013 08:56:51 -0400 From: "Cartwright, Ken" To: Mickael Marrache , "drinks@ietf.org" Date: Thu, 9 May 2013 08:56:49 -0400 Thread-Topic: [drinks] Following today's meeting Thread-Index: Ac5BHO4n4ACJuABgTMSfhVummvos7wK3GjYg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B4254E341B54864B92D28BC2138A9DC30328C92048TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Following today's meeting X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 12:57:02 -0000 --_000_B4254E341B54864B92D28BC2138A9DC30328C92048TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 PubI= d-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/TN= Range/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 d= ocument to represent the implementation construct in the XSD that uses a PI= Type, 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. G= ood catch. --- "For example, an obvious URI for a TN resource would represent the key attr= ibutes 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 pro= blem by using a special string to represent the absence of a value, or by u= sing other types of URI parameters (e.g. query parameters), but I don't thi= nk it's the right way to go." KJC: Hierarchical relationships in REST URIs are "optional". If the hiera= rchical relationship exists then it is in the URI, if it does not exist, th= en it is not in the URI. So a reasonable approach to resolving your Rest U= RI 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 i= n at least a couple ways as follows... 1) Consider modeling the URI in a way that is analogous to the SOAP XS= D;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/{d= gName}/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 the= re. 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 additio= n 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 ass= ociated 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: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Mickael Marrache Sent: Wednesday, April 24, 2013 2:51 PM To: drinks@ietf.org 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 c= ardinality should not be interpreted as limiting a PI to be associated to a= t 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 "s= ame" telephone number may be associated to multiple DGs by the use of multi= ple 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 allowe= d. 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 o= bvious URI for a TN resource would represent the key attributes as path par= ameters 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 sp= ecial string to represent the absence of a value, or by using other types o= f 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 i= s 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, t= he maxOccurs attribute of the dgName element should be set to unbounded. Th= e 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 meani= ng to let a registrant organization provision the same PI (in terms of valu= e) 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). Cr= eating a new complex type DestGrpRefType that includes the DG key and the c= orInfo element would solve this issue. The list of dgName (ObjNameType) wou= ld become a list of dgRefs (DestGrpRefType). Not related to this question, there are two other points I raised in the ma= iling list: 1. The framework document states: "If the response to the Get operation i= ncludes object(s) that extend the BasicObjType, the Registry MUST include t= he 'cDate' and 'mDate', if applicable.". In the examples section in the SOA= P 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 o= riginating SSP to the registry. The originating SSP must be a peering organ= ization 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 fie= ld has the value iana-en:111 as expected. There is an error in the SOAP doc= ument in section 10.11. The rant field has the value iana-en:222 where it s= hould 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 Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_B4254E341B54864B92D28BC2138A9DC30328C92048TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,


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

 <= /p>

“During the call, we agreed that the cardinali= ty 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 ca= rdinality 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 fra= mework document incorrectly illustrates 0..n because it was a carry-over from the requirements document diagram, which was more no= tional (and was referring to the requirement that a given TN/TNRange/etc ca= n 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 cons= truct in the XSD that uses a PIType, rather than the notional concepts in t= he requirements document.  The operative point being that we are not r= eally “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 ty= pes of URI parameters (e.g. query parameters), but I don't think it's the r= ight way to go.”

 

KJC:  Hierarchical relationships in REST URIs a= re “optional”.  If the hierarchical relationship exists th= en 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 hierarc= hy where the DG “contains” the TNs/PIs.  This can be accom= plished in at least a couple ways as follows…

 

1)      Consider modeling the URI in a way that is analogou= s 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/170= 39876543

/rant/SomeCompany/TN/130= 13456789/DG/NorthEast

In this approach your qu= andary goes away.  If there is no DG relationship, then that portion o= f 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/Nor= thEast/TN/17039876543

/rant/SomeCompany/TN/130= 19876543

 

Some TNs are “in&#= 8221; DGs and some are not.  There should be no issue with that approa= ch 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<= o:p>

/rant/{rant}/PI/{PIString= }/DG/{dgName}

Examples:

/rant/SomeCompany/PI/Pref= ix/17039

/rant/SomeCompany/PI/TN/1= 3019876543/DG/NorthEast

/rant/SomeCompany/PI/Rang= e/13010000000-13019999999/DG/NorthEast

/rant/SomeCompany/PI/LRN/= 19059876543/DG/SouthEast

 

---

 

I also noticed that the text in section 3.1, bullet two, about Destina=
tion groups says “can be
      associated =
with one or more SED Groups”.  That should say “can be ass=
ociated with zero or more SED Groups”
 
---
“the corInfo element should b=
e 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 wou=
ld reduce the flexibility that is in the current model, while not reducing =
the complexity.
 
Thanks

 

 <= /p>

From: drinks-b= ounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Mickael Marrache
Sent: Wednesday, April 24, 2013 2:51 PM
To: drinks@ietf.org
Subject: [drinks] Following today's meeting

 

Hi,

 

During the call, we agreed that the cardinality on t= he 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 P= I to be associated to at most one DG. However, this cardinality should be interpreted as limiting a PI insta= nce to be associated to at most one DG. Thus, for example, the "same&q= uot; telephone number may be associated to multiple DGs by the use of multi= ple TN instances. This way is made possible by including the dgName element as part of the key, so that for a given re= gistrant and a given value (e.g. tn, tnp, start/end...), different values f= or the dgName element are allowed.

 

I think that the dgName element should not be part o= f the key because it is optional. While it may be acceptable for a key attr= ibute 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 suc= h as /rant/{rant}/TN/dgName/{dgName}/tn/{tn}. However, dgName is optional a= nd 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 d= gName element from the key. So, there would be only one PI instance for a p= articular 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 att= ribute of the dgName element should be set to unbounded. The registrant org= anization would only deal with one instance for a given PI value. The URI f= or the TN resource would then be /rant/{rant}/TN/{tn}.

 

Concerning the carrier-of-record concern, the questi= on is: Is there a meaning to let a registrant organization provision the sa= me 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 asso= ciation since it is not intrisic to the PI itself but depends on an externa= l factor (in this case, the association with a particular DG). Creating a new complex type DestGrpRefType that inc= ludes the DG key and the corInfo element would solve this issue. The list o= f dgName (ObjNameType) would become a list of dgRefs (DestGrpRefType).=

 

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

  1. The fr= amework document states: "If the response to the Get operation in= cludes object(s) that extend the BasicObjType, the Registry MUST inclu= de the 'cDate' and 'mDate', if applicable.". In the examples= section in the SOAP document (section 10), for the Get examples, the elements cDat= e and mDate are not part of the returned responses.
    2. <= li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto;mso-list:l4 level1 lfo1"> Accord= ing 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, th= e 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-protoco= l-rest-02. It would be great if you can take a look at it and comment.

 

Thanks,

Mickael


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

 --_000_B4254E341B54864B92D28BC2138A9DC30328C92048TNSMAILNAwin2_-- From mickaelmarrache@gmail.com Thu May 9 07:14:32 2013 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F2721F89AF for ; Thu, 9 May 2013 07:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3343vGCKKSov for ; Thu, 9 May 2013 07:14:31 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBAB21F8960 for ; Thu, 9 May 2013 07:14:29 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id fm20so2832729lab.25 for ; Thu, 09 May 2013 07:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=NqzSy9lcJ0KM4dhJU/5mB9ltTn8dwE+wrUJbEkZDkqs=; b=bABHHXXoK5hatDy2Y3EhzKONweWsFtVO15EVlEyQIIy2eGCgRogpuN47mh85u7PMiC OupcQFQOaLGLdjce1Dd2Bs/5jyAB1uWrOrztfjqc2zGbJ6ER5fkHexhb6Ddgm9Rm0GQQ 78Q9scjXJcJbAHUhVuIAXFsvD2ulNvuF18kXw5510VlA8jURxy/VSTbjybsM0rrdMxcU nN/SXbV1HgyjDVzOuhZIZu1cULsOd1qj3H5UUQB999GapSo8W2NI46ePfI4stcCeeHo2 T/1ag/hTWr2yklaER5pTpKzLF5/fdq1zkKRKXcWHg1boXL+DxFjCwSgys6un19+zffFZ a1qg== MIME-Version: 1.0 X-Received: by 10.152.116.113 with SMTP id jv17mr5546698lab.35.1368108868973; Thu, 09 May 2013 07:14:28 -0700 (PDT) Received: by 10.114.184.20 with HTTP; Thu, 9 May 2013 07:14:28 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 May 2013 17:14:28 +0300 Message-ID: From: Mickael Marrache To: "Cartwright, Ken" , drinks@ietf.org Content-Type: multipart/alternative; boundary=001a11c3657a2639e804dc49abee Subject: Re: [drinks] Following today's meeting X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 14:14:32 -0000 --001a11c3657a2639e804dc49abee Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Concerning the first point, this is what I meant. I just explained the current approach as a prerequisite for the next part. Concerning the second point, I think you don't answer the real question. Firstly, using optional path parameters introduces an implementation issue. Also, JAX-RS, which will probably be the most used solution for implementing SPPP over REST in Java, does not support easily optional parameters (see http://www.nakov.com/blog/2009/07/15/jax-rs-path-pathparam-and-optional-par= ameters/). There are workarounds to this "issue" but this lack of support shows this is a rare way of defining URIs in REST. Optional path parameters are generally discouraged in REST. I think the real question is why to include the name of the destination group as part of the PI key, not how to represent optional path parameters in REST. Also, I don't see how excluding the dgName from the PI key would reduce flexibility of the model. On the other hand, I think that including the dgName as part of the PI key increases complexity of RESTful implementations for the reasons I mentioned in the previous paragraph. Also, I think that defining two URI templates for PIs (one for PIs that are part of DGs and another for PIs that are not part of DGs) makes the REST API less intuitive for the clients, and adds complexity for implementors. I don't really see enough advantages with the current model, that would convince me to accept this implementation complexity. Concerning the COR aspect, it's only a question we raised during the last meeting. I agree that the COR is intrinsic to the PI, so we don't need to move it at the PI-DG association level. Thanks, Mickael On Thu, May 9, 2013 at 3:56 PM, Cartwright, Ken wrote= : > Hi,**** > > > Thanks for these thoughts. Very insightful. My $.02 is as follows (sorr= y > for any grammar/typos, putting this response together in a rush):**** > > ** ** > > =93During the call, we agreed that the cardinality on the DG side of the > PubId-DG association should be 0..1 instead of 0...n.=94**** > > ** ** > > KJC: I=92d state it like this=85The cardinality in the body of the frame= work > document and in the XSD are already correct/whatWeIntended, 0..1. But th= e > 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 =93changing= =94 a > cardinality, but are making a clerical correction to a diagram, albeit a > good correction. Good catch.**** > > ** ** > > ---**** > > ** ** > > =93For 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.=94**** > > ** ** > > KJC: Hierarchical relationships in REST URIs are =93optional=94. 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 a= s > a mandatory hierarchy where the DG =93contains=94 the TNs/PIs. This can = be > accomplished in at least a couple ways as follows=85**** > > ** ** > > **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=92d 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 =93in=94 DGs and some are not. There should be no issue wit= h > 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 Destinatio= n groups says =93can be**** > > associated with one or more SED Groups=94. That should say =93can = be associated with zero or more SED Groups=94**** > > ** ** > > ---**** > > =93the corInfo element should be an attribute of the PI-DG association si= nce it is not intrisic to the PI itself=94**** > > ** ** > > KJC: I believe that the COR claim is intrinsic to the PI. And putting i= t 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:* drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] *On > Behalf Of *Mickael Marrache > *Sent:* Wednesday, April 24, 2013 2:51 PM > *To:* drinks@ietf.org > *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 possib= le > 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 valu= es > 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 optiona= l > 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 th= e > 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 DG= s, > 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 (DestGrpRefTyp= e). > **** > > ** ** > > 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 Registr= y > 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 pee= ring > 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.1= 7, > the rant field has the value iana-en:111 as expected. There is an erro= r 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 m= ay > contain confidential and privileged information of Transaction Network > Services. > Any unauthorised review, use, disclosure or distribution is prohibited. I= f > you > are not the intended recipient, please contact the sender by reply e-mail > and destroy all copies of the original message. > > --001a11c3657a2639e804dc49abee Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,

Concerning the first point, this is what I mean= t. I just explained the current approach as a prerequisite for the next par= t.

Concerning the second point, I think you don't answer the rea= l question.

Firstly, using optional path parameters introduces an implementation is= sue. Also, JAX-RS, which will probably be the most used solution for implem= enting SPPP over REST in Java, does=20 not support easily optional parameters (see http://www= .nakov.com/blog/2009/07/15/jax-rs-path-pathparam-and-optional-parameters/). There are workarounds to this=20 "issue" but this lack of support shows this is a rare way of defi= ning=20 URIs in REST. Optional path parameters are generally discouraged in REST.
I think the real question is why to include the name of the destinati= on group as part of the PI key, not how to represent optional path paramete= rs in REST. Also, I don't see how excluding the dgName from the PI key = would reduce flexibility of the model. On the other hand, I think that incl= uding the dgName as part of the PI key increases complexity of RESTful impl= ementations for the reasons I mentioned in the previous paragraph. Also, I = think that defining two URI templates for PIs (one for PIs that are part of= DGs and another for PIs that are not part of DGs) makes the REST API less = intuitive for the clients, and adds complexity for implementors. I don'= t really see enough advantages with the current model, that would convince = me to accept this implementation complexity.

Concerning the COR aspect, it's only a question we raised during th= e last meeting. I agree that the COR is intrinsic to the PI, so we don'= t need to move it at the PI-DG association level.

Thanks,
Mickael=

On Thu, May 9, 2013 at 3:56 PM, Cartwright, = Ken <kcartwright@tnsi.com> wrote:

Hi,<= /p>


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

=A0<= /p>

=93During the call, we agreed that the cardinality o= n the DG side of the PubId-DG association should be 0..1 instead of 0...n.= =94

=A0

KJC:=A0 I=92d state it like this=85The cardinality i= n the body of the framework document and in the XSD are already correct/wha= tWeIntended, 0..1.=A0 But the diagram in the intro of the framework documen= t incorrectly illustrates 0..n because it was a carry-over from the requirements document diagram, which was more no= tional (and was referring to the requirement that a given TN/TNRange/etc ca= n be in one or more DGs, or not in a DG).=A0 So we decided on the recent ca= ll that it would be best to change the diagram in the framework document to represent the implementation cons= truct in the XSD that uses a PIType, rather than the notional concepts in t= he requirements document.=A0 The operative point being that we are not real= ly =93changing=94 a cardinality, but are making a clerical correction to a diagram, albeit a good correction.=A0 Go= od catch.

=A0

---

=A0

=93For example, an obvious URI for a TN resource wou= ld 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 val= ue. We can solve this problem by using a special string to represent the absence of a value, or by using other ty= pes of URI parameters (e.g. query parameters), but I don't think it'= ;s the right way to go.=94

=A0

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

=A0

1)= =A0=A0=A0=A0=A0 Consider modeling the URI in a way that is analogous t= o the SOAP XSD;s approach, with an attribute of the TN/PI containing the DG= relationship.=A0 =A0=A0If you do that, then instead of having this: /rant/= {rant}/TN/DGNAME/{dgName}/TN/{tn}

You=92d have this:

/rant/{rant}/TN/{tn}/DG/= {dgName}

Examples:=A0 <= /u>

/rant/SomeCompany/TN/170= 39876543

/rant/SomeCompany/TN/130= 13456789/DG/NorthEast

In this approach your qu= andary goes away.=A0 If there is no DG relationship, then that portion of t= he URI is just not necessary and is therefore not there.=A0 Note that this = is basically how the SOAP XSD design does it.

=A0

2)= =A0=A0=A0=A0=A0 You could alternatively do it like this:=

/rant/{rant}/DG/{dgName}= /TN/{tn}

Examples:<= /p>

/rant/SomeCompany/DG/Nor= thEast/TN/17039876543

/rant/SomeCompany/TN/130= 19876543

=A0

Some TNs are =93in=94 DG= s and some are not.=A0 There should be no issue with that approach either.<= u>

=A0

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<= u>

/rant/{rant}/PI/{PIString= }/DG/{dgName}

Examples:

/rant/SomeCompany/PI/Pref= ix/17039

/rant/SomeCompany/PI/TN/1= 3019876543/DG/NorthEast

/rant/SomeCompany/PI/Rang= e/13010000000-13019999999/DG/NorthEast

/rant/SomeCompany/PI/LRN/= 19059876543/DG/SouthEast

=A0

---

=A0

I also noticed that the text in section 3.1, bullet two, about Destina=
tion groups says =93can be
=A0=A0=A0=A0=A0 associated with one or more SED Groups=94.=
=A0 That should say =93can be associated with zero or more SED Groups=94=

=A0
---
=93the corInfo element should be an attribute of th=
e PI-DG association since it is not intrisic to the PI itself=94<=
/u>
=A0
KJC:=A0 I believe that the COR claim is intrinsic to the P=
I.=A0 And putting it on an association between the PI and the DG would add =
further complexity to the XSD and the model.
=A0
In general, I think making this change would reduce the fl=
exibility that is in the current model, while not reducing the complexity.<=
u>
=A0
Thanks

=A0

=A0<= /p>

From: drinks-bounces@ietf.o= rg [mailto:drinks-bounces@ietf.org] On Behalf Of Mickael Marrache
Sent: Wednesday, April 24, 2013 2:51 PM
To: drinks@ietf= .org
Subject: [drinks] Following today's meeting=

=A0

Hi,

=A0

During the call, we agreed that the cardinality on t= he 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 P= I to be associated to at most one DG. However, this cardinality should be interpreted as limiting a PI insta= nce to be associated to at most one DG. Thus, for example, the "same&q= uot; telephone number may be associated to multiple DGs by the use of multi= ple TN instances. This way is made possible by including the dgName element as part of the key, so that for a given re= gistrant and a given value (e.g. tn, tnp, start/end...), different values f= or the dgName element are allowed.

=A0

I think that the dgName element should not be part o= f the key because it is optional. While it may be acceptable for a key attr= ibute 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 suc= h as /rant/{rant}/TN/dgName/{dgName}/tn/{tn}. However, dgName is optional a= nd 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.

=A0

What I proposed during the call was to exclude the d= gName element from the key. So, there would be only one PI instance for a p= articular 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 att= ribute of the dgName element should be set to unbounded. The registrant org= anization would only deal with one instance for a given PI value. The URI f= or the TN resource would then be /rant/{rant}/TN/{tn}.

=A0

Concerning the carrier-of-record concern, the questi= on is: Is there a meaning to let a registrant organization provision the sa= me 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 asso= ciation since it is not intrisic to the PI itself but depends on an externa= l factor (in this case, the association with a particular DG). Creating a new complex type DestGrpRefType that inc= ludes the DG key and the corInfo element would solve this issue. The list o= f dgName (ObjNameType) would become a list of dgRefs (DestGrpRefType).

=A0

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

  1. The fr= amework document states:=A0"If the response to the Get operation inclu= des object(s) that extend=A0the BasicObjType, the Registry MUST include the= 'cDate' and 'mDate',=A0if applicable.".=A0In the exam= ples section in the SOAP document (section 10), for the Get examples, the elements cDat= e and mDate are not part of the returned responses.
  2. Accord= ing 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, th= e 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.

=A0

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

=A0

Thanks,

Mickael


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

--001a11c3657a2639e804dc49abee-- From kcartwright@tnsi.com Thu May 9 07:36:17 2013 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F1521F850E for ; Thu, 9 May 2013 07:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhvPXCBtYjov for ; Thu, 9 May 2013 07:36:10 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB0C21F84F9 for ; Thu, 9 May 2013 07:36:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusEACOzi1GsEQfn/2dsb2JhbABICoJDe7dTiDOBEHSCHwEBBRoNBjoHBBcCAQgRBAEBIQEGByERFAkIAQEEARIIE4dfAxu1KQ2IGoxSgRoKgQEEGwgQAQaCbmEDk12Ba4MKim2ITYFW X-IronPort-AV: E=Sophos;i="4.87,641,1363132800"; d="scan'208,217";a="2407487" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 09 May 2013 15:23:09 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 9 May 2013 10:36:02 -0400 From: "Cartwright, Ken" To: Mickael Marrache , "drinks@ietf.org" Date: Thu, 9 May 2013 10:36:00 -0400 Thread-Topic: [drinks] Following today's meeting Thread-Index: Ac5Mv4cCMrFeumrzQ9+OyIfjhlf04gAAI/Aw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B4254E341B54864B92D28BC2138A9DC30328C920A5TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Following today's meeting X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 14:36:17 -0000 --_000_B4254E341B54864B92D28BC2138A9DC30328C920A5TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok. My apologies if I "didn't answer the key question" in the way you want= ed. I think I responded directly to your points. And I think that the URL= structures that I propose are very clean and intuitive, not complicated or= esoteric. You did not say anything about "optional parameters" until this= reply. So perhaps I can now speak to that question now that you have pose= d it. The model in the doc is what it is, if the group decides to change i= t, then so be it. But, SOAP has no issue dealing with it and I believe tha= t Rest has no real issue dealing with it either, and as I stated I think th= e resulting URL structure is very clear and simple. I also do not really s= ee this as an "optional parameter" type situation. The example in the link= you describe was speaking to someone wanting to put a "format" selection i= n the main body of the output URL path so that they know if it is XML or JS= ON or etc. The situation here is more of including a hierarchical relatio= nship as part of the URL path, which is done all the time. And of course n= ot all objects in a model will always have the same hierarchical relationsh= ips. But, that's my $.02. Take it fwiw. :) Ken From: Mickael Marrache [mailto:mickaelmarrache@gmail.com] Sent: Thursday, May 09, 2013 10:14 AM To: Cartwright, Ken; drinks@ietf.org Subject: Re: [drinks] Following today's meeting Hi, Concerning the first point, this is what I meant. I just explained the curr= ent approach as a prerequisite for the next part. Concerning the second point, I think you don't answer the real question. Firstly, using optional path parameters introduces an implementation issue.= Also, JAX-RS, which will probably be the most used solution for implementi= ng SPPP over REST in Java, does not support easily optional parameters (see= http://www.nakov.com/blog/2009/07/15/jax-rs-path-pathparam-and-optional-pa= rameters/). There are workarounds to this "issue" but this lack of support = shows this is a rare way of defining URIs in REST. Optional path parameters= are generally discouraged in REST. I think the real question is why to include the name of the destination gro= up as part of the PI key, not how to represent optional path parameters in = REST. Also, I don't see how excluding the dgName from the PI key would redu= ce flexibility of the model. On the other hand, I think that including the = dgName as part of the PI key increases complexity of RESTful implementation= s for the reasons I mentioned in the previous paragraph. Also, I think that= defining two URI templates for PIs (one for PIs that are part of DGs and a= nother for PIs that are not part of DGs) makes the REST API less intuitive = for the clients, and adds complexity for implementors. I don't really see e= nough advantages with the current model, that would convince me to accept t= his implementation complexity. Concerning the COR aspect, it's only a question we raised during the last m= eeting. I agree that the COR is intrinsic to the PI, so we don't need to mo= ve it at the PI-DG association level. Thanks, Mickael On Thu, May 9, 2013 at 3:56 PM, Cartwright, Ken > wrote: 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 PubI= d-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/TN= Range/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 d= ocument to represent the implementation construct in the XSD that uses a PI= Type, 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. G= ood catch. --- "For example, an obvious URI for a TN resource would represent the key attr= ibutes 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 pro= blem by using a special string to represent the absence of a value, or by u= sing other types of URI parameters (e.g. query parameters), but I don't thi= nk it's the right way to go." KJC: Hierarchical relationships in REST URIs are "optional". If the hiera= rchical relationship exists then it is in the URI, if it does not exist, th= en it is not in the URI. So a reasonable approach to resolving your Rest U= RI 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 i= n at least a couple ways as follows... 1) Consider modeling the URI in a way that is analogous to the SOAP XS= D;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/{d= gName}/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 the= re. 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 additio= n 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 ass= ociated 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: drinks-bounces@ietf.org [mailto:drink= s-bounces@ietf.org] On Behalf Of Mickael Ma= rrache Sent: Wednesday, April 24, 2013 2:51 PM To: drinks@ietf.org 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 c= ardinality should not be interpreted as limiting a PI to be associated to a= t 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 "s= ame" telephone number may be associated to multiple DGs by the use of multi= ple 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 allowe= d. 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 o= bvious URI for a TN resource would represent the key attributes as path par= ameters 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 sp= ecial string to represent the absence of a value, or by using other types o= f 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 i= s 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, t= he maxOccurs attribute of the dgName element should be set to unbounded. Th= e 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 meani= ng to let a registrant organization provision the same PI (in terms of valu= e) 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). Cr= eating a new complex type DestGrpRefType that includes the DG key and the c= orInfo element would solve this issue. The list of dgName (ObjNameType) wou= ld become a list of dgRefs (DestGrpRefType). Not related to this question, there are two other points I raised in the ma= iling list: 1. The framework document states: "If the response to the Get operation i= ncludes object(s) that extend the BasicObjType, the Registry MUST include t= he 'cDate' and 'mDate', if applicable.". In the examples section in the SOA= P 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 o= riginating SSP to the registry. The originating SSP must be a peering organ= ization 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 fie= ld has the value iana-en:111 as expected. There is an error in the SOAP doc= ument in section 10.11. The rant field has the value iana-en:222 where it s= hould 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 Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_B4254E341B54864B92D28BC2138A9DC30328C920A5TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok.  My apologies if= I “didn’t answer the key question” in the way you wanted= .  I think I responded directly to your points.  And I think that= the URL structures that I propose are very clean and intuitive, not complicated or esoteric. =  You did not say anything about “optional parameters” unti= l this reply.  So perhaps I can now speak to that question now that yo= u have posed it.  The model in the doc is what it is, if the group decides to change it, then so be it.  But, SOAP has no i= ssue dealing with it and I believe that Rest has no real issue dealing with= it either, and as I stated I think the resulting URL structure is very cle= ar and simple.  I also do not really see this as an “optional parameter” type situation.  The = example in the link you describe was speaking to someone wanting to put a &= #8220;format” selection in the main body of the output URL path so th= at they know if it is XML or JSON or etc.  The situation here is more of including a  hierarchical relationship as part of the URL = path, which is done all the time.  And of course not all objects in a = model will always have the same hierarchical relationships.

 <= /p>

But, that’s my $.02= .  Take it fwiw.  J

 <= /p>

Ken

 <= /p>

From: Mickael = Marrache [mailto:mickaelmarrache@gmail.com]
Sent: Thursday, May 09, 2013 10:14 AM
To: Cartwright, Ken; drinks@ietf.org
Subject: Re: [drinks] Following today's meeting

 

Hi,

Concerning the first point, this is what I meant. I just explained the curr= ent approach as a prerequisite for the next part.

Concerning the second point, I think you don't answer the real question.
Firstly, using optional path parameters introduces an implementation issue.= Also, JAX-RS, which will probably be the most used solution for implementi= ng SPPP over REST in Java, does not support easily optional parameters (see http://www.nakov.com/blog/2009/07/15/jax-rs-path-pathparam-and-optional-par= ameters/). There are workarounds to this "issue" but this lac= k of support shows this is a rare way of defining URIs in REST. Optional pa= th parameters are generally discouraged in REST.

I think the real question is why to include the name of the destination gro= up as part of the PI key, not how to represent optional path parameters in = REST. Also, I don't see how excluding the dgName from the PI key would redu= ce flexibility of the model. On the other hand, I think that including the dgName as part of the PI key in= creases complexity of RESTful implementations for the reasons I mentioned i= n the previous paragraph. Also, I think that defining two URI templates for= PIs (one for PIs that are part of DGs and another for PIs that are not part of DGs) makes the REST API le= ss intuitive for the clients, and adds complexity for implementors. I don't= really see enough advantages with the current model, that would convince m= e to accept this implementation complexity.

Concerning the COR aspect, it's only a question we raised during the last m= eeting. I agree that the COR is intrinsic to the PI, so we don't need to mo= ve it at the PI-DG association level.

Thanks,
Mickael

On Thu, May 9, 2013 at 3:56 PM, Cartwright, Ken <= kcartwright@tnsi.= com> wrote:

Hi,


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

 

“During the call, we agreed that the cardinality on the DG s= ide of the PubId-DG association should be 0..1 instead of 0...n.”

 

KJC:  I’d state it like this…The cardinality in t= he body of the framework document and in the XSD are already correct/whatWe= Intended, 0..1.  But the diagram in the intro of the framework document incorrectly illustrates 0..n because it was a carry-ove= r 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 m= ore 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 makin= g a clerical correction to a diagram, albeit a good correction.  Good = catch.

 

---

 

“For example, an obvious URI for a TN resource would represe= nt the key attributes as path parameters such as /rant/{rant}/TN/dgName/{dg= Name}/tn/{tn}. However, dgName is optional and may not have a value. We can solve this problem by using a special str= ing to represent the absence of a value, or by using other types of URI par= ameters (e.g. query parameters), but I don't think it's the right way to go= .”

 

KJC:  Hierarchical relationships in REST URIs are “opti= onal”.  If the hierarchical relationship exists then it is in th= e 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 implem= ent the TNs/PIs->DG relationship as a mandatory hierarchy where the DG &= #8220;contains” the TNs/PIs.  This can be accomplished in at lea= st a couple ways as follows…

 

1)      = Consider modeling the URI in a way that is analogous to the SOAP XSD;s appr= oach, with an attribute of the TN/PI containing the DG relationship.  =   If you do that, then instead of having this: /rant/{rant}/TN/DG= NAME/{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 relations= hip, then that portion of the URI is just not necessary and is therefore no= t 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 n= o issue with that approach either.

 

Imo, also adding in the concept of the PI to the URL may be a vali= d 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<= /p>

/rant/SomeCompany/PI/LRN/19059876543/DG/SouthEast

 

---

 

I also noticed that the text in section 3.1, bullet two, about Destina=
tion groups says “can be
      associated with one or more SED Groups&=
#8221;.  That should say “can be associated with zero or more SE=
D Groups”
 
---
“the corInfo element should be an attribute of the PI-DG associa=
tion 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 furthe=
r complexity to the XSD and the model.
 
In general, I think making this change would reduce the flexibility th=
at is in the current model, while not reducing the complexity.

 


Thanks


 


 


From:
drinks-bounces=
@ietf.org [mailto:drinks-bounces@ietf.org]
On Behalf Of Mickael Marrache

Sent: Wednesday, April 24, 20=
13 2:51 PM

To: drinks@ietf=
.org

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 th=
at this cardinality should not be interpreted
 as limiting a PI to be associated to at most one DG. However, this cardina=
lity 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 e=
lement 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 beca=
use it is optional. While it may be acceptable for a key attribute to be op=
tional in some cases, I think it's relatively
 rare. Also, it becomes more difficult to define a URI for each public iden=
tifier concrete type. For example, an obvious URI for a TN resource would r=
epresent the key attributes as path parameters such as /rant/{rant}/TN/dgNa=
me/{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 type=
s of URI parameters (e.g. query parameters), but I don't think it's the rig=
ht 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 valu=
e, that is identified by the registrant
 that owns the PI, and the value of the PI (e.g. tn, tnp...). In order to a=
llow a PI to be associated to multiple DGs, the maxOccurs attribute of the =
dgName element should be set to unbounded. The registrant organization woul=
d only deal with one instance for
 a given PI value. The URI for the TN resource would then be /rant/{rant}/T=
N/{tn}.






 






Concerning the carrier-of-record concern, the question is: Is ther=
e a meaning to let a registrant organization provision the same PI (in term=
s of value) with different COR information?
 The current model allows such a feature by the use of multiple PI instance=
s (thus, allowing multiple corInfos). If this is a real use case, the corIn=
fo 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 t=
he 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 fr=
amework document states: "If the response to the Get operation in=
cludes object(s) that extend the BasicObjType, the Registry MUST inclu=
de the 'cDate' and 'mDate', if applicable.". In the examples=
 section
 in the SOAP document (section 10), for the Get examples, the elements cDat=
e and mDate are not part of the returned responses.
    2. <=
li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;mso-list:l0 level1 lfo1">
Accord=
ing 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, th=
e 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-pro=
tocol-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 Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 


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

 --_000_B4254E341B54864B92D28BC2138A9DC30328C920A5TNSMAILNAwin2_-- From vbhatia@tnsi.com Thu May 9 08:01:02 2013 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7535421F853A for ; Thu, 9 May 2013 08:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkMQCrWWN7KF for ; Thu, 9 May 2013 08:00:58 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id C19E721F8539 for ; Thu, 9 May 2013 08:00:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoEAAC5i1GsEQfn/2dsb2JhbABICoJDe7dTiDOBEHSCHwEBBS06BxsCAQgRBAEBKAcyFAkIAQEEARIIiBC9U41mBgqBAQQzAQaCbmEDk12EdZM6gVY X-IronPort-AV: E=Sophos;i="4.87,641,1363132800"; d="scan'208,217";a="2407589" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 09 May 2013 15:48:03 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 9 May 2013 11:00:56 -0400 From: "Bhatia, Vikas" To: Mickael Marrache , "drinks@ietf.org" Date: Thu, 9 May 2013 11:00:55 -0400 Thread-Topic: [drinks] Following today's meeting Thread-Index: Ac5BHO4n4ACJuABgTMSfhVummvos7wLp7Pxg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B4254E341B54864B92D28BC2138A9DC30328C920CDTNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Following today's meeting X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 15:01:02 -0000 --_000_B4254E341B54864B92D28BC2138A9DC30328C920CDTNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable W.r.t the following two points from the email below =3D=3D=3D Not related to this question, there are two other points I raised in the ma= iling list: 1. The framework document states: "If the response to the Get operation i= ncludes object(s) that extend the BasicObjType, the Registry MUST include t= he 'cDate' and 'mDate', if applicable.". In the examples section in the SOA= P 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 o= riginating SSP to the registry. The originating SSP must be a peering organ= ization 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 fie= ld has the value iana-en:111 as expected. There is an error in the SOAP doc= ument in section 10.11. The rant field has the value iana-en:222 where it s= hould have the value iana-en:111 that identifies SSP1. For #1 - "cDate" is part of all GET examples (http://tools.ietf.org/html/dr= aft-ietf-drinks-spp-protocol-over-soap-03.txt). "mDate" is an optional para= meter that comes only if the record has been modified. The framework docume= nt section 7.3 says "the Registry MUST include the 'cDate' and 'mDate', i= f applicable.", "if applicable" is key. For #2 - Its just an example and each example can be seen in isolation. The= document does not state that SSP1 has registrant ID "iana-en:11" always. Thanks, Vikas From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Mickael Marrache Sent: Wednesday, April 24, 2013 2:51 PM To: drinks@ietf.org 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 c= ardinality should not be interpreted as limiting a PI to be associated to a= t 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 "s= ame" telephone number may be associated to multiple DGs by the use of multi= ple 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 allowe= d. 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 o= bvious URI for a TN resource would represent the key attributes as path par= ameters 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 sp= ecial string to represent the absence of a value, or by using other types o= f 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 i= s 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, t= he maxOccurs attribute of the dgName element should be set to unbounded. Th= e 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 meani= ng to let a registrant organization provision the same PI (in terms of valu= e) 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). Cr= eating a new complex type DestGrpRefType that includes the DG key and the c= orInfo element would solve this issue. The list of dgName (ObjNameType) wou= ld become a list of dgRefs (DestGrpRefType). Not related to this question, there are two other points I raised in the ma= iling list: 1. The framework document states: "If the response to the Get operation i= ncludes object(s) that extend the BasicObjType, the Registry MUST include t= he 'cDate' and 'mDate', if applicable.". In the examples section in the SOA= P 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 o= riginating SSP to the registry. The originating SSP must be a peering organ= ization 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 fie= ld has the value iana-en:111 as expected. There is an error in the SOAP doc= ument in section 10.11. The rant field has the value iana-en:222 where it s= hould 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 Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_B4254E341B54864B92D28BC2138A9DC30328C920CDTNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

W.r.t the following two p= oints from the email below

 <= /p>

=3D=3D=3D

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

  1. The fr= amework document states: "If the response to the Get operation in= cludes object(s) that extend the BasicObjType, the Registry MUST inclu= de the 'cDate' and 'mDate', if applicable.". In the examples= section in the SOAP document (section 10), for the Get examples, the elements cDat= e and mDate are not part of the returned responses.
  2. Accord= ing 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, th= e 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.

&= nbsp;

For #1= – “cDate” is part of all GET examples (http://tools.ietf= .org/html/draft-ietf-drinks-spp-protocol-over-soap-03.txt). “mDate= 221; is an optional parameter that comes only if the record has been modifi= ed. The framework document section 7.3 says &= #8220;the Registry MUST include the 'cDate' and 'mDate',   if a= pplicable.”, “if applicable” is key.

For #2= – Its just an example and each example can be seen in isolation. The= document does not state that SSP1 has registrant ID “iana-en:11R= 21; always.

 

Thanks,

Vikas

From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org= ] On Behalf Of Mickael Marrache
Sent: Wednesday, April 24, 2013 2:51 PM
To: drinks@ietf.org
Subject: [drinks] Following today's meeting

 

Hi,

 

During the call, we agre= ed that the cardinality on the DG side of the PubId-DG association should b= e 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 interpre= ted as limiting a PI instance to be associated to at most one DG. Thus, for= example, the "same" telephone number may be associated to multip= le DGs by the use of multiple TN instances. This way is made possible by including the dgName element as part of the k= ey, so that for a given registrant and a given value (e.g. tn, tnp, start/e= nd...), 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. F= or example, an obvious URI for a TN resource would represent the key attrib= utes as path parameters such as /rant/{rant}/TN/dgName/{dgName}/tn/{tn}. Ho= wever, dgName is optional and may not have a value. We can solve this problem by using a special string to r= epresent 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 t= he 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 regi= strant that owns the PI, and the value of the PI (e.g. tn, tnp...). In order to allow a PI to be associated to mu= ltiple DGs, the maxOccurs attribute of the dgName element should be set to = unbounded. The registrant organization would only deal with one instance fo= r a given PI value. The URI for the TN resource would then be /rant/{rant}/TN/{tn}.

 

Concerning the carrier-o= f-record concern, the question is: Is there a meaning to let a registrant o= rganization provision the same PI (in terms of value) with different COR in= formation? The current model allows such a feature by the use of multiple PI instances (thus, allowing multipl= e corInfos). If this is a real use case, the corInfo element should be an a= ttribute 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 compl= ex type DestGrpRefType that includes the DG key and the corInfo element wou= ld solve this issue. The list of dgName (ObjNameType) would become a list o= f dgRefs (DestGrpRefType).

 

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

  1. The fr= amework document states: "If the response to the Get operation in= cludes object(s) that extend the BasicObjType, the Registry MUST inclu= de the 'cDate' and 'mDate', if applicable.". In the examples= section in the SOAP document (section 10), for the Get examples, the elements cDat= e and mDate are not part of the returned responses.
    2. <= li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto;margin-left:.75in;mso-list:l0 level1 lfo1"> Accord= ing 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, th= e 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 RES= T 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 t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_B4254E341B54864B92D28BC2138A9DC30328C920CDTNSMAILNAwin2_-- From kcartwright@tnsi.com Fri May 10 11:39:09 2013 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8126021F90C3 for ; Fri, 10 May 2013 11:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3aQnfTpP9bF for ; Fri, 10 May 2013 11:39:01 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6046A21F902D for ; Fri, 10 May 2013 11:38:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcEAK89jVGsEQfn/2dsb2JhbABICoJDe7ddiD6BEnSCHwEBBRoNBjoHBBcCAQgRBAEBIQEGByERFAkIAQEEARIIE4dfAxu1Og2IIoxSgRoKgQEEBxQIEAeCbmEDk12Ba4MKim2ITYFW X-IronPort-AV: E=Sophos;i="4.87,650,1363132800"; d="scan'208,217";a="2411470" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 10 May 2013 19:25:58 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 10 May 2013 14:38:56 -0400 From: "Cartwright, Ken" To: Mickael Marrache , "drinks@ietf.org" Date: Fri, 10 May 2013 14:38:54 -0400 Thread-Topic: [drinks] Following today's meeting Thread-Index: Ac5Mv4cCMrFeumrzQ9+OyIfjhlf04gAAI/AwADYPLlA= Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B4254E341B54864B92D28BC2138A9DC30328C9231ETNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Following today's meeting X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 18:39:09 -0000 --_000_B4254E341B54864B92D28BC2138A9DC30328C9231ETNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And not that I've given the REST mapping any deep thought, but the more I t= hink about it, the more it seems to me that the below is clear/simple/good = and would support what the model says should be supported. I also see no r= eason why a Rest implementation would have issues with this (in fact it loo= ks like vanilla Rest to me). There are many examples in the real world of = needing to work with objects that reside inside _and_ outside of some hiera= rchical container/collection. Rest certainly supports that very easily. I= can also think of a couple other approaches and variations of the approach= below that also make sense. Given this, I can't see a reason why the Res= t question that arose would necessitate a change to the model. //How to list and get one or more rants - but this may or may not not be a = feature that is supported sppapi.example.com/rants/{rantIdentifier} sppapi.example.com/rants //For a given Rant, how to list and get one or more of the Dest Groups sppapi.example.com/rants/{rantIdentifier}/destGroups/{destGroupIdentifier} sppapi.example.com/rants/{rantIdentifier}/destGroups //For a given Rant, how to list and get one or more PIs/TNs associated with= (in) a Dest Group sppapi.example.com/rants/{rantIdentifier}/destGroups/{destGroupIdentifier}/= TNs/{tnIdentifier} sppapi.example.com/rants/{rantIdentifier}/destGroups/{destGroupIdentifier}/= TNs //For a given Rant, how to list and get one or more PIs/TNs not associated = with (not in) a Dest Group sppapi.example.com/rants/{rantIdentifier}/TNs/{tnIdentifier} sppapi.example.com/rants/{rantIdentifier}/TNs //For a given Rant, how to list and get one or more SEDGroups sppapi.example.com/rants/{rantIdentifier}/SEDGroups/{sedGroupIdentifier} sppapi.example.com/rants/{rantIdentifier}/SEDGroups //etc, etc for other object types From: Cartwright, Ken Sent: Thursday, May 09, 2013 10:36 AM To: 'Mickael Marrache'; drinks@ietf.org Subject: RE: [drinks] Following today's meeting Ok. My apologies if I "didn't answer the key question" in the way you want= ed. I think I responded directly to your points. And I think that the URL= structures that I propose are very clean and intuitive, not complicated or= esoteric. You did not say anything about "optional parameters" until this= reply. So perhaps I can now speak to that question now that you have pose= d it. The model in the doc is what it is, if the group decides to change i= t, then so be it. But, SOAP has no issue dealing with it and I believe tha= t Rest has no real issue dealing with it either, and as I stated I think th= e resulting URL structure is very clear and simple. I also do not really s= ee this as an "optional parameter" type situation. The example in the link= you describe was speaking to someone wanting to put a "format" selection i= n the main body of the output URL path so that they know if it is XML or JS= ON or etc. The situation here is more of including a hierarchical relatio= nship as part of the URL path, which is done all the time. And of course n= ot all objects in a model will always have the same hierarchical relationsh= ips. But, that's my $.02. Take it fwiw. :) Ken From: Mickael Marrache [mailto:mickaelmarrache@gmail.com] Sent: Thursday, May 09, 2013 10:14 AM To: Cartwright, Ken; drinks@ietf.org Subject: Re: [drinks] Following today's meeting Hi, Concerning the first point, this is what I meant. I just explained the curr= ent approach as a prerequisite for the next part. Concerning the second point, I think you don't answer the real question. Firstly, using optional path parameters introduces an implementation issue.= Also, JAX-RS, which will probably be the most used solution for implementi= ng SPPP over REST in Java, does not support easily optional parameters (see= http://www.nakov.com/blog/2009/07/15/jax-rs-path-pathparam-and-optional-pa= rameters/). There are workarounds to this "issue" but this lack of support = shows this is a rare way of defining URIs in REST. Optional path parameters= are generally discouraged in REST. I think the real question is why to include the name of the destination gro= up as part of the PI key, not how to represent optional path parameters in = REST. Also, I don't see how excluding the dgName from the PI key would redu= ce flexibility of the model. On the other hand, I think that including the = dgName as part of the PI key increases complexity of RESTful implementation= s for the reasons I mentioned in the previous paragraph. Also, I think that= defining two URI templates for PIs (one for PIs that are part of DGs and a= nother for PIs that are not part of DGs) makes the REST API less intuitive = for the clients, and adds complexity for implementors. I don't really see e= nough advantages with the current model, that would convince me to accept t= his implementation complexity. Concerning the COR aspect, it's only a question we raised during the last m= eeting. I agree that the COR is intrinsic to the PI, so we don't need to mo= ve it at the PI-DG association level. Thanks, Mickael On Thu, May 9, 2013 at 3:56 PM, Cartwright, Ken > wrote: 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 PubI= d-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/TN= Range/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 d= ocument to represent the implementation construct in the XSD that uses a PI= Type, 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. G= ood catch. --- "For example, an obvious URI for a TN resource would represent the key attr= ibutes 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 pro= blem by using a special string to represent the absence of a value, or by u= sing other types of URI parameters (e.g. query parameters), but I don't thi= nk it's the right way to go." KJC: Hierarchical relationships in REST URIs are "optional". If the hiera= rchical relationship exists then it is in the URI, if it does not exist, th= en it is not in the URI. So a reasonable approach to resolving your Rest U= RI 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 i= n at least a couple ways as follows... 1) Consider modeling the URI in a way that is analogous to the SOAP XS= D;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/{d= gName}/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 the= re. 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 additio= n 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 ass= ociated 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: drinks-bounces@ietf.org [mailto:drink= s-bounces@ietf.org] On Behalf Of Mickael Ma= rrache Sent: Wednesday, April 24, 2013 2:51 PM To: drinks@ietf.org 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 c= ardinality should not be interpreted as limiting a PI to be associated to a= t 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 "s= ame" telephone number may be associated to multiple DGs by the use of multi= ple 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 allowe= d. 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 o= bvious URI for a TN resource would represent the key attributes as path par= ameters 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 sp= ecial string to represent the absence of a value, or by using other types o= f 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 i= s 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, t= he maxOccurs attribute of the dgName element should be set to unbounded. Th= e 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 meani= ng to let a registrant organization provision the same PI (in terms of valu= e) 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). Cr= eating a new complex type DestGrpRefType that includes the DG key and the c= orInfo element would solve this issue. The list of dgName (ObjNameType) wou= ld become a list of dgRefs (DestGrpRefType). Not related to this question, there are two other points I raised in the ma= iling list: 1. The framework document states: "If the response to the Get operation i= ncludes object(s) that extend the BasicObjType, the Registry MUST include t= he 'cDate' and 'mDate', if applicable.". In the examples section in the SOA= P 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 o= riginating SSP to the registry. The originating SSP must be a peering organ= ization 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 fie= ld has the value iana-en:111 as expected. There is an error in the SOAP doc= ument in section 10.11. The rant field has the value iana-en:222 where it s= hould 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 Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_B4254E341B54864B92D28BC2138A9DC30328C9231ETNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And not that I’ve given the REST mapping any = deep thought, but the more I think about it, the more it seems to me that the below is clear/simple/good and would support what the model sa= ys should be supported.  I also see no reason why a Rest implementatio= n would have issues with this (in fact it looks like vanilla Rest to me).&n= bsp; There are many examples in the real world of needing to work with objects that reside inside _and_ outside of= some hierarchical container/collection.  Rest certainly supports that= very easily.  I can also think of a couple other approaches and varia= tions of the approach below that also make sense.  Given this, I can’t see a  reason why the Rest que= stion that arose would necessitate a change to the model.=

 

//How to list and get one or more rants – but= this may or may not not be a feature that is supported

 

sppapi.example.com/rants/{rantIdentifier}

sppapi.example.com/rants

 

//For a given Rant, how to list and get one or more= of the Dest Groups

 

sppapi.example.com/rants/{rantIdentifier}/destGroup= s/{destGroupIdentifier}

sppapi.example.com/rants/{rantIdentifier}/destGroup= s

 

//For a given Rant, how to list and get one or more= PIs/TNs associated with (in) a Dest Group

 

sppapi.example.com/rants/{rantIdentifier}/destGroup= s/{destGroupIdentifier}/TNs/{tnIdentifier}

sppapi.example.com/rants/{rantIdentifier}/destGroup= s/{destGroupIdentifier}/TNs

 

//For a given Rant, how to list and get one or more= PIs/TNs not associated with (not in) a Dest Group

 

sppapi.example.com/rants/{rantIdentifier}/TNs/{tnId= entifier}

sppapi.example.com/rants/{rantIdentifier}/TNs<= /o:p>

 

//For a given Rant, how to list and get one or more= SEDGroups

 

sppapi.example.com/rants/{rantIdentifier}/SEDGroups= /{sedGroupIdentifier}

sppapi.example.com/rants/{rantIdentifier}/SEDGroups=

 

//etc, etc for other object types=

 

 <= /p>

From: Cartwrig= ht, Ken
Sent: Thursday, May 09, 2013 10:36 AM
To: 'Mickael Marrache'; drinks@ietf.org
Subject: RE: [drinks] Following today's meeting

 

Ok.  My apologies if= I “didn’t answer the key question” in the way you wanted= .  I think I responded directly to your points.  And I think that= the URL structures that I propose are very clean and intuitive, not complicated or esoteric. =  You did not say anything about “optional parameters” unti= l this reply.  So perhaps I can now speak to that question now that yo= u have posed it.  The model in the doc is what it is, if the group decides to change it, then so be it.  But, SOAP has no i= ssue dealing with it and I believe that Rest has no real issue dealing with= it either, and as I stated I think the resulting URL structure is very cle= ar and simple.  I also do not really see this as an “optional parameter” type situation.  The = example in the link you describe was speaking to someone wanting to put a &= #8220;format” selection in the main body of the output URL path so th= at they know if it is XML or JSON or etc.  The situation here is more of including a  hierarchical relationship as part of the URL = path, which is done all the time.  And of course not all objects in a = model will always have the same hierarchical relationships.

 <= /p>

But, that’s my $.02= .  Take it fwiw.  J

 <= /p>

Ken

 <= /p>

From: Mickael = Marrache [mailto:mickaelmarrac= he@gmail.com]
Sent: Thursday, May 09, 2013 10:14 AM
To: Cartwright, Ken; drinks@ietf.= org
Subject: Re: [drinks] Following today's meeting

 

Hi,

Concerning the first point, this is what I meant. I just explained the curr= ent approach as a prerequisite for the next part.

Concerning the second point, I think you don't answer the real question.
Firstly, using optional path parameters introduces an implementation issue.= Also, JAX-RS, which will probably be the most used solution for implementi= ng SPPP over REST in Java, does not support easily optional parameters (see http://www.nakov.com/blog/2009/07/15/jax-rs-path-pathparam-and-optional-par= ameters/). There are workarounds to this "issue" but this lac= k of support shows this is a rare way of defining URIs in REST. Optional pa= th parameters are generally discouraged in REST.

I think the real question is why to include the name of the destination gro= up as part of the PI key, not how to represent optional path parameters in = REST. Also, I don't see how excluding the dgName from the PI key would redu= ce flexibility of the model. On the other hand, I think that including the dgName as part of the PI key in= creases complexity of RESTful implementations for the reasons I mentioned i= n the previous paragraph. Also, I think that defining two URI templates for= PIs (one for PIs that are part of DGs and another for PIs that are not part of DGs) makes the REST API le= ss intuitive for the clients, and adds complexity for implementors. I don't= really see enough advantages with the current model, that would convince m= e to accept this implementation complexity.

Concerning the COR aspect, it's only a question we raised during the last m= eeting. I agree that the COR is intrinsic to the PI, so we don't need to mo= ve it at the PI-DG association level.

Thanks,
Mickael

On Thu, May 9, 2013 at 3:56 PM, Cartwright, Ken <= kcartwright@tnsi.= com> wrote:

Hi,


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

 

“During the call, we agreed that the cardinality on the DG s= ide of the PubId-DG association should be 0..1 instead of 0...n.”

 

KJC:  I’d state it like this…The cardinality in t= he body of the framework document and in the XSD are already correct/whatWe= Intended, 0..1.  But the diagram in the intro of the framework document incorrectly illustrates 0..n because it was a carry-ove= r 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 m= ore 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 makin= g a clerical correction to a diagram, albeit a good correction.  Good = catch.

 

---

 

“For example, an obvious URI for a TN resource would represe= nt the key attributes as path parameters such as /rant/{rant}/TN/dgName/{dg= Name}/tn/{tn}. However, dgName is optional and may not have a value. We can solve this problem by using a special str= ing to represent the absence of a value, or by using other types of URI par= ameters (e.g. query parameters), but I don't think it's the right way to go= .”

 

KJC:  Hierarchical relationships in REST URIs are “opti= onal”.  If the hierarchical relationship exists then it is in th= e 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 implem= ent the TNs/PIs->DG relationship as a mandatory hierarchy where the DG &= #8220;contains” the TNs/PIs.  This can be accomplished in at lea= st a couple ways as follows…

 

1)      = Consider modeling the URI in a way that is analogous to the SOAP XSD;s appr= oach, with an attribute of the TN/PI containing the DG relationship.  =   If you do that, then instead of having this: /rant/{rant}/TN/DG= NAME/{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 relations= hip, then that portion of the URI is just not necessary and is therefore no= t 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 n= o issue with that approach either.

 

Imo, also adding in the concept of the PI to the URL may be a vali= d 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<= /p>

/rant/SomeCompany/PI/LRN/19059876543/DG/SouthEast

 

---

 

I also noticed that the text in section 3.1, bullet two, about Destina=
tion groups says “can be
      associated with one or more SED Groups&=
#8221;.  That should say “can be associated with zero or more SE=
D Groups”
 
---
“the corInfo element should be an attribute of the PI-DG associa=
tion 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 furthe=
r complexity to the XSD and the model.
 
In general, I think making this change would reduce the flexibility th=
at is in the current model, while not reducing the complexity.

 


Thanks


 


 


From:
drinks-bounces=
@ietf.org [mailto:drinks-bounces@ietf.org]
On Behalf Of Mickael Marrache

Sent: Wednesday, April 24, 20=
13 2:51 PM

To: drinks@ietf=
.org

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 th=
at this cardinality should not be interpreted
 as limiting a PI to be associated to at most one DG. However, this cardina=
lity 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 e=
lement 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 beca=
use it is optional. While it may be acceptable for a key attribute to be op=
tional in some cases, I think it's relatively
 rare. Also, it becomes more difficult to define a URI for each public iden=
tifier concrete type. For example, an obvious URI for a TN resource would r=
epresent the key attributes as path parameters such as /rant/{rant}/TN/dgNa=
me/{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 type=
s of URI parameters (e.g. query parameters), but I don't think it's the rig=
ht 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 valu=
e, that is identified by the registrant
 that owns the PI, and the value of the PI (e.g. tn, tnp...). In order to a=
llow a PI to be associated to multiple DGs, the maxOccurs attribute of the =
dgName element should be set to unbounded. The registrant organization woul=
d only deal with one instance for
 a given PI value. The URI for the TN resource would then be /rant/{rant}/T=
N/{tn}.






 






Concerning the carrier-of-record concern, the question is: Is ther=
e a meaning to let a registrant organization provision the same PI (in term=
s of value) with different COR information?
 The current model allows such a feature by the use of multiple PI instance=
s (thus, allowing multiple corInfos). If this is a real use case, the corIn=
fo 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 t=
he 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 fr=
amework document states: "If the response to the Get operation in=
cludes object(s) that extend the BasicObjType, the Registry MUST inclu=
de the 'cDate' and 'mDate', if applicable.". In the examples=
 section
 in the SOAP document (section 10), for the Get examples, the elements cDat=
e and mDate are not part of the returned responses.
    2. <=
li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;mso-list:l3 level1 lfo3">
Accord=
ing 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, th=
e 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-pro=
tocol-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 Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 


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

 --_000_B4254E341B54864B92D28BC2138A9DC30328C9231ETNSMAILNAwin2_-- From sumanth@cablelabs.com Fri May 10 16:18:51 2013 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26D821F910D for ; Fri, 10 May 2013 16:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooybYG36KAQT for ; Fri, 10 May 2013 16:18:45 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id AF41C21F914C for ; Fri, 10 May 2013 16:18:41 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r4ANIeOC030170 for ; Fri, 10 May 2013 17:18:40 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 10 May 2013 17:18:40 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0123.003; Fri, 10 May 2013 17:18:40 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Thread-Topic: Rough notes from the design team call on 5/9 Thread-Index: AQHOTdS0HYfJie9rakGjBybw2GTqJA== Date: Fri, 10 May 2013 23:18:40 +0000 Message-ID: In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7D1FF40003@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Rough notes from the design team call on 5/9 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 23:18:51 -0000 IETF DRINKS DESIGN TEAM CALL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 5/9/2013, 11:00a-11:45a (Eastern) Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - David Schwartz - Dean Willis - Vikas Bhatia - Mickael Marrache=20 - Sumanth Channabasappa Rough Notes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - The design team discussed the topic from the mailing list: retaining TN + DG (Destination Group) as the key, or to retain only the TN as the key > See recent mailing list exchanges for this topic - David suggested - and Sumanth (as the chair) concurred - that we take REST out of the equation, and look at the current design to see if we should leave it that way or change it as being suggested by Mickael. - Vikas provided his view on the discussion and what is lost or gained; and recommended that we don't make a change unless we are absolutely sure - Dean made another suggestion, whereby he suggested that the DG be made an attribute - which should provide the same functionality as it does today? - We did not come to specific conclusions since we felt that the rest of the team was not present - Sumanth (as the chair) suggested the following: > Keep RESTful implementations out of this discussion; and see if there are merits to the current model v/s any changes - Mickael offered to send a proposal > Discuss the proposals (pros and cons) and ensure that we make a decision that gets documented (to avoid rehashing this discussion) - Via mailing list discussions, and the next call (tentatively, next Thu at 11a Eastern) From mickaelmarrache@gmail.com Mon May 13 06:56:01 2013 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB2A21F93C4 for ; Mon, 13 May 2013 06:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTdhvdxTlzZ8 for ; Mon, 13 May 2013 06:55:56 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0E021F92EC for ; Mon, 13 May 2013 06:55:55 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id t10so2340225lbi.4 for ; Mon, 13 May 2013 06:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=OdlYNtxDfOnPnIbH9pQ+u9gDdTcoD0r16IuzeJKDB0g=; b=XE6/tcSWN0e5H6+gPSoIJZ6zF2xxYxN+E7GexFbxL2sPDu2LpS9WmQDEHPyligR6VP r0STkoJ+PgBRdJYuybb7H5i8/G8pNB3u3Mp1En/Xf3WEjxRzRde32+meb4OJ5O8v7kNP cK6qkCRAwHNYI99bdIBgNxYR5kQB58aUtQHsMJ+DB638BEESNFrZDsieNESpBc2PHZJ6 7vo1Avp6GidYzeLxK7H36WaBJljwXxYIA/d75BoiBoLAWTWLGBd0pU7IB9nuWilIEFD1 Zv5sh7ku9ip9g6eZu+J4F7vz6SRKq/zijY/Mjw9DMMLEK5yHa/UnfuTo1qiVjBEFrwXU QSkg== MIME-Version: 1.0 X-Received: by 10.112.159.1 with SMTP id wy1mr12880905lbb.80.1368453354194; Mon, 13 May 2013 06:55:54 -0700 (PDT) Received: by 10.114.184.20 with HTTP; Mon, 13 May 2013 06:55:54 -0700 (PDT) Date: Mon, 13 May 2013 16:55:54 +0300 Message-ID: From: Mickael Marrache To: drinks@ietf.org Content-Type: multipart/alternative; boundary=001a11c33e64118b6504dc99e0ff Subject: [drinks] Change proposal X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 13:56:01 -0000 --001a11c33e64118b6504dc99e0ff Content-Type: text/plain; charset=ISO-8859-1 Hi, - Exclude the Destination Group's name from the Public Identifier key in section 5.2.2 of the framework document. Note that I don't mean to exclude the DG name from the PI type. - Update section 6.2 and 12 of the framework document accordingly. It consist of adding a maxOccurs attribute to the dgName element with the value unbounded. This way, it will be possible to associate the PI with multiple DGs. After the change, the PubIdType would look like: Since we agreed the COR is intrinsic to the PI (i.e. it doesn't depend on the association with a particular DG), this element should stay in the derived types of PubIdType. - Update sections 7.1.2 and 9 of the SOAP document. *Pros:* -For REST, the API is more intuitive since a single URI template is defined for PIs while two URI templates are defined with the current model (i.e. one for in-DG PIs and another for standalone PIs). -Less duplication of data when PIs are manipulated. For example, in order to associate the number 12345 to 4 DGs with the current model, 4 ADD requests are sent. These requests contain the same data except the dgName element. With the proposed changes, only 1 ADD request is sent. -With the current model, different COR may be provided for the number 12345 and it is an error as we discussed. With the proposed changes, for a given PI, the COR is defined only once so this unexpected scenario cannot happen. -Also concerning COR, with the current model, if the registry is authoritative, a registrant would have to set the same COR for a telephone number when it associates it to multiple DGssince a registrant must set the COR when it associates *Cons:* -Lack of flexibility. If flexibility means the ability to populate different information for the "same" PI depending on which DG it is associated to, I think the right way to do is to use a dedicated type for the association as it is done for the SED Group-SED Record association. The only thing I see behind the term flexibility is the fact that the current model is better suited for data distribution where for example, multiple PIs representing the same telephone number are stored at different places. But, I think this concept is irrelevant at the provisioning protocol level. -Need to make some modifications to both documents while they are closed to become RFCs. The changes are not big and I can allocate time to write them. *Another related point:* Currently, there are no additional elements that describe the PI-DG association (as for example, the priority element in the SED Group-SED Record association). Therefore, the association is represented by a list of ObjNameType (i.e. simple string). With the current model, this is enough since a new PI instance is created for each PI-DG association. With the proposed changes, it would be better to follow the same model as for the SED Group-SED Record association (i.e. using a new type, for example, DestGrpRefType) so that additional attributes may be added to the association in the future. Mickael --001a11c33e64118b6504dc99e0ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

- Exclude the Destination Group's name from= the Public Identifier key in section 5.2.2 of the framework document. Note= that I don't mean to exclude the DG name from the PI type.
- Update section 6.2 and 12 of the framework document accordingly. It consi= st of adding a maxOccurs attribute to the dgName element with the value unb= ounded. This way, it will be possible to associate the PI with multiple DGs= . After the change, the PubIdType would look like:
<complexType name=3D"PubIdType" abstract=3D"true&quo=
t;>
    <complexContent>
     <extension base=3D"sppfb:BasicObjType">
      <sequence>
       <element name=3D"dgName" type=3D"sppfb:ObjNameType=
" minOccurs=3D"0" maxOccurs=3D"unbounded"/>
      </sequence>
     </extension>
    </complexContent>
</complexType>
Since we agreed the COR is intrinsic to the P= I (i.e. it doesn't depend on the association with a particular DG), thi= s element should stay in the derived types of PubIdType.

- Update se= ctions 7.1.2 and 9 of the SOAP document.

Pros:
-For REST, the API is more intuitive since a single URI template is defined= for PIs while two URI templates are defined with the current model (i.e. o= ne for in-DG PIs and another for standalone PIs).
-Less duplication of d= ata when PIs are manipulated. For example, in order to associate the number= 12345 to 4 DGs with the current model, 4 ADD requests are sent. These requ= ests contain the same data except the dgName element. With the proposed cha= nges, only 1 ADD request is sent.
-With the current model, different COR may be provided for the number 12345= and it is an error as we discussed. With the proposed changes, for a given= PI, the COR is defined only once so this unexpected scenario cannot happen= .
-Also concerning COR, with the current model, if the registry is authoritat= ive, a registrant would have to set the same COR for a telephone number whe= n it associates it to multiple DGssince a registrant must set the COR when = it associates

Cons:
-Lack of flexibility. If flexibility means the ability = to populate different information for the "same" PI depending on = which DG it is associated to, I think the right way to do is to use a dedic= ated type for the association as it is done for the SED Group-SED Record as= sociation. The only thing I see behind the term flexibility is the fact tha= t the current model is better suited for data distribution where for exampl= e, multiple PIs representing the same telephone number are stored at differ= ent places. But, I think this concept is irrelevant at the provisioning pro= tocol level.
-Need to make some modifications to both documents while they are closed to= become RFCs. The changes are not big and I can allocate time to write them= .

Another related point:

Currently, there are no addit= ional elements that describe the PI-DG association (as for example, the pri= ority element in the SED Group-SED Record association). Therefore, the asso= ciation is represented by a list of ObjNameType (i.e. simple string). With = the current model, this is enough since a new PI instance is created for ea= ch PI-DG association. With the proposed changes, it would be better to foll= ow the same model as for the SED Group-SED Record association (i.e. using a= new type, for example, DestGrpRefType) so that additional attributes may b= e added to the association in the future.

Mickael
--001a11c33e64118b6504dc99e0ff-- From dean.willis@softarmor.com Thu May 16 09:10:24 2013 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DA011E80FC for ; Thu, 16 May 2013 09:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXzLot6Obn5I for ; Thu, 16 May 2013 09:10:22 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 90A1421F93B1 for ; Thu, 16 May 2013 09:10:22 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id z1so1153736qcx.31 for ; Thu, 16 May 2013 09:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FoYxzcG/pYUQ5ad4kxNZG7LICla21MFWC0Rc2aaUMm4=; b=OCyAadPCMG0WzQDCwKqwAK/HwOxQmUOMytXbqxSifE/y+ZpXSHSO1MJTKHsdEqFQM3 TOhcm5/QmYx+DlbZC3uSrljp9ddpVcmdSxJ/j82J67ExikeB0f3dIDGhKrdCdec2LQ+M lPxiVxxXJeaOF0/2aJ5sib7pxcXNyv+2fyvaU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=FoYxzcG/pYUQ5ad4kxNZG7LICla21MFWC0Rc2aaUMm4=; b=Fnjv+FM9ZVSilgoVT+ngiXoEtTdnAqNGKQNT+ugcKO8DxHYauGd8F/d5slFDPjc7jk XfdULjDnFSe2MSzoBXN9uClV+Rij5QYRwLm9mnQM37lzaIK7GG0LVXET/aFyfQq9ofMi 3d+wHH3qsN54Letlulq8JuuVutYt7QzWrAi8sbyZ+aAlMrauDgbDVMavZavZy7kCFUt8 qyEjYXPJGuBlJSWTAuNNiE5uTtRRR2N2CXwCgZlbH7aAPhyDpd7aNbxgFQDF/zI0TlIA 03ZKxINad6eFlBHGwcgJeODgV0BoR0uo1E5RqRQHynR0sf8bV0gZLa2avzqTDfEi9Yh0 Q/nQ== MIME-Version: 1.0 X-Received: by 10.49.14.135 with SMTP id p7mr6545682qec.57.1368720621966; Thu, 16 May 2013 09:10:21 -0700 (PDT) Received: by 10.49.104.50 with HTTP; Thu, 16 May 2013 09:10:21 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 May 2013 11:10:21 -0500 Message-ID: From: Dean Willis To: Mickael Marrache Content-Type: multipart/alternative; boundary=047d7bb04e36782b1404dcd81a54 X-Gm-Message-State: ALoCoQmtTjl0eKpFDjH0S+faWXByNV0ckeS0cQIqmkRanvFozj7f6eckd4UkUvrvECmV84J2gA3e Cc: "drinks@ietf.org" Subject: Re: [drinks] Change proposal X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 16:10:24 -0000 --047d7bb04e36782b1404dcd81a54 Content-Type: text/plain; charset=ISO-8859-1 I think the current "optional key" model is complicated. If we need the functionality, there are alternative structures that could provide it with fewer headaches. If we don't need the functionality, then Mickael's modification makes the structure simpler and easier to understand. And I think "simpler and easier to understand" is a good selling point for wider adoption of the protocol. So: first question: Do we need the functionality? On Mon, May 13, 2013 at 8:55 AM, Mickael Marrache wrote: > Hi, > > - Exclude the Destination Group's name from the Public Identifier key in > section 5.2.2 of the framework document. Note that I don't mean to exclude > the DG name from the PI type. > - Update section 6.2 and 12 of the framework document accordingly. It > consist of adding a maxOccurs attribute to the dgName element with the > value unbounded. This way, it will be possible to associate the PI with > multiple DGs. After the change, the PubIdType would look like: > > > > > > > > > > > > Since we agreed the COR is intrinsic to the PI (i.e. it doesn't depend on > the association with a particular DG), this element should stay in the > derived types of PubIdType. > > - Update sections 7.1.2 and 9 of the SOAP document. > > *Pros:* > -For REST, the API is more intuitive since a single URI template is > defined for PIs while two URI templates are defined with the current model > (i.e. one for in-DG PIs and another for standalone PIs). > -Less duplication of data when PIs are manipulated. For example, in order > to associate the number 12345 to 4 DGs with the current model, 4 ADD > requests are sent. These requests contain the same data except the dgName > element. With the proposed changes, only 1 ADD request is sent. > -With the current model, different COR may be provided for the number > 12345 and it is an error as we discussed. With the proposed changes, for a > given PI, the COR is defined only once so this unexpected scenario cannot > happen. > -Also concerning COR, with the current model, if the registry is > authoritative, a registrant would have to set the same COR for a telephone > number when it associates it to multiple DGssince a registrant must set the > COR when it associates > > *Cons:* > -Lack of flexibility. If flexibility means the ability to populate > different information for the "same" PI depending on which DG it is > associated to, I think the right way to do is to use a dedicated type for > the association as it is done for the SED Group-SED Record association. The > only thing I see behind the term flexibility is the fact that the current > model is better suited for data distribution where for example, multiple > PIs representing the same telephone number are stored at different places. > But, I think this concept is irrelevant at the provisioning protocol level. > -Need to make some modifications to both documents while they are closed > to become RFCs. The changes are not big and I can allocate time to write > them. > > *Another related point:* > > Currently, there are no additional elements that describe the PI-DG > association (as for example, the priority element in the SED Group-SED > Record association). Therefore, the association is represented by a list of > ObjNameType (i.e. simple string). With the current model, this is enough > since a new PI instance is created for each PI-DG association. With the > proposed changes, it would be better to follow the same model as for the > SED Group-SED Record association (i.e. using a new type, for example, > DestGrpRefType) so that additional attributes may be added to the > association in the future. > > Mickael > > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks > > --047d7bb04e36782b1404dcd81a54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think the current "optional key" model is comp= licated.

If we need the functionality, there are a= lternative structures that could provide it with fewer headaches.

If= we don't need the functionality, then Mickael's modification makes= the structure simpler and easier to understand.

And I think "simpler and easier to und= erstand" is a good selling point for wider adoption of the protocol.= =A0

So: first question: Do we need the functionality?


On Mon, May 13, 2013 at 8:55 AM, Mickael= Marrache <mickaelmarrache@gmail.com> wrote:
Hi,

- Exclude the Destination Group's name from= the Public Identifier key in section 5.2.2 of the framework document. Note= that I don't mean to exclude the DG name from the PI type.
- Update section 6.2 and 12 of the framework document accordingly. It consi= st of adding a maxOccurs attribute to the dgName element with the value unb= ounded. This way, it will be possible to associate the PI with multiple DGs= . After the change, the PubIdType would look like:
<complexType name=3D"PubIdType" abstract=3D"true&quo=
t;>
    <complexContent>
     <extension base=3D"sppfb:BasicObjType">
      <sequence>
       <element name=3D"dgName" type=3D"sppfb:ObjNameType=
" minOccurs=3D"0" maxOccurs=3D"unbounded"/>
      </sequence>
     </extension>
    </complexContent>
</complexType>
Since we agreed the COR is intrinsic to the P= I (i.e. it doesn't depend on the association with a particular DG), thi= s element should stay in the derived types of PubIdType.

- Update se= ctions 7.1.2 and 9 of the SOAP document.

Pros:
-For REST, the API is more intuitive since a single URI template is defined= for PIs while two URI templates are defined with the current model (i.e. o= ne for in-DG PIs and another for standalone PIs).
-Less duplication of d= ata when PIs are manipulated. For example, in order to associate the number= 12345 to 4 DGs with the current model, 4 ADD requests are sent. These requ= ests contain the same data except the dgName element. With the proposed cha= nges, only 1 ADD request is sent.
-With the current model, different COR may be provided for the number 12345= and it is an error as we discussed. With the proposed changes, for a given= PI, the COR is defined only once so this unexpected scenario cannot happen= .
-Also concerning COR, with the current model, if the registry is authoritat= ive, a registrant would have to set the same COR for a telephone number whe= n it associates it to multiple DGssince a registrant must set the COR when = it associates

Cons:
-Lack of flexibility. If flexibility means the ability = to populate different information for the "same" PI depending on = which DG it is associated to, I think the right way to do is to use a dedic= ated type for the association as it is done for the SED Group-SED Record as= sociation. The only thing I see behind the term flexibility is the fact tha= t the current model is better suited for data distribution where for exampl= e, multiple PIs representing the same telephone number are stored at differ= ent places. But, I think this concept is irrelevant at the provisioning pro= tocol level.
-Need to make some modifications to both documents while they are closed to= become RFCs. The changes are not big and I can allocate time to write them= .

Another related point:

Currently, there are no addit= ional elements that describe the PI-DG association (as for example, the pri= ority element in the SED Group-SED Record association). Therefore, the asso= ciation is represented by a list of ObjNameType (i.e. simple string). With = the current model, this is enough since a new PI instance is created for ea= ch PI-DG association. With the proposed changes, it would be better to foll= ow the same model as for the SED Group-SED Record association (i.e. using a= new type, for example, DestGrpRefType) so that additional attributes may b= e added to the association in the future.

Mickael

_______________________________________________
drinks mailing list
drinks@ietf.org
= https://www.ietf.org/mailman/listinfo/drinks


--047d7bb04e36782b1404dcd81a54-- From alexander.mayrhofer@nic.at Tue May 21 03:20:35 2013 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EEB21F9008 for ; Tue, 21 May 2013 03:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.43 X-Spam-Level: X-Spam-Status: No, score=-9.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Eh1+IPrN6L2 for ; Tue, 21 May 2013 03:20:30 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id AA61921F920E for ; Tue, 21 May 2013 03:20:27 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.49 ; Tue, 21 May 2013 12:17:04 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0123.003; Tue, 21 May 2013 12:20:20 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: DRAFT minutes of the 2013-05-16 conference call. Thread-Index: Ac5WC2CkxZZE/wXAQJ+MeSaZ2npL5A== Date: Tue, 21 May 2013 10:20:19 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750A24C705@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: [drinks] DRAFT minutes of the 2013-05-16 conference call. X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 10:20:35 -0000 DRINKS design team conference call =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D 2013-05-16, 08:30 - 09:00am Pacific Time Participants -------------- - Mickael Marrache - Dean Willis - Alex Mayrhofer - David Schwartz - Syed Ali - Vikas Bhatia AI --- 1/ (All) Post PROs and CONs regarding DGname as component of PI Key Type to= mailing list (if not yet posted) 2/ (Design Team) Make informed decision based on full information Minutes ---------- 1) clarification that cardinality mistake in diagram is solved - will be ch= anged (Figure 2 - Relation between PI and DG) 2) discussion about whether DGname should be part of the publickeytype. Vikas: What new information came to table that we didn't have before? David: Implementation work brought this up. Alex (individual): Having optional attribute as key component sounds illogi= cal (although understand that NULL values can be key components) Vikas: What do we gain when we remove it? David: Implementation is much easier. Dean: Simplification might subsequently lead to more deployment? Vikas: two options - again, what new has come to light to change this forme= r decision? Dean: Optional keys & hibernation in DB are complex.. Vikas: We need more arguments than just "this is complex" David: Only Counter-argument he hears is "let's not change it" - Can someon= e come up with a use case why this is needen, What the advantage is to leav= e it in besides avoiding a change? Vikas: Argument is not inertia, but what is the new information? David: new info is implementation experience. David: Optional parameter as key component is not the way to do data modesl= .=20 Vikas: Depends on the case. Alex (as chair):=20 Conclusion: No concensus yet. We Need more information - Please post PROs a= nd CONs to the list,=20 so that we can make an informed decision, hopefully over the course of the = next week Call concludes. From sumanth@cablelabs.com Wed May 22 15:27:07 2013 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80F811E813A for ; Wed, 22 May 2013 15:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAaq2N52WWGr for ; Wed, 22 May 2013 15:27:03 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB6711E814B for ; Wed, 22 May 2013 15:27:00 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r4MMQxZ1029160 for ; Wed, 22 May 2013 16:26:59 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 22 May 2013 16:26:59 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0123.003; Wed, 22 May 2013 16:26:59 -0600 From: Sumanth Channabasappa To: "drinks@ietf.org" Thread-Topic: [drinks] DRAFT minutes of the 2013-05-16 conference call. Thread-Index: Ac5WC2CkxZZE/wXAQJ+MeSaZ2npL5ABMBd2A Date: Wed, 22 May 2013 22:26:58 +0000 Message-ID: In-Reply-To: <19F54F2956911544A32543B8A9BDE0750A24C705@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [drinks] DRAFT minutes of the 2013-05-16 conference call. X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 22:27:08 -0000 Folks, Can you please post your thoughts around the pros and cons as you seem them so that we can resolve this topic? It will be useful to have this (on the list) before we have another design team call. See below for details. Thanks! - S (as the co-chair) On 5/21/13 4:20 AM, "Alexander Mayrhofer" wrote: > >DRINKS design team conference call >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >2013-05-16, 08:30 - 09:00am Pacific Time > >Participants >-------------- > > - Mickael Marrache > - Dean Willis > - Alex Mayrhofer > - David Schwartz > - Syed Ali > - Vikas Bhatia > >AI >--- > >1/ (All) Post PROs and CONs regarding DGname as component of PI Key Type >to mailing list (if not yet posted) >2/ (Design Team) Make informed decision based on full information > >Minutes >---------- > >1) clarification that cardinality mistake in diagram is solved - will be >changed (Figure 2 - Relation between PI and DG) > >2) discussion about whether DGname should be part of the publickeytype. > >Vikas: What new information came to table that we didn't have before? >David: Implementation work brought this up. >Alex (individual): Having optional attribute as key component sounds >illogical (although understand that NULL values can be key components) >Vikas: What do we gain when we remove it? >David: Implementation is much easier. >Dean: Simplification might subsequently lead to more deployment? > >Vikas: two options - again, what new has come to light to change this >former decision? >Dean: Optional keys & hibernation in DB are complex.. >Vikas: We need more arguments than just "this is complex" >David: Only Counter-argument he hears is "let's not change it" - Can >someone come up with a use case why this is needen, What the advantage is >to leave it in besides avoiding a change? >Vikas: Argument is not inertia, but what is the new information? >David: new info is implementation experience. >David: Optional parameter as key component is not the way to do data >modesl.=20 >Vikas: Depends on the case. > >Alex (as chair):=20 >Conclusion: No concensus yet. We Need more information - Please post PROs >and CONs to the list, >so that we can make an informed decision, hopefully over the course of >the next week > >Call concludes. > > >_______________________________________________ >drinks mailing list >drinks@ietf.org >https://www.ietf.org/mailman/listinfo/drinks > From kcartwright@tnsi.com Tue May 28 13:01:05 2013 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24EF21F92B7 for ; Tue, 28 May 2013 13:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xBjqn50IOgB for ; Tue, 28 May 2013 13:01:00 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A88621F9104 for ; Tue, 28 May 2013 13:00:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUFAOULpVGsEQfn/2dsb2JhbABZgkR0wiKBHXSCIwEBBS1cAgEIEQQBASgHMhQJCAEBBAESCMN+jWuBAQQzAQaCbWEDk2qYPIFV X-IronPort-AV: E=Sophos;i="4.87,759,1363132800"; d="scan'208,217";a="2468762" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 28 May 2013 20:46:33 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 28 May 2013 16:00:57 -0400 From: "Cartwright, Ken" To: Mickael Marrache , "drinks@ietf.org" Date: Tue, 28 May 2013 16:00:57 -0400 Thread-Topic: [drinks] Change proposal Thread-Index: Ac5P4Z7zfDGbgC50TKWHUeI4wZ9jLAL+dzRw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B4254E341B54864B92D28BC2138A9DC3032971FFB3TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Change proposal X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 20:01:06 -0000 --_000_B4254E341B54864B92D28BC2138A9DC3032971FFB3TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, After discussions with some others on this proposed change, I think I can l= ive with this change, although some intrinsic changes would have to be made= to the way an existing system works to accommodate this change. So from m= y perspective, feel free to make this change if you feel the need to do so. Ken From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Mickael Marrache Sent: Monday, May 13, 2013 9:56 AM To: drinks@ietf.org Subject: [drinks] Change proposal Hi, - Exclude the Destination Group's name from the Public Identifier key in se= ction 5.2.2 of the framework document. Note that I don't mean to exclude th= e DG name from the PI type. - Update section 6.2 and 12 of the framework document accordingly. It consi= st of adding a maxOccurs attribute to the dgName element with the value unb= ounded. This way, it will be possible to associate the PI with multiple DGs= . After the change, the PubIdType would look like: Since we agreed the COR is intrinsic to the PI (i.e. it doesn't depend on t= he association with a particular DG), this element should stay in the deriv= ed types of PubIdType. - Update sections 7.1.2 and 9 of the SOAP document. Pros: -For REST, the API is more intuitive since a single URI template is defined= for PIs while two URI templates are defined with the current model (i.e. o= ne for in-DG PIs and another for standalone PIs). -Less duplication of data when PIs are manipulated. For example, in order t= o associate the number 12345 to 4 DGs with the current model, 4 ADD request= s are sent. These requests contain the same data except the dgName element.= With the proposed changes, only 1 ADD request is sent. -With the current model, different COR may be provided for the number 12345= and it is an error as we discussed. With the proposed changes, for a given= PI, the COR is defined only once so this unexpected scenario cannot happen= . -Also concerning COR, with the current model, if the registry is authoritat= ive, a registrant would have to set the same COR for a telephone number whe= n it associates it to multiple DGssince a registrant must set the COR when = it associates Cons: -Lack of flexibility. If flexibility means the ability to populate differen= t information for the "same" PI depending on which DG it is associated to, = I think the right way to do is to use a dedicated type for the association = as it is done for the SED Group-SED Record association. The only thing I se= e behind the term flexibility is the fact that the current model is better = suited for data distribution where for example, multiple PIs representing t= he same telephone number are stored at different places. But, I think this = concept is irrelevant at the provisioning protocol level. -Need to make some modifications to both documents while they are closed to= become RFCs. The changes are not big and I can allocate time to write them= . Another related point: Currently, there are no additional elements that describe the PI-DG associa= tion (as for example, the priority element in the SED Group-SED Record asso= ciation). Therefore, the association is represented by a list of ObjNameTyp= e (i.e. simple string). With the current model, this is enough since a new = PI instance is created for each PI-DG association. With the proposed change= s, it would be better to follow the same model as for the SED Group-SED Rec= ord association (i.e. using a new type, for example, DestGrpRefType) so tha= t additional attributes may be added to the association in the future. 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 Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_B4254E341B54864B92D28BC2138A9DC3032971FFB3TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,=

 <= /p>

After discussions with so= me others on this proposed change, I think I can live with this change, alt= hough some intrinsic changes would have to be made to the way an existing system works to accommodate this change.  So from my = perspective, feel free to make this change if you feel the need to do so.

 <= /p>

Ken

 <= /p>

From: drinks-b= ounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Mickael Marrache
Sent: Monday, May 13, 2013 9:56 AM
To: drinks@ietf.org
Subject: [drinks] Change proposal

 

Hi,

- Exclude the Destination Group's name from the Public Identifier key in se= ction 5.2.2 of the framework document. Note that I don't mean to exclude th= e DG name from the PI type.
- Update section 6.2 and 12 of the framework document accordingly. It consi= st of adding a maxOccurs attribute to the dgName element with the value unb= ounded. This way, it will be possible to associate the PI with multiple DGs= . After the change, the PubIdType would look like:

<complexType name=3D"PubIdType" abstract=3D"true&quo=
t;>
    <complexContent>
     <extension base=3D"sppfb:BasicObjType=
">
      <sequence>
       <element name=3D"dgName&q=
uot; type=3D"sppfb:ObjNameType" minOccurs=3D"0" maxOccu=
rs=3D"unbounded"/>
      </sequence>
     </extension>
    </complexContent>
</complexType>

Since we agreed the COR is intrinsic to the PI (i.e.= it doesn't depend on the association with a particular DG), this element s= hould stay in the derived types of PubIdType.

- Update sections 7.1.2 and 9 of the SOAP document.

Pros:
-For REST, the API is more intuitive since a single URI template is defined= for PIs while two URI templates are defined with the current model (i.e. o= ne for in-DG PIs and another for standalone PIs).
-Less duplication of data when PIs are manipulated. For example, in order t= o associate the number 12345 to 4 DGs with the current model, 4 ADD request= s are sent. These requests contain the same data except the dgName element.= With the proposed changes, only 1 ADD request is sent.
-With the current model, different COR may be provided for the number 12345= and it is an error as we discussed. With the proposed changes, for a given= PI, the COR is defined only once so this unexpected scenario cannot happen= .
-Also concerning COR, with the current model, if the registry is authoritat= ive, a registrant would have to set the same COR for a telephone number whe= n it associates it to multiple DGssince a registrant must set the COR when = it associates

Cons:
-Lack of flexibility. If flexibility means the ability to populate differen= t information for the "same" PI depending on which DG it is assoc= iated to, I think the right way to do is to use a dedicated type for the as= sociation as it is done for the SED Group-SED Record association. The only thing I see behind the term flexibility is th= e fact that the current model is better suited for data distribution where = for example, multiple PIs representing the same telephone number are stored= at different places. But, I think this concept is irrelevant at the provisioning protocol level.
-Need to make some modifications to both documents while they are closed to= become RFCs. The changes are not big and I can allocate time to write them= .

Another related point:

Currently, there are no additional elements that describe the PI-DG associa= tion (as for example, the priority element in the SED Group-SED Record asso= ciation). Therefore, the association is represented by a list of ObjNameTyp= e (i.e. simple string). With the current model, this is enough since a new PI instance is created for each = PI-DG association. With the proposed changes, it would be better to follow = the same model as for the SED Group-SED Record association (i.e. using a ne= w type, for example, DestGrpRefType) so that additional attributes may be added to the association in the futur= e.

Mickael


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

 --_000_B4254E341B54864B92D28BC2138A9DC3032971FFB3TNSMAILNAwin2_--