From alexander.mayrhofer@nic.at Thu Jul 5 05:37:08 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50D321F865D for ; Thu, 5 Jul 2012 05:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.43 X-Spam-Level: X-Spam-Status: No, score=-9.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUOOs12DgiXD for ; Thu, 5 Jul 2012 05:37:08 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 546E421F8685 for ; Thu, 5 Jul 2012 05:37:06 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Thu, 5 Jul 2012 14:37:18 +0200 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Thu, 5 Jul 2012 14:37:12 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: DRINKS design team call DRAFT minutes from Jun 28 2012 Thread-Index: Ac1aqscBN+bZg0R3Sa2MJ4Z8thlLtA== Date: Thu, 5 Jul 2012 12:37:12 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750967358A@NICS-EXCH.sbg.nic.at> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.133] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: [drinks] DRINKS design team call DRAFT minutes from Jun 28 2012 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 12:37:08 -0000 Please find the minutes from last week's call below. Apologies because of t= he delay. DRINKS design team call DRAFT minutes ---------------------------------------- Jun 28 2012, 10am - 11am esatern Participants ------------ - Sumanth=20 - Dean=20 - Manjul - Alex - Vikas - Syed ACTION ITEMS ------------ 1/ Provide feedback about David's changes to the documents (All) 2/ Provide DoS text proposal (Dean) 3/ Incorporate amendments to proposed text (Alex) Agenda ------ 1/ Continue discussion of document updates Minutes ------- Sumanth opens the meeting. Lists open issues. Alex describes his mail to the design team, and discusses the two proposals in order to fix Vikas' comments about the original proposals. Vikas is=20 fine with both proposals - Action item is closed. Alex notes that document deadline for updated drafts is jul 16th.=20 sumanth says we want to be done with editing one week before, which would hence be jul 9th. Vikas has read through David's changes, has some feedback=20 and will provide them in an email to the list. Sumanth says we should all provide feedback about these changes this week.= =20 Documents would be WGLCed once published with the agreed changes. Meeting concludes, next call on Thu Jul 05. From dean.willis@softarmor.com Thu Jul 5 07:24:56 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C009121F8690 for ; Thu, 5 Jul 2012 07:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9gNBfLX0U2L for ; Thu, 5 Jul 2012 07:24:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD0021F85F4 for ; Thu, 5 Jul 2012 07:24:55 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so15164302obb.31 for ; Thu, 05 Jul 2012 07:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; bh=z5Px3pMdBy7MwjJbVNyXgfi5E9ow03AOqRwwaq/jp/s=; b=U/6VjinlrGrYoIWT0BihyMUXdxkCzbkV0NpgQ2OZ2BKd01o9YhRQoPFjbUax0+jaBf lKDYmSIft7igL79ktCy7nft2NMaWykr33oGGfZDsQS9tVgac7Sn1pVTW4ttJ167fANw7 61dH6fUQImzHgx/ah98Ob8hOIBqFw8OGSFCLc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer :x-gm-message-state; bh=z5Px3pMdBy7MwjJbVNyXgfi5E9ow03AOqRwwaq/jp/s=; b=cWG8/OGs8CJHIYEUiRbtd5gxz7LoMuOGtSk70dd8MSD10HX9HEcGRxZ2BW3I76cTtg LGxxRvLTXKgdZMiyeIasHhO6pp1B1mPArfivrTna3WIAqmckrvX6snydBEMWuONuZdBu 3SetETAuGGrnGKgKxc4f+Ikxs6UN6I0U2mEBPJNF6U6HQdK5kaW71XAQv/f5yyTnspDG y6k6jQvJb+lfuh6I47TMX/QDQm7CbhnvmxnlHnRz4H/LmtrTOY5reoKCfFURMbuxhmiO HWSt/OhXH0ram3FXP8fErQ7dSFtkHMhAJsyqQ/BstgqD9jmACc90wJHPHET3zV3kPwvj aztw== Received: by 10.182.52.38 with SMTP id q6mr21334443obo.8.1341498308886; Thu, 05 Jul 2012 07:25:08 -0700 (PDT) Received: from [192.168.2.119] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id g1sm14818404oei.4.2012.07.05.07.25.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jul 2012 07:25:08 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <2043209D-2A7F-4CB5-A980-DB8A142EC48F@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Date: Thu, 5 Jul 2012 09:25:05 -0500 To: "Cartwright, Ken" X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnO+n/m9BLLri4zi8HokdmXKq8caSmZzA88OOOmydg1oyiBJNioGCnAa0INhe0bhBnJLx+i Cc: "drinks@ietf.org" Subject: Re: [drinks] Proposed text for Security Considerations/DOS X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 14:24:56 -0000 On Jun 28, 2012, at 10:27 AM, Cartwright, Ken wrote: >=20 >=20 > SPPP allows a client to submit multiple-element or "batch" requests = that may insert or otherwise affect a large amount of data with a single = request. In the simplest case, the server progresses sequentially = through each element in a batch, completing one and before starting the = next. However, implementations may re-order request elements, = parallelize them, distribute them to subprocesses, or perform other = optimizations. >=20 > KJC: While it is theoretically possible under some circumstances, = suggesting that implementations can/may "re-order request elements" = might be a pandora's box that we should not open. Re-ordering of request = elements in a batch request is not the intended approach, and I think = that in-order processing is discussed/mentioned in the doc. So you = might want to consider removing the above sentence. Right, the SOAP doc 6.2.1.1 Add Request text states "The elements are = processed by the SPPF server in the order in which they are included in = the request." However, the FRAMEWORK document doesn't seem to indicate. = Could different biding have different order-execution properties? If not = we may want to mandate sequential execution in the framework. Question: How does a SOAP-binding client know whether a batch rolled = back or committed-prior-to-error? Which result code is sent in each = case? Does this require a-priori knowledge about the the server? It seems like we're currently set up to return a particular 2000-class = message for the failing request element, but I don't see a way to convey = partial completion status. Perhaps we could use the third digit; 1 for = partial-commit, 2 for roll-back? >=20 > Implementation designers must choose how to handle a mid-batch failure = and decide what to do with other request elements in batch wherein one = or more elements fail. Options include 1) stopping the batch with a = "partial commit" wherein previously complemented request elements remain = committed to the data store but elements "after" the failing element do = not execute, 2) stopping the batch and rolling-back the data store to = its pre-request state, and 3) continuing the batch, such that all = non-failing elements complete and are committed to the data store. This = is > a complex set of alternatives, and implementors must thoroughly = analyze their choices for DoS vulnerabilities. >=20 > In particular, a "stop and roll-back" choice provides a DoS = opportunity. A hostile client could repeatedly issue large batch = requests with one or more failing elements, causing the server to = repeatedly stop and roll-back large transactions. The suggested response = is to monitor clients for such failures, and take administrative action = (such as blocking the user) when an excessive number of roll-vbacks is = reported. >=20 > KJC: An additional suggested response is for an implementer to set = their maximum allowable XML message size, and their maximum allowable = batch size at a level that they feel protects their operational = instance, given the hardware sizing they have in place and the expected = load and size needs that their users expect. >=20 In the SOAP binding, we have a response code 2001 Request Too Large, = which parameterizes by the maximum number of request elements = supported. This doesn't let us say anything about the actual XML-size.= From dean.willis@softarmor.com Thu Jul 5 07:48:51 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CC021F86A8 for ; Thu, 5 Jul 2012 07:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwvrpzbIPdRo for ; Thu, 5 Jul 2012 07:48:50 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0E2321F869D for ; Thu, 5 Jul 2012 07:48:50 -0700 (PDT) Received: by qadz3 with SMTP id z3so3789223qad.10 for ; Thu, 05 Jul 2012 07:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:from:subject:date:to:x-mailer; bh=iWKvKOGyoZ/Ve1bhE3EVmkqYemPe9NnJpVkmCSwwFcI=; b=bCWgTRaV4NI55if9j/od/Hpy/BpFBkNRjHpk4iHxP+2Cin4uK2i9NjXsEgzJdqhY/R rw5L9eIXMZYo7Dzu2A8wgytiQjYFyR3OBm87l4Z58NmbjLcUOs71zurGxZ/ZKpU/vPmu 4aVUwnB0QYJsOlFHDZdZfAUCaxi8dVcDsHkak= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:from:subject:date:to:x-mailer :x-gm-message-state; bh=iWKvKOGyoZ/Ve1bhE3EVmkqYemPe9NnJpVkmCSwwFcI=; b=OWBdXH/zcKXY+lxrw9xX3ASCd6Pyo1MUwABefo21ytPMlL2CeeR4rMlsqpf86NFcLd vjZQOmr29jJ/BPfhWoN+sUdIA2PK4A+YWvjwIPYIJlNo3uu3NE5cU9k7rTmdjJAOJ+dX kXixZAN3ZnBLjKhNk4d369CBqqBtGnlmyHjaLtCNYvveQsnuTA4B0RVv0NwkIViwyLFg HILKUC7nFh9Bc+RSlezWLjG+W6Io9bcdkEqoYh09DaHcENULNALVFiLyct5aKHCVoLoz 1e/PPNli49To6gHAeC/3eLe9m9bzTRg6wUxFAo6mPKLujyNDwz/rArjQ9pIbHz3We2/D DMsA== Received: by 10.60.2.99 with SMTP id 3mr26956471oet.20.1341499743890; Thu, 05 Jul 2012 07:49:03 -0700 (PDT) Received: from [192.168.2.119] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id l9sm14852415oeg.3.2012.07.05.07.49.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jul 2012 07:49:03 -0700 (PDT) References: <2043209D-2A7F-4CB5-A980-DB8A142EC48F@softarmor.com> In-Reply-To: <2043209D-2A7F-4CB5-A980-DB8A142EC48F@softarmor.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Dean Willis Date: Thu, 5 Jul 2012 09:49:01 -0500 To: drinks@ietf.org X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnGEDDts4wWuhsXRtsGP4E5ItL7rYoLhp290IqBnHtOLVXOK7lj2Faf7sgx4wDzPafKxyOI Subject: Re: [drinks] Proposed text for Security Considerations/DOS X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 14:48:52 -0000 On Jul 5, 2012, at 9:25 AM, Dean Willis wrote: >>=20 >>=20 >> KJC: While it is theoretically possible under some circumstances, = suggesting that implementations can/may "re-order request elements" = might be a pandora's box that we should not open. Re-ordering of request = elements in a batch request is not the intended approach, and I think = that in-order processing is discussed/mentioned in the doc. So you = might want to consider removing the above sentence. >=20 > Right, the SOAP doc 6.2.1.1 Add Request text states "The elements are = processed by the SPPF server in the order in which they are included in = the request." However, the FRAMEWORK document doesn't seem to indicate. = Could different biding have different order-execution properties? If not = we may want to mandate sequential execution in the framework. I am mis-informed; the framework document does have text: =46rom 6.2.5.1 Batch Request Structure With respect to handling of error conditions, it is a matter of policy whether the batch operation processed in a "stop and rollback" fashion or in a "stop and commit" fashion. In the "stop and rollback" scenario, the SPPF server would stop processing elements in the request at the first error and roll back any elements that had already been processed for that batch request. In the "stop and commit" scenario the SPPF server would stop processing elements in the request at the first error but commit any elements that had already been processed for that batch request. From dean.willis@softarmor.com Thu Jul 5 07:51:49 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D56D21F86E1 for ; Thu, 5 Jul 2012 07:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntJCAZZPk7E8 for ; Thu, 5 Jul 2012 07:51:49 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C73F521F85A0 for ; Thu, 5 Jul 2012 07:51:48 -0700 (PDT) Received: by qcac10 with SMTP id c10so4292931qca.31 for ; Thu, 05 Jul 2012 07:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:from:subject:date:to:x-mailer; bh=AFMLiSQW0wn1YqXIlokeBF1LFjyPKKIQdIV0IBW6ynM=; b=BtssQGBkxuMzqQaOd9u09yriO6d/wdRNT5WHbYG7Ubqq2S/wzg+z5ZfpHLAZG1VKVQ +UQC13GFJYR80W/ewWYpUBGwl16/Y5fXzGrjOM4VS3G+Ifeq0wfV/RC6O7fSN+N3+0Cs e73c26VyYt4DtU86PhoGv2rPyPpuBqUOEvuXE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:from:subject:date:to:x-mailer :x-gm-message-state; bh=AFMLiSQW0wn1YqXIlokeBF1LFjyPKKIQdIV0IBW6ynM=; b=UNJav9geSk40xysD/Ibn+6WR8yHhXwFj8EUfPSKKzTg66LPWLTlKozu6Myzvui+WOr 8nbu+vqeKz/GYuGaN0SQV9IL4jpYriKsc5Rx72SnaxgYDbzrxcdJqWbiKIZhPG1UhQaN nlwm/YKXE1sXBJIEYg7FjJrzmMM9r7TtvnPfOrqBnzHhIRtWYc5+PhD6xJGpSvRRpPgu v4d/VW8YmtfL5F9FXDqvGpaf1p0Tnai3LqTV0CFX18ErNIxM+L58LWWeQfP2W7UMHjf3 o0BiNKpJ+i7MSTEqi9BqMjKHsQMx5sICx3AXMAZ5yvFt+xa9qS/DLqud1CBlUTxWdoDd XbVQ== Received: by 10.60.172.202 with SMTP id be10mr108119oec.53.1341499921942; Thu, 05 Jul 2012 07:52:01 -0700 (PDT) Received: from [192.168.2.119] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id rr9sm20846689obc.8.2012.07.05.07.52.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jul 2012 07:52:00 -0700 (PDT) References: <2043209D-2A7F-4CB5-A980-DB8A142EC48F@softarmor.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <5F0C6943-9E3A-49D6-BD76-EF9006B880B7@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Date: Thu, 5 Jul 2012 09:51:57 -0500 To: drinks@ietf.org X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmH6xhv4qF+L+MUBIxutPfocYnFr97rervUZZvN+9iPIp5n4DGTPnFC/G3NT47kThugOyje Subject: Re: [drinks] Proposed text for Security Considerations/DOS X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 14:51:49 -0000 On Jul 5, 2012, at 9:49 AM, Dean Willis wrote: >=20 > On Jul 5, 2012, at 9:25 AM, Dean Willis wrote: >>>=20 >>>=20 >>> KJC: While it is theoretically possible under some circumstances, = suggesting that implementations can/may "re-order request elements" = might be a pandora's box that we should not open. Re-ordering of request = elements in a batch request is not the intended approach, and I think = that in-order processing is discussed/mentioned in the doc. So you = might want to consider removing the above sentence. >>=20 >> Right, the SOAP doc 6.2.1.1 Add Request text states "The elements = are processed by the SPPF server in the order in which they are included = in the request." However, the FRAMEWORK document doesn't seem to = indicate. Could different biding have different order-execution = properties? If not we may want to mandate sequential execution in the = framework. >=20 > I am mis-informed; the framework document does have text: >=20 > =46rom 6.2.5.1 Batch Request Structure >=20 > With respect to handling of error conditions, it is a matter of > policy whether the batch operation processed in a "stop and = rollback" > fashion or in a "stop and commit" fashion. In the "stop and > rollback" scenario, the SPPF server would stop processing elements = in > the request at the first error and roll back any elements that had > already been processed for that batch request. In the "stop and > commit" scenario the SPPF server would stop processing elements in > the request at the first error but commit any elements that had > already been processed for that batch request. >=20 Whoops. I'm misinformed about being mis-informed; that text is from the = SOAP doc, not frmework. So the SOAP document has multiple incidents of = rollback-vs-multiple commit. -- Dean From kcartwright@tnsi.com Thu Jul 5 08:29:27 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CE621F8735 for ; Thu, 5 Jul 2012 08:29:25 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBXtPz-5e1tP for ; Thu, 5 Jul 2012 08:29:24 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4973521F86C9 for ; Thu, 5 Jul 2012 08:29:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAGWy9U+sEQfn/2dsb2JhbABFuC6CGAEBAQMBAQEBNzQXBAIBCBEEAQEBHgkHJwsUCQgBAQQBEgiHfhC5RASLORqFRGADqDWBQw X-IronPort-AV: E=Sophos;i="4.77,531,1336345200"; d="scan'208";a="1354298" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 05 Jul 2012 16:29:36 +0100 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; Thu, 5 Jul 2012 11:29:35 -0400 From: "Cartwright, Ken" To: Dean Willis , "drinks@ietf.org" Date: Thu, 5 Jul 2012 11:29:34 -0400 Thread-Topic: [drinks] Proposed text for Security Considerations/DOS Thread-Index: Ac1avcHj1g+1hufATSi5QrC/TGuioAAAWqIg Message-ID: References: <2043209D-2A7F-4CB5-A980-DB8A142EC48F@softarmor.com> <5F0C6943-9E3A-49D6-BD76-EF9006B880B7@softarmor.com> In-Reply-To: <5F0C6943-9E3A-49D6-BD76-EF9006B880B7@softarmor.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: Re: [drinks] Proposed text for Security Considerations/DOS X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 15:29:28 -0000 I think this ended up getting moved into the SOAP doc as part of the unfort= unate re-layering activity. But isn't that the correct location for it? I= think it better belongs there than in the "Framework" document. -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Dean Willis Sent: Thursday, July 05, 2012 10:52 AM To: drinks@ietf.org Subject: Re: [drinks] Proposed text for Security Considerations/DOS On Jul 5, 2012, at 9:49 AM, Dean Willis wrote: > > On Jul 5, 2012, at 9:25 AM, Dean Willis wrote: >>> >>> >>> KJC: While it is theoretically possible under some circumstances, sugg= esting that implementations can/may "re-order request elements" might be a = pandora's box that we should not open. Re-ordering of request elements in a= batch request is not the intended approach, and I think that in-order proc= essing is discussed/mentioned in the doc. So you might want to consider re= moving the above sentence. >> >> Right, the SOAP doc 6.2.1.1 Add Request text states "The elements are p= rocessed by the SPPF server in the order in which they are included in the = request." However, the FRAMEWORK document doesn't seem to indicate. Could d= ifferent biding have different order-execution properties? If not we may wa= nt to mandate sequential execution in the framework. > > I am mis-informed; the framework document does have text: > > From 6.2.5.1 Batch Request Structure > > With respect to handling of error conditions, it is a matter of > policy whether the batch operation processed in a "stop and rollback" > fashion or in a "stop and commit" fashion. In the "stop and > rollback" scenario, the SPPF server would stop processing elements in > the request at the first error and roll back any elements that had > already been processed for that batch request. In the "stop and > commit" scenario the SPPF server would stop processing elements in > the request at the first error but commit any elements that had > already been processed for that batch request. > Whoops. I'm misinformed about being mis-informed; that text is from the SOA= P doc, not frmework. So the SOAP document has multiple incidents of rollbac= k-vs-multiple commit. -- Dean _______________________________________________ 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 Thu Jul 5 08:29:27 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E61321F872D for ; Thu, 5 Jul 2012 08:29:25 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Wp2hmXBYkvw for ; Thu, 5 Jul 2012 08:29:24 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2ED21F86D8 for ; Thu, 5 Jul 2012 08:29:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAGWy9U+sEQfn/2dsb2JhbABFuC6CGAEBBAE6PwwEAgEIEQQBAR8JBzIUCQgBAQQOBQiHfrlYizkahURgA6g1gUM X-IronPort-AV: E=Sophos;i="4.77,531,1336345200"; d="scan'208";a="1354297" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 05 Jul 2012 16:29:36 +0100 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; Thu, 5 Jul 2012 11:29:34 -0400 From: "Cartwright, Ken" To: Dean Willis Date: Thu, 5 Jul 2012 11:29:34 -0400 Thread-Topic: [drinks] Proposed text for Security Considerations/DOS Thread-Index: Ac1auf0iUKEiBqthR3eh8ki6XEiuoQAAC0SQ Message-ID: References: <2043209D-2A7F-4CB5-A980-DB8A142EC48F@softarmor.com> In-Reply-To: <2043209D-2A7F-4CB5-A980-DB8A142EC48F@softarmor.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 Cc: "drinks@ietf.org" Subject: Re: [drinks] Proposed text for Security Considerations/DOS X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 15:29:28 -0000 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, July 05, 2012 10:25 AM To: Cartwright, Ken Cc: drinks@ietf.org Subject: Re: [drinks] Proposed text for Security Considerations/DOS On Jun 28, 2012, at 10:27 AM, Cartwright, Ken wrote: > > > SPPP allows a client to submit multiple-element or "batch" requests that = may insert or otherwise affect a large amount of data with a single request= . In the simplest case, the server progresses sequentially through each ele= ment in a batch, completing one and before starting the next. However, impl= ementations may re-order request elements, parallelize them, distribute the= m to subprocesses, or perform other optimizations. > > KJC: While it is theoretically possible under some circumstances, sugges= ting that implementations can/may "re-order request elements" might be a pa= ndora's box that we should not open. Re-ordering of request elements in a b= atch request is not the intended approach, and I think that in-order proces= sing is discussed/mentioned in the doc. So you might want to consider remo= ving the above sentence. Right, the SOAP doc 6.2.1.1 Add Request text states "The elements are proc= essed by the SPPF server in the order in which they are included in the req= uest." However, the FRAMEWORK document doesn't seem to indicate. Could diff= erent biding have different order-execution properties? If not we may want = to mandate sequential execution in the framework. KJC: This again comes down to how much "how to develop software" guidance = we want to put in these docs. If you feel that the docs do not make the in= -order processing requirement clear enough then feel free to make that clea= rer. Question: How does a SOAP-binding client know whether a batch rolled back o= r committed-prior-to-error? Which result code is sent in each case? Does th= is require a-priori knowledge about the the server? It seems like we're currently set up to return a particular 2000-class mess= age for the failing request element, but I don't see a way to convey partia= l completion status. Perhaps we could use the third digit; 1 for partial-co= mmit, 2 for roll-back? > > Implementation designers must choose how to handle a mid-batch failure > and decide what to do with other request elements in batch wherein one or= more elements fail. Options include 1) stopping the batch with a "partial = commit" wherein previously complemented request elements remain committed t= o the data store but elements "after" the failing element do not execute, 2= ) stopping the batch and rolling-back the data store to its pre-request sta= te, and 3) continuing the batch, such that all non-failing elements complet= e and are committed to the data store. This is a complex set of alternative= s, and implementors must thoroughly analyze their choices for DoS vulnerabi= lities. > > In particular, a "stop and roll-back" choice provides a DoS opportunity. = A hostile client could repeatedly issue large batch requests with one or mo= re failing elements, causing the server to repeatedly stop and roll-back la= rge transactions. The suggested response is to monitor clients for such fai= lures, and take administrative action (such as blocking the user) when an e= xcessive number of roll-vbacks is reported. > > KJC: An additional suggested response is for an implementer to set their= maximum allowable XML message size, and their maximum allowable batch size= at a level that they feel protects their operational instance, given the h= ardware sizing they have in place and the expected load and size needs that= their users expect. > In the SOAP binding, we have a response code 2001 Request Too Large, which = parameterizes by the maximum number of request elements supported. This do= esn't let us say anything about the actual XML-size. KJC: That's what I meant, too many items in the XML 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 alexander.mayrhofer@nic.at Fri Jul 6 07:22:56 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C6F21F8440 for ; Fri, 6 Jul 2012 07:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.43 X-Spam-Level: X-Spam-Status: No, score=-9.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw1RrjTAmnOM for ; Fri, 6 Jul 2012 07:22:56 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 66E7B21F8579 for ; Fri, 6 Jul 2012 07:22:54 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Fri, 6 Jul 2012 16:23:09 +0200 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Fri, 6 Jul 2012 16:23:04 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: DRAFT minutes from the DRINKS design team call on 2012-07-06 Thread-Index: Ac1bgszmveVV9+YNQVCSPW7k1uw/TQ== Date: Fri, 6 Jul 2012 14:23:04 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075096777FD@NICS-EXCH.sbg.nic.at> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.133] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: [drinks] DRAFT minutes from the DRINKS design team call on 2012-07-06 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:22:56 -0000 DRINKS design team call DRAFT minutes=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=3D=3D=3D=3D=3D=3D=3D=3D=3D Call on Jul 05 2012, 10am - 11am eastern Participants ------------ - David - Syed - Dean - Manjul - Alex - Vikas - Ken - Sumanth ACTION ITEMS ------------ 1/ Send minor changes to David for incorporation into the docs (Alex) 2/ Incorporate comments on docs (David) Minutes ------- Sumanth opens the meeting, walks through Action items from last week. Statu= s: - Dean sent text about DoS - Alex proposed text to address Vikas' concerns, however didn't add that to the documents. - David still has the token on the documents David needs to incorporate a few comments, Alex will send his minor changes to David (AI). David walks design team through changes applied to the document - will send= out=20 the diff to the group. Manjul: catches that ingrSedRec in egress route example should be ingrSedGr= p.. Sumanth requests design team again to please review the changes. DoS: Dean explains concerns about batched requests. Alex says he remembers that we decided to either do commit/rollback, or partial only, and agreed=20 that we did only commit/rollback. Sumanth seconds that.=20 Alex in favour of removing all partial commit traces. Dean notes that=20 Jeremy re-opened that discussion because of simpler database structure of partial commits. Discussion about the "stop and commit" or "stop and rollback" choices Sumanth reminds group that we made a decision it would be "stop and rollbac= k",=20 let's not make it overly complex. Ken mentions that really big batches (eg. 5 million nubmers) are done via f= iles anyway, rather than SOAP requests - but there, failures are expected, and should no= t stop processing. But file-based transmission was not in scope. Sumanth notes we have a standing decision from long time ago. David will start a thread on the mailing list regarding this. Meeting concludes From alexander.mayrhofer@nic.at Thu Jul 12 03:47:59 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6831121F8806 for ; Thu, 12 Jul 2012 03:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.43 X-Spam-Level: X-Spam-Status: No, score=-9.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf9aiV6Z7Ezm for ; Thu, 12 Jul 2012 03:47:58 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCA221F8804 for ; Thu, 12 Jul 2012 03:47:57 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Thu, 12 Jul 2012 12:48:24 +0200 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Thu, 12 Jul 2012 12:48:19 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: Design team call 2012-07-11 DRAFT minutes Thread-Index: Ac1gG9ZQ+TRaAV24SYGWyDsM+Sax9g== Date: Thu, 12 Jul 2012 10:48:17 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750967BD62@NICS-EXCH.sbg.nic.at> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.133] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: [drinks] Design team call 2012-07-11 DRAFT minutes X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 10:47:59 -0000 DRINKS design team call DRAFT minutes 2012-07-11 =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 Design team call on 2012-07-11, 10am - 10:40am Participants ------------ - Dean - Vikas - Sumanth - Manjul - Alex ACTION ITEMS ------------ 1/ Modify document(s) to specify "rollback" as the only operational mode for the SOAP transport (Alex) 2/ Continue Reviewing documents (All) Minutes ------- Sumanth opens the meeting, and mentions the various mails sent to the desig= n team. Vikas incorporated some comments directly into the documents after David se= nt them, result was sent to the design team. Alex' 2nd comment was not yet incorporated by Vikas. Discussion around the status of "commit vs rollback" definition arises. Q: Status of the "commit and rollback"? Dean sent DoS text, but didn't do anything regarding commit/rollback.. Dean: If we want to do both, we would need to have a different requesttype, and also a new response code in order to signal back. Reordering of requests must not happen in either case. Alex is concerned about introducing a second operational mode into the prot= ocol.=20 Dean also thinks we should not add a second operational mode. Sumanth: We have a long standing decision that we should stick to - being "= rollback" Manjul agrees, Vikas has concerns. Currently, docs leave the option open, but server cannot indicate=20 which "mode" of operation it followed.=20 Alex notes that Ken said last time giant bulk requests would likely not use= =20 SOAP transport - so leave it open in the framework, and specify it in the S= OAP? Sumanth describes Options: 1) stick to previous decision, and do only rollback 2) leave it open, and adapt response structure accordingly. Vikas: We could add the info to the getserverdetails request. Vikas: ok with keeping both if clarifications are minor Alex: Understand that some use cases will work better with partial commit. Sumanth: From chair's perspective, we need to clarify within the next=20 few days, before the deadline. Monday is deadline.=20 Timing issue - we won't send the docs to WGLC without addressing this. Sumanth: The document that goes to WGLC should be the one we submit on=20 monday, no "postponed" changes. Decision: Since nobody has the time to address the add the text around addi= ng=20 both options, we stick with rollback only.=20 Alex volunteers to change the documents by tomorrow morning US time.=20 Meeting concludes. From internet-drafts@ietf.org Mon Jul 16 01:28:25 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E28621F84DF; Mon, 16 Jul 2012 01:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQbOA3-NAPOo; Mon, 16 Jul 2012 01:28:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AD021F8476; Mon, 16 Jul 2012 01:28:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716082824.4252.70753.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 01:28:24 -0700 Cc: drinks@ietf.org Subject: [drinks] I-D Action: draft-ietf-drinks-spp-protocol-over-soap-02.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 08:28:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Data for Reachability of Inter/tra-Networ= K SIP Working Group of the IETF. Title : Session Peering Provisioning (SPP) Protocol over SOAP Author(s) : Kenneth Cartwright Vikas Bhatia Alexander Mayrhofer Filename : draft-ietf-drinks-spp-protocol-over-soap-02.txt Pages : 91 Date : 2012-07-16 Abstract: The Session Peering Provisioning Framework (SPPF) is an XML framework 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 protocol for SPPF 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 SPPF XML structures over SOAP and HTTP(s). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-drinks-spp-protocol-over-soap There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-drinks-spp-protocol-over-soap-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-drinks-spp-protocol-over-so= ap-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 16 05:33:31 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B009921F860B; Mon, 16 Jul 2012 05:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3ltGG6+pw72; Mon, 16 Jul 2012 05:33:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAF421F85F8; Mon, 16 Jul 2012 05:33:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716123330.16598.77271.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 05:33:30 -0700 Cc: drinks@ietf.org Subject: [drinks] I-D Action: draft-ietf-drinks-spp-framework-02.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 12:33:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Data for Reachability of Inter/tra-Networ= K SIP Working Group of the IETF. Title : Session Peering Provisioning Framework (SPPF) Author(s) : Kenneth Cartwright Vikas Bhatia Syed Wasim Ali David Schwartz Filename : draft-ietf-drinks-spp-framework-02.txt Pages : 63 Date : 2012-07-16 Abstract: This document specifies the data model and the overall structure for a framework to provision session establishment data into Session Data Registries and SIP Service Provider data stores. The framework is called the Session Peering Provisioning Framework (SPPF). The provisioned data is typically used by network elements for session peering. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-drinks-spp-framework-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-drinks-spp-framework-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sumanth@cablelabs.com Mon Jul 30 16:50:35 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9ED211E809B for ; Mon, 30 Jul 2012 16:50:35 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kXI6i92ExPC for ; Mon, 30 Jul 2012 16:50:35 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 49A9211E8072 for ; Mon, 30 Jul 2012 16:50:32 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q6UNoP8A026322 for ; Mon, 30 Jul 2012 17:50:25 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 30 Jul 2012 17:50:25 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 30 Jul 2012 17:50:25 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Mon, 30 Jul 2012 17:50:22 -0600 Thread-Topic: Quick WG Status Thread-Index: Ac1urhbUP6Gs87x7QjqSJ2uV0kH/yw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC3C6BCEF6A2sumanthcablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Quick WG Status X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:50:36 -0000 --_000_CC3C6BCEF6A2sumanthcablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG Participants, Since we are not planning to meet in Vancouver, we wanted to provide a quic= k update on the WG status. As you know we have had three goals and mileston= es in the charter (for a while). 1. Use Cases and Protocol Requirements; draft-ietf-drinks-usecases-requirem= ents 2. Session Provisioning Protocol (SPP) Framework; draft-ietf-drinks-spp-fra= mework 3. SPP over SOAP; draft-ietf-drinks-spp-protocol-over-soap #1 was completed and published as RFC6461. The remaining two documents were= recently updated to address comments made during the last IETF, and in sub= sequent design team and other discussions, which have been captured on the = mailing list (http://www.ietf.org/mail-archive/web/drinks/current/maillist.= html). The design team believes that all of the known comments and feedback have b= een incorporated into these two documents, based on resolutions that the de= sign team arrived at. Accordingly, we believe it is now ready for another (= final?) working group last call. We will be announcing this shortly. - Alex & Sumanth (as WG Chairs) --_000_CC3C6BCEF6A2sumanthcablelabscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear WG Participant= s,

