From mickaelmarrache@gmail.com Tue Apr 16 07:43:12 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 71B1D21F9693 for ; Tue, 16 Apr 2013 07:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7GC+34FtNl7w for ; Tue, 16 Apr 2013 07:43:11 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6F921F9500 for ; Tue, 16 Apr 2013 07:43:10 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id fn20so545665lab.15 for ; Tue, 16 Apr 2013 07:43:10 -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=dL9s+tfJQawed3QQYAoBIalbZQIu6qVWnYBrWEjvfHo=; b=SyuKwRZKZ7YGD4saC0WZTz8bRJ7/o0vE6XQV9axzE0+jaAWFR4qNgYAHd2jvI7V0QO aMbOGScXZzfKUddUXGdckKL4CMkFkDKtbZ1EmRhpWbtufymVMJxQ2S1bdz3aTqqOzss9 ZzxrHLUd2hD620UOWmxkS5Wi8G4x3Zv3LHoxDBnYtbePvGixPszMqlZ6FZhnHw2Qqlrl Kn5+jgN9hguuwGrSMI01jgwvUn4sFuoJFJN38pqHZTvpLmLecvxvlZIDMlfU4bXFdWdq nj/gOnwBuDYQbSpQ9sCoT9i6R3jEO+G/Ip2iH/zJW+e0Iuw5QvIGUPlvGMQRpH+XvzZn y0QA== MIME-Version: 1.0 X-Received: by 10.152.170.136 with SMTP id am8mr1371022lac.35.1366123390098; Tue, 16 Apr 2013 07:43:10 -0700 (PDT) Received: by 10.114.184.20 with HTTP; Tue, 16 Apr 2013 07:43:10 -0700 (PDT) Date: Tue, 16 Apr 2013 17:43:10 +0300 Message-ID: From: Mickael Marrache To: drinks@ietf.org Content-Type: multipart/alternative; boundary=089e0117720562e18f04da7b63a8 Subject: [drinks] Why is the dgName part of the key for public identities? 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, 16 Apr 2013 14:43:12 -0000 --089e0117720562e18f04da7b63a8 Content-Type: text/plain; charset=ISO-8859-1 Hi, According to the requirements document (RFC6461), a public identifier object can be contained in exactly one destination group object. Figure 3 explicitly shows this intent by the 0...1 cardinality on the destination group side in the DG-PI association. In the framework document (section 3.1), this cardinality is different (0...n instead of 0...1). Is the real intention the one defined in the requirements document or in the framework document? Also, according to the framework document, a public identity is uniquely identified by its type, rant, dgName and value (e.g. tn for telephone numbers). The only motivation to include the dgName as part of the key is to allow a public identity to be associated with multiple destination groups. If the right intention is the one defined in the requirements document, it's an error to include the dgName as part of the key. Following this way, we would be allowed to associate the same public identity to multiple destination groups. If the right intention if the one defined in the framework document, there is still an issue since there is duplication of information. For example, if registrant Org-1 wants to associate the telephone number 1234 to two of its destination groups DG-1 and DG-2, he would need to specify two objects in the spppAddRequest. These two objects will contain exactly the same data, except that the dgNames will be different (i.e. DG-1 for the first object and DG-2 for the second one). Thus, regardless which intention is the right one, I think the dgName should not be part of the key. A public identity should then be identified by its type, rant and value only. Then, according to which is the right intention, the dgName field should be declared with maxOccurs=1 (i.e. from requirements) or maxOccurs=unbounded (i.e. for framework). The fact that a field that composes the key may be optional is a symptom of this design issue. In this case, this field is dgName. Regards, Mickael --089e0117720562e18f04da7b63a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

According to the requirements docum= ent (RFC6461), a public identifier object can be contained in exactly one d= estination group object. Figure 3 explicitly shows this intent by the 0...1= cardinality on the destination group side in the DG-PI association. In the= framework document (section 3.1), this cardinality is different (0...n ins= tead of 0...1).
Is the real intention the one defined in the requirements document or = in the framework document?

Also, according to the = framework document, a public identity is uniquely identified by its type, r= ant, dgName and value (e.g. tn for telephone numbers). The only motivation = to include the dgName as part of the key is to allow a public identity to b= e associated with multiple destination groups. If the right intention is th= e one defined in the requirements document, it's an error to include th= e dgName as part of the key. Following this way, we would be allowed to ass= ociate the same public identity to multiple destination groups. If the righ= t intention if the one defined in the framework document, there is still an= issue since there is duplication of information. For example, if registran= t Org-1 wants to associate the telephone number 1234 to two of its destinat= ion groups DG-1 and DG-2, he would need to specify two objects in the spppA= ddRequest. These two objects will contain exactly the same data, except tha= t the dgNames will be different (i.e. DG-1 for the first object and DG-2 fo= r the second one).

