Re: [drinks] Change proposal

[Dean Willis <[e-mail]>]

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


On May 28, 2013, at 3:00 PM, "Cartwright, Ken" <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Mickael Marrache
> Sent: Monday, May 13, 2013 9:56 AM
> To: [e-mail]
> 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="PubIdType" abstract="true">
>     <complexContent>
>      <extension base="sppfb:BasicObjType">
>       <sequence>
>        <element name="dgName" type="sppfb:ObjNameType" minOccurs="0" maxOccurs="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 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/drinks