From dean.willis@softarmor.com Wed Jun 5 12:32:46 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 9C0A521F9B4D for ; Wed, 5 Jun 2013 12:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.184 X-Spam-Level: X-Spam-Status: No, score=-100.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=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 vKTn+2QOc3m4 for ; Wed, 5 Jun 2013 12:32:45 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 86C0C21F9B20 for ; Wed, 5 Jun 2013 12:32:44 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va7so3248048obc.41 for ; Wed, 05 Jun 2013 12:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to:x-mailer; bh=f5vHJHZWXd6RxhsG0sjKvbawv0smOWUveSx+wVrUJo4=; b=VXh4G/a2mUhzEYM40lDa2aQNw+3dEwylLnJOZfyMHtKFCocvbu0m15OYB6E25/fV2p RUTKg0MHj9qD5EhV3Up1BinYm1NLkFAOxZUFvooHoqL/APC/Za++91u10b53ADWNrLqc h+DqOfrRIsoWQj3++gqMZm1KyUnE3WVq58RuQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to:x-mailer:x-gm-message-state; bh=f5vHJHZWXd6RxhsG0sjKvbawv0smOWUveSx+wVrUJo4=; b=QM5eT3QhlizOrpX5voJY0LXOD85VOc2CbJWGsPVptvp2+HCS4rDOarfpOACnAHAQyF exs5nUaSbSP+WLjsnorHIUYMHGDdLLyTsoxXPEKJ28/2wUWRTVOlz9k9FWP3KXgnkAfg Xl6JLL0K1GhRq5mPWW4MaqRtrS6CCXSZ5PKxLEPYorA6S0k+gY5MKUDFeMr2KedbF3BP eYuIVav7RDKsPkpRUCNQdgDHhfFgDZVI2YGZQUQTy1Lp0VoCFS06Zl3q0c23L0fJMQht nPQfO32hcIDB1oldpVpBhKY23+TjqDcU9ZE8+oNC8PQJLUOlicBO4zpDbY+sBjhuacPQ i0Fw== X-Received: by 10.60.84.102 with SMTP id x6mr16133971oey.73.1370460720286; Wed, 05 Jun 2013 12:32:00 -0700 (PDT) Received: from [192.168.2.106] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPSA id b5sm54378427oby.12.2013.06.05.12.31.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 12:31:58 -0700 (PDT) From: Dean Willis Content-Type: multipart/alternative; boundary="Apple-Mail=_D659FBBA-7F2B-4711-9DF9-C3186F7A9860" Message-Id: <6AFDDFEF-2D5E-4C40-BDD0-B4B0D23A1808@softarmor.com> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Wed, 5 Jun 2013 14:31:55 -0500 References: To: "Drinks@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlDVBERWUiWglMJp3S2oEIwK2pJpV4FlZibuqLZJ8hU/dizK77fmtRglX+Pj4TtYV/aYDBC 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: Wed, 05 Jun 2013 19:32:46 -0000 --Apple-Mail=_D659FBBA-7F2B-4711-9DF9-C3186F7A9860 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I also have no objections to the proposed change. I think it's a little = bit easier to work with, but it's not a big deal either way. This is beginning to sound like rough consensus.=20 Anybody disagree? If not, let's nail this bogey to the tree and go find = another tree that might have a squirrel in it. I'm getting a crick in my = neck looking up at this one. -- Dean On May 28, 2013, at 3:00 PM, "Cartwright, Ken" = wrote: > Hi All, > =20 > After discussions with some others on this proposed change, I think I = can live 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 my perspective, feel free to make this change if you feel the = need to do so. > =20 > Ken > =20 > 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 > =20 > Hi, >=20 > - 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. >=20 > - Update sections 7.1.2 and 9 of the SOAP document. >=20 > 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=20 >=20 > 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. >=20 > Another related point: >=20 > 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. >=20 > Mickael >=20 > This e-mail message is for the sole use of the intended = recipient(s)and may > contain confidential and privileged information of Transaction Network = Services. > Any unauthorised review, use, disclosure or distribution is = prohibited. If you > are not the intended recipient, please contact the sender by reply = e-mail and destroy all copies of the original message. >=20 > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks --Apple-Mail=_D659FBBA-7F2B-4711-9DF9-C3186F7A9860 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I also have no objections = to the proposed change.  I think it's a little bit easier to work = with, but it's not a big deal either way.

This = is beginning to sound like rough = consensus. 

Anybody disagree? If not, = let's nail this bogey to the tree and go find another tree that might = have a squirrel in it. I'm getting a crick in my neck looking up at this = one.

--
Dean

<= br>
On May 28, 2013, at 3:00 PM, "Cartwright, Ken" <kcartwright@tnsi.com> = wrote:

Hi = All,
 
After discussions with some others on this = proposed change, I think I can live 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 my 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 = 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:
<complexType name=3D"PubIdType" =
abstract=3D"true">
     <extension =
base=3D"sppfb:BasicObjType">
       <element =
