Subject: Re: [drinks] protocol observations...

From: "Ali, Syed Wasim" <[email-masked]>
Date: Tue, 1 Jun 2010 04:34:47 -0400

Ken,

Thanks for reviewing the changes and a detailed feedback. Please see inline.

On 5/26/10 6:25 PM, "Cartwright, Ken" <[email-masked]> wrote:

>
> 1) Instead of the DestGroupType containing the identifiers of the routes that
> route to it, the RteGrpType should contain the identifiers of the destination
> groups that it routes to.
Reqts doc says:

"Destination Group:   An aggregation of a set of public identifiers,
      TN Ranges, or RNs that share common SED."

The current schema definition doesn't show "aggregation of a set of public
identifiers",

    <complexType name="DestGrpType">
        <sequence>
            <element name="base" type="spppb:BasicObjType"/>
            <element name="dgName" type="string"/>
            <element name="rteGrpName" type="string" minOccurs="0"
maxOccurs="unbounded"/>
        </sequence>
    </complexType>

Updated type definitions:

    <complexType name="DestGrpType">
        <sequence>
            <element name="base" type="spppb:BasicObjType"/>
            <element name="dgName" type="string"/>
            <element name="pi" type="spppb:" maxOccurs="unbounded"/>
        </sequence>
    </complexType>
    <complexType name="RteGrpType">
        <sequence>
            <element name="base" type="spppb:BasicObjType"/>
            <element name="rteGrpName" type="string"/>
            <element name="rteRec" type="spppb:RteRecType" minOccurs="0"
maxOccurs="unbounded"/>
            <element name="destGrp" type="spppb:DestGrpType" minOccurs="0"
maxOccurs="unbounded"/>
            <element name="peeringOrg" type="spppb:OrgIdType" minOccurs="0"
maxOccurs="unbounded"/>
            <element name="sourceIdent" type="spppb:SourceIdentType"
minOccurs="0"
                maxOccurs="unbounded"/>
            <element name="isInSvc" type="boolean"/>
        </sequence>
    </complexType>

thoughts?

> 2) DestGroupType should be renamed to DestGrpType.
Done.

> 3) In URIType is there a reason that the "ere" element is defined/located here
> as an attribute of the object?
If you are suggesting that we should consider making "ere" an element, that
should be fine.

> 4) imo, the concept of "authoritative" does not belong in BasicRqstType, it
> should be a mandatory element of the PubIdType.  Secondly, the use cases speak
> to Carrier of Record and Transit, but by expressing the requirements of these
> use cases with a more generic Boolean attribute called "authoritative" it
> seems to be implying something else that is less precise.  Maybe that is ok,
> but we need to understand this new meaning, otherwise the systems will not
> know how to use it in resolution responses.
We should discuss this on the next call.

> 6) In BasicRspnseType I prefer the clientTransId and serverTransId to be
> elements over attributes.  I see these values as core pieces of information
> about the response.
Style bit; either way works for me. I changed it back to element.

> 7) Elimination of the minor version attribute eliminates the ability to
> determine the minor version, unless you add the minor version into the
> namespace, which I do not see in there.  "...ns:sppp:base:1".  If we add the
> minor version into the namespace then I'm ok with removing the minor version
> element, but others may comment on it as it drew some feedback last time.
> Also, if you remove the minor version element then you can also rename the
> majMinVersion element in SvcMenuType to just "version".
This is something that we continue to discuss. We should tee this up for the
next call and see if we can finalize the next step.

> 8) Given the intended use of the clientTransId, I think is not good to have
> the getter methods include/extend the BasicRqstType (which contains the
> clientTransId).  For similar reason, it may not be good to have the getter
> responses include/extend the BasicRspnseType.  The intended use of the
> clientTransId is to help ensure that the server does not miss any transactions
> from a given client, as a result, transactionId's are "consumed" in sequence
> by a given client.  Imposing this same limitation on getters is not necessary,
> and will have negative consequences on performance and complexity of the code
> base.

