From lendl@nic.at Thu Feb 10 02:28:00 2011 Return-Path: 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 8F2003A6947 for ; Thu, 10 Feb 2011 02:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] 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 4xJqKrTNBG4v for ; Thu, 10 Feb 2011 02:27:59 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id BCC113A6847 for ; Thu, 10 Feb 2011 02:27:58 -0800 (PST) Received: from [10.10.0.210] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id 22A274C7F9 for ; Thu, 10 Feb 2011 11:28:09 +0100 (CET) Message-ID: <4D53BDB9.1070001@nic.at> Date: Thu, 10 Feb 2011 11:28:09 +0100 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: drinks@ietf.org References: <76AC5FEF83F1E64491446437EA81A61F7D203155ED@srvxchg> <76AC5FEF83F1E64491446437EA81A61F7D20452EC0@srvxchg> <76AC5FEF83F1E64491446437EA81A61F7D20A09B51@srvxchg> <76AC5FEF83F1E64491446437EA81A61F7D20A09C76@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7D20A09C76@srvxchg> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [drinks] Rough Notes and AI list from the call on 1/27 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 10:28:00 -0000 On 27.01.2011 18:19, Sumanth Channabasappa wrote: > > - Syed provided a quick update on further changes. We had a discussion > around the text related to the expansion of the TN Range w.r.t. the open > numbering plan. Ken suggested alternative text. Further, Sumanth > recommended that 'range' may not make sense with an 'open numbering > plan'. That's one thing that I noticed, too: range and open numbering plans don't mix. The TNPType is sufficient. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From lendl@nic.at Thu Feb 10 03:52:16 2011 Return-Path: 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 AEC5E3A6980 for ; Thu, 10 Feb 2011 03:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] 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 cZ9+1971qRMw for ; Thu, 10 Feb 2011 03:52:15 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id CF2DE3A697A for ; Thu, 10 Feb 2011 03:52:13 -0800 (PST) Received: from [10.10.0.210] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id 07CB94C7FE for ; Thu, 10 Feb 2011 12:52:24 +0100 (CET) Message-ID: <4D53D179.8090901@nic.at> Date: Thu, 10 Feb 2011 12:52:25 +0100 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: drinks@ietf.org References: <76AC5FEF83F1E64491446437EA81A61F7D20315CFE@srvxchg> <4D01F363.5020804@nic.at> In-Reply-To: <4D01F363.5020804@nic.at> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [drinks] My review of SPPP-03, part 2 (was: Seeking volunteers for the protocol I-D) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 11:52:16 -0000 On 10.12.2010 10:31, Otmar Lendl wrote: > On 03.11.2010 00:36, Sumanth Channabasappa wrote: >> >> Given this, we would like to request expert reviewers who can help the WG make progress on this I-D. > > .... to be continued. I finally managed to read through the rest of the document. Here are my comments: Fist of all, the ordering in chapter 6 is messed up. > 6. Protocol Commands . . . . . . . . . . . . . . . . . . . . . . 27 > 6.1. Add Route Group Operation . . . . . . . . . . . . . . . . 27 > 6.2. Get Route Groups Operation . . . . . . . . . . . . . . . . 31 > 6.3. Add Destination Group Operation . . . . . . . . . . . . . 32 > 6.4. Get Destination Groups Operation . . . . . . . . . . . . . 33 > 6.5. Add Route Group Offer Operation . . . . . . . . . . . . . 34 > 6.6. Accept Route Group Offer Operation . . . . . . . . . . . . 36 > 6.7. Reject Route Group Offer Operation . . . . . . . . . . . . 37 > 6.8. Get Route Group Offers Operation . . . . . . . . . . . . . 38 > 6.9. Public Identifier Operations . . . . . . . . . . . . . . . 40 > 6.10. Egress Route Operations . . . . . . . . . . . . . . . . . 45 > 6.11. Add Route Record Operation . . . . . . . . . . . . . . . . 47 > 6.12. Get Route Records Operation . . . . . . . . . . . . . . . 52 > 6.13. Delete Operation . . . . . . . . . . . . . . . . . . . . . 53 I'd go for: > 6.13. Delete Operation . . . . . . . . . . . . . . . . . . . . . 53 > 6.3. Add Destination Group Operation . . . . . . . . . . . . . 32 > 6.4. Get Destination Groups Operation . . . . . . . . . . . . . 33 > 6.9. Public Identifier Operations . . . . . . . . . . . . . . . 40 > 6.11. Add Route Record Operation . . . . . . . . . . . . . . . . 47 > 6.12. Get Route Records Operation . . . . . . . . . . . . . . . 52 > 6.5. Add Route Group Offer Operation . . . . . . . . . . . . . 34 > 6.1. Add Route Group Operation . . . . . . . . . . . . . . . . 27 > 6.2. Get Route Groups Operation . . . . . . . . . . . . . . . . 31 > 6.6. Accept Route Group Offer Operation . . . . . . . . . . . . 36 > 6.7. Reject Route Group Offer Operation . . . . . . . . . . . . 37 > 6.8. Get Route Group Offers Operation . . . . . . . . . . . . . 38 > 6.10. Egress Route Operations . . . . . . . . . . . . . . . . . 45 (or the order used in the example section 7) Page 29: ---- o peeringOrg: Set of zero or more peering organization IDs that have accepted an offer to receive this Route Group's information. ---- Would there be a point in also offering the list of peering orgs that you have offered the route-group to? ---------- A more general question regarding all Add* requests: --- The AddDestGrpRqstType operation creates or overwrites a Destination Group object. If a Destination Group with the given name and registrant ID (which together comprise the unique key for a Destination Group) does not exist, then the server MUST create the Destination Group. --- What does SPPP say about the write permissions in the registry? The the EPP world, registrars can only modify/delete objects that they themselves have created. The only exception is the domain transfer operation. While the BasicObjType guarantees that the registry keeps track of who generated what, I'm a bit at loss on where that information is relevant. As I read the SPPP document, all registrars can enter data for all registrants. There is no protection against malicious registrars changing object submitted by another registrar. This, of course, makes the "registrant A is now handled by registrar B instead of C" operation unnecessary. The phrase "...querying registrar has the authority to view." shows up a few times, but I find nothing on visibility rules or permissions to change objects. Page 40 --- SPPP identifies three types of Public Identifiers: telephone number (TN), email address, and the routing number (RN). SPPP provides structures to manage a single TN, a contiguous range of TNs, and a TN prefix. --- Please get rid of "email address". Use SIP URIs as examples. Page 41 --- If there is a conflict and a Public Identifier already exists in the Registry, the old entry will be replaced with the newly provisioned entry. For the add or update operation, the destination group name is a mandatory parameter. Not including a valid destination group name in the update request will cause the Registry to return an appropriate error. --- This basically implies some sort of database integrity check (i.e. a foreign key) on Add. This is good. But: what about deletes? Can I remove an object that is referenced by some other object? What if the referencing object is owned by another registrar? Will the delete be rejected? Will the delete cascade? Will the system allow for inconsistencies in such a case? --- o corInfo: corInfo is an optional parameter of type CORInfoType that allows the registrant organization to set forth a claim to be the carrier-of-record [see RFC 5067]. --- Does SPPP allow for any filtering on received routes based on the CORInfo data? e.g.: "Please return only then Routes for a query if the TN is tagged as COR in the matching DestGrp." Page 43 --- o prefix: Optional attribute, when set to "true", indicates that the Open Number Plan applies to a given TN Range --- As mentioned before: Range and ONPs don't mix. See also http://www.ietf.org/mail-archive/web/drinks/current/msg00803.html Page 45 --- 6.10. Egress Route Operations --- WHY? I can't remember whether I wrote about this before, but there is absolutely no need to bother the registry with this. This is something you might tell your resolution service. Egress routes are only relevant to one registrant, so why put it in a shared database? Page 49 --- The NSType object is comprised of the data elements necessary for a Name Server that points to another DNS server that contains the desired routing information. --- I'm missing here two things: * It's completely unstated that one should use ENUM to query the nameservers returned here. Please make that explicit. * It might be helpful to also include the ENUM Apex to be used. "e164.arpa" is fine as the default, but why not add the option here to use something else? Page 51 --- --- Wouldn't that be cleaner as an attribute and not a element? i.e. instead of 1.2.3.4 IPv4<7type> use something like 1.2.3.4 Yes, this is purely cosmetic. --- The NSType object is composed of the following elements: o hostName: Fully qualified host name of the name server. o ipAddr: Zero or more objects of type IpAddrType. Each object holds an IP Address and the IP Address type, IPv4 or IP v6. --- I don't like this. Either you give just the FQDN and let the DNS resolve the rest, or just return the IP-Addresses. Doing both will lead to inconsistencies with the real world DNS, generating confusion and debugging hell. On a more general level regarding route entries, I'm still waiting for feedback on my proposal from http://www.ietf.org/mail-archive/web/drinks/current/msg00766.html . Page 62 junk 7.8 ------------- I hope this helps. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From sumanth@cablelabs.com Mon Feb 14 12:23:47 2011 Return-Path: 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 117FC3A6C75 for ; Mon, 14 Feb 2011 12:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 xQwBXlNsYjP0 for ; Mon, 14 Feb 2011 12:23:46 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 3712F3A6C51 for ; Mon, 14 Feb 2011 12:23:43 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id p1EKO4IT025457 for ; Mon, 14 Feb 2011 13:24:05 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 14 Feb 2011 13:24:05 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 14 Feb 2011 13:24:06 -0700 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Mon, 14 Feb 2011 13:24:03 -0700 Thread-Topic: Rough Notes and AI list from the call on 2/10 Thread-Index: AcvMhOrCsXIjKVZASnG61VARIHG3Pg== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D20AFF4AF@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 X-Approved: ondar Subject: [drinks] Rough Notes and AI list from the call on 2/10 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 20:23:47 -0000 FYI...there was no call on 2/3. IETF DRINKS DESIGN TEAM CALL=20 =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 2/10/2011, 10:00a-10:30a (Eastern)/8:00a-8:30a (Mountain) =20 Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Ken Cartwright - Syed Ali - Manjul Maharishi - Sumanth Channabasappa=20 =20 ACTION ITEMS=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [Ken, 2/15] Present an update t the I-D [Authors, 2/15] Review and respond to Otmar's comments AGENDA =3D=3D=3D=3D=3D=3D 0. Notes from last time 1. Status update from the authors (use cases, protocol I-Ds)=20 2. Agenda for the next IETF=20 3. Other topics (e.g., open source project) NOTES =3D=3D=3D=3D=3D 0. Notes from last time 1. Status update from the authors (use cases, protocol I-Ds)=20 2. Agenda for the next IETF=20 3. Other topics (e.g., open source project) 1. Status update from the authors (use cases, protocol I-Ds)=20 - Syed indicated that he is done with the changes he had proposed last week - Ken is going to update the I-D with a few more changes - Otmar send across a detailed set of comments (thanks); the authors plan t= o review and respond in the next few days. 2. TBD for the next IETF - We discussed the following tentative agenda =20 1/ WG status review (5 mts, WG chairs) =20 2/ Protocol document - status, open issues, discussion (45 mts, D= ocument Authors) Link : http://tools.ietf.org/wg/drinks/draft-ietf-drinks-= spprov/ 3/ Transport document - status, open issues, discussion (15 mts, = Document Authors) Link : http://tools.ietf.org/wg/drinks/draft-ietf-drinks-= sppp-over-soap/ 4/ Proposed Next steps (10 mts) 5/ Open Mic (10 mts) - If there are no further comments on the WG we will submit this as the ten= tative agenda From sumanth@cablelabs.com Mon Feb 14 14:16:01 2011 Return-Path: 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 A82BE3A6997 for ; Mon, 14 Feb 2011 14:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=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 bQyr-QHEpQsg for ; Mon, 14 Feb 2011 14:15:58 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id ED9553A6C31 for ; Mon, 14 Feb 2011 14:15:57 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id p1EMGKdO004564 for ; Mon, 14 Feb 2011 15:16:20 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 14 Feb 2011 15:16:20 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 14 Feb 2011 15:16:20 -0700 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Mon, 14 Feb 2011 15:16:18 -0700 Thread-Topic: Draft agenda for IETF#80 Thread-Index: AcvMlL9QrRXGAF/7QSq6MasgtBks6Q== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D20AFF4D0@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F7D20AFF4D0srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Draft agenda for IETF#80 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 22:16:01 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7D20AFF4D0srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, and comments are welcome... IETF 80 - Prague, Czech Republic DATE : TBD TIME : TBD PLACE: TBD Personnel =3D=3D=3D=3D=3D=3D=3D=3D=3D WG Chairs: - Alexander Mayrhofer > - Sumanth Channabasappa > Area Directors: - Gonzalo Camarillo > - Robert Sparks > Mailing List - Address: drinks@ietf.org - To Subscribe: https://www.ietf.org/mailman/listinfo/drinks - Archive: http://www.ietf.org/mail-archive/web/drinks/ Jabber Chat: - Room Address: xmpp:drinks@jabber.ietf.org - Logs: http://jabber.ietf.org/logs/drinks/ AGENDA =3D=3D=3D=3D=3D=3D 0/ Welcome and Administrivia (5 mts) - Note well - Blue Sheets - Scribes - Agenda bashing 1/ WG status review (5 mts, WG chairs) 2/ Protocol document - status, open issues, discussion (45 mts, D= ocument Authors) Link : http://tools.ietf.org/wg/drinks/draft-ietf-drinks-= spprov/ 3/ Transport document - status, open issues, discussion (15 mts, = Document Authors) Link : http://tools.ietf.org/wg/drinks/draft-ietf-drinks-= sppp-over-soap/ 4/ Proposed Next steps (10 mts) 5/ Open Mic (10 mts) --_000_76AC5FEF83F1E64491446437EA81A61F7D20AFF4D0srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI, and comm= ents are welcome…       

 