Thus, regardless which intention is the right one, I th= ink the dgName should not be part of the key. A public identity should then= be identified by its type, rant and value only. Then, according to which i= s the right intention, the dgName field should be declared with maxOccurs= =3D1 (i.e. from requirements) or maxOccurs=3Dunbounded (i.e. for framework)= .

The fact that a field that composes the key may be opti= onal is a symptom of this design issue. In this case, this field is dgName.=

Regards,
Mickael




--089e0117720562e18f04da7b63a8-- From syedwasimali@gmail.com Tue Apr 16 09:19:08 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 6A20A21F95D0 for ; Tue, 16 Apr 2013 09:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ZjV4Yk1rnhaP for ; Tue, 16 Apr 2013 09:19:07 -0700 (PDT) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 387D721F91A2 for ; Tue, 16 Apr 2013 09:19:07 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id f13so529174vbg.28 for ; Tue, 16 Apr 2013 09:19:06 -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:cc:content-type; bh=DFJNEAHMWCze6+O9yZFgF3pmi38RPdISPpjlThLu1VE=; b=P3YNzyWApOMCmRM01atiJ202ag8pToPS5ldJDxht+4VrZx5bpRSe1iv+C0MMwm20fq 6fw3S+avqffRXiSQJeYqgFsQNC13myCshhSWWK9C+dLbNyW8RUCmbrehwBRGho4j94U4 vacX9a0NxPpuZZsQspFMduhtTH1Ps98808A8RZf4828BWi2B71RsULZZjjSllyWhr2Rl rAwYr/bpddmcqINBVuQ0/M0wMSeb3ySFJeh2NWirmr0p2LKAnbO4lKOXxY8cTD8BfEKb PwQl3Q9f0huMmp9wVeu8Lldo6SUWrW6xZ1r3pC6Cj7M0H2qh1s6CzYoNZYmDodlb8RvF CiHg== MIME-Version: 1.0 X-Received: by 10.58.29.101 with SMTP id j5mr2083130veh.26.1366129146542; Tue, 16 Apr 2013 09:19:06 -0700 (PDT) Received: by 10.59.1.41 with HTTP; Tue, 16 Apr 2013 09:19:06 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Apr 2013 12:19:06 -0400 Message-ID: From: Syed W Ali To: Mickael Marrache Content-Type: multipart/alternative; boundary=047d7b6765627f7e0504da7cba71 Cc: "drinks@ietf.org" Subject: Re: [drinks] Why is the dgName part of the key for public identities? 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, 16 Apr 2013 16:19:08 -0000 --047d7b6765627f7e0504da7cba71 Content-Type: text/plain; charset=ISO-8859-1 This is a great find. Thanks for bringing this up. Other authors of the document are welcome to comment. Though I will try to look into 0..1 and 0..n collision issue and respond a little later, along with suggestions on what constitutes a fix. Either way, I feel that the grouping of TNs by destination group allows for more granular control over the configuration as to which pathways are more appropriate for establishing the session. Let's say that there are ten different regions with large concentration of subscribers. Use of destination groups allows for greater flexibility in isolating select paths to attempt session establishment at resolution time than would have otherwise been possible. Using your example, DG1 and DG2 selectors will allow for different path associations to the TN 1234 or else an aggregate of the two session data information would be returned. And I think the basic premise of your suggestion is evident in the examples where the read-back/get of the record doesn't require the name of the destination group as an input parameter. Though if the 0..n cardinality is enforced, dest group name should be a consideration for optional parameter. To be clear, the intent of the read-back/get function in the SPP context is to retrieve the full record in its current state since the last update. -Syed On Tue, Apr 16, 2013 at 10:43 AM, Mickael Marrache < mickaelmarrache@gmail.com> wrote: > Hi, > > According to the requirements document (RFC6461), a public identifier > object can be contained in exactly one destination group object. Figure 3 > explicitly shows this intent by the 0...1 cardinality on the destination > group side in the DG-PI association. In the framework document (section > 3.1), this cardinality is different (0...n instead of 0...1). > Is the real intention the one defined in the requirements document or in > the framework document? > > Also, according to the framework document, a public identity is uniquely > identified by its type, rant, dgName and value (e.g. tn for telephone > numbers). The only motivation to include the dgName as part of the key is > to allow a public identity to be associated with multiple destination > groups. If the right intention is the one defined in the requirements > document, it's an error to include the dgName as part of the key. Following > this way, we would be allowed to associate the same public identity to > multiple destination groups. If the right intention if the one defined in > the framework document, there is still an issue since there is duplication > of information. For example, if registrant Org-1 wants to associate the > telephone number 1234 to two of its destination groups DG-1 and DG-2, he > would need to specify two objects in the spppAddRequest. These two objects > will contain exactly the same data, except that the dgNames will be > different (i.e. DG-1 for the first object and DG-2 for the second one). > > Thus, regardless which intention is the right one, I think the dgName > should not be part of the key. A public identity should then be identified > by its type, rant and value only. Then, according to which is the right > intention, the dgName field should be declared with maxOccurs=1 (i.e. from > requirements) or maxOccurs=unbounded (i.e. for framework). > > The fact that a field that composes the key may be optional is a symptom > of this design issue. In this case, this field is dgName. > > Regards, > Mickael > > > > > > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks > > --047d7b6765627f7e0504da7cba71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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

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