We share the same concern about performance and complexity of the code. As I
mentioned earlier, not including a correlation tag in the getter request has
an unintended consequence that the client thread has to wait for the
response from the server before it can send another getter request. SPPP
server will likely have a pool of resources that can service multiple
requests.

Perhaps I should take a step back and ask about the purpose of the getters
in the first place. My assumption was that the getter methods provide the
logical equivalent to an ENUM or a SIP query. If so, why would these be
mixed with the provisioning requests? This is not a norm in deployments
today, right? And even if the getters and the updates are mixed in,
considering the importance of transactional integrity, returning a response
to a getter ahead of an update which could have affected the answer of the
getter should be a concern. At the minimum, the SPPP client using the getter
should either do it in sequence, like other update requests, or use a
separate thread to exclusively perform gets. Then again, it could be that my
understanding of the getters is not correct to begin with. I will await your
reply.

> 9) Based on the point 8 above I'm sure you see the issue with using the
> BasicRspnseType for both update transactions and getters.
> 10) Do we want to do something about the theoretical possibility that the
> current XSD allows a client to pass in several update requests, comingled with
> getter requests, in the spppRequest element?  I think we probably want to
> structurally disallow that.
In its current form, unless I am mistaken, it enables the bulk provisioning
use case. We can always limit the current spppRequest to a single
BasicRqstType and introduce a separate spppBulkRequest methods that allows
one or more spppRequest requests. I am open to both approaches.

