Re: [drinks] Change proposal

[Sumanth Channabasappa <[e-mail]>]

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 "rough consensus" and request the authors to incorporate this change.

- S
(as the co-chair)

From: <Bhatia>, Vikas Bhatia <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, June 5, 2013 3:08 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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…The initial argument was easier implementation 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 REST and proposed change (the current approach is equally intuitive as far as 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 measure 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 driver yet for this change.

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

Thanks,
Vikas

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Dean Willis
Sent: Wednesday, June 05, 2013 3:32 PM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [drinks] Change proposal

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]<mailto:[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]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Mickael Marrache
Sent: Monday, May 13, 2013 9:56 AM
To: [e-mail]<mailto:[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]<mailto:[e-mail]>
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 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.