From syed.ali@neustar.biz  Tue Jun  1 01:35:12 2010
Return-Path: <syed.ali@neustar.biz>
X-Original-To: drinks@core3.amsl.com
Delivered-To: drinks@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84A343A6972 for <drinks@core3.amsl.com>; Tue,  1 Jun 2010 01:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.334
X-Spam-Level: ***
X-Spam-Status: No, score=3.334 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FB_IOW=3.333]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSEK8r2sS3A4 for <drinks@core3.amsl.com>; Tue,  1 Jun 2010 01:35:10 -0700 (PDT)
Received: from neustar.com (mx1.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 761563A6986 for <drinks@ietf.org>; Tue,  1 Jun 2010 01:35:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1275381292; x=1590734577; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=vQf1CUECExs/UkpD/VES7 ZM49zG4uROynk+Yfj6/zEI=; b=OITn2PB/O39Hdi8AnyDEVjrYW1/HC7HFsY3Gd MWMmS8DTMlNzHQSQcFEr9+HzYgNjHHcs8MKo+DR2QJYx5fbOg==
Received: from ([10.31.13.50]) by stihiron2.va.neustar.com with ESMTP  id 5202732.32943819; Tue, 01 Jun 2010 04:34:51 -0400
Received: from STNTEXCHHT03.cis.neustar.com ([10.31.13.242]) by stntexch11.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 1 Jun 2010 04:34:45 -0400
Received: from STNTEXCH02.cis.neustar.com ([fe80::f828:7b2d:14aa:84b7]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 1 Jun 2010 04:35:09 -0400
From: "Ali, Syed Wasim" <syed.ali@neustar.biz>
To: "Cartwright, Ken" <kcartwright@tnsi.com>, Sumanth Channabasappa <sumanth@cablelabs.com>, David Schwartz <dschwartz@xconnect.net>, "Maharishi, Manjul" <mmaharishi@tnsi.com>, Jean-Francois Mule <jf.mule@cablelabs.com>, Alexander Mayrhofer <alexander.mayrhofer@nic.at>,  Hadriel Kaplan <HKaplan@acmepacket.com>, "drinks@ietf.org" <drinks@ietf.org>
Date: Tue, 1 Jun 2010 04:34:47 -0400
Thread-Topic: [drinks] protocol observations...
Thread-Index: AcruA2Riqb+RexL1R06SGhtB33meHwADHFtAAATD62MDlZ6zMgAn1NgAARMlz1o=
Message-ID: <C82A3E67.3CCBE%syed.ali@neustar.biz>
In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA2446E8C7F9@TNS-MAIL-NA.win2k.corp.tnsi.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA==
x-ems-stamp: 1+muHz/zYNV33gDO7GKAZg==
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 01 Jun 2010 08:34:45.0619 (UTC) FILETIME=[4A11B430:01CB0165]
Subject: Re: [drinks] protocol observations...
X-BeenThere: drinks@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DRINKS WG <drinks.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/drinks>
List-Post: <mailto:drinks@ietf.org>
List-Help: <mailto:drinks-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Jun 2010 08:35:12 -0000

Ken,

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

On 5/26/10 6:25 PM, "Cartwright, Ken" <kcartwright@tnsi.com> wrote:

>
> 1) Instead of the DestGroupType containing the identifiers of the routes =
that
> route to it, the RteGrpType should contain the identifiers of the destina=
tion
> 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=3D"DestGrpType">
        <sequence>
            <element name=3D"base" type=3D"spppb:BasicObjType"/>
            <element name=3D"dgName" type=3D"string"/>
            <element name=3D"rteGrpName" type=3D"string" minOccurs=3D"0"
maxOccurs=3D"unbounded"/>
        </sequence>
    </complexType>

Updated type definitions:

    <complexType name=3D"DestGrpType">
        <sequence>
            <element name=3D"base" type=3D"spppb:BasicObjType"/>
            <element name=3D"dgName" type=3D"string"/>
            <element name=3D"pi" type=3D"spppb:" maxOccurs=3D"unbounded"/>
        </sequence>
    </complexType>
    <complexType name=3D"RteGrpType">
        <sequence>
            <element name=3D"base" type=3D"spppb:BasicObjType"/>
            <element name=3D"rteGrpName" type=3D"string"/>
            <element name=3D"rteRec" type=3D"spppb:RteRecType" minOccurs=3D=
"0"
maxOccurs=3D"unbounded"/>
            <element name=3D"destGrp" type=3D"spppb:DestGrpType" minOccurs=
=3D"0"
maxOccurs=3D"unbounded"/>
            <element name=3D"peeringOrg" type=3D"spppb:OrgIdType" minOccurs=
=3D"0"
maxOccurs=3D"unbounded"/>
            <element name=3D"sourceIdent" type=3D"spppb:SourceIdentType"
minOccurs=3D"0"
                maxOccurs=3D"unbounded"/>
            <element name=3D"isInSvc" type=3D"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 t=
hese
> 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 no=
t
> 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 informati=
on
> 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 vers=
ion
> 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 th=
e
> majMinVersion element in SvcMenuType to just "version".
This is something that we continue to discuss. We should tee this up for th=
e
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 ha=
ve
> the getter methods include/extend the BasicRqstType (which contains the
> clientTransId).  For similar reason, it may not be good to have the gette=
r
> responses include/extend the BasicRspnseType.  The intended use of the
> clientTransId is to help ensure that the server does not miss any transac=
tions
> from a given client, as a result, transactionId's are "consumed" in seque=
nce
> by a given client.  Imposing this same limitation on getters is not neces=
sary,
> 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 ha=
s
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 gette=
r
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 m=
y
understanding of the getters is not correct to begin with. I will await you=
r
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:syed.ali@neustar.biz]
> Sent: Tuesday, May 25, 2010 10:16 PM
> To: Sumanth Channabasappa; Cartwright, Ken; David Schwartz; Maharishi, Ma=
njul;
> Jean-Francois Mule; Alexander Mayrhofer; Hadriel Kaplan; drinks@ietf.org
> 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 a=
nd
> the weekly calls
> (2-) Updates that correspond to the changes in the latest use case docume=
nt
> (3-) Improvements in the schema that do not affect the XML output and tha=
t
> 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 k=
now
> what the change is about.
>
> Also, just to make it absolutely clear, the latest schema remains in a dr=
aft
> stage until such time that a consensus is reached in the usual fashion.
>
> - (1-) Line 15: "targetDomain" element is removed. In the last f2f interi=
m
> meeting, there was agreement that the target-domain will be represented a=
s 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 NAP=
TR
> RR. This had unintended consequences. The latest definition is the same a=
s
> the last published SPPP WG document. This amounts to "no change".
> - (1-) Line 82: default value associated with the optional "ttl" attribut=
e
> 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 avoid=
s
> 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 t=
o
> 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 cas=
e
> "INTERCONNECT #2" per draft-ietf-drinks-usecases-requirements-03.txt. Thi=
s
> 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 provisi=
on
> the request as a carrier-of-record, then "authoritative=3Dtrue" 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-reco=
rd,
> then a unique error will be returned to the provisioning client. If
> "authoritative=3Dfalse" 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 w=
ill
> 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 accordingl=
y.
> - (3-) Line 160: All response methods now extend BasicRspnsType. This avo=
ids
> 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 th=
e
> 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 f=
rom
> the corresponding BasicRqstType and BasicRspnsType. The attached before a=
nd
> 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" <syed.ali@neustar.biz> wrote:
>
>>
>>
>> Ken,
>>
>> Thanks for the background information. Please, see inline.
>>
>>
>> On 5/7/10 2:07 PM, "Cartwright, Kenneth" <kcartwright@tnsi.com> wrote:
>>
>>> Hi Syed,
>>>
>>> These are good thoughts.  My $.02 is in-line below, prefixed with "KJC"=
.
>>>
>>> -----Original Message-----
>>> From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behal=
f Of
>>> Ali, Syed Wasim
>>> Sent: Friday, May 07, 2010 12:36 PM
>>> To: drinks@ietf.org
>>> Subject: [drinks] protocol observations...
>>>
>>>
>>> Hi,
>>>
>>> While working on the protocol mapping, I noted a few things that I thou=
ght
>>> we should either acknowledge as they stand or make the needed changes, =
if
>>> necessary. NOTE: All of the following bullets relate to the single inst=
ance
>>> 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 "versi=
on"
>>> since there is no other type of version element found in the schema. Se=
cond,
>>> the version type is defined as spppb:MinorVerType(unsignedLong). We oft=
en
>>> 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 th=
e
>>> 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 th=
e
>>> 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 si=
ngle
>>> request? Fourth, is the intent to communicate the version number of SPP=
P
>>> protocol or something arbitrary that is implementation specific? If for=
mer,
>>> the namespace can arguably fulfill the need (as in SAML,...). And for t=
he
>>> latter, one it shouldn't be a mandatory argument and two, we should per=
haps
>>> 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.  An=
d it
>>> may be that, because the "Versioning" section of the protocol text docu=
ment
>>> 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 maj=
or
>>> 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 "versio=
n"
>>> would of course be inaccurate and confusing.
>>>         3) Having it as an unsigned integer value instead of a string m=
ake
>>> 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 th=
at
>> 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 proto=
col
>> supports extension mechanics, I am not sure if spppb:MinorVerType adds a=
ny
>> 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 elem=
ent
>>> definition.  If, after considering this point, you still feel that it i=
s
>>> cleaner to move the version tag into spppRequest then I'm ok with it to=
o.
>> The difference between the BasicRqstType and BasicQueryType is that the
>> latter doesn't have a 'clientTransId'. This limits the queries to one sy=
nc
>> 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 me=
thod
>> 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 <rte=
Grp>.
>>> 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 s=
ingle
>>> <rteRec>
>>>
>>> KJC:  Given that (1) a sequence of provisioning activities that involve=
d
>>> building-up the content of a RteGrp may result in a RteGrp not having a=
ny
>>> 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 de=
al
>>> more
>>> comfortable with the protocol allowing for the possibility that there m=
ay be
>>> zero rteRecs on a RteGrp under some circumstances.  Not allowing for th=
at
>>> possibility I think may very well come to bite us and would probably re=
sult
>>> 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 disallowe=
d or
>> else TN activation requests to such a RteGrp can spell disaster.
>>
>>>
>>> - In the last published schema document, a separate element <targetDoma=
in>
>>> 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 structu=
res
>>> that will contain the data elements necessary to meet the "LUF use case=
s" 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 thi=
nk it
>>> is just a matter of moving the element called basicRqst into the spppRe=
quest
>>> 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 b=
e 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 l=
ast
>> published protocol schema and "after_" reflects the changes I am proposi=
ng.
>> 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 reasona=
ble
>>> to leave the <rantId> in place to enable a Registrar to provision on be=
half
>>> 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 betw=
een
>>> 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 ne=
ed to
>>> be managed outside the protocol because the protocol commands must be
>>> authorized.  However, as mentioned on the use case review, I think we a=
re
>>> missing a couple use cases related to Registrar/Registrant relationship=
s, 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 y=
ou
>> are right that the "organization IDs" management happens elsewhere. The
>> question is that since there isn't enough trust information in the messa=
ge
>> 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 d=
elve
>> into this a little later.
>>
>>>
>>>
>>> Thoughts? And sorry about the long email. The reason why I am not posti=
ng it
>>> to the list just yet is because I lack the historical perspective and s=
ome
>>> of the above questions could be answered rather easily without much noi=
se.
>>>
>>> -Syed
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
>>>
>>> <?xml version=3D"1.0" encoding=3D"UTF-8"?>
>>> <spppRequest xmlns=3D"urn:ietf:params:xml:ns:sppp:base:1"
>>>     xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
>>>     xsi:schemaLocation=3D"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=3D"NAPTRType">
>>>                 <order>10</order>
>>>                 <pref>100</pref>
>>>                 <flags>u</flags>
>>>                 <svcs>E2U+sip</svcs>
>>>                 <regx>
>>>                     <ere>^(.*)$</ere>
>>>                     <repl>sip:\1@gw1.example.com</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=3D"NAPTRType">
>>>                 <order>10</order>
>>>                 <pref>100</pref>
>>>                 <flags>u</flags>
>>>                 <svcs>E2U+sip</svcs>
>>>                 <regx>
>>>                     <ere>^(.*)$</ere>
>>>                     <repl>sip:\1@gw2.example.com</repl>
>>>                 </regx>
>>>             </rteRec>
>>>             <isInSvc>true</isInSvc>
>>>         </rteGrp>
>>>     </addRteGrpsRqst>
>>> </spppRequest>
>>>
>>> _______________________________________________
>>> drinks mailing list
>>> drinks@ietf.org
>>> 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-ma=
il
>>> and
>>> destroy all copies of the original message.
>>>
>>
>
>
> This e-mail message is for the sole use of the intended recipient(s)and m=
ay
> contain confidential and privileged information of Transaction Network
> Services.
> Any unauthorised review, use, disclosure or distribution is prohibited. I=
f you
> are not the intended recipient, please contact the sender by reply e-mail=
 and