And I think the basic premise of your sugge= stion is evident in the examples where the read-back/get of the record does= n't require the name of the destination group as an input parameter. Th= ough if the 0..n cardinality is enforced, dest group name should be a consi= deration for optional parameter. To be clear, the intent of the read-back/g= et function in the SPP context is to retrieve the full record in its curren= t state since the last update.

-Syed


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

Acco= rding to the requirements document (RFC6461), a public identifier object ca= n be contained in exactly one destination group object. Figure 3 explicitly= shows this intent by the 0...1 cardinality on the destination group side i= n the DG-PI association. In the framework document (section 3.1), this card= inality is different (0...n instead of 0...1).
Is the real intention the one defined in the requirements document or = in the framework document?

Also, according to the = framework document, a public identity is uniquely identified by its type, r= ant, dgName and value (e.g. tn for telephone numbers). The only motivation = to include the dgName as part of the key is to allow a public identity to b= e associated with multiple destination groups. If the right intention is th= e one defined in the requirements document, it's an error to include th= e dgName as part of the key. Following this way, we would be allowed to ass= ociate the same public identity to multiple destination groups. If the righ= t intention if the one defined in the framework document, there is still an= issue since there is duplication of information. For example, if registran= t Org-1 wants to associate the telephone number 1234 to two of its destinat= ion groups DG-1 and DG-2, he would need to specify two objects in the spppA= ddRequest. These two objects will contain exactly the same data, except tha= t the dgNames will be different (i.e. DG-1 for the first object and DG-2 fo= r the second one).

Thus, regardless which intention is the right one, I th= ink the dgName should not be part of the key. A public identity should then= be identified by its type, rant and value only. Then, according to which i= s the right intention, the dgName field should be declared with maxOccurs= =3D1 (i.e. from requirements) or maxOccurs=3Dunbounded (i.e. for framework)= .

The fact that a field that composes the key may be opti= onal is a symptom of this design issue. In this case, this field is dgName.=

Regards,
Mickael





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


--047d7b6765627f7e0504da7cba71-- From mickaelmarrache@gmail.com Fri Apr 19 07:45:19 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 9B66921F8F20 for ; Fri, 19 Apr 2013 07:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wGA0iaeC7zxv for ; Fri, 19 Apr 2013 07:45:19 -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 B4E4521F8F1C for ; Fri, 19 Apr 2013 07:45:18 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id ek20so3587489lab.25 for ; Fri, 19 Apr 2013 07:45:15 -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=FNa57nsZqYa4wvDMMMjtoucnY382eHpppONCGJo5kho=; b=JpSz9fgQii93Ls9aBu/gRaJTjkg0JWgjatxlboQjwk+iEoYHrnGCFafG/KNtX0sJiV T4WHLu4alJyZ0OiiMmaYhnLR7YmnbMagd5pwgLJbE8yLQFifiF9RDhvxybYGlxZTpf4g GQ9Q5PlGZcRis7Q4CFt8HGIZC4if2z1ioba+OMlnKeltevLvoFo79JcByUAT+eUXpLnq kxuSeFFOi4/hb1uYLAN0RbhUYSW/9fSEnd0AbAhowxYnOYYJkcJ+j/7RgtUMU4c2wu5x muz2J5uXy0J4ImOIye1OF4KMRBJRuBNdlKj9i5OXQQ4nv7NWLmDaKJkQZHGIEAFEiwok Yhdg== MIME-Version: 1.0 X-Received: by 10.112.168.97 with SMTP id zv1mr8188087lbb.25.1366382715304; Fri, 19 Apr 2013 07:45:15 -0700 (PDT) Received: by 10.114.184.20 with HTTP; Fri, 19 Apr 2013 07:45:15 -0700 (PDT) Date: Fri, 19 Apr 2013 17:45:15 +0300 Message-ID: From: Mickael Marrache To: drinks@ietf.org Content-Type: multipart/alternative; boundary=001a11c341c85f812f04dab7c44d Subject: [drinks] Error in SOAP document - section 10.11 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, 19 Apr 2013 14:45:19 -0000 --001a11c341c85f812f04dab7c44d Content-Type: text/plain; charset=ISO-8859-1 Hi, According to the framework document, an egress route is added by the originating SSP to the registry. The originating SSP must be a peering organization of the SED group to which the egress route is associated. I deduce that an egress route is an element owned by the originating SSP. Thus, the rant field of the egress route identifies the originating SSP and not the owner of the SED group. Also, in the SOAP document in section 10.17, the rant field has the value iana-en:111 as expected. If what I said until here is right, 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. Mickael --001a11c341c85f812f04dab7c44d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