=  

 

  IETF 80 - Prague, Czech Republic

          <= o:p>

      &= nbsp;   DATE : TBD

&nb= sp;         TIME : TBD

        &= nbsp; PLACE: TBD

 

        &n= bsp; Personnel

   &nbs= p;      =3D=3D=3D=3D=3D=3D=3D=3D=3D

=

 

 =          WG Chairs:

<= p class=3DMsoPlainText>        &nbs= p; - Alexander Mayrhofer <= alexander.mayrhofer@nic.at>

&n= bsp;         - Sumanth Channabasapp= a <sumanth@cablelabs.com>= ;

 

          Area Direc= tors:       

          - Gonzal= o Camarillo <gonzalo.c= amarillo@ericsson.com>

 &= nbsp;        - Robert Sparks <rjsparks@nostrum.com>

        &n= bsp;         

<= p class=3DMsoPlainText>        &nbs= p; Mailing List

  &nbs= p;       - Address: drinks@ietf.org

 &= nbsp;        - To Subscribe: https://www.ietf.org/mailman/= listinfo/drinks

   = ;       - Archive: http://www.ietf.org/mail-archive/web/drinks/=

 

          Jabber = Chat:

     &= nbsp;    - Room Address: xmpp:drinks@jabber.ietf.org

       &n= bsp;  - Logs: http://j= abber.ietf.org/logs/drinks/

 = ;      

          AGENDA

       &= nbsp;  =3D=3D=3D=3D=3D=3D