> destroy all copies of the original message.
>


From kcartwright@tnsi.com  Tue Jun  1 07:30:31 2010
Return-Path: <kcartwright@tnsi.com>
X-Original-To: drinks@core3.amsl.com
Delivered-To: drinks@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF83628C149 for <drinks@core3.amsl.com>; Tue,  1 Jun 2010 07:30:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.334
X-Spam-Level: ***
X-Spam-Status: No, score=3.334 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FB_IOW=3.333]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFP3QKpYTPce for <drinks@core3.amsl.com>; Tue,  1 Jun 2010 07:30:29 -0700 (PDT)
Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 86C8A28C0F5 for <drinks@ietf.org>; Tue,  1 Jun 2010 07:30:26 -0700 (PDT)
Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.44164580; Tue, 01 Jun 2010 10:30:09 -0400
Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 1 Jun 2010 10:30:09 -0400
From: "Cartwright, Ken" <kcartwright@tnsi.com>
To: "Ali, Syed Wasim" <syed.ali@neustar.biz>, Sumanth Channabasappa <sumanth@cablelabs.com>, David Schwartz <dschwartz@xconnect.net>, "Maharishi, Manjul" <mmaharishi@tnsi.com>, Jean-Francois Mule <jf.mule@cablelabs.com>, Alexander Mayrhofer <alexander.mayrhofer@nic.at>,  Hadriel Kaplan <HKaplan@acmepacket.com>, "drinks@ietf.org" <drinks@ietf.org>
Date: Tue, 1 Jun 2010 10:30:07 -0400
Thread-Topic: [drinks] protocol observations...
Thread-Index: AcruA2Riqb+RexL1R06SGhtB33meHwADHFtAAATD62MDlZ6zMgAn1NgAARMlz1oAC6RfIA==
Message-ID: <754963199212404AB8E9CFCA6C3D0CDA2446E8D384@TNS-MAIL-NA.win2k.corp.tnsi.com>
References: <754963199212404AB8E9CFCA6C3D0CDA2446E8C7F9@TNS-MAIL-NA.win2k.corp.tnsi.com> <C82A3E67.3CCBE%syed.ali@neustar.biz>
In-Reply-To: <C82A3E67.3CCBE%syed.ali@neustar.biz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [drinks] protocol observations...
X-BeenThere: drinks@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DRINKS WG <drinks.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/drinks>
List-Post: <mailto:drinks@ietf.org>
List-Help: <mailto:drinks-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Jun 2010 14:30:32 -0000

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 o=
bjet unwieldy (think hundreds of thousands of PIs in a single DestGrpType. =
 So the current design of having the PI to DestGrp relationship living in t=
he 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 De=
stGrps 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 aut=
horitative/COR/Transit does not apply to all types of topology objects.  Fo=
r example, it does not apply to DestGrps, or DataRecipients, or RRs.  It re=
ally 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 a=
nd 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 no=
t 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 statem=
ent 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 withou=
t transaction IDs.  In a different type of "transport" the client and serve=
r 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 requ=
est with the responses because they always come back in the correct order o=
n that TCP connection.  So I still maintain that we should not have transac=
tion IDs on getters.

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

-----Original Message-----
From: Ali, Syed Wasim [mailto:syed.ali@neustar.biz]
Sent: Tuesday, June 01, 2010 4:35 AM
To: Cartwright, Ken; Sumanth Channabasappa; David Schwartz; Maharishi, Manj=
ul; Jean-Francois Mule; Alexander Mayrhofer; Hadriel Kaplan; drinks@ietf.or=
g
Subject: Re: [drinks] protocol observations...


Ken,

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

On 5/26/10 6:25 PM, "Cartwright, Ken" <kcartwright@tnsi.com> wrote:

>
> 1) Instead of the DestGroupType containing the identifiers of the routes =
that
> route to it, the RteGrpType should contain the identifiers of the destina=
tion
> 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=3D"DestGrpType">
        <sequence>
            <element name=3D"base" type=3D"spppb:BasicObjType"/>
            <element name=3D"dgName" type=3D"string"/>
            <element name=3D"rteGrpName" type=3D"string" minOccurs=3D"0"
maxOccurs=3D"unbounded"/>
        </sequence>
    </complexType>

Updated type definitions:

    <complexType name=3D"DestGrpType">
        <sequence>
            <element name=3D"base" type=3D"spppb:BasicObjType"/>
            <element name=3D"dgName" type=3D"string"/>
            <element name=3D"pi" type=3D"spppb:" maxOccurs=3D"unbounded"/>
        </sequence>
    </complexType>
    <complexType name=3D"RteGrpType">
        <sequence>
            <element name=3D"base" type=3D"spppb:BasicObjType"/>
            <element name=3D"rteGrpName" type=3D"string"/>
            <element name=3D"rteRec" type=3D"spppb:RteRecType" minOccurs=3D=
"0"
maxOccurs=3D"unbounded"/>
            <element name=3D"destGrp" type=3D"spppb:DestGrpType" minOccurs=
=3D"0"
maxOccurs=3D"unbounded"/>
            <element name=3D"peeringOrg" type=3D"spppb:OrgIdType" minOccurs=
=3D"0"
maxOccurs=3D"unbounded"/>
            <element name=3D"sourceIdent" type=3D"spppb:SourceIdentType"
minOccurs=3D"0"
                maxOccurs=3D"unbounded"/>
            <element name=3D"isInSvc" type=3D"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 t=
