From dean.willis@softarmor.com Tue May 8 08:08:18 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 0489211E8085 for ; Tue, 8 May 2012 08:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.529 X-Spam-Level: X-Spam-Status: No, score=-103.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 c1Q8mYVtwLRJ for ; Tue, 8 May 2012 08:08:17 -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 396E111E8098 for ; Tue, 8 May 2012 08:08:17 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so11818986obb.31 for ; Tue, 08 May 2012 08:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer; bh=SEU/QLJulJL+KTK79cm4MnISZ5puq2rDCRyb7L+2aMQ=; b=GPBSzjAEx3st69/eZcP8z2PjrJIa4xL+Gjf0Z8S4kyZcSvDarf8ZkP6xZ0v+4jvW9/ l5+5GBcXjbIwOiafnskz1ATGneQBLHdwlvc6fkYnhdK7FzGo6labm8KQKxpEMGwkunw8 AqELt30NM6GnOFicajL8VQj8YidqH68BmdYfY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer:x-gm-message-state; bh=SEU/QLJulJL+KTK79cm4MnISZ5puq2rDCRyb7L+2aMQ=; b=W9sNNaqxLw6/SttgHpgnL1rcOxg99tEiLH+2LOo4G9UBevznNP5xmCRgYXBrT7krjW qbJYLhIw6xkhhXK001QCiUn5FFin1jBJAHbpwdn+tpvcsx9yyCjLNfuxJROg0Zovu5M6 qvcxYnjs0ggVdZUtN1RK1Jh9wXfp63gw/Het4VUY+6ttdcs9ZwBBzcrztfGhddjwB/QL nGc1QokS1pPhytp/9botTW10FZV+eSovG6cpkXcU13AeL1EVK+ku+c9NEATbwL+bs/wR W897GxryItq1oT3LD+RH0zXQ2+LLUcsXGiwb+fNVGfMKck+lXwzq5rnNlQ0mNend/OLV 8tfA== Received: by 10.182.179.73 with SMTP id de9mr4535852obc.44.1336489696755; Tue, 08 May 2012 08:08:16 -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 bd10sm22029502obb.15.2012.05.08.08.08.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 08:08:15 -0700 (PDT) From: Dean Willis Content-Type: text/plain; charset=us-ascii Message-Id: Date: Tue, 8 May 2012 10:08:14 -0500 To: drinks@ietf.org Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnUKhVnUNKb6G6CtKzu2d3CaMwhVyG09R9VCRUF4plezwxwpPYZuI/y7TZwqz3ZSVC+oFZY Subject: [drinks] Security considerations references 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: Tue, 08 May 2012 15:08:18 -0000 Someone asked for references on today's design tem call How-to references: http://www.ietf.org/rfc/rfc3552.txt http://www.ietf.org/rfc/rfc4732.txt http://tools.ietf.org/html/rfc4778 Examples: http://tools.ietf.org/html/rfc3964 http://www.rfc-editor.org/rfc/rfc4347.txt chapter 5 http://www.viagenie.ca/ietf/rfc/rfc5619.txt chapter 3 http://xmpp.org/extensions/xep-0205.html , esp. ch. 4 Absolutely minimal example: http://bitworking.org/projects/atom/rfc5023.html#rfc.section.15.1 Example of how NOT to do it: http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html esp. 15.7.1 From dean.willis@softarmor.com Tue May 8 08:48:30 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 0CA6111E80B0 for ; Tue, 8 May 2012 08:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.534 X-Spam-Level: X-Spam-Status: No, score=-103.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 Y1FEyxlcR9ZQ for ; Tue, 8 May 2012 08:48:29 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04A5B21F8652 for ; Tue, 8 May 2012 08:48:28 -0700 (PDT) Received: by yenq13 with SMTP id q13so2026930yen.31 for ; Tue, 08 May 2012 08:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer; bh=OZhMS/8F0qK5+6ED22oqkKzpY3igbb2AMPJuC3VQXs4=; b=J+JS9R5CUH+DYYTL8rHlDtyV10Bqim4HMLJj3VAg0oRWyqNjrdofYClwWOW9+a0Uzj dBtSTAsrCs9b94xDWuGbWIeziePi2GJvf4Le7hAoCRrkKpzZkfbV9Div1jLCINGPxBu6 iMhgEM8dnOcU+wYrJyRl55Uww99EwRffI04Ds= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer:x-gm-message-state; bh=OZhMS/8F0qK5+6ED22oqkKzpY3igbb2AMPJuC3VQXs4=; b=nXkeHRo5PCCtttsUmntWphPS0gVYVgep6URg/DkR7CpKEeUp+y+3JOUgZR5LBExVgN A0Qbcw8P8PFQxMxwlFH0Mjf4Ui5E+Z9TFLQRwTp3sr2eGksvCbsUn12E2E9Yks3FlWo9 YH79HJ2U/5u3WXPGCREu3kgXpA0/xfNeznvSx4do4AE1cPni+m49d+8yfDRjAVWXQ0Uc Os2TjLzUKHXjYkmJJdMzYNLC/hUD5aoOjZ1m4qjDsOrpVevgQOWYObywA1PLoT3cCiyT Zbae5zvFrVUL9roRbGDfZNzTn0hDn5dgPNA9lpJ+eAun/RFUslOBLGq0wfe2+P/GfY+i wNnQ== Received: by 10.60.13.37 with SMTP id e5mr7597740oec.70.1336492108538; Tue, 08 May 2012 08:48:28 -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 yw3sm22150392obb.7.2012.05.08.08.48.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 08:48:28 -0700 (PDT) From: Dean Willis Content-Type: text/plain; charset=us-ascii Message-Id: <0A1AD864-5663-4348-AB5F-46B61ABA83D8@softarmor.com> Date: Tue, 8 May 2012 10:48:26 -0500 To: drinks@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmxxs5jK0ptAzqfvq6k4l5/+hAI6Jez+PD4bZUYvmH317DJJxkOlk0ntFbAZb5VhOnbWgkK Subject: [drinks] Thoughts on DoS issue related to "batch transactions" 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: Tue, 08 May 2012 15:48:30 -0000 SPPP as currently defined allows a client to send a bundle of requests = to a server. We have an open question on what to do when one of those requests fails. = Options include: 1) Process the requests in the bundle sequentially, and stop the bundle = when one fails. a) Keep the completed requests, reject the remainder, and tell the = client what happened. We might call this "partial sequential completion = of the bundle". b) Roll back all completed requests, returning the server to the state = at which it was before the transaction started. We might call this = "atomic sequential completion of the bundle". 2) Process the requests in the bundle independently, notifying the = client of each failed request. We might call this "independent = completion of the bundle with no guarantee of sequential processing". We started with 1a, and I suggested 1b due to the risk of leaving the = server content in an unexpected state. Jeremy argues in favor of 1a, on = the argument that rolling back a large transaction bundle is hard on a = database and we might be introducing a DoS opportunity. But it occurs to me that if we use a model like 2, then we have the = potential to parallel-process requests in the bundle. This would require = two things; Req 1) Not structuring sequential dependencies in a bundle. For example, = if within a a request we add A, B, and C and delete B, a sequential = execution would give us a database with records A and C. Non-sequential = execution might give us either a database containing A and C or a = database containing A. B, and C, and an error message that says B did = not exist. Actually we don't have to NOT do this; we just have to be = willing to live with either result. Req 2) We need to be able to return multiple responses, potentially one = for each transaction in the bundle. However, what independent processing and reporting gives us is the = ability to fully parallelize and distribute the requests in a bundle. = That could be a huge performance game changer. If we choose to stay with 1b, I believe that any DoS issue could be = dealth with by describing the issue (a client can DoS the server by = repeatedly issuing large bundles with a single failing transaction at = the end), and the mitigation (since the server authenticates such = requests, it can start denying service to an abusive client) in the = security considerations section of the document. A 1b solution also allows some parallelization of the requests subject = to a sequential-dependency analysis, so I favor it as a potential = improver of performance over 1a. However, the 1a solution is by far the = simplest. -- Dean From alexander.mayrhofer@nic.at Wed May 9 07:21:28 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 1A59B11E8089 for ; Wed, 9 May 2012 07:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.797 X-Spam-Level: X-Spam-Status: No, score=-8.797 tagged_above=-999 required=5 tests=[AWL=0.633, 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 7M3LsOeumGYH for ; Wed, 9 May 2012 07:21:25 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id D217011E8072 for ; Wed, 9 May 2012 07:21:24 -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 ; Wed, 9 May 2012 16:21:22 +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; Wed, 9 May 2012 16:21:18 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: DRAFT minutes of the DRINKS design team call on 2012-05-08 Thread-Index: Ac0t7vFc2F1N2DAGTUqZoLfgJrQ6bw== Date: Wed, 9 May 2012 14:21:16 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750EAF10@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 of the DRINKS design team call on 2012-05-08 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: Wed, 09 May 2012 14:21:28 -0000 DRINKS Design Team Call DRAFT minutes - May 08 2012, 10am - 11am EST =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Participants: ------------- - Ken Cartwright - Sumanth Channabasappa=20 - Vikas Bhatia - Alexander Mayrhofer - Dean Willis Agenda ------ 1/ Document open issues Action items ------------ 0/ Research and describe status of the four remaining issues (as below) Minutes of the call ------------------- Sumanth opens the call, proposes in order to address the open issues to: - list all open items - get a clear definition of each of them - decide how to proceed with each item There was one open item from posting the new docs, which was the discussion about "peering" (combined with the "route group offer" generalisazion) Furthermore, the internationalization issue is also still open. Then=20 more open items were added in Paris =20 (Sumanth opens up the .rtf notes that he uploaded to the meetings=20 material page - they seem to be different from what is shown on the=20 tools.ietf.org page.) Two more issues were discussed in Paris, which makes the total list of=20 open issues: - route group type issue (added during Paris meeting) - denial of service considerations (added during Paris) - peering / route group offer generalization=20 - internationalization (Ken noted that i18n is still open - added as fourth items) The status of each of the items was then discussed. No concensus was reached on the route group type in Paris - discussion=20 about value of that mechanism. Peering: had a few emails around that, Dean posted a proposal text to the=20 mailing list. Denial of Service: Jeremy presented, we might need additional text in the=20 document to address those concerns. Internationalization: Text proposed, comments from Ken received.=20 Vikas an Ken note that they have limited resources during this and=20 the next week. Sumanth proposes that we should assign each item to a participant of the ca= ll, who should then research the current status of the item, so that we=20 could address the item with all available information during one of the nex= t=20 calls. Sumanth proposes to take on DoS considerations, Alex proposes taking on i18= n. There is an discussion about what exactly the "Peering / route group offer"= =20 open item should compromise, and whether that wasn't already solved? There= =20 is agreement that we won't change the core of the protocol Ken notes: if we removed it, do we create a "peering protocol"=20 without any peering?=20 Ken said he didn't like the new intro text, but he can live with it. Dean: The problems of of how/whether we do peering, and the route record ge= neralization (using URIs) are differnt problems. ("SED data type" thread). DoS: Ken notes that for example EPP do not mention DoS considerations at al= l.. Sumanth says that DoS is part of the security considerations in most ca= ses. Dean: RFC3552 describes how to consider DoS in security consideration secti= ons.=20 Alex: summing up the individual issues was to be assigned to a certain pers= on: - route group type issue (added during Paris meeting) =3D> Alex - denial of service considerations (added during Paris) =3D> Ken=20 - peering / route group offer generalization =3D> Sumanth - internationalization =3D> Alex Sumanth originally offered to take the DoS issue, Ken offeres to take=20 that one over. Ken: keep i18n simple.=20 Alex: Yes, should be limited to things that are required to ensure interopa= bility. Next call: next wed at usual time. summarize issues until then. Call concludes. From shollenbeck@verisign.com Wed May 9 07:38:07 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 856E711E8072 for ; Wed, 9 May 2012 07:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Lfpg0bGWb9Uf for ; Wed, 9 May 2012 07:38:07 -0700 (PDT) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id C62CF11E8079 for ; Wed, 9 May 2012 07:38:02 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKT6qBSn1v0JnH47LOOvEiUEo+H7JwoHuA@postini.com; Wed, 09 May 2012 07:38:06 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q49Ebv5Y013442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 May 2012 10:37:58 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Wed, 9 May 2012 10:37:58 -0400 From: "Hollenbeck, Scott" To: Alexander Mayrhofer , "drinks@ietf.org" Thread-Topic: DRAFT minutes of the DRINKS design team call on 2012-05-08 Thread-Index: Ac0t7vFc2F1N2DAGTUqZoLfgJrQ6bwAAe+Wg Date: Wed, 9 May 2012 14:37:57 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D5FA6B9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <19F54F2956911544A32543B8A9BDE0750EAF10@NICS-EXCH.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE0750EAF10@NICS-EXCH.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [drinks] DRAFT minutes of the DRINKS design team call on 2012-05-08 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: Wed, 09 May 2012 14:38:07 -0000 > DoS: Ken notes that for example EPP do not mention DoS considerations > at all.. Sumanth says that DoS is part of the security considerations > in most cases. It's most definitely mentioned in the EPP specs. Please see the last paragr= aph of section 8 of RFC 5734, "Extensible Provisioning Protocol (EPP) Trans= port over TCP". Scott From kcartwright@tnsi.com Wed May 9 09:54:01 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 21AFE21F8484 for ; Wed, 9 May 2012 09:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.930, 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 Dxhb2C4n37MP for ; Wed, 9 May 2012 09:54:00 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id A200221F8472 for ; Wed, 9 May 2012 09:53:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EANGgqk+sEQfn/2dsb2JhbABEtEGCDAEBAQMBAQEBNzQQBwQCAQgRBAEBHwkHJwsUCQgBAQQBEggThXeBdxC7cgSLDBmFFmMEqUOBQg X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="1193461" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 09 May 2012 17:53:55 +0100 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; Wed, 9 May 2012 12:53:55 -0400 From: "Cartwright, Ken" To: "Hollenbeck, Scott" , Alexander Mayrhofer , "drinks@ietf.org" Date: Wed, 9 May 2012 12:53:53 -0400 Thread-Topic: [drinks] DRAFT minutes of the DRINKS design team call on 2012-05-08 Thread-Index: Ac0t7vFc2F1N2DAGTUqZoLfgJrQ6bwAAe+WgAATKeYA= Message-ID: References: <19F54F2956911544A32543B8A9BDE0750EAF10@NICS-EXCH.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F0D5FA6B9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D5FA6B9@BRN1WNEXMBX01.vcorp.ad.vrsn.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] DRAFT minutes of the DRINKS design team call on 2012-05-08 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: Wed, 09 May 2012 16:54:01 -0000 My apologies. I missed it in there at the end of the security consideratio= ns section: EPP TCP servers are vulnerable to common TCP denial-of-service attacks including TCP SYN flooding. Servers SHOULD take steps to minimize the impact of a denial-of-service attack using combinations of easily implemented solutions, such as deployment of firewall technology and border router filters to restrict inbound server access to known, trusted clients. -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Hollenbeck, Scott Sent: Wednesday, May 09, 2012 10:38 AM To: Alexander Mayrhofer; drinks@ietf.org Subject: Re: [drinks] DRAFT minutes of the DRINKS design team call on 2012-= 05-08 > DoS: Ken notes that for example EPP do not mention DoS considerations > at all.. Sumanth says that DoS is part of the security considerations > in most cases. It's most definitely mentioned in the EPP specs. Please see the last paragr= aph of section 8 of RFC 5734, "Extensible Provisioning Protocol (EPP) Trans= port over TCP". Scott _______________________________________________ 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 dean.willis@softarmor.com Wed May 9 12:12:07 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 BC7CA11E80C6 for ; Wed, 9 May 2012 12:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.505 X-Spam-Level: X-Spam-Status: No, score=-103.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 ftAB21QLxnM0 for ; Wed, 9 May 2012 12:12:07 -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 05B0411E80D5 for ; Wed, 9 May 2012 12:12:06 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so806699obb.31 for ; Wed, 09 May 2012 12:12: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:cc:from:subject:date:to:x-mailer; bh=+oEt/NXNfF/70BpcziTu8vr/5yTiCtdiJOqq31aEhNk=; b=avxay7bJHLHgvHXzgWnxBH8lZEKaiTMjzmgP3zzWwHeZGyBQbBRKA6t4iYE4YKv951 mVZYGu7zLSr6SZC/q2q8Yza51xVP9gPgGgb2GnREeRoWTh/nl1e9ZIVf4Z0KWS56rR3K kZ6rjrp3eGMVKjuAElMdyNt6Vd1JUqDfL7Hz8= 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=+oEt/NXNfF/70BpcziTu8vr/5yTiCtdiJOqq31aEhNk=; b=iHZW1RQycgHr3fgSfxegip90DqywtG2kSmHzySICAI3hapI3VAT2iwl4Yh+ursfSDg UM+3oA7WI3Jm7o1pmY9OY58k/ZSCHS5yd8CXdlG1eSGKwZwkP+p3PuAEYSdAZ2mVYk91 3/ppBWZppiREFpOUzkDiZesVu6fZUjPfdc4WHN0on7LzvhncNgtePUbTfkiHmUWeF6hd EubL3JoBo//1hrjXSoIOvPAzqD9MJjrfDWGXbN3lCZEU0nRfmoExHdt/+Hl4oiSNfbKL LAA7fmY3jQcA73ocZgHjGIjEbwajNZhR1/hIKMSKSsAZRY8Z8YDX1PCsJdBBhQySHLSv hp4Q== Received: by 10.182.119.33 with SMTP id kr1mr1661075obb.60.1336590721104; Wed, 09 May 2012 12:12: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 n9sm2919765oen.2.2012.05.09.12.12.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 May 2012 12:12:00 -0700 (PDT) References: <19F54F2956911544A32543B8A9BDE0750EAF10@NICS-EXCH.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F0D5FA6B9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <8C109A29-B0F1-47BA-834F-069CF192BDB2@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Date: Wed, 9 May 2012 14:11:59 -0500 To: "Cartwright, Ken" X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkAO5iFZ86Zf63hiM9C5SAXzk4Fn4sOMWe+TCGkWM+CsgpRvJ2Rb07vz5k7KEHljW5b2bIa Cc: "drinks@ietf.org" Subject: Re: [drinks] DRAFT minutes of the DRINKS design team call on 2012-05-08 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: Wed, 09 May 2012 19:12:07 -0000 On May 9, 2012, at 11:53 AM, Cartwright, Ken wrote: > My apologies. I missed it in there at the end of the security = considerations section: >=20 > EPP TCP servers are vulnerable to common TCP denial-of-service > attacks including TCP SYN flooding. Servers SHOULD take steps to > minimize the impact of a denial-of-service attack using combinations > of easily implemented solutions, such as deployment of firewall > technology and border router filters to restrict inbound server > access to known, trusted clients. >=20 >=20 >=20 Yep. By RFC 4732 standards, it's not much of an analysis of DoS in the = context of EPP. It's like the good old days when "Use a firewall" was = considered an adequate Security Considerations section. On the other hand, it may well be enough of an analysis for the = constituency of the protocol, which might as well be published by the = WGNETF (that's Walled Garden Network Engineering Task Force). There's no = apparent expectation of using this protocol on the public net. Should = there be? -- Dean From kcartwright@tnsi.com Wed May 9 12:48:46 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 46CD721F8539 for ; Wed, 9 May 2012 12:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 l2GBsGy6s7sY for ; Wed, 9 May 2012 12:48:45 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA17B21F8535 for ; Wed, 9 May 2012 12:48:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAMXJqk+sEQfn/2dsb2JhbABEtESCDAEBBAE6PwUHBAIBCBEEAQEfCQcyFAkIAQEEDgUIE4V3gXe8C4sMGYUWYwSpQ4FC X-IronPort-AV: E=Sophos;i="4.75,559,1330905600"; d="scan'208";a="1194174" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 09 May 2012 20:48:44 +0100 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; Wed, 9 May 2012 15:48:44 -0400 From: "Cartwright, Ken" To: Dean Willis Date: Wed, 9 May 2012 15:48:42 -0400 Thread-Topic: [drinks] DRAFT minutes of the DRINKS design team call on 2012-05-08 Thread-Index: Ac0uF6CiGAGartIsRwq+bimUFItiDQAAosug Message-ID: References: <19F54F2956911544A32543B8A9BDE0750EAF10@NICS-EXCH.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F0D5FA6B9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <8C109A29-B0F1-47BA-834F-069CF192BDB2@softarmor.com> In-Reply-To: <8C109A29-B0F1-47BA-834F-069CF192BDB2@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] DRAFT minutes of the DRINKS design team call on 2012-05-08 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: Wed, 09 May 2012 19:48:46 -0000 EPP is used on the "public net" (at least it was when I implemented and ran= my EPP clients several years ago, and I'm fairly certain it still is, by m= ultiple implementers). And SPP will be used on the "public net". Ken -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, May 09, 2012 3:12 PM To: Cartwright, Ken Cc: Hollenbeck, Scott; Alexander Mayrhofer; drinks@ietf.org Subject: Re: [drinks] DRAFT minutes of the DRINKS design team call on 2012-= 05-08 On May 9, 2012, at 11:53 AM, Cartwright, Ken wrote: > My apologies. I missed it in there at the end of the security considerat= ions section: > > EPP TCP servers are vulnerable to common TCP denial-of-service > attacks including TCP SYN flooding. Servers SHOULD take steps to > minimize the impact of a denial-of-service attack using combinations > of easily implemented solutions, such as deployment of firewall > technology and border router filters to restrict inbound server > access to known, trusted clients. > > > Yep. By RFC 4732 standards, it's not much of an analysis of DoS in the cont= ext of EPP. It's like the good old days when "Use a firewall" was considere= d an adequate Security Considerations section. On the other hand, it may well be enough of an analysis for the constituenc= y of the protocol, which might as well be published by the WGNETF (that's W= alled Garden Network Engineering Task Force). There's no apparent expectati= on of using this protocol on the public net. Should there be? -- Dean 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 dean.willis@softarmor.com Thu May 10 22:23:02 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 D94AA21F8507 for ; Thu, 10 May 2012 22:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.509 X-Spam-Level: X-Spam-Status: No, score=-103.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 b0RDiRxVE9Wk for ; Thu, 10 May 2012 22:23:01 -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 C271921F84B3 for ; Thu, 10 May 2012 22:23:01 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so3315232obb.31 for ; Thu, 10 May 2012 22:23:00 -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=/dZLg92FcwoBYGWa0M8DUbsM1yjbL5XPsnEecEQelD0=; b=Nl1jt3fUwALXzi6P9o/AYYPRR4ELQ3Iv7lnhmFMQnz8F1Q2jAD3pUd0pFBBnMtbG1t aOnyTYeZ9UUs9UBvGKpurmYnR0Txwe27hJadnnKi+83VQ0+C7d8r5fSH+5Rw+FEOc7mm jyLarcLnWxMtpm1hhClBi7EoGhOm37PUxZZ/w= 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=/dZLg92FcwoBYGWa0M8DUbsM1yjbL5XPsnEecEQelD0=; b=Byy+E3Qvn5eJoWJwcX1pGBa/+YJRi8ZkHZnc6NUsyMkTsJ6JF6HJUlowM/NgzjP31o LdX6fnFLg/ep4qdl46X//UzNWrJfnYqRHlzS+wJFsLhkURJFESMQw17KRiuBjDoMMVP9 c4tGVjkoYi6m/vKgCPqfQ/9MqJgN1nb4zK1VlE4ygS81Iy16JOamvFtbdMBOCgvoW90e 3cRG4nqaTvJ+HYe4YeNigk85lLsJOkKtelo5H/HLYxMm3N+RohOqc7Xl23z2f0DBpcdv CYS0cylKYcVA3FaO2mro3GV/UP9xSEgadbW/xlMFOVWPA8UqbG5Gvmh9ZGNyuBP2A6kj QO0g== Received: by 10.60.24.201 with SMTP id w9mr9455333oef.49.1336713780886; Thu, 10 May 2012 22:23:00 -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 vp14sm6913976oeb.5.2012.05.10.22.22.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 22:22:59 -0700 (PDT) References: <19F54F2956911544A32543B8A9BDE0750EAF10@NICS-EXCH.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F0D5FA6B9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <8C109A29-B0F1-47BA-834F-069CF192BDB2@softarmor.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <996893A5-6F21-4F89-BBAE-85301AD33671@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Date: Fri, 11 May 2012 00:22:58 -0500 To: "Cartwright, Ken" X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQl3LMp33EIDwuMW+taqUXIp4X2Of1GM8GRThQlCT7rBs7iji770U8pBvRwK2MPv1CJamOWa Cc: "drinks@ietf.org" Subject: Re: [drinks] DRAFT minutes of the DRINKS design team call on 2012-05-08 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, 11 May 2012 05:23:03 -0000 On May 9, 2012, at 2:48 PM, Cartwright, Ken wrote: > EPP is used on the "public net" (at least it was when I implemented = and ran my EPP clients several years ago, and I'm fairly certain it = still is, by multiple implementers). And SPP will be used on the = "public net". >=20 OK, then that argues for a slightly higher standard of documentation on = things like security/DoS analysis. This shouldn't be a huge amount of = work, just a couple of paragraphs citing the usual fixes for TCP servers = like edge filters, etc. from the RFC, and whatever we conclude about the = DoS concern. Almost everything is doable "by reference" now. -- Dean= From vbhatia@tnsi.com Mon May 14 11:44:01 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 85CCD21F88B4 for ; Mon, 14 May 2012 11:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.734 X-Spam-Level: X-Spam-Status: No, score=0.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_IOW=3.333] 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 TTFUpndtAm4I for ; Mon, 14 May 2012 11:44:00 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 959BF21F88AC for ; Mon, 14 May 2012 11:43:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAEVRsU+sEQfn/2dsb2JhbABEtHuCFQEBAQQBAQE3NBcEAgEIEQQBAR8JBycLFAkIAQEEARIIE4d+ul8EixoZhQRjBKlCgUM X-IronPort-AV: E=Sophos;i="4.75,588,1330905600"; d="scan'208";a="1206222" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 14 May 2012 19:43:57 +0100 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; Mon, 14 May 2012 14:43:57 -0400 From: "Bhatia, Vikas" To: Dean Willis , "drinks@ietf.org" Date: Mon, 14 May 2012 14:43:54 -0400 Thread-Topic: [drinks] Thoughts on DoS issue related to "batch transactions" Thread-Index: Ac0tMgYE/pkkZuLyTumpctGox/7YcQEytA5A Message-ID: References: <0A1AD864-5663-4348-AB5F-46B61ABA83D8@softarmor.com> In-Reply-To: <0A1AD864-5663-4348-AB5F-46B61ABA83D8@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] Thoughts on DoS issue related to "batch transactions" 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, 14 May 2012 18:44:01 -0000 W.r.t the comment "If we choose to stay with 1b,..." It is my understanding that there was general agreement on the following tw= o points for the processing of requests in a SPP Protocol over SOAP operati= on: 1. Elements would be processed in the order of their occurrence in the requ= est. 2. Option 1a ("stop and commit") or 1b ("stop and rollback") would be left = to the SPPF server (as a policy decision) and *not* normatively define in t= he protocol document. Following is an excerpt from the current version of SPP Protocol over SOAP = document: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=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 The elements are processed by the SPPF server in the order in which they are included in the request. With respect to handling of error conditions, it is a matter of policy whether the objects are 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 BasicObjType elements in the request at the first error and roll back any BasicObjType elements that had already been processed for that add request. In the "stop and commit" scenario the SPPF server would stop processing BasicObjType elements in the request at the first error but commit any BasicObjType elements that had already been processed for that add request. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=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 Iow, choice is already made and I don't recall this being an open item. Let= me know if I am missing something. As regards the DoS concerns, they are b= eing (or should be) discussed as a general threat for WS API operations. Mo= st public WS APIs are susceptible to DoS and as long as there is text in Se= curity Considerations to inform the implementers of this threat, that imho = should be good enough. Thanks, Vikas -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Dean Willis Sent: Tuesday, May 08, 2012 11:48 AM To: drinks@ietf.org Subject: [drinks] Thoughts on DoS issue related to "batch transactions" SPPP as currently defined allows a client to send a bundle of requests to a= server. We have an open question on what to do when one of those requests fails. Op= tions include: 1) Process the requests in the bundle sequentially, and stop the bundle whe= n one fails. a) Keep the completed requests, reject the remainder, and tell the client w= hat happened. We might call this "partial sequential completion of the bund= le". b) Roll back all completed requests, returning the server to the state at w= hich it was before the transaction started. We might call this "atomic sequ= ential completion of the bundle". 2) Process the requests in the bundle independently, notifying the client o= f each failed request. We might call this "independent completion of the bu= ndle with no guarantee of sequential processing". We started with 1a, and I suggested 1b due to the risk of leaving the serve= r content in an unexpected state. Jeremy argues in favor of 1a, on the arg= ument that rolling back a large transaction bundle is hard on a database an= d we might be introducing a DoS opportunity. But it occurs to me that if we use a model like 2, then we have the potenti= al to parallel-process requests in the bundle. This would require two thing= s; Req 1) Not structuring sequential dependencies in a bundle. For example, if= within a a request we add A, B, and C and delete B, a sequential execution= would give us a database with records A and C. Non-sequential execution mi= ght give us either a database containing A and C or a database containing A= . B, and C, and an error message that says B did not exist. Actually we do= n't have to NOT do this; we just have to be willing to live with either res= ult. Req 2) We need to be able to return multiple responses, potentially one for= each transaction in the bundle. However, what independent processing and reporting gives us is the ability = to fully parallelize and distribute the requests in a bundle. That could be= a huge performance game changer. If we choose to stay with 1b, I believe that any DoS issue could be dealth = with by describing the issue (a client can DoS the server by repeatedly is= suing large bundles with a single failing transaction at the end), and the = mitigation (since the server authenticates such requests, it can start den= ying service to an abusive client) in the security considerations section o= f the document. A 1b solution also allows some parallelization of the requests subject to a= sequential-dependency analysis, so I favor it as a potential improver of p= erformance over 1a. However, the 1a solution is by far the simplest. -- 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 alexander.mayrhofer@nic.at Tue May 15 02:55: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 80FE921F88B4 for ; Tue, 15 May 2012 02:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.708 X-Spam-Level: X-Spam-Status: No, score=-8.708 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_35=0.6, 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 K2eC+BSIlxhN for ; Tue, 15 May 2012 02:55:55 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFD821F8910 for ; Tue, 15 May 2012 02:55: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 ; Tue, 15 May 2012 11:55:52 +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, 15 May 2012 11:55:49 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: Summary of "Route Record Data Type" discussion Thread-Index: Ac0yclkiySCbd1U8QFK4iv0OsK2/1A== Date: Tue, 15 May 2012 09:55:48 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075168AE6@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] Summary of "Route Record Data Type" discussion 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: Tue, 15 May 2012 09:55:56 -0000 As agreed during last week's Design Team call, i have summarized the discus= sion around the "route record data type" (SED data) below: Originally, when we started with DRINKS (or, PEPPERMINT ;) the focus was to= create a provisioning protocol mostly for ENUM-style services, and, hence,= the data to be incorporated was mostly DNS-style data, specifically NAPTR = records (NAPTRType) and NS-style delegations (NSType). In order to accomoda= te situations in which the protocol would be used to provision LUF-only ser= vices (returning an administrative domain identifier), the URIType was adde= d, which together with an yet-to-defined URI scheme for SPID identification= would allow to enter such SPIDs into SPP. During the IETF Meeting in Paris, David Schwartz held a presentation includ= ing some considerations regarding the typing and nomenclature of those rout= e record types: http://tools.ietf.org/agenda/83/slides/slides-83-drinks-6.pdf (slides #3 to= #7) There was significant discussion around the issue, as noted in the meeting = minutes, and the topic was finally deferred to the mailing list: http://tools.ietf.org/wg/drinks/minutes?item=3Dminutes-83-drinks.html David later on proposed a change to the data model, which would provide a c= lear seperation between "target" and "location" type records: http://www.ietf.org/mail-archive/web/drinks/current/msg01152.html This proposal was then discussed extensively during the Design Team Call on= April 4. There was consensus about clarifying intent and usage, however, t= here was also some doubt that the current proposal would provide that clari= ty. There was, however, consensus that renaming route record, maybe to SED = record, was useful.=20 During that call, Dean came up with the Idea to use RFC4501 to encapsulate = the DNS data, and use URIs for all of the different record types. It was no= t immediately clear whether RFC 4501 would meet the needs. Subsequent discussion took place on the mailing list, thread starts here: http://www.ietf.org/mail-archive/web/drinks/current/msg01154.html Among other things, Dean proposed to use URIs for all "record types" and al= so drop the seperate definition of an "egress route". Therefore the open is= sue seems to split up into the following "sub-issues": 1/ Whether a distinction between "Target" and "Location" type responses (LU= F vs. LRF) would be needed on the provisioning side 2/ Whether "URI + regex" would (as the single "record type") satisfy all th= e requirements and use cases of the protocol, and hence the existing NAPTRT= ype, NSType, URIType would be merged into a single "record type".=20 3/ Whether an "egress route" would be covered by that "generic" record type= as well. 4/ Whether the "Route Record" should be renamed into "SED record" - there s= eems to be rough concensus among the Design Team members that this should b= e done. (Note that URNs are a subtype of an URI, so they would be included in the U= RI type as well). For each of those sub-issues, our options are as follows: 1/ Target/Location subtyping: 1-1/ Keep as it is (no seperation). Understand the implications and limitat= ions (as far as they affect the provisioning side, not the lookup side) 1-2/ Adopt the "split" of record type into "location" / "target" type. This= would require (besides change to the data model, XML scheme and the docume= nt in general) to agree which record types would be available under which o= f the "supertypes" of records.=20 (Personal note: I *think* that a split between location and target is only = needed *if* the same record could be used in both situations. However, as J= on said during the Paris meeting, eg. a URI can only be dereferenced in the= way it is specified for the URI scheme itself - does that still allow for = ambiguity?) 2/ URI+regex instead of all other types? 2-1/ Keep the seperate subtypes. 2-2/ Replace all sub-types with a single "URI+regex" type.=20 (Personal note: I understand that while RFC 4501 describes a URI scheme for= DNS *queries*, it does not describe a URI scheme that would allow to inclu= de DNS *data* in a URI. Therefore, i'm not sure we would be able to put NAP= TR and NS data into such a field. Also, there's a traditional concern about= the ambigiuity of "open" URI fields, particularly since the "data:" URI sc= heme allows for arbitrary data without any clear semantics) 3/ Drop "egress route" in favor of a generic "SED Type" record 3-1/ Do nothing (keep egress route - probably clarify it's use case?) 3-2/ Drop Egress route, and explain how "normal" route records can supply t= his functionality 4/ Rename "Route Record" into "SED record" 4-1/ Keep old name 4-2/ Rename I'm proposing to use the information above as a basis for tomorrow's Design= Team call - hopefully we can solve that one issue during the discussion.. Alex From kcartwright@tnsi.com Tue May 15 06:25:05 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 9E4E121F8978 for ; Tue, 15 May 2012 06:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.623 X-Spam-Level: X-Spam-Status: No, score=-0.623 tagged_above=-999 required=5 tests=[AWL=-1.357, BAYES_00=-2.599, FB_IOW=3.333] 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 c12EfdwvyffN for ; Tue, 15 May 2012 06:25:04 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8977021F8983 for ; Tue, 15 May 2012 06:25:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EABpYsk+sEQfn/2dsb2JhbABEtH+CFQEBAQQBAQE3NBcEAgEIEQQBAR8JBycLFAkIAQEEARIIE4d+uncEixwZhQRjBKlCgUM X-IronPort-AV: E=Sophos;i="4.75,595,1330905600"; d="scan'208";a="1208527" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 15 May 2012 14:25:01 +0100 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; Tue, 15 May 2012 09:25:01 -0400 From: "Cartwright, Ken" To: "Bhatia, Vikas" , Dean Willis , "drinks@ietf.org" Date: Tue, 15 May 2012 09:24:58 -0400 Thread-Topic: [drinks] Thoughts on DoS issue related to "batch transactions" Thread-Index: Ac0tMgYE/pkkZuLyTumpctGox/7YcQEytA5AAChNyuA= Message-ID: References: <0A1AD864-5663-4348-AB5F-46B61ABA83D8@softarmor.com> In-Reply-To: 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] Thoughts on DoS issue related to "batch transactions" 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: Tue, 15 May 2012 13:25:05 -0000 That is correct Vikas. -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Bhatia, Vikas Sent: Monday, May 14, 2012 2:44 PM To: Dean Willis; drinks@ietf.org Subject: Re: [drinks] Thoughts on DoS issue related to "batch transactions" W.r.t the comment "If we choose to stay with 1b,..." It is my understanding that there was general agreement on the following tw= o points for the processing of requests in a SPP Protocol over SOAP operati= on: 1. Elements would be processed in the order of their occurrence in the requ= est. 2. Option 1a ("stop and commit") or 1b ("stop and rollback") would be left = to the SPPF server (as a policy decision) and *not* normatively define in t= he protocol document. Following is an excerpt from the current version of SPP Protocol over SOAP = document: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=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 The elements are processed by the SPPF server in the order in which they are included in the request. With respect to handling of error conditions, it is a matter of policy whether the objects are 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 BasicObjType elements in the request at the first error and roll back any BasicObjType elements that had already been processed for that add request. In the "stop and commit" scenario the SPPF server would stop processing BasicObjType elements in the request at the first error but commit any BasicObjType elements that had already been processed for that add request. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=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 Iow, choice is already made and I don't recall this being an open item. Let= me know if I am missing something. As regards the DoS concerns, they are b= eing (or should be) discussed as a general threat for WS API operations. Mo= st public WS APIs are susceptible to DoS and as long as there is text in Se= curity Considerations to inform the implementers of this threat, that imho = should be good enough. Thanks, Vikas -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Dean Willis Sent: Tuesday, May 08, 2012 11:48 AM To: drinks@ietf.org Subject: [drinks] Thoughts on DoS issue related to "batch transactions" SPPP as currently defined allows a client to send a bundle of requests to a= server. We have an open question on what to do when one of those requests fails. Op= tions include: 1) Process the requests in the bundle sequentially, and stop the bundle whe= n one fails. a) Keep the completed requests, reject the remainder, and tell the client w= hat happened. We might call this "partial sequential completion of the bund= le". b) Roll back all completed requests, returning the server to the state at w= hich it was before the transaction started. We might call this "atomic sequ= ential completion of the bundle". 2) Process the requests in the bundle independently, notifying the client o= f each failed request. We might call this "independent completion of the bu= ndle with no guarantee of sequential processing". We started with 1a, and I suggested 1b due to the risk of leaving the serve= r content in an unexpected state. Jeremy argues in favor of 1a, on the arg= ument that rolling back a large transaction bundle is hard on a database an= d we might be introducing a DoS opportunity. But it occurs to me that if we use a model like 2, then we have the potenti= al to parallel-process requests in the bundle. This would require two thing= s; Req 1) Not structuring sequential dependencies in a bundle. For example, if= within a a request we add A, B, and C and delete B, a sequential execution= would give us a database with records A and C. Non-sequential execution mi= ght give us either a database containing A and C or a database containing A= . B, and C, and an error message that says B did not exist. Actually we do= n't have to NOT do this; we just have to be willing to live with either res= ult. Req 2) We need to be able to return multiple responses, potentially one for= each transaction in the bundle. However, what independent processing and reporting gives us is the ability = to fully parallelize and distribute the requests in a bundle. That could be= a huge performance game changer. If we choose to stay with 1b, I believe that any DoS issue could be dealth = with by describing the issue (a client can DoS the server by repeatedly is= suing large bundles with a single failing transaction at the end), and the = mitigation (since the server authenticates such requests, it can start den= ying service to an abusive client) in the security considerations section o= f the document. A 1b solution also allows some parallelization of the requests subject to a= sequential-dependency analysis, so I favor it as a potential improver of p= erformance over 1a. However, the 1a solution is by far the simplest. -- 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 Ser= vices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-ma= il and destroy all copies of the original message. _______________________________________________ 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 vbhatia@tnsi.com Wed May 16 06:52:14 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 753E721F85A3 for ; Wed, 16 May 2012 06:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.633 X-Spam-Level: X-Spam-Status: No, score=-0.633 tagged_above=-999 required=5 tests=[AWL=1.367, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] 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 BjUAGZJlfV3v for ; Wed, 16 May 2012 06:52:13 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 66C7C21F859F for ; Wed, 16 May 2012 06:52:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAJ2ws0+sEQfn/2dsb2JhbABEtRKCFQEBAQICAQEBNzQXBAIBCBEEAQEfCQcnCxQJCAEBBAESCAGIELsmixMZhFpiA5cLkjSBQw X-IronPort-AV: E=Sophos;i="4.75,603,1330905600"; d="scan'208";a="1212088" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 16 May 2012 14:52:11 +0100 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; Wed, 16 May 2012 09:52:12 -0400 From: "Bhatia, Vikas" To: Alexander Mayrhofer , "drinks@ietf.org" Date: Wed, 16 May 2012 09:52:09 -0400 Thread-Topic: Summary of "Route Record Data Type" discussion Thread-Index: Ac0yclkiySCbd1U8QFK4iv0OsK2/1AA9bWkw Message-ID: References: <19F54F2956911544A32543B8A9BDE075168AE6@NICS-EXCH.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE075168AE6@NICS-EXCH.sbg.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 Subject: Re: [drinks] Summary of "Route Record Data Type" discussion 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: Wed, 16 May 2012 13:52:14 -0000 Thanks Alex. This was a useful summary on the historical perspective. We can discuss on the rest, but specifically for the following: >3/ Drop "egress route" in favor of a generic "SED Type" record > >3-1/ Do nothing (keep egress route - probably clarify it's use case?) 3-2/= Drop Egress route, and explain how "normal" route records can supply this = >functionality I don't think dropping the "egress route" is an option. Not exactly sure wh= at you meant by "normal" RRs, but none of the existing Route Record types (= NAPTR, NS, URI) can fulfill the purpose of an egress route (in their curren= t form). In my view, Egress Routes have a their own specific use case. Davi= d had proposed a Route Rule concept in Paris, but after giving that a thoug= ht I don't think Route Rule and Egress Route can be mixed either (because t= hey are trying to create one structure for different use cases). In interest of putting the Egress Route debate to bed, I would propose to m= odify Egress Route definition as follows (we had discussed this during the = interim prior to last IETF and to be a general agreement - but we decided t= o wait until David's Route Rule proposal): Changes are: "ingrRteRec" changed to "ingrRteGrp" - meaning Egress Route is associated t= o a Route Group Added "svcs" element - indicates the ENUM service(s) to which Egress Route'= s "regxRewriteRule" should be applied (this will essentially drive what RRs= within the RG need to be "egressed" through this Egress Route Thanks, Vikas -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Alexander Mayrhofer Sent: Tuesday, May 15, 2012 5:56 AM To: drinks@ietf.org Subject: [drinks] Summary of "Route Record Data Type" discussion As agreed during last week's Design Team call, i have summarized the discus= sion around the "route record data type" (SED data) below: Originally, when we started with DRINKS (or, PEPPERMINT ;) the focus was to= create a provisioning protocol mostly for ENUM-style services, and, hence,= the data to be incorporated was mostly DNS-style data, specifically NAPTR = records (NAPTRType) and NS-style delegations (NSType). In order to accomoda= te situations in which the protocol would be used to provision LUF-only ser= vices (returning an administrative domain identifier), the URIType was adde= d, which together with an yet-to-defined URI scheme for SPID identification= would allow to enter such SPIDs into SPP. During the IETF Meeting in Paris, David Schwartz held a presentation includ= ing some considerations regarding the typing and nomenclature of those rout= e record types: http://tools.ietf.org/agenda/83/slides/slides-83-drinks-6.pdf (slides #3 to= #7) There was significant discussion around the issue, as noted in the meeting = minutes, and the topic was finally deferred to the mailing list: http://tools.ietf.org/wg/drinks/minutes?item=3Dminutes-83-drinks.html David later on proposed a change to the data model, which would provide a c= lear seperation between "target" and "location" type records: http://www.ietf.org/mail-archive/web/drinks/current/msg01152.html This proposal was then discussed extensively during the Design Team Call on= April 4. There was consensus about clarifying intent and usage, however, t= here was also some doubt that the current proposal would provide that clari= ty. There was, however, consensus that renaming route record, maybe to SED = record, was useful. During that call, Dean came up with the Idea to use RFC4501 to encapsulate = the DNS data, and use URIs for all of the different record types. It was no= t immediately clear whether RFC 4501 would meet the needs. Subsequent discussion took place on the mailing list, thread starts here: http://www.ietf.org/mail-archive/web/drinks/current/msg01154.html Among other things, Dean proposed to use URIs for all "record types" and al= so drop the seperate definition of an "egress route". Therefore the open is= sue seems to split up into the following "sub-issues": 1/ Whether a distinction between "Target" and "Location" type responses (LU= F vs. LRF) would be needed on the provisioning side 2/ Whether "URI + regex" would (as the single "record type") satisfy all th= e requirements and use cases of the protocol, and hence the existing NAPTRT= ype, NSType, URIType would be merged into a single "record type". 3/ Whether an "egress route" would be covered by that "generic" record type= as well. 4/ Whether the "Route Record" should be renamed into "SED record" - there s= eems to be rough concensus among the Design Team members that this should b= e done. (Note that URNs are a subtype of an URI, so they would be included in the U= RI type as well). For each of those sub-issues, our options are as follows: 1/ Target/Location subtyping: 1-1/ Keep as it is (no seperation). Understand the implications and limitat= ions (as far as they affect the provisioning side, not the lookup side) 1-2/ Adopt the "split" of record type into "location" / "target" type. This= would require (besides change to the data model, XML scheme and the docume= nt in general) to agree which record types would be available under which o= f the "supertypes" of records. (Personal note: I *think* that a split between location and target is only = needed *if* the same record could be used in both situations. However, as J= on said during the Paris meeting, eg. a URI can only be dereferenced in the= way it is specified for the URI scheme itself - does that still allow for = ambiguity?) 2/ URI+regex instead of all other types? 2-1/ Keep the seperate subtypes. 2-2/ Replace all sub-types with a single "URI+regex" type. (Personal note: I understand that while RFC 4501 describes a URI scheme for= DNS *queries*, it does not describe a URI scheme that would allow to inclu= de DNS *data* in a URI. Therefore, i'm not sure we would be able to put NAP= TR and NS data into such a field. Also, there's a traditional concern about= the ambigiuity of "open" URI fields, particularly since the "data:" URI sc= heme allows for arbitrary data without any clear semantics) 3/ Drop "egress route" in favor of a generic "SED Type" record 3-1/ Do nothing (keep egress route - probably clarify it's use case?) 3-2/ Drop Egress route, and explain how "normal" route records can supply t= his functionality 4/ Rename "Route Record" into "SED record" 4-1/ Keep old name 4-2/ Rename I'm proposing to use the information above as a basis for tomorrow's Design= Team call - hopefully we can solve that one issue during the discussion.. Alex _______________________________________________ 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 dschwartz@xconnect.net Wed May 16 06:58: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 2CB2221F864A for ; Wed, 16 May 2012 06:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] 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 LUDaqTKMxTyb for ; Wed, 16 May 2012 06:58:55 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF8721F85F7 for ; Wed, 16 May 2012 06:58:54 -0700 (PDT) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Wed, 16 May 2012 16:58:53 +0300 From: David Schwartz To: Alexander Mayrhofer Date: Wed, 16 May 2012 16:58:50 +0300 Thread-Topic: [drinks] Summary of "Route Record Data Type" discussion Thread-Index: Ac0zbAbYYZcIPpluRTGJ5JPeICBzYw== Message-ID: <9194C2EB-E865-4395-A6F5-A91C9C9C4A50@xconnect.net> References: <19F54F2956911544A32543B8A9BDE075168AE6@NICS-EXCH.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE075168AE6@NICS-EXCH.sbg.nic.at> 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_9194C2EBE8654395A6F5A91C9C9C4A50xconnectnet_" MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Summary of "Route Record Data Type" discussion 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: Wed, 16 May 2012 13:58:56 -0000 --_000_9194C2EBE8654395A6F5A91C9C9C4A50xconnectnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alex and thanks for this summary. Here are a few comments (I am copying the relevant text)... ****************** 1/ Target/Location subtyping: 1-1/ Keep as it is (no seperation). Understand the implications and limitat= ions (as far as they affect the provisioning side, not the lookup side) 1-2/ Adopt the "split" of record type into "location" / "target" type. This= would require (besides change to the data model, XML scheme and the docume= nt in general) to agree which record types would be available under which o= f the "supertypes" of records. (Personal note: I *think* that a split between location and target is only = needed *if* the same record could be used in both situations. However, as J= on said during the Paris meeting, eg. a URI can only be dereferenced in the= way it is specified for the URI scheme itself - does that still allow for = ambiguity?) DS: I agree regarding the mechanism to dereference a URI - the issue I see = is that a target is nothing more than an opaque identifier and is not deref= erenced in the first place. its not that I am worried about the question of= "how" to dereference as much as I am worried about the question of "if" to= dereference ****************** 2/ URI+regex instead of all other types? 2-1/ Keep the seperate subtypes. 2-2/ Replace all sub-types with a single "URI+regex" type. (Personal note: I understand that while RFC 4501 describes a URI scheme for= DNS *queries*, it does not describe a URI scheme that would allow to inclu= de DNS *data* in a URI. Therefore, i'm not sure we would be able to put NAP= TR and NS data into such a field. Also, there's a traditional concern about= the ambigiuity of "open" URI fields, particularly since the "data:" URI sc= heme allows for arbitrary data without any clear semantics) DS: Still wavering on this. ****************** 3/ Drop "egress route" in favor of a generic "SED Type" record 3-1/ Do nothing (keep egress route - probably clarify it's use case?) 3-2/ Drop Egress route, and explain how "normal" route records can supply t= his functionality DS: Egress route is semantically different than SED Type as its really just= a rewrite rule that is there to modify an existing SED Type so no - we can= 't just drop. All I was saying was that the name "egress" implies only one = kind of rule (that of an egress route) when in reality there are other uses= for a rewrite rule (like some peering organization specific modification) = and thus suggested we call it something more generic like "RouteRule" or no= w that Route is probably being deprecated in favor of SED --> "SEDRule" ****************** 4/ Rename "Route Record" into "SED record" 4-1/ Keep old name 4-2/ Rename DS: Rename --_000_9194C2EBE8654395A6F5A91C9C9C4A50xconnectnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Alex and thanks for this summary. 