>
>
>
>
> -----Original Message-----
> From: Ali, Syed Wasim [mailto:[email-masked]]
> Sent: Tuesday, May 25, 2010 10:16 PM
> To: Sumanth Channabasappa; Cartwright, Ken; David Schwartz; Maharishi, Manjul;
> Jean-Francois Mule; Alexander Mayrhofer; Hadriel Kaplan; [email-masked]
> Subject: Re: [drinks] protocol observations...
>
>
> Hi,
>
> In the past few weeks, we have made a lot of progress with the
> use-case/requirements document. We are getting closer to the date for
> finalizing the submissions for the next IETF meeting. In the interest of
> time, I have attempted to update the SPPP schema to reflect the necessary
> changes and invite everyone to comment and provide the needed suggestions.
> These changes to the schema can be categorized as below:
>
> (1-) Updates that were discussed and agreed upon in the interim meeting and
> the weekly calls
> (2-) Updates that correspond to the changes in the latest use case document
> (3-) Improvements in the schema that do not affect the XML output and that
> are targeted to improve the type definitions, reduce repetition, etc.
> (4-) Suggested changes to improve readability of the XML output
>
> Attached diff ( diff-2e_and_2f-3.html) between the last published schema
> (Apr 2, 2010) and the latest schema (...2f-3.html) enumerates the changes in
> detail. Down below, I try to explain the changes in order from top to
> bottom. Each item below starts with a category above to help the reader know
> what the change is about.
>
> Also, just to make it absolutely clear, the latest schema remains in a draft
> stage until such time that a consensus is reached in the usual fashion.
>
> - (1-) Line 15: "targetDomain" element is removed. In the last f2f interim
> meeting, there was agreement that the target-domain will be represented as a
> form of URI and not a standalone element.
> - (1-) Line 33: Use of <choice> was experimental with the intent that the
> public identifier has a restriction to include at least a "dgName" or NAPTR
> RR. This had unintended consequences. The latest definition is the same as
> the last published SPPP WG document. This amounts to "no change".
> - (1-) Line 82: default value associated with the optional "ttl" attribute
> has been removed.
> - (4-) Line 123: Element name has been changed from "value" to a more a
> self-descriptive "uri"
> - (4-) Line 136: This is an experimental change. "MinorVerType" has been
> removed. The detailed reasons are discussed in the following email thread.
> - (1-) Line 143: There is no active use case for "effDate", hence removed.
> - (3-) Line 149: All request methods now extend BasicRqstType. This avoids
> repetition in each request method definition. And it also simplifies the XML
> output. Please see the corresponding before- and after- attached XML
> messages as examples.
> - (3-) Line 149: "clientTransId" is now an attribute. In doing so, as
> demonstrated in the attached after- XML output, as a common denominator to
> all SPPP requests, it is not mixed with the context of the implied SPPP
> request message.
> - (4-) Line 154: Lacking an "Update" request type, it is not clear if we
> need to identify a "Query" request type separately. Also, to uniquely
> identify the query transaction, "clientTransId" attribute is useful. It
> appears that the basic BasicRqstType is sufficient for both query as well as
> update request types. Therefore, BasicQueryType definition is removed
> - (2-) Line 158+: optional "authoritative" attribute is added to the
> BasicRqstType in support of the carrier-of-record as mentioned in use case
> "INTERCONNECT #2" per draft-ietf-drinks-usecases-requirements-03.txt. This
> use case mentions two possible levels of authority: carrier-of-record and
> transit provider. With that mind, it appears that the "boolean" data type
> satisfies the basic requirement to say that if an SSP proceeds to provision
> the request as a carrier-of-record, then "authoritative=true" attribute
> should be explicitly added in the SPPP request. If the SPPP server finds the
> request in error and fails to identify the given SSP as a carrier-of-record,
> then a unique error will be returned to the provisioning client. If
> "authoritative=false" is explicitly added to the SPPP request, the SPPP
> server will attempt to process the request as non-authoritative. Success or
> failure will be noted in the corresponding SPPP response. If the
> "authoritative" attribute is omitted in a SPPP request, the SPPP server will
> consult local policies to complete the request. In this last case, one
> possible interpretation could be for a SPPP server to test whether the
> provisioning SSP is in fact a carrier-of-record and process it accordingly.
> - (3-) Line 160: All response methods now extend BasicRspnsType. This avoids
> repetition in each request method definition. And it also simplifies the XML
> output. Please see the corresponding before- and after- attached XML
> messages as examples.
> - (3-) Line 162: "clientTransId" and "serverTransId" are now attributes. In
> doing so, as demonstrated in the attached after- XML output, as a common
> denominator to all SPPP responses, it is not mixed with the context of the
> implied SPPP response message that contains the response code and the
> corresponding response text.
> - (3-) Line 214+: All SPPP request and response method types now extend from
> the corresponding BasicRqstType and BasicRspnsType. The attached before and
> after examples of XML output show the effect.
> - (2-) Line 354+: An optional "transactional" attribute has been added in
> support of use case "PROV #3" per
> draft-ietf-drinks-usecases-requirements-03.txt.
>
> thanks,
>
> -Syed
>
>
> On 5/7/10 4:21 PM, "Syed Ali" <[email-masked]> wrote:
>
>>
>>
>> Ken,
>>
>> Thanks for the background information. Please, see inline.
>>
>>
>> On 5/7/10 2:07 PM, "Cartwright, Kenneth" <[email-masked]> wrote:
>>
>>> Hi Syed,
>>>
>>> These are good thoughts.  My $.02 is in-line below, prefixed with "KJC".
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>> Ali, Syed Wasim
>>> Sent: Friday, May 07, 2010 12:36 PM
>>> To: [email-masked]
>>> Subject: [drinks] protocol observations...
>>>
>>>
>>> Hi,
>>>
>>> While working on the protocol mapping, I noted a few things that I thought
>>> we should either acknowledge as they stand or make the needed changes, if
>>> necessary. NOTE: All of the following bullets relate to the single instance
>>> document towards the end of the email.
>>>
>>> - "minorVer" is the attribute defined for element basicRqst of type
>>> spppb:BasicRqstType. First, should we change the element name to "version"
>>> since there is no other type of version element found in the schema. Second,
>>> the version type is defined as spppb:MinorVerType(unsignedLong). We often
>>> encounter version numbers to have at least a major and minor version
>>> expressed in the form "1.0" or a more elaborate "1.0.2". Considering the
>>> fact that the version number is arbitrary at best, and not something
>>> constrained to a specific value, I think we should think about changing it
>>> to "string"; as in spppb:MinorVerType(string). Third, any reason why the
>>> version number is part of the <basicRqst> in the nested element and not
>>> <spppRequest> root element, which I believe has to be used for every single
>>> request? Fourth, is the intent to communicate the version number of SPPP
>>> protocol or something arbitrary that is implementation specific? If former,
>>> the namespace can arguably fulfill the need (as in SAML,...). And for the
>>> latter, one it shouldn't be a mandatory argument and two, we should perhaps
>>> consider removing version altogether in favor of extensions mechanism. And
>>> lastly, there seems to be an opportunity to change the name
>>> spppb:MinorVerType to spppb:VersionType.
>>>
>>> KJC:  As you suggest, there are multiple ways to handle versioning.  And it
>>> may be that, because the "Versioning" section of the protocol text document
>>> has not been written, the expected approach to versioning is unclear.  My
>>> thoughts on this are...
>>>         1) The intent was to use the namespace to only indicate the major
>>> version, and to use the minorVer element to indicate the minor version.  The
>>> purported advantage of this is that the namespace need not change when onlyt
>>> minor changes are made.
>>>         2) In light of point 1 above, changing the name to just "version"
>>> would of course be inaccurate and confusing.
>>>         3) Having it as an unsigned integer value instead of a string make
>>> its
>>> content and structure more precise and limited.  And because it is just the
>>> minor version, that seemed fine and good.
>> Ah! Now I know the intent. And yes, the protocol schema doesn't make it
>> self-evident. "minor change" has the same effect as a major change in that
>> the two potential SPPP implementations are no longer the same. While the
>> value of the major version is in the clear, "minor version" value is
>> arbitrary. This poses yet another challenge as to how the two validating
>> SPPP implementations will corroborate the value to know what's different and
>> how to correctly process the request. Given the fact that the SPPP protocol
>> supports extension mechanics, I am not sure if spppb:MinorVerType adds any
>> value.
>>
>>>         4) I see your point about moving it out of BasicRqstType and
>>> BasicQueryType and into spppRequest.  But keep in mind that the former two
>>> are
>>> both object type definitions, while the latter, spppRequest, is an element
>>> definition.  If, after considering this point, you still feel that it is
>>> cleaner to move the version tag into spppRequest then I'm ok with it too.
>> The difference between the BasicRqstType and BasicQueryType is that the
>> latter doesn't have a 'clientTransId'. This limits the queries to one sync
>> request per connection to SPPP server. The SPPP client is forced to wait for
>> the response before it can issue another query since there is no longer a
>> unique handle to disambiguate the response from the server. Also, the method
>> names, like getRteGrpsRqst, clearly spells out the intent. I am not sure we
>> need to maintain a separate data type BasicQueryType.
>>
>>>
>>> - <rteRec> has the the 0..unbounded ordinal association within the <rteGrp>.
>>> I think it should be changed to 1..unbounded since, along with the name of
>>> the route group, <rteGrp> definition is incomplete without at least a single
>>> <rteRec>
>>>
>>> KJC:  Given that (1) a sequence of provisioning activities that involved
>>> building-up the content of a RteGrp may result in a RteGrp not having any
>>> rteRec for some period of time, and (2) it may be the case that some
>>> elements
>>> of a RteGrp are valuable even if there are no rteRecs associated with a
>>> RteGrp, and (3) other unforeseen boundary condisions, I feel a great deal
>>> more
>>> comfortable with the protocol allowing for the possibility that there may be
>>> zero rteRecs on a RteGrp under some circumstances.  Not allowing for that
>>> possibility I think may very well come to bite us and would probably result
>>> in
>>> provisioners, from time-to-time, creating "dummy" rteRecs just to work
>>> around
>>> that requirement.
>> Ok. The SPPP server will have to perform validations for certain actions.
>> For instance, for an add route group request, a RteGrp structure with
>> <isInSvc> set to true and no <rteRec> definition should not be disallowed or
>> else TN activation requests to such a RteGrp can spell disaster.
>>
>>>
>>> - In the last published schema document, a separate element <targetDomain>
>>> was introduced as a child of <rteGrp>. Based on the latest discussions, I
>>> suppose it is ok to remove it in favor of expressing the target domain as a
>>> RteRec.
>>>
>>> KJC:  Right.  I think when we see your proposal on the XML data structures
>>> that will contain the data elements necessary to meet the "LUF use cases" in
>>> the latest version of the use case document, then it will become clear
>>> whether
>>> that data element is no longer necessary.
>> Ok.
>>
>>>
>>> - <basicRqst> is something that applies for ALL requests. There is an
>>> opportunity to move it to <spppRequest>, the ultimate root element for ALL
>>> SPPP requests.
>>>
>>> KJC:  An element of type BasicRqstType is in any update actions, but an
>>> element of type BasicQueryType is in any query actions.  So I don't think it
>>> is just a matter of moving the element called basicRqst into the spppRequest
>>> element.  But perhaps you could propose some larger re-organization of the
>>> elements to achieve the goal you are implying.
>>
>> Please, see above reasons. If we add the 'clientTransId' in the
>> BasicQueryType, it is sytactically the same as BasicRqstType. This may be a
>> good thing since semantically speaking, QueryType is also a request like
>> RqstType.
>>
>> The BasicRqstType is repeated in all method requests in the schema. And
>> unless I am missing something, I think we can try to improve on this. I know
>> you are flexible about this issue. Attached examples reflect the changes
>> whereby the "before_" reflects the validated XML instance based on the last
>> published protocol schema and "after_" reflects the changes I am proposing.
>> The way I see it, we are favoring simplicity by removing duplicate
>> definitions across schema.
>>
>>>
>>> - Registrar information in this message is merely a label. This is not
>>> enough information for the server to validate if the registrant has
>>> authorized the registrar to provision data on its behalf. With that in mind,
>>> what real value does this add? On the other hand, I think it is reasonable
>>> to leave the <rantId> in place to enable a Registrar to provision on behalf
>>> of one or more Registrant. In both cases, provisioning server will have to
>>> use out of band mechanics to make the authorization check.
>>>
>>> KJC:  As with "versioning" discussed above, perhaps the fact that the
>>> Registrar/Registrant section of the protocol doc has not been written
>>> results
>>> in a lack of clarity here.  It is the intent that the relationship between
>>> the
>>> clientID element (that identifies the registrar) and the rantIds (that
>>> identify the registrant) are managed outside the protocol.  Attempting to
>>> manage these inside the protocol would create a chicken and egg problem.
>>> Iow,
>>> allocation of the organization IDs that play a role in authorization need to
>>> be managed outside the protocol because the protocol commands must be
>>> authorized.  However, as mentioned on the use case review, I think we are
>>> missing a couple use cases related to Registrar/Registrant relationships, so
>>> we may be missing a couple related things in the protocol as well (e.g. how
>>> a
>>> DataRecipient identifier relates to a Registrar and/or Registrant
>>> identifier,
>>> and how/if the list of DataRecipients can be looked up).  If you wanna make
>>> a
>>> proposal on that front that would be great.
>> Thanks for the detailed response. Just to be sure, I am not advocating
>> solving the registrar and registrant relationship in the protocol. And you
>> are right that the "organization IDs" management happens elsewhere. The
>> question is that since there isn't enough trust information in the message
>> that enables registrar and registrant relationship, why even include who the
>> registrar is? If you are planning to add the missing use cases, we can delve
>> into this a little later.
>>
>>>
>>>
>>> Thoughts? And sorry about the long email. The reason why I am not posting it
>>> to the list just yet is because I lack the historical perspective and some
>>> of the above questions could be answered rather easily without much noise.
>>>
>>> -Syed
>>>
>>> =======================================================
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <spppRequest xmlns="urn:ietf:params:xml:ns:sppp:base:1"
>>>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>     xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1">
>>>     <addRteGrpsRqst>
>>>         <basicRqst>
>>>             <clientTransId>tx_id-1983461983</clientTransId>
>>>             <minorVer>50</minorVer>
>>>         </basicRqst>
>>>         <rteGrp>
>>>             <base>
>>>                 <rantId>registrant_1</rantId>
>>>                 <rarId>registrar_1</rarId>
>>>             </base>
>>>             <rteGrpName>rte_grp_1</rteGrpName>
>>>             <rteRec xsi:type="NAPTRType">
>>>                 <order>10</order>
>>>                 <pref>100</pref>
>>>                 <flags>u</flags>
>>>                 <svcs>E2U+sip</svcs>
>>>                 <regx>
>>>                     <ere>^(.*)$</ere>
>>>                     <repl>sip:\[email-masked]</repl>
>>>                 </regx>
>>>             </rteRec>
>>>             <isInSvc>true</isInSvc>
>>>         </rteGrp>
>>>         <rteGrp>
>>>             <base>
>>>                 <rantId>registrant_1</rantId>
>>>                 <rarId>registrar_1</rarId>
>>>             </base>
>>>             <rteGrpName>rte_grp_2</rteGrpName>
>>>             <rteRec xsi:type="NAPTRType">
>>>                 <order>10</order>
>>>                 <pref>100</pref>
>>>                 <flags>u</flags>
>>>                 <svcs>E2U+sip</svcs>
>>>                 <regx>
>>>                     <ere>^(.*)$</ere>
>>>                     <repl>sip:\[email-masked]</repl>
>>>                 </regx>
>>>             </rteRec>
>>>             <isInSvc>true</isInSvc>
>>>         </rteGrp>
>>>     </addRteGrpsRqst>
>>> </spppRequest>
>>>
>>> _______________________________________________
>>> drinks mailing list
>>> [email-masked]
>>> 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.
>>>
>>
>
>
> 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.
>