hese
> 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 no=
t
> 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 informati=
on
> 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 vers=
ion
> 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 th=
e
> majMinVersion element in SvcMenuType to just "version".
This is something that we continue to discuss. We should tee this up for th=
e
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 ha=
ve
> the getter methods include/extend the BasicRqstType (which contains the
> clientTransId).  For similar reason, it may not be good to have the gette=
r
> responses include/extend the BasicRspnseType.  The intended use of the
> clientTransId is to help ensure that the server does not miss any transac=
tions
> from a given client, as a result, transactionId's are "consumed" in seque=
nce
> by a given client.  Imposing this same limitation on getters is not neces=
sary,
> 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 ha=
s
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 gette=
r
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 m=
y
understanding of the getters is not correct to begin with. I will await you=
r
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:syed.ali@neustar.biz]
> Sent: Tuesday, May 25, 2010 10:16 PM
> To: Sumanth Channabasappa; Cartwright, Ken; David Schwartz; Maharishi, Ma=
njul;
> Jean-Francois Mule; Alexander Mayrhofer; Hadriel Kaplan; drinks@ietf.org
> 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 a=
nd
> the weekly calls
> (2-) Updates that correspond to the changes in the latest use case docume=
nt
> (3-) Improvements in the schema that do not affect the XML output and tha=
t
> 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 k=
now
> what the change is about.
>
> Also, just to make it absolutely clear, the latest schema remains in a dr=
aft
> stage until such time that a consensus is reached in the usual fashion.
>
> - (1-) Line 15: "targetDomain" element is removed. In the last f2f interi=
m
> meeting, there was agreement that the target-domain will be represented a=
s 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 NAP=
TR
> RR. This had unintended consequences. The latest definition is the same a=
s
> the last published SPPP WG document. This amounts to "no change".
> - (1-) Line 82: default value associated with the optional "ttl" attribut=
e
> 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 avoid=
s
> 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 t=
o
> 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 cas=
e
> "INTERCONNECT #2" per draft-ietf-drinks-usecases-requirements-03.txt. Thi=
s
> 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 provisi=
on
> the request as a carrier-of-record, then "authoritative=3Dtrue" 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-reco=
rd,
> then a unique error will be returned to the provisioning client. If
> "authoritative=3Dfalse" 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 w=
ill
> 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 accordingl=
y.
> - (3-) Line 160: All response methods now extend BasicRspnsType. This avo=
ids
> 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 th=
e
> 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 f=
rom
> the corresponding BasicRqstType and BasicRspnsType. The attached before a=
nd
> 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" <syed.ali@neustar.biz> wrote:
>
>>
>>
>> Ken,
>>
>> Thanks for the background information. Please, see inline.
>>
>>
>> On 5/7/10 2:07 PM, "Cartwright, Kenneth" <kcartwright@tnsi.com> wrote:
>>
>>> Hi Syed,
>>>
>>> These are good thoughts.  My $.02 is in-line below, prefixed with "KJC"=
.
>>>
>>> -----Original Message-----
>>> From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behal=
f Of
>>> Ali, Syed Wasim
>>> Sent: Friday, May 07, 2010 12:36 PM
>>> To: drinks@ietf.org
>>> Subject: [drinks] protocol observations...
>>>
>>>
>>> Hi,
>>>
>>> While working on the protocol mapping, I noted a few things that I thou=
ght
>>> we should either acknowledge as they stand or make the needed changes, =
if
>>> necessary. NOTE: All of the following bullets relate to the single inst=
ance
>>> 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 "versi=
on"
>>> since there is no other type of version element found in the schema. Se=
cond,
>>> the version type is defined as spppb:MinorVerType(unsignedLong). We oft=
en
>>> 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 th=
e
>>> 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 th=
e
>>> 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 si=
ngle
>>> request? Fourth, is the intent to communicate the version number of SPP=
P
>>> protocol or something arbitrary that is implementation specific? If for=
mer,
>>> the namespace can arguably fulfill the need (as in SAML,...). And for t=
he
>>> latter, one it shouldn't be a mandatory argument and two, we should per=
haps
>>> 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.  An=
d it
>>> may be that, because the "Versioning" section of the protocol text docu=
ment
>>> 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 maj=
or
>>> 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 "versio=
n"
>>> would of course be inaccurate and confusing.
>>>         3) Having it as an unsigned integer value instead of a string m=
ake
>>> 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 th=
at
>> 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 proto=
col
>> supports extension mechanics, I am not sure if spppb:MinorVerType adds a=
ny
>> 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 elem=
ent
>>> definition.  If, after considering this point, you still feel that it i=
s
>>> cleaner to move the version tag into spppRequest then I'm ok with it to=
o.
>> The difference between the BasicRqstType and BasicQueryType is that the
>> latter doesn't have a 'clientTransId'. This limits the queries to one sy=
nc
>> 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 me=
thod
>> 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 <rte=
Grp>.
>>> 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 s=
ingle
>>> <rteRec>
>>>
>>> KJC:  Given that (1) a sequence of provisioning activities that involve=
d
>>> building-up the content of a RteGrp may result in a RteGrp not having a=
ny
>>> 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 de=
al
>>> more
>>> comfortable with the protocol allowing for the possibility that there m=
ay be
>>> zero rteRecs on a RteGrp under some circumstances.  Not allowing for th=
at
>>> possibility I think may very well come to bite us and would probably re=
sult
>>> 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 disallowe=
d or
>> else TN activation requests to such a RteGrp can spell disaster.
>>
>>>
>>> - In the last published schema document, a separate element <targetDoma=
in>
>>> 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 structu=
res
>>> that will contain the data elements necessary to meet the "LUF use case=
s" 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 thi=
nk it
>>> is just a matter of moving the element called basicRqst into the spppRe=
quest
>>> 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 b=
e 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 l=
ast
>> published protocol schema and "after_" reflects the changes I am proposi=
ng.
>> 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 reasona=
ble
>>> to leave the <rantId> in place to enable a Registrar to provision on be=
half
>>> 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 betw=
een
>>> 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 ne=
ed to
>>> be managed outside the protocol because the protocol commands must be
>>> authorized.  However, as mentioned on the use case review, I think we a=
re
>>> missing a couple use cases related to Registrar/Registrant relationship=
s, 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 y=
ou
>> are right that the "organization IDs" management happens elsewhere. The
>> question is that since there isn't enough trust information in the messa=
ge
>> 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 d=
elve
>> into this a little later.
>>
>>>
>>>
>>> Thoughts? And sorry about the long email. The reason why I am not posti=
ng it
>>> to the list just yet is because I lack the historical perspective and s=
ome
>>> of the above questions could be answered rather easily without much noi=
se.
>>>
>>> -Syed
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
>>>
>>> <?xml version=3D"1.0" encoding=3D"UTF-8"?>
>>> <spppRequest xmlns=3D"urn:ietf:params:xml:ns:sppp:base:1"
>>>     xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
>>>     xsi:schemaLocation=3D"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=3D"NAPTRType">
>>>                 <order>10</order>
>>>                 <pref>100</pref>
>>>                 <flags>u</flags>
>>>                 <svcs>E2U+sip</svcs>
>>>                 <regx>
>>>                     <ere>^(.*)$</ere>
>>>                     <repl>sip:\1@gw1.example.com</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=3D"NAPTRType">
>>>                 <order>10</order>
>>>                 <pref>100</pref>
>>>                 <flags>u</flags>
>>>                 <svcs>E2U+sip</svcs>
>>>                 <regx>
>>>                     <ere>^(.*)$</ere>
>>>                     <repl>sip:\1@gw2.example.com</repl>
>>>                 </regx>
>>>             </rteRec>
>>>             <isInSvc>true</isInSvc>
>>>         </rteGrp>
>>>     </addRteGrpsRqst>
>>> </spppRequest>
>>>
>>> _______________________________________________
>>> drinks mailing list
>>> drinks@ietf.org
>>> 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-ma=
il
>>> and
>>> destroy all copies of the original message.
>>>
>>
>
>
> This e-mail message is for the sole use of the intended recipient(s)and m=
ay
> contain confidential and privileged information of Transaction Network
> Services.
> Any unauthorised review, use, disclosure or distribution is prohibited. I=
f 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 Serv=
ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If =
you
are not the intended recipient, please contact the sender by reply e-mail a=
nd destroy all copies of the original message.


