Subject: [drinks] protocol observations...

From: "Ali, Syed Wasim" <[email-masked]>
Date: Fri, 7 May 2010 12:36:07 -0400

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.

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

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

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

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

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>

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Fri, 7 May 2010 14:07:02 -0400

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,

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

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.

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.

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.

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.

-Syed

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

---

From: "Ali, Syed Wasim" <[email-masked]>
Date: Fri, 7 May 2010 16:21:38 -0400

Ken,

Thanks for the background information. Please, see inline.

On 5/7/10 2:07 PM, "Cartwright, Kenneth" <[email-masked]> wrote:

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

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

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

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

> 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.
 
> 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, 25 May 2010 22:15:57 -0400

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

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 26 May 2010 12:56:54 -0400

Hi Syed,

I was out sick yesterday and have also been otherwise swamped.  I'll get a chance to provide input to your emails later today and tomorrow.

Ken

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

thanks,

-Syed

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 26 May 2010 18:25:08 -0400

Hi Syed,

Nice work.  My $.02 is...

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.
2) DestGroupType should be renamed to DestGrpType.
3) In URIType is there a reason that the "ere" element is defined/located here as an attribute of the object?
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.
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.
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".
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.
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.

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

thanks,

-Syed