---

From: "Cartwright, Ken" <[email-masked]>
Date: Tue, 1 Jun 2010 10:30:07 -0400

Hi Syed,

1) It would not be good, imo to move the PI to Dest Grp relationship inside the DestGrpType object.  Doing so would make the size of the DestGrpType objet unwieldy (think hundreds of thousands of PIs in a single DestGrpType.  So the current design of having the PI to DestGrp relationship living in the PI is better.  But the point I was making was about the location of the RteGrp to DestGrp relationship.  The RteGrp needs to contain the list of DestGrps that the RteGrp is associated with, rather than the other way around.

2) Ok.

3) Ok.

4) If necessary, please call me so that we can discuss.  The concept of authoritative/COR/Transit does not apply to all types of topology objects.  For example, it does not apply to DestGrps, or DataRecipients, or RRs.  It really only needs to apply to PIs.  So the authoritative/COR/Transit concept should be an attribute of a PI object, not a setting at the request level.

5) Not sure what happened to "5".  :-)

6) Ok.

7) Ok.  I'm gonna let Sumanth take over this point.  He has more succinct and stronger feelings about it than I.  Sumanth?

8) Wow.  :-) We're on totally different wavelengths on this one.  :-)  The getter methods are intended to allow the SPPP client to get the properties of any of the SPPP objects that they have the authority to view.  They aren't ENUM lookups of SIP invites.  Secondly, on your point about "if we do not have transaction IDs in the getter responses then the client has to wait for the response", I don't really see it that way.  That is really a statement about the transport, more than the protocol, but just to get us in sync... In a SOAP over HTTP "transport" the requests and responses will always be written and read in order, so even without the transaction ID the client and server can always correlate the request and the responses, even without transaction IDs.  In a different type of "transport" the client and server could agree to support "pipelining" where the client can write  multiple request to a single TCP connection and then start reading the responses on that connection.  The client and server can still always correlate the request with the responses because they always come back in the correct order on that TCP connection.  So I still maintain that we should not have transaction IDs on getters.