From syed.ali@neustar.biz  Tue Jun  1 13:10:04 2010
Return-Path: <syed.ali@neustar.biz>
X-Original-To: drinks@core3.amsl.com
Delivered-To: drinks@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D983A6855 for <drinks@core3.amsl.com>; Tue,  1 Jun 2010 13:10:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.944
X-Spam-Level: *
X-Spam-Status: No, score=1.944 tagged_above=-999 required=5 tests=[AWL=1.390,  BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V96yQgFJ8u8k for <drinks@core3.amsl.com>; Tue,  1 Jun 2010 13:10:01 -0700 (PDT)
Received: from neustar.com (keys.neustar.biz [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 2D5423A6886 for <drinks@ietf.org>; Tue,  1 Jun 2010 13:10:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1275422983; x=1590781880; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=+3p4IuxLdHJxTRaFbdbrW crZu2MphzJhY5wk+V37KNE=; b=AM96OqYUX1lWgySl7nfL7I/AeWXo+AMBCWEO6 6c60PfYyg7PurpWAsElTxu7lw0E0P/LfCT8pni+wfc98xYqpA==
Received: from ([10.31.13.50]) by stihiron1.va.neustar.com with ESMTP  id G6K7MJ1.9634645; Tue, 01 Jun 2010 16:09:42 -0400
Received: from STNTEXCHHT03.cis.neustar.com ([10.31.13.242]) by stntexch11.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 1 Jun 2010 16:09:35 -0400
Received: from STNTEXCH02.cis.neustar.com ([fe80::f828:7b2d:14aa:84b7]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 1 Jun 2010 16:10:04 -0400
From: "Ali, Syed Wasim" <syed.ali@neustar.biz>
To: "Cartwright, Ken" <kcartwright@tnsi.com>, Sumanth Channabasappa <sumanth@cablelabs.com>, David Schwartz <dschwartz@xconnect.net>, "Maharishi, Manjul" <mmaharishi@tnsi.com>, Jean-Francois Mule <jf.mule@cablelabs.com>, Alexander Mayrhofer <alexander.mayrhofer@nic.at>,  Hadriel Kaplan <HKaplan@acmepacket.com>, "drinks@ietf.org" <drinks@ietf.org>
Date: Tue, 1 Jun 2010 16:09:40 -0400
Thread-Topic: [drinks] protocol observations...
Thread-Index: AcruA2Riqb+RexL1R06SGhtB33meHwADHFtAAATD62MDlZ6zMgAn1NgAARMlz1oAC6RfIAAMoF8j
Message-ID: <C82AE144.3CE93%syed.ali@neustar.biz>
In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA2446E8D384@TNS-MAIL-NA.win2k.corp.tnsi.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA==
x-ems-stamp: SGvsVfvCXWj8lwTesLUkyQ==
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 01 Jun 2010 20:09:35.0266 (UTC) FILETIME=[5B090020:01CB01C6]
Subject: Re: [drinks] protocol observations...
X-BeenThere: drinks@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DRINKS WG <drinks.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/drinks>
List-Post: <mailto:drinks@ietf.org>
List-Help: <mailto:drinks-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Jun 2010 20:10:04 -0000

please see inline.

On 6/1/10 10:30 AM, "Cartwright, Ken" <kcartwright@tnsi.com> wrote:

> Hi Syed,
>
> 1) It would not be good, imo to move the PI to Dest Grp relationship insi=
de
> 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=3D"PubIdType" abstract=3D"true">
        <sequence>
            <element name=3D"base" type=3D"spppb:BasicObjType"/>
            <element name=3D"dgName" type=3D"string" minOccurs=3D"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 t=
hat
> 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 a=
s
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.  I=
t
> really only needs to apply to PIs.  So the authoritative/COR/Transit conc=
ept
> 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.

>
> 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.  :-)  Th=
e
> getter methods are intended to allow the SPPP client to get the propertie=
s 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 t=
he
> response", I don't really see it that way.  That is really a statement ab=
out
> 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 a=
nd
> read in order, so even without the transaction ID the client and server c=
an
> 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 si=
ngle
> TCP connection and then start reading the responses on that connection.  =
The
> client and server can still always correlate the request with the respons=
es
> 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
=3D=3D=3D=3D=3D=3D      =3D=3D=3D=3D=3D=3D      =3D=3D=3D=3D=3D=3D         =
   =3D=3D=3D             =3D=3D=3D
  |   REQ1    |             |               |             |
  |---------->|   REQ1      |               |             |
  |   REQ2    |------------>|               |             |
  |---------->|             |      REQ2     |             |
  |   REQ3    |---------------------------->|             |
  |---------->|             |               |    REQ3     |
  |           |------------------------------------------>|
  |   RESP2   |             |               |             |
  |<----------------------------------------|             |
  |   RESP1   |             |               |             |
  |<------------------------|               |             |
  |   RESP3   |             |               |             |
  |<------------------------------------------------------|

In the end, your point about not requiring a "clientTransId" for the getter=
s
in not without merit for other reasons. In fact, it is important to give th=
e
provisioning entities the needed flexibility to exercise their own judgment
whether a specific mention of "clientTransId" is needed to begin with, be i=
t
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 availabl=
e
for provisioning entities to use as an *optional* field to fit their own ec=
o
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.
>
> -----Original Message-----
> From: Ali, Syed Wasim [mailto:syed.ali@neustar.biz]
> Sent: Tuesday, June 01, 2010 4:35 AM
> To: Cartwright, Ken; Sumanth Channabasappa; David Schwartz; Maharishi, Ma=
njul;
> Jean-Francois Mule; Alexander Mayrhofer; Hadriel Kaplan; drinks@ietf.org
> Subject: Re: [drinks] protocol observations...
>
>
> Ken,
>
> Thanks for reviewing the changes and a detailed feedback. Please see inli=
ne.
>
> On 5/26/10 6:25 PM, "Cartwright, Ken" <kcartwright@tnsi.com> wrote:
>
>>
>> 1) Instead of the DestGroupType containing the identifiers of the routes=
 that
>> route to it, the RteGrpType should contain the identifiers of the destin=
ation
>> 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 publi=
c
> identifiers",
>
>     <complexType name=3D"DestGrpType">
>         <sequence>
>             <element name=3D"base" type=3D"spppb:BasicObjType"/>
>             <element name=3D"dgName" type=3D"string"/>
>             <element name=3D"rteGrpName" type=3D"string" minOccurs=3D"0"
> maxOccurs=3D"unbounded"/>
>         </sequence>
>     </complexType>
>
> Updated type definitions:
>
>     <complexType name=3D"DestGrpType">
>         <sequence>
>             <element name=3D"base" type=3D"spppb:BasicObjType"/>
>             <element name=3D"dgName" type=3D"string"/>
>             <element name=3D"pi" type=3D"spppb:" maxOccurs=3D"unbounded"/=
>
>         </sequence>
>     </complexType>
>     <complexType name=3D"RteGrpType">
>         <sequence>
>             <element name=3D"base" type=3D"spppb:BasicObjType"/>
>             <element name=3D"rteGrpName" type=3D"string"/>
>             <element name=3D"rteRec" type=3D"spppb:RteRecType" minOccurs=
=3D"0"
> maxOccurs=3D"unbounded"/>
>             <element name=3D"destGrp" type=3D"spppb:DestGrpType" minOccur=
s=3D"0"
> maxOccurs=3D"unbounded"/>
>             <element name=3D"peeringOrg" type=3D"spppb:OrgIdType" minOccu=
rs=3D"0"
> maxOccurs=3D"unbounded"/>
>             <element name=3D"sourceIdent" type=3D"spppb:SourceIdentType"
> minOccurs=3D"0"
>                 maxOccurs=3D"unbounded"/>
>             <element name=3D"isInSvc" type=3D"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/locate=
d
>> here
>> as an attribute of the object?
> If you are suggesting that we should consider making "ere" an element, th=
at
> 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" i=
t
>> 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 n=
ot
>> 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 informat=
ion
>> 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 ver=
sion
>> 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 t=
he
>> 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 h=
ave
>> the getter methods include/extend the BasicRqstType (which contains the
>> clientTransId).  For similar reason, it may not be good to have the gett=
er
>> 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 sequ=
ence
>> 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. A=
s 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 getter=
s
> 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 respon=
se
> to a getter ahead of an update which could have affected the answer of th=
e
> getter should be a concern. At the minimum, the SPPP client using the get=
ter
> 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 y=
our
> 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 th=
e
>> current XSD allows a client to pass in several update requests, comingle=
d
>> with
>> getter requests, in the spppRequest element?  I think we probably want t=
o
>> structurally disallow that.
> In its current form, unless I am mistaken, it enables the bulk provisioni=
ng
> use case. We can always limit the current spppRequest to a single
> BasicRqstType and introduce a separate spppBulkRequest methods that allow=
s
> one or more spppRequest requests. I am open to both approaches.
>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Ali, Syed Wasim [mailto:syed.ali@neustar.biz]
>> Sent: Tuesday, May 25, 2010 10:16 PM
>> To: Sumanth Channabasappa; Cartwright, Ken; David Schwartz; Maharishi,
>> Manjul;
>> Jean-Francois Mule; Alexander Mayrhofer; Hadriel Kaplan; drinks@ietf.org
>> 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 necessar=
y
>> changes and invite everyone to comment and provide the needed suggestion=
s.
>> 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 docum=
ent
>> (3-) Improvements in the schema that do not affect the XML output and th=
at
>> 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 change=
s 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 d=
raft
>> stage until such time that a consensus is reached in the usual fashion.
>>
>> - (1-) Line 15: "targetDomain" element is removed. In the last f2f inter=
im
>> 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 th=
e
>> public identifier has a restriction to include at least a "dgName" or NA=
PTR
>> 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" attribu=
te
>> 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 threa=
d.
>> - (1-) Line 143: There is no active use case for "effDate", hence remove=
d.
>> - (3-) Line 149: All request methods now extend BasicRqstType. This avoi=
ds
>> 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 wel=
l 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 ca=
se
>> "INTERCONNECT #2" per draft-ietf-drinks-usecases-requirements-03.txt. Th=
is
>> use case mentions two possible levels of authority: carrier-of-record an=
d
>> transit provider. With that mind, it appears that the "boolean" data typ=
e
>> satisfies the basic requirement to say that if an SSP proceeds to provis=
ion
>> the request as a carrier-of-record, then "authoritative=3Dtrue" attribut=
e
>> 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-rec=
ord,
>> then a unique error will be returned to the provisioning client. If
>> "authoritative=3Dfalse" is explicitly added to the SPPP request, the SPP=
P
>> 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 according=
ly.
>> - (3-) Line 160: All response methods now extend BasicRspnsType. This av=
oids
>> 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 t=
he
>> 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 i=
n
>> 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" <syed.ali@neustar.biz> wrote:
>>


From kcartwright@tnsi.com  Wed Jun  2 10:04:32 2010
Return-Path: <kcartwright@tnsi.com>
X-Original-To: drinks@core3.amsl.com
Delivered-To: drinks@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B695E28B797 for <drinks@core3.amsl.com>; Wed,  2 Jun 2010 10:04:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.667
X-Spam-Level: *
X-Spam-Status: No, score=1.667 tagged_above=-999 required=5 tests=[AWL=1.667,  BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9c2TFCIqhOh for <drinks@core3.amsl.com>; Wed,  2 Jun 2010 10:04:30 -0700 (PDT)
Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 73EFE3A6823 for <drinks@ietf.org>; Wed,  2 Jun 2010 10:04:30 -0700 (PDT)
Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.44207124; Wed, 02 Jun 2010 13:04:10 -0400
Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 2 Jun 2010 13:04:10 -0400
From: "Cartwright, Ken" <kcartwright@tnsi.com>
To: "Ali, Syed Wasim" <syed.ali@neustar.biz>, Sumanth Channabasappa <sumanth@cablelabs.com>, David Schwartz <dschwartz@xconnect.net>, "Maharishi, Manjul" <mmaharishi@tnsi.com>, Jean-Francois Mule <jf.mule@cablelabs.com>, Alexander Mayrhofer <alexander.mayrhofer@nic.at>,  Hadriel Kaplan <HKaplan@acmepacket.com>, "drinks@ietf.org" <drinks@ietf.org>
Date: Wed, 2 Jun 2010 13:04:09 -0400
Thread-Topic: [drinks] protocol observations...
Thread-Index: AcruA2Riqb+RexL1R06SGhtB33meHwADHFtAAATD62MDlZ6zMgAn1NgAARMlz1oAC6RfIAAMoF8jACdNghA=
Message-ID: <754963199212404AB8E9CFCA6C3D0CDA2446F4EF55@TNS-MAIL-NA.win2k.corp.tnsi.com>
References: <754963199212404AB8E9CFCA6C3D0CDA2446E8D384@TNS-MAIL-NA.win2k.corp.tnsi.com> <C82AE144.3CE93%syed.ali@neustar.biz>
In-Reply-To: <C82AE144.3CE93%syed.ali@neustar.biz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [drinks] protocol observations...
X-BeenThere: drinks@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DRINKS WG <drinks.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/drinks>
List-Post: <mailto:drinks@ietf.org>
List-Help: <mailto:drinks-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jun 2010 17:04:33 -0000

Hi Syed,

...because if you want to set up a Route Group to identify the points of in=
gress or other SED for multiple destination groups it requires that multipl=
e 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 modificati=
on.

...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 th=
at relationship over the dest group.

Ken

-----Original Message-----
From: Ali, Syed Wasim [mailto:syed.ali@neustar.biz]
Sent: Tuesday, June 01, 2010 4:10 PM
To: Cartwright, Ken; Sumanth Channabasappa; David Schwartz; Maharishi, Manj=
ul; Jean-Francois Mule; Alexander Mayrhofer; Hadriel Kaplan; drinks@ietf.or=
g
Subject: Re: [drinks] protocol observations...


please see inline.

On 6/1/10 10:30 AM, "Cartwright, Ken" <kcartwright@tnsi.com> wrote:

> Hi Syed,
>
> 1) It would not be good, imo to move the PI to Dest Grp relationship insi=
de
> 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=3D"PubIdType" abstract=3D"true">
        <sequence>
            <element name=3D"base" type=3D"spppb:BasicObjType"/>
            <element name=3D"dgName" type=3D"string" minOccurs=3D"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 t=
hat
> 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 a=
s
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.  I=
t
> really only needs to apply to PIs.  So the authoritative/COR/Transit conc=
ept
> 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.

>
> 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.  :-)  Th=
e
> getter methods are intended to allow the SPPP client to get the propertie=
s 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 t=
he
> response", I don't really see it that way.  That is really a statement ab=
out
> 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 a=
nd
> read in order, so even without the transaction ID the client and server c=
an
> 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 si=
ngle
> TCP connection and then start reading the responses on that connection.  =
The
> client and server can still always correlate the request with the respons=
es
> 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
=3D=3D=3D=3D=3D=3D      =3D=3D=3D=3D=3D=3D      =3D=3D=3D=3D=3D=3D         =
   =3D=3D=3D             =3D=3D=3D
  |   REQ1    |             |               |             |
  |---------->|   REQ1      |               |             |
  |   REQ2    |------------>|               |             |
  |---------->|             |      REQ2     |             |
  |   REQ3    |---------------------------->|             |
  |---------->|             |               |    REQ3     |
  |           |------------------------------------------>|
  |   RESP2   |             |               |             |
  |<----------------------------------------|             |
  |   RESP1   |             |               |             |
  |<------------------------|               |             |
  |   RESP3   |             |               |             |
  |<------------------------------------------------------|