Since we are not planning to meet in Vancouver,= we wanted to provide a quick update on the WG status. As you know we have = had three goals and milestones in the charter (for a while).

=
1. Use Cases and Protocol Requirements; draft-ietf-drinks-usecas= es-requirements
2. Session Provisioning Protocol (SPP) Framework;= draft-ietf-drinks-spp-framework 
3. SPP over SOAP; draft-ie= tf-drinks-spp-protocol-over-soap

#1 was completed = and published as RFC6461. The remaining two documents were recently updated= to address comments made during the last IETF, and in subsequent design te= am and other discussions, which have been captured on the mailing list (htt= p://www.ietf.org/mail-archive/web/drinks/current/maillist.html). 

The design team believes that all of the known comment= s and feedback have been incorporated into these two documents, based on re= solutions that the design team arrived at. Accordingly, we believe it is no= w ready for another (final?) working group last call. We will be announcing= this shortly.

- Alex & Sumanth (as WG Chairs)=





=



--_000_CC3C6BCEF6A2sumanthcablelabscom_-- From alexander.mayrhofer@nic.at Mon Jul 30 16:55:22 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A090621F8564 for ; Mon, 30 Jul 2012 16:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.43 X-Spam-Level: X-Spam-Status: No, score=-9.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDAD6FsxWEt7 for ; Mon, 30 Jul 2012 16:55:22 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 74EE021F8562 for ; Mon, 30 Jul 2012 16:55:20 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Tue, 31 Jul 2012 01:55:19 +0200 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Tue, 31 Jul 2012 01:55:14 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: WGLC announcement for draft-ietf-drinks-spp-framework-02.txt Thread-Index: Ac1urmz/pL/X+UEuRVGMmzKFOLlf9Q== Date: Mon, 30 Jul 2012 23:55:14 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750969AFA9@NICS-EXCH.sbg.nic.at> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.17.175.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: [drinks] WGLC announcement for draft-ietf-drinks-spp-framework-02.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:55:22 -0000 WG Participants, This email is to announce the Working Group Last Call(WGLC) for comments re= lated to draft-ietf-drinks-spp-framework-02.txt =20 Link : http://tools.ietf.org/id/draft-ietf-drinks-spp-framework-02.txt Title : Session Peering Provisioning Framework (SPPF) Intended status of th= e document: Standards Track --- Please review the document, and send comments to this (drinks@ietf.org) mai= ling list. The WGLC for this document will last for three weeks starting Ju= ly 31st, 2012 - so please send your comments by: Aug, 21, 2012, 23:59 UTC. =20 For an overview about the draft's history and associated diffs, please see: http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/history/ =09 Changes to this draft, and the reason for the changes, can be obtained from= mailing list discussions at: http://www.ietf.org/mail-archive/web/drinks/current/maillist.html --- As a note, this document replaced - what used to be - the Session Peering P= rovisioning Protocol Data Model, after this version: http://tools.ietf.org/html/draft-ietf-drinks-spprov-12 The reason for the update is documented in the meeting notes from Taipei, at: http://www.ietf.org/mail-archive/web/drinks/current/msg01077.html, and = subsequent discussions on the mailing list. Regards, Alex [As WG chair] From sumanth@cablelabs.com Mon Jul 30 16:55:23 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698DA21F8564 for ; Mon, 30 Jul 2012 16:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GoZuJcGx5+C for ; Mon, 30 Jul 2012 16:55:23 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id DEA1521F8562 for ; Mon, 30 Jul 2012 16:55:22 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q6UNtL4T026663 for ; Mon, 30 Jul 2012 17:55:21 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 30 Jul 2012 17:55:21 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 30 Jul 2012 17:55:22 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Mon, 30 Jul 2012 17:55:18 -0600 Thread-Topic: WGLC announcement for draft-ietf-drinks-spp-protocol-over-soap-02.txt Thread-Index: Ac1urseSiva38cEsRzi4aqBd/erAxA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC3C6CF6F6AEsumanthcablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] WGLC announcement for draft-ietf-drinks-spp-protocol-over-soap-02.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:55:23 -0000 --_000_CC3C6CF6F6AEsumanthcablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WG Participants, This email is to announce the Working Group Last Call(WGLC) for comments re= lated to draft-ietf-drinks-spp-protocol-over-soap-02.txt Link : http://tools.ietf.org/id/draft-ietf-drinks-spp-protocol-over-soap-0= 2.txt Title : Session Peering Provisioning (SPP) Protocol over SOAP Intended status of the document: Standards Track --- Please review the document, and send comments to this (drinks@ietf.org) mai= ling list. The WGLC for this document will last for three weeks starting Ju= ly 31st, 2012 - so please send your comments by: Aug, 21, 2012, 23:59 UTC. For an overview about the draft's history and associated diffs, please see: http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-protocol-over-soap/hi= story/ Changes to this draft, and the reason for the changes, can be obtained from= mailing list discussions at: http://www.ietf.org/mail-archive/web/drinks/current/maillist.html --- As a note, this document replaced - what used to be - SPPP Over SOAP and HT= TP, after this version: http://tools.ietf.org/id/draft-ietf-drinks-sppp-over-soap-07.txt The reason for the update is documented in the meeting notes from Taipei, a= t: http://www.ietf.org/mail-archive/web/drinks/current/msg01077.html, and s= ubsequent discussions on the mailing list. Regards, Sumanth [As WG chair] --_000_CC3C6CF6F6AEsumanthcablelabscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
WG Participants,