Here are a few comments (I am copying the relevant text).= ..

<= font class=3D"Apple-style-span" size=3D"3">******************
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin= -left: 0px; font: normal normal normal 22px/normal Helvetica; color: rgb(35= , 79, 174); ">1/ Target/Locatio= n subtyping:

1-1/ Keep as it is (no seperation). Understand = the implications and limitations (as far as they affect the provisioning si= de, not the lookup side)
1-2/ Adopt the "split" of record type into "location" = / "target" type. This would require (besides change to the data model, XML = scheme and the document in general) to agree which record types would be av= ailable under which of the "supertypes" of records. 

(Personal note: I *t= hink* that a split between location and target is only needed *if* the same= record could be used in both situations. However, as Jon said during the P= aris meeting, eg. a URI can only be dereferenced in the way it is specified= for the URI scheme itself - does that still allow for ambiguity?)

DS: I agree regarding the mechanism to dereference a URI - th= e issue I see is that a target is nothing more than an opaque identifier an= d is not dereferenced in the first place. its not that I am worried about t= he question of "how" to dereference as much as I am worried about the quest= ion of "if" to dereference

******************

2/ URI+regex instead of all other types?

2-1= / Keep the seperate subtypes.
2-2/ Replace all sub-types with a single "= URI+regex" type. 