In the end, your point about not requiring a "clientTransId" for the getter=
s
in not without merit for other reasons. In fact, it is important to give th=
e
provisioning entities the needed flexibility to exercise their own judgment
whether a specific mention of "clientTransId" is needed to begin with, be i=
t
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 availabl=
e
for provisioning entities to use as an *optional* field to fit their own ec=
o
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.
>
> -----Original Message-----
> From: Ali, Syed Wasim [mailto:syed.ali@neustar.biz]
> Sent: Tuesday, June 01, 2010 4:35 AM
> To: Cartwright, Ken; Sumanth Channabasappa; David Schwartz; Maharishi, Ma=
njul;
> Jean-Francois Mule; Alexander Mayrhofer; Hadriel Kaplan; drinks@ietf.org
> Subject: Re: [drinks] protocol observations...
>
>
> Ken,
>
> Thanks for reviewing the changes and a detailed feedback. Please see inli=
ne.
>
> On 5/26/10 6:25 PM, "Cartwright, Ken" <kcartwright@tnsi.com> wrote:
>
>>
>> 1) Instead of the DestGroupType containing the identifiers of the routes=
 that
>> route to it, the RteGrpType should contain the identifiers of the destin=
ation
>> 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 publi=
c
> identifiers",
>
>     <complexType name=3D"DestGrpType">
>         <sequence>
>             <element name=3D"base" type=3D"spppb:BasicObjType"/>
>             <element name=3D"dgName" type=3D"string"/>
>             <element name=3D"rteGrpName" type=3D"string" minOccurs=3D"0"
> maxOccurs=3D"unbounded"/>
>         </sequence>
>     </complexType>
>
> Updated type definitions:
>
>     <complexType name=3D"DestGrpType">
>         <sequence>
>             <element name=3D"base" type=3D"spppb:BasicObjType"/>
>             <element name=3D"dgName" type=3D"string"/>
>             <element name=3D"pi" type=3D"spppb:" maxOccurs=3D"unbounded"/=
>
>         </sequence>
>     </complexType>
>     <complexType name=3D"RteGrpType">
>         <sequence>
>             <element name=3D"base" type=3D"spppb:BasicObjType"/>
>             <element name=3D"rteGrpName" type=3D"string"/>
>             <element name=3D"rteRec" type=3D"spppb:RteRecType" minOccurs=
=3D"0"
> maxOccurs=3D"unbounded"/>
>             <element name=3D"destGrp" type=3D"spppb:DestGrpType" minOccur=
s=3D"0"
> maxOccurs=3D"unbounded"/>
>             <element name=3D"peeringOrg" type=3D"spppb:OrgIdType" minOccu=
rs=3D"0"
> maxOccurs=3D"unbounded"/>
>             <element name=3D"sourceIdent" type=3D"spppb:SourceIdentType"
> minOccurs=3D"0"
>                 maxOccurs=3D"unbounded"/>
>             <element name=3D"isInSvc" type=3D"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/locate=
d
>> here
>> as an attribute of the object?
> If you are suggesting that we should consider making "ere" an element, th=
at
> 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" i=
t
>> 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 n=
ot
>> 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 informat=
ion
>> 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 ver=
sion
>> 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 t=
he
>> 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 h=
ave
>> the getter methods include/extend the BasicRqstType (which contains the
>> clientTransId).  For similar reason, it may not be good to have the gett=
er
>> 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 sequ=
ence
>> 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. A=
s 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 getter=
s
> 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 respon=
se
> to a getter ahead of an update which could have affected the answer of th=
e
> getter should be a concern. At the minimum, the SPPP client using the get=
ter
> 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 y=
our
> 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 th=
e
>> current XSD allows a client to pass in several update requests, comingle=
d
>> with
>> getter requests, in the spppRequest element?  I think we probably want t=
o
>> structurally disallow that.
> In its current form, unless I am mistaken, it enables the bulk provisioni=
ng
> use case. We can always limit the current spppRequest to a single
> BasicRqstType and introduce a separate spppBulkRequest methods that allow=
s
> one or more spppRequest requests. I am open to both approaches.
>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Ali, Syed Wasim [mailto:syed.ali@neustar.biz]
>> Sent: Tuesday, May 25, 2010 10:16 PM
>> To: Sumanth Channabasappa; Cartwright, Ken; David Schwartz; Maharishi,
>> Manjul;
>> Jean-Francois Mule; Alexander Mayrhofer; Hadriel Kaplan; drinks@ietf.org
>> 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 necessar=
y
>> changes and invite everyone to comment and provide the needed suggestion=
s.
>> 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 docum=
ent
>> (3-) Improvements in the schema that do not affect the XML output and th=
at
>> 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 change=
s 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 d=
raft
>> stage until such time that a consensus is reached in the usual fashion.
>>
>> - (1-) Line 15: "targetDomain" element is removed. In the last f2f inter=
im
>> 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 th=
e
>> public identifier has a restriction to include at least a "dgName" or NA=
PTR
>> 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" attribu=
te
>> 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 threa=
d.
>> - (1-) Line 143: There is no active use case for "effDate", hence remove=
d.
>> - (3-) Line 149: All request methods now extend BasicRqstType. This avoi=
ds
>> 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 wel=
l 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 ca=
se
>> "INTERCONNECT #2" per draft-ietf-drinks-usecases-requirements-03.txt. Th=
is
>> use case mentions two possible levels of authority: carrier-of-record an=
d
>> transit provider. With that mind, it appears that the "boolean" data typ=
e
>> satisfies the basic requirement to say that if an SSP proceeds to provis=
ion
>> the request as a carrier-of-record, then "authoritative=3Dtrue" attribut=
e
>> 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-rec=
ord,
>> then a unique error will be returned to the provisioning client. If
>> "authoritative=3Dfalse" is explicitly added to the SPPP request, the SPP=
P
>> 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 according=
ly.
>> - (3-) Line 160: All response methods now extend BasicRspnsType. This av=
oids
>> 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 t=
he
>> 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 i=
n
>> 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" <syed.ali@neustar.biz> wrote:
>>


This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv=
ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If =
you
are not the intended recipient, please contact the sender by reply e-mail a=
nd destroy all copies of the original message.