name=3D"dgName" type=3D"sppfb:ObjNameType" minOccurs=3D"0" =
maxOccurs=3D"unbounded"/>
     =
</extension>
</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 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

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

_______________________________________________
= drinks mailing list
drinks@ietf.org
To: "drinks@ietf.org" Date: Wed, 5 Jun 2013 17:08:58 -0400 Thread-Topic: [drinks] Change proposal Thread-Index: Ac5iI4oN3Ds2UWUPTSeuKKAuYAD8WgACYLwg Message-ID: References: <6AFDDFEF-2D5E-4C40-BDD0-B4B0D23A1808@softarmor.com> In-Reply-To: <6AFDDFEF-2D5E-4C40-BDD0-B4B0D23A1808@softarmor.com> 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_B4254E341B54864B92D28BC2138A9DC30329945353TNSMAILNAwin2_" 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: Wed, 05 Jun 2013 21:09:06 -0000 --_000_B4254E341B54864B92D28BC2138A9DC30329945353TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My thought goes back to the discussions on the last design call regarding = what is the driver for this change...The initial argument was easier implem= entation in REST but that, as we discussed on the last call, was deemed not= the case based on last set of email exchanges on the mailing list around R= EST and proposed change (the current approach is equally intuitive as far a= s REST is concerned). The other argument brought up by Dean on the design call was of simplicity = and ease of understanding for wider adoption, which generically speaking is= a reasonable argument. But the part that is concerning to me there is, was= this (Mickael's proposed change) the only piece of the protocol that was a= sticking point in the wider adoption? Are there others and what is the mea= sure of "wider adoption"? Sometimes something that is simple from one point= of view is complex from a different view point. To me, there is no clear d= river yet for this change. Having said that, I can live with this instance of change... Thanks, Vikas From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Dean Willis Sent: Wednesday, June 05, 2013 3:32 PM To: Drinks@ietf.org Subject: Re: [drinks] Change proposal I also have no objections to the proposed change. I think it's a little bi= t easier to work with, but it's not a big deal either way. This is beginning to sound like rough consensus. Anybody disagree? If not, let's nail this bogey to the tree and go find ano= ther tree that might have a squirrel in it. I'm getting a crick in my neck = looking up at this one. -- Dean On May 28, 2013, at 3:00 PM, "Cartwright, Ken" > wrote: 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:drink= s-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. _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks ________________________________ 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_B4254E341B54864B92D28BC2138A9DC30329945353TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My thought goes back to t= he discussions on the last design call  regarding what is the driver f= or this change…The initial argument was easier implementation in REST but that, as we discussed on the last call, was deemed not the cas= e based on last set of email exchanges on the mailing list around REST and = proposed change (the current approach is equally intuitive as far as REST i= s concerned).

 <= /p>

The other argument brough= t up by Dean on the design call was of simplicity and ease of understanding= for wider adoption, which generically speaking is a reasonable argument. But the part that is concerning to me there is, was this (Mickae= l’s proposed change) the only piece of the protocol that was a sticki= ng point in the wider adoption? Are there others and what is the measure of= “wider adoption”? Sometimes something that is simple from one point of view is complex from a different view poi= nt. To me, there is no clear driver yet for this change.<= /p>

 <= /p>

Having said that, I can l= ive with this instance of change…

 <= /p>

Thanks,=

Vikas

 <= /p>

From: drinks-b= ounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Dean Willis
Sent: Wednesday, June 05, 2013 3:32 PM
To: Drinks@ietf.org
Subject: Re: [drinks] Change proposal

 

I also have no objections to the proposed change. &n= bsp;I think it's a little bit easier to work with, but it's not a big deal = either way.

 

This is beginning to sound like rough consensus= . 

 

Anybody disagree? If not, let's nail this bogey to t= he tree and go find another tree that might have a squirrel in it. I'm gett= ing a crick in my neck looking up at this one.

 

--