(Personal note: I understand that while RFC 4= 501 describes a URI scheme for DNS *queries*, it does not describe a URI sc= heme that would allow to include DNS *data* in a URI. Therefore, i'm not su= re we would be able to put NAPTR and NS data into such a field. Also, there= 's a traditional concern about the ambigiuity of "open" URI fields, particu= larly since the "data:" URI scheme allows for arbitrary data without any cl= ear semantics)

DS: Still wavering on this.


=
******************
3/ Drop "egress route" in favor of a generic "SED Ty= pe" record

3-1/ Do nothing (keep egress route - probably clarify it'= s use case?)
3-2/ Drop Egress route, and explain how "normal" route reco= rds can supply this functionality

DS: Egr= ess route is semantically different than SED Type as its really just a rewr= ite rule that is there to modify an existing SED Type so no - we can't just= drop. All I was saying was that the name "egress" implies only one kind of= rule (that of an egress route) when in reality there are other uses for a = rewrite rule (like some peering organization specific modification) and thu= s suggested we call it something more generic like "RouteRule" or now that = Route is probably being deprecated in favor of SED --> "SEDRule"<= /font>

******************
4/ Rename "Route Record" into "S= ED record"

4-1/ Keep old name
4-2/ Rename

<= /span>
DS: Rename
= --_000_9194C2EBE8654395A6F5A91C9C9C4A50xconnectnet_-- From dschwartz@xconnect.net Wed May 16 07:03:13 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 D345421F86A2 for ; Wed, 16 May 2012 07:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] 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 V9cRBpJQ31wm for ; Wed, 16 May 2012 07:03:13 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id 432CE21F869E for ; Wed, 16 May 2012 07:03:12 -0700 (PDT) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Wed, 16 May 2012 17:03:11 +0300 From: David Schwartz To: "Bhatia, Vikas" Date: Wed, 16 May 2012 17:03:08 +0300 Thread-Topic: [drinks] Summary of "Route Record Data Type" discussion Thread-Index: Ac0zbKBy5TdrjUJGQgeIa0G4lrIpbg== Message-ID: References: <19F54F2956911544A32543B8A9BDE075168AE6@NICS-EXCH.sbg.nic.at> In-Reply-To: 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] Summary of "Route Record Data Type" discussion 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: Wed, 16 May 2012 14:03:13 -0000 Hi Vikas I agree that it cannot be dropped as it is different from the others (see m= y previous post).=20 Regarding the issue of whether or not its modifying a single record or grou= p record I can go either way. My comment had more to do with the fact that = egressRoutes have uses other than just egress routes. :D On May 16, 2012, at 4:52 PM, Bhatia, Vikas wrote: > Thanks Alex. This was a useful summary on the historical perspective. >=20 > We can discuss on the rest, but specifically for the following: >=20 >=20 >> 3/ Drop "egress route" in favor of a generic "SED Type" record >>=20 >> 3-1/ Do nothing (keep egress route - probably clarify it's use case?) 3-= 2/ Drop Egress route, and explain how "normal" route records can supply thi= s >functionality >=20 > I don't think dropping the "egress route" is an option. Not exactly sure = what you meant by "normal" RRs, but none of the existing Route Record types= (NAPTR, NS, URI) can fulfill the purpose of an egress route (in their curr= ent form). In my view, Egress Routes have a their own specific use case. Da= vid had proposed a Route Rule concept in Paris, but after giving that a tho= ught I don't think Route Rule and Egress Route can be mixed either (because= they are trying to create one structure for different use cases). >=20 > In interest of putting the Egress Route debate to bed, I would propose to= modify Egress Route definition as follows (we had discussed this during th= e interim prior to last IETF and to be a general agreement - but we decided= to wait until David's Route Rule proposal): >=20 > > > > > > > type=3D"sppfb:RegexParamType"/> > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > minOccurs=3D"0"/> > > > > >=20 > Changes are: >=20 > "ingrRteRec" changed to "ingrRteGrp" - meaning Egress Route is associated= to a Route Group > Added "svcs" element - indicates the ENUM service(s) to which Egress Rout= e's "regxRewriteRule" should be applied (this will essentially drive what R= Rs within the RG need to be "egressed" through this Egress Route >=20 > Thanks, > Vikas >=20 >=20 > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf = Of Alexander Mayrhofer > Sent: Tuesday, May 15, 2012 5:56 AM > To: drinks@ietf.org > Subject: [drinks] Summary of "Route Record Data Type" discussion >=20 > As agreed during last week's Design Team call, i have summarized the disc= ussion around the "route record data type" (SED data) below: >=20 > Originally, when we started with DRINKS (or, PEPPERMINT ;) the focus was = to create a provisioning protocol mostly for ENUM-style services, and, henc= e, the data to be incorporated was mostly DNS-style data, specifically NAPT= R records (NAPTRType) and NS-style delegations (NSType). In order to accomo= date situations in which the protocol would be used to provision LUF-only s= ervices (returning an administrative domain identifier), the URIType was ad= ded, which together with an yet-to-defined URI scheme for SPID identificati= on would allow to enter such SPIDs into SPP. >=20 > During the IETF Meeting in Paris, David Schwartz held a presentation incl= uding some considerations regarding the typing and nomenclature of those ro= ute record types: >=20 > http://tools.ietf.org/agenda/83/slides/slides-83-drinks-6.pdf (slides #3 = to #7) >=20 > There was significant discussion around the issue, as noted in the meetin= g minutes, and the topic was finally deferred to the mailing list: >=20 > http://tools.ietf.org/wg/drinks/minutes?item=3Dminutes-83-drinks.html >=20 > David later on proposed a change to the data model, which would provide a= clear seperation between "target" and "location" type records: >=20 > http://www.ietf.org/mail-archive/web/drinks/current/msg01152.html >=20 > This proposal was then discussed extensively during the Design Team Call = on April 4. There was consensus about clarifying intent and usage, however,= there was also some doubt that the current proposal would provide that cla= rity. There was, however, consensus that renaming route record, maybe to SE= D record, was useful. >=20 > During that call, Dean came up with the Idea to use RFC4501 to encapsulat= e the DNS data, and use URIs for all of the different record types. It was = not immediately clear whether RFC 4501 would meet the needs. >=20 > Subsequent discussion took place on the mailing list, thread starts here: >=20 > http://www.ietf.org/mail-archive/web/drinks/current/msg01154.html >=20 > Among other things, Dean proposed to use URIs for all "record types" and = also drop the seperate definition of an "egress route". Therefore the open = issue seems to split up into the following "sub-issues": >=20 > 1/ Whether a distinction between "Target" and "Location" type responses (= LUF vs. LRF) would be needed on the provisioning side > 2/ Whether "URI + regex" would (as the single "record type") satisfy all = the requirements and use cases of the protocol, and hence the existing NAPT= RType, NSType, URIType would be merged into a single "record type". > 3/ Whether an "egress route" would be covered by that "generic" record ty= pe as well. > 4/ Whether the "Route Record" should be renamed into "SED record" - there= seems to be rough concensus among the Design Team members that this should= be done. >=20 > (Note that URNs are a subtype of an URI, so they would be included in the= URI type as well). >=20 > For each of those sub-issues, our options are as follows: >=20 > 1/ Target/Location subtyping: >=20 > 1-1/ Keep as it is (no seperation). Understand the implications and limit= ations (as far as they affect the provisioning side, not the lookup side) > 1-2/ Adopt the "split" of record type into "location" / "target" type. Th= is would require (besides change to the data model, XML scheme and the docu= ment in general) to agree which record types would be available under which= of the "supertypes" of records. >=20 > (Personal note: I *think* that a split between location and target is onl= y needed *if* the same record could be used in both situations. However, as= Jon said during the Paris meeting, eg. a URI can only be dereferenced in t= he way it is specified for the URI scheme itself - does that still allow fo= r ambiguity?) >=20 > 2/ URI+regex instead of all other types? >=20 > 2-1/ Keep the seperate subtypes. > 2-2/ Replace all sub-types with a single "URI+regex" type. >=20 > (Personal note: I understand that while RFC 4501 describes a URI scheme f= or DNS *queries*, it does not describe a URI scheme that would allow to inc= lude DNS *data* in a URI. Therefore, i'm not sure we would be able to put N= APTR and NS data into such a field. Also, there's a traditional concern abo= ut the ambigiuity of "open" URI fields, particularly since the "data:" URI = scheme allows for arbitrary data without any clear semantics) >=20 > 3/ Drop "egress route" in favor of a generic "SED Type" record >=20 > 3-1/ Do nothing (keep egress route - probably clarify it's use case?) > 3-2/ Drop Egress route, and explain how "normal" route records can supply= this functionality >=20 > 4/ Rename "Route Record" into "SED record" >=20 > 4-1/ Keep old name > 4-2/ Rename >=20 > I'm proposing to use the information above as a basis for tomorrow's Desi= gn Team call - hopefully we can solve that one issue during the discussion.= . >=20 > Alex >=20 >=20 > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks >=20 > This e-mail message is for the sole use of the intended recipient(s)and m= ay > contain confidential and privileged information of Transaction Network Se= rvices. > Any unauthorised review, use, disclosure or distribution is prohibited. I= f you > are not the intended recipient, please contact the sender by reply e-mail= and destroy all copies of the original message. >=20 > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks From D.Malas@cablelabs.com Wed May 16 09:40:06 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 B4D2721F8669 for ; Wed, 16 May 2012 09:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.863 X-Spam-Level: X-Spam-Status: No, score=-99.863 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_35=0.6, 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 wuuaa+nmz-2k for ; Wed, 16 May 2012 09:40:05 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id B943B21F8665 for ; Wed, 16 May 2012 09:40:05 -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 q4GGe3pA002518; Wed, 16 May 2012 10:40:04 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 16 May 2012 10:40:03 -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; Wed, 16 May 2012 10:36:15 -0600 From: Daryl Malas To: David Schwartz , "Bhatia, Vikas" Date: Wed, 16 May 2012 10:36:12 -0600 Thread-Topic: [drinks] Summary of "Route Record Data Type" discussion Thread-Index: Ac0zggKIZXz78IqdQd+vkPoPTk+jNg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "drinks@ietf.org" Subject: Re: [drinks] Summary of "Route Record Data Type" discussion 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: Wed, 16 May 2012 16:40:06 -0000 David, I have some concerns with this suggestion, "the fact that egressRoutes have uses other than just egress routes." If an egress route is used for something other than an egress route, then it ceases to be an egress route. Egress route is used specifically for that -- that's why it's called an egress route. If you want a new requirement for some other purpose, then I think it should be stated as such. We need to be careful not to overload and split hairs over semantics. If you want new functionality that is not covered by DRINKS, then propose a new requirement. The chairs can then work with the Ads to determine whether or not it is in the scope of the charter. --Daryl On 5/16/12 10:03 AM, "David Schwartz" wrote: >Hi Vikas > >I agree that it cannot be dropped as it is different from the others (see >my previous post). > >Regarding the issue of whether or not its modifying a single record or >group record I can go either way. My comment had more to do with the fact >that egressRoutes have uses other than just egress routes. > >:D > >On May 16, 2012, at 4:52 PM, Bhatia, Vikas wrote: > >> Thanks Alex. This was a useful summary on the historical perspective. >>=20 >> We can discuss on the rest, but specifically for the following: >>=20 >>=20 >>> 3/ Drop "egress route" in favor of a generic "SED Type" record >>>=20 >>> 3-1/ Do nothing (keep egress route - probably clarify it's use case?) >>>3-2/ Drop Egress route, and explain how "normal" route records can >>>supply this >functionality >>=20 >> I don't think dropping the "egress route" is an option. Not exactly >>sure what you meant by "normal" RRs, but none of the existing Route >>Record types (NAPTR, NS, URI) can fulfill the purpose of an egress route >>(in their current form). In my view, Egress Routes have a their own >>specific use case. David had proposed a Route Rule concept in Paris, but >>after giving that a thought I don't think Route Rule and Egress Route >>can be mixed either (because they are trying to create one structure for >>different use cases). >>=20 >> In interest of putting the Egress Route debate to bed, I would propose >>to modify Egress Route definition as follows (we had discussed this >>during the interim prior to last IETF and to be a general agreement - >>but we decided to wait until David's Route Rule proposal): >>=20 >> >> >> >> >> >> >> > type=3D"sppfb:RegexParamType"/> >> > minOccurs=3D"0" maxOccurs=3D"unbounded"/> >> >minOccurs=3D"0"/> >> > minOccurs=3D"0"/> >> >> >> >> >>=20 >> Changes are: >>=20 >> "ingrRteRec" changed to "ingrRteGrp" - meaning Egress Route is >>associated to a Route Group >> Added "svcs" element - indicates the ENUM service(s) to which Egress >>Route's "regxRewriteRule" should be applied (this will essentially drive >>what RRs within the RG need to be "egressed" through this Egress Route >>=20 >> Thanks, >> Vikas >>=20 >>=20 >> -----Original Message----- >> From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On >>Behalf Of Alexander Mayrhofer >> Sent: Tuesday, May 15, 2012 5:56 AM >> To: drinks@ietf.org >> Subject: [drinks] Summary of "Route Record Data Type" discussion >>=20 >> As agreed during last week's Design Team call, i have summarized the >>discussion around the "route record data type" (SED data) below: >>=20 >> Originally, when we started with DRINKS (or, PEPPERMINT ;) the focus >>was to create a provisioning protocol mostly for ENUM-style services, >>and, hence, the data to be incorporated was mostly DNS-style data, >>specifically NAPTR records (NAPTRType) and NS-style delegations >>(NSType). In order to accomodate situations in which the protocol would >>be used to provision LUF-only services (returning an administrative >>domain identifier), the URIType was added, which together with an >>yet-to-defined URI scheme for SPID identification would allow to enter >>such SPIDs into SPP. >>=20 >> During the IETF Meeting in Paris, David Schwartz held a presentation >>including some considerations regarding the typing and nomenclature of >>those route record types: >>=20 >> http://tools.ietf.org/agenda/83/slides/slides-83-drinks-6.pdf (slides >>#3 to #7) >>=20 >> There was significant discussion around the issue, as noted in the >>meeting minutes, and the topic was finally deferred to the mailing list: >>=20 >> http://tools.ietf.org/wg/drinks/minutes?item=3Dminutes-83-drinks.html >>=20 >> David later on proposed a change to the data model, which would provide >>a clear seperation between "target" and "location" type records: >>=20 >> http://www.ietf.org/mail-archive/web/drinks/current/msg01152.html >>=20 >> This proposal was then discussed extensively during the Design Team >>Call on April 4. There was consensus about clarifying intent and usage, >>however, there was also some doubt that the current proposal would >>provide that clarity. There was, however, consensus that renaming route >>record, maybe to SED record, was useful. >>=20 >> During that call, Dean came up with the Idea to use RFC4501 to >>encapsulate the DNS data, and use URIs for all of the different record >>types. It was not immediately clear whether RFC 4501 would meet the >>needs. >>=20 >> Subsequent discussion took place on the mailing list, thread starts >>here: >>=20 >> http://www.ietf.org/mail-archive/web/drinks/current/msg01154.html >>=20 >> Among other things, Dean proposed to use URIs for all "record types" >>and also drop the seperate definition of an "egress route". Therefore >>the open issue seems to split up into the following "sub-issues": >>=20 >> 1/ Whether a distinction between "Target" and "Location" type responses >>(LUF vs. LRF) would be needed on the provisioning side >> 2/ Whether "URI + regex" would (as the single "record type") satisfy >>all the requirements and use cases of the protocol, and hence the >>existing NAPTRType, NSType, URIType would be merged into a single >>"record type". >> 3/ Whether an "egress route" would be covered by that "generic" record >>type as well. >> 4/ Whether the "Route Record" should be renamed into "SED record" - >>there seems to be rough concensus among the Design Team members that >>this should be done. >>=20 >> (Note that URNs are a subtype of an URI, so they would be included in >>the URI type as well). >>=20 >> For each of those sub-issues, our options are as follows: >>=20 >> 1/ Target/Location subtyping: >>=20 >> 1-1/ Keep as it is (no seperation). Understand the implications and >>limitations (as far as they affect the provisioning side, not the lookup >>side) >> 1-2/ Adopt the "split" of record type into "location" / "target" type. >>This would require (besides change to the data model, XML scheme and the >>document in general) to agree which record types would be available >>under which of the "supertypes" of records. >>=20 >> (Personal note: I *think* that a split between location and target is >>only needed *if* the same record could be used in both situations. >>However, as Jon said during the Paris meeting, eg. a URI can only be >>dereferenced in the way it is specified for the URI scheme itself - does >>that still allow for ambiguity?) >>=20 >> 2/ URI+regex instead of all other types? >>=20 >> 2-1/ Keep the seperate subtypes. >> 2-2/ Replace all sub-types with a single "URI+regex" type. >>=20 >> (Personal note: I understand that while RFC 4501 describes a URI scheme >>for DNS *queries*, it does not describe a URI scheme that would allow to >>include DNS *data* in a URI. Therefore, i'm not sure we would be able to >>put NAPTR and NS data into such a field. Also, there's a traditional >>concern about the ambigiuity of "open" URI fields, particularly since >>the "data:" URI scheme allows for arbitrary data without any clear >>semantics) >>=20 >> 3/ Drop "egress route" in favor of a generic "SED Type" record >>=20 >> 3-1/ Do nothing (keep egress route - probably clarify it's use case?) >> 3-2/ Drop Egress route, and explain how "normal" route records can >>supply this functionality >>=20 >> 4/ Rename "Route Record" into "SED record" >>=20 >> 4-1/ Keep old name >> 4-2/ Rename >>=20 >> I'm proposing to use the information above as a basis for tomorrow's >>Design Team call - hopefully we can solve that one issue during the >>discussion.. >>=20 >> Alex >>=20 >>=20 >> _______________________________________________ >> drinks mailing list >> drinks@ietf.org >> https://www.ietf.org/mailman/listinfo/drinks >>=20 >> This e-mail message is for the sole use of the intended recipient(s)and >>may >> contain confidential and privileged information of Transaction Network >>Services. >> Any unauthorised review, use, disclosure or distribution is prohibited. >>If you >> are not the intended recipient, please contact the sender by reply >>e-mail and destroy all copies of the original message. >>=20 >> _______________________________________________ >> drinks mailing list >> drinks@ietf.org >> https://www.ietf.org/mailman/listinfo/drinks > >_______________________________________________ >drinks mailing list >drinks@ietf.org >https://www.ietf.org/mailman/listinfo/drinks From dschwartz@xconnect.net Wed May 16 09:50:15 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 CCF3121F86D6 for ; Wed, 16 May 2012 09:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.805 X-Spam-Level: X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] 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 GBg7z2GwZbUd for ; Wed, 16 May 2012 09:50:14 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1F18F21F86C3 for ; Wed, 16 May 2012 09:50:14 -0700 (PDT) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Wed, 16 May 2012 19:50:13 +0300 From: David Schwartz To: Daryl Malas Date: Wed, 16 May 2012 19:50:11 +0300 Thread-Topic: [drinks] Summary of "Route Record Data Type" discussion Thread-Index: Ac0zg/ZCSnRNQS3+Q0Sf8UOd8eIbLA== Message-ID: References: In-Reply-To: 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] Summary of "Route Record Data Type" discussion 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: Wed, 16 May 2012 16:50:16 -0000 Hi Daryl I am sorry for not being precise.=20 Modifying routes via regular expressions is not unique to egress routes and= as such I feel that the name should be changed to a more generic RouteRewr= iteRule or SEDRewriteRule as opposed to EgressRoute. I think the name Egers= sRoute is an unfortunate choice as it defines a use case more so than a dat= a type. Additionally, egress routes are not really shareable (by definition= two peering orgs cannot have the same egress route raising the question as= to what this construct is doing in a shared registry) as opposed to routeR= ewriteRules which are.=20 :D On May 16, 2012, at 7:36 PM, Daryl Malas wrote: > David, >=20 > I have some concerns with this suggestion, "the fact that egressRoutes > have uses other than just egress routes." If an egress route is used for > something other than an egress route, then it ceases to be an egress > route. Egress route is used specifically for that -- that's why it's > called an egress route. If you want a new requirement for some other > purpose, then I think it should be stated as such. We need to be careful > not to overload and split hairs over semantics. If you want new > functionality that is not covered by DRINKS, then propose a new > requirement. The chairs can then work with the Ads to determine whether > or not it is in the scope of the charter. >=20 > --Daryl >=20 > On 5/16/12 10:03 AM, "David Schwartz" wrote: >=20 >> Hi Vikas >>=20 >> I agree that it cannot be dropped as it is different from the others (se= e >> my previous post). >>=20 >> Regarding the issue of whether or not its modifying a single record or >> group record I can go either way. My comment had more to do with the fac= t >> that egressRoutes have uses other than just egress routes. >>=20 >> :D >>=20 >> On May 16, 2012, at 4:52 PM, Bhatia, Vikas wrote: >>=20 >>> Thanks Alex. This was a useful summary on the historical perspective. >>>=20 >>> We can discuss on the rest, but specifically for the following: >>>=20 >>>=20 >>>> 3/ Drop "egress route" in favor of a generic "SED Type" record >>>>=20 >>>> 3-1/ Do nothing (keep egress route - probably clarify it's use case?) >>>> 3-2/ Drop Egress route, and explain how "normal" route records can >>>> supply this >functionality >>>=20 >>> I don't think dropping the "egress route" is an option. Not exactly >>> sure what you meant by "normal" RRs, but none of the existing Route >>> Record types (NAPTR, NS, URI) can fulfill the purpose of an egress rout= e >>> (in their current form). In my view, Egress Routes have a their own >>> specific use case. David had proposed a Route Rule concept in Paris, bu= t >>> after giving that a thought I don't think Route Rule and Egress Route >>> can be mixed either (because they are trying to create one structure fo= r >>> different use cases). >>>=20 >>> In interest of putting the Egress Route debate to bed, I would propose >>> to modify Egress Route definition as follows (we had discussed this >>> during the interim prior to last IETF and to be a general agreement - >>> but we decided to wait until David's Route Rule proposal): >>>=20 >>> >>> >>> >>> >>> >>> >>> >> type=3D"sppfb:RegexParamType"/> >>> >> minOccurs=3D"0" maxOccurs=3D"unbounded"/> >>> >> minOccurs=3D"0"/> >>> >> minOccurs=3D"0"/> >>> >>> >>> >>> >>>=20 >>> Changes are: >>>=20 >>> "ingrRteRec" changed to "ingrRteGrp" - meaning Egress Route is >>> associated to a Route Group >>> Added "svcs" element - indicates the ENUM service(s) to which Egress >>> Route's "regxRewriteRule" should be applied (this will essentially driv= e >>> what RRs within the RG need to be "egressed" through this Egress Route >>>=20 >>> Thanks, >>> Vikas >>>=20 >>>=20 >>> -----Original Message----- >>> From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On >>> Behalf Of Alexander Mayrhofer >>> Sent: Tuesday, May 15, 2012 5:56 AM >>> To: drinks@ietf.org >>> Subject: [drinks] Summary of "Route Record Data Type" discussion >>>=20 >>> As agreed during last week's Design Team call, i have summarized the >>> discussion around the "route record data type" (SED data) below: >>>=20 >>> Originally, when we started with DRINKS (or, PEPPERMINT ;) the focus >>> was to create a provisioning protocol mostly for ENUM-style services, >>> and, hence, the data to be incorporated was mostly DNS-style data, >>> specifically NAPTR records (NAPTRType) and NS-style delegations >>> (NSType). In order to accomodate situations in which the protocol would >>> be used to provision LUF-only services (returning an administrative >>> domain identifier), the URIType was added, which together with an >>> yet-to-defined URI scheme for SPID identification would allow to enter >>> such SPIDs into SPP. >>>=20 >>> During the IETF Meeting in Paris, David Schwartz held a presentation >>> including some considerations regarding the typing and nomenclature of >>> those route record types: >>>=20 >>> http://tools.ietf.org/agenda/83/slides/slides-83-drinks-6.pdf (slides >>> #3 to #7) >>>=20 >>> There was significant discussion around the issue, as noted in the >>> meeting minutes, and the topic was finally deferred to the mailing list= : >>>=20 >>> http://tools.ietf.org/wg/drinks/minutes?item=3Dminutes-83-drinks.html >>>=20 >>> David later on proposed a change to the data model, which would provide >>> a clear seperation between "target" and "location" type records: >>>=20 >>> http://www.ietf.org/mail-archive/web/drinks/current/msg01152.html >>>=20 >>> This proposal was then discussed extensively during the Design Team >>> Call on April 4. There was consensus about clarifying intent and usage, >>> however, there was also some doubt that the current proposal would >>> provide that clarity. There was, however, consensus that renaming route >>> record, maybe to SED record, was useful. >>>=20 >>> During that call, Dean came up with the Idea to use RFC4501 to >>> encapsulate the DNS data, and use URIs for all of the different record >>> types. It was not immediately clear whether RFC 4501 would meet the >>> needs. >>>=20 >>> Subsequent discussion took place on the mailing list, thread starts >>> here: >>>=20 >>> http://www.ietf.org/mail-archive/web/drinks/current/msg01154.html >>>=20 >>> Among other things, Dean proposed to use URIs for all "record types" >>> and also drop the seperate definition of an "egress route". Therefore >>> the open issue seems to split up into the following "sub-issues": >>>=20 >>> 1/ Whether a distinction between "Target" and "Location" type responses >>> (LUF vs. LRF) would be needed on the provisioning side >>> 2/ Whether "URI + regex" would (as the single "record type") satisfy >>> all the requirements and use cases of the protocol, and hence the >>> existing NAPTRType, NSType, URIType would be merged into a single >>> "record type". >>> 3/ Whether an "egress route" would be covered by that "generic" record >>> type as well. >>> 4/ Whether the "Route Record" should be renamed into "SED record" - >>> there seems to be rough concensus among the Design Team members that >>> this should be done. >>>=20 >>> (Note that URNs are a subtype of an URI, so they would be included in >>> the URI type as well). >>>=20 >>> For each of those sub-issues, our options are as follows: >>>=20 >>> 1/ Target/Location subtyping: >>>=20 >>> 1-1/ Keep as it is (no seperation). Understand the implications and >>> limitations (as far as they affect the provisioning side, not the looku= p >>> side) >>> 1-2/ Adopt the "split" of record type into "location" / "target" type. >>> This would require (besides change to the data model, XML scheme and th= e >>> document in general) to agree which record types would be available >>> under which of the "supertypes" of records. >>>=20 >>> (Personal note: I *think* that a split between location and target is >>> only needed *if* the same record could be used in both situations. >>> However, as Jon said during the Paris meeting, eg. a URI can only be >>> dereferenced in the way it is specified for the URI scheme itself - doe= s >>> that still allow for ambiguity?) >>>=20 >>> 2/ URI+regex instead of all other types? >>>=20 >>> 2-1/ Keep the seperate subtypes. >>> 2-2/ Replace all sub-types with a single "URI+regex" type. >>>=20 >>> (Personal note: I understand that while RFC 4501 describes a URI scheme >>> for DNS *queries*, it does not describe a URI scheme that would allow t= o >>> include DNS *data* in a URI. Therefore, i'm not sure we would be able t= o >>> put NAPTR and NS data into such a field. Also, there's a traditional >>> concern about the ambigiuity of "open" URI fields, particularly since >>> the "data:" URI scheme allows for arbitrary data without any clear >>> semantics) >>>=20 >>> 3/ Drop "egress route" in favor of a generic "SED Type" record >>>=20 >>> 3-1/ Do nothing (keep egress route - probably clarify it's use case?) >>> 3-2/ Drop Egress route, and explain how "normal" route records can >>> supply this functionality >>>=20 >>> 4/ Rename "Route Record" into "SED record" >>>=20 >>> 4-1/ Keep old name >>> 4-2/ Rename >>>=20 >>> I'm proposing to use the information above as a basis for tomorrow's >>> Design Team call - hopefully we can solve that one issue during the >>> discussion.. >>>=20 >>> Alex >>>=20 >>>=20 >>> _______________________________________________ >>> drinks mailing list >>> drinks@ietf.org >>> https://www.ietf.org/mailman/listinfo/drinks >>>=20 >>> This e-mail message is for the sole use of the intended recipient(s)and >>> may >>> contain confidential and privileged information of Transaction Network >>> Services. >>> Any unauthorised review, use, disclosure or distribution is prohibited. >>> If you >>> are not the intended recipient, please contact the sender by reply >>> e-mail and destroy all copies of the original message. >>>=20 >>> _______________________________________________ >>> drinks mailing list >>> drinks@ietf.org >>> https://www.ietf.org/mailman/listinfo/drinks >>=20 >> _______________________________________________ >> drinks mailing list >> drinks@ietf.org >> https://www.ietf.org/mailman/listinfo/drinks >=20 From vbhatia@tnsi.com Wed May 16 20:59:21 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 0282711E808F for ; Wed, 16 May 2012 20:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.016 X-Spam-Level: X-Spam-Status: No, score=-1.016 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_35=0.6] 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 l2cLuSvgTZp3 for ; Wed, 16 May 2012 20:59:20 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAAA11E8089 for ; Wed, 16 May 2012 20:59:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAMF2tE+sEQfn/2dsb2JhbABEtROCFQEBAQIBAQEBATc0CwUHBAIBCA4DBAEBAR4JBycLFAkIAQEEAQ0FCAGIABC8AYsTGYRcYgOXC5I0gUM X-IronPort-AV: E=Sophos;i="4.75,607,1330905600"; d="scan'208";a="1214356" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 17 May 2012 04:59:17 +0100 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; Wed, 16 May 2012 23:59:17 -0400 From: "Bhatia, Vikas" To: David Schwartz , "d.malas@cablelabs.com" Date: Wed, 16 May 2012 23:59:15 -0400 Thread-Topic: [drinks] Summary of "Route Record Data Type" discussion Thread-Index: Ac0zg/ZCSnRNQS3+Q0Sf8UOd8eIbLAAU/pBw Message-ID: References: In-Reply-To: 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] Summary of "Route Record Data Type" discussion 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, 17 May 2012 03:59:21 -0000 David, W.r.t the comment "as such I feel that the name should be changed to a mor= e generic RouteRewriteRule or SEDRewriteRule as opposed to EgressRoute" -From what was proposed back in Paris (http://tools.ietf.org/agenda/83/slid= es/slides-83-drinks-6.pdf), it was not just a name change. Along with the n= ame change from "EgrRteType" to "RteRuleType", there was an additional elem= ent introduced into --as proposed-- "RteRuleType" definition called "peerin= gOrg" - which along with the name change, significantly changes the semanti= cs of this structure and makes it quite ambiguous imo. That is where my fir= st and main concern is. Egress Routes are specific to an organization and d= o not have any peeringOrgs. Egress Routes solve a very specific use case of= determining what Egress points within the operator's network are to be use= d for particular RR(s) within a RG (which may have been granted by a peerin= gOrg any way). What does it mean to have the proposed "RteRuleType" that ha= s both a peeringOrg and a RR(or RG)? That leads to my second concern, which= is that the actors are different as well. Egress Route rewrite regex will = always be created by a peering org that is the recipient of a RG offer (to = whom the route has been offered), whereas in your new use case of "like som= e peering organization specific modification" of the route, rule will be cr= eated by the peering org that has offered the route to various peers. Imho, we are trying to create this generic structure to accommodate a diffe= rent use case which muddles up and solves none of the use cases properly. I= f at all this has to be done, then structurally we probably would have a ba= se RteRuleType, and then two derived types - one for Egress Route Rule and = another derived type (for the new/different use case you have brought up). = If we all want to take on this additional use case, then we can consider go= ing this path. W.r.t the comment " the question as to what this construct is doing in a sh= ared registry.." I am not sure if I understand this comment very well. Can you please elabor= ate? I thought this basic question of what Egress Route construct is doing = in this registry should be have been discussed and agreed long back. Thanks. Vikas -----Original Message----- From: David Schwartz [mailto:dschwartz@xconnect.net] Sent: Wednesday, May 16, 2012 12:50 PM To: d.malas@cablelabs.com Cc: Bhatia, Vikas; drinks@ietf.org Subject: Re: [drinks] Summary of "Route Record Data Type" discussion Hi Daryl I am sorry for not being precise. Modifying routes via regular expressions is not unique to egress routes and= as such I feel that the name should be changed to a more generic RouteRewr= iteRule or SEDRewriteRule as opposed to EgressRoute. I think the name Egers= sRoute is an unfortunate choice as it defines a use case more so than a dat= a type. Additionally, egress routes are not really shareable (by definition= two peering orgs cannot have the same egress route raising the question as= to what this construct is doing in a shared registry) as opposed to routeR= ewriteRules which are. :D On May 16, 2012, at 7:36 PM, Daryl Malas wrote: > David, > > I have some concerns with this suggestion, "the fact that egressRoutes > have uses other than just egress routes." If an egress route is used for > something other than an egress route, then it ceases to be an egress > route. Egress route is used specifically for that -- that's why it's > called an egress route. If you want a new requirement for some other > purpose, then I think it should be stated as such. We need to be careful > not to overload and split hairs over semantics. If you want new > functionality that is not covered by DRINKS, then propose a new > requirement. The chairs can then work with the Ads to determine whether > or not it is in the scope of the charter. > > --Daryl > > On 5/16/12 10:03 AM, "David Schwartz" wrote: > >> Hi Vikas >> >> I agree that it cannot be dropped as it is different from the others (se= e >> my previous post). >> >> Regarding the issue of whether or not its modifying a single record or >> group record I can go either way. My comment had more to do with the fac= t >> that egressRoutes have uses other than just egress routes. >> >> :D >> >> On May 16, 2012, at 4:52 PM, Bhatia, Vikas wrote: >> >>> Thanks Alex. This was a useful summary on the historical perspective. >>> >>> We can discuss on the rest, but specifically for the following: >>> >>> >>>> 3/ Drop "egress route" in favor of a generic "SED Type" record >>>> >>>> 3-1/ Do nothing (keep egress route - probably clarify it's use case?) >>>> 3-2/ Drop Egress route, and explain how "normal" route records can >>>> supply this >functionality >>> >>> I don't think dropping the "egress route" is an option. Not exactly >>> sure what you meant by "normal" RRs, but none of the existing Route >>> Record types (NAPTR, NS, URI) can fulfill the purpose of an egress rout= e >>> (in their current form). In my view, Egress Routes have a their own >>> specific use case. David had proposed a Route Rule concept in Paris, bu= t >>> after giving that a thought I don't think Route Rule and Egress Route >>> can be mixed either (because they are trying to create one structure fo= r >>> different use cases). >>> >>> In interest of putting the Egress Route debate to bed, I would propose >>> to modify Egress Route definition as follows (we had discussed this >>> during the interim prior to last IETF and to be a general agreement - >>> but we decided to wait until David's Route Rule proposal): >>> >>> >>> >>> >>> >>> >>> >>> >> type=3D"sppfb:RegexParamType"/> >>> >> minOccurs=3D"0" maxOccurs=3D"unbounded"/> >>> >> minOccurs=3D"0"/> >>> >> minOccurs=3D"0"/> >>> >>> >>> >>> >>> >>> Changes are: >>> >>> "ingrRteRec" changed to "ingrRteGrp" - meaning Egress Route is >>> associated to a Route Group >>> Added "svcs" element - indicates the ENUM service(s) to which Egress >>> Route's "regxRewriteRule" should be applied (this will essentially driv= e >>> what RRs within the RG need to be "egressed" through this Egress Route >>> >>> Thanks, >>> Vikas >>> >>> >>> -----Original Message----- >>> From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On >>> Behalf Of Alexander Mayrhofer >>> Sent: Tuesday, May 15, 2012 5:56 AM >>> To: drinks@ietf.org >>> Subject: [drinks] Summary of "Route Record Data Type" discussion >>> >>> As agreed during last week's Design Team call, i have summarized the >>> discussion around the "route record data type" (SED data) below: >>> >>> Originally, when we started with DRINKS (or, PEPPERMINT ;) the focus >>> was to create a provisioning protocol mostly for ENUM-style services, >>> and, hence, the data to be incorporated was mostly DNS-style data, >>> specifically NAPTR records (NAPTRType) and NS-style delegations >>> (NSType). In order to accomodate situations in which the protocol would >>> be used to provision LUF-only services (returning an administrative >>> domain identifier), the URIType was added, which together with an >>> yet-to-defined URI scheme for SPID identification would allow to enter >>> such SPIDs into SPP. >>> >>> During the IETF Meeting in Paris, David Schwartz held a presentation >>> including some considerations regarding the typing and nomenclature of >>> those route record types: >>> >>> http://tools.ietf.org/agenda/83/slides/slides-83-drinks-6.pdf (slides >>> #3 to #7) >>> >>> There was significant discussion around the issue, as noted in the >>> meeting minutes, and the topic was finally deferred to the mailing list= : >>> >>> http://tools.ietf.org/wg/drinks/minutes?item=3Dminutes-83-drinks.html >>> >>> David later on proposed a change to the data model, which would provide >>> a clear seperation between "target" and "location" type records: >>> >>> http://www.ietf.org/mail-archive/web/drinks/current/msg01152.html >>> >>> This proposal was then discussed extensively during the Design Team >>> Call on April 4. There was consensus about clarifying intent and usage, >>> however, there was also some doubt that the current proposal would >>> provide that clarity. There was, however, consensus that renaming route >>> record, maybe to SED record, was useful. >>> >>> During that call, Dean came up with the Idea to use RFC4501 to >>> encapsulate the DNS data, and use URIs for all of the different record >>> types. It was not immediately clear whether RFC 4501 would meet the >>> needs. >>> >>> Subsequent discussion took place on the mailing list, thread starts >>> here: >>> >>> http://www.ietf.org/mail-archive/web/drinks/current/msg01154.html >>> >>> Among other things, Dean proposed to use URIs for all "record types" >>> and also drop the seperate definition of an "egress route". Therefore >>> the open issue seems to split up into the following "sub-issues": >>> >>> 1/ Whether a distinction between "Target" and "Location" type responses >>> (LUF vs. LRF) would be needed on the provisioning side >>> 2/ Whether "URI + regex" would (as the single "record type") satisfy >>> all the requirements and use cases of the protocol, and hence the >>> existing NAPTRType, NSType, URIType would be merged into a single >>> "record type". >>> 3/ Whether an "egress route" would be covered by that "generic" record >>> type as well. >>> 4/ Whether the "Route Record" should be renamed into "SED record" - >>> there seems to be rough concensus among the Design Team members that >>> this should be done. >>> >>> (Note that URNs are a subtype of an URI, so they would be included in >>> the URI type as well). >>> >>> For each of those sub-issues, our options are as follows: >>> >>> 1/ Target/Location subtyping: >>> >>> 1-1/ Keep as it is (no seperation). Understand the implications and >>> limitations (as far as they affect the provisioning side, not the looku= p >>> side) >>> 1-2/ Adopt the "split" of record type into "location" / "target" type. >>> This would require (besides change to the data model, XML scheme and th= e >>> document in general) to agree which record types would be available >>> under which of the "supertypes" of records. >>> >>> (Personal note: I *think* that a split between location and target is >>> only needed *if* the same record could be used in both situations. >>> However, as Jon said during the Paris meeting, eg. a URI can only be >>> dereferenced in the way it is specified for the URI scheme itself - doe= s >>> that still allow for ambiguity?) >>> >>> 2/ URI+regex instead of all other types? >>> >>> 2-1/ Keep the seperate subtypes. >>> 2-2/ Replace all sub-types with a single "URI+regex" type. >>> >>> (Personal note: I understand that while RFC 4501 describes a URI scheme >>> for DNS *queries*, it does not describe a URI scheme that would allow t= o >>> include DNS *data* in a URI. Therefore, i'm not sure we would be able t= o >>> put NAPTR and NS data into such a field. Also, there's a traditional >>> concern about the ambigiuity of "open" URI fields, particularly since >>> the "data:" URI scheme allows for arbitrary data without any clear >>> semantics) >>> >>> 3/ Drop "egress route" in favor of a generic "SED Type" record >>> >>> 3-1/ Do nothing (keep egress route - probably clarify it's use case?) >>> 3-2/ Drop Egress route, and explain how "normal" route records can >>> supply this functionality >>> >>> 4/ Rename "Route Record" into "SED record" >>> >>> 4-1/ Keep old name >>> 4-2/ Rename >>> >>> I'm proposing to use the information above as a basis for tomorrow's >>> Design Team call - hopefully we can solve that one issue during the >>> discussion.. >>> >>> Alex >>> >>> >>> _______________________________________________ >>> drinks mailing list >>> drinks@ietf.org >>> https://www.ietf.org/mailman/listinfo/drinks >>> >>> This e-mail message is for the sole use of the intended recipient(s)and >>> may >>> contain confidential and privileged information of Transaction Network >>> Services. >>> Any unauthorised review, use, disclosure or distribution is prohibited. >>> If you >>> are not the intended recipient, please contact the sender by reply >>> e-mail and destroy all copies of the original message. >>> >>> _______________________________________________ >>> drinks mailing list >>> drinks@ietf.org >>> https://www.ietf.org/mailman/listinfo/drinks >> >> _______________________________________________ >> 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 alexander.mayrhofer@nic.at Mon May 21 05:40:18 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 AD0AD21F8619 for ; Mon, 21 May 2012 05:40:18 -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 rfzVHt78A44z for ; Mon, 21 May 2012 05:40:17 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id CD83121F84B2 for ; Mon, 21 May 2012 05:40:13 -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 ; Mon, 21 May 2012 14:40:12 +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; Mon, 21 May 2012 14:40:09 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: DRAFT Minutes of the DRINKS design team call on May 16 2012 Thread-Index: Ac03TtnvYNdTQEnNQe6Muwrg2wxbdQ== Date: Mon, 21 May 2012 12:40:08 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE07516C74E@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 of the DRINKS design team call on May 16 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: Mon, 21 May 2012 12:40:18 -0000 DRINKS DESIGN Team Call DRAFT minutes May 16 2012 10am-11am EST =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Dean Willis - Vikas Bhatia - Manjul Maharishi - David Schwartz (on Skype with Dean) - Alexander Mayrhofer Apologies: - Syed Ali - Ken Cartwright - Sumanth Channabasappa=20 ACTION ITEMS ------------ - Continue discussion of "route group / data type" open issue. - Describe issue denial of service considerations (added during Paris) =3D>= Ken=20 - Describe issue peering / route group offer generalization =3D> Sumanth - Describe issue internationalization =3D> Alex Agenda ------ 1/ Work on documented open issues Minutes of the call ------------------- Alex describes/lists the action items from last week, four open issues=20 were to be summarized. Alex has created a summary of the "Data Type / Recor= d Type" discussion. There were responses sent to Alex' email on the WG mailing list. =3D=3D Egress route Vikas explains: egress route discussion was brought up during the=20 interim before paris, association with rtgrp rather than rtrec. Vikas: mixing egress route with route rule thing is not a good thing. One o= r=20 the other Alex: Egress routes seem to be SP-internal - why share them via the registr= y? Dean: channels that david thinks that ergress route is an=20 "rewriting mechanism" only, "location" / "target" thing is=20 independent from the egress route. David says that since egress routes cannot be shared, we should=20 replace that egress routes with a more generic rewriting rule.=20 david argues that the generic route rule could be used as some=20 kind of egress route. Dean: re-iterating Alex's question: If you don't share it, why put=20 it into the registry? Alex: registry as mechanism to share info *within* the SP's network?=20 Also, Concerned that adding new things all the time would delay documents. "Hum": Keeping egress route instead the generic route rule thing is preferr= ed=20 by Vikas, Manjul and Alex, Dean said he doesn't know. =3D=3D Renaming route rec to SED rec vikas: has a feeling that renaming is not worth because we would risk=20 to miss some spots on the document. It's just a name. Discussion around proposed re-structuring of RteRecType into SEDType. This is not trying to solve the limitations of ENUM and or SIP (distinguish= =20 between "target" and "location" type ENUM records, for example). discussion around "location / target" split: Some URI schemes clearly targe= t=20 (eg. URN with GSPID), some could be both (SIP), but for those dereferencing= =20 should define what to do. Alex: Splitting in input only makes sense when output channel (lookup proto= col)=20 allows distinguish those categories as well - otherwise info getting lost. No clear conclusion on the open action item. Call concludes after one hour. From dschwartz@xconnect.net Tue May 22 01:45:01 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 36B1321F84FC for ; Tue, 22 May 2012 01:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_35=0.6] 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 k53I3-hheDWO for ; Tue, 22 May 2012 01:45:00 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6AF21F84FB for ; Tue, 22 May 2012 01:44:59 -0700 (PDT) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Tue, 22 May 2012 11:44:57 +0300 From: David Schwartz To: "Bhatia, Vikas" Date: Tue, 22 May 2012 11:44:59 +0300 Thread-Topic: [drinks] Summary of "Route Record Data Type" discussion Thread-Index: Ac039yoBWFx0uHXERWS8TxiYIcYpcw== Message-ID: References: In-Reply-To: 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] Summary of "Route Record Data Type" discussion 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: Tue, 22 May 2012 08:45:01 -0000 Hi Vikas and sorry for delay in responding to this. I only noticed this was= in my inbox today. Comments inline... On May 17, 2012, at 6:59 AM, Bhatia, Vikas wrote: > David, > > W.r.t the comment "as such I feel that the name should be changed to a m= ore generic RouteRewriteRule or SEDRewriteRule as opposed to EgressRoute" > > -From what was proposed back in Paris (http://tools.ietf.org/agenda/83/sl= ides/slides-83-drinks-6.pdf), it was not just a name change. Along with the= name change from "EgrRteType" to "RteRuleType", there was an additional el= ement introduced into --as proposed-- "RteRuleType" definition called "peer= ingOrg" - which along with the name change, significantly changes the seman= tics of this structure and makes it quite ambiguous imo. DS: If anything, having an element named PeeringOrg makes things more expli= cit. Let me try to be more specific. By definition, the egress route (other= than the actual rewrite rule) has two pieces of information that need to b= e specified: (1) which route does this rewrite rule apply to and (2) for wh= om does this rule apply. The egress route solves (2) by simply having the o= rganization needing this route modification provision (rant) the egress rou= te. In a sense the "rant" of the egress route is not the owner of the route= - but the owner of the modification rule so that instead of using the peer= ingOrg construct (which is there to define origination type stuff) for (2) = it uses the rant for the same purpose which imho introduces more confusion = (and I am aware that you can argue that rant is about "ownership" of things= - not just routes or numbers but rules as well - still this is fuzzy). The= mechanism I am proposing make all this much more explicit by solving (2) u= sing the peeringOrg mechanism (whose meaning is more closely aligned to wha= t you are trying to do) adding clarity not only to the definition of egress= routes, but enabling as well other uses more suitable for a shared registr= y (see further comment below). > That is where my first and main concern is. Egress Routes are specific to= an organization and do not have any peeringOrgs. Egress Routes solve a ver= y specific use case of determining what Egress points within the operator's= network are to be used for particular RR(s) within a RG (which may have be= en granted by a peeringOrg any way). What does it mean to have the proposed= "RteRuleType" that has both a peeringOrg and a RR(or RG)? That leads to my= second concern, which is that the actors are different as well. Egress Rou= te rewrite regex will always be created by a peering org that is the recipi= ent of a RG offer (to whom the route has been offered), > whereas in your new use case of "like some peering organization specific = modification" of the route, rule will be created by the peering org that ha= s offered the route to various peers. DS: You say that like its a bad thing. I thought shared registries were mea= nt to be provisioned by parties wishing offer routes to various peers? > > Imho, we are trying to create this generic structure to accommodate a dif= ferent use case which muddles up and solves none of the use cases properly.= If at all this has to be done, then structurally we probably would have a = base RteRuleType, and then two derived types - one for Egress Route Rule an= d another derived type (for the new/different use case you have brought up)= . If we all want to take on this additional use case, then we can consider = going this path. DS: I am sorry but I do not get this insistence on having use case specific= constructs when the exact functionality can be achieved using a more gener= ic approach. > > W.r.t the comment " the question as to what this construct is doing in a = shared registry.." > I am not sure if I understand this comment very well. Can you please elab= orate? I thought this basic question of what Egress Route construct is doin= g in this registry should be have been discussed and agreed long back. DS: If your only use case for this functionality is egress routes I do not = understand why we would would be creating a mechanism whose sole purpose is= to provision private information that is not to be shared with anyone else= in protocol for provisioning of a shared registry? Imho, making the routeR= ule more generic and allowing for shared applications is probably the justi= fication you need. > > Thanks. > > Vikas > > -----Original Message----- > From: David Schwartz [mailto:dschwartz@xconnect.net] > Sent: Wednesday, May 16, 2012 12:50 PM > To: d.malas@cablelabs.com > Cc: Bhatia, Vikas; drinks@ietf.org > Subject: Re: [drinks] Summary of "Route Record Data Type" discussion > > Hi Daryl > > I am sorry for not being precise. > > Modifying routes via regular expressions is not unique to egress routes a= nd as such I feel that the name should be changed to a more generic RouteRe= writeRule or SEDRewriteRule as opposed to EgressRoute. I think the name Ege= rssRoute is an unfortunate choice as it defines a use case more so than a d= ata type. Additionally, egress routes are not really shareable (by definiti= on two peering orgs cannot have the same egress route raising the question = as to what this construct is doing in a shared registry) as opposed to rout= eRewriteRules which are. > > :D > > On May 16, 2012, at 7:36 PM, Daryl Malas wrote: > >> David, >> >> I have some concerns with this suggestion, "the fact that egressRoutes >> have uses other than just egress routes." If an egress route is used fo= r >> something other than an egress route, then it ceases to be an egress >> route. Egress route is used specifically for that -- that's why it's >> called an egress route. If you want a new requirement for some other >> purpose, then I think it should be stated as such. We need to be carefu= l >> not to overload and split hairs over semantics. If you want new >> functionality that is not covered by DRINKS, then propose a new >> requirement. The chairs can then work with the Ads to determine whether >> or not it is in the scope of the charter. >> >> --Daryl >> >> On 5/16/12 10:03 AM, "David Schwartz" wrote: >> >>> Hi Vikas >>> >>> I agree that it cannot be dropped as it is different from the others (s= ee >>> my previous post). >>> >>> Regarding the issue of whether or not its modifying a single record or >>> group record I can go either way. My comment had more to do with the fa= ct >>> that egressRoutes have uses other than just egress routes. >>> >>> :D >>> >>> On May 16, 2012, at 4:52 PM, Bhatia, Vikas wrote: >>> >>>> Thanks Alex. This was a useful summary on the historical perspective. >>>> >>>> We can discuss on the rest, but specifically for the following: >>>> >>>> >>>>> 3/ Drop "egress route" in favor of a generic "SED Type" record >>>>> >>>>> 3-1/ Do nothing (keep egress route - probably clarify it's use case?) >>>>> 3-2/ Drop Egress route, and explain how "normal" route records can >>>>> supply this >functionality >>>> >>>> I don't think dropping the "egress route" is an option. Not exactly >>>> sure what you meant by "normal" RRs, but none of the existing Route >>>> Record types (NAPTR, NS, URI) can fulfill the purpose of an egress rou= te >>>> (in their current form). In my view, Egress Routes have a their own >>>> specific use case. David had proposed a Route Rule concept in Paris, b= ut >>>> after giving that a thought I don't think Route Rule and Egress Route >>>> can be mixed either (because they are trying to create one structure f= or >>>> different use cases). >>>> >>>> In interest of putting the Egress Route debate to bed, I would propose >>>> to modify Egress Route definition as follows (we had discussed this >>>> during the interim prior to last IETF and to be a general agreement - >>>> but we decided to wait until David's Route Rule proposal): >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> type=3D"sppfb:RegexParamType"/> >>>> >>> minOccurs=3D"0" maxOccurs=3D"unbounded"/> >>>> >>> minOccurs=3D"0"/> >>>> >>> minOccurs=3D"0"/> >>>> >>>> >>>> >>>> >>>> >>>> Changes are: >>>> >>>> "ingrRteRec" changed to "ingrRteGrp" - meaning Egress Route is >>>> associated to a Route Group >>>> Added "svcs" element - indicates the ENUM service(s) to which Egress >>>> Route's "regxRewriteRule" should be applied (this will essentially dri= ve >>>> what RRs within the RG need to be "egressed" through this Egress Route >>>> >>>> Thanks, >>>> Vikas >>>> >>>> >>>> -----Original Message----- >>>> From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On >>>> Behalf Of Alexander Mayrhofer >>>> Sent: Tuesday, May 15, 2012 5:56 AM >>>> To: drinks@ietf.org >>>> Subject: [drinks] Summary of "Route Record Data Type" discussion >>>> >>>> As agreed during last week's Design Team call, i have summarized the >>>> discussion around the "route record data type" (SED data) below: >>>> >>>> Originally, when we started with DRINKS (or, PEPPERMINT ;) the focus >>>> was to create a provisioning protocol mostly for ENUM-style services, >>>> and, hence, the data to be incorporated was mostly DNS-style data, >>>> specifically NAPTR records (NAPTRType) and NS-style delegations >>>> (NSType). In order to accomodate situations in which the protocol woul= d >>>> be used to provision LUF-only services (returning an administrative >>>> domain identifier), the URIType was added, which together with an >>>> yet-to-defined URI scheme for SPID identification would allow to enter >>>> such SPIDs into SPP. >>>> >>>> During the IETF Meeting in Paris, David Schwartz held a presentation >>>> including some considerations regarding the typing and nomenclature of >>>> those route record types: >>>> >>>> http://tools.ietf.org/agenda/83/slides/slides-83-drinks-6.pdf (slides >>>> #3 to #7) >>>> >>>> There was significant discussion around the issue, as noted in the >>>> meeting minutes, and the topic was finally deferred to the mailing lis= t: >>>> >>>> http://tools.ietf.org/wg/drinks/minutes?item=3Dminutes-83-drinks.html >>>> >>>> David later on proposed a change to the data model, which would provid= e >>>> a clear seperation between "target" and "location" type records: >>>> >>>> http://www.ietf.org/mail-archive/web/drinks/current/msg01152.html >>>> >>>> This proposal was then discussed extensively during the Design Team >>>> Call on April 4. There was consensus about clarifying intent and usage= , >>>> however, there was also some doubt that the current proposal would >>>> provide that clarity. There was, however, consensus that renaming rout= e >>>> record, maybe to SED record, was useful. >>>> >>>> During that call, Dean came up with the Idea to use RFC4501 to >>>> encapsulate the DNS data, and use URIs for all of the different record >>>> types. It was not immediately clear whether RFC 4501 would meet the >>>> needs. >>>> >>>> Subsequent discussion took place on the mailing list, thread starts >>>> here: >>>> >>>> http://www.ietf.org/mail-archive/web/drinks/current/msg01154.html >>>> >>>> Among other things, Dean proposed to use URIs for all "record types" >>>> and also drop the seperate definition of an "egress route". Therefore >>>> the open issue seems to split up into the following "sub-issues": >>>> >>>> 1/ Whether a distinction between "Target" and "Location" type response= s >>>> (LUF vs. LRF) would be needed on the provisioning side >>>> 2/ Whether "URI + regex" would (as the single "record type") satisfy >>>> all the requirements and use cases of the protocol, and hence the >>>> existing NAPTRType, NSType, URIType would be merged into a single >>>> "record type". >>>> 3/ Whether an "egress route" would be covered by that "generic" record >>>> type as well. >>>> 4/ Whether the "Route Record" should be renamed into "SED record" - >>>> there seems to be rough concensus among the Design Team members that >>>> this should be done. >>>> >>>> (Note that URNs are a subtype of an URI, so they would be included in >>>> the URI type as well). >>>> >>>> For each of those sub-issues, our options are as follows: >>>> >>>> 1/ Target/Location subtyping: >>>> >>>> 1-1/ Keep as it is (no seperation). Understand the implications and >>>> limitations (as far as they affect the provisioning side, not the look= up >>>> side) >>>> 1-2/ Adopt the "split" of record type into "location" / "target" type. >>>> This would require (besides change to the data model, XML scheme and t= he >>>> document in general) to agree which record types would be available >>>> under which of the "supertypes" of records. >>>> >>>> (Personal note: I *think* that a split between location and target is >>>> only needed *if* the same record could be used in both situations. >>>> However, as Jon said during the Paris meeting, eg. a URI can only be >>>> dereferenced in the way it is specified for the URI scheme itself - do= es >>>> that still allow for ambiguity?) >>>> >>>> 2/ URI+regex instead of all other types? >>>> >>>> 2-1/ Keep the seperate subtypes. >>>> 2-2/ Replace all sub-types with a single "URI+regex" type. >>>> >>>> (Personal note: I understand that while RFC 4501 describes a URI schem= e >>>> for DNS *queries*, it does not describe a URI scheme that would allow = to >>>> include DNS *data* in a URI. Therefore, i'm not sure we would be able = to >>>> put NAPTR and NS data into such a field. Also, there's a traditional >>>> concern about the ambigiuity of "open" URI fields, particularly since >>>> the "data:" URI scheme allows for arbitrary data without any clear >>>> semantics) >>>> >>>> 3/ Drop "egress route" in favor of a generic "SED Type" record >>>> >>>> 3-1/ Do nothing (keep egress route - probably clarify it's use case?) >>>> 3-2/ Drop Egress route, and explain how "normal" route records can >>>> supply this functionality >>>> >>>> 4/ Rename "Route Record" into "SED record" >>>> >>>> 4-1/ Keep old name >>>> 4-2/ Rename >>>> >>>> I'm proposing to use the information above as a basis for tomorrow's >>>> Design Team call - hopefully we can solve that one issue during the >>>> discussion.. >>>> >>>> Alex >>>> >>>> >>>> _______________________________________________ >>>> 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)an= d >>>> may >>>> contain confidential and privileged information of Transaction Network >>>> Services. >>>> Any unauthorised review, use, disclosure or distribution is prohibited= . >>>> If you >>>> are not the intended recipient, please contact the sender by reply >>>> e-mail and destroy all copies of the original message. >>>> >>>> _______________________________________________ >>>> drinks mailing list >>>> drinks@ietf.org >>>> https://www.ietf.org/mailman/listinfo/drinks >>> >>> _______________________________________________ >>> 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 m= ay > contain confidential and privileged information of Transaction Network Se= rvices. > Any unauthorised review, use, disclosure or distribution is prohibited. I= f you > are not the intended recipient, please contact the sender by reply e-mail= and destroy all copies of the original message. > From vbhatia@tnsi.com Wed May 23 15:15:28 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 C43A911E80AA for ; Wed, 23 May 2012 15:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_35=0.6] 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 P+Wu8dTcozn2 for ; Wed, 23 May 2012 15:15:27 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 09A1F11E8098 for ; Wed, 23 May 2012 15:15:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAAFhvU+sEQfn/2dsb2JhbABDtTSCFQEBAQIBAQEBATc0CwUHBAIBCA4DBAEBAR4JBycLFAkIAQEEDgUIAYd/ELsZin0TB4QmYAOWJ5FngUM X-IronPort-AV: E=Sophos;i="4.75,647,1330905600"; d="scan'208";a="1234079" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 23 May 2012 23:15:24 +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; Wed, 23 May 2012 18:15:24 -0400 From: "Bhatia, Vikas" To: David Schwartz Date: Wed, 23 May 2012 18:15:23 -0400 Thread-Topic: [drinks] Summary of "Route Record Data Type" discussion Thread-Index: Ac039yoBWFx0uHXERWS8TxiYIcYpcwBM/RjQ Message-ID: References: In-Reply-To: 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] Summary of "Route Record Data Type" discussion 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: Wed, 23 May 2012 22:15:28 -0000 Sorry, but some of the basic concerns/queries I had with your new proposal = are still not answered. Let us try to argue this on the basis of few basic questions that need to b= e answered with your proposal: >From one of your earlier emails, the new use case/scenario is "like some pe= ering organization specific modification" of the route" Based on that: 1. Can you please provide an example? It will be very helpful if you can wa= lk us through a scenario for the case you have brought up. Along with helpi= ng us meaningfully interpret your proposal, it will also help answer the fo= llowing questions. 2. As I understand, with the proposed change we will have more than one Rul= es that may be applicable to a RG during resolution (as opposed to currentl= y when there is only one egress route rule is applicable for one RG at reso= lution). How then, does a resolution system determine the order/sequence in= which these multiple rules that will be associated to a RG? Does that matt= er (probably..)? 3. How should a resolution system interpret it when both a peeringOrg and a= RG is associated to the EgrRte? Egress routes, by definition, do not have = a peering org. Does it mean, apply the route rule to all routes chosen for = the peering Orgs or just that RG, or their intersection..very confusing con= struct? 4. W.rt to your comment: " In a sense the "rant" of the egress route is not the owner of the route -= but the owner of the modification rule so that instead of using the peerin= gOrg construct (which is there to define origination type stuff) for (2) it= uses the rant for the same purpose which imho introduces more confusion" I am not really sure what you mean. What "route" are you referring to above= when you say " is not the owner of the route"? Rant of the egress route ru= le is the owner of the rule and is the only one who has knowledge on how to= rewrite the ingress route to point to one of his egress routes. 5. Who are the actors for two types of rules?.."egress route rule" vs the n= ew " peering organization specific modification"..Are not they mututally ex= clusive when "peeringOrgs" in the construct vs. when "RG" in the construct? Thanks for helping understand your proposal better. Vikas -----Original Message----- From: David Schwartz [mailto:dschwartz@xconnect.net] Sent: Tuesday, May 22, 2012 4:45 AM To: Bhatia, Vikas Cc: d.malas@cablelabs.com; drinks@ietf.org Subject: Re: [drinks] Summary of "Route Record Data Type" discussion Hi Vikas and sorry for delay in responding to this. I only noticed this was= in my inbox today. Comments inline... On May 17, 2012, at 6:59 AM, Bhatia, Vikas wrote: > David, > > W.r.t the comment "as such I feel that the name should be changed to a m= ore generic RouteRewriteRule or SEDRewriteRule as opposed to EgressRoute" > > -From what was proposed back in Paris (http://tools.ietf.org/agenda/83/sl= ides/slides-83-drinks-6.pdf), it was not just a name change. Along with the= name change from "EgrRteType" to "RteRuleType", there was an additional el= ement introduced into --as proposed-- "RteRuleType" definition called "peer= ingOrg" - which along with the name change, significantly changes the seman= tics of this structure and makes it quite ambiguous imo. DS: If anything, having an element named PeeringOrg makes things more expli= cit. Let me try to be more specific. By definition, the egress route (other= than the actual rewrite rule) has two pieces of information that need to b= e specified: (1) which route does this rewrite rule apply to and (2) for wh= om does this rule apply. The egress route solves (2) by simply having the o= rganization needing this route modification provision (rant) the egress rou= te. In a sense the "rant" of the egress route is not the owner of the route= - but the owner of the modification rule so that instead of using the peer= ingOrg construct (which is there to define origination type stuff) for (2) = it uses the rant for the same purpose which imho introduces more confusion = (and I am aware that you can argue that rant is about "ownership" of things= - not just routes or numbers but rules as well - still this is fuzzy). The= mechanism I am proposing make all this much more explicit by solving (2) u= sing the peeringOrg mechanism (whose meaning is more closely aligned to wha= t you are trying to do) adding clarity not only to the definition of egress= routes, but enabling as well other uses more suitable for a shared registr= y (see further comment below). > That is where my first and main concern is. Egress Routes are specific to= an organization and do not have any peeringOrgs. Egress Routes solve a ver= y specific use case of determining what Egress points within the operator's= network are to be used for particular RR(s) within a RG (which may have be= en granted by a peeringOrg any way). What does it mean to have the proposed= "RteRuleType" that has both a peeringOrg and a RR(or RG)? That leads to my= second concern, which is that the actors are different as well. Egress Rou= te rewrite regex will always be created by a peering org that is the recipi= ent of a RG offer (to whom the route has been offered), > whereas in your new use case of "like some peering organization specific = modification" of the route, rule will be created by the peering org that ha= s offered the route to various peers. DS: You say that like its a bad thing. I thought shared registries were mea= nt to be provisioned by parties wishing offer routes to various peers? > > Imho, we are trying to create this generic structure to accommodate a dif= ferent use case which muddles up and solves none of the use cases properly.= If at all this has to be done, then structurally we probably would have a = base RteRuleType, and then two derived types - one for Egress Route Rule an= d another derived type (for the new/different use case you have brought up)= . If we all want to take on this additional use case, then we can consider = going this path. DS: I am sorry but I do not get this insistence on having use case specific= constructs when the exact functionality can be achieved using a more gener= ic approach. > > W.r.t the comment " the question as to what this construct is doing in a = shared registry.." > I am not sure if I understand this comment very well. Can you please elab= orate? I thought this basic question of what Egress Route construct is doin= g in this registry should be have been discussed and agreed long back. DS: If your only use case for this functionality is egress routes I do not = understand why we would would be creating a mechanism whose sole purpose is= to provision private information that is not to be shared with anyone else= in protocol for provisioning of a shared registry? Imho, making the routeR= ule more generic and allowing for shared applications is probably the justi= fication you need. > > Thanks. > > Vikas > > -----Original Message----- > From: David Schwartz [mailto:dschwartz@xconnect.net] > Sent: Wednesday, May 16, 2012 12:50 PM > To: d.malas@cablelabs.com > Cc: Bhatia, Vikas; drinks@ietf.org > Subject: Re: [drinks] Summary of "Route Record Data Type" discussion > > Hi Daryl > > I am sorry for not being precise. > > Modifying routes via regular expressions is not unique to egress routes a= nd as such I feel that the name should be changed to a more generic RouteRe= writeRule or SEDRewriteRule as opposed to EgressRoute. I think the name Ege= rssRoute is an unfortunate choice as it defines a use case more so than a d= ata type. Additionally, egress routes are not really shareable (by definiti= on two peering orgs cannot have the same egress route raising the question = as to what this construct is doing in a shared registry) as opposed to rout= eRewriteRules which are. > > :D > > On May 16, 2012, at 7:36 PM, Daryl Malas wrote: > >> David, >> >> I have some concerns with this suggestion, "the fact that egressRoutes >> have uses other than just egress routes." If an egress route is used fo= r >> something other than an egress route, then it ceases to be an egress >> route. Egress route is used specifically for that -- that's why it's >> called an egress route. If you want a new requirement for some other >> purpose, then I think it should be stated as such. We need to be carefu= l >> not to overload and split hairs over semantics. If you want new >> functionality that is not covered by DRINKS, then propose a new >> requirement. The chairs can then work with the Ads to determine whether >> or not it is in the scope of the charter. >> >> --Daryl >> >> On 5/16/12 10:03 AM, "David Schwartz" wrote: >> >>> Hi Vikas >>> >>> I agree that it cannot be dropped as it is different from the others (s= ee >>> my previous post). >>> >>> Regarding the issue of whether or not its modifying a single record or >>> group record I can go either way. My comment had more to do with the fa= ct >>> that egressRoutes have uses other than just egress routes. >>> >>> :D >>> >>> On May 16, 2012, at 4:52 PM, Bhatia, Vikas wrote: >>> >>>> Thanks Alex. This was a useful summary on the historical perspective. >>>> >>>> We can discuss on the rest, but specifically for the following: >>>> >>>> >>>>> 3/ Drop "egress route" in favor of a generic "SED Type" record >>>>> >>>>> 3-1/ Do nothing (keep egress route - probably clarify it's use case?) >>>>> 3-2/ Drop Egress route, and explain how "normal" route records can >>>>> supply this >functionality >>>> >>>> I don't think dropping the "egress route" is an option. Not exactly >>>> sure what you meant by "normal" RRs, but none of the existing Route >>>> Record types (NAPTR, NS, URI) can fulfill the purpose of an egress rou= te >>>> (in their current form). In my view, Egress Routes have a their own >>>> specific use case. David had proposed a Route Rule concept in Paris, b= ut >>>> after giving that a thought I don't think Route Rule and Egress Route >>>> can be mixed either (because they are trying to create one structure f= or >>>> different use cases). >>>> >>>> In interest of putting the Egress Route debate to bed, I would propose >>>> to modify Egress Route definition as follows (we had discussed this >>>> during the interim prior to last IETF and to be a general agreement - >>>> but we decided to wait until David's Route Rule proposal): >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> type=3D"sppfb:RegexParamType"/> >>>> >>> minOccurs=3D"0" maxOccurs=3D"unbounded"/> >>>> >>> minOccurs=3D"0"/> >>>> >>> minOccurs=3D"0"/> >>>> >>>> >>>> >>>> >>>> >>>> Changes are: >>>> >>>> "ingrRteRec" changed to "ingrRteGrp" - meaning Egress Route is >>>> associated to a Route Group >>>> Added "svcs" element - indicates the ENUM service(s) to which Egress >>>> Route's "regxRewriteRule" should be applied (this will essentially dri= ve >>>> what RRs within the RG need to be "egressed" through this Egress Route >>>> >>>> Thanks, >>>> Vikas >>>> >>>> >>>> -----Original Message----- >>>> From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On >>>> Behalf Of Alexander Mayrhofer >>>> Sent: Tuesday, May 15, 2012 5:56 AM >>>> To: drinks@ietf.org >>>> Subject: [drinks] Summary of "Route Record Data Type" discussion >>>> >>>> As agreed during last week's Design Team call, i have summarized the >>>> discussion around the "route record data type" (SED data) below: >>>> >>>> Originally, when we started with DRINKS (or, PEPPERMINT ;) the focus >>>> was to create a provisioning protocol mostly for ENUM-style services, >>>> and, hence, the data to be incorporated was mostly DNS-style data, >>>> specifically NAPTR records (NAPTRType) and NS-style delegations >>>> (NSType). In order to accomodate situations in which the protocol woul= d >>>> be used to provision LUF-only services (returning an administrative >>>> domain identifier), the URIType was added, which together with an >>>> yet-to-defined URI scheme for SPID identification would allow to enter >>>> such SPIDs into SPP. >>>> >>>> During the IETF Meeting in Paris, David Schwartz held a presentation >>>> including some considerations regarding the typing and nomenclature of >>>> those route record types: >>>> >>>> http://tools.ietf.org/agenda/83/slides/slides-83-drinks-6.pdf (slides >>>> #3 to #7) >>>> >>>> There was significant discussion around the issue, as noted in the >>>> meeting minutes, and the topic was finally deferred to the mailing lis= t: >>>> >>>> http://tools.ietf.org/wg/drinks/minutes?item=3Dminutes-83-drinks.html >>>> >>>> David later on proposed a change to the data model, which would provid= e >>>> a clear seperation between "target" and "location" type records: >>>> >>>> http://www.ietf.org/mail-archive/web/drinks/current/msg01152.html >>>> >>>> This proposal was then discussed extensively during the Design Team >>>> Call on April 4. There was consensus about clarifying intent and usage= , >>>> however, there was also some doubt that the current proposal would >>>> provide that clarity. There was, however, consensus that renaming rout= e >>>> record, maybe to SED record, was useful. >>>> >>>> During that call, Dean came up with the Idea to use RFC4501 to >>>> encapsulate the DNS data, and use URIs for all of the different record >>>> types. It was not immediately clear whether RFC 4501 would meet the >>>> needs. >>>> >>>> Subsequent discussion took place on the mailing list, thread starts >>>> here: >>>> >>>> http://www.ietf.org/mail-archive/web/drinks/current/msg01154.html >>>> >>>> Among other things, Dean proposed to use URIs for all "record types" >>>> and also drop the seperate definition of an "egress route". Therefore >>>> the open issue seems to split up into the following "sub-issues": >>>> >>>> 1/ Whether a distinction between "Target" and "Location" type response= s >>>> (LUF vs. LRF) would be needed on the provisioning side >>>> 2/ Whether "URI + regex" would (as the single "record type") satisfy >>>> all the requirements and use cases of the protocol, and hence the >>>> existing NAPTRType, NSType, URIType would be merged into a single >>>> "record type". >>>> 3/ Whether an "egress route" would be covered by that "generic" record >>>> type as well. >>>> 4/ Whether the "Route Record" should be renamed into "SED record" - >>>> there seems to be rough concensus among the Design Team members that >>>> this should be done. >>>> >>>> (Note that URNs are a subtype of an URI, so they would be included in >>>> the URI type as well). >>>> >>>> For each of those sub-issues, our options are as follows: >>>> >>>> 1/ Target/Location subtyping: >>>> >>>> 1-1/ Keep as it is (no seperation). Understand the implications and >>>> limitations (as far as they affect the provisioning side, not the look= up >>>> side) >>>> 1-2/ Adopt the "split" of record type into "location" / "target" type. >>>> This would require (besides change to the data model, XML scheme and t= he >>>> document in general) to agree which record types would be available >>>> under which of the "supertypes" of records. >>>> >>>> (Personal note: I *think* that a split between location and target is >>>> only needed *if* the same record could be used in both situations. >>>> However, as Jon said during the Paris meeting, eg. a URI can only be >>>> dereferenced in the way it is specified for the URI scheme itself - do= es >>>> that still allow for ambiguity?) >>>> >>>> 2/ URI+regex instead of all other types? >>>> >>>> 2-1/ Keep the seperate subtypes. >>>> 2-2/ Replace all sub-types with a single "URI+regex" type. >>>> >>>> (Personal note: I understand that while RFC 4501 describes a URI schem= e >>>> for DNS *queries*, it does not describe a URI scheme that would allow = to >>>> include DNS *data* in a URI. Therefore, i'm not sure we would be able = to >>>> put NAPTR and NS data into such a field. Also, there's a traditional >>>> concern about the ambigiuity of "open" URI fields, particularly since >>>> the "data:" URI scheme allows for arbitrary data without any clear >>>> semantics) >>>> >>>> 3/ Drop "egress route" in favor of a generic "SED Type" record >>>> >>>> 3-1/ Do nothing (keep egress route - probably clarify it's use case?) >>>> 3-2/ Drop Egress route, and explain how "normal" route records can >>>> supply this functionality >>>> >>>> 4/ Rename "Route Record" into "SED record" >>>> >>>> 4-1/ Keep old name >>>> 4-2/ Rename >>>> >>>> I'm proposing to use the information above as a basis for tomorrow's >>>> Design Team call - hopefully we can solve that one issue during the >>>> discussion.. >>>> >>>> Alex >>>> >>>> >>>> _______________________________________________ >>>> 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)an= d >>>> may >>>> contain confidential and privileged information of Transaction Network >>>> Services. >>>> Any unauthorised review, use, disclosure or distribution is prohibited= . >>>> If you >>>> are not the intended recipient, please contact the sender by reply >>>> e-mail and destroy all copies of the original message. >>>> >>>> _______________________________________________ >>>> drinks mailing list >>>> drinks@ietf.org >>>> https://www.ietf.org/mailman/listinfo/drinks >>> >>> _______________________________________________ >>> 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 m= ay > contain confidential and privileged information of Transaction Network Se= rvices. > Any unauthorised review, use, disclosure or distribution is prohibited. I= f you > are not the intended recipient, please contact the sender by reply e-mail= and destroy all copies of the original message. > This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From alexander.mayrhofer@nic.at Fri May 25 05:25:11 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 3623A21F84D9 for ; Fri, 25 May 2012 05:25:11 -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 WoVG8dKMnn0A for ; Fri, 25 May 2012 05:25:10 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id D2FCA21F84A2 for ; Fri, 25 May 2012 05:25:09 -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, 25 May 2012 14:25:07 +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, 25 May 2012 14:25:03 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: DRAFT minutes of the DRINKS design team call 2012-05-24 Thread-Index: Ac06cWcqqFlXwSxBSmyTWWd6osX0kw== Date: Fri, 25 May 2012 12:25:02 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE07518DCB0@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.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: [drinks] DRAFT minutes of the DRINKS design team call 2012-05-24 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, 25 May 2012 12:25:11 -0000 DRINKS Design Team Call - DRAFT minutes =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 May 24 2012, 10am - 11am Eastern Participants ------------ - Dean Willis - Vikas Bhatia - Manjul Maharishi - David Schwartz=20 - Alexander Mayrhofer - Syed Ali - Ken Cartwright - Sumanth Channabasappa=20 ACTION ITEMS ------------ - Continue discussion of remaining open items - Provide descriptions of 3 other remaining "main" issues - Provide arguments for egress route to mailing list (Syed) Agenda ------ 1/ Work on documented open issues Minutes ------- Sumanth opens the call, the group decides to go forward with one select iss= ue. Alex/Sumant explain that there were 4 main issues, and the one currently=20 described issue ("Data Type" issue) contains 4 "sub-issues". Alex proposes to start with the "renaming rte rec to sed rec" sub-issue, bu= t Vikas explains that his concern about renaming rte rec to sed rec is=20 connected to the decision about target/location split, so the two should be= =20 combined. Based on that, the agreement is to tackle the egress route first, which is= =20 being discussed subsequently David explains that the only purpose of egr route is to rewrite routes=20 by the consumer of route recs, so why does that go into the registry? Says he wanst to make it a more generic concept, in which case it=20 would make sense to share via the registry Vikas is not completely opposed to changes, but wants to ensure that=20 the egress route use case is covered, and wants to see what other use=20 cases that generic mechanism would cover. Alex says: concerned that generalization might imply the definition=20 of a whole new range of required semantics.=20 Dean: Is an egress route mandatory, or optional? When do you use it? There is extensive discussion around those issues. Sumanth summarizes: Do we want to have a generic rule or not? would have to define its use very clearly (likely lots of effort) -=20 difference whether we should make changes (a new mechanism) or=20 do we just need to clarify what's there? David says, making it generic makes it shareable, and hence then=20 it would "fit" into a registry which very purpose is to share data.=20 Is this protocol to provision private data? Ken: This is a feature that is out there. Document is very clear=20 about how it is applied. If unclear, please suggest text on the list. Vikas: two basic questions - do we want to keep it or not? And if yes,=20 seperate question whether we want to generalize it or not?=20 Would create totally new use cases that we have been unaware so far. Sumanth: Q: Does current mechanism solve use case? David: Yes, but in a inconsistent way for the protocol (private data) Vikas: Generic mechanism proposed by David does not solve=20 the egress use case! Sumanth: regarding "power" of the design team: We can make a decision=20 here, and confirm on the mailing list. Dean: Only concern is the sharing of private date in the registry. Alex agr= ees. Syed: Private data: typically contracts in place, and it's an=20 *option*. Nobody forced to use it. Plus, IP addresses are typically=20 from a private network range. Sumanth: Let's make a decision, now. Sumanth: Proposal: Let's keep egr route as it is, and clarify that=20 it's optional. Who's in favor / who objects? David is the only=20 participant who objects. Sumanth: 2nd question: Any objection on keeping the scope, and=20 not extending? Proposing we don't look at extending it. No objections Conclusion: egress route definition will stay in the protocol as=20 currently defined, we need to clarify a few points - Syed mentioned a range of good points, and will send these out of the mailing list. Next calls: There will be two calls next week, Tue and Thur. Call concludes. From alexander.mayrhofer@nic.at Tue May 29 06:22: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 4FF0E21F85CC for ; Tue, 29 May 2012 06:22: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 QMObyK7TSks6 for ; Tue, 29 May 2012 06:22:07 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 015E521F85C6 for ; Tue, 29 May 2012 06:22: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 ; Tue, 29 May 2012 15:22:04 +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, 29 May 2012 15:21:59 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: UPDATED DRAFT minutes of the DRINKS design team call 2012-05-24 Thread-Index: Ac09nZWceh9rxHXjSX+QeZNWviSZ+A== Date: Tue, 29 May 2012 13:21:59 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075191978@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] UPDATED DRAFT minutes of the DRINKS design team call 2012-05-24 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: Tue, 29 May 2012 13:22:08 -0000 I've updated the minutes from last weeks design team call - see below:=20 - Most importantly, call this week will take place on WED and FRI - contrar= y to what was given in the last draft minutes - Secondly, i've updated Sumanth's statement regarding "power of the design= team". thanks & sorry for the confusion, Alex DRINKS Design Team Call - DRAFT minutes =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 May 24 2012, 10am - 11am Eastern Participants ------------ - Dean Willis - Vikas Bhatia - Manjul Maharishi - David Schwartz=20 - Alexander Mayrhofer - Syed Ali - Ken Cartwright - Sumanth Channabasappa=20 ACTION ITEMS ------------ - Continue discussion of remaining open items - Provide descriptions of 3 other remaining "main" issues - Provide arguments for egress route to mailing list (Syed) Agenda ------ 1/ Work on documented open issues Minutes ------- Sumanth opens the call, the group decides to go forward with one select iss= ue. Alex/Sumant explain that there were 4 main issues, and the one currently=20 described issue ("Data Type" issue) contains 4 "sub-issues". Alex proposes to start with the "renaming rte rec to sed rec" sub-issue, bu= t Vikas explains that his concern about renaming rte rec to sed rec is=20 connected to the decision about target/location split, so the two should be= =20 combined. Based on that, the agreement is to tackle the egress route first, which is= =20 being discussed subsequently David explains that the only purpose of egr route is to rewrite routes=20 by the consumer of route recs, so why does that go into the registry? Says he wanst to make it a more generic concept, in which case it=20 would make sense to share via the registry Vikas is not completely opposed to changes, but wants to ensure that=20 the egress route use case is covered, and wants to see what other use=20 cases that generic mechanism would cover. Alex says: concerned that generalization might imply the definition=20 of a whole new range of required semantics.=20 Dean: Is an egress route mandatory, or optional? When do you use it? There is extensive discussion around those issues. Sumanth summarizes: Do we want to have a generic rule or not? would have to define its use very clearly (likely lots of effort) -=20 difference whether we should make changes (a new mechanism) or=20 do we just need to clarify what's there? David says, making it generic makes it shareable, and hence then=20 it would "fit" into a registry which very purpose is to share data.=20 Is this protocol to provision private data? Ken: This is a feature that is out there. Document is very clear=20 about how it is applied. If unclear, please suggest text on the list. Vikas: two basic questions - do we want to keep it or not? And if yes,=20 seperate question whether we want to generalize it or not?=20 Would create totally new use cases that we have been unaware so far. Sumanth: Q: Does current mechanism solve use case? David: Yes, but in a inconsistent way for the protocol (private data) Vikas: Generic mechanism proposed by David does not solve=20 the egress use case! Sumanth: We can discuss and vote within the design team, and propose the re= sults as a recommendation to the DRINKS mailing list. WG participants can t= hen chime in, resulting in a final decision (as the WG).=20 Dean: Only concern is the sharing of private date in the registry. Alex agr= ees. Syed: Private data: typically contracts in place, and it's an=20 *option*. Nobody forced to use it. Plus, IP addresses are typically=20 from a private network range. Sumanth: Let's make a decision, now. Sumanth: Proposal: Let's keep egr route as it is, and clarify that=20 it's optional. Who's in favor / who objects? David is the only=20 participant who objects. Sumanth: 2nd question: Any objection on keeping the scope, and=20 not extending? Proposing we don't look at extending it. No objections Conclusion: egress route definition will stay in the protocol as=20 currently defined, we need to clarify a few points - Syed mentioned a range of good points, and will send these out of the mailing list. Next calls: There will be two calls next week, Wed and Fri. Call concludes. From alexander.mayrhofer@nic.at Thu May 31 06:18: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 1B8C521F869E for ; Thu, 31 May 2012 06:18: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 PqueMiXykV1y for ; Thu, 31 May 2012 06:18:55 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0A56421F8698 for ; Thu, 31 May 2012 06:18: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 ; Thu, 31 May 2012 15:18:52 +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, 31 May 2012 15:18:49 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: DRAFT minutes of the DRINKS design team call on May 30 2012. Thread-Index: Ac0/L9mIDjg9gMfZQoq5o3R/95bARA== Date: Thu, 31 May 2012 13:18:48 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075192F53@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 of the DRINKS design team call on May 30 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, 31 May 2012 13:18:56 -0000 DRAFT minutes DRINKS design team call May 30 2012 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May 30 2012, 10am - 11am eastern Participants ------------ - Vikas Bhatia - Manjul Maharishi - David Schwartz=20 - Alexander Mayrhofer - Syed Ali - Ken Cartwright - Sumanth Channabasappa=20 ACTION ITEMS ------------ - continue discussion of open items Agenda ------ 1/ Work on documented open issues Minutes ------- Sumanth opens the call - runs through last week notes. Alex summarizes decisions from last week. Vikas mentions that the decision whether egress route was to be associated with rte grp instead of rte rec was pending. Alex asks whether the design team would be ok with chaing egr rte from=20 rte rec to rte grp. Sumanth brings up the respective email from vikas, group is ok with the cha= nge, including the svcs addition (alex mentions that the svcs field semantics=20 need to be clearly defined). The team agrees to the two changes. -> Decision: change association of egress route from route record to route= =20 group, add "svcs" field to egress route. Clarify svcs semantics. Target vs. location (and rte to sed rename): Vikas said they are connected, david comments he's not sure why.=20 David explains the Target/Location issue - sees a gap between SPEERMINT=20 terminology and the DRINKS documents. Alex notes that an "identification" field in the base rte rec type (optiona= l) would allow people to choose whether or not they want to use the "split". Sumanth brings up david's proposal (chart): http://www.ietf.org/mail-archive/web/drinks/current/msg01152.html Manjul: are we trying to solve an resolution protocol problem here? David: no, just trying to add to the provisioning side a way to=20 differentiate whether the provisioned data is LUF or LRF. Alex: concerned that people would be forced to categorize.. David: Want to force people to do it, in order to solve interopability nigh= tmares. Syed: Clarification that it's just *annotation*, there's no effect on the=20 resolution protocol side. Ken: please summarize issue in two sentences? David: Trying to force the SP into removing ambiguity from the provisioned= =20 data. Resolution side is not affected. There's just a little bit of=20 extra data in the registry. More discussion around whether that split is useful, and options to convey = it in resolution protocols (such as terminal flag in ENUM). Discussion whether this is in scope or not - "S" in "drinks" stands for "SI= P"?=20 Sumanth: Thinks we should be ok if that is annotation only. Ken: Need to think that through, but would it be possible to make "collidin= g"=20 annotations, such as a "gspid:" URI scheme with a "Location" type? Syed: All we're looking is adding an additional element for annotation, in= =20 order to distinguish the types. Sumanth: Call on Fri?=20 Group: Let's do Thur - new call tomorrow. Discussion about whether sub-typing or attribute would be the easier way.=20 Alex feels that subtyping is pretty strict (Ken agrees), David thinks=20 being strict can be an advantage. No conclusion here. Call concludes after an hour, next call on Thu, May 31. From dschwartz@xconnect.net Thu May 31 06:47:41 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 C25A421F864B for ; Thu, 31 May 2012 06:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, 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 mhU7cPClNJwx for ; Thu, 31 May 2012 06:47:40 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7B24521F8644 for ; Thu, 31 May 2012 06:47:39 -0700 (PDT) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Thu, 31 May 2012 16:47:37 +0300 From: David Schwartz To: Alexander Mayrhofer Date: Thu, 31 May 2012 16:47:37 +0300 Thread-Topic: [drinks] DRAFT minutes of the DRINKS design team call on May 30 2012. Thread-Index: Ac0/M/B/4vffQmMYS7Gmh7B+i4lO9w== Message-ID: <71043FB0-75BD-4047-B235-6D72E486F69B@xconnect.net> References: <19F54F2956911544A32543B8A9BDE075192F53@NICS-EXCH.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE075192F53@NICS-EXCH.sbg.nic.at> 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_71043FB075BD4047B2356D72E486F69Bxconnectnet_" MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] DRAFT minutes of the DRINKS design team call on May 30 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, 31 May 2012 13:47:41 -0000 --_000_71043FB075BD4047B2356D72E486F69Bxconnectnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Here is a possible snippet for my Action Item=85 :D On May 31, 2012, at 4:18 PM, Alexander Mayrhofer wrote: DRAFT minutes DRINKS design team call May 30 2012 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May 30 2012, 10am - 11am eastern Participants ------------ - Vikas Bhatia - Manjul Maharishi - David Schwartz - Alexander Mayrhofer - Syed Ali - Ken Cartwright - Sumanth Channabasappa ACTION ITEMS ------------ - continue discussion of open items Agenda ------ 1/ Work on documented open issues Minutes ------- Sumanth opens the call - runs through last week notes. Alex summarizes decisions from last week. Vikas mentions that the decision whether egress route was to be associated with rte grp instead of rte rec was pending. Alex asks whether the design team would be ok with chaing egr rte from rte rec to rte grp. Sumanth brings up the respective email from vikas, group is ok with the cha= nge, including the svcs addition (alex mentions that the svcs field semantics need to be clearly defined). The team agrees to the two changes. -> Decision: change association of egress route from route record to route group, add "svcs" field to egress route. Clarify svcs semantics. Target vs. location (and rte to sed rename): Vikas said they are connected, david comments he's not sure why. David explains the Target/Location issue - sees a gap between SPEERMINT terminology and the DRINKS documents. Alex notes that an "identification" field in the base rte rec type (optiona= l) would allow people to choose whether or not they want to use the "split". Sumanth brings up david's proposal (chart): http://www.ietf.org/mail-archive/web/drinks/current/msg01152.html Manjul: are we trying to solve an resolution protocol problem here? David: no, just trying to add to the provisioning side a way to differentiate whether the provisioned data is LUF or LRF. Alex: concerned that people would be forced to categorize.. David: Want to force people to do it, in order to solve interopability nigh= tmares. Syed: Clarification that it's just *annotation*, there's no effect on the resolution protocol side. Ken: please summarize issue in two sentences? David: Trying to force the SP into removing ambiguity from the provisioned data. Resolution side is not affected. There's just a little bit of extra data in the registry. More discussion around whether that split is useful, and options to convey = it in resolution protocols (such as terminal flag in ENUM). Discussion whether this is in scope or not - "S" in "drinks" stands for "SI= P"? Sumanth: Thinks we should be ok if that is annotation only. Ken: Need to think that through, but would it be possible to make "collidin= g" annotations, such as a "gspid:" URI scheme with a "Location" type? Syed: All we're looking is adding an additional element for annotation, in order to distinguish the types. Sumanth: Call on Fri? Group: Let's do Thur - new call tomorrow. Discussion about whether sub-typing or attribute would be the easier way. Alex feels that subtyping is pretty strict (Ken agrees), David thinks being strict can be an advantage. No conclusion here. Call concludes after an hour, next call on Thu, May 31. _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks --_000_71043FB075BD4047B2356D72E486F69Bxconnectnet_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Here is a possible snippet= for my Action Item=85