From alexander.mayrhofer@nic.at  Thu Jun  3 06:54:04 2010
Return-Path: <alexander.mayrhofer@nic.at>
X-Original-To: drinks@core3.amsl.com
Delivered-To: drinks@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E5F63A67F0 for <drinks@core3.amsl.com>; Thu,  3 Jun 2010 06:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.47
X-Spam-Level: *
X-Spam-Status: No, score=1.47 tagged_above=-999 required=5 tests=[AWL=-0.300,  BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_66=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etQN7MisuEYY for <drinks@core3.amsl.com>; Thu,  3 Jun 2010 06:54:03 -0700 (PDT)
Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by core3.amsl.com (Postfix) with ESMTP id 3391B3A67B5 for <Drinks@ietf.org>; Thu,  3 Jun 2010 06:54:01 -0700 (PDT)
Received: from nics-mail.sbg.nic.at ([192.168.1.2]) by mail.sbg.nic.at with XWall v3.45 ; Thu, 3 Jun 2010 15:53:45 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB0324.2E9CF7EF"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 3 Jun 2010 15:53:46 +0200
Message-ID: <8BC845943058D844ABFC73D2220D466509289B8C@nics-mail.sbg.nic.at>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Meeting notes from the Interim Meeting on May 5th
Thread-Index: AcsDJC91t/jKAf2hSD6qLT3Q/cODxw==
From: "Alexander Mayrhofer" <alexander.mayrhofer@nic.at>
To: <Drinks@ietf.org>
X-XWALL-BCKS: auto
Subject: [drinks] Meeting notes from the Interim Meeting on May 5th
X-BeenThere: drinks@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DRINKS WG <drinks.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/drinks>
List-Post: <mailto:drinks@ietf.org>
List-Help: <mailto:drinks-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jun 2010 13:54:04 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB0324.2E9CF7EF
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I've aggregated all the notes that were sent to me into the following
Meeting minutes. If you have notes that you haven't sent to me yet,
please do so. The majority of the notes has been provided by Richard.

Please comment on the minutes if you feel something should be changed,
or if something is incorrect.

thanks,

Alex

------_=_NextPart_001_01CB0324.2E9CF7EF
Content-Type: text/plain;
	name="DRINKS-interim-minutes-77.5.txt"
Content-Transfer-Encoding: base64
Content-Description: DRINKS-interim-minutes-77.5.txt
Content-Disposition: attachment;
	filename="DRINKS-interim-minutes-77.5.txt"

RFJJTktTIFdHIEludGVyaW0gTWludXRlcyBmb3IgRFJJTktTIEludGVyaW0gTWVldGluZyAoNzcu
NSkNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09DQoNCg0KV0VETkVTREFZLCBNYXkgNSAyMDEwDQowOTAwLTU6MDAgIFROU0kgUmVzdG9u
IFZBDQpEYXRhIGZvciBSZWFjaGFiaWxpdHkgb2YgSW50ZXIvdHJhLU5ldHdvcksgU0lQIChkcmlu
a3MpDQoNCkNoYWlyczoNCiAgICAgUmljaGFyZCBTaG9ja2V5IDxyaWNoYXJkQHNob2NrZXkudXM+
DQogICAgIEFsZXhhbmRlciBNYXlyaG9mZXIgPGFsZXhhbmRlci5tYXlyaG9mZXJAZW51bS5hdD4N
Cg0KIFJlYWwtdGltZSBBcHBsaWNhdGlvbnMgYW5kIEluZnJhc3RydWN0dXJlIEFyZWEgRGlyZWN0
b3JzOg0KICAgICBHb256YWxvIENhbWFyaWxsbyA8Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24u
Y29tPg0KICAgICBSb2JlcnQgU3BhcmtzIDxyanNwYXJrc0Bub3N0cnVtLmNvbT4NCiAgICAgICAg
IA0KDQogTWFpbGluZyBMaXN0czoNCiAgICAgR2VuZXJhbCBEaXNjdXNzaW9uOiBkcmlua3NAaWV0
Zi5vcmcNCiAgICAgVG8gU3Vic2NyaWJlOiAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2RyaW5rcw0KICAgICBBcmNoaXZlOiAgICAgICAgICAgIGh0dHA6Ly93d3cu
aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kcmlua3MvY3VycmVudC9tYWlsbGlzdC5odG1sDQoN
ClRoZSBtZWV0aW5nIHdhcyBhbHNvIGF2YWlsYWJsZSBvdmVyIFdlYiBjb25mZXJlbmNpbmcuDQoN
CiJCbHVlIHNoZWV0cyINCi0tLS0tLS0tLS0tLS0NCg0KVGhlIGZvbGxvd2luZyBwYXJ0aWNpcGFu
dHMgYXR0ZW5kZWQgdGhlIG1lZXRpbmc6DQoNCkRhbiBSb21hbnNjYW51IA0KR29uemFsbG8gQ2Ft
YXJpbGxvDQpKZWFuIEZyYW7nb2lzIE11bGUNClN1bWFudGggQ2hhbm5hYmFzYXBwYQ0KUmljaGFy
ZCBTaG9ja2V5DQpBbGV4YW5kZXIgTWF5cmZob2Zlcg0KUGVubiBQZmF1dHoNCkhhZHJpZWwgS2Fw
bGFuDQpOaW5nID8NClN5ZWQgQWxpDQpNYW5qdWwgTWFoYXJpc2hpDQpLZW4gQ2FydHdyaWdodA0K
RGF2aWQgU2Nod2FydHoNCg0KQWdlbmRhIEJhc2hpbmcNCi0tLS0tLS0tLS0tLS0tDQoNClRoZSBB
Z2VuZGEgd2FzIHBvc3RlZCBvbiB0aGUgbWFpbGluZyBsaXN0IGFzIGZvbGxvd3M6DQpodHRwOi8v
d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZHJpbmtzL2N1cnJlbnQvbXNnMDA2NzMuaHRt
bA0KDQpLZW4gQ2FydGh3cmlnaHQgbm90ZWQgdGhhdCBtYXBwaW5nIHVzZSBjYXNlcyB0byB0aGUg
cHJvdG9jb2wgZG9jdW1lbnQgb25seSBtYWtlcyBzZW5zZSANCm9uY2UgdGhlIHVzZSBjYXNlcyBh
cmUgZnVsbHkgbWFwcGVkIG91dCAtIHRoaXMgaXMgbm90IHRoZSBjYXNlIHlldA0KDQpJRVRGIE5v
dGUgd2VsbA0KLS0tLS0tLS0tLS0tLS0NCg0KVGhpcyBpbnRlcmltIG1lZXRpbmcgaXMgc3ViamVj
dCB0byB0aGUgc2FtZSBJRVRGICJub3RlIHdlbGwiIHJ1bGVzIGFzICJub3JtYWwiIFdHIHNlc3Np
b25zLiANCklmIHlvdSBoYXZlbid0IHJlYWQgdGhlICJub3RlIHdlbGwiIHN0YXRlbWVudCwgcGxl
YXNlIGRvIHNvIG5vdy4NCg0KQWRtaW5pc3RyaXZpYQ0KLS0tLS0tLS0tLS0tLQ0KDQpSaWNoYXJk
IFNob2NrZXkgd2lsbCBkbyB0aGUgbWludXRlIHRha2luZywgb3RoZXJzIGFyZSB3ZWxjb21lIHRv
IGNyZWF0ZSBub3RlcyBhcyB3ZWxsLg0KDQoxLglEaXNjdXNzaW9uIERSSU5LUyBVc2UgQ2FzZXMg
YW5kIFByb3RvY29sIFJlcXVpcmVtZW50cw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1pZXRmLWRyaW5rcy11c2VjYXNlcy1yZXF1aXJlbWVudHMgDQoNClJldmlldyBv
ZiB0ZXJtaW5vbG9neSAuLg0KDQpCYXNpYyBxdWVzdGlvbjogU3RpY2sgd2l0aCBTcGVlcm1pbnQg
dGVybW9ubG9neT8gIGNvbmNsdXNpb246IGFsc28gVXNlIDUwNjcgdGVybWlub2xvZ3kgZnJvbQ0K
SW5mcmFzdHJ1Y3R1cmUgRU5VTSByZXF1aXJlbWVudHMsIGlmIG5lZWRlZC4gVGhlIGFtYmlndWl0
eSBvY3VycyB3aXRoIEUuMTY0IGJ1dCBub3QgZW1haWwgDQpzdHlsZSBhZGRyZXNzZXMuIEFkZCBh
IG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gNTA2Ny4NCk5lZWQgdG8gcmVmaW5pbmcgdGhlIHJlbGF0
aW9uc2hpcCBiZXR3ZWVuIFB1YmxpYyBJZGVudGlmaWVyIGFuZCBUTiBSTiBlbWFpbCBzdHlsZSBh
ZGRyZXNzZXMuICANCg0KMi4JRGlzY3Vzc2lvbiBvZiB1c2UgY2FzZXMuIA0KLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KUHJvdmlzaW9uaW5nIC4uIHRoZSBncm91cCBkaXNjdXNz
ZXMgYW5kIHJlZmluZXMgdGhlIGRlZmluaXRpb24gb2YgQnVsayBQcm92aXNpb25pbmcuDQpUaGVy
ZSBhcmUgc2V2ZXJhbCBkaXN0aW5jdCBkaW1lbnNpb25zLCBhbmQgdGhpcyBuZWVkcyBiZSBiZSBk
ZWZpbmVkLCBpbiBvcmRlciB0byBzZXBlcmF0ZSB0aGVtDQpwcm9wZXJseS4gDQoNClJlYWx0aW1l
IHZzIE5vbiBSZWFsIHRpbWU6IENoYW5nZSB0byBTeW5jaHJvbm91cyB2cyBBc3luY2hyb25vdXMs
IHdoaWNoIG1vcmUgZGVzY3JpYmVzIHRoZSANCmludGVudGlvbi4NCg0KV2hhdCBpcyBidWxrIHBy
b3Zpc2lvbmluZz8gIFJlZmlubWVudCBvZiBtdWx0aSByZXF1ZXN0IHByb3Zpc2lvbmluZyBpc3N1
ZXMgDQppcyB0aGlzIEF0b21pYyBvciBub3Q/IENvbmNsdXNpb246IEFsbCBidWxrIHRyYW5zYWN0
aW9ucyBtdXN0IHN1Y2NlZWQgb3IgYWxsIGZhaWwuIA0KDQpKZWFuIEZyYW7nb2lzIE11bGU6IElz
IHRoaXMgcmVsYXRlZCB0byBQaWdneWJhY2tpbmcgY29tbWFuZCBpbiBNR0NQPyAgDQoNClJldmll
dyBvZiBTRUQgRXhjaGFuZ2UgYW5kIERpc2NvdmVyeS4gSXMgdGhlIHVzZSBvZiBBZG1pbnN0cmF0
aXZlIERvbWFpbiBOYW1lIGFwcHJvcHJpYXRlPyANCg0KUmljaGFyZCBTaG9ja2V5OiBEbyBub3Qg
dXNlIGRvbWFpbiBuYW1lISANCkplYW4gRnJhbudvaXMgTXVsZTogIGNhbGwgaXQgIFNQLUlEIG9y
IFNQTiBvciBFbnRlcnByaXNlIE51bWJlcnMuICBEb250IHVzZSBOb3J0aCBBbWVyaWNhbiBzcGVj
aWZpYyAgdGVybWlub2xvZ3kuIA0KDQpQZW5uIFBmYXV0ejpEZWZpbmUgImFkbWluaXN0cmF0aXZl
IGRvbWFpbiBpZGVudGlmaWVyIiBhcyBTUE4NCg0KVGhlIGluZGl2aWR1YWwgdXNlIGNhc2VzIGFy
ZSBleHRlbnNpdmVseSBkaXNjdXNzZWQgZnVydGhlci4NCg0KVUMgU0VEIERhdGEgIzkgTmVlZCB0
byByZWZpbmUgIC4uLiAgTmVlZCB0byBkZWZpbmUgbXVsdGlwbGUgTFVGIGRlbGVnYXRlZCANCm5h
bWUgc2VydmVycyBmb3IgZGlmZmVyZW50IGRhdGEgdHlwZXMgc3VjaCBhcyBDTkFNPyAgTmVlZCBQ
b2luZXJzIHRvIGRpZmZlcmVudCByZWdpc3RyaWVzPyANCg0KS2VuICBDYXJ0aHdyaWdodDogRGVm
aW5lIGNvbnRlbnRzIG9mIFNFRCBkYXRhPyAgTW9yZSBzcGVjaWZpYyBkYXRhIGRlZmluaXRpb25z
IGFyZSANCm5lZWRlZC4gIFJlZmVyIHRvIFNwZWVybWludCB3aGVyZSBwb3NzaWJsZS4NCiAgDQpV
QyBBZG1pbiAjMS0yICBXaGF0IGlzIHRoZSBsZXZlbCBvZiBzcGVjaWZpY2l0eSByZXF1aXJlZCBp
biB0aGUgZG91bWVudD8gDQoNCkhhZHJpZWwgS2FwbGFuOiBJcyB0aGlzIHJlYWxseSBwYXJ0IG9m
IHRoZSByZXF1aXJlbWVudHM/DQpTdW1hdGg6IFRoZSBpc3N1ZSBpcyCEd2hhdCBpcyBhIGxvb2sg
dXAga2V5kyAgdGhpcyBzaG91bGQgYmUgaW4gdGhlIGRlZmluaXRpb25zLiANClN1bWF0aCA6IERl
Y2lzaW9uIHNob3VsZCBiZSB0byBjb25zb2xpZGF0ZSB0aGVzZSB1c2UgY2FzZXMgaW4gYSBzaW5n
bGUgdGVybSBhbmQgbW92ZSB0byB0ZXJtcy4NCg0KVUMgQWRtaW4gIzM6IFdoYXQgaXMgYWN0dWFs
bHkgaXMgdGhlIHVzZSBjYXNlIGhlcmU/ICANCg0KVUNOUCAjMiANCiANClJpY2hhcmQgU2hvY2tl
eTogIHdoYXQgaXMgZGVzY3JpYmVkIGhlcmUgaXMgYSBjb25kaXRpb25hbCBjaGFuZ2UgdG8gdGhl
IHJlZ2lzdHJ5IA0KdW50aWwgdGhlIGF1dGhvcmF0aXZlIG51bWJlcmluZyBkYXRhYmFzZSBjYW4g
Y29uZmlybSB0aGF0IHRoZSBjYXJyaWVyIG9mIHJlY29yZCBvZiBoYXMgY2hhbmdlZC4gDQoNClBy
b3RvY29sIERvY3VtZW50DQo9PT09PT09PT09PT09PT09PQ0KDQpodHRwOi8vdG9vbHMuaWV0Zi5v
cmcvaWQvZHJhZnQtbXVsZS1kcmlua3MtcHJvdG8tMDIudHh0DQoNCg0KRGlzY3Vzc2lvbiBzdGFy
dHMgYXQgMlBNOg0KDQpjaGFuZ2VzIGZyb20gU3llZCBkYXRlZCA0LzIvMjAxMCBvbiB0aGUgbGlz
dCBhcmUgYmVpbmcgZGlzY3Vzc2VkLiANCnJldmlzaW9ucyBvbiBhYnN0cmFjdGlvbiBvbiBsb29r
IHVwIHR5cGUgZnJvbSBwdWJsaWMgaXRlbml0eSB0byBUTiwgZW1haWwgdHlwZSBhbmQgUk4gLSBl
YWNoIGhhcw0KaXRzIG93biBkYXRhdHlwZS4NCg0KSGFkcmllbCBLYXBsYW46IEhvdyBkb2VzIHRo
ZSBwcm90b2NvbCBkZWFsIHdpdGggb3BlbiBkaWFsaW5nIHBsYW5zIGluIGV1cm9wZT8gIA0KTklO
RyA6IFdsaWRjYXJkaW5nIHRoZSBwcmVmaXg/DQoNClRoZXJlJ3MgYSBsb25nIGRpc2N1c3Npb24g
YWJvdXQgaW1wbGljYXRpb25zIG9mIG9wZW4gbnVtYmVyaW5nIHBsYW5zIC0gc2FtZSBpc3N1ZXMg
YXMgaW4gRU5VTT8/DQpTdW1tYXRoOiBIYWRyaWVsIHNob3VsZCBTdWJtaXQgYSB1c2UgY2FzZSBm
b3Igb3BlbiBudW1iZXJpbmcgcGxhbi4NCg0KSG93IGlzIHRoZSBTUElEIFNQTiB0byBiZSByZWZl
cmVuY2VkPyBUaGlzIHdhcyBhIHVucmVzb2x2ZWQgaXNzdWUgaW4gYW5haGVpbT8gDQpTaG91bGQg
c2VydmljZSBwcm92aWRlciBJRCBTUElEIHJlcXVpcmUgYSBVUk4/IFdoYXQgaXMgdGhlIG5hbWVz
cGFjZSBmb3IgdGhpcw0KUmVtaW5kZXI6IFRoZXJlJ3MgYW4gbGlhc2lvbiB3aXRoIElUVS1UIG9u
IFNQSUQgaXNzdWUuDQoNCkRvZXMgdGhlIElUVSBoYXZlIGEgVVJOID8NCkpGTTogICBXZSBuZWVk
IGEgc3BlYyB0aGF0IHdlIG5lZWQgZG9uZSBpbiAxMiBtb250aHMgLSBkb3VidCB0aGF0IHdlIGNh
biBnZXQgb3VyIG93biBuYW1lc3BhY2UgaW4gdGhhdCANCnRpbWUNCk9wdGlvbnM6IElUQUQgPyBJ
VFUgU1BOPyBJQU5BIEVudGVycHJpc2UgSUQgIE51bWJlcnM/IA0KUGVubiBQZmF1dHo6IE5vIG5l
dyBuYW1lc3BhY2UuIFRyeSB0byB1c2Ugd2hhdCBpcyBvdXQgdGhlcmUhDQpSaWNoIFMuIERvIHlv
dSBuZWVkIGEgd2hvaXMgZm9yIGFuIFNQTj8gDQoNCkFncmVlZCBhY3Rpb24gaXRlbXMuDQo9PT09
PT09PT09PT09PT09PT09PQ0KDQpBY3Rpb24gSXRlbXMgKGNvbGxlY3RlZCBieSBTdW1hbnRoKQ0K
DQoxLiBTdW1hbnRoIHRvIHVwZGF0ZSB0aGUgdXNlIGNhc2VzIEktRCBiYXNlZCBwcmltYXJpbHkg
b24gDQpyZWNvbW1lbmRhdGlvbnMgZnJvbSBLZW4gQU5EIHJlc3VsdHMgb2YgdGhlIGRpc2N1c3Np
b25zIHRvZGF5IA0KICAgLSBIYWRyaWVsIGFuZCBLZW4gdG8gcHJvdmlkZSB1cGRhdGVzDQogICAt
IFdlIHdpbGwgb2J0YWluIERhdmlkJ3MgZmVlZGJhY2sgYXQgYSBsYXRlciBkYXRlDQogDQoyLiBT
eWVkIHRvIHN0YXJ0IHRoZSBtYXBwaW5nIG9mIHVzZSBjYXNlcyB0byBwcm90b2NvbCAod2hhdCBp
cyBjb3ZlcmVkPyB3aGF0IGlzIG5vdD8pDQogICAtIEhlIHdpbGwgdXNlIHRoZSBjdXJyZW50IFdv
cmQgZG9jdW1lbnQgYXMgdGhlIGJhc2UuDQogDQozLiBKZWFuLUZyYW5jb2lzIHRvIGhhdmUgYSBj
YWxsIHdpdGggdGhlIGNvLWF1dGhvcnMgZm9yIGEgcHJvdG9jb2wgZG9jIHVwZGF0ZQ0KICAgLSBX
ZSB3aWxsIGhhdmUgYSBwaGFzZWQgYXBwcm9hY2ggZm9yIHRoZSB1cGRhdGVzIChiZXR3ZWVuIG5v
dyBhbmQgdGhlIG5leHQgSUVURikNCiANCjQuIEhvdyBkbyB3ZSByZXByZXNlbnQgdGhlIFNQSUQg
aXNzdWU/DQogICAtIERpc2N1c3MgdGhpcyBvbiB0aGUgbGlzdD8NCiANCjUuIElkZW50aWZ5IGV4
dGVybmFsIHJldmlld2VycyBmb3IgYWxsIHRoZSBkb2N1bWVudHMNCiAgIC0gQWxleCBhbmQgUmlj
aA0KDQpNZWV0aW5nIGNvbmNsdWRlcyBhcm91bmQgNDozMHBtDQoNCg==

------_=_NextPart_001_01CB0324.2E9CF7EF--

From kcartwright@tnsi.com  Mon Jun  7 14:09:43 2010
Return-Path: <kcartwright@tnsi.com>
X-Original-To: drinks@core3.amsl.com
Delivered-To: drinks@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 092143A6852 for <drinks@core3.amsl.com>; Mon,  7 Jun 2010 14:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmwlBK1YyWLA for <drinks@core3.amsl.com>; Mon,  7 Jun 2010 14:09:42 -0700 (PDT)
Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id BB6313A6834 for <drinks@ietf.org>; Mon,  7 Jun 2010 14:09:41 -0700 (PDT)
Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.44360183; Mon, 07 Jun 2010 17:09:37 -0400
Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 7 Jun 2010 17:09:38 -0400
From: "Cartwright, Ken" <kcartwright@tnsi.com>
To: Sumanth Channabasappa <sumanth@cablelabs.com>, DRINKS WG <drinks@ietf.org>
Date: Mon, 7 Jun 2010 17:09:36 -0400
Thread-Topic: Use Case: Selecting egress points
Thread-Index: Acr9xOokLsBLp7HHTaiH9Ig0PgtaWgIh62Uw
Message-ID: <754963199212404AB8E9CFCA6C3D0CDA2446FE203E@TNS-MAIL-NA.win2k.corp.tnsi.com>
References: <76AC5FEF83F1E64491446437EA81A61F7CF49FA725@srvxchg>
In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF49FA725@srvxchg>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [drinks] Use Case: Selecting egress points
X-BeenThere: drinks@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DRINKS WG <drinks.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/drinks>
List-Post: <mailto:drinks@ietf.org>
List-Help: <mailto:drinks-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jun 2010 21:09:43 -0000

With respect to my action item related to the inactive/active concept of a =
PI that we all agreed needed to be in the protocol...

I think the current use case UC LOOKUP #6 speaks to this concept under its =
portion "c)".  So I suggest that we change the last sentence of this use ca=
se to say... "The choice is dependent on the policies of the implementer of=
 the protocol".  The alternative of adding in another use case that specifi=
cally speaks to section "c)" is probably not a good idea.

Ken

-----Original Message-----
From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of=
 Sumanth Channabasappa
Sent: Thursday, May 27, 2010 1:49 PM
To: DRINKS WG
Subject: [drinks] Use Case: Selecting egress points

Folks,

Ken reminded me of a use case that inadvertently got dropped off in an earl=
ier revision of the use cases I-D. I am enclosing the use case here. Please=
 provide your comments. And if there are no objections, I will include it i=
n the next rev.

Thanks!
- S

Selecting egress points

An SSP has a peering relationship with a peer, and when sending messages to=
 that peer's point of interconnection, the originating SSP wishes to use on=
e or more points of egress.  These points of egress may vary for any given =
peer.  This capability is supported by allowing an originating SSP to provi=
sion SED for identities terminating to other SSPs where the originating SSP=
 is itself the data recipient.  The provisioning SSP may make use of multip=
le data recipient identities if it requires different sets of egress points=
 be used for calls originating from different parts of its network.  Routin=
g from egress points to ingress points of the terminating SSP may be accomp=
lished by static routing from the egress points or by the egress points usi=
ng data provisioned to the Registry by the terminating SSP.
_______________________________________________
drinks mailing list
drinks@ietf.org
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 Serv=
ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If =
you
are not the intended recipient, please contact the sender by reply e-mail a=
nd destroy all copies of the original message.


From kcartwright@tnsi.com  Wed Jun 16 06:30:01 2010
Return-Path: <kcartwright@tnsi.com>
X-Original-To: drinks@core3.amsl.com
Delivered-To: drinks@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437F33A6A30 for <drinks@core3.amsl.com>; Wed, 16 Jun 2010 06:30:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.301
X-Spam-Level: 
X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[AWL=-0.300,  BAYES_50=0.001, J_CHICKENPOX_42=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwPQhn6CwAxw for <drinks@core3.amsl.com>; Wed, 16 Jun 2010 06:29:59 -0700 (PDT)
Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 363333A67A7 for <drinks@ietf.org>; Wed, 16 Jun 2010 06:29:58 -0700 (PDT)
Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.44626628; Wed, 16 Jun 2010 09:30:00 -0400
Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 16 Jun 2010 09:30:01 -0400
From: "Cartwright, Ken" <kcartwright@tnsi.com>
To: "Drinks@ietf.org" <Drinks@ietf.org>
Date: Wed, 16 Jun 2010 09:29:59 -0400
Thread-Topic: Rough Notes and AI list from the call on 6/3
Thread-Index: AcqV2P0ww6+1MwG5SmORdQMbm0PpIgAADOsgAJ24mBAAPjHlYABqXOzQAoGpeVAAMX5+0AFfjqeAAWnibYABXbDPsAEnF0pwAC4eOEACY3K2IAAAy6SQC1rmhuABZNKi0AFhM5AAAV2RSGABkU7wAAD13PYQ
Message-ID: <754963199212404AB8E9CFCA6C3D0CDA24471A05A3@TNS-MAIL-NA.win2k.corp.tnsi.com>
References: <76AC5FEF83F1E64491446437EA81A61F7CD09B45C7@srvxchg.cablelabs.com> <76AC5FEF83F1E64491446437EA81A61F7CD4B2A944@srvxchg> <76AC5FEF83F1E64491446437EA81A61F7CD4B2ADC0@srvxchg> <76AC5FEF83F1E64491446437EA81A61F7CD4B2B20E@srvxchg> <76AC5FEF83F1E64491446437EA81A61F7CD4D31523@srvxchg> <76AC5FEF83F1E64491446437EA81A61F7CD4D31961@srvxchg> <76AC5FEF83F1E64491446437EA81A61F7CD4D31A4B@srvxchg> <76AC5FEF83F1E64491446437EA81A61F7CD4E30719@srvxchg> <76AC5FEF83F1E64491446437EA81A61F7CD4E3072A@srvxchg> <76AC5FEF83F1E64491446437EA81A61F7CD504EF05@srvxchg> <76AC5FEF83F1E64491446437EA81A61F7CF49FA1D4@srvxchg> <76AC5FEF83F1E64491446437EA81A61F7CF49FA726@srvxchg> <76AC5FEF83F1E64491446437EA81A61F7CF49FABFB@srvxchg> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [drinks] Rough Notes and AI list from the call on 6/3
X-BeenThere: drinks@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DRINKS WG <drinks.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/drinks>
List-Post: <mailto:drinks@ietf.org>
List-Help: <mailto:drinks-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Jun 2010 13:30:01 -0000

-----Original Message-----
From: Cartwright, Ken
Sent: Friday, June 11, 2010 12:11 PM
To: 'Sumanth Channabasappa'; Jean-Francois Mule; 'Alexander Mayrhofer'; Dav=
id Schwartz; Maharishi, Manjul; Syed Ali
Cc: drinks-chairs@tools.ietf.org
Subject: RE: Rough Notes and AI list from the call on 6/3

I've submitted the preliminary SPPP over SOAP and HTTP document (what we ca=
ll the "transport" document) as a WG doc.  Thanks Sumanth for the guidance.

http://www.ietf.org/staging/draft-ietf-drinks-sppp-over-soap-00.txt

Ken

-----Original Message-----
From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com]
Sent: Thursday, June 03, 2010 12:40 PM
To: Jean-Francois Mule; 'Alexander Mayrhofer'; David Schwartz; Cartwright, =
Ken; Maharishi, Manjul; Syed Ali
Cc: drinks-chairs@tools.ietf.org; Sumanth Channabasappa
Subject: Rough Notes and AI list from the call on 6/3

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IETF DRINKS REQS & PROTOCOL WEEKLY CALL
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
6/3/2010, 10:00a-11:00a (Eastern)/8:00a-9:00a (Mountain)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Participants (in order of announcement)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- Alex Mayrhofer, enum.at GmbH
- Ken Cartwright, TNSI, Inc.
- Jean-Francois Mule, CableLabs (until 8:15a)
- David Schwartz, XConnect
- Manjul Maharishi, TNSI, Inc.  (>8:10a)
- Syed Ali, Neustar (8:15a)