9/10) We discussed this during today's call.  JFM is going to write down the Rqmnts we discussed and we will go from there.

-----Original Message-----
From: Ali, Syed Wasim [mailto:[email-masked]]
Sent: Tuesday, June 01, 2010 4:35 AM
To: Cartwright, Ken; Sumanth Channabasappa; David Schwartz; Maharishi, Manjul; Jean-Francois Mule; Alexander Mayrhofer; Hadriel Kaplan; [email-masked]
Subject: Re: [drinks] protocol observations...

Ken,

Reqts doc says:

thoughts?

Done.

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.

---

From: "Ali, Syed Wasim" <[email-masked]>
Date: Tue, 1 Jun 2010 16:09:40 -0400

please see inline.

On 6/1/10 10:30 AM, "Cartwright, Ken" <[email-masked]> wrote:

> Hi Syed,
>
> 1) It would not be good, imo to move the PI to Dest Grp relationship inside
> the DestGrpType object.  Doing so would make the size of the DestGrpType objet
> unwieldy (think hundreds of thousands of PIs in a single DestGrpType.
makes sense.

> So the
> current design of having the PI to DestGrp relationship living in the PI is
> better.
In that case, we have this already covered:

    <complexType name="PubIdType" abstract="true">
        <sequence>
            <element name="base" type="spppb:BasicObjType"/>
            <element name="dgName" type="string" minOccurs="0"/>

> But the point I was making was about the location of the RteGrp to
> DestGrp relationship.  The RteGrp needs to contain the list of DestGrps that
> the RteGrp is associated with, rather than the other way around.
I am sure there is a good reason for the latter, but I am drawing a blank as
I write this. Referring to the Figure 4 below from
"draft-mule-drinks-proto-02"

                        +-----------------------+
                        |Route Group:           |
                        |  rteGrpName*,         |
                        |  isInService,         |
                        |  targetDomain,        |
                        |  extension            |
                        |                       |
                        +-----------------------+
                                   ^
                                   |
                         +---------+------------+
                         |Destination           |
                         |Group:                |
                         |  destGroupName*,     |<----+
                         |  routeGrpNames*,     |     |
                         |  extension           |     |
                         +----------------------+     |
                                                      |
                                        +-------------+---------+
                                        |Public                 |
                                        |Identifier:            |
                                        |  publicIdentifier*,   |
                                        |  destGroupName*,      |
                                        |  extension            |
                                        +-----------------------+

         LUF-only Data Model Example for SPPP for DRINKS WG Review

                                 Figure 4

Here is one possible sequence of provisioning steps to activate a public
identifier
1- create a rtegrp called "rtegrp_1" with a rterec definition.
2- create a dest group called "dstgrp_1" with "rtegrp_1" as part of it.
3- create a public identifier that identifies with "dstgrp_1"

What am I missing?  :-)