&= nbsp;

      =     0/ Welcome and Administrivia (5 mts)

         &n= bsp;   - Note well

 &n= bsp;           - Blue She= ets

     &nb= sp;       - Scribes

          &n= bsp;  - Agenda bashing

       &n= bsp;  1/ WG status review (5 mts, WG chairs)

 

  = ;        2/ Protocol document - sta= tus, open issues, discussion (45 mts, Document Authors)

         &n= bsp;   Link      : http://tools.ietf.org/wg/d= rinks/draft-ietf-drinks-spprov/

<= o:p> 

     &= nbsp;    3/ Transport document - status, open issues, discus= sion (15 mts, Document Authors)

 = ;            Link&nb= sp;     : http://tools.ietf.org/wg/drinks/draft-ietf= -drinks-sppp-over-soap/

&nbs= p;

      &nb= sp;   4/ Proposed Next steps (10 mts)

 

   &= nbsp;      5/ Open Mic (10 mts)

 

 = ;

 

 

 

= --_000_76AC5FEF83F1E64491446437EA81A61F7D20AFF4D0srvxchg_-- From sumanth@cablelabs.com Thu Feb 17 08:40:42 2011 Return-Path: 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 809CE3A6AFD for ; Thu, 17 Feb 2011 08:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 lEGb7gN-Fxb4 for ; Thu, 17 Feb 2011 08:40:41 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 95FC23A6AB2 for ; Thu, 17 Feb 2011 08:40:41 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id p1HGfBF6004631 for ; Thu, 17 Feb 2011 09:41:11 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 17 Feb 2011 09:41:11 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 17 Feb 2011 09:41:12 -0700 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Thu, 17 Feb 2011 09:41:10 -0700 Thread-Topic: Rough Notes and AI list from the call on 2/17 Thread-Index: AcvOwXUR1TTVry5/RpurZ9VChz+7Qw== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D2DDCE579@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 X-Approved: ondar Subject: [drinks] Rough Notes and AI list from the call on 2/17 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 16:40:42 -0000 IETF DRINKS DESIGN TEAM CALL=20 =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 2/17/2011, 10:00a-10:30a (Eastern)/8:00a-8:30a (Mountain) =20 Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Ken Cartwright - Manjul Maharishi - Sumanth Channabasappa=20 ACTION ITEMS=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [Authors, 2/19] Submit the current revision of the I-Ds AGENDA =3D=3D=3D=3D=3D=3D 0. Notes from last time 1. Status update from the authors (use cases, protocol I-Ds)=20 2. Agenda for the next IETF=20 3. Other topics (e.g., open source project) NOTES =3D=3D=3D=3D=3D 0. Notes from last time - We did not these notes 1. Status update from the authors (use cases, protocol I-Ds)=20 - Syed and Ken have an updated I-D; however this does not address Otmar's r= ecent comments - Sumanth suggested that we submit this version, and follow-up with Otmar's= comments -- participants agreed - Sumanth also requested the authors - who have been busy with other commit= ments - to address open comments (i.e., Otmar's email) as soon as possible 2. Agenda for the next IETF=20 - Sumanth has sent across a tentative agenda last week - The participants are fine with this 3. Other topics - None From sumanth@cablelabs.com Thu Feb 17 09:12:09 2011 Return-Path: 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 8E1EF3A6CEA for ; Thu, 17 Feb 2011 09:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 VcLAhCZnphIS for ; Thu, 17 Feb 2011 09:12:07 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id AFF323A6CB8 for ; Thu, 17 Feb 2011 09:12:07 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id p1HHCbor008092; Thu, 17 Feb 2011 10:12:37 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 17 Feb 2011 10:12:37 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 17 Feb 2011 10:12:38 -0700 From: Sumanth Channabasappa To: Otmar Lendl , "drinks@ietf.org" Date: Thu, 17 Feb 2011 10:12:37 -0700 Thread-Topic: [drinks] My review of SPPP-03, part 2 (was: Seeking volunteers for the protocol I-D) Thread-Index: AcvJGQGD96B/UnsMSemVhZSGaETb8wFqIC5w Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D2DDCE58A@srvxchg> References: <76AC5FEF83F1E64491446437EA81A61F7D20315CFE@srvxchg> <4D01F363.5020804@nic.at> <4D53D179.8090901@nic.at> In-Reply-To: <4D53D179.8090901@nic.at> 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 X-Approved: ondar Subject: Re: [drinks] My review of SPPP-03, part 2 (was: Seeking volunteers for the protocol I-D) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 17:12:09 -0000 Thanks, Otmar. While the authors have been preoccupied, they hope to review= and respond over the next few days. They did indicate that their current I= -D updates (that they plan to submit) do not address your comments.=20 - S -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Otmar Lendl Sent: Thursday, February 10, 2011 4:52 AM To: drinks@ietf.org Subject: [drinks] My review of SPPP-03, part 2 (was: Seeking volunteers for= the protocol I-D) On 10.12.2010 10:31, Otmar Lendl wrote: > On 03.11.2010 00:36, Sumanth Channabasappa wrote: >> >> Given this, we would like to request expert reviewers who can help the W= G make progress on this I-D.=20 >=20 > .... to be continued. I finally managed to read through the rest of the document. Here are my comments: Fist of all, the ordering in chapter 6 is messed up. > 6. Protocol Commands . . . . . . . . . . . . . . . . . . . . . . 27 > 6.1. Add Route Group Operation . . . . . . . . . . . . . . . . 27 > 6.2. Get Route Groups Operation . . . . . . . . . . . . . . . . 31 > 6.3. Add Destination Group Operation . . . . . . . . . . . . . 32 > 6.4. Get Destination Groups Operation . . . . . . . . . . . . . 33 > 6.5. Add Route Group Offer Operation . . . . . . . . . . . . . 34 > 6.6. Accept Route Group Offer Operation . . . . . . . . . . . . 36 > 6.7. Reject Route Group Offer Operation . . . . . . . . . . . . 37 > 6.8. Get Route Group Offers Operation . . . . . . . . . . . . . 38 > 6.9. Public Identifier Operations . . . . . . . . . . . . . . . 40 > 6.10. Egress Route Operations . . . . . . . . . . . . . . . . . 45 > 6.11. Add Route Record Operation . . . . . . . . . . . . . . . . 47 > 6.12. Get Route Records Operation . . . . . . . . . . . . . . . 52 > 6.13. Delete Operation . . . . . . . . . . . . . . . . . . . . .=20 > 53 I'd go for: > 6.13. Delete Operation . . . . . . . . . . . . . . . . . . . . . 53 > 6.3. Add Destination Group Operation . . . . . . . . . . . . . 32 > 6.4. Get Destination Groups Operation . . . . . . . . . . . . . 33 > 6.9. Public Identifier Operations . . . . . . . . . . . . . . . 40 > 6.11. Add Route Record Operation . . . . . . . . . . . . . . . . 47 > 6.12. Get Route Records Operation . . . . . . . . . . . . . . . 52 > 6.5. Add Route Group Offer Operation . . . . . . . . . . . . . 34 > 6.1. Add Route Group Operation . . . . . . . . . . . . . . . . 27 > 6.2. Get Route Groups Operation . . . . . . . . . . . . . . . . 31 > 6.6. Accept Route Group Offer Operation . . . . . . . . . . . . 36 > 6.7. Reject Route Group Offer Operation . . . . . . . . . . . . 37 > 6.8. Get Route Group Offers Operation . . . . . . . . . . . . . 38 > 6.10. Egress Route Operations . . . . . . . . . . . . . . . . .=20 > 45 (or the order used in the example section 7) Page 29: ---- o peeringOrg: Set of zero or more peering organization IDs that have accepted an offer to receive this Route Group's information. ---- Would there be a point in also offering the list of peering orgs that you h= ave offered the route-group to? ---------- A more general question regarding all Add* requests: --- The AddDestGrpRqstType operation creates or overwrites a Destination Group object. If a Destination Group with the given name and registrant ID (which together comprise the unique key for a Destination Group) does not exist, then the server MUST create the Destination Group. --- What does SPPP say about the write permissions in the registry? The the EPP= world, registrars can only modify/delete objects that they themselves have= created. The only exception is the domain transfer operation. While the BasicObjType guarantees that the registry keeps track of who gene= rated what, I'm a bit at loss on where that information is relevant. As I read the SPPP document, all registrars can enter data for all registra= nts. There is no protection against malicious registrars changing object su= bmitted by another registrar. This, of course, makes the "registrant A is n= ow handled by registrar B instead of C" operation unnecessary. The phrase "...querying registrar has the authority to view." shows up a fe= w times, but I find nothing on visibility rules or permissions to change ob= jects. Page 40 --- SPPP identifies three types of Public Identifiers: telephone number (TN), email address, and the routing number (RN). SPPP provides structures to manage a single TN, a contiguous range of TNs, and a TN prefix. --- Please get rid of "email address". Use SIP URIs as examples. Page 41 --- If there is a conflict and a Public Identifier already exists in the Registry, the old entry will be replaced with the newly provisioned entry. For the add or update operation, the destination group name is a mandatory parameter. Not including a valid destination group name in the update request will cause the Registry to return an appropriate error. --- This basically implies some sort of database integrity check (i.e. a foreig= n key) on Add. This is good. But: what about deletes? Can I remove an object that is referenced by some = other object? What if the referencing object is owned by another registrar? Will the delete be rejected? Will the delete cascade? Will the system allow for inconsistencies in such a case? --- o corInfo: corInfo is an optional parameter of type CORInfoType that allows the registrant organization to set forth a claim to be the carrier-of-record [see RFC 5067]. --- Does SPPP allow for any filtering on received routes based on the CORInfo d= ata? e.g.: "Please return only then Routes for a query if the TN is tagged = as COR in the matching DestGrp." Page 43 --- o prefix: Optional attribute, when set to "true", indicates that the Open Number Plan applies to a given TN Range --- As mentioned before: Range and ONPs don't mix. See also http://www.ietf.org/mail-archive/web/drinks/current/msg00803.html Page 45 --- 6.10. Egress Route Operations --- WHY? I can't remember whether I wrote about this before, but there is absolutely= no need to bother the registry with this. This is something you might tell your resolution service. Egress routes are= only relevant to one registrant, so why put it in a shared database? Page 49 --- The NSType object is comprised of the data elements necessary for a Name Server that points to another DNS server that contains the desired routing information. --- I'm missing here two things: * It's completely unstated that one should use ENUM to query the nameserver= s returned here. Please make that explicit. * It might be helpful to also include the ENUM Apex to be used. "e164.arpa" is fine as the default, but why not add the option here to use something el= se? Page 51 --- --- Wouldn't that be cleaner as an attribute and not a element? i.e. instead of 1.2.3.4 IPv4<7type> use something like 1.2.3.4 Yes, this is purely cosmetic. --- The NSType object is composed of the following elements: o hostName: Fully qualified host name of the name server. o ipAddr: Zero or more objects of type IpAddrType. Each object holds an IP Address and the IP Address type, IPv4 or IP v6. --- I don't like this. Either you give just the FQDN and let the DNS resolve th= e rest, or just return the IP-Addresses. Doing both will lead to inconsiste= ncies with the real world DNS, generating confusion and debugging hell. On a more general level regarding route entries, I'm still waiting for feed= back on my proposal from http://www.ietf.org/mail-archive/web/drinks/curren= t/msg00766.html . Page 62 junk 7.8 ------------- I hope this helps. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // _________= ______________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From Internet-Drafts@ietf.org Fri Feb 18 06:30:03 2011 Return-Path: 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 BB8B53A6CAC; Fri, 18 Feb 2011 06:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 1cz9hzGd86eU; Fri, 18 Feb 2011 06:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0BC93A6CCE; Fri, 18 Feb 2011 06:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110218143001.32405.46807.idtracker@localhost> Date: Fri, 18 Feb 2011 06:30:01 -0800 Cc: drinks@ietf.org Subject: [drinks] I-D Action:draft-ietf-drinks-spprov-04.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 14:30:03 -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 : Session Peering Provisioning Protocol Author(s) : J. Mule, et al. Filename : draft-ietf-drinks-spprov-04.txt Pages : 97 Date : 2011-02-18 This document defines a protocol for provisioning session establishment data into Session Data Registries and SIP Service Provider data stores. The provisioned data is typically used by various network elements for session peering. This document describes the Session Peering Provisioning Protocol used by clients to provision registries. The document provides a set of guiding principles for the design of this protocol including extensibility and independent transport definitions, a basic data model and an XML Schema Document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drinks-spprov-04.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-spprov-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-18062603.I-D@ietf.org> --NextPart-- From kcartwright@tnsi.com Fri Feb 18 06:30:27 2011 Return-Path: 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 3B0BD3A6CCE for ; Fri, 18 Feb 2011 06:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 keviBK4TIQZA for ; Fri, 18 Feb 2011 06:30:26 -0800 (PST) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 0E7893A6F8A for ; Fri, 18 Feb 2011 06:30:24 -0800 (PST) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.51813306; Fri, 18 Feb 2011 09:30:57 -0500 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 18 Feb 2011 09:30:57 -0500 From: "Cartwright, Ken" To: "Drinks@ietf.org" Date: Fri, 18 Feb 2011 09:30:56 -0500 Thread-Topic: New Version Notification for draft-ietf-drinks-spprov-04 Thread-Index: AcvPd916ZdQ8oT7dQP2pkYuNXow9GAAAI3nA Message-ID: <754963199212404AB8E9CFCA6C3D0CDA2D97860124@TNS-MAIL-NA.win2k.corp.tnsi.com> 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: [drinks] FW: New Version Notification for draft-ietf-drinks-spprov-04 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 14:30:27 -0000 fyi -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Friday, February 18, 2011 9:26 AM To: Cartwright, Ken Cc: jfm@cablelabs.com; syed.ali@neustar.biz; alexander.mayrhofer@enum.at Subject: New Version Notification for draft-ietf-drinks-spprov-04 A new version of I-D, draft-ietf-drinks-spprov-04.txt has been successfully= submitted by Kenneth Cartwright and posted to the IETF repository. Filename: draft-ietf-drinks-spprov Revision: 04 Title: Session Peering Provisioning Protocol Creation_date: 2011-02-17 WG ID: drinks Number_of_pages: 97 Abstract: This document defines a protocol for provisioning session establishment data into Session Data Registries and SIP Service Provider data stores. The provisioned data is typically used by various network elements for session peering. This document describes the Session Peering Provisioning Protocol used by clients to provision registries. The document provides a set of guiding principles for the design of this protocol including extensibility and independent transport definitions, a basic data model and an XML Schema Document. The IETF Secretariat. 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 Fri Feb 18 06:32:38 2011 Return-Path: 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 78DC43A6CCE for ; Fri, 18 Feb 2011 06:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 2hDPVFLImzrF for ; Fri, 18 Feb 2011 06:32:37 -0800 (PST) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 6E4093A6CAC for ; Fri, 18 Feb 2011 06:32:37 -0800 (PST) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.51813381; Fri, 18 Feb 2011 09:33:06 -0500 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 18 Feb 2011 09:33:06 -0500 From: "Cartwright, Ken" To: "Drinks@ietf.org" Date: Fri, 18 Feb 2011 09:33:05 -0500 Thread-Topic: New Version Notification for draft-ietf-drinks-sppp-over-soap-02 Thread-Index: AcvPeHlln1ensS50RVenhqxdrunziQAAEH3w Message-ID: <754963199212404AB8E9CFCA6C3D0CDA2D97860128@TNS-MAIL-NA.win2k.corp.tnsi.com> 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: [drinks] FW: New Version Notification for draft-ietf-drinks-sppp-over-soap-02 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 14:32:38 -0000 fyi -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Friday, February 18, 2011 9:30 AM To: Cartwright, Ken Subject: New Version Notification for draft-ietf-drinks-sppp-over-soap-02 A new version of I-D, draft-ietf-drinks-sppp-over-soap-02.txt has been succ= essfully submitted by Kenneth Cartwright and posted to the IETF repository. Filename: draft-ietf-drinks-sppp-over-soap Revision: 02 Title: SPPP Over SOAP and HTTP Creation_date: 2011-02-17 WG ID: drinks Number_of_pages: 17 Abstract: 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). The IETF Secretariat. 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 Internet-Drafts@ietf.org Fri Feb 18 06:45:02 2011 Return-Path: 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 8E7B03A6F9B; Fri, 18 Feb 2011 06:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 o86yaBuOkRyB; Fri, 18 Feb 2011 06:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1FF03A6DC6; Fri, 18 Feb 2011 06:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110218144501.4082.97989.idtracker@localhost> Date: Fri, 18 Feb 2011 06:45:01 -0800 Cc: drinks@ietf.org Subject: [drinks] I-D Action:draft-ietf-drinks-sppp-over-soap-02.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 14: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-02.txt Pages : 17 Date : 2011-02-18 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-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-18063027.I-D@ietf.org> --NextPart--