- Sumanth Channabasappa, CableLabs


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ACTION ITEMS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
[David]
- Speak to some of the players (Rich, Gonzalo) regarding the Global SPID

[David]
- Provide thoughts on how best to represent priority values.

[Syed]
- Volunteered to put together examples based on the use cases


[Syed, Sumanth]
- Work on updating the use cases mapping document to contain requirement nu=
mbers.

[Ken]
Issues of active/inactive status for public identities.

[All]
Resolve the SPID issue?


=3D=3D=3D=3D=3D=3D
AGENDA
=3D=3D=3D=3D=3D=3D
- Discuss timelines for I-D updates and reviewers
- Global SPID
- Changes to the protocol documents
- Additional use cases


=3D=3D=3D=3D=3D
NOTES
=3D=3D=3D=3D=3D

=3D Discuss timelines for I-D updates and reviewers
  a) Non-transport protocol (Syed, Jean-Francois, Ken):
        - publish a wg draft-00 document by COB, Friday June 11
        - publish a wg draft-01 document by COB, Friday June 25

  b) Transport protocol (Ken):
        - publish a wg draft-00 document by COB, Friday June 11
        - publish a wg draft-01 document early July


=3D Global SPID

  (David) Are we going to wait for this to be solved for us, or should we d=
o something?
  (Sumanth) Proposed the following:
      - Separate the protocol document from a direct dependency on the Glob=