>
> 2) Ok.
>
> 3) Ok.
>
> 4) If necessary, please call me so that we can discuss.  The concept of
> authoritative/COR/Transit does not apply to all types of topology objects.
> For example, it does not apply to DestGrps, or DataRecipients, or RRs.  It
> really only needs to apply to PIs.  So the authoritative/COR/Transit concept
> should be an attribute of a PI object, not a setting at the request level.
This is a fair observation. However, by adding the authority in the top
level request, I thought we captured the intent, that is, "Execute this
request with the stated authority". And in cases where it doesn't apply, it
could amount to NO-OP. This generic treatment makes it available for future
use. Still, we can consider limiting the use of authority to PI if this is
where the larger consensus is.

> 7) Ok.  I'm gonna let Sumanth take over this point.  He has more succinct and
> stronger feelings about it than I.  Sumanth?
>
> 8) Wow.  :-) We're on totally different wavelengths on this one.  :-)  The
> getter methods are intended to allow the SPPP client to get the properties of
> any of the SPPP objects that they have the authority to view.  They aren't
> ENUM lookups of SIP invites.  Secondly, on your point about "if we do not have
> transaction IDs in the getter responses then the client has to wait for the
> response", I don't really see it that way.  That is really a statement about
> the transport, more than the protocol, but just to get us in sync... In a SOAP
> over HTTP "transport" the requests and responses will always be written and
> read in order, so even without the transaction ID the client and server can
> always correlate the request and the responses, even without transaction IDs.
> In a different type of "transport" the client and server could agree to
> support "pipelining" where the client can write  multiple request to a single
> TCP connection and then start reading the responses on that connection.  The
> client and server can still always correlate the request with the responses
> because they always come back in the correct order on that TCP connection.  So
> I still maintain that we should not have transaction IDs on getters.