<simpleType name=3D"SEDCa= tegoryType">
  <restriction base=3D"token">
  &= nbsp; <enumeration value=3D"target"/>
    <enu= meration value=3D"unspecified"/>
  </restriction>
</simpleType>

<= ;complexType name=3D"SEDRecType" abstract=3D"true">
  <= ;complexContent>
    <extension base=3D"sppfb:Bas= icObjType">
      <sequence>
&n= bsp;       <element name=3D"sedName" type=3D"sppfb:ObjNam= eType"/>
        <element name=3D"sedCa= tegory" type=3D"sppfb:SEDCategoryType" />
     =   <element name=3D"isInSvc" type=3D"boolean"/>
 = ;       <element name=3D"ttl" 
  = ;               type=3D"positiveInteger"= minOccurs=3D"0"/>
      </sequence>
    </extension>
  </complexContent= >
</complexType>

:D
=


On May 31, 2012, at 4:18 PM, Alexander Ma= yrhofer wrote:


DRAFT minutes DRINKS design team call May 30 2012
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
May 30 2012, 10am - 11am eastern

Participants
------------
- Vikas Bhatia
- Manjul Maharishi
- David Schwartz
- Alexan= der Mayrhofer
- Syed Ali
- Ken Cartwright
- Sumanth Channabasappa =