al SPID resolution (e.g., leave it as a opaque string)
      - Work on a proposal independent of the transport protocol

      This will help us complete the current I-Ds on time, and not delaying=
 them unnecessarily

      - After some discussion (Alex, David) we agreed with this.
      - In addition, David volunteered to check with Gonzalo and Rich regar=
ding their thoughts on moving forward.

      -  (David) should we submit an -00 document?
      - Sumanth indicated that we should, if we have a proposal, unless the=
re are other efforts.

      -  (Ken) cautioned that we should be careful about what we speak abou=
t when we said G-SPID;
          we are talking about administrative domains, not a generic Global=
 SPID. We agreed.

      - (Ken) also reminded us that Rich took on ownership of this effort. =
David will check on this.

   Resolution: David to check on the best way forward.


=3D Changes to the protocol documents
  - (Sumanth) requested Syed and Ken to provide any main highlights based o=
n their discussions
    (see the DRINKS mailing list for details)

  - (Ken) indicated that David had suggestions around priority values. For =
instance, same number in multiple destination groups.
  > AI: David to provide his thoughts on the mailing list.

  - (Syed) Raised the question as to whether we need a mandatory client tra=
nsaction id? His proposal was to leave it optional on the client side, and =
conditional mandatory on the server side (i.e., if the client includes it i=
n the request, the server includes it in the response)?
  > Resolution: After some discussion, David and Ken agreed that we could l=
eave this optional.

  - (Syed) Should we use the terms COR and Transit, or Authoritative and no=
n-authoritative?
  > Resolution: COR and transit

  - (Syed) Should the designation of COR and transit be explicitly indicate=
d, or should there be a default - and where should this be reflected?
  > (Ken) recommended that this should be an attribute of the public identi=
fier
  > AI: we agreed with Ken's recommendation

  - (Syed) Should we allow multiple requests within one?
  > Yes.
  > (Ken) will this be atomic?


=3D Additional use cases

David proposed the following use cases via email on 5/27; this was discusse=
d earlier and David will follow-up.

1. Network management based load sharing/sequencing/failing: A network mana=
ger needs to assign priorities to routing elements within his/her network t=
o allow for proper network management. This could include things like shari=
ng or sequencing the load (load balancing) as well as providing for failure=
 cases (hot standby).

2. Policy based traffic shaping: Need the ability to assign priorities to d=
estination groups containing similar public identities. The priorities are =
needed for proper sequencing of the response set. Priority policy is out of=
 scope.





This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv=
ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If =
you
are not the intended recipient, please contact the sender by reply e-mail a=
nd destroy all copies of the original message.


From root@core3.amsl.com  Thu Jun 17 08:45:02 2010
Return-Path: <root@core3.amsl.com>
X-Original-To: drinks@ietf.org
Delivered-To: drinks@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 416113A68D4; Thu, 17 Jun 2010 08:45:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100617154502.416113A68D4@core3.amsl.com>
Date: Thu, 17 Jun 2010 08:45:02 -0700 (PDT)
Cc: drinks@ietf.org
Subject: [drinks] I-D Action:draft-ietf-drinks-sppp-over-soap-00.txt
X-BeenThere: drinks@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DRINKS WG <drinks.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/drinks>
List-Post: <mailto:drinks@ietf.org>
List-Help: <mailto:drinks-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jun 2010 15:45:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Data for Reachability of Inter/tra-NetworK SIP Working Group of the IETF.


	Title           : SPPP Over SOAP and HTTP
	Author(s)       : K. Cartwright
	Filename        : draft-ietf-drinks-sppp-over-soap-00.txt
	Pages           : 16
	Date            : 2010-06-11

The Session Peering Provisioning Protocol (SPPP) is an XML protocol
that exists to enable the provisioning of session establishment data
into Session Data Registries or SIP Service Provider data stores.
Sending XML data structures over Simple Object Access Protocol (SOAP)
and HTTP(s) is a widely used, de-facto standard for messaging between
elements of provisioning systems.  Therefore the combination of SOAP
and HTTP(s) as a transport for SPPP is a natural fit.  The obvious
benefits include leveraging existing industry expertise, leveraging
existing standards, and a higher probability that existing
provisioning systems can be more easily integrated with this
protocol.  This document describes the specification for transporting
SPPP XML structures over SOAP and HTTP(s).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-drinks-sppp-over-soap-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-drinks-sppp-over-soap-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-06-17083035.I-D@ietf.org>


--NextPart--

From alexander.mayrhofer@nic.at  Mon Jun 28 00:55:45 2010
Return-Path: <alexander.mayrhofer@nic.at>
X-Original-To: drinks@core3.amsl.com
Delivered-To: drinks@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5503A6990 for <drinks@core3.amsl.com>; Mon, 28 Jun 2010 00:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.595
X-Spam-Level: 
X-Spam-Status: No, score=0.595 tagged_above=-999 required=5 tests=[AWL=-0.575,  BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTnPdzDfAF6t for <drinks@core3.amsl.com>; Mon, 28 Jun 2010 00:55:45 -0700 (PDT)
Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by core3.amsl.com (Postfix) with ESMTP id 83A663A6820 for <Drinks@ietf.org>; Mon, 28 Jun 2010 00:55:40 -0700 (PDT)
Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel with XWall v3.45 ; Mon, 28 Jun 2010 09:55:47 +0200
Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.0.694.0; Mon, 28 Jun 2010 09:55:46 +0200
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 28 Jun 2010 09:55:41 +0200
Message-ID: <8BC845943058D844ABFC73D2220D4665092FDAFA@nics-mail.sbg.nic.at>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Call for Agenda items for IETF #78
Thread-Index: AcsWl05H/KfLC4aRQQykkfzxweDucg==
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
To: <Drinks@ietf.org>
X-XWALL-BCKS: auto
Subject: [drinks] Call for Agenda items for IETF #78
X-BeenThere: drinks@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DRINKS WG <drinks.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/drinks>
List-Post: <mailto:drinks@ietf.org>
List-Help: <mailto:drinks-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Jun 2010 07:55:45 -0000

We're preparing for the 78th IETF meeting, and would like to start
planning the session's agenda.

If you intend to present in Maastricht, please let the chairs know how
much time you require.

thanks,

Alex