According to the framework document= , an egress route is added by the originating SSP to the registry. The orig= inating SSP must be a peering organization of the SED group to which the eg= ress route is associated. I deduce that an egress route is an element owned= by the originating SSP. Thus, the rant field of the egress route identifie= s the originating SSP and not the owner of the SED group. Also, in the SOAP= document in section 10.17, the rant field has the value iana-en:111 as exp= ected.

If what I said until here is right, there is an error i= n 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.

Mickael
--001a11c341c85f812f04dab7c44d-- From mickaelmarrache@gmail.com Wed Apr 24 11:51:52 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 0171421F90EB for ; Wed, 24 Apr 2013 11:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.499, 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 vhwTQfyg60qr for ; Wed, 24 Apr 2013 11:51:50 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id A8A7B21F8F0F for ; Wed, 24 Apr 2013 11:51:47 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id r11so2093765lbv.12 for ; Wed, 24 Apr 2013 11:51:26 -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=z6sNDBNtJJFveSeC5o2mOTA9QxNmP7sb+od/GrcYkMA=; b=YEJH9k6L83/pvQbwOuKXqGc78CO3FnUwiJ0KriZK1+lwQY2KUU7/WicH/QVe1AzCyT ppPOd9zU5B16exHMAbG8PvYMhjoRW2/8oLGmVumckXGv7gX4PRZYMflwFcE0vMmDeGus Womqfw60mLmbP5aGWu+CI/DA97qHed/lOnxtBBwuYyETWfwYkQTF6dC+41bSevWlYmgj iiHgkytd7JW95HHT8zm0rNuB0BWqPP0ePUmn/TXcUYrE63Q54fY0ivLl6u3UVmYGmJFC LFJngUZyQZul7J2aZyQfoQGEu/+sHmn1Bm5846MzIPIzwB00Zd4nxHCRwJar1/D1HWNZ d2/Q== MIME-Version: 1.0 X-Received: by 10.152.6.162 with SMTP id c2mr18344434laa.20.1366829485928; Wed, 24 Apr 2013 11:51:25 -0700 (PDT) Received: by 10.114.184.20 with HTTP; Wed, 24 Apr 2013 11:51:25 -0700 (PDT) Date: Wed, 24 Apr 2013 21:51:25 +0300 Message-ID: From: Mickael Marrache To: drinks@ietf.org Content-Type: multipart/alternative; boundary=089e013d139efa345804db1fc9dc Subject: [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: Wed, 24 Apr 2013 18:51:52 -0000 --089e013d139efa345804db1fc9dc Content-Type: text/plain; charset=ISO-8859-1 Hi, During the call, we agreed that the cardinality on the DG side of the PubId-DG association should be 0..1 instead of 0...n. We also agreed that this cardinality should not be interpreted as limiting a PI to be associated to at most one DG. However, this cardinality should be interpreted as limiting a PI instance to be associated to at most one DG. Thus, for example, the "same" telephone number may be associated to multiple DGs by the use of multiple TN instances. This way is made possible by including the dgName element as part of the key, so that for a given registrant and a given value (e.g. tn, tnp, start/end...), different values for the dgName element are allowed. I think that the dgName element should not be part of the key because it is optional. While it may be acceptable for a key attribute to be optional in some cases, I think it's relatively rare. Also, it becomes more difficult to define a URI for each public identifier concrete type. For example, an obvious URI for a TN resource would represent the key attributes as path parameters such as /rant/{rant}/TN/dgName/{dgName}/tn/{tn}. However, dgName is optional and may not have a value. We can solve this problem by using a special string to represent the absence of a value, or by using other types of URI parameters (e.g. query parameters), but I don't think it's the right way to go. What I proposed during the call was to exclude the dgName element from the key. So, there would be only one PI instance for a particular value, that is identified by the registrant that owns the PI, and the value of the PI (e.g. tn, tnp...). In order to allow a PI to be associated to multiple DGs, the maxOccurs attribute of the dgName element should be set to unbounded. The registrant organization would only deal with one instance for a given PI value. The URI for the TN resource would then be /rant/{rant}/TN/{tn}. Concerning the carrier-of-record concern, the question is: Is there a meaning to let a registrant organization provision the same PI (in terms of value) with different COR information? The current model allows such a feature by the use of multiple PI instances (thus, allowing multiple corInfos). If this is a real use case, the corInfo element should be an attribute of the PI-DG association since it is not intrisic to the PI itself but depends on an external factor (in this case, the association with a particular DG). Creating a new complex type DestGrpRefType that includes the DG key and the corInfo element would solve this issue. The list of dgName (ObjNameType) would become a list of dgRefs (DestGrpRefType). Not related to this question, there are two other points I raised in the mailing list: 1. The framework document states: "If the response to the Get operation includes object(s) that extend the BasicObjType, the Registry MUST include the 'cDate' and 'mDate', if applicable.". In the examples section in the SOAP document (section 10), for the Get examples, the elements cDate and mDate are not part of the returned responses. 2. According to the framework document, an egress route is added by the originating SSP to the registry. The originating SSP must be a peering organization of the SED group to which the egress route is associated. Thus, an egress route is an element owned by the originating SSP. The rant field of the egress route would then identify the originating SSP and not the owner of the SED group. Also, in the SOAP document in section 10.17, the rant field has the value iana-en:111 as expected. There is an error in the SOAP document in section 10.11. The rant field has the value iana-en:222 where it should have the value iana-en:111 that identifies SSP1. Also, a new version of the REST draft is available at http://tools.ietf.org/html/draft-marrache-drinks-spp-protocol-rest-02. It would be great if you can take a look at it and comment. Thanks, Mickael --089e013d139efa345804db1fc9dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

During the call, we agreed that the= cardinality on the DG side of the PubId-DG association should be 0..1 inst= ead of 0...n. We also agreed that this cardinality should not be interprete= d as limiting a PI to be associated to at most one DG. However, this cardin= ality should be interpreted as limiting a PI instance to be associated to a= t most one DG. Thus, for example, the "same" telephone number may= be associated to multiple DGs by the use of multiple TN instances. This wa= y is made possible by including the dgName element as part of the key, so t= hat 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 t= he key because it is optional. While it may be acceptable for a key attribu= te 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 ke= y 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 th= is problem by using a special string to represent the absence of a value, o= r 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 dgNa= me element from the key. So, there would be only one PI instance for a part= icular value, that is identified by the registrant that owns the PI, and th= e value of the PI (e.g. tn, tnp...). In order to allow a PI to be associate= d to multiple DGs, the maxOccurs attribute of the dgName element should be = set to unbounded. The registrant organization would only deal with one inst= ance 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 al= lows such a feature by the use of multiple PI instances (thus, allowing mul= tiple 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 it= self 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 dgNa= me (ObjNameType) would become a list of dgRefs (DestGrpRefType).

Not related to this question, there are two other point= s I raised in the mailing list:
  1. The framework document states:=A0"If th= e response to the Get operation includes object(s) that extend=A0the BasicO= bjType, the Registry MUST include the 'cDate' and 'mDate',= =A0if applicable.".=A0In the examples section in the SOAP document (se= ction 10), for the Get examples, the elements cDate and mDate are not part = of the returned responses.
  2. According to the fram= ework document, an egress route is added by the originating SSP to the regi= stry. The originating SSP must be a peering organization of the SED group t= o 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 the= n identify the originating SSP and not the owner of the SED group. Also, in= the SOAP document in section 10.17, the rant field has the value iana-en:1= 11 as expected. There is an error in the SOAP document in section 10.11. Th= e 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=A0http://tools.ietf.org/html/draft-ma= rrache-drinks-spp-protocol-rest-02. It would be great if you can take a= look at it and comment.

Thanks,
Mickael
--089e013d139efa345804db1fc9dc--