:-) Not the first for me; I suspected something was amiss.  :-) Your
reference to the SOAP over HTTP "transport" behavior will not be complete
without an added constraint that the server process is either
single-threaded or the same effect is achieved by serializing requests by
other means. Specially for "read-only" operations, such as getters, these
are performance impacting and I am sure we don't want to introduce these
limitations in or as part of the SPPP. To elaborate on this point further,
it is normal to have the following race condition in resource optimized
environments:

SPPP        SPPP        (1)               (2)             (3)
Client      Server      Thr               Thr             Thr
======      ======      ======            ===             ===
  |   REQ1    |             |               |             |
  |---------->|   REQ1      |               |             |
  |   REQ2    |------------>|               |             |
  |---------->|             |      REQ2     |             |
  |   REQ3    |---------------------------->|             |
  |---------->|             |               |    REQ3     |
  |           |------------------------------------------>|
  |   RESP2   |             |               |             |
  |<----------------------------------------|             |
  |   RESP1   |             |               |             |
  |<------------------------|               |             |
  |   RESP3   |             |               |             |
  |<------------------------------------------------------|

In the end, your point about not requiring a "clientTransId" for the getters
in not without merit for other reasons. In fact, it is important to give the
provisioning entities the needed flexibility to exercise their own judgment
whether a specific mention of "clientTransId" is needed to begin with, be it
a getter or an update method. It is important to note that "serverTransId"
is a *mandatory* element that serves as the glue b/w an atomic SPPP request
and a response. In this case, I will side with other IETF efforts, such as,
EPP spec, which leaves the "clientTransId" as an *optional* field. Finally,
this resolve meets our objectives such that the "clientTransId" is available
for provisioning entities to use as an *optional* field to fit their own eco
system. And the SPPP server MUST include the "clientTransId" in the request,
only if it is included in the original request.
>
> 9/10) We discussed this during today's call.  JFM is going to write down the
> Rqmnts we discussed and we will go from there.
>
> To: Cartwright, Ken; Sumanth Channabasappa; David Schwartz; Maharishi, Manjul;

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 2 Jun 2010 13:04:09 -0400

Hi Syed,

...because if you want to set up a Route Group to identify the points of ingress or other SED for multiple destination groups it requires that multiple dest group objects be modified over the protocol.  Not good.  Whereas if the relationship were in the Rte Group it's just a single object modification.

...secondarily, given the primary role of a dest group and the primary role of a route group, it better fits the role of the route group to contain that relationship over the dest group.

Ken

-----Original Message-----
From: Ali, Syed Wasim [mailto:[email-masked]]
Sent: Tuesday, June 01, 2010 4:10 PM
To: Cartwright, Ken; Sumanth Channabasappa; David Schwartz; Maharishi, Manjul; Jean-Francois Mule; Alexander Mayrhofer; Hadriel Kaplan; [email-masked]
Subject: Re: [drinks] protocol observations...

please see inline.

makes sense.

                                 Figure 4

What am I missing?  :-)

SPPP        SPPP        (1)               (2)             (3)