This email is to announce the Working Group Last Cal= l(WGLC) for comments related to draft-ietf-drinks-spp-protocol-over-soap-02= .txt
 
Link  : http://tools.ietf.org/id/draft= -ietf-drinks-spp-protocol-over-soap-02.txt
Title : Session Peerin= g Provisioning (SPP) Protocol over SOAP
Intended status of the do= cument: Standards Track


--- 
Please review the document, and send comments to this (drinks@ietf= .org) mailing list. The WGLC for this document will last for three weeks st= arting July 31st, 2012  - so please send your comments by: Aug, 21, 20= 12, 23:59 UTC.
 
For an overview about the draft's= history and associated diffs, please see:
http://datatracker.iet= f.org/doc/draft-ietf-drinks-spp-protocol-over-soap/history/

=
Changes to this draft, and the reason for the changes, can be ob= tained from mailing list discussions at:
http://www.ietf.org/mail= -archive/web/drinks/current/maillist.html

---
As a note, this document replaced - what used to be - SPPP Over SOAP = and HTTP, after this version:
http://tools.ietf.org/id/draft-ietf= -drinks-sppp-over-soap-07.txt 
 
The reason f= or the update is documented in the meeting notes from Taipei, at: http://ww= w.ietf.org/mail-archive/web/drinks/current/msg01077.html, and subsequent di= scussions on the mailing list.


Rega= rds,
Sumanth [As WG chair]
--_000_CC3C6CF6F6AEsumanthcablelabscom_--