Subject: [drinks] Change proposal

From: Mickael Marrache <[email-masked]>
Date: Mon, 13 May 2013 16:55:54 +0300

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

---

From: Dean Willis <[email-masked]>
Date: Thu, 16 May 2013 11:10:21 -0500

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 <[email-masked]
> wrote:

>        <element name="dgName" type="sppfb:ObjNameType" minOccurs="0" maxOccurs="unbounded"/>
>       </sequence>
>      </extension>
>     </complexContent>
> </complexType>
>
> -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).
> -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.
> -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:*
>
> _______________________________________________
> drinks mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/drinks
>
>

---

From: "Cartwright, Ken" <[email-masked]>
Date: Tue, 28 May 2013 16:00:57 -0400

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

    <complexContent>

      <sequence>

      </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.

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.