Dean

 

 



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-bounces@ie= tf.org [mailto= :drinks-bo= unces@ietf.org] On Behalf Of Mickael Ma= rrache
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 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.

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

 


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_B4254E341B54864B92D28BC2138A9DC30329945353TNSMAILNAwin2_-- From sumanth@cablelabs.com Wed Jun 12 13:30:13 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 CC35221E8097 for ; Wed, 12 Jun 2013 13:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.397 X-Spam-Level: * X-Spam-Status: No, score=1.397 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 Q3ZufhUAXOvH for ; Wed, 12 Jun 2013 13:30:09 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6E73321E8094 for ; Wed, 12 Jun 2013 13:30:08 -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 r5CKU6wK015480; Wed, 12 Jun 2013 14:30:06 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 12 Jun 2013 14:30:06 -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, 12 Jun 2013 14:30:05 -0600 From: Sumanth Channabasappa To: "Bhatia, Vikas" , "drinks@ietf.org" Thread-Topic: [drinks] Change proposal Thread-Index: AQHOT+GcKy+SV5cJZEe2Bq96BfLy6ZkbgPSAgAyKioCAABsdAIAKkN2A Date: Wed, 12 Jun 2013 20:30:05 +0000 Message-ID: In-Reply-To: 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: multipart/alternative; boundary="_000_CDDE35C636433sumanthcablelabscom_" MIME-Version: 1.0 X-Approved: ondar 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: Wed, 12 Jun 2013 20:30:13 -0000 --_000_CDDE35C636433sumanthcablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks, Vikas. Sounds like people are "ok" with the changes proposed by Mic= kael. If that is incorrect, and you have objections to this proposal or nee= d more time to think about this, please respond this week. If not, Alex and= I will consider this "rough consensus" and request the authors to incorpor= ate this change. - S (as the co-chair) From: , Vikas Bhatia > Date: Wednesday, June 5, 2013 3:08 PM To: "Drinks@ietf.org" > Subject: Re: [drinks] Change proposal My thought goes back to the discussions on the last design call regarding = what is the driver for this change=85The initial argument was easier implem= entation in REST but that, as we discussed on the last call, was deemed not= the case based on last set of email exchanges on the mailing list around R= EST and proposed change (the current approach is equally intuitive as far a= s REST is concerned). The other argument brought up by Dean on the design call was of simplicity = and ease of understanding for wider adoption, which generically speaking is= a reasonable argument. But the part that is concerning to me there is, was= this (Mickael=92s proposed change) the only piece of the protocol that was= a sticking point in the wider adoption? Are there others and what is the m= easure of =93wider adoption=94? Sometimes something that is simple from one= point of view is complex from a different view point. To me, there is no c= lear driver yet for this change. Having said that, I can live with this instance of change=85 Thanks, Vikas From: drinks-bounces@ietf.org [mailto:drink= s-bounces@ietf.org] On Behalf Of Dean Willis Sent: Wednesday, June 05, 2013 3:32 PM To: Drinks@ietf.org Subject: Re: [drinks] Change proposal I also have no objections to the proposed change. I think it's a little bi= t easier to work with, but it's not a big deal either way. This is beginning to sound like rough consensus. Anybody disagree? If not, let's nail this bogey to the tree and go find ano= ther tree that might have a squirrel in it. I'm getting a crick in my neck = looking up at this one. -- Dean On May 28, 2013, at 3:00 PM, "Cartwright, Ken" > wrote: 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:drink= s-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. _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks ________________________________ 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_CDDE35C636433sumanthcablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <70BB85586D57A2428B86AD3EF1AA172C@cablelabs.com> Content-Transfer-Encoding: quoted-printable
Thanks, Vikas. Sounds like people are "ok" with the changes = proposed by Mickael. If that is incorrect, and you have objections= to this proposal or need more time to think about this, please respond this week. If not, Alex and I will consider this "roug= h consensus" and request the authors to incorporate this change. =

- S
(as the co-chair)

From: <Bhatia>, Vikas Bhatia = <vbhatia@tnsi.com>
Date: Wednesday, June 5, 2013 3:08 = PM
To: "Drinks@ietf.org" <= Drinks@ietf.org>
Subject: Re: [drinks] Change propos= al

My thought goes back to the discus= sions on the last design call  regarding what is the driver for this c= hange=85The initial argument was easier implementation in REST but that, as we discussed on the last call, was deemed not the cas= e based on last set of email exchanges on the mailing list around REST and = proposed change (the current approach is equally intuitive as far as REST i= s concerned).

 

The other argument brought up by D= ean on the design call was of simplicity and ease of understanding for wide= r adoption, which generically speaking is a reasonable argument. But the part that is concerning to me there is, = was this (Mickael=92s proposed change) the only piece of the protocol that = was a sticking point in the wider adoption? Are there others and what is th= e measure of =93wider adoption=94? Sometimes something that is simple from one point of view is complex from a differen= t view point. To me, there is no clear driver yet for this change.

 

Having said that, I can live with = this instance of change=85

 

Thanks,

Vikas

 

From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Dean Willis
Sent: Wednesday, June 05, 2013 3:32 PM
To: Drinks@ietf.org
Subject: Re: [drinks] Change proposal

 

I also have no objections to the proposed change. &n= bsp;I think it's a little bit easier to work with, but it's not a big deal = either way.

 

This is beginning to sound like rough consensus= . 

 

Anybody disagree? If not, let's nail this bogey to t= he tree and go find another tree that might have a squirrel in it. I'm gett= ing a crick in my neck looking up at this one.

 

--

Dean

 

 

On May 28, 2013, at 3:00 PM, "Cartwright, Ken&q= uot; <kcartwright@tnsi.com&g= t; wrote:



Hi All,

 

After discussions with some others= on this proposed change, I think I can live with this change, although som= e 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.

 

Ken

 

From: dr= inks-bounces@ietf.org = ;[mailto:drinks-bounces@ietf.org] On Behalf Of Mickael Ma= rrache
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 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.

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

 


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_CDDE35C636433sumanthcablelabscom_--