ACTION ITEMS
------------

- continue discussion of open i= tems

Agenda
------

1/ Work on documented open issues
Minutes
-------

Sumanth opens the call - runs through last week= notes.

Alex summarizes decisions from last week.

Vikas menti= ons that the decision whether egress route was to be associated
with rte= grp instead of rte rec was pending.

Alex asks whether the design te= am would be ok with chaing egr rte from
rte rec to rte grp.

Suma= nth brings up the respective email from vikas, group is ok with the change,=
including the svcs addition (alex mentions that the svcs field semantic= s
need to be clearly defined). The team agrees to the two changes.
<= br>-> Decision: change association of egress route from route record to = route
group, add "svcs" field to egress route. Clarify svcs semantics.<= br>
Target vs. location (and rte to sed rename): Vikas said they are con= nected,
david comments he's not sure why.

David explains the Tar= get/Location issue - sees a gap between SPEERMINT
terminology and the D= RINKS documents.

Alex notes that an "identification" field in the ba= se rte rec type (optional) would allow people to choose whether or not they= want to
use the "split".

Sumanth brings up david's proposal (cha= rt):
http://www.ietf.org/mail-archive/web/drinks/current/msg01152.htm= l

Manjul: are we trying to solve an resolution protocol problem = here?
David: no, just trying to add to the provisioning side a way to differentiate whether the provisioned data is LUF or LRF.

Alex: co= ncerned that people would be forced to categorize..
David: Want to force= people to do it, in order to solve interopability nightmares.

Syed:= Clarification that it's just *annotation*, there's no effect on the
re= solution protocol side.

Ken: please summarize issue in two sentences= ?

David: Trying to force the SP into removing ambiguity from the pro= visioned
data. Resolution side is not affected. There's just a little b= it of
extra data in the registry.

More discussion around whether= that split is useful, and options to convey it
in resolution protocols = (such as terminal flag in ENUM).

Discussion whether this is in scope= or not - "S" in "drinks" stands for "SIP"?
Sumanth: Thinks we should b= e ok if that is annotation only.

Ken: Need to think that through, bu= t would it be possible to make "colliding"
annotations, such as a "gspi= d:" URI scheme with a "Location" type?

Syed: All we're looking is ad= ding an additional element for annotation, in
order to distinguish the = types.

Sumanth: Call on Fri?
Group: Let's do Thur - new call tom= orrow.

Discussion about whether sub-typing or attribute would be the= easier way.
Alex feels that subtyping is pretty strict (Ken agrees), D= avid thinks
being strict can be an advantage. No conclusion here.
Call concludes after an hour, next call on Thu, May 31.
______________= _________________________________
drinks mailing list
drinks@ietf.org=
https://www.ietf.org/mailman/listinfo/drinks

= --_000_71043FB075BD4047B2356D72E486F69Bxconnectnet_--