From nobody Mon Feb 1 22:03:01 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAC11A01D5; Mon, 1 Feb 2016 22:01:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160202060157.30702.98800.idtracker@ietfa.amsl.com> Date: Mon, 01 Feb 2016 22:01:57 -0800 Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org Subject: [lisp] Spencer Dawkins' No Objection on charter-ietf-lisp-03-00: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 06:01:57 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-lisp-03-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-lisp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This text "The LISP WG is chartered to continue work on the LISP base protocol with the main objective to develop a standard solution based on the completed Experimental RFCs and the experience gained from early deployments." might be clearer if it said "a standards-track solution". From nobody Tue Feb 2 01:03:07 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B361AC434 for ; Tue, 2 Feb 2016 01:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAGVtMmm_evn for ; Tue, 2 Feb 2016 01:03:04 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2981AC3D3 for ; Tue, 2 Feb 2016 01:03:03 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id l66so12108649wml.0 for ; Tue, 02 Feb 2016 01:03:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ra1S9BbrhywaIlwkBPxFP+O6tL3Z87EI+0KFdAN0+84=; b=YWLk0lLiCPsWlgWe8UOM56jbtxDYRHJIKeGPQFlMEb9LtnXzy0oz9jUOus6IL1Zq0n lCWR519CnuWVjJ53YOrIcFlSrWIhYz0TtMwNs+DQEcx+wIAfa4gvdviNDv4EY93+PBPL sCPfYaxNyapLfp1P05nJJaLjDMrQN9mW6J1Oth/+Mqnly6Ej6ObhXflydM/BQrhQHmwW 3uZwVB3XI0qAj1Iypi2XWvQZQa79VHeU9mPSWl2unkPgddMwFBRNcOZqjMZyOtHl2fxB jZ9fxarwB2t2vhMMKn8/ArNoA3MJBHidWuzRCYxUhHW4aeFW+XR34voqx+upw84tzTP4 /rLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Ra1S9BbrhywaIlwkBPxFP+O6tL3Z87EI+0KFdAN0+84=; b=lB8aA8jG+UbxZjkZVvcprXu9taamgfaFURYGW7te1144twfDk8k8uLQkxBtWZ2gIml xwliT7ctUB8Ng9eM4dcppSuYRaQNBzLWWkjSYxfp9dwapOCea5b47iRQmeJghI42ut6b hBrvbd4n7+DqJKYzZ2+gF8bPDzIwKSMl1q0l8D4xc4Fvb3cgYA27+uMSzp01gt7BnNbA VK+bgzlvaWHBC7NL2sWj3cMLv30JwHn4vFebPetUMwTw8cavo5CJ3fkJK4tMAblAzJjF 1P/3T7Sk5mfQgl3WyFrH/STeeQfiD+y2hPSCCToIJbuH2z47kyREnw/cweOty9OiwYdJ uXMQ== X-Gm-Message-State: AG10YOTbREjs6fbSmpiUCFj4IgsYaqQbPVUAD9Iv8eN5qP8sKupvxI+lKk5sA5amEZ9qcg== X-Received: by 10.28.60.68 with SMTP id j65mr16146612wma.33.1454403782180; Tue, 02 Feb 2016 01:03:02 -0800 (PST) Received: from [10.9.1.109] (napsach022.hosting-cea.net. [192.54.209.59]) by smtp.gmail.com with ESMTPSA id x2sm439446wjf.13.2016.02.02.01.02.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 02 Feb 2016 01:03:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: <20160202060157.30702.98800.idtracker@ietfa.amsl.com> Date: Tue, 2 Feb 2016 10:03:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160202060157.30702.98800.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.3112) Archived-At: Cc: lisp-chairs@ietf.org, The IESG , lisp@ietf.org Subject: Re: [lisp] Spencer Dawkins' No Objection on charter-ietf-lisp-03-00: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 09:03:05 -0000 Hi Spencer, thanks for the catch I agree that the current text is sloppy on this = point and that the wording you suggest is much better. ciao L. > On 02 Feb 2016, at 07:01, Spencer Dawkins = wrote: >=20 > Spencer Dawkins has entered the following ballot position for > charter-ietf-lisp-03-00: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-lisp/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > This text >=20 > "The LISP WG is chartered to continue work on the LISP base protocol = with > the > main objective to develop a standard solution based on the completed > Experimental RFCs and the experience gained from early deployments." >=20 > might be clearer if it said "a standards-track solution". >=20 >=20 From nobody Tue Feb 2 08:39:51 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 807571B2D3B; Tue, 2 Feb 2016 08:39:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Alvaro Retana" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160202163941.8955.70959.idtracker@ietfa.amsl.com> Date: Tue, 02 Feb 2016 08:39:41 -0800 Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org Subject: [lisp] Alvaro Retana's No Objection on charter-ietf-lisp-03-00: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 16:39:41 -0000 Alvaro Retana has entered the following ballot position for charter-ietf-lisp-03-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-lisp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Joel in that some more detail on the deliverables would be nice — also, some of the expected interactions should be called out; for example, for the multicast item I would expect interaction with the pim WG, etc. From hassan_samii21@yahoo.com Tue Feb 2 09:09:57 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555A31B2D96 for ; Tue, 2 Feb 2016 09:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.2 X-Spam-Level: * X-Spam-Status: No, score=1.2 tagged_above=-999 required=5 tests=[BAYES_60=1.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4wRRQPPEOQO for ; Tue, 2 Feb 2016 09:09:56 -0800 (PST) Received: from nm35-vm9.bullet.mail.ir2.yahoo.com (nm35-vm9.bullet.mail.ir2.yahoo.com [212.82.97.132]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC561B2D86 for ; Tue, 2 Feb 2016 09:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1454432994; bh=abFlquNFwWA0nVoaDz1D82WAmu44Mg6lZLxi9dG41Fw=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=Q9UWPymu0MS6H6dM7R+mT55H1/lakQKZEpHyycTiolY42+ohY/ie8pT1bag1dIBNjokJjmJmuLVyv/MhN1l3IQxq9PuUwoP+X4pD8iLqt79GB0q43KMxgPDkBvlZQ9JtHij2QONRhG5BOZs+YuNnECvg5xD6zPQejMkg+7DSkX81b3HJWSVWl3+vZ9fFh+3tIy0s80inid6BuH7Vb2jii/qe/c0kaf7lmmVDXRkMMKC/YzP0O+hzX6EndKv7yLzmtzvhjEhg5jGUrP2TIGeUNq5rjnS7PF9/OO0IqNkXlUcsOZVERwKdrDgam5uCe8wqpBDMp7EqTdS7wBS0+6rl7g== Received: from [212.82.98.52] by nm35.bullet.mail.ir2.yahoo.com with NNFMP; 02 Feb 2016 17:09:54 -0000 Received: from [212.82.98.106] by tm5.bullet.mail.ir2.yahoo.com with NNFMP; 02 Feb 2016 17:09:54 -0000 Received: from [127.0.0.1] by omp1043.mail.ir2.yahoo.com with NNFMP; 02 Feb 2016 17:09:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 336524.40732.bm@omp1043.mail.ir2.yahoo.com X-YMail-OSG: D_zZ5tEVM1k3sOjbl51F4u8CF6b6I3viPM945Zvz24y22qeGYikNaarbQL7sjph 3W3HgluR.yWBN0rDzAPf.VY8dOefr8vQqwNXYSkpEPB3.Z10JRUIYV4Qf0dN.sPDZXnyI4YNJ.u. Tod5L7AdswT_ODeeNOcb_v5GKQo.cy6yuzGErT5bvVXsiWHi6C3.kVsP9jplPREjHE9sYOMItoH4 8THhIqj.dYqlBcdlnWTzV35chZXDGSBTdyghLx.m5c_dwqeZXDJ_pG9RFyS40fdt6QC7bx0oQTub FyqO0T7QqlKhPcO9rdzsF7XK.DkgjZWJMRcO1qrJL_P2LCpuXFht7pDR5UmvFPFy1FOZ5TDrKflw f6fiqO5fIMqoAKFFb6FbXP1CaLStkfjgFlwQrGEo_RBnU2GF_DI4wv84svUVMMKsoOi7vwohoALa zpek_djUu0z87Tpvr1aL4vFlOXn0BZOpMl3OiNUJh.Rwm9QXMeJPdKV_2_htF_FXySSqkjSQrKJj ThD2xINR1CPkdkGuLRkbTxv.5 Received: by 212.82.98.117; Tue, 02 Feb 2016 17:09:53 +0000 Date: Tue, 2 Feb 2016 17:09:53 +0000 (UTC) From: Hassan Samii To: "lisp@ietf.org" Message-ID: <1786526842.844836.1454432993367.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_844835_769442878.1454432993365" References: <1786526842.844836.1454432993367.JavaMail.yahoo.ref@mail.yahoo.com> Archived-At: Subject: [lisp] LISP tool not available anymore on the webpage X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Hassan Samii List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 17:21:05 -0000 ------=_Part_844835_769442878.1454432993365 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello,There used to be a tool with which you could see if your EID-RLOC add= resses work on the official LISP network. It used to be on the lisp4.net we= bsite under tools at=C2=A0LISP Control Plane Status as viewed from various = Map Resolvers=C2=A0at the following web page=C2=A0http://www.lisp4.net/stat= us/ =C2=A0but the webpage gives a 404 error. Will this too ever be up again? Or= has it been substituted?Regards=C2=A0 Hassan ------=_Part_844835_769442878.1454432993365 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,
T= here used to be a tool with which you could see if your EID-RLOC addresses = work on the official LISP network. It used to be on the lisp4.net website u= nder tools at LISP Control Plane Status as view= ed from various Map Resolvers at the following web page http://www.lisp4.net/status/=
 but the webpage gives a 404 error. Will this too ever be up again= ? Or has it been substituted?
Regards
  Hassan




------=_Part_844835_769442878.1454432993365-- From nobody Tue Feb 2 11:22:13 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77F21B2F61; Tue, 2 Feb 2016 11:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRC4x5YsMi-v; Tue, 2 Feb 2016 11:22:07 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845F31B2EAC; Tue, 2 Feb 2016 11:22:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 71D4E246737; Tue, 2 Feb 2016 11:22:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1454440927; bh=ZxqgnyzyqLbzQIgRrjgHC5zM/7PK1dOqDPxOQaQkInM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=bA4ejsz2/WwaLndC8CMbIiBMkNU4+CcpsyBFvetq86EZWOkFJOqevz0Htd6mzP+99 DSJQxaH1NuXowHD+pdoeMLva5rNFlVM8PGywVoEV2PRINYD+ldX48Rpz42cwSHBkGo fRR5e6H6cVOsSvp2kiR/oaJy11lY285L5ZdkzZ94= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A855E240837; Tue, 2 Feb 2016 11:22:01 -0800 (PST) To: Alvaro Retana , The IESG References: <20160202163941.8955.70959.idtracker@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <56B101BB.6030802@joelhalpern.com> Date: Tue, 2 Feb 2016 14:21:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160202163941.8955.70959.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org Subject: Re: [lisp] Alvaro Retana's No Objection on charter-ietf-lisp-03-00: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 19:22:09 -0000 I am not sure how to properly expand the descriptions of the mobility and multicast items. The mobility item is specifically aimed at using the LISP Mobile Node techniques (for which we have an Internet Draft in good shape.) There has been discussion of using that for moved VMs and for actual mobile terminals. We can reference NVO3 for data center usage. But that is not really mobility. the multicast work is reflective of a series of drafts on which the working group is pretty close to agreement on a replication engineering draft and a signal free draft. The replication engineering draft mentions PIM, but does not modify or affect it in any way. And signla-free is separate from any other working group effort. We can add text on each one talking about the solutions the working group is looking at, but I don't think that is a good idea. Yours, Joel On 2/2/16 11:39 AM, Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > charter-ietf-lisp-03-00: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-lisp/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Joel in that some more detail on the deliverables would be > nice — also, some of the expected interactions should be called out; for > example, for the multicast item I would expect interaction with the pim > WG, etc. > > > From nobody Tue Feb 2 11:23:54 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B86E1B2FB8; Tue, 2 Feb 2016 11:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQEZoOAuQ4ly; Tue, 2 Feb 2016 11:23:52 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147D61B2F61; Tue, 2 Feb 2016 11:23:52 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id 65so110112955pfd.2; Tue, 02 Feb 2016 11:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CrzX9jRGvyTchYoLRQbMJdg1choJ/YtjxyzSO2R2Sc8=; b=XC6RzIGaGQhxVca/k6gSU0Zvp9ECqM90UFV7q4AtJa6toP/UUvA3VbJw2MocCzKYIA ovZfP0VQ2weQ/ZkDffceXpcRaNI6GhWtMSzmP0/LcYbRRGH4N66q+nruixLM3UTTLfdg zSHLogOBeIooi416KNWeWvWOitokz6DwU8XCuYN53WzzyP76Ld8xWClbcHgk8bnOSa/z DIUR9F4DC7H2ZoBCUBPxjZA4fPbFNttzMScHZlRuVQ6EBKpCNjnbX8UKpz0tzTY/BTYi /ihA4BLcskkPqOcc3N9mt3hNjGyWMvfukFMxBJmqN64pu/l8mywDeO98oMS3i1izSfI9 c+Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=CrzX9jRGvyTchYoLRQbMJdg1choJ/YtjxyzSO2R2Sc8=; b=Lr2I9yu2NGLawdMVbDPTi+psYr2ptO7LkgZkuP6uwduLHu+j18YLQfrTcLwZYsc/GC FDNzNb4sk5dwyZ39v0RpPfotQlaF+SNLetwcrccsNMdz2l3d9mb/01VLSRypJVI18EBK uV8UMdsg/IU/otC9RmeDn0thQ+vG01X/AL34gg6jb+C0xBpFjwXay78jUmMZsi+iqtY/ I+UwGo29OO0t2LdcZB6/0xCam0H6tlUOrqHO2nwMCqccZzIyv7guebZDnK1SsTbD82Cq kTrODs5MsGeaycujGoyIRkRbOxvqraCsY19NnnIQY7mqBlgxBd8Tr9LU91yCfwSMnQp/ hUWA== X-Gm-Message-State: AG10YOQvL27vZKxVEbYeP5mHPW842AQobLQ2iEK/Loe+yWT0igT/gvDTgGa6J01ISVVWNg== X-Received: by 10.98.18.215 with SMTP id 84mr11589599pfs.131.1454441031706; Tue, 02 Feb 2016 11:23:51 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id f27sm4503477pfj.0.2016.02.02.11.23.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Feb 2016 11:23:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dino Farinacci In-Reply-To: <56B101BB.6030802@joelhalpern.com> Date: Tue, 2 Feb 2016 11:23:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <92DC39B5-F1EC-4EB6-94D7-8AAC5C65611E@gmail.com> References: <20160202163941.8955.70959.idtracker@ietfa.amsl.com> <56B101BB.6030802@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: lisp@ietf.org, The IESG , lisp-chairs@ietf.org Subject: Re: [lisp] Alvaro Retana's No Objection on charter-ietf-lisp-03-00: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 19:23:53 -0000 > the multicast work is reflective of a series of drafts on which the = working group is pretty close to agreement on a replication engineering = draft and a signal free draft. The replication engineering draft = mentions PIM, but does not modify or affect it in any way. And = signla-free is separate from any other working group effort. And there is RFC6831. It mentions PIM in a big way. Dino From nobody Tue Feb 2 11:39:08 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335081B3003; Tue, 2 Feb 2016 11:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSrJXzB3lNFT; Tue, 2 Feb 2016 11:39:07 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 469D61B2FF7; Tue, 2 Feb 2016 11:39:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 2DFDF25F056; Tue, 2 Feb 2016 11:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1454441947; bh=+hJwhAzfgTfFwPhFYA/xKH3C/j+41k2J/tDsaUXEMP0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=VPcm1pnz71AveCov410quQjk4eLvRMfoMGQIYMlJZ970CB74L0wzetVJXHFVg23qf nJUaZrJunvd/UloEXMUH1895HKEYwIDfjb2RxDNio+TYTVJUBU7lIMKz/SRF0Ym4l7 edstyfb+FGTfYTln3Ve/7/tsbaAEq1KARdqX6JMY= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 90E6F24D4CC; Tue, 2 Feb 2016 11:39:06 -0800 (PST) To: Dino Farinacci References: <20160202163941.8955.70959.idtracker@ietfa.amsl.com> <56B101BB.6030802@joelhalpern.com> <92DC39B5-F1EC-4EB6-94D7-8AAC5C65611E@gmail.com> From: "Joel M. Halpern" Message-ID: <56B105BC.7090200@joelhalpern.com> Date: Tue, 2 Feb 2016 14:38:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <92DC39B5-F1EC-4EB6-94D7-8AAC5C65611E@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: lisp@ietf.org, The IESG , lisp-chairs@ietf.org Subject: Re: [lisp] Alvaro Retana's No Objection on charter-ietf-lisp-03-00: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 19:39:08 -0000 Yes, we did RFC 6831. As far as I know, no one in the WG plans to make any enhancements to that or its interaction with PIM. Yours, Joel On 2/2/16 2:23 PM, Dino Farinacci wrote: >> the multicast work is reflective of a series of drafts on which the working group is pretty close to agreement on a replication engineering draft and a signal free draft. The replication engineering draft mentions PIM, but does not modify or affect it in any way. And signla-free is separate from any other working group effort. > > And there is RFC6831. It mentions PIM in a big way. > > Dino > From nobody Tue Feb 2 11:48:18 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007F91B3017; Tue, 2 Feb 2016 11:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRvJt5MP0siz; Tue, 2 Feb 2016 11:48:15 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A191B3014; Tue, 2 Feb 2016 11:48:15 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id o185so105557067pfb.1; Tue, 02 Feb 2016 11:48:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KysNCALh9nAqHwD2kCnN8b1IhfNc5IXwE4wG/oZPH1Q=; b=XOE/N3KB+dxhmffLJWBJl/o1jC8u8OlceJh3j+eltT1tUSWgKTvXJT1KuoPwZ4r6us Kp86/78tINvOzbu4T7dL78nhBgGaPNKmGR4BahwC5oW+ofMdsowy/vcdKUzlzXZUC6nQ sF87gmCQ+uhBDwhRjT9GppjA3XbDw97fKT+0pTnOU4rBrPX8NpNZ0aBrmkwbDywABL9l 3gJoEQxuOedB49Qq/Ccp7hUwKpK/K1WmVDu5YLXvku2yI9rKh0+aJjZMT72odTmf5O9x hlH0QaPf8R7nGMK03QthmscOqilmYZ9yh7m2C4MEIUMTcQ5PpihdG191EduA/JJlxdHq iGaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=KysNCALh9nAqHwD2kCnN8b1IhfNc5IXwE4wG/oZPH1Q=; b=LKPrnqZymmgLXbTtTdEEJJyoa5Qz8r+qx9OuQf+o7Z1LNRzjxYMiUvZdJJBV5LBRDn A/3fHCYoWuWhFo/38UEeIxYr56x9W3PrtUzNSmyBgpLLykikX+LE14QWuEGzBSXRTgzz GtPyQfQJ4MiA0r5qyJqoiv9hjKZxdgoX0JQ2TION6flVuJ6tKSoklsgp7SRP+F6Z9phK vPD+Q/fENlBQAo/1Kn7vKgJwzyudXuJks+6ZxM9SCGPXMsLAH38x+JJKxdCLGFbbvlEe n0CjFEnmtI0uRz/L6Y8gafpXpUYk+0vjSDc+L6AOf3OnoxZ4zXoKfekwq63UPs2Bp7NQ jqHg== X-Gm-Message-State: AG10YOQ2NNheMnY8CBy70UE9JDbs5EW7E5eYrCVZZ9+Y4KqXwFyUnlcohW6pqWwAuMLJlQ== X-Received: by 10.98.44.66 with SMTP id s63mr50192286pfs.2.1454442495302; Tue, 02 Feb 2016 11:48:15 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id p20sm4441450pfi.86.2016.02.02.11.48.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Feb 2016 11:48:14 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dino Farinacci In-Reply-To: <56B105BC.7090200@joelhalpern.com> Date: Tue, 2 Feb 2016 11:48:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6846BA18-08AC-453E-896C-1238D3BE3E3F@gmail.com> References: <20160202163941.8955.70959.idtracker@ietfa.amsl.com> <56B101BB.6030802@joelhalpern.com> <92DC39B5-F1EC-4EB6-94D7-8AAC5C65611E@gmail.com> <56B105BC.7090200@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: lisp@ietf.org, The IESG , lisp-chairs@ietf.org Subject: Re: [lisp] Alvaro Retana's No Objection on charter-ietf-lisp-03-00: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 19:48:17 -0000 > Yes, we did RFC 6831. As far as I know, no one in the WG plans to = make any enhancements to that or its interaction with PIM. Agree. RFC6831 was designed and written to interwork with existing = PIM/IGMP multicast deployed at LISP sites. Dino >=20 > Yours, > Joel >=20 > On 2/2/16 2:23 PM, Dino Farinacci wrote: >>> the multicast work is reflective of a series of drafts on which the = working group is pretty close to agreement on a replication engineering = draft and a signal free draft. The replication engineering draft = mentions PIM, but does not modify or affect it in any way. And = signla-free is separate from any other working group effort. >>=20 >> And there is RFC6831. It mentions PIM in a big way. >>=20 >> Dino >>=20 From nobody Tue Feb 2 19:51:03 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5141F1B3326; Tue, 2 Feb 2016 19:51:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160203035100.21037.83397.idtracker@ietfa.amsl.com> Date: Tue, 02 Feb 2016 19:51:00 -0800 Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org Subject: [lisp] Terry Manderson's No Objection on charter-ietf-lisp-03-00: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 03:51:00 -0000 Terry Manderson has entered the following ballot position for charter-ietf-lisp-03-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-lisp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think it is appropriate to take the both the experimental RFCs with early deployment experience and develop them into PS. Can the priority of that work be highlighted in the charter as more than just the "main"? eg it IS the number one priority, forsaking all others. ... And clearly once that is achieved a charter mod can certainly occur to readdress the priority balance. My rationale is that while there may be fluctuations in the base spec there is a product/user base in existence, a following raft (10) of draft WG documents and even more Individual submissions, that could be impacted by any necessary changes in moving from Experimental to PS. I don't object to the additional scope of items, in fact I encourage it - but in a sane balance of making the base spec robust with reward of working on shiny new things in a way that informs the Experimental ==> PS tango. So these additional scope of "may" be worked need not be listed as a priority and the WG can establish its own ordering with that in mind. I concur with others, having an explicit list of the WG (or liaison group) interactions spelled out here early would be beneficial to those target WGs and the sanity of the chairs and ADs in cross area coordination. From nobody Wed Feb 3 05:52:32 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6C41AC426 for ; Wed, 3 Feb 2016 05:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjqmclMyfied for ; Wed, 3 Feb 2016 05:52:29 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id BB7431AC3EC for ; Wed, 3 Feb 2016 05:52:28 -0800 (PST) Received: from [147.83.35.39] (pcgari-i-calvet.ac.upc.es [147.83.35.39]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id u13DqS8R012693; Wed, 3 Feb 2016 14:52:28 +0100 To: Hassan Samii , "lisp@ietf.org" References: <1786526842.844836.1454432993367.JavaMail.yahoo.ref@mail.yahoo.com> <1786526842.844836.1454432993367.JavaMail.yahoo@mail.yahoo.com> From: =?UTF-8?Q?Albert_L=c3=b3pez?= Message-ID: <56B206E8.6080103@ac.upc.edu> Date: Wed, 3 Feb 2016 14:55:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <1786526842.844836.1454432993367.JavaMail.yahoo@mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------090100030505060609050807" Archived-At: Subject: Re: [lisp] LISP tool not available anymore on the webpage X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 13:52:31 -0000 This is a multi-part message in MIME format. --------------090100030505060609050807 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Hassan, Thanks for letting us know. We are looking into it at this point. We'll notify you as soon as it is up and running again. Albert On 02/02/16 18:09, Hassan Samii wrote: > Hello, > There used to be a tool with which you could see if your EID-RLOC > addresses work on the official LISP network. It used to be on the > lisp4.net website under tools at LISP Control Plane Status as viewed > from various Map Resolvers at the > following web page http://www.lisp4.net/status/ > but the webpage gives a 404 error. Will this too ever be up again? Or > has it been substituted? > Regards > Hassan > > > > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --------------090100030505060609050807 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Hassan,

Thanks for letting us know. We are looking into it at this point. We'll notify you as soon as it is up and running again.

Albert


On 02/02/16 18:09, Hassan Samii wrote:
Hello,
There used to be a tool with which you could see if your EID-RLOC addresses work on the official LISP network. It used to be on the lisp4.net website under tools at LISP Control Plane Status as viewed from various Map Resolvers at the following web page http://www.lisp4.net/status/
 but the webpage gives a 404 error. Will this too ever be up again? Or has it been substituted?
Regards
  Hassan






_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


--------------090100030505060609050807-- From nobody Wed Feb 3 07:18:51 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 101691ACE23; Wed, 3 Feb 2016 07:18:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160203151848.2111.33680.idtracker@ietfa.amsl.com> Date: Wed, 03 Feb 2016 07:18:48 -0800 Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org Subject: [lisp] Brian Haberman's No Objection on charter-ietf-lisp-03-00: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 15:18:48 -0000 Brian Haberman has entered the following ballot position for charter-ietf-lisp-03-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-lisp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Terry that priorities should be spelled out. This is important given the number of potential new work items that keep popping up on the LISP mailing list. From nobody Wed Feb 3 13:59:10 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0654C1B357E; Wed, 3 Feb 2016 13:59:05 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160203215905.3881.80821.idtracker@ietfa.amsl.com> Date: Wed, 03 Feb 2016 13:59:05 -0800 Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org, draft-ietf-lisp-threats@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [lisp] Document Action: 'LISP Threats Analysis' to Informational RFC (draft-ietf-lisp-threats-15.txt) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 21:59:05 -0000 The IESG has approved the following document: - 'LISP Threats Analysis' (draft-ietf-lisp-threats-15.txt) as Informational RFC This document is the product of the Locator/ID Separation Protocol Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-threats/ Technical Summary This document review the kinds of security threats that arise when LISP is being used. It discusses the kinds of attacks and mechanisms, so as to note clearly where LISP modifies the normal assumptions. It then discusses particular attacks that can be mounted. The document concludes with some general recommendations on deployment and configuration techniques that can ameliorate some of the attacks. Working Group Summary The document has going through multiple reviews and restructurings. The current document is very clear and readable. The documented is intended to provide information to the community, and does not modify the protocol nor mandate specific techniques. As such, the working group is requesting that this be published as an Informational RFC. In addition, there were multiple reviews by different people to ensure that the full range of threats were covered and accurately described. Finding the right wording was challenging, but was accomplished. Document Quality The shepherd has performed a final review, and agrees that this document is useful and ready for publication as an Informational RFC. Personnel Who is the Document Shepherd for this document? Joel Halpern Who is the Responsible Area Director? Deborah Brungard From nobody Wed Feb 3 15:50:05 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EF81B36F4; Wed, 3 Feb 2016 15:50:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Jari Arkko" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160203235002.11194.20571.idtracker@ietfa.amsl.com> Date: Wed, 03 Feb 2016 15:50:02 -0800 Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org Subject: [lisp] Jari Arkko's Block on charter-ietf-lisp-03-00: (with BLOCK) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 23:50:03 -0000 Jari Arkko has entered the following ballot position for charter-ietf-lisp-03-00: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-lisp/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- Thank you for formulating a proposal for LISP work to continue to next step(s). The results will be interesting, and there's a group of people interested in doing the work. The basics of the proposed charter seem good; learn from the experience and take what worked well into PS, ditch the not-so-well-worked parts, and continue some part of the work as experimental until we have more experience of it. I will support a new charter for the working group, but first I have a question that I want discuss. I do think though that we should talk about the scoping of the charter. It is quite imprecise with respect to what will be on standards track and what is not. Could that or the process leading to that decision be clarified? Or am I missing something on this late hour when I read the charter? For instance, consider taking to PS things that we have published as RFCs before (possibly modified). From nobody Wed Feb 3 16:27:20 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0921B3781; Wed, 3 Feb 2016 16:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7v6DXH9uNRD; Wed, 3 Feb 2016 16:27:14 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD69F1B3784; Wed, 3 Feb 2016 16:27:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A3A84AC040D; Wed, 3 Feb 2016 16:27:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1454545634; bh=4YWoHYx3rdICOQdPQZE+K0WYvZjkjMXEmRvxHtpknhM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ADLM98SvWZ9pDth1yroeCP00EOucbM/YQOqagckAhzxowBh7NaeX+SAvzYCOzz1wU KINrsKFptGZH0N1ZG/TBL7jTxJJViqBz2vlq7zKE4Y/mg6ztjAgNX01cGH3ClBD3/f +vYA05UNrV/gqXylhd4JraZfRIbf5SDt5hnlkksE= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 233AC1C0455; Wed, 3 Feb 2016 16:27:14 -0800 (PST) To: Jari Arkko , The IESG References: <20160203235002.11194.20571.idtracker@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <56B29AC0.7060600@joelhalpern.com> Date: Wed, 3 Feb 2016 19:26:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160203235002.11194.20571.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org Subject: Re: [lisp] Jari Arkko's Block on charter-ietf-lisp-03-00: (with BLOCK) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 00:27:16 -0000 I am not sure what you are asking for Jari. There have beeen some comments that we should make clearer that the top priority (although not preventing the WG from working on other topics) is moving the needed core documents from Experimental to PS. That change is one we can and should make. Beyond that, I don't think we want to mandate in the charter whether the other work will turn out to be experimental or standards track. Can you explain why we need to decide that status issue now? Yours, Joel On 2/3/16 6:50 PM, Jari Arkko wrote: > Jari Arkko has entered the following ballot position for > charter-ietf-lisp-03-00: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-lisp/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > Thank you for formulating a proposal for LISP work to continue to next > step(s). The results will be interesting, and there's a group of people > interested in doing the work. > > The basics of the proposed charter seem good; learn from the experience > and take what worked well into PS, ditch the not-so-well-worked parts, > and continue some part of the work as experimental until we have more > experience of it. > > I will support a new charter for the working group, but first I have a > question that I want discuss. I do think though that we should talk about > the scoping of the charter. It is quite imprecise with respect to what > will be on standards track and what is not. Could that or the process > leading to that decision be clarified? Or am I missing something on this > late hour when I read the charter? For instance, consider taking to PS > things that we have published as RFCs before (possibly modified). > > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Wed Feb 3 23:13:03 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D7E1A079D; Wed, 3 Feb 2016 23:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72lH9GLaDJKh; Wed, 3 Feb 2016 23:12:56 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id ABDBC1A047A; Wed, 3 Feb 2016 23:12:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 10F8C2CCBF; Thu, 4 Feb 2016 09:12:54 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zqB96S-cFox; Thu, 4 Feb 2016 09:12:53 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 6AC0C2CC9A; Thu, 4 Feb 2016 09:12:52 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B2EE8019-8020-405C-A672-3165F0A48179"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Jari Arkko In-Reply-To: <56B29AC0.7060600@joelhalpern.com> Date: Thu, 4 Feb 2016 08:12:35 +0100 Message-Id: References: <20160203235002.11194.20571.idtracker@ietfa.amsl.com> <56B29AC0.7060600@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: lisp-chairs@ietf.org, The IESG , lisp@ietf.org Subject: Re: [lisp] Jari Arkko's Block on charter-ietf-lisp-03-00: (with BLOCK) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 07:12:58 -0000 --Apple-Mail=_B2EE8019-8020-405C-A672-3165F0A48179 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Joel, > There have beeen some comments that we should make clearer that the = top priority (although not preventing the WG from working on other = topics) is moving the needed core documents from Experimental to PS. = That change is one we can and should make. That is ok. > Beyond that, I don't think we want to mandate in the charter whether = the other work will turn out to be experimental or standards track. Can = you explain why we need to decide that status issue now? The proposed charter has no information in this topic. It essentially = gives the issue up to the working group to decide .That may or may not = be fine, and I like the model where the working group is in charge. But = at the same time, a complete freedom makes it more difficult for anybody = at the community or the IESG to say later that wait, this particular = item shouldn=92t be on standards track. I like to think of the charter as a promise. About getting to do and = publish the work & doing within these requirements or constraints. What I am asking is some additional scoping. This could be of course a = direct spec of what is standards track and what is not in the charter. = Is that not possible then at this time? But there are of course = alternatives, as well, such stating what you know now and making changes = later; asking the working group to come to some kind of checkpoint later = when you do know and communicate with the rest of the IETF and IESG = about your suggested classification; or adding some kind of general = language to the charter about what types of results you feel are = sufficient for standards track (broad interest, experience, have = resolved all major issues, =85). My preference would be to state what is standards track right now in the = charter, if that is known. If that is not known, then we can discuss = more and figure out if, for instance, the general language approach = would help. Jari --Apple-Mail=_B2EE8019-8020-405C-A672-3165F0A48179 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWsvnkAAoJEM80gCTQU46qRAoQAIUcFhy1XB+0fDCqY3YbiOIN Gxm/TlXBCWdqxrg7rpR1GQPO1B/6kY+peG4g/zGZlvNr25dcaG65TnUj+s3mTmu2 qUZ5Bxaos1J6PMqCUyExZci4FnXqeNoP9BqparXbj04YMWNKiT3xllzYAiZXKv9C utuOZIPVrcI6PvF4he1VvlyIIwj4hFwyS5fa6ZwAtH34HYwNxGEN/U5hpFcdXugz +UDIzqTZke/zgJMdlQoZPsU9S0pDDT26FJ2qgyx0SFEa1ysYLDp+Ebl7dncU8Ok/ Ra4gvRDIILVbQxxR5L70L5Evy7vF0/JyGS7OI5V9ICKgKLKFxQiu7m64hIReIFMv AqxBrESRttcOAGDPmMLIJo9SwEFGwcBKwB/jjnMMghQ2DHitldTno0pNy5jlp/wX zyXRn03ghahc2mj9vDbP6g82IRHf4pXFblnwjG8eLtVbLefiKJ6GWJGBg3ttGeAo wGkiT7Pl/stErO7C1SGVFqKQyqpDxKn6BIsisZw/ipYv2lSgorIvd21RMA9Rg6Wa t/cx09wCgGBds0v1mPd7nsC8lcu5bk8dygDA57XPz8cVHuVE9C/GIDPKa2O+d/pV BbzXumhTIUYiqcRpSkvgoOIeWcawX5x3BpGKqV6ldW2uSHZeHiYYBqJ4orVCyhs5 Yn2R7fIr9Vc3IXzW1RUF =gDI0 -----END PGP SIGNATURE----- --Apple-Mail=_B2EE8019-8020-405C-A672-3165F0A48179-- From nobody Thu Feb 4 01:12:15 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4F11A1EF5; Thu, 4 Feb 2016 01:12:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160204091208.9791.84600.idtracker@ietfa.amsl.com> Date: Thu, 04 Feb 2016 01:12:08 -0800 Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org Subject: [lisp] Benoit Claise's No Objection on charter-ietf-lisp-03-00: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 09:12:08 -0000 Benoit Claise has entered the following ballot position for charter-ietf-lisp-03-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-lisp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - One advantage of doing a late review is that much has been said. I basically agree with all comments made the IESG so far. In particular with Jari: the charter is basically an initial promise. As such it should contain the right expectations (ex: standards track), and ideally the milestones (however, we don't have a clear consensus with the IESG on the milestones, so I won't insist). - "Besides this main focus, the LISP WG may work on the following items:" "May" is weird, when you have already adopted a WG. Ex: draft-ietf-lisp-yang-01.txt - Finally, - Management models: Support for managing the LISP protocol and deployments that include data models, as well as allowing for programmable management interfaces. These management methods should be considered for both the data-plane, control plane, and mapping system components. We speak about the management of the experimental RFCs or the new standards track document? Please clarify From nobody Thu Feb 4 06:11:41 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 288F31AC3D3; Thu, 4 Feb 2016 06:11:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160204141139.16383.25586.idtracker@ietfa.amsl.com> Date: Thu, 04 Feb 2016 06:11:39 -0800 Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org Subject: [lisp] Stephen Farrell's No Objection on charter-ietf-lisp-03-00: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 14:11:39 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-lisp-03-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-lisp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm happy to see the encryption work item. Thanks for working on that. From nobody Thu Feb 4 08:27:31 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0076E1B3282; Thu, 4 Feb 2016 08:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD5fMzdvRtET; Thu, 4 Feb 2016 08:27:19 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1776B1B3281; Thu, 4 Feb 2016 08:27:18 -0800 (PST) Received: from gw-3.ac.upc.es (gw-3.ac.upc.es [147.83.30.9]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id u14GRHVm004965; Thu, 4 Feb 2016 17:27:17 +0100 Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by gw-3.ac.upc.es (Postfix) with ESMTPSA id EB82FA5; Thu, 4 Feb 2016 17:27:16 +0100 (CET) Received: by mail-lb0-f182.google.com with SMTP id x4so34954073lbm.0; Thu, 04 Feb 2016 08:27:16 -0800 (PST) X-Gm-Message-State: AG10YOTHGKY73m75fiVeKyOLcp2vvOuTOD7a/TCrCATuH3XuIrVYxCbCACt5jstbj8PwrblNh7n9WLk09ms85w== X-Received: by 10.112.146.34 with SMTP id sz2mr3902872lbb.96.1454603236099; Thu, 04 Feb 2016 08:27:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.17.168 with HTTP; Thu, 4 Feb 2016 08:26:56 -0800 (PST) From: Alberto Rodriguez-Natal Date: Thu, 4 Feb 2016 17:26:56 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "lisp@ietf.org list" , nvo3@ietf.org, SDN IRTF list , nfvrg@irtf.org, sfc@ietf.org Content-Type: multipart/alternative; boundary=047d7b3a85c82d50dc052af43562 Archived-At: Subject: [lisp] OpenOverlayRouter released! X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 16:27:23 -0000 --047d7b3a85c82d50dc052af43562 Content-Type: text/plain; charset=UTF-8 Hi all, We would like to announce the first release of OpenOverlayRouter (OOR - spelled "double-O-R"), an open-source project, under the Apache 2.0 License, to instantiate programmable overlays. OOR is edge-oriented and multiplatform (Android, Linux and OpenWRT) with the aim to offer a flexible and easy-to-deploy overlay infrastructure. OOR is based on the former LISPmob.org code. * Who can use it * OOR is intended for end-users looking for easy multihoming, companies with strong presence at the edge, startups interested in overlay solutions and researchers exploring new scenarios. * Supported protocols * OOR is interoperable with OpenDaylight and supports several protocols for both the data and control plane. On the control plane, it supports NETCONF for provisioning and management and LISP for operational state exchange. On the data plane, it supports IPv4 and IPv6 overlays with LISP and VXLAN-GPE encapsulations. The roadmap includes L2 overlays, further encapsulations and support for SFC headers. * Code * You can find all the details and get the code at: http://openoverlayrouter.org/ Thanks! The OpenOverlayRouter team --047d7b3a85c82d50dc052af43562 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

We would like to announce the first release= of OpenOverlayRouter (OOR - spelled "double-O-R"), an open-sourc= e project, under the Apache 2.0 License, to instantiate programmable overla= ys. OOR is edge-oriented and multiplatform (Android, Linux and OpenWRT) wit= h the aim to offer a flexible and easy-to-deploy overlay infrastructure. OO= R is based on the former LISPmob.org code.


* Who can use it *
OOR is intended for end-users looking for easy multihoming, companies = with strong presence at the edge, startups interested in overlay solutions = and researchers exploring new scenarios.


* Supported protocols *=

OOR is interoperable with OpenDaylight and supports several protoco= ls for both the data and control plane. On the control plane, it supports N= ETCONF for provisioning and management and LISP for operational state excha= nge. On the data plane, it supports IPv4 and IPv6 overlays with LISP and VX= LAN-GPE encapsulations. The roadmap includes L2 overlays, further encapsula= tions and support for SFC headers.


* Code *

You can find = all the details and get the code at:
http://openoverlayrouter.org/


Thanks!
The OpenOver= layRouter team
--047d7b3a85c82d50dc052af43562-- From nobody Thu Feb 4 21:54:52 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7D61B35D7; Thu, 4 Feb 2016 21:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cM8grWqaeKVw; Thu, 4 Feb 2016 21:54:47 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0102.outbound.protection.outlook.com [104.47.0.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83831B35D1; Thu, 4 Feb 2016 21:54:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=m7DZMZf8l/ATP+auT63y0S3sT5Z1i40WaDjdBuI2zwE=; b=gWWqiFvYJIMRkZf+mCODYq33ex0t0fISrV0beTkAYoY0aIn20v4ONfpaWMuQQM8kk3AXl97jISlJWpN5UySuzv62IoKBAxFFBza6zPYoWj+xD1PIyBYlQLnoFUNpbuD2rEvhrNdtp1r5tpoPDx0ww1tp00lSRwqPSCa7g0EKq1k= Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) with Microsoft SMTP Server (TLS) id 15.1.396.15; Fri, 5 Feb 2016 05:54:44 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0396.020; Fri, 5 Feb 2016 05:54:44 +0000 From: Alexander Vainshtein To: Alberto Rodriguez-Natal , "lisp@ietf.org list" , "nvo3@ietf.org" , SDN IRTF list , "nfvrg@irtf.org" , "sfc@ietf.org" Thread-Topic: [nvo3] OpenOverlayRouter released! Thread-Index: AQHRX2jz4A1OabkdbU2B2yaF8oT/fp8c9FCs Date: Fri, 5 Feb 2016 05:54:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ac.upc.edu; dkim=none (message not signed) header.d=none;ac.upc.edu; dmarc=none action=none header.from=ecitele.com; x-originating-ip: [164.40.145.154] x-microsoft-exchange-diagnostics: 1; DB3PR03MB0780; 5:7TjDzULx2Zn6HptkpX7PJXjLOu5uGPDPo8ep/r813df8egnct3LQKCsoeZLrQhhHCO/ykPcrTvgVWBoKvMQQvezQPxvvDlEchn+g0aNBc1dpblh1yf9Jbi4ttMYpbCrJGQWypu4Ki0uJaZYCzgBOdA==; 24:44Ln6JIELgzvTdvpA2HOzlMCPO4bDxtI1W5s7J4jH4Hb+hoChJtg9e+NBRZm2DtZwoZKBv3XrNA9yl5d5RKgkhORWuC8FR8WvsD3U5ALkiA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0780; x-ms-office365-filtering-correlation-id: c4a1d411-82f6-4eb5-291e-08d32df0d931 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB3PR03MB0780; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0780; x-forefront-prvs: 0843C17679 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(53754006)(2201001)(74316001)(19617315012)(19625215002)(107886002)(1220700001)(3280700002)(87936001)(189998001)(86362001)(1096002)(102836003)(5008740100001)(19580395003)(586003)(15395725005)(5002640100001)(5001960100002)(11100500001)(16236675004)(40100003)(19580405001)(2501003)(33656002)(15975445007)(92566002)(6116002)(2950100001)(66066001)(106116001)(122556002)(50986999)(76176999)(77096005)(54356999)(3846002)(19627405001)(3660700001)(2906002)(10400500002)(226693001)(2900100001)(5004730100002)(5003600100002)(3900700001)(5001770100001)(2171001)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0780; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0780DA2CE529B076DCBBD9379DD20DB3PR03MB0780eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2016 05:54:44.8025 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0780 Archived-At: Subject: Re: [lisp] [nvo3] OpenOverlayRouter released! X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 05:54:50 -0000 --_000_DB3PR03MB0780DA2CE529B076DCBBD9379DD20DB3PR03MB0780eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is this a proper kind of message on IETF mailing lists? ________________________________ From: nvo3 on behalf of Alberto Rodriguez-Natal Sent: Thursday, February 4, 2016 6:26 PM To: lisp@ietf.org list; nvo3@ietf.org; SDN IRTF list; nfvrg@irtf.org; sfc@i= etf.org Subject: [nvo3] OpenOverlayRouter released! Hi all, We would like to announce the first release of OpenOverlayRouter (OOR - spe= lled "double-O-R"), an open-source project, under the Apache 2.0 License, t= o instantiate programmable overlays. OOR is edge-oriented and multiplatform= (Android, Linux and OpenWRT) with the aim to offer a flexible and easy-to-= deploy overlay infrastructure. OOR is based on the former LISPmob.org code. * Who can use it * OOR is intended for end-users looking for easy multihoming, companies with = strong presence at the edge, startups interested in overlay solutions and r= esearchers exploring new scenarios. * Supported protocols * OOR is interoperable with OpenDaylight and supports several protocols for b= oth the data and control plane. On the control plane, it supports NETCONF f= or provisioning and management and LISP for operational state exchange. On = the data plane, it supports IPv4 and IPv6 overlays with LISP and VXLAN-GPE = encapsulations. The roadmap includes L2 overlays, further encapsulations an= d support for SFC headers. * Code * You can find all the details and get the code at: http://openoverlayrouter.org/ Thanks! The OpenOverlayRouter team --_000_DB3PR03MB0780DA2CE529B076DCBBD9379DD20DB3PR03MB0780eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Is this a proper kind of  message on  IETF mailing lists?



From: nvo3 <nvo3-bounces= @ietf.org> on behalf of Alberto Rodriguez-Natal <arnatal@ac.upc.edu&g= t;
Sent: Thursday, February 4, 2016 6:26 PM
To: lisp@ietf.org list; nvo3@ietf.org; SDN IRTF list; nfvrg@irtf.org= ; sfc@ietf.org
Subject: [nvo3] OpenOverlayRouter released!
 
Hi all,

We would like to announce the first release of OpenOverlayRouter (OOR - spe= lled "double-O-R"), an open-source project, under the Apache 2.0 = License, to instantiate programmable overlays. OOR is edge-oriented and mul= tiplatform (Android, Linux and OpenWRT) with the aim to offer a flexible and easy-to-deploy overlay infrastructure. OOR= is based on the former LISPmob.org code.


* Who can use it *

OOR is intended for end-users looking for easy multihoming, companies with = strong presence at the edge, startups interested in overlay solutions and r= esearchers exploring new scenarios.


* Supported protocols *

OOR is interoperable with OpenDaylight and supports several protocols for b= oth the data and control plane. On the control plane, it supports NETCONF f= or provisioning and management and LISP for operational state exchange. On = the data plane, it supports IPv4 and IPv6 overlays with LISP and VXLAN-GPE encapsulations. The roadmap incl= udes L2 overlays, further encapsulations and support for SFC headers.


* Code *

You can find all the details and get the code at:
http://openoverlayrouter.org/


Thanks!
The OpenOverlayRouter team
--_000_DB3PR03MB0780DA2CE529B076DCBBD9379DD20DB3PR03MB0780eurp_-- From nobody Fri Feb 5 07:08:44 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A631B3A3E; Fri, 5 Feb 2016 07:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BLEp98-Wc1k; Fri, 5 Feb 2016 07:08:39 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196271B3A38; Fri, 5 Feb 2016 07:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17518; q=dns/txt; s=iport; t=1454684918; x=1455894518; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tNEwPRwA2KLU79mx4PYh/E9zytfHpTDsQ2gVEuIWZ7Q=; b=DG+Nrp2RSO/lhDtsgSOjlfwdCaHdxb08ZteuQ1uFWOtBP8C5KwXuMF71 sZLKTO74hv1r0Alg3obmn+yvNIQQPLHXKPB6x241x1yHw0beZ8Pu7L0+C HDufm3utsEUGoOOgSL3DZWOzEntxu5qgH/kLb81UdHhjZoWlH61ffgtcA 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSAwAOurRW/4gNJK1egm5MUl4PBoQph?= =?us-ascii?q?CyhI450dgENgWYXAQaCP4FZgVcCHIEUOBQBAQEBAQEBgQqEQQEBAQICAQEBIEs?= =?us-ascii?q?LEAIBCBEEAQEoAwICAiULFAkIAgQOBRkCiAAOsG2OZgEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARWCH4NzgW2CSoQ4AQ8XCQiCQiuBDwWWdQGFS4gEgiWMTo49AQ8PAQF?= =?us-ascii?q?CgUw3GYFIagEBAYh9fAEBAQ?= X-IronPort-AV: E=Sophos; i="5.22,401,1449532800"; d="scan'208,217"; a="74193303" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Feb 2016 15:08:37 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u15F8bbt024595 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Feb 2016 15:08:37 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 5 Feb 2016 09:08:36 -0600 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Fri, 5 Feb 2016 09:08:36 -0600 From: "Paul Quinn (paulq)" To: "Carlos Pignataro (cpignata)" Thread-Topic: [nvo3] OpenOverlayRouter released! Thread-Index: AQHRX2j1xsTPugnWN0uqwhbV/LDzPp8dWS8AgACOMACAAAyNAA== Date: Fri, 5 Feb 2016 15:08:36 +0000 Message-ID: <720EE3ED-688E-4DB5-8CF6-4B2D9F357348@cisco.com> References: <4E7E7ADA-2647-4B00-9968-36981056E8B1@cisco.com> In-Reply-To: <4E7E7ADA-2647-4B00-9968-36981056E8B1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.17.230] Content-Type: multipart/alternative; boundary="_000_720EE3ED688E4DB58CF64B2D9F357348ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Alexander Vainshtein , SDN IRTF list , "lisp@ietf.org list" , "sfc@ietf.org" , "nvo3@ietf.org" , "nfvrg@irtf.org" Subject: Re: [lisp] [nvo3] OpenOverlayRouter released! X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 15:08:40 -0000 --_000_720EE3ED688E4DB58CF64B2D9F357348ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VsbCBzYWlkIENhcmxvcyEgIENvZGUgRlRXIQ0KDQoNCk9uIEZlYiA1LCAyMDE2LCBhdCA5OjIz IEFNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhQGNpc2NvLmNvbTxtYWls dG86Y3BpZ25hdGFAY2lzY28uY29tPj4gd3JvdGU6DQoNClNhc2hhLA0KDQpJdCBzZWVtcyB0byBt ZSB0byBiZSBleHRyZW1lbHkgcmVsZXZhbnQgYW5kIHZlcnkgcHJvcGVyLCBhcyB3ZSB3YW50IG1v cmUgb3BlbiBzb3VyY2Ugc29mdHdhcmUgY29ubmVjdGlvbnMgd2l0aCB0aGUgSUVURi4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21lZXRpbmcvOTEvMjAxNC4xMS4xM19EV2FyZC1JRVRGLTkxLnBkZg0K aHR0cHM6Ly93d3cuaW50ZXJuZXRzb2NpZXR5Lm9yZy9wdWJsaWNhdGlvbnMvaWV0Zi1qb3VybmFs LW1hcmNoLTIwMTUvb3Blbi1zdGFuZGFyZHMtb3Blbi1zb3VyY2Utb3Blbi1sb29wDQoNCuKAnFdp dGhpbiB0aGUgSUVURiwgd2UgZmFjZSBudW1lcm91cyBpc3N1ZXMgYXJvdW5kIG91ciBvd24gbGlm ZSBjeWNsZS4gW+KApl0gV2hhdCBkb2VzIHRoZSBzdWJqZWN0IG1hdHRlciBvZiBwb3B1bGFyLCBu ZXR3b3JrLWNlbnRyaWMgT1NTIHByb2plY3RzIGltcGx5IG1pZ2h0IGJlIG1pc3NpbmcgYXQgdGhl IElFVEY/4oCdDQoNCuKAnEhvdyB0byBNYWtlIHRoZSBJRVRGIFJlbGV2YW50IGluIHRoaXMgRW52 aXJvbm1lbnQNCg0K4oCiIEZpeCwgY2hhbmdlLCBvciByZWludmVudCB0aGUgbGlhaXNvbiBwcm9j ZXNzIGJlY2F1c2UgaXQgd2lsbCBiZSBjcml0aWNhbCB0byBjb2xsYWJvcmF0aW9uIHdpdGggT1NT IHByb2plY3RzLiBJbiBmYWN0LCBkb27igJl0IGV2ZW4gdXNlIHRoZSBsaWFpc29uIHByb2Nlc3Mg YXMgYSBtb2RlbC4NCuKAoiBFbWJyYWNlIE9wZW4gU291cmNlIHByb2plY3RzLuKAnQ0KDQpUaGFu a3MsDQoNCuKAlCBDYXJsb3MuDQoNCg0KT24gRmViIDUsIDIwMTYsIGF0IDEyOjU0IEFNLCBBbGV4 YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRv OkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPj4gd3JvdGU6DQoNCklzIHRoaXMgYSBw cm9wZXIga2luZCBvZiAgbWVzc2FnZSBvbiAgSUVURiBtYWlsaW5nIGxpc3RzPw0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBudm8zIDxudm8zLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBBbGJlcnRv IFJvZHJpZ3Vlei1OYXRhbCA8YXJuYXRhbEBhYy51cGMuZWR1PG1haWx0bzphcm5hdGFsQGFjLnVw Yy5lZHU+Pg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDQsIDIwMTYgNjoyNiBQTQ0KVG86IGxp c3BAaWV0Zi5vcmc8bWFpbHRvOmxpc3BAaWV0Zi5vcmc+IGxpc3Q7IG52bzNAaWV0Zi5vcmc8bWFp bHRvOm52bzNAaWV0Zi5vcmc+OyBTRE4gSVJURiBsaXN0OyBuZnZyZ0BpcnRmLm9yZzxtYWlsdG86 bmZ2cmdAaXJ0Zi5vcmc+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFtudm8zXSBPcGVuT3ZlcmxheVJvdXRlciByZWxlYXNlZCENCg0KSGkgYWxsLA0KDQpXZSB3 b3VsZCBsaWtlIHRvIGFubm91bmNlIHRoZSBmaXJzdCByZWxlYXNlIG9mIE9wZW5PdmVybGF5Um91 dGVyIChPT1IgLSBzcGVsbGVkICJkb3VibGUtTy1SIiksIGFuIG9wZW4tc291cmNlIHByb2plY3Qs IHVuZGVyIHRoZSBBcGFjaGUgMi4wIExpY2Vuc2UsIHRvIGluc3RhbnRpYXRlIHByb2dyYW1tYWJs ZSBvdmVybGF5cy4gT09SIGlzIGVkZ2Utb3JpZW50ZWQgYW5kIG11bHRpcGxhdGZvcm0gKEFuZHJv aWQsIExpbnV4IGFuZCBPcGVuV1JUKSB3aXRoIHRoZSBhaW0gdG8gb2ZmZXIgYSBmbGV4aWJsZSBh bmQgZWFzeS10by1kZXBsb3kgb3ZlcmxheSBpbmZyYXN0cnVjdHVyZS4gT09SIGlzIGJhc2VkIG9u IHRoZSBmb3JtZXIgTElTUG1vYi5vcmc8aHR0cDovL2xpc3Btb2Iub3JnLz4gY29kZS4NCg0KDQoq IFdobyBjYW4gdXNlIGl0ICoNCg0KT09SIGlzIGludGVuZGVkIGZvciBlbmQtdXNlcnMgbG9va2lu ZyBmb3IgZWFzeSBtdWx0aWhvbWluZywgY29tcGFuaWVzIHdpdGggc3Ryb25nIHByZXNlbmNlIGF0 IHRoZSBlZGdlLCBzdGFydHVwcyBpbnRlcmVzdGVkIGluIG92ZXJsYXkgc29sdXRpb25zIGFuZCBy ZXNlYXJjaGVycyBleHBsb3JpbmcgbmV3IHNjZW5hcmlvcy4NCg0KDQoqIFN1cHBvcnRlZCBwcm90 b2NvbHMgKg0KDQpPT1IgaXMgaW50ZXJvcGVyYWJsZSB3aXRoIE9wZW5EYXlsaWdodCBhbmQgc3Vw cG9ydHMgc2V2ZXJhbCBwcm90b2NvbHMgZm9yIGJvdGggdGhlIGRhdGEgYW5kIGNvbnRyb2wgcGxh bmUuIE9uIHRoZSBjb250cm9sIHBsYW5lLCBpdCBzdXBwb3J0cyBORVRDT05GIGZvciBwcm92aXNp b25pbmcgYW5kIG1hbmFnZW1lbnQgYW5kIExJU1AgZm9yIG9wZXJhdGlvbmFsIHN0YXRlIGV4Y2hh bmdlLiBPbiB0aGUgZGF0YSBwbGFuZSwgaXQgc3VwcG9ydHMgSVB2NCBhbmQgSVB2NiBvdmVybGF5 cyB3aXRoIExJU1AgYW5kIFZYTEFOLUdQRSBlbmNhcHN1bGF0aW9ucy4gVGhlIHJvYWRtYXAgaW5j bHVkZXMgTDIgb3ZlcmxheXMsIGZ1cnRoZXIgZW5jYXBzdWxhdGlvbnMgYW5kIHN1cHBvcnQgZm9y IFNGQyBoZWFkZXJzLg0KDQoNCiogQ29kZSAqDQoNCllvdSBjYW4gZmluZCBhbGwgdGhlIGRldGFp bHMgYW5kIGdldCB0aGUgY29kZSBhdDoNCmh0dHA6Ly9vcGVub3ZlcmxheXJvdXRlci5vcmcvPGh0 dHA6Ly93ZWJkZWZlbmNlLmdsb2JhbC5ibGFja3NwaWRlci5jb20vdXJsd3JhcC8/cT1BWGljSmNx eERjSkFEQUJBUzB6QUl2OTVrUVlxT21vb29YSWVpN3prMkpIanZNZ2VqTVFNekJNRVY5OTJBN2NQ d09zTllMdzBxUXVUMVRCZzRhemlwaHl5RGpDbjluUTVYM09UOW1uWEFqSTlVZTVrb1dLUnFYY3Fj cVJjbkpoLXYzY2ZEekhxU0tLVmpIRXhuZjM3MVI0Ul9sYTdhaWdvJlo+DQoNCg0KVGhhbmtzIQ0K VGhlIE9wZW5PdmVybGF5Um91dGVyIHRlYW0NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpudm8zIG1haWxpbmcgbGlzdA0KbnZvM0BpZXRmLm9yZzxtYWls dG86bnZvM0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bnZvMw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bnZvMyBtYWlsaW5nIGxpc3QNCm52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCg0K --_000_720EE3ED688E4DB58CF64B2D9F357348ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KV2VsbCBzYWlkIENhcmxvcyEgJm5i c3A7Q29kZSBGVFchDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEZlYiA1LCAyMDE2LCBhdCA5OjIzIEFNLCBDYXJsb3Mg UGlnbmF0YXJvIChjcGlnbmF0YSkgJmx0OzxhIGhyZWY9Im1haWx0bzpjcGlnbmF0YUBjaXNjby5j b20iIGNsYXNzPSIiPmNwaWduYXRhQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsg LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj5TYXNoYSw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPkl0IHNlZW1zIHRvIG1lIHRvIGJlIGV4dHJlbWVseSByZWxldmFudCBh bmQgdmVyeSBwcm9wZXIsIGFzIHdlIHdhbnQgbW9yZSBvcGVuIHNvdXJjZSBzb2Z0d2FyZSBjb25u ZWN0aW9ucyB3aXRoIHRoZSBJRVRGLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzkxLzIwMTQuMTEuMTNfRFdhcmQtSUVURi05MS5wZGYi IGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21lZXRpbmcvOTEvMjAxNC4xMS4xM19EV2Fy ZC1JRVRGLTkxLnBkZjwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaW50ZXJuZXRzb2NpZXR5Lm9yZy9wdWJsaWNhdGlvbnMvaWV0Zi1qb3VybmFsLW1hcmNoLTIw MTUvb3Blbi1zdGFuZGFyZHMtb3Blbi1zb3VyY2Utb3Blbi1sb29wIiBjbGFzcz0iIj5odHRwczov L3d3dy5pbnRlcm5ldHNvY2lldHkub3JnL3B1YmxpY2F0aW9ucy9pZXRmLWpvdXJuYWwtbWFyY2gt MjAxNS9vcGVuLXN0YW5kYXJkcy1vcGVuLXNvdXJjZS1vcGVuLWxvb3A8L2E+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48aSBjbGFzcz0i Ij7igJxXaXRoaW4gdGhlIElFVEYsIHdlIGZhY2UgbnVtZXJvdXMgaXNzdWVzIGFyb3VuZCBvdXIg b3duIGxpZmUgY3ljbGUuIFvigKZdJm5ic3A7V2hhdCBkb2VzJm5ic3A7dGhlIHN1YmplY3QgbWF0 dGVyIG9mIHBvcHVsYXIsIG5ldHdvcmstY2VudHJpYyBPU1MgcHJvamVjdHMgaW1wbHkgbWlnaHQm bmJzcDtiZSBtaXNzaW5nIGF0IHRoZSBJRVRGP+KAnTwvaT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGkgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9pPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48aSBj bGFzcz0iIj7igJxIb3cgdG8gTWFrZSB0aGUgSUVURiBSZWxldmFudCBpbiB0aGlzIEVudmlyb25t ZW50PC9pPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48aSBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2k+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10 YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPuKAoiBGaXgsIGNoYW5nZSwg b3IgcmVpbnZlbnQgdGhlIGxpYWlzb24gcHJvY2VzcyBiZWNhdXNlIGl0IHdpbGwgYmUgY3JpdGlj YWwgdG8gY29sbGFib3JhdGlvbiB3aXRoIE9TUyBwcm9qZWN0cy4mbmJzcDtJbiBmYWN0LCBkb27i gJl0IGV2ZW4gdXNlIHRoZSBsaWFpc29uIHByb2Nlc3MgYXMgYSBtb2RlbC48YnIgY2xhc3M9IiI+ DQo8L2k+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxpIGNsYXNzPSIiPuKAoiBFbWJyYWNlIE9wZW4g U291cmNlIHByb2plY3RzLuKAnTwvaT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlCBDYXJsb3MuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5P biBGZWIgNSwgMjAxNiwgYXQgMTI6NTQgQU0sIEFsZXhhbmRlciBWYWluc2h0ZWluICZsdDs8YSBo cmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iIGNsYXNzPSIiPkFs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIg Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg aWQ9ImRpdnRhZ2RlZmF1bHR3cmFwcGVyIiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZvbnQt c2l6ZTogMTJwdDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIFRpbWVzLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IiBjbGFzcz0iIj5JcyB0 aGlzIGEgcHJvcGVyIGtpbmQgb2YgJm5ic3A7bWVzc2FnZSBvbiAmbmJzcDtJRVRGIG1haWxpbmcg bGlzdHM/PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSIi IGNsYXNzPSIiPg0KPGhyIHRhYmluZGV4PSItMSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZS1ibG9j azsgd2lkdGg6IDY3Ny4xNzE4NzVweDsiIGNsYXNzPSIiPg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1z ZyIgZGlyPSJsdHIiIGNsYXNzPSIiPjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYiIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5Gcm9tOjwvYj48c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+bnZvMyAmbHQ7PGEg aHJlZj0ibWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZyIgY2xhc3M9IiI+bnZvMy1ib3VuY2Vz QGlldGYub3JnPC9hPiZndDsgb24NCiBiZWhhbGYgb2YgQWxiZXJ0byBSb2RyaWd1ZXotTmF0YWwg Jmx0OzxhIGhyZWY9Im1haWx0bzphcm5hdGFsQGFjLnVwYy5lZHUiIGNsYXNzPSIiPmFybmF0YWxA YWMudXBjLmVkdTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2VudDo8L2I+PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBG ZWJydWFyeSA0LCAyMDE2IDY6MjYgUE08YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8L2I+ PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpsaXNwQGlldGYub3JnIiBjbGFzcz0iIj5saXNwQGlldGYub3JnPC9hPjxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5saXN0OzxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86bnZv M0BpZXRmLm9yZyIgY2xhc3M9IiI+bnZvM0BpZXRmLm9yZzwvYT47DQogU0ROIElSVEYgbGlzdDs8 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOm5mdnJnQGlydGYub3JnIiBjbGFzcz0iIj5uZnZyZ0BpcnRmLm9yZzwvYT47PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpzZmNAaWV0Zi5vcmciIGNsYXNzPSIiPnNmY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8 YiBjbGFzcz0iIj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+W252bzNdIE9wZW5PdmVybGF5Um91dGVyIHJlbGVhc2VkITwvZm9udD4N CjxkaXYgY2xhc3M9IiI+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGRpcj0ibHRyIiBjbGFzcz0iIj5IaSBhbGwsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K V2Ugd291bGQgbGlrZSB0byBhbm5vdW5jZSB0aGUgZmlyc3QgcmVsZWFzZSBvZiBPcGVuT3Zlcmxh eVJvdXRlciAoT09SIC0gc3BlbGxlZCAmcXVvdDtkb3VibGUtTy1SJnF1b3Q7KSwgYW4gb3Blbi1z b3VyY2UgcHJvamVjdCwgdW5kZXIgdGhlIEFwYWNoZSAyLjAgTGljZW5zZSwgdG8gaW5zdGFudGlh dGUgcHJvZ3JhbW1hYmxlIG92ZXJsYXlzLiBPT1IgaXMgZWRnZS1vcmllbnRlZCBhbmQgbXVsdGlw bGF0Zm9ybSAoQW5kcm9pZCwgTGludXggYW5kIE9wZW5XUlQpIHdpdGgNCiB0aGUgYWltIHRvIG9m ZmVyIGEgZmxleGlibGUgYW5kIGVhc3ktdG8tZGVwbG95IG92ZXJsYXkgaW5mcmFzdHJ1Y3R1cmUu IE9PUiBpcyBiYXNlZCBvbiB0aGUgZm9ybWVyPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9saXNwbW9iLm9yZy8iIGNsYXNzPSIi PkxJU1Btb2Iub3JnPC9hPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5jb2RlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CiogV2hvIGNhbiB1c2UgaXQgKjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9PUiBpcyBp bnRlbmRlZCBmb3IgZW5kLXVzZXJzIGxvb2tpbmcgZm9yIGVhc3kgbXVsdGlob21pbmcsIGNvbXBh bmllcyB3aXRoIHN0cm9uZyBwcmVzZW5jZSBhdCB0aGUgZWRnZSwgc3RhcnR1cHMgaW50ZXJlc3Rl ZCBpbiBvdmVybGF5IHNvbHV0aW9ucyBhbmQgcmVzZWFyY2hlcnMgZXhwbG9yaW5nIG5ldyBzY2Vu YXJpb3MuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKiBTdXBw b3J0ZWQgcHJvdG9jb2xzICo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPT1IgaXMgaW50 ZXJvcGVyYWJsZSB3aXRoIE9wZW5EYXlsaWdodCBhbmQgc3VwcG9ydHMgc2V2ZXJhbCBwcm90b2Nv bHMgZm9yIGJvdGggdGhlIGRhdGEgYW5kIGNvbnRyb2wgcGxhbmUuIE9uIHRoZSBjb250cm9sIHBs YW5lLCBpdCBzdXBwb3J0cyBORVRDT05GIGZvciBwcm92aXNpb25pbmcgYW5kIG1hbmFnZW1lbnQg YW5kIExJU1AgZm9yIG9wZXJhdGlvbmFsIHN0YXRlIGV4Y2hhbmdlLiBPbiB0aGUgZGF0YSBwbGFu ZSwgaXQgc3VwcG9ydHMgSVB2NA0KIGFuZCBJUHY2IG92ZXJsYXlzIHdpdGggTElTUCBhbmQgVlhM QU4tR1BFIGVuY2Fwc3VsYXRpb25zLiBUaGUgcm9hZG1hcCBpbmNsdWRlcyBMMiBvdmVybGF5cywg ZnVydGhlciBlbmNhcHN1bGF0aW9ucyBhbmQgc3VwcG9ydCBmb3IgU0ZDIGhlYWRlcnMuPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKiBDb2RlICo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpZb3UgY2FuIGZpbmQgYWxsIHRoZSBkZXRhaWxzIGFuZCBnZXQg dGhlIGNvZGUgYXQ6PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cDovL3dlYmRlZmVuY2UuZ2xv YmFsLmJsYWNrc3BpZGVyLmNvbS91cmx3cmFwLz9xPUFYaWNKY3F4RGNKQURBQkFTMHpBSXY5NWtR WXFPbW9vb1hJZWk3emsySkhqdk1nZWpNUU16Qk1FVjk5MkE3Y1B3T3NOWUx3MHFRdVQxVEJnNGF6 aXBoeXlEakNuOW5RNVgzT1Q5bW5YQWpJOVVlNWtvV0tScVhjcWNxUmNuSmgtdjNjZkR6SHFTS0tW akhFeG5mMzcxUjRSX2xhN2FpZ28mYW1wO1oiIGNsYXNzPSIiPmh0dHA6Ly9vcGVub3ZlcmxheXJv dXRlci5vcmcvPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N ClRoYW5rcyE8YnIgY2xhc3M9IiI+DQpUaGUgT3Blbk92ZXJsYXlSb3V0ZXIgdGVhbTwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNw bGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsi IGNsYXNzPSIiPm52bzMNCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9 IiI+DQo8YSBocmVmPSJtYWlsdG86bnZvM0BpZXRmLm9yZyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5u dm8zQGlldGYub3JnPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zIiBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMzwvYT48L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCm52bzMgbWFp bGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOm52bzNAaWV0Zi5vcmciIGNs YXNzPSIiPm52bzNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9udm8zPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_720EE3ED688E4DB58CF64B2D9F357348ciscocom_-- From nobody Fri Feb 5 08:39:24 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E4D1B3B45; Fri, 5 Feb 2016 08:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKdbJwyHPuQ1; Fri, 5 Feb 2016 08:39:17 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325EA1B3B30; Fri, 5 Feb 2016 08:39:17 -0800 (PST) Received: by mail-pa0-x229.google.com with SMTP id ho8so36533191pac.2; Fri, 05 Feb 2016 08:39:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hdBfi4CSJ28N3VYcOnPxJS0iXk+guQHpKfIH1M71eE8=; b=IQuBepzgpHVsIu48Q9ZOUJ4i6bW2Tf8I/juCxVKCgMLuv8PMHPUXurYHc0pmMkB+zw a/tgV5hW06ZSAYx7QiiYzV6cThU1VApxyW80C+JxDwwvfLkA4n35V1NIm6rQjRnINjDt k1/7oXjPW5wsX8KyOvGCX7hybt3coyB1KBcTenwtQPMTMZ9z7wwMu7R4+jTul285h5xY wVd6rUPIUIOrxoq8zbrl1qUH1NUXgrCaDF9wjm2wApSPVaPr8IpmNMmatEwAu4YK8100 jqiqj83GlJQS/8ozbWvIi6sBK9EKvgg0pZFqszgC4pDpabyZET6cO3UKfsj6d8/2GjXy anug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=hdBfi4CSJ28N3VYcOnPxJS0iXk+guQHpKfIH1M71eE8=; b=kNe9LxvgbhvidKvhcKDjcJUIburazY/zbr1vl7DrOtaym24riX2VY1DuwiyI7WbXg9 ws0iezfcxIMRf5JFBt5YOkSCJaMC420d5nlt9QBCThV7rCXP/6IhlXwCvJ6eogD0C6qd R6y8q931hizbXBt9kwy5+Cnoj1pofkwFuYUa+z8k1LdRtALmDsDeUjiKPO5dFTTa+BWl bsuOEqwUmPgDTsURkmdcoSUcjWfpbB0mHdbhk8t41iQl5ZWIRReqIT0mwd96iCwrnJmL kUjtc7vj5aQHn1MCJ+p/7mzZ4au3wmfgVWTRj0pE0PkPeNa9lpyWzbJI1t09eFdFeBDh 8m5A== X-Gm-Message-State: AG10YOS4iuFj8jLa+Wv1XxGazt4R6rMZHwPY+L1P9e8JVG/KjkEMFL1He2B+deaShFTztg== X-Received: by 10.66.124.164 with SMTP id mj4mr13598046pab.128.1454690356804; Fri, 05 Feb 2016 08:39:16 -0800 (PST) Received: from [10.0.0.48] (c-98-248-50-149.hsd1.ca.comcast.net. [98.248.50.149]) by smtp.gmail.com with ESMTPSA id n4sm25704772pfi.3.2016.02.05.08.39.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 08:39:15 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-6E8DDD13-52AD-4E5E-9F48-E8DB498832FB Mime-Version: 1.0 (1.0) From: Sharon X-Mailer: iPhone Mail (13D15) In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78@NJFPSRVEXG0.research.att.com> Date: Fri, 5 Feb 2016 08:39:13 -0800 Content-Transfer-Encoding: 7bit Message-Id: <8C368751-8559-414E-AA92-CBC0B32766A0@gmail.com> References: <4E7E7ADA-2647-4B00-9968-36981056E8B1@cisco.com> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78@NJFPSRVEXG0.research.att.com> To: "MORTON, ALFRED C (AL)" Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , Alexander Vainshtein , SDN IRTF list , "lisp@ietf.org list" , "sfc@ietf.org" , "nvo3@ietf.org" , "nfvrg@irtf.org" Subject: Re: [lisp] [nvo3] OpenOverlayRouter released! X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 16:39:20 -0000 --Apple-Mail-6E8DDD13-52AD-4E5E-9F48-E8DB498832FB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ++ Overlays probably the most sustainable artifact of network virtualization tr= end. Good to distill distinct overlay notions into practical code base combining t= hem. Further build from there in parallel to formal interface standardization. --szb > On Feb 5, 2016, at 6:53 AM, MORTON, ALFRED C (AL) wrote= : >=20 > +1 Carlos, and Running Code has *always* been of interest here. > Al > =20 > From: Nfvrg [mailto:nfvrg-bounces@irtf.org] On Behalf Of Carlos Pignataro (= cpignata) > Sent: Friday, February 05, 2016 9:24 AM > To: Alexander Vainshtein > Cc: SDN IRTF list; lisp@ietf.org list; sfc@ietf.org; nvo3@ietf.org; nfvrg@= irtf.org; Alberto Rodriguez-Natal > Subject: Re: [Nfvrg] [nvo3] OpenOverlayRouter released! > =20 > Sasha, > =20 > It seems to me to be extremely relevant and very proper, as we want more o= pen source software connections with the IETF. > https://www.ietf.org/meeting/91/2014.11.13_DWard-IETF-91.pdf > https://www.internetsociety.org/publications/ietf-journal-march-2015/open-= standards-open-source-open-loop > =20 > =E2=80=9CWithin the IETF, we face numerous issues around our own life cycl= e. [=E2=80=A6] What does the subject matter of popular, network-centric OSS p= rojects imply might be missing at the IETF?=E2=80=9D > =20 > =E2=80=9CHow to Make the IETF Relevant in this Environment > =20 > =E2=80=A2 Fix, change, or reinvent the liaison process because it will be c= ritical to collaboration with OSS projects. In fact, don=E2=80=99t even use t= he liaison process as a model. > =E2=80=A2 Embrace Open Source projects.=E2=80=9D > =20 > Thanks, > =20 > =E2=80=94 Carlos. > =20 > =20 > On Feb 5, 2016, at 12:54 AM, Alexander Vainshtein wrote: > =20 > Is this a proper kind of message on IETF mailing lists? > =20 >=20 > From: nvo3 on behalf of Alberto Rodriguez-Natal > Sent: Thursday, February 4, 2016 6:26 PM > To: lisp@ietf.org list; nvo3@ietf.org; SDN IRTF list; nfvrg@irtf.org; sfc@= ietf.org > Subject: [nvo3] OpenOverlayRouter released! > =20 > Hi all, >=20 > We would like to announce the first release of OpenOverlayRouter (OOR - sp= elled "double-O-R"), an open-source project, under the Apache 2.0 License, t= o instantiate programmable overlays. OOR is edge-oriented and multiplatform (= Android, Linux and OpenWRT) with the aim to offer a flexible and easy-to-dep= loy overlay infrastructure. OOR is based on the former LISPmob.org code. >=20 >=20 > * Who can use it * >=20 > OOR is intended for end-users looking for easy multihoming, companies with= strong presence at the edge, startups interested in overlay solutions and r= esearchers exploring new scenarios. >=20 >=20 > * Supported protocols * >=20 > OOR is interoperable with OpenDaylight and supports several protocols for b= oth the data and control plane. On the control plane, it supports NETCONF fo= r provisioning and management and LISP for operational state exchange. On th= e data plane, it supports IPv4 and IPv6 overlays with LISP and VXLAN-GPE enc= apsulations. The roadmap includes L2 overlays, further encapsulations and su= pport for SFC headers. >=20 >=20 > * Code * >=20 > You can find all the details and get the code at: > http://openoverlayrouter.org/ >=20 >=20 > Thanks! > The OpenOverlayRouter team > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > =20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 --Apple-Mail-6E8DDD13-52AD-4E5E-9F48-E8DB498832FB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
++
Overlays probably the most sustainable artifact of network virtualization t= rend.
Good to distill distinct overlay n= otions into practical code base combining them.
Further build from there in parallel to formal interface standardiza= tion.


--szb

On Feb= 5, 2016, at 6:53 AM, MORTON, ALFRED C (AL) <acmorton@att.com> wrote:

+1 Carlos, and Running Code has *always* been of intere= st here.

Al

 

From: Nfvrg [= mailto:nfvrg-bounces@irtf.org]= On Behalf Of Carlos Pignataro (cpignata)
Sent: Friday, Feb= ruary 05, 2016 9:24 AM
To: Alexander Vainshtein
Cc: SDN I= RTF list; lisp@ietf.org list; sfc@ietf.org; nvo= 3@ietf.org; nfvrg@irtf.org; Albert= o Rodriguez-Natal
Subject: Re: [Nfvrg] [nvo3] OpenOverlayRouter re= leased!

 <= /o:p>

Sasha,

 

It se= ems to me to be extremely relevant and very proper, as we want more open sou= rce software connections with the IETF.

 

=E2= =80=9CWithin the IETF, we face numerous issues around our own life cycle. [=E2= =80=A6] What does the subject matter of popular, network-centric O= SS projects imply might be missing at the IETF?=E2=80=9D=

 

=E2=80=9CHow to Make the IETF Relevant in this Environme= nt

 

=

=E2=80=A2 Fix, change, or reinvent the l= iaison process because it will be critical to collaboration with OSS project= s. In fact, don=E2=80=99t even use the liaison process as a model.<= o:p>

=E2=80=A2 Embrace Open So= urce projects.=E2=80=9D

=  

Thanks,

 

=E2=80=94 Carlos.

 

 

On Feb 5, 2016, at 12:54 AM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:

 

 

From: nvo3 <nv= o3-bounces@ietf.org> on behalf of Alberto Rodriguez-Natal <arnatal@ac.upc.edu>
Sent: Thursday, February 4, 2016 6= :26 PM
To: lisp@ietf.org list; = nvo3@ietf.org; SDN IRTF list; n= fvrg@irtf.org; sfc@ietf.org
Subject: [nvo3] OpenOverlayRouter released!=

 =

Hi all,

We would like to announce the first release of Ope= nOverlayRouter (OOR - spelled "double-O-R"), an open-source project, under t= he Apache 2.0 License, to instantiate programmable overlays. OOR is edge-ori= ented and multiplatform (Android, Linux and OpenWRT) with the aim to offer a= flexible and easy-to-deploy overlay infrastructure. OOR is based on the for= mer LISPmob.org = code.


* Who can use it *

OOR is intended for end-users loo= king for easy multihoming, companies with strong presence at the edge, start= ups interested in overlay solutions and researchers exploring new scenarios.=


* Supported protocols *

OOR is interoperable with OpenDay= light and supports several protocols for both the data and control plane. On= the control plane, it supports NETCONF for provisioning and management and L= ISP for operational state exchange. On the data plane, it supports IPv4 and I= Pv6 overlays with LISP and VXLAN-GPE encapsulations. The roadmap includes L2= overlays, further encapsulations and support for SFC headers.


* C= ode *

You can find all the details and get the code at:
http:= //openoverlayrouter.org/


Thanks!
The OpenOverlayRouter tea= m

_= ______________________________________________
nvo3 mailing list
nvo3@ietf.org
<= span style=3D"font-size:9.0pt;font-family:"Helvetica","sans-s= erif"">https://www.ietf.org/mailman/listinfo/nvo3=

 

___________= ____________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.or= g/mailman/listinfo/nvo3
= --Apple-Mail-6E8DDD13-52AD-4E5E-9F48-E8DB498832FB-- From nobody Sat Feb 6 10:14:39 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F117A1B2F0D; Fri, 5 Feb 2016 06:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrJPTJzws0Be; Fri, 5 Feb 2016 06:23:40 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A49A1B3961; Fri, 5 Feb 2016 06:23:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14110; q=dns/txt; s=iport; t=1454682220; x=1455891820; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3N5JfGMezz+iYGDcjCjhaQjWo+M0R5uvg4iNDOcws+g=; b=PCZ2Yjinddmp5S219EvkngrjHzP+TJ9zC9NJh8FznZh/krIg+eutd/y9 C4D8XDBUpEc77BP1uuscp0HTxMJ8C08+lXGtZWKrWW2PZpBoBReLgUDeK RpTBR4Raoo7c8ODmSsuL8z4sjwbddFM1r0QAz7uOWmXFdSeTbmGKla4Qx c=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWBABTr7RW/4kNJK1egm5MUm0GhCmEL?= =?us-ascii?q?KEjjnR2DoFmFwEGgj+BWYFXAoEwOBQBAQEBAQEBgQqEQQEBAQIBAQEBASBLCwU?= =?us-ascii?q?LAgEIEQQBAQEnAwICJwsUCQgCBA4FDgsCh3gIDrB+jmcBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQENCIIfg3OBbQiCQoQ4ASYJCIJCK4EPBZZ1AYJ9gWRqiASCJYxOjj0?= =?us-ascii?q?BDw8BQ4FMghhqAQEBiH18AQEB?= X-IronPort-AV: E=Sophos;i="5.22,400,1449532800"; d="asc'?scan'208,217";a="68336784" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Feb 2016 14:23:39 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u15ENdcC020772 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Feb 2016 14:23:39 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 5 Feb 2016 09:23:38 -0500 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Fri, 5 Feb 2016 09:23:38 -0500 From: "Carlos Pignataro (cpignata)" To: Alexander Vainshtein Thread-Topic: [nvo3] OpenOverlayRouter released! Thread-Index: AQHRX2j0avRNDVouIEKwOnMGpfvWQZ8dSGwAgACOLwA= Date: Fri, 5 Feb 2016 14:23:38 +0000 Message-ID: <4E7E7ADA-2647-4B00-9968-36981056E8B1@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.54.100] Content-Type: multipart/signed; boundary="Apple-Mail=_D2B1ACA0-B6A0-45D5-8807-216672242AB5"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 06 Feb 2016 10:14:37 -0800 Cc: SDN IRTF list , "lisp@ietf.org list" , "sfc@ietf.org" , "nvo3@ietf.org" , "nfvrg@irtf.org" Subject: Re: [lisp] [nvo3] OpenOverlayRouter released! X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 14:23:43 -0000 --Apple-Mail=_D2B1ACA0-B6A0-45D5-8807-216672242AB5 Content-Type: multipart/alternative; boundary="Apple-Mail=_44D0ACB1-6E3A-4082-9799-4FAEC4135D3A" --Apple-Mail=_44D0ACB1-6E3A-4082-9799-4FAEC4135D3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sasha, It seems to me to be extremely relevant and very proper, as we want more = open source software connections with the IETF. https://www.ietf.org/meeting/91/2014.11.13_DWard-IETF-91.pdf = = https://www.internetsociety.org/publications/ietf-journal-march-2015/open-= standards-open-source-open-loop = =E2=80=9CWithin the IETF, we face numerous issues around our own life = cycle. [=E2=80=A6] What does the subject matter of popular, = network-centric OSS projects imply might be missing at the IETF?=E2=80=9D =E2=80=9CHow to Make the IETF Relevant in this Environment =E2=80=A2 Fix, change, or reinvent the liaison process because it will = be critical to collaboration with OSS projects. In fact, don=E2=80=99t = even use the liaison process as a model. =E2=80=A2 Embrace Open Source projects.=E2=80=9D Thanks, =E2=80=94 Carlos. > On Feb 5, 2016, at 12:54 AM, Alexander Vainshtein = wrote: >=20 > Is this a proper kind of message on IETF mailing lists? >=20 >=20 > From: nvo3 > on = behalf of Alberto Rodriguez-Natal > > Sent: Thursday, February 4, 2016 6:26 PM > To: lisp@ietf.org list; nvo3@ietf.org = ; SDN IRTF list; nfvrg@irtf.org = ; sfc@ietf.org > Subject: [nvo3] OpenOverlayRouter released! >=20 > Hi all, >=20 > We would like to announce the first release of OpenOverlayRouter (OOR = - spelled "double-O-R"), an open-source project, under the Apache 2.0 = License, to instantiate programmable overlays. OOR is edge-oriented and = multiplatform (Android, Linux and OpenWRT) with the aim to offer a = flexible and easy-to-deploy overlay infrastructure. OOR is based on the = former LISPmob.org code. >=20 >=20 > * Who can use it * >=20 > OOR is intended for end-users looking for easy multihoming, companies = with strong presence at the edge, startups interested in overlay = solutions and researchers exploring new scenarios. >=20 >=20 > * Supported protocols * >=20 > OOR is interoperable with OpenDaylight and supports several protocols = for both the data and control plane. On the control plane, it supports = NETCONF for provisioning and management and LISP for operational state = exchange. On the data plane, it supports IPv4 and IPv6 overlays with = LISP and VXLAN-GPE encapsulations. The roadmap includes L2 overlays, = further encapsulations and support for SFC headers. >=20 >=20 > * Code * >=20 > You can find all the details and get the code at: > http://openoverlayrouter.org/ = >=20 >=20 > Thanks! > The OpenOverlayRouter team > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 = --Apple-Mail=_44D0ACB1-6E3A-4082-9799-4FAEC4135D3A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Sasha,

It seems to me to be extremely relevant = and very proper, as we want more open source software connections with = the IETF.
https://www.ietf.org/meeting/91/2014.11.13_DWard-IETF-91.pdf
https://www.internetsociety.org/publications/ietf-journal-march= -2015/open-standards-open-source-open-loop

=E2=80=9CWithin the IETF, = we face numerous issues around our own life cycle. [=E2=80=A6] What = does the subject matter of popular, network-centric OSS projects = imply might be missing at the IETF?=E2=80=9D

=E2=80=9CHow to Make the IETF Relevant in this = Environment

=E2=80=A2 Fix, = change, or reinvent the liaison process because it will be critical to = collaboration with OSS projects. In fact, don=E2=80=99t even use = the liaison process as a model.
=E2=80=A2 Embrace Open Source projects.=E2=80=9D

Thanks,

=E2=80=94 = Carlos.


On = Feb 5, 2016, at 12:54 AM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:

Is this a proper kind of =  message on  IETF mailing lists?


From: nvo3 <nvo3-bounces@ietf.org> on behalf of Alberto = Rodriguez-Natal <arnatal@ac.upc.edu>
Sent: Thursday, February 4, 2016 = 6:26 PM
To: lisp@ietf.org list; nvo3@ietf.org; SDN IRTF = list; nfvrg@irtf.org; sfc@ietf.org
Subject: [nvo3] OpenOverlayRouter = released!
 
Hi all,

We would = like to announce the first release of OpenOverlayRouter (OOR - spelled = "double-O-R"), an open-source project, under the Apache 2.0 License, to = instantiate programmable overlays. OOR is edge-oriented and = multiplatform (Android, Linux and OpenWRT) with the aim to offer a = flexible and easy-to-deploy overlay infrastructure. OOR is based on the = former LISPmob.org code.


* Who can use it *

OOR is intended for end-users looking for easy multihoming, = companies with strong presence at the edge, startups interested in = overlay solutions and researchers exploring new scenarios.


* Supported protocols *

OOR is interoperable with OpenDaylight and = supports several protocols for both the data and control plane. On the = control plane, it supports NETCONF for provisioning and management and = LISP for operational state exchange. On the data plane, it supports IPv4 = and IPv6 overlays with LISP and VXLAN-GPE encapsulations. The roadmap = includes L2 overlays, further encapsulations and support for SFC = headers.


* Code *

You can find all the details and get the code = at:
http://openoverlayrouter.org/


Thanks!
The OpenOverlayRouter = team
_______________________________________________
nvo3 mailing = list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

= --Apple-Mail=_44D0ACB1-6E3A-4082-9799-4FAEC4135D3A-- --Apple-Mail=_D2B1ACA0-B6A0-45D5-8807-216672242AB5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWtLBqAAoJEIXgpQGOZny9bcQQAKVwP3gVK0FjL+XNzzuYtPH6 MPTZ5NhTgV+RMaWKNnPFExfFT2SYwkSaHfrQ99yuMOyXrcbRFeh6QIbq3diNLmV+ off0eoBnHMof+rzEiR+W/Yp0PjaSmYr0iULeLiF53i/m1lAnCoyHv9tA9pqoVEbz BkWIC6fz059RgIlEdOR1R5rGO/kBjZZHqWOfRFu5xw6QVb9eWMG0l1YMIZ4r5y+r Jf74Q6ABHrHM//VSCe45wbiBnNMYCOvzUKd8/yPWTtXhj9ru2MshuvP7ZD7sA/wG Nhu6cWzb7V2NKOZF0ZeZLPeZacnFAUXLZRGGo0T3QiPk62kW14lzzMSkyK0GLRAp Nj3CnE3xZIY1GM21Sv9aRZyXcABLmybFgCTsPJR9dHAtcEP8+9u+ngsmXnLL4lhv wpQpmuXGYqUzs9Jctfhua0mJJb8QB7irqXjGl7RdFiWx7o3/UjqAVeiejsfb/kZb 2gcRFIe4xUH7JyJmsAlS3eBNHKI7ZYW6ORX9Vugl08kaaSYMhW3abRCJK7L2U7sy t2rsrQn4yEe6tFxgIHKdqH/0C+omwzgBk739yj893rHzvZADFk7nNuwc3YIyrgpl ArRx3cCe9NhYlAnFgHpq/6Q/uPssexPzwUJEGSRrmTEcxhcBvzE/f662KZXXeO9Q wMBhGfsTAZijhWuK+y3d =F6p8 -----END PGP SIGNATURE----- --Apple-Mail=_D2B1ACA0-B6A0-45D5-8807-216672242AB5-- From nobody Sat Feb 6 10:14:40 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333A61B39F9; Fri, 5 Feb 2016 06:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gey2QHOzqK-b; Fri, 5 Feb 2016 06:53:24 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id B4CD91B39F1; Fri, 5 Feb 2016 06:53:23 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id EBA441229CE; Fri, 5 Feb 2016 09:56:12 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id AE332E1008; Fri, 5 Feb 2016 09:50:16 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Fri, 5 Feb 2016 09:53:22 -0500 From: "MORTON, ALFRED C (AL)" To: "Carlos Pignataro (cpignata)" , Alexander Vainshtein Date: Fri, 5 Feb 2016 09:53:21 -0500 Thread-Topic: [nvo3] OpenOverlayRouter released! Thread-Index: AQHRX2j0avRNDVouIEKwOnMGpfvWQZ8dSGwAgACOLwD//7RG4A== Message-ID: <4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78@NJFPSRVEXG0.research.att.com> References: <4E7E7ADA-2647-4B00-9968-36981056E8B1@cisco.com> In-Reply-To: <4E7E7ADA-2647-4B00-9968-36981056E8B1@cisco.com> 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_4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78NJFPSRVEXG0re_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 06 Feb 2016 10:14:37 -0800 Cc: SDN IRTF list , "lisp@ietf.org list" , "sfc@ietf.org" , "nvo3@ietf.org" , "nfvrg@irtf.org" Subject: Re: [lisp] [nvo3] OpenOverlayRouter released! X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 14:53:26 -0000 --_000_4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78NJFPSRVEXG0re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgQ2FybG9zLCBhbmQgUnVubmluZyBDb2RlIGhhcyAqYWx3YXlzKiBiZWVuIG9mIGludGVyZXN0 IGhlcmUuDQpBbA0KDQpGcm9tOiBOZnZyZyBbbWFpbHRvOm5mdnJnLWJvdW5jZXNAaXJ0Zi5vcmdd IE9uIEJlaGFsZiBPZiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkNClNlbnQ6IEZyaWRheSwg RmVicnVhcnkgMDUsIDIwMTYgOToyNCBBTQ0KVG86IEFsZXhhbmRlciBWYWluc2h0ZWluDQpDYzog U0ROIElSVEYgbGlzdDsgbGlzcEBpZXRmLm9yZyBsaXN0OyBzZmNAaWV0Zi5vcmc7IG52bzNAaWV0 Zi5vcmc7IG5mdnJnQGlydGYub3JnOyBBbGJlcnRvIFJvZHJpZ3Vlei1OYXRhbA0KU3ViamVjdDog UmU6IFtOZnZyZ10gW252bzNdIE9wZW5PdmVybGF5Um91dGVyIHJlbGVhc2VkIQ0KDQpTYXNoYSwN Cg0KSXQgc2VlbXMgdG8gbWUgdG8gYmUgZXh0cmVtZWx5IHJlbGV2YW50IGFuZCB2ZXJ5IHByb3Bl ciwgYXMgd2Ugd2FudCBtb3JlIG9wZW4gc291cmNlIHNvZnR3YXJlIGNvbm5lY3Rpb25zIHdpdGgg dGhlIElFVEYuDQpodHRwczovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzkxLzIwMTQuMTEuMTNfRFdh cmQtSUVURi05MS5wZGYNCmh0dHBzOi8vd3d3LmludGVybmV0c29jaWV0eS5vcmcvcHVibGljYXRp b25zL2lldGYtam91cm5hbC1tYXJjaC0yMDE1L29wZW4tc3RhbmRhcmRzLW9wZW4tc291cmNlLW9w ZW4tbG9vcA0KDQrigJxXaXRoaW4gdGhlIElFVEYsIHdlIGZhY2UgbnVtZXJvdXMgaXNzdWVzIGFy b3VuZCBvdXIgb3duIGxpZmUgY3ljbGUuIFvigKZdIFdoYXQgZG9lcyB0aGUgc3ViamVjdCBtYXR0 ZXIgb2YgcG9wdWxhciwgbmV0d29yay1jZW50cmljIE9TUyBwcm9qZWN0cyBpbXBseSBtaWdodCBi ZSBtaXNzaW5nIGF0IHRoZSBJRVRGP+KAnQ0KDQrigJxIb3cgdG8gTWFrZSB0aGUgSUVURiBSZWxl dmFudCBpbiB0aGlzIEVudmlyb25tZW50DQoNCuKAoiBGaXgsIGNoYW5nZSwgb3IgcmVpbnZlbnQg dGhlIGxpYWlzb24gcHJvY2VzcyBiZWNhdXNlIGl0IHdpbGwgYmUgY3JpdGljYWwgdG8gY29sbGFi b3JhdGlvbiB3aXRoIE9TUyBwcm9qZWN0cy4gSW4gZmFjdCwgZG9u4oCZdCBldmVuIHVzZSB0aGUg bGlhaXNvbiBwcm9jZXNzIGFzIGEgbW9kZWwuDQrigKIgRW1icmFjZSBPcGVuIFNvdXJjZSBwcm9q ZWN0cy7igJ0NCg0KVGhhbmtzLA0KDQrigJQgQ2FybG9zLg0KDQoNCk9uIEZlYiA1LCAyMDE2LCBh dCAxMjo1NCBBTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+IHdyb3Rl Og0KDQpJcyB0aGlzIGEgcHJvcGVyIGtpbmQgb2YgIG1lc3NhZ2Ugb24gIElFVEYgbWFpbGluZyBs aXN0cz8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IG52bzMgPG52 bzMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVo YWxmIG9mIEFsYmVydG8gUm9kcmlndWV6LU5hdGFsIDxhcm5hdGFsQGFjLnVwYy5lZHU8bWFpbHRv OmFybmF0YWxAYWMudXBjLmVkdT4+DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgNCwgMjAxNiA2 OjI2IFBNDQpUbzogbGlzcEBpZXRmLm9yZzxtYWlsdG86bGlzcEBpZXRmLm9yZz4gbGlzdDsgbnZv M0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz47IFNETiBJUlRGIGxpc3Q7IG5mdnJnQGly dGYub3JnPG1haWx0bzpuZnZyZ0BpcnRmLm9yZz47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPg0KU3ViamVjdDogW252bzNdIE9wZW5PdmVybGF5Um91dGVyIHJlbGVhc2VkIQ0KDQpI aSBhbGwsDQoNCldlIHdvdWxkIGxpa2UgdG8gYW5ub3VuY2UgdGhlIGZpcnN0IHJlbGVhc2Ugb2Yg T3Blbk92ZXJsYXlSb3V0ZXIgKE9PUiAtIHNwZWxsZWQgImRvdWJsZS1PLVIiKSwgYW4gb3Blbi1z b3VyY2UgcHJvamVjdCwgdW5kZXIgdGhlIEFwYWNoZSAyLjAgTGljZW5zZSwgdG8gaW5zdGFudGlh dGUgcHJvZ3JhbW1hYmxlIG92ZXJsYXlzLiBPT1IgaXMgZWRnZS1vcmllbnRlZCBhbmQgbXVsdGlw bGF0Zm9ybSAoQW5kcm9pZCwgTGludXggYW5kIE9wZW5XUlQpIHdpdGggdGhlIGFpbSB0byBvZmZl ciBhIGZsZXhpYmxlIGFuZCBlYXN5LXRvLWRlcGxveSBvdmVybGF5IGluZnJhc3RydWN0dXJlLiBP T1IgaXMgYmFzZWQgb24gdGhlIGZvcm1lciBMSVNQbW9iLm9yZzxodHRwOi8vbGlzcG1vYi5vcmcv PiBjb2RlLg0KDQoNCiogV2hvIGNhbiB1c2UgaXQgKg0KDQpPT1IgaXMgaW50ZW5kZWQgZm9yIGVu ZC11c2VycyBsb29raW5nIGZvciBlYXN5IG11bHRpaG9taW5nLCBjb21wYW5pZXMgd2l0aCBzdHJv bmcgcHJlc2VuY2UgYXQgdGhlIGVkZ2UsIHN0YXJ0dXBzIGludGVyZXN0ZWQgaW4gb3ZlcmxheSBz b2x1dGlvbnMgYW5kIHJlc2VhcmNoZXJzIGV4cGxvcmluZyBuZXcgc2NlbmFyaW9zLg0KDQoNCiog U3VwcG9ydGVkIHByb3RvY29scyAqDQoNCk9PUiBpcyBpbnRlcm9wZXJhYmxlIHdpdGggT3BlbkRh eWxpZ2h0IGFuZCBzdXBwb3J0cyBzZXZlcmFsIHByb3RvY29scyBmb3IgYm90aCB0aGUgZGF0YSBh bmQgY29udHJvbCBwbGFuZS4gT24gdGhlIGNvbnRyb2wgcGxhbmUsIGl0IHN1cHBvcnRzIE5FVENP TkYgZm9yIHByb3Zpc2lvbmluZyBhbmQgbWFuYWdlbWVudCBhbmQgTElTUCBmb3Igb3BlcmF0aW9u YWwgc3RhdGUgZXhjaGFuZ2UuIE9uIHRoZSBkYXRhIHBsYW5lLCBpdCBzdXBwb3J0cyBJUHY0IGFu ZCBJUHY2IG92ZXJsYXlzIHdpdGggTElTUCBhbmQgVlhMQU4tR1BFIGVuY2Fwc3VsYXRpb25zLiBU aGUgcm9hZG1hcCBpbmNsdWRlcyBMMiBvdmVybGF5cywgZnVydGhlciBlbmNhcHN1bGF0aW9ucyBh bmQgc3VwcG9ydCBmb3IgU0ZDIGhlYWRlcnMuDQoNCg0KKiBDb2RlICoNCg0KWW91IGNhbiBmaW5k IGFsbCB0aGUgZGV0YWlscyBhbmQgZ2V0IHRoZSBjb2RlIGF0Og0KaHR0cDovL29wZW5vdmVybGF5 cm91dGVyLm9yZy88aHR0cDovL3dlYmRlZmVuY2UuZ2xvYmFsLmJsYWNrc3BpZGVyLmNvbS91cmx3 cmFwLz9xPUFYaWNKY3F4RGNKQURBQkFTMHpBSXY5NWtRWXFPbW9vb1hJZWk3emsySkhqdk1nZWpN UU16Qk1FVjk5MkE3Y1B3T3NOWUx3MHFRdVQxVEJnNGF6aXBoeXlEakNuOW5RNVgzT1Q5bW5YQWpJ OVVlNWtvV0tScVhjcWNxUmNuSmgtdjNjZkR6SHFTS0tWakhFeG5mMzcxUjRSX2xhN2FpZ28mWj4N Cg0KDQpUaGFua3MhDQpUaGUgT3Blbk92ZXJsYXlSb3V0ZXIgdGVhbQ0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm52bzMgbWFpbGluZyBsaXN0DQpudm8z QGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9udm8zDQoNCg== --_000_4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78NJFPSRVEXG0re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAy IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFwcGxlLXRh Yi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uYXBwbGUtY29u dmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxh bmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+KzEgQ2FybG9zLCBhbmQgUnVubmluZyBDb2Rl IGhhcyAqPGI+YWx3YXlzPC9iPiogYmVlbiBvZiBpbnRlcmVzdCBoZXJlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+QWw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PiBOZnZyZyBbbWFpbHRvOm5mdnJnLWJvdW5jZXNAaXJ0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8 L2I+Q2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpPGJyPjxiPlNlbnQ6PC9iPiBGcmlkYXksIEZl YnJ1YXJ5IDA1LCAyMDE2IDk6MjQgQU08YnI+PGI+VG86PC9iPiBBbGV4YW5kZXIgVmFpbnNodGVp bjxicj48Yj5DYzo8L2I+IFNETiBJUlRGIGxpc3Q7IGxpc3BAaWV0Zi5vcmcgbGlzdDsgc2ZjQGll dGYub3JnOyBudm8zQGlldGYub3JnOyBuZnZyZ0BpcnRmLm9yZzsgQWxiZXJ0byBSb2RyaWd1ZXot TmF0YWw8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbTmZ2cmddIFtudm8zXSBPcGVuT3ZlcmxheVJv dXRlciByZWxlYXNlZCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlNh c2hhLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkl0IHNlZW1zIHRvIG1l IHRvIGJlIGV4dHJlbWVseSByZWxldmFudCBhbmQgdmVyeSBwcm9wZXIsIGFzIHdlIHdhbnQgbW9y ZSBvcGVuIHNvdXJjZSBzb2Z0d2FyZSBjb25uZWN0aW9ucyB3aXRoIHRoZSBJRVRGLjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21lZXRpbmcvOTEvMjAxNC4xMS4xM19EV2FyZC1JRVRGLTkxLnBkZiI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWVldGluZy85MS8yMDE0LjExLjEzX0RXYXJkLUlFVEYtOTEucGRmPC9h PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmludGVybmV0c29jaWV0eS5vcmcvcHVibGljYXRpb25zL2lldGYtam91cm5hbC1t YXJjaC0yMDE1L29wZW4tc3RhbmRhcmRzLW9wZW4tc291cmNlLW9wZW4tbG9vcCI+aHR0cHM6Ly93 d3cuaW50ZXJuZXRzb2NpZXR5Lm9yZy9wdWJsaWNhdGlvbnMvaWV0Zi1qb3VybmFsLW1hcmNoLTIw MTUvb3Blbi1zdGFuZGFyZHMtb3Blbi1zb3VyY2Utb3Blbi1sb29wPC9hPjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxpPuKAnFdpdGhpbiB0aGUgSUVURiwgd2UgZmFjZSBu dW1lcm91cyBpc3N1ZXMgYXJvdW5kIG91ciBvd24gbGlmZSBjeWNsZS4gW+KApl0mbmJzcDtXaGF0 IGRvZXMmbmJzcDt0aGUgc3ViamVjdCBtYXR0ZXIgb2YgcG9wdWxhciwgbmV0d29yay1jZW50cmlj IE9TUyBwcm9qZWN0cyBpbXBseSBtaWdodCZuYnNwO2JlIG1pc3NpbmcgYXQgdGhlIElFVEY/4oCd PC9pPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxpPuKAnEhvdyB0byBN YWtlIHRoZSBJRVRGIFJlbGV2YW50IGluIHRoaXMgRW52aXJvbm1lbnQ8L2k+PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGk+4oCiIEZpeCwgY2hhbmdlLCBvciByZWludmVu dCB0aGUgbGlhaXNvbiBwcm9jZXNzIGJlY2F1c2UgaXQgd2lsbCBiZSBjcml0aWNhbCB0byBjb2xs YWJvcmF0aW9uIHdpdGggT1NTIHByb2plY3RzLiZuYnNwO0luIGZhY3QsIGRvbuKAmXQgZXZlbiB1 c2UgdGhlIGxpYWlzb24gcHJvY2VzcyBhcyBhIG1vZGVsLjwvaT48bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48aT7igKIgRW1icmFjZSBPcGVuIFNvdXJjZSBwcm9q ZWN0cy7igJ08L2k+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhhbmtz LDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPuKAlCBDYXJsb3MuPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGJs b2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gRmViIDUsIDIwMTYsIGF0IDEyOjU0IEFNLCBBbGV4YW5k ZXIgVmFpbnNodGVpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tIj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48ZGl2PjxkaXYgaWQ9ZGl2dGFnZGVmYXVsdHdyYXBwZXI+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPklzIHRoaXMgYSBwcm9wZXIga2luZCBvZiAm bmJzcDttZXNzYWdlIG9uICZuYnNwO0lFVEYgbWFpbGluZyBsaXN0cz88bzpwPjwvbzpwPjwvcD48 L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tn cm91bmQ6d2hpdGUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdiBjbGFzcz1Nc29Ob3Jt YWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl Jz48aHIgc2l6ZT0yIHdpZHRoPTY3NyBzdHlsZT0nd2lkdGg6NTA3LjlwdCcgYWxpZ249Y2VudGVy PjwvZGl2PjxkaXYgaWQ9ZGl2UnBseUZ3ZE1zZz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2Jh Y2tncm91bmQ6d2hpdGUnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz1h cHBsZS1jb252ZXJ0ZWQtc3BhY2U+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Jz5udm8zICZsdDs8YSBocmVmPSJtYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnIj5udm8zLWJv dW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQWxiZXJ0byBSb2RyaWd1ZXotTmF0 YWwgJmx0OzxhIGhyZWY9Im1haWx0bzphcm5hdGFsQGFjLnVwYy5lZHUiPmFybmF0YWxAYWMudXBj LmVkdTwvYT4mZ3Q7PGJyPjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1z cGFjZT4mbmJzcDs8L3NwYW4+VGh1cnNkYXksIEZlYnJ1YXJ5IDQsIDIwMTYgNjoyNiBQTTxicj48 Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86bGlzcEBpZXRmLm9yZyI+bGlzcEBpZXRmLm9yZzwvYT48c3BhbiBjbGFz cz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPmxpc3Q7PHNwYW4gY2xhc3M9YXBw bGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86bnZvM0BpZXRm Lm9yZyI+bnZvM0BpZXRmLm9yZzwvYT47IFNETiBJUlRGIGxpc3Q7PHNwYW4gY2xhc3M9YXBwbGUt Y29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86bmZ2cmdAaXJ0Zi5v cmciPm5mdnJnQGlydGYub3JnPC9hPjs8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+ Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwv YT48YnI+PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZu YnNwOzwvc3Bhbj5bbnZvM10gT3Blbk92ZXJsYXlSb3V0ZXIgcmVsZWFzZWQhPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRl Jz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz5IaSBhbGwsPGJyPjxicj5XZSB3b3VsZCBs aWtlIHRvIGFubm91bmNlIHRoZSBmaXJzdCByZWxlYXNlIG9mIE9wZW5PdmVybGF5Um91dGVyIChP T1IgLSBzcGVsbGVkICZxdW90O2RvdWJsZS1PLVImcXVvdDspLCBhbiBvcGVuLXNvdXJjZSBwcm9q ZWN0LCB1bmRlciB0aGUgQXBhY2hlIDIuMCBMaWNlbnNlLCB0byBpbnN0YW50aWF0ZSBwcm9ncmFt bWFibGUgb3ZlcmxheXMuIE9PUiBpcyBlZGdlLW9yaWVudGVkIGFuZCBtdWx0aXBsYXRmb3JtIChB bmRyb2lkLCBMaW51eCBhbmQgT3BlbldSVCkgd2l0aCB0aGUgYWltIHRvIG9mZmVyIGEgZmxleGli bGUgYW5kIGVhc3ktdG8tZGVwbG95IG92ZXJsYXkgaW5mcmFzdHJ1Y3R1cmUuIE9PUiBpcyBiYXNl ZCBvbiB0aGUgZm9ybWVyPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJodHRwOi8vbGlzcG1vYi5vcmcvIj5MSVNQbW9iLm9yZzwvYT48c3BhbiBj bGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPmNvZGUuPGJyPjxicj48YnI+ KiBXaG8gY2FuIHVzZSBpdCAqPGJyPjxicj5PT1IgaXMgaW50ZW5kZWQgZm9yIGVuZC11c2VycyBs b29raW5nIGZvciBlYXN5IG11bHRpaG9taW5nLCBjb21wYW5pZXMgd2l0aCBzdHJvbmcgcHJlc2Vu Y2UgYXQgdGhlIGVkZ2UsIHN0YXJ0dXBzIGludGVyZXN0ZWQgaW4gb3ZlcmxheSBzb2x1dGlvbnMg YW5kIHJlc2VhcmNoZXJzIGV4cGxvcmluZyBuZXcgc2NlbmFyaW9zLjxicj48YnI+PGJyPiogU3Vw cG9ydGVkIHByb3RvY29scyAqPGJyPjxicj5PT1IgaXMgaW50ZXJvcGVyYWJsZSB3aXRoIE9wZW5E YXlsaWdodCBhbmQgc3VwcG9ydHMgc2V2ZXJhbCBwcm90b2NvbHMgZm9yIGJvdGggdGhlIGRhdGEg YW5kIGNvbnRyb2wgcGxhbmUuIE9uIHRoZSBjb250cm9sIHBsYW5lLCBpdCBzdXBwb3J0cyBORVRD T05GIGZvciBwcm92aXNpb25pbmcgYW5kIG1hbmFnZW1lbnQgYW5kIExJU1AgZm9yIG9wZXJhdGlv bmFsIHN0YXRlIGV4Y2hhbmdlLiBPbiB0aGUgZGF0YSBwbGFuZSwgaXQgc3VwcG9ydHMgSVB2NCBh bmQgSVB2NiBvdmVybGF5cyB3aXRoIExJU1AgYW5kIFZYTEFOLUdQRSBlbmNhcHN1bGF0aW9ucy4g VGhlIHJvYWRtYXAgaW5jbHVkZXMgTDIgb3ZlcmxheXMsIGZ1cnRoZXIgZW5jYXBzdWxhdGlvbnMg YW5kIHN1cHBvcnQgZm9yIFNGQyBoZWFkZXJzLjxicj48YnI+PGJyPiogQ29kZSAqPGJyPjxicj5Z b3UgY2FuIGZpbmQgYWxsIHRoZSBkZXRhaWxzIGFuZCBnZXQgdGhlIGNvZGUgYXQ6PGJyPjxhIGhy ZWY9Imh0dHA6Ly93ZWJkZWZlbmNlLmdsb2JhbC5ibGFja3NwaWRlci5jb20vdXJsd3JhcC8/cT1B WGljSmNxeERjSkFEQUJBUzB6QUl2OTVrUVlxT21vb29YSWVpN3prMkpIanZNZ2VqTVFNekJNRVY5 OTJBN2NQd09zTllMdzBxUXVUMVRCZzRhemlwaHl5RGpDbjluUTVYM09UOW1uWEFqSTlVZTVrb1dL UnFYY3FjcVJjbkpoLXYzY2ZEekhxU0tLVmpIRXhuZjM3MVI0Ul9sYTdhaWdvJmFtcDtaIj5odHRw Oi8vb3Blbm92ZXJsYXlyb3V0ZXIub3JnLzwvYT48YnI+PGJyPjxicj5UaGFua3MhPGJyPlRoZSBP cGVuT3ZlcmxheVJvdXRlciB0ZWFtPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj5udm8zIG1haWxpbmcgbGlzdDxicj48L3NwYW4+PGEg aHJlZj0ibWFpbHRvOm52bzNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz5udm8zQGlldGYub3JnPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2Ei LCJzYW5zLXNlcmlmIic+PGJyPjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL252bzMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL252bzM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2tx dW90ZT48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+ PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78NJFPSRVEXG0re_-- From nobody Sun Feb 7 16:41:53 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582BD1A871A; Sun, 7 Feb 2016 16:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.257 X-Spam-Level: X-Spam-Status: No, score=-96.257 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-YI5f94TJs0; Sun, 7 Feb 2016 16:41:50 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30D01A8716; Sun, 7 Feb 2016 16:41:49 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: "'MORTON, ALFRED C \(AL\)'" , "'Carlos Pignataro \(cpignata\)'" , "'Alexander Vainshtein'" References: <4E7E7ADA-2647-4B00-9968-36981056E8B1@cisco.com> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78@NJFPSRVEXG0.research.att.com> Date: Sun, 7 Feb 2016 19:41:40 -0500 Message-ID: <00d601d16209$7a235a60$6e6a0f20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D7_01D161DF.91505FA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEa13StjE5LHmI2LycE7tADVdmQWwJuieFbAe3+c14CVq6ciqBYyiYA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'SDN IRTF list' , lisp@ietf.org, sfc@ietf.org, nvo3@ietf.org, nfvrg@irtf.org Subject: Re: [lisp] [sfc] [nvo3] OpenOverlayRouter released! X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 00:41:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D7_01D161DF.91505FA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable +1 to Al and Carlos. Running code has and should be of interest in = IETF.=20 =20 Sue=20 =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of MORTON, ALFRED C = (AL) Sent: Friday, February 05, 2016 9:53 AM To: Carlos Pignataro (cpignata); Alexander Vainshtein Cc: SDN IRTF list; lisp@ietf.org list; sfc@ietf.org; nvo3@ietf.org; = nfvrg@irtf.org; Alberto Rodriguez-Natal Subject: Re: [sfc] [nvo3] OpenOverlayRouter released! =20 +1 Carlos, and Running Code has *always* been of interest here. Al =20 From: Nfvrg [mailto:nfvrg-bounces@irtf.org] On Behalf Of Carlos = Pignataro (cpignata) Sent: Friday, February 05, 2016 9:24 AM To: Alexander Vainshtein Cc: SDN IRTF list; lisp@ietf.org list; sfc@ietf.org; nvo3@ietf.org; = nfvrg@irtf.org; Alberto Rodriguez-Natal Subject: Re: [Nfvrg] [nvo3] OpenOverlayRouter released! =20 Sasha, =20 It seems to me to be extremely relevant and very proper, as we want more = open source software connections with the IETF. https://www.ietf.org/meeting/91/2014.11.13_DWard-IETF-91.pdf https://www.internetsociety.org/publications/ietf-journal-march-2015/open= -standards-open-source-open-loop =20 =E2=80=9CWithin the IETF, we face numerous issues around our own life = cycle. [=E2=80=A6] What does the subject matter of popular, = network-centric OSS projects imply might be missing at the = IETF?=E2=80=9D =20 =E2=80=9CHow to Make the IETF Relevant in this Environment =20 =E2=80=A2 Fix, change, or reinvent the liaison process because it will = be critical to collaboration with OSS projects. In fact, don=E2=80=99t = even use the liaison process as a model. =E2=80=A2 Embrace Open Source projects.=E2=80=9D =20 Thanks, =20 =E2=80=94 Carlos. =20 =20 On Feb 5, 2016, at 12:54 AM, Alexander Vainshtein = wrote: =20 Is this a proper kind of message on IETF mailing lists? =20 _____ =20 From: nvo3 on behalf of Alberto Rodriguez-Natal = Sent: Thursday, February 4, 2016 6:26 PM To: lisp@ietf.org list; nvo3@ietf.org; SDN IRTF list; nfvrg@irtf.org; = sfc@ietf.org Subject: [nvo3] OpenOverlayRouter released! =20 Hi all, We would like to announce the first release of OpenOverlayRouter (OOR - = spelled "double-O-R"), an open-source project, under the Apache 2.0 = License, to instantiate programmable overlays. OOR is edge-oriented and = multiplatform (Android, Linux and OpenWRT) with the aim to offer a = flexible and easy-to-deploy overlay infrastructure. OOR is based on the = former LISPmob.org code. * Who can use it * OOR is intended for end-users looking for easy multihoming, companies = with strong presence at the edge, startups interested in overlay = solutions and researchers exploring new scenarios. * Supported protocols * OOR is interoperable with OpenDaylight and supports several protocols = for both the data and control plane. On the control plane, it supports = NETCONF for provisioning and management and LISP for operational state = exchange. On the data plane, it supports IPv4 and IPv6 overlays with = LISP and VXLAN-GPE encapsulations. The roadmap includes L2 overlays, = further encapsulations and support for SFC headers. * Code * You can find all the details and get the code at: http://openoverlayrouter.org/ = = Thanks! The OpenOverlayRouter team _______________________________________________ nvo3 mailing list nvo3@ietf.org = https://www.ietf.org/mailman/listinfo/nvo3 =20 ------=_NextPart_000_00D7_01D161DF.91505FA0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

+1 to Al and Carlos.=C2=A0 Running code has and should be of interest = in IETF.

 

Sue

 

From:= = sfc [mailto:sfc-bounces@ietf.org] On Behalf Of MORTON, ALFRED C = (AL)
Sent: Friday, February 05, 2016 9:53 AM
To: = Carlos Pignataro (cpignata); Alexander Vainshtein
Cc: SDN IRTF = list; lisp@ietf.org list; sfc@ietf.org; nvo3@ietf.org; nfvrg@irtf.org; = Alberto Rodriguez-Natal
Subject: Re: [sfc] [nvo3] = OpenOverlayRouter released!

 

+1 = Carlos, and Running Code has *always* been of interest = here.

Al

 

From:= = Nfvrg [mailto:nfvrg-bounces@irtf.org]= On Behalf Of Carlos Pignataro (cpignata)
Sent: Friday, = February 05, 2016 9:24 AM
To: Alexander = Vainshtein
Cc: SDN IRTF list; lisp@ietf.org list; sfc@ietf.org; nvo3@ietf.org; nfvrg@irtf.org; Alberto = Rodriguez-Natal
Subject: Re: [Nfvrg] [nvo3] OpenOverlayRouter = released!

 

Sasha,

 

It seems to me to be extremely relevant and very = proper, as we want more open source software connections with the = IETF.

 

=E2=80=9CWithin the IETF, we face numerous issues = around our own life cycle. [=E2=80=A6] What does the subject = matter of popular, network-centric OSS projects imply might be = missing at the IETF?=E2=80=9D

 

=E2=80=9CHow to Make the IETF Relevant in this = Environment

 

=E2=80=A2 Fix, change, or reinvent the liaison = process because it will be critical to collaboration with OSS = projects. In fact, don=E2=80=99t even use the liaison process as a = model.

=E2=80=A2 = Embrace Open Source projects.=E2=80=9D

 

Thanks,

 

=E2=80=94 Carlos.

 

 

On Feb 5, 2016, at 12:54 AM, Alexander Vainshtein = <Alexander.Vainshtein@eci= tele.com> wrote:

 

Is this a proper kind of  message on =  IETF mailing lists?

 

From: nvo3 = <nvo3-bounces@ietf.org> on = behalf of Alberto Rodriguez-Natal <arnatal@ac.upc.edu>
Sent:=  Thursday, February = 4, 2016 6:26 PM
To: lisp@ietf.org list; nvo3@ietf.org; SDN IRTF list; nfvrg@irtf.org; sfc@ietf.org
Subject: [nvo3] OpenOverlayRouter = released!

 

Hi all,

We would = like to announce the first release of OpenOverlayRouter (OOR - spelled = "double-O-R"), an open-source project, under the Apache 2.0 = License, to instantiate programmable overlays. OOR is edge-oriented and = multiplatform (Android, Linux and OpenWRT) with the aim to offer a = flexible and easy-to-deploy overlay infrastructure. OOR is based on the = former LISPmob.org code.


* Who can = use it *

OOR is intended for end-users looking for easy = multihoming, companies with strong presence at the edge, startups = interested in overlay solutions and researchers exploring new = scenarios.


* Supported protocols *

OOR is = interoperable with OpenDaylight and supports several protocols for both = the data and control plane. On the control plane, it supports NETCONF = for provisioning and management and LISP for operational state exchange. = On the data plane, it supports IPv4 and IPv6 overlays with LISP and = VXLAN-GPE encapsulations. The roadmap includes L2 overlays, further = encapsulations and support for SFC headers.


* Code = *

You can find all the details and get the code at:
http://openoverlayrouter.org/


Thanks!
The = OpenOverlayRouter team

__________= _____________________________________
nvo3 mailing list
nvo3@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/nvo3

 

------=_NextPart_000_00D7_01D161DF.91505FA0-- From nobody Mon Feb 15 09:07:33 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3851A8AB3; Mon, 15 Feb 2016 09:07:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160215170730.24481.67897.idtracker@ietfa.amsl.com> Date: Mon, 15 Feb 2016 09:07:30 -0800 Archived-At: Cc: draft-ietf-lisp-eid-block@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org Subject: [lisp] Spencer Dawkins' No Objection on draft-ietf-lisp-eid-block-12: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 17:07:30 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-lisp-eid-block-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Could you expand EID as EID Endpoint IDentifier in the document title? I'm seeing text that's fairly clear, but could use a native English speaker pass. For example, Transition Mechanism: The existence of a LISP specific EID block may prove useful in transition scenarios. A non-LISP domain would ask an allocation in the LISP EID block and use it to deploy ^^^ "ask for"? or "request"? LISP in its network. Such allocation will not be announced in ^^^^ "Such an"? or "This"? the BGP routing infrastructure (cf., Section 4). This approach will avoid non-LISP domains to fragment their already allocated ^^^ "fragmenting previously allocated non-LISP address space in non-LISP domains"? non-LISP addressing space, which may lead to BGP routing table inflation since it may (rightfully) be announced in the BGP ^^^^^^^^^^ "correctly"? routing infrastructure. From nobody Mon Feb 15 09:27:03 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E22611B2F9A; Mon, 15 Feb 2016 00:40:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160215084023.3188.74091.idtracker@ietfa.amsl.com> Date: Mon, 15 Feb 2016 00:40:23 -0800 Archived-At: X-Mailman-Approved-At: Mon, 15 Feb 2016 09:27:02 -0800 Cc: lisp-chairs@ietf.org, lisp@ietf.org, luigi.iannone@telecom-paristech.fr Subject: [lisp] lisp - New Meeting Session Request for IETF 95 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 08:40:24 -0000 A new meeting session request has just been submitted by Luigi Iannone, a Chair of the lisp working group. --------------------------------------------------------- Working Group Name: Locator/ID Separation Protocol Area Name: Routing Area Session Requester: Luigi Iannone Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: rtgwg nvo3 i2rs sidr grow sfc sdnrg nfvrg pim Second Priority: intarea mboned icnrg irtfopen idr spring Third Priority: l2tpext bess Special Requests: --------------------------------------------------------- From nobody Mon Feb 15 14:40:48 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B53EA1A00DB; Mon, 15 Feb 2016 14:40:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Alvaro Retana" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160215224046.28084.69566.idtracker@ietfa.amsl.com> Date: Mon, 15 Feb 2016 14:40:46 -0800 Archived-At: Cc: draft-ietf-lisp-eid-block@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org Subject: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 22:40:46 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-lisp-eid-block-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This document is clearly requesting the assignment of LISP EID space for an experiment. Why is it not an Experimental document? [I may have missed the discussion in the archive.] Along the same lines, the conditions for the experiment to be successful and the IETF to consider whether to transform the prefix into a permanent assignment (Section 6. 3+3 Allocation Plan) are not defined. How should this decision be made? How will the IETF know the experiment is successful? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- An early allocation was made in October/2015. The values should be included in the document. The dates mentioned assumed a start date of December/2015, but the document isn't getting approved until now — is there a need to change the dates? Just wondering — part of it is that I'm not sure if RIPE has already started allocating addresses or not. Please expand ROA and put in a reference. From nobody Mon Feb 15 14:42:06 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2EEF1A01A9; Mon, 15 Feb 2016 14:42:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alvaro Retana" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160215224202.25311.31160.idtracker@ietfa.amsl.com> Date: Mon, 15 Feb 2016 14:42:02 -0800 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-eid-block-mgmnt@ietf.org, lisp@ietf.org Subject: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-mgmnt-06: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 22:42:02 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-lisp-eid-block-mgmnt-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This document describes a set of guidelines that will be used in an experiment. Why is it not an Experimental document? [I may have missed the discussion in the archive.] ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In the request template, the dates should match the ones in draft-ietf-lisp-eid-block: 2018 instead of 2017 and 2021 instead of 2020. From nobody Mon Feb 15 20:23:42 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4044E1B325E; Mon, 15 Feb 2016 20:23:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160216042340.12332.23631.idtracker@ietfa.amsl.com> Date: Mon, 15 Feb 2016 20:23:40 -0800 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-eid-block-mgmnt@ietf.org, lisp@ietf.org Subject: [lisp] Spencer Dawkins' No Objection on draft-ietf-lisp-eid-block-mgmnt-06: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 04:23:40 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-lisp-eid-block-mgmnt-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I can't parse The conditions of registration renewal should no different to the conditions of registration. From nobody Tue Feb 16 00:51:13 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D4B1A0423; Tue, 16 Feb 2016 00:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AtRlV2b7TVx; Tue, 16 Feb 2016 00:51:08 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5FED1A1B23; Tue, 16 Feb 2016 00:51:04 -0800 (PST) Received: by mail-lb0-x232.google.com with SMTP id x4so91660841lbm.0; Tue, 16 Feb 2016 00:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5AKJzMzBMe2xIqZIQoe0npYXoY1IkJi/Scf/Y3+gBsw=; b=DW8MA+a9Jm88p+arGn+grviTRIz4um2eQg0Yvko7vHrdgXemjnmeIy5zxS+rHEO9Wt 9NIxWKaVNI6uvsdrXezByNzkTqCR2f6KR/HPJWXe+z6HSIm8Hxl2oqPDBVspaCaqBcoC utwsH7RdTUAvRZxCzL0kg7r5f0OTLFo1l5VIgjCX78Hs6Tijh9Kn4SeHpjqdih3ydu93 pHwAsKrGk7KqXQLxEPR453/4356iD89wOO5s+Sioq8EsyvetaiEYlr8/yChwPQaihKd0 o9AMIy4Mpt+bWRrTJkX0F0ZHMm4JuROq4Qb01D3HQMussvjCAi1dfYcWwtUxA/kjdp3T Uxmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5AKJzMzBMe2xIqZIQoe0npYXoY1IkJi/Scf/Y3+gBsw=; b=RXeG0WJM1IkKXbV9Qj/HZSkHOk0Tj0dfeP2nxL2vFnSEC37vLlA5Vj8dLT/+z7LdpB m9OQW2mPQG2ZDYvL8tOowam0kznEks7i7PFEl4+6ZclIdRPri2i1CQDt0Qz5qFz8r8rn jm/76HS0e8t6Ge7B8FCWnKN0dw+8Eej/tCwoPK3hYdwe0nNpVYSsbMVrE+Zz3jar2mn+ uAFRgkNMcTm9XSx5rBdOMfFK4aGY9r2ydYsmBOYMpKGihJBagVldUJH8pF0k1FOWHFvf wRQaOTH04xFP4MRG9lfuB03G8QxKahDtQKhbyZzi7pE0Ne1KZwtkZhHuoXXvwT7PY+aE BE7w== X-Gm-Message-State: AG10YOSqBPDkW4/Mz0n9zz43KoRHG46PCzG10FiFSAMG7YdROGa7h+g+oWeyPmHM+VgSyl5qpy788vTLGSftFQ== MIME-Version: 1.0 X-Received: by 10.112.67.1 with SMTP id j1mr7368500lbt.103.1455612662330; Tue, 16 Feb 2016 00:51:02 -0800 (PST) Received: by 10.25.205.203 with HTTP; Tue, 16 Feb 2016 00:51:02 -0800 (PST) In-Reply-To: <20160215224202.25311.31160.idtracker@ietfa.amsl.com> References: <20160215224202.25311.31160.idtracker@ietfa.amsl.com> Date: Tue, 16 Feb 2016 09:51:02 +0100 Message-ID: From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= To: Alvaro Retana Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-eid-block-mgmnt@ietf.org, "lisp@ietf.org" , The IESG Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-mgmnt-06: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 08:51:09 -0000 On Mon, Feb 15, 2016 at 11:42 PM, Alvaro Retana wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This document describes a set of guidelines that will be used in an > experiment. Why is it not an Experimental document? [I may have missed > the discussion in the archive.] That's a good question. This document is the management part extracted from the other draft so it copied the status from the other document. I guess the question is if both should change status to Experimental or if they're fine as they are? > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In the request template, the dates should match the ones in > draft-ietf-lisp-eid-block: 2018 instead of 2017 and 2021 instead of 2020. They've been edited at different times, and it is a 3year experiment so the date will have to be adjusted in both document if they're approved, before they can be published. Other document is draft-ietf-lisp-eid-block -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From nobody Tue Feb 16 02:16:20 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485181A0030 for ; Tue, 16 Feb 2016 02:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CI6ke3Cmwios for ; Tue, 16 Feb 2016 02:16:16 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43F0A1A7034 for ; Tue, 16 Feb 2016 02:16:14 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id g62so184048646wme.0 for ; Tue, 16 Feb 2016 02:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LV/NnKOm7sCgAGNZFsGVtATGPqyyB4S8I3BZmbfHvz0=; b=18w7FqISTRBExJimasznVmCUKiQDZHa+/VATqT3/Fu8Fwc3OKguwL112gABMgHgye0 1MWlkR5zzrxkgH0KZyxOgHwd/AtRttAWIDW7lJDDFcTPt9h1Fh4JvNnRzwUheGRN4beI CIrwLjixWBE0Huxcq9H77auHLMGMYQLGX708j2rev2EOUY2bVyDtjDLz2XeRG9Dj56il /QqFpfwwKdXvOHO3tFzvJcGOdZtBaD+Pm1aToHlAZ2KRQUQk79Qn0W8RSZV7uqL2rFy2 9Xvzet09M+cPzpp0ULDsefPdmZ89d1BUDHttd70fZ56s2H5Q9wC0OgM2dpNu0/tjLR7F 9fHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=LV/NnKOm7sCgAGNZFsGVtATGPqyyB4S8I3BZmbfHvz0=; b=Zxzk0Y9W9Vnr5587ui3xwIe8ZdPDlAs2C+KPhMdz/gml4yEAm07WHF6ekGtQ4DAE6N lkLOAm0UrLuAkODLZHM9WLvVkVg6KEl7OW6xx++qteLPPyC1jTNT2PGm6s+MxlTMsHJl PJkbHwQUmPCbmsZqmp74YtpT/Tj0RDt+LZTFh7+6T3z6T5zJSjsQD7uaSKFqAs+77EYm lbI7e1d7D/hULMcDjB8ZyHiExtJVqGz3Mdyvof3yohnWe3zcMqdVNml5uJdB2bG6JQzn EUv84Da3um/qNGwEIi57kOY4iwooBXnjXJoPuv9LKz9wF6/0fsSYBefSnhxe5LvnRv4w AScQ== X-Gm-Message-State: AG10YOQRYpi/Lht4qTJ41nCJnsxFjVwva8ck9SbQ3h3L9H+uPZVlbQw7GOJwKRDxniwmxA== X-Received: by 10.194.92.107 with SMTP id cl11mr24988870wjb.21.1455617772798; Tue, 16 Feb 2016 02:16:12 -0800 (PST) Received: from fatboy.ciscolive.local ([195.243.240.25]) by smtp.gmail.com with ESMTPSA id 79sm19951531wmo.7.2016.02.16.02.16.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Feb 2016 02:16:11 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: <20160215170730.24481.67897.idtracker@ietfa.amsl.com> Date: Tue, 16 Feb 2016 11:16:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160215170730.24481.67897.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.3112) Archived-At: Cc: draft-ietf-lisp-eid-block@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org, The IESG Subject: Re: [lisp] Spencer Dawkins' No Objection on draft-ietf-lisp-eid-block-12: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 10:16:17 -0000 Hi Spencer, thank you for reading so carefully the document. We certainly can expand the EID acronym in the title. We will also go over the document again trying to fix all english nits = (BTW thanks for your suggestions). ciao L. > On 15 Feb 2016, at 18:07, Spencer Dawkins = wrote: >=20 > Spencer Dawkins has entered the following ballot position for > draft-ietf-lisp-eid-block-12: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Could you expand EID as EID Endpoint IDentifier in the document title? >=20 > I'm seeing text that's fairly clear, but could use a native English > speaker pass. For example, >=20 > Transition Mechanism: The existence of a LISP specific EID block = may > prove useful in transition scenarios. A non-LISP domain would > ask an allocation in the LISP EID block and use it to deploy > ^^^ "ask for"? or "request"? > LISP in its network. Such allocation will not be announced in > ^^^^ "Such an"? or "This"? > the BGP routing infrastructure (cf., Section 4). This = approach > will avoid non-LISP domains to fragment their already = allocated > ^^^ "fragmenting previously allocated non-LISP > address=20 > space in non-LISP domains"? > non-LISP addressing space, which may lead to BGP routing table > inflation since it may (rightfully) be announced in the BGP > ^^^^^^^^^^ "correctly"? > routing infrastructure. >=20 >=20 From nobody Tue Feb 16 02:26:13 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7971B2DB6 for ; Tue, 16 Feb 2016 02:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ol9mV8rz9_KU for ; Tue, 16 Feb 2016 02:26:09 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3123A1A88D3 for ; Tue, 16 Feb 2016 02:26:07 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id g62so98697202wme.1 for ; Tue, 16 Feb 2016 02:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9GGeLYYu8ss4tPstFNrDsWKmLJP4djCS2/xHVn8fWdw=; b=GCHUl+dsx+eihNLTbrRRmjpnL/BHxFG6JRQPBo+287jueRI4QgMu7uUaGGEwq1P3xp BYxyRT2dMD6t3PdkPkmGGuaPpyr4kz33RON02ZYkW2MjGYlJzfynpypYKZahjxurX7PV y1tmzLrNaXT0mbrp9kHklT2w1x3sJmUUC0AaKZ2YiZohcazE+eQlEO2zu90wKg9otQVR yTp7LRruaIXAB1DJZ/loccskYER+ZuRyL4GSJARRuef70eAQO9ZA0h32UP6r6uS14EaP Rq4Ctmx7fGK2ZVx1f1VNMtiJmoWIOUks/87GWGMXYsA4XPecCFkq2MC/h+wMNqlXaC94 Y/yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=9GGeLYYu8ss4tPstFNrDsWKmLJP4djCS2/xHVn8fWdw=; b=mMxBIhNmE/vNw/xhTNIkbqNiVNyeHNAfJ+e2FjaPi6zXcTZu9p0z9fJjUeXyp6Q++o M7TBROT1j05YYoiyIIctxC3F0oPdezh2cuBzJusjcLSvRT1pP1zyKF6fm6PlivE1ZxNW nCSYVMY1CVJHUSLiGV6lA1lbost/7DgXkpuQvBtJYL0UxMUYz02X9Bxjsmgpk3gLi7WO MFKYjCjne+NYLJ6pLaqNt6vmMbdPp23ZjxwQgi41s5CpWoMDtQjPKx9OBw8ewbSJxBvg bhmE1s7lmak3CeMbgz8t58hBor8PYYb8wSnYpAIwbXYZ4H/5fFDkdcYPUHLrtyiSn8qB 9auw== X-Gm-Message-State: AG10YOQ3mhTMFjI0Ly4IO9meKYApW5pn7VeOLw/hiBnxnbxTTeoAPwtLAIn4If2avBwZpw== X-Received: by 10.194.190.115 with SMTP id gp19mr17048880wjc.19.1455618365816; Tue, 16 Feb 2016 02:26:05 -0800 (PST) Received: from ?IPv6:2003:8:10:8500:1df9:ebef:5c5:4a5a? ([2003:8:10:8500:1df9:ebef:5c5:4a5a]) by smtp.gmail.com with ESMTPSA id s2sm29562372wjs.39.2016.02.16.02.26.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Feb 2016 02:26:04 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: Date: Tue, 16 Feb 2016 11:26:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6376C1E6-7D8D-489D-8848-003723E3843C@gigix.net> References: <20160215224202.25311.31160.idtracker@ietfa.amsl.com> To: =?utf-8?Q?Roger_J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3112) Archived-At: Cc: lisp-chairs@ietf.org, "lisp@ietf.org" , The IESG , draft-ietf-lisp-eid-block-mgmnt@ietf.org Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-mgmnt-06: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 10:26:10 -0000 Hi Alvaro, as Roger pointed out there was no explicit discussion about = informational vs experimental. Certainly if the IESG feels that experimental is more suitable (which = actually IMHO does)=20 we can change the document intended status for both the management and = allocation documents. For the dates, they can be adjusted before going in the roc editor = queue. ciao L. > On 16 Feb 2016, at 09:51, Roger J=C3=B8rgensen = wrote: >=20 > On Mon, Feb 15, 2016 at 11:42 PM, Alvaro Retana = wrote: > >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> This document describes a set of guidelines that will be used in an >> experiment. Why is it not an Experimental document? [I may have = missed >> the discussion in the archive.] >=20 > That's a good question. This document is the management part extracted > from the other draft so it copied the status from the other document. > I guess the question is if both should change status to Experimental > or if they're fine as they are? >=20 >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> In the request template, the dates should match the ones in >> draft-ietf-lisp-eid-block: 2018 instead of 2017 and 2021 instead of = 2020. >=20 > They've been edited at different times, and it is a 3year experiment > so the date will have to be adjusted in both document if they're > approved, before they can be published. >=20 >=20 >=20 > Other document is draft-ietf-lisp-eid-block >=20 > --=20 >=20 > Roger Jorgensen | ROJO9-RIPE > rogerj@gmail.com | - IPv6 is The Key! > http://www.jorgensen.no | roger@jorgensen.no From nobody Tue Feb 16 02:28:13 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122001B2EED for ; Tue, 16 Feb 2016 02:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 839E8kviDE5m for ; Tue, 16 Feb 2016 02:28:09 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647161B2EEC for ; Tue, 16 Feb 2016 02:28:07 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id g62so184499991wme.0 for ; Tue, 16 Feb 2016 02:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0Ze5gQj7wrfzApriN/tdGCwautyGwaTS8jrw/Rr2Eck=; b=SlJXTSSULn+wQJFaCKhuwTpf2fSof8gJx24OhyLRJoNBA2G45WwrVOMKmSePK3FjaA mgJopx1av5DAIaH/Ju5+zil8Tc+y8dZMqAJsoSkhawnbbGYQMG+YG+hUjJ6TO8O5ziwx tuhw0skVKUBZ7ifaeUDjxY6wkEzL01x0yT6ye5wAdW/+BAoZa9ItkCZupZ0SSU8gLkxR 9DvALfQ2cZLxj0I4D9nlK/5poBu3W7oM4KJMK1LrNpJkwyFQPVeqDEBlNd2qlKMK+aDG 5zH3IuwmsnOCNYKs24IYs7XOPSM3HoMgBtwHYf4WiBR1Fus5kN8tdBSu0ziAD+uNmV6Q +ydw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=0Ze5gQj7wrfzApriN/tdGCwautyGwaTS8jrw/Rr2Eck=; b=mygNgAxtkIeiCsFw8LCe+niOAjHdatg6agk4tGLgecnk4KFa1l+/ToDm2c4A5GkO1b gSwLAQF8Vu0d3MJUMzfxiHmD0I21wTL0ct1nVRfztm4+48uJuu23VXQGdy/DlK0/8zGW MoGxLw2XRGmAW5heULXr90d9VWCP5Tk18VKMtWrV1/aMd4osQGE4jE58XmtSgWzyNmib TCQ60egUm9KtcVrELl/EGatJr93iCkr7vJqJfvZ24vXGz0cvWYakw9HAP3JO08leCDRc gB3LBTwBI37knhmT9zXwVExh7Zk5xS7NaSFimC2aji0eOXbMN8zLKPS2I/Hi7+hr+XU6 Sj8w== X-Gm-Message-State: AG10YOT1jjHX9dcG//GtAqCqlHFEYXZCt8sAnIgMpUF+QqTinEfZgcPU3Gec/gmGXBmR6g== X-Received: by 10.28.32.147 with SMTP id g141mr17885840wmg.19.1455618485952; Tue, 16 Feb 2016 02:28:05 -0800 (PST) Received: from ?IPv6:2003:8:10:8500:1df9:ebef:5c5:4a5a? ([2003:8:10:8500:1df9:ebef:5c5:4a5a]) by smtp.gmail.com with ESMTPSA id r10sm29483162wjz.24.2016.02.16.02.28.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Feb 2016 02:28:04 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: <20160216042340.12332.23631.idtracker@ietfa.amsl.com> Date: Tue, 16 Feb 2016 11:28:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160216042340.12332.23631.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.3112) Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-eid-block-mgmnt@ietf.org, lisp@ietf.org, The IESG Subject: Re: [lisp] Spencer Dawkins' No Objection on draft-ietf-lisp-eid-block-mgmnt-06: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 10:28:10 -0000 Yes=E2=80=A6. badly worded. The idea was that renewing the registration means that the requester = continue using the prefix in the way described at first registration = request. Wa will rephrase the sentence. ciao L. > On 16 Feb 2016, at 05:23, Spencer Dawkins = wrote: >=20 > Spencer Dawkins has entered the following ballot position for > draft-ietf-lisp-eid-block-mgmnt-06: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I can't parse=20 >=20 > The conditions of registration renewal should no different to = the > conditions of registration. >=20 >=20 From nobody Tue Feb 16 02:33:11 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316C01B2C1A for ; Tue, 16 Feb 2016 02:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNOMO_VaocsN for ; Tue, 16 Feb 2016 02:33:07 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 001F11B2C2D for ; Tue, 16 Feb 2016 02:33:04 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id g62so145635797wme.0 for ; Tue, 16 Feb 2016 02:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CYF3mkPo5JyyDLtuAbTdFq5eIMZ/3BdnK4B3eWrc7V0=; b=cPwxpOtl8f2xXxmlEEygt6f+QsllcaA0+9dcVK1SkWKhLXhBCuH2xWKf0gGENg/sIJ pIbP5xqx49NccUb8VIjcDU/TVNNjG7AORrvmws5OP4qs+xDVWQg3pQb+EV1G9FR0tgzR Dkfi0ZlSx6eqweNAcSvF3yeJOPvvCYJ5Nva8fe+nKxBs7t6RG0azZNXZmqQUhiabeH1n T96tyvOFd2oxOn6Mi1PAClMnVHCDzYBT9FcdInNTxQeJv3YYfh090BRuAv4YxhFtXn6s pLZUL/mBTewVe677KSlPAbIG7f7FnsFRNv7J1/+VxpANKHeoh8Q7VAehETp30Xxp9VKA Ns3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=CYF3mkPo5JyyDLtuAbTdFq5eIMZ/3BdnK4B3eWrc7V0=; b=RD05fLlgdUIbqxbb7Q9MSprTjoIspim/l2K51n7S4k+CrIh8uTHoi7wWDweRvK7Gtx uTpmhTO3JKTs890cmM1tkPPkmvBYzN7NL8FvP8TX04pqjLOn3gXahNbAhVWR9MSRb222 ILfD73Pke9c6lte8MyUr12XU7dyZ04h5oHAAMQVJKzrqStU8U9klEVVZvAD1OTdHgOjA 4I/siBTlplbBiqTuubuiVhx52yHl7IuqGDyvM4o6ft2sYUFqr2Br6rbGdGeT45J/QB43 rnL5FN5LEcEdrrN6QGqFgm5BJZLJVv8EUMmWzZNYdCIF9+iTvqPrZutjmAEBNL06PVd/ Fvxg== X-Gm-Message-State: AG10YOTHtjr77CDmQr+5OrMcCL4y9m1MA1b84QP+Ttwht1Zo3iI6eGFsqWYr116x+73tFA== X-Received: by 10.194.76.211 with SMTP id m19mr25563949wjw.113.1455618783591; Tue, 16 Feb 2016 02:33:03 -0800 (PST) Received: from ?IPv6:2003:8:10:8500:1df9:ebef:5c5:4a5a? ([2003:8:10:8500:1df9:ebef:5c5:4a5a]) by smtp.gmail.com with ESMTPSA id q75sm20033218wmd.6.2016.02.16.02.33.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Feb 2016 02:33:02 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: <20160215224046.28084.69566.idtracker@ietfa.amsl.com> Date: Tue, 16 Feb 2016 11:33:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1C8A2608-7564-4190-9CE6-698024EB9564@gigix.net> References: <20160215224046.28084.69566.idtracker@ietfa.amsl.com> To: Alvaro Retana X-Mailer: Apple Mail (2.3112) Archived-At: Cc: draft-ietf-lisp-eid-block@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org, The IESG Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 10:33:09 -0000 Hi Alvaro, se comments inline. > On 15 Feb 2016, at 23:40, Alvaro Retana wrote: >=20 > Alvaro Retana has entered the following ballot position for > draft-ietf-lisp-eid-block-12: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This document is clearly requesting the assignment of LISP EID space = for > an experiment. Why is it not an Experimental document? [I may have > missed the discussion in the archive.] >=20 As I replied for the management document, certainly we can go for = experimental. > Along the same lines, the conditions for the experiment to be = successful > and the IETF to consider whether to transform the prefix into a = permanent > assignment (Section 6. 3+3 Allocation Plan) are not defined. How = should > this decision be made? How will the IETF know the experiment is > successful? >=20 This is normal IETF process. LISP WG has to discuss whether or not a = permanent allocation is needed. >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > An early allocation was made in October/2015. The values should be > included in the document. Right. The allocation has been granted after the -12 has been published. We will include the values in the -13 version. >=20 > The dates mentioned assumed a start date of December/2015, but the > document isn't getting approved until now =E2=80=94 is there a need to = change the > dates? Just wondering =E2=80=94 part of it is that I'm not sure if = RIPE has > already started allocating addresses or not. >=20 We can easily shift all the timing to start at 2016. > Please expand ROA and put in a reference. >=20 >=20 Thanks. Will do. ciao L. From nobody Tue Feb 16 03:12:32 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3144D1A86FD; Tue, 16 Feb 2016 03:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHDMxW0t-w2j; Tue, 16 Feb 2016 03:12:26 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7771A3BA2; Tue, 16 Feb 2016 03:12:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1008; q=dns/txt; s=iport; t=1455621146; x=1456830746; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ddwX75ZiBOFxO7jIg4Ftz/Hdoq8/k9y9VkIBdPtXkJY=; b=jansyw+W+LoQxnwsQp+M43mkjFsZtoljM6J6t5wsOSekf7n9KJWWyiTO juwY9nD4W37oqiw/Jb4uDzhQ5jA3WHj4XRCcvV/I6QUcgurWG9qboIkWl kh77PkihFtkPRwq5crhCYzP0del3b97V04UmxQPf05AizND2trqklRFdI 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgDLA8NW/4YNJK1egzqBPwa4C4ITA?= =?us-ascii?q?Q2BZ4YNAoE7OBQBAQEBAQEBgQqEQgEBBDo/EAIBCA4oEDIlAgQOBYgauQABAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBF4YRhDWIbAEEkm+EEAGNWI5zjj8BHgEBQoICGRSBN?= =?us-ascii?q?GqHYHwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,455,1449532800"; d="scan'208";a="71819301" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Feb 2016 11:12:25 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u1GBCPmK032186 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 16 Feb 2016 11:12:25 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 16 Feb 2016 05:12:24 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Tue, 16 Feb 2016 05:12:24 -0600 From: "Alvaro Retana (aretana)" To: Luigi Iannone Thread-Topic: Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) Thread-Index: AQHRaEHsoX4wm6EbUU2zdG+H0868d58u3uQA//+3JwA= Date: Tue, 16 Feb 2016 11:12:24 +0000 Message-ID: References: <20160215224046.28084.69566.idtracker@ietfa.amsl.com> <1C8A2608-7564-4190-9CE6-698024EB9564@gigix.net> In-Reply-To: <1C8A2608-7564-4190-9CE6-698024EB9564@gigix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <04B1867E95356641B2513146E45FE7D1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-lisp-eid-block@ietf.org" , "lisp-chairs@ietf.org" , "lisp@ietf.org" , The IESG Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 11:12:28 -0000 On 2/16/16, 5:33 AM, "Luigi Iannone" wrote: Luigi: Hi! ... > >> Along the same lines, the conditions for the experiment to be successful >> and the IETF to consider whether to transform the prefix into a >>permanent >> assignment (Section 6. 3+3 Allocation Plan) are not defined. How >>should >> this decision be made? How will the IETF know the experiment is >> successful? >>=20 > >This is normal IETF process. LISP WG has to discuss whether or not a >permanent allocation is needed. I think it is fine if the lisp WG has the discussion and we go from there. I still think there should be some indication of what is success. Is it related to the number of allocations made by RIPE? Is it related to the advertisement of those allocations? The use of those allocation in production? All/none of the above? IOW, if the WG is going to have a discussion about whether to continue or not, there should be some criteria to consider. Thanks! Alvaro. From nobody Tue Feb 16 06:59:11 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258981AC3A1; Tue, 16 Feb 2016 06:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VR6yhxqs7qC3; Tue, 16 Feb 2016 06:59:04 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7D01A90BE; Tue, 16 Feb 2016 06:59:04 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 0A68B88108; Tue, 16 Feb 2016 06:59:04 -0800 (PST) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 06420328081A; Tue, 16 Feb 2016 06:59:02 -0800 (PST) To: Luigi Iannone , =?UTF-8?Q?Roger_J=c3=b8rgensen?= References: <20160215224202.25311.31160.idtracker@ietfa.amsl.com> <6376C1E6-7D8D-489D-8848-003723E3843C@gigix.net> From: Brian Haberman X-Enigmail-Draft-Status: N1110 Message-ID: <56C33930.6020900@innovationslab.net> Date: Tue, 16 Feb 2016 09:58:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <6376C1E6-7D8D-489D-8848-003723E3843C@gigix.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LF2TJOCkd0CtQhIdvKJBJHbk0JUPqTKDv" Archived-At: Cc: lisp-chairs@ietf.org, "lisp@ietf.org" , The IESG , draft-ietf-lisp-eid-block-mgmnt@ietf.org Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-mgmnt-06: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 14:59:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LF2TJOCkd0CtQhIdvKJBJHbk0JUPqTKDv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, On 2/16/16 5:26 AM, Luigi Iannone wrote: > Hi Alvaro, >=20 > as Roger pointed out there was no explicit discussion about information= al vs experimental. I believe I suggested Informational for the address block request when I was the shepherding AD for LISP. The block management draft inherited that status when it was split out. >=20 > Certainly if the IESG feels that experimental is more suitable (which a= ctually IMHO does)=20 > we can change the document intended status for both the management and = allocation documents. I didn't think Experimental was appropriate because the intent was not to describe any experimentation in the block request draft. If the IESG believes Experimental is appropriate, I would support adding text to the document that describes the exit criteria for the experiment.= >=20 > For the dates, they can be adjusted before going in the roc editor queu= e. >=20 Agreed. Brian > ciao >=20 > L. >=20 >=20 >> On 16 Feb 2016, at 09:51, Roger J=C3=B8rgensen wrot= e: >> >> On Mon, Feb 15, 2016 at 11:42 PM, Alvaro Retana wr= ote: >> >>> ---------------------------------------------------------------------= - >>> DISCUSS: >>> ---------------------------------------------------------------------= - >>> >>> This document describes a set of guidelines that will be used in an >>> experiment. Why is it not an Experimental document? [I may have mis= sed >>> the discussion in the archive.] >> >> That's a good question. This document is the management part extracted= >> from the other draft so it copied the status from the other document. >> I guess the question is if both should change status to Experimental >> or if they're fine as they are? >> >> >>> ---------------------------------------------------------------------= - >>> COMMENT: >>> ---------------------------------------------------------------------= - >>> >>> In the request template, the dates should match the ones in >>> draft-ietf-lisp-eid-block: 2018 instead of 2017 and 2021 instead of 2= 020. >> >> They've been edited at different times, and it is a 3year experiment >> so the date will have to be adjusted in both document if they're >> approved, before they can be published. >> >> >> >> Other document is draft-ietf-lisp-eid-block >> >> --=20 >> >> Roger Jorgensen | ROJO9-RIPE >> rogerj@gmail.com | - IPv6 is The Key! >> http://www.jorgensen.no | roger@jorgensen.no --LF2TJOCkd0CtQhIdvKJBJHbk0JUPqTKDv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWwzk1AAoJEBOZRqCi7goqgFoIAJrAEHe/+sNTq4ve4tnvojAb NOaUKZ3lXxA2Brbns6+NuEs9+TwsSZm79UArolZYvcXZGXtA5Vd7UkvAS5Jx3sKS Icbyu/crdx9ZprsbekOAppWT0G8Fm8kW+2SvseOHoBEQra6ldYh4OEZDwYB6nEme wXhl3zh9geWbufiNW+RjZr/G/LjZZxhj41FTW5Yy0wUbTj0imfLLsrjg172AlXRd ESd3SSiLJNZinEpoZdKifzNnPmBJb6sjP5NKnuGdk7YtkfnIohKTQ+v7GySL+zCe PP3jwNXBhLZBqhU9+RIP/Lwu5fNHDovobOiydwfmfzoLbAsM7PSkjd4VwvE2YIE= =fAPh -----END PGP SIGNATURE----- --LF2TJOCkd0CtQhIdvKJBJHbk0JUPqTKDv-- From nobody Tue Feb 16 07:04:24 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114A51ACEC5; Tue, 16 Feb 2016 07:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udwWdOIVOcq3; Tue, 16 Feb 2016 07:04:18 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA5D1ACEC0; Tue, 16 Feb 2016 07:04:18 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 5D41388108; Tue, 16 Feb 2016 07:04:18 -0800 (PST) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7A273328081A; Tue, 16 Feb 2016 07:04:17 -0800 (PST) To: "Alvaro Retana (aretana)" , Luigi Iannone References: <20160215224046.28084.69566.idtracker@ietfa.amsl.com> <1C8A2608-7564-4190-9CE6-698024EB9564@gigix.net> From: Brian Haberman Message-ID: <56C33A70.3080307@innovationslab.net> Date: Tue, 16 Feb 2016 10:04:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8c0P5cjmfmbF9c5ma0NKl3rsm5v1XQsd0" Archived-At: Cc: "draft-ietf-lisp-eid-block@ietf.org" , "lisp-chairs@ietf.org" , "lisp@ietf.org" , The IESG Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 15:04:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8c0P5cjmfmbF9c5ma0NKl3rsm5v1XQsd0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Alvaro, On 2/16/16 6:12 AM, Alvaro Retana (aretana) wrote: > On 2/16/16, 5:33 AM, "Luigi Iannone" wrote: >=20 > Luigi: >=20 > Hi! >=20 > ... >> >>> Along the same lines, the conditions for the experiment to be success= ful >>> and the IETF to consider whether to transform the prefix into a >>> permanent >>> assignment (Section 6. 3+3 Allocation Plan) are not defined. How >>> should >>> this decision be made? How will the IETF know the experiment is >>> successful? >>> >> >> This is normal IETF process. LISP WG has to discuss whether or not a >> permanent allocation is needed. >=20 > I think it is fine if the lisp WG has the discussion and we go from the= re. >=20 > I still think there should be some indication of what is success. Is i= t > related to the number of allocations made by RIPE? Is it related to the= > advertisement of those allocations? The use of those allocation in > production? All/none of the above? >=20 > IOW, if the WG is going to have a discussion about whether to continue = or > not, there should be some criteria to consider. The original request was for a permanent allocation from IANA. During the first IETF Last Call, there was significant push back on that. The result was to request a temporary allocation that expires in a set time period. After that, it would be up to the IESG to determine if the allocation should be made permanent or retired. I viewed that compromise as saying that the IESG in 2018 would determine the criteria for making the allocation permanent or not. This may be worth discussing in detail on Thursday. Regards, Brian --8c0P5cjmfmbF9c5ma0NKl3rsm5v1XQsd0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWwzpwAAoJEBOZRqCi7goqL9gH/RcwTXKLCN2LSGfk+QGjpjSr zXgNFlW1VOFQRvEWs5CIqNWMGn1fp85dwxMnDUp36UP1Q312JnOpzHLw9PqH18T8 VCRZdtRHBJMgdavMhBPBOSkenGCk3NCyqBX7nHFxAg5vugKsZUznXxUJPfsIdcoe J8R96OlLRh06iZF0GL/RSL0nzWBy2BITWx4kEaqF9IvobmJjyQ7WIRv7Kvt6pRkf ijAF0TBA2DA1ZJGNdT9DOMdGohuyTDdIt97J6+UbgGXSLRi7ehH4SAmluGzueTxr cpoWbjbVRh9fWjT/DxfjUbKmShVvQclgGptJU+zEsMWs2kdJZlRlosma8uZ74T0= =6u28 -----END PGP SIGNATURE----- --8c0P5cjmfmbF9c5ma0NKl3rsm5v1XQsd0-- From nobody Tue Feb 16 09:09:09 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DB31B30BC; Tue, 16 Feb 2016 09:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gkNDaR67Zkz; Tue, 16 Feb 2016 09:09:05 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997621B30C2; Tue, 16 Feb 2016 09:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1950; q=dns/txt; s=iport; t=1455642545; x=1456852145; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=09cO2coEtANamguO6aHtgpDBZXYrokTsDD2ZWsv9NFI=; b=ZRPEKVQ8E7HPxozQCL2ZcLNdEzGioc4JEwhwg/Lz1fusZNejPAN0mKAj LMe0pCnk16TUtEoBbGrH/EVIpR2kVJSuZbmrrE+UWnWiB8BWe8uEf0tYO +RbCcB2sbF8L9F88YS8k/yfNU414hhAo87krHCM1X6vQJi8DNSusQzkMj o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALBQBoV8NW/4oNJK1dgzqBPwa4FoIhg?= =?us-ascii?q?WeGDQKBOzoSAQEBAQEBAYEKhEIBAQQ6PxACAQgYHhAyJQIEAQ0FiBq6fwEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEXhhGENYhsAQSSb4QQAY1YjnOOPwEnAjmCAhkUgTRqh?= =?us-ascii?q?yMkGXwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,456,1449532800"; d="scan'208";a="239035033" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Feb 2016 17:09:04 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u1GH94QT026276 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 16 Feb 2016 17:09:04 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 16 Feb 2016 11:09:04 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Tue, 16 Feb 2016 11:09:04 -0600 From: "Alvaro Retana (aretana)" To: Brian Haberman , Luigi Iannone Thread-Topic: Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) Thread-Index: AQHRaEHsoX4wm6EbUU2zdG+H0868d58u3uQA//+3JwCAAJShAP//zwYA Date: Tue, 16 Feb 2016 17:09:04 +0000 Message-ID: References: <20160215224046.28084.69566.idtracker@ietfa.amsl.com> <1C8A2608-7564-4190-9CE6-698024EB9564@gigix.net> <56C33A70.3080307@innovationslab.net> In-Reply-To: <56C33A70.3080307@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-lisp-eid-block@ietf.org" , "lisp-chairs@ietf.org" , The IESG , "lisp@ietf.org" Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 17:09:09 -0000 On 2/16/16, 10:04 AM, "iesg on behalf of Brian Haberman" wrote: Brian: Hi! >Hi Alvaro, > >On 2/16/16 6:12 AM, Alvaro Retana (aretana) wrote: >> On 2/16/16, 5:33 AM, "Luigi Iannone" wrote: >>=20 >> Luigi: >>=20 >> Hi! >>=20 >> ... >>> >>>> Along the same lines, the conditions for the experiment to be >>>>successful >>>> and the IETF to consider whether to transform the prefix into a >>>> permanent >>>> assignment (Section 6. 3+3 Allocation Plan) are not defined. How >>>> should >>>> this decision be made? How will the IETF know the experiment is >>>> successful? >>>> >>> >>> This is normal IETF process. LISP WG has to discuss whether or not a >>> permanent allocation is needed. >>=20 >> I think it is fine if the lisp WG has the discussion and we go from >>there. >>=20 >> I still think there should be some indication of what is success. Is it >> related to the number of allocations made by RIPE? Is it related to the >> advertisement of those allocations? The use of those allocation in >> production? All/none of the above? >>=20 >> IOW, if the WG is going to have a discussion about whether to continue >>or >> not, there should be some criteria to consider. > >The original request was for a permanent allocation from IANA. During >the first IETF Last Call, there was significant push back on that. The >result was to request a temporary allocation that expires in a set time >period. After that, it would be up to the IESG to determine if the >allocation should be made permanent or retired. > >I viewed that compromise as saying that the IESG in 2018 would determine >the criteria for making the allocation permanent or not. This may be >worth discussing in detail on Thursday. Sure. =20 I don't feel comfortable not having a pre-determined criteria to start with. Thanks! Alvaro. From nobody Tue Feb 16 13:37:54 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527121A1ABB; Tue, 16 Feb 2016 13:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7CX2ECH60Lj; Tue, 16 Feb 2016 13:37:51 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED8F1A1A59; Tue, 16 Feb 2016 13:37:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id BBE8A24EA94; Tue, 16 Feb 2016 13:37:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1455658671; bh=mBYAeM+nWG4ybddWjbzUK2TOhjMtkDF1Fn/1JX4Nni8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=oc2GHArdqlVl7Gq3hoWH7xIyJgkW4Ec/uXf4hNhPvTrItc+cqAu1uLcUHVF7/8E3a of8JFWQebA8jn4HuseeeNhW5CouSffwTd1+Ay1KY7acyIfTkML9PWRW4VIjj+7oX+t FcsPsOQNrLGMqoCds4rWnGz1fiMdk176PMx5dXWI= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 014FE2406EC; Tue, 16 Feb 2016 13:37:50 -0800 (PST) To: "Alvaro Retana (aretana)" , Luigi Iannone References: <20160215224046.28084.69566.idtracker@ietfa.amsl.com> <1C8A2608-7564-4190-9CE6-698024EB9564@gigix.net> From: "Joel M. Halpern" Message-ID: <56C396A6.1080506@joelhalpern.com> Date: Tue, 16 Feb 2016 16:37:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-lisp-eid-block@ietf.org" , "lisp-chairs@ietf.org" , "lisp@ietf.org" , The IESG Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 21:37:53 -0000 To phrase the experiment judgment differently, either after tree years there will be sufficient demonstrated value to justify a permanent allocation, or there won't. It would take a strange situation to extend the experimental allocation (although of course we can not foresee every possible situation.) Since I do not expect the IESG to commit to specific criteria (other than those already documented in RFCs) for granting the permanent allocation, I don't see much that can be said. If you really want, I suppose that we could add a sentence saying that after the experiment, permanent allocation will be evaluated using the usual criteria for such requests. Yours, Joel On 2/16/16 6:12 AM, Alvaro Retana (aretana) wrote: > On 2/16/16, 5:33 AM, "Luigi Iannone" wrote: > > Luigi: > > Hi! > > ... >> >>> Along the same lines, the conditions for the experiment to be successful >>> and the IETF to consider whether to transform the prefix into a >>> permanent >>> assignment (Section 6. 3+3 Allocation Plan) are not defined. How >>> should >>> this decision be made? How will the IETF know the experiment is >>> successful? >>> >> >> This is normal IETF process. LISP WG has to discuss whether or not a >> permanent allocation is needed. > > I think it is fine if the lisp WG has the discussion and we go from there. > > I still think there should be some indication of what is success. Is it > related to the number of allocations made by RIPE? Is it related to the > advertisement of those allocations? The use of those allocation in > production? All/none of the above? > > IOW, if the WG is going to have a discussion about whether to continue or > not, there should be some criteria to consider. > > Thanks! > > Alvaro. > > From nobody Tue Feb 16 14:44:27 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F101A9140; Tue, 16 Feb 2016 14:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CryTWJSZ7qIP; Tue, 16 Feb 2016 14:44:20 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E471A9110; Tue, 16 Feb 2016 14:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1204; q=dns/txt; s=iport; t=1455662659; x=1456872259; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5fyBWaxXJ10T9rPGSXlp321pq7rKP+rAuPK0MjWJStA=; b=NpOZHV8Qd/73WjwUEBYIhL5y3E5r3X1ejI/+9kFOXh4885fTFAAyp1bV GZ19aIqFfi9BMDnwUzdYAM+CgLcW405derluDv6x9RkjDpnACybmtNIh8 M+QODVxykVhL9gbVAthxgr+q0yr36jp5O4sef/ypjvMkVcIwFgT+zXjiv 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgA8pcNW/5BdJa1egzqBPwa4HYITA?= =?us-ascii?q?Q2BZ4YNAoE7OBQBAQEBAQEBgQqEQgEBBDo/EAIBCDYQMiUCBAENBYgau0wBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBF4YRhDWIbAEEknCEEAGNWI5zjkABHgEBQoICGRSBN?= =?us-ascii?q?GqHKCQZfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,456,1449532800"; d="scan'208";a="239343853" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2016 22:44:18 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u1GMiIE5015776 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 16 Feb 2016 22:44:18 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 16 Feb 2016 16:44:17 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Tue, 16 Feb 2016 16:44:17 -0600 From: "Alvaro Retana (aretana)" To: "Joel M. Halpern" , Luigi Iannone Thread-Topic: Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) Thread-Index: AQHRaEHsoX4wm6EbUU2zdG+H0868d58u3uQA//+3JwCAAQKOAP//vsSA Date: Tue, 16 Feb 2016 22:44:17 +0000 Message-ID: References: <20160215224046.28084.69566.idtracker@ietfa.amsl.com> <1C8A2608-7564-4190-9CE6-698024EB9564@gigix.net> <56C396A6.1080506@joelhalpern.com> In-Reply-To: <56C396A6.1080506@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <14A0837991336E4B9CDB372DA0167FE1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-lisp-eid-block@ietf.org" , "lisp-chairs@ietf.org" , "lisp@ietf.org" , The IESG Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 22:44:22 -0000 On 2/16/16, 4:37 PM, "iesg on behalf of Joel M. Halpern" wrote: Hi! >To phrase the experiment judgment differently, either after tree years >there will be sufficient demonstrated value to justify a permanent >allocation, or there won't. It would take a strange situation to extend >the experimental allocation (although of course we can not foresee every >possible situation.) > >Since I do not expect the IESG to commit to specific criteria (other >than those already documented in RFCs) for granting the permanent >allocation, I don't see much that can be said. > >If you really want, I suppose that we could add a sentence saying that >after the experiment, permanent allocation will be evaluated using the >usual criteria for such requests. The point I'm trying to make is about the evaluation of what you call "sufficient demonstrated value". As you say, the allocation is justified if value is demonstrated, how is that value demonstrated? At this point in time the allocation is being made temporarily so that an experiment can be run. What is the success criteria for that experiment? Thanks! Alvaro. From nobody Tue Feb 16 15:53:13 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E421ACE89; Tue, 16 Feb 2016 15:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIz7RpUyBEle; Tue, 16 Feb 2016 15:53:10 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AC0B1ACE7A; Tue, 16 Feb 2016 15:53:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 05314241553; Tue, 16 Feb 2016 15:53:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1455666790; bh=JYHob9zVa2MtlMH5tnWA+AMN8q1UvVFNGKluIxGTVZk=; h=Date:Subject:From:To:Cc:From; b=oSYO5bcAkilWlPF1RMgAbhPb3MMqu22ULNdny2faXDVVk110XOE2mTr6nfwBuNJHf MaNFddjxxAtUEn5VGu1GYeSfD21xvV9gQTq0bxT3abtvGMTBI4XKXruAyP0gKRio7w PWmWdcbcvgV+rAcfF/jNQvOcJ4aJLYB2MvjCy6ZE= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [10.231.181.254] (mobile-166-171-058-042.mycingular.net [166.171.58.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 3463D240D2E; Tue, 16 Feb 2016 15:53:09 -0800 (PST) Date: Tue, 16 Feb 2016 18:53:05 -0500 Message-ID: <50sus3sgbqr0yhw275dcc7fl.1455666785804@email.android.com> Importance: normal From: "jmh.direct" To: "Alvaro Retana (aretana)" , "Joel M. Halpern" , Luigi Iannone MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_39179455904494190" Archived-At: Cc: "draft-ietf-lisp-eid-block@ietf.org" , "lisp-chairs@ietf.org" , "lisp@ietf.org" , The IESG Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 23:53:12 -0000 ----_com.samsung.android.email_39179455904494190 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBkb24ndCB0aGluayB0aGUgZnV0dXJlIElFU0cgd291bGQgYXBwcmVjaWF0ZSBpdCBpZiB3ZSB0 b2xkIHRoZW0gdGhhdCB0aGV5IG11c3QgYWxsb2NhdGUgaWYgY29uZGl0aW9uIFggaXMgbWV0LiDC oEp1c3QgYXMgdGhlIGluaXRpYWwgcmVxdWVzdCBmb3IgYSBwZXJtYW5lbnQgY29kZSBwb2ludCB3 YXMgYSBqdWRnbWVudCB4YWxsLCBzbyB3aWxsIHRoZSBmdXR1cmUgcmVxZXN0LiDCoEluIGZhY3Qs IHRvIHdyaXRlIHRoZSBjb25kaXRpb2JzLCB3ZSB3b3VsZCBoYXZlIHRvIGNvcHkgdGV4dCBmcm9t IGEgbnVtYmVyIG9mIFJGQ1MgYW5kIHRoZW4gYWRkIHNwZWNpZmljcyB0byB0aGUganVkZ2VtZW50 IGNhbGxzIHRob3NlIHByZXNjcmliZS4gwqBUaGF0IGRvZXMgbm90IHNvdW5kIGxpa2UgdGhlIHJp Z2h0IHRoaW5nIHRvIGRvLgpZb3VycyxKb2VsCgoKU2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5 IFPCriA2LCBhbiBBVCZUIDRHIExURSBzbWFydHBob25lLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2Fn ZSAtLS0tLS0tLUZyb206ICJBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSIgPGFyZXRhbmFAY2lzY28u Y29tPiBEYXRlOiAyLzE2LzIwMTYgIDU6NDQgUE0gIChHTVQtMDU6MDApIFRvOiAiSm9lbCBNLiBI YWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4sIEx1aWdpIElhbm5vbmUgPGdneEBnaWdpeC5u ZXQ+IENjOiBkcmFmdC1pZXRmLWxpc3AtZWlkLWJsb2NrQGlldGYub3JnLCBsaXNwLWNoYWlyc0Bp ZXRmLm9yZywgbGlzcEBpZXRmLm9yZywgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+LCBkYW1pZW4u c2F1Y2V6QGdtYWlsLmNvbSBTdWJqZWN0OiBSZTogQWx2YXJvIFJldGFuYSdzIERpc2N1c3Mgb24g ZHJhZnQtaWV0Zi1saXNwLWVpZC1ibG9jay0xMjogKHdpdGgKICBESVNDVVNTIGFuZCBDT01NRU5U KSAKT24gMi8xNi8xNiwgNDozNyBQTSwgImllc2cgb24gYmVoYWxmIG9mIEpvZWwgTS4gSGFscGVy biIKPGllc2ctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygam1oQGpvZWxoYWxwZXJuLmNv bT4gd3JvdGU6CgpIaSEKCj5UbyBwaHJhc2UgdGhlIGV4cGVyaW1lbnQganVkZ21lbnQgZGlmZmVy ZW50bHksIGVpdGhlciBhZnRlciB0cmVlIHllYXJzCj50aGVyZSB3aWxsIGJlIHN1ZmZpY2llbnQg ZGVtb25zdHJhdGVkIHZhbHVlIHRvIGp1c3RpZnkgYSBwZXJtYW5lbnQKPmFsbG9jYXRpb24sIG9y IHRoZXJlIHdvbid0LsKgIEl0IHdvdWxkIHRha2UgYSBzdHJhbmdlIHNpdHVhdGlvbiB0byBleHRl bmQKPnRoZSBleHBlcmltZW50YWwgYWxsb2NhdGlvbiAoYWx0aG91Z2ggb2YgY291cnNlIHdlIGNh biBub3QgZm9yZXNlZSBldmVyeQo+cG9zc2libGUgc2l0dWF0aW9uLikKPgo+U2luY2UgSSBkbyBu b3QgZXhwZWN0IHRoZSBJRVNHIHRvIGNvbW1pdCB0byBzcGVjaWZpYyBjcml0ZXJpYSAob3RoZXIK PnRoYW4gdGhvc2UgYWxyZWFkeSBkb2N1bWVudGVkIGluIFJGQ3MpIGZvciBncmFudGluZyB0aGUg cGVybWFuZW50Cj5hbGxvY2F0aW9uLCBJIGRvbid0IHNlZSBtdWNoIHRoYXQgY2FuIGJlIHNhaWQu Cj4KPklmIHlvdSByZWFsbHkgd2FudCwgSSBzdXBwb3NlIHRoYXQgd2UgY291bGQgYWRkIGEgc2Vu dGVuY2Ugc2F5aW5nIHRoYXQKPmFmdGVyIHRoZSBleHBlcmltZW50LCBwZXJtYW5lbnQgYWxsb2Nh dGlvbiB3aWxsIGJlIGV2YWx1YXRlZCB1c2luZyB0aGUKPnVzdWFsIGNyaXRlcmlhIGZvciBzdWNo IHJlcXVlc3RzLgoKVGhlIHBvaW50IEknbSB0cnlpbmcgdG8gbWFrZSBpcyBhYm91dCB0aGUgZXZh bHVhdGlvbiBvZiB3aGF0IHlvdSBjYWxsCiJzdWZmaWNpZW50IGRlbW9uc3RyYXRlZCB2YWx1ZSIu wqAgQXMgeW91IHNheSwgdGhlIGFsbG9jYXRpb24gaXMganVzdGlmaWVkCmlmIHZhbHVlIGlzIGRl bW9uc3RyYXRlZCwgaG93IGlzIHRoYXQgdmFsdWUgZGVtb25zdHJhdGVkPwoKQXQgdGhpcyBwb2lu dCBpbiB0aW1lIHRoZSBhbGxvY2F0aW9uIGlzIGJlaW5nIG1hZGUgdGVtcG9yYXJpbHkgc28gdGhh dCBhbgpleHBlcmltZW50IGNhbiBiZSBydW4uwqAgV2hhdCBpcyB0aGUgc3VjY2VzcyBjcml0ZXJp YSBmb3IgdGhhdCBleHBlcmltZW50PwoKVGhhbmtzIQoKQWx2YXJvLgoK ----_com.samsung.android.email_39179455904494190 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkkgZG9uJ3QgdGhpbmsgdGhl IGZ1dHVyZSBJRVNHIHdvdWxkIGFwcHJlY2lhdGUgaXQgaWYgd2UgdG9sZCB0aGVtIHRoYXQgdGhl eSBtdXN0IGFsbG9jYXRlIGlmIGNvbmRpdGlvbiBYIGlzIG1ldC4gJm5ic3A7SnVzdCBhcyB0aGUg aW5pdGlhbCByZXF1ZXN0IGZvciBhIHBlcm1hbmVudCBjb2RlIHBvaW50IHdhcyBhIGp1ZGdtZW50 IHhhbGwsIHNvIHdpbGwgdGhlIGZ1dHVyZSByZXFlc3QuICZuYnNwO0luIGZhY3QsIHRvIHdyaXRl IHRoZSBjb25kaXRpb2JzLCB3ZSB3b3VsZCBoYXZlIHRvIGNvcHkgdGV4dCBmcm9tIGEgbnVtYmVy IG9mIFJGQ1MgYW5kIHRoZW4gYWRkIHNwZWNpZmljcyB0byB0aGUganVkZ2VtZW50IGNhbGxzIHRo b3NlIHByZXNjcmliZS4gJm5ic3A7VGhhdCBkb2VzIG5vdCBzb3VuZCBsaWtlIHRoZSByaWdodCB0 aGluZyB0byBkby48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PllvdXJzLDwvZGl2PjxkaXY+Sm9l bDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYg aWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjoj NTc1NzU3Ij5TZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgU8KuIDYsIGFuIEFUJmFtcDtUIDRH IExURSBzbWFydHBob25lPC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEwMCU7Y29s b3I6IzAwMDAwMCI+PCEtLSBvcmlnaW5hbE1lc3NhZ2UgLS0+PGRpdj4tLS0tLS0tLSBPcmlnaW5h bCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiAiQWx2YXJvIFJldGFuYSAoYXJldGFu YSkiICZsdDthcmV0YW5hQGNpc2NvLmNvbSZndDsgPC9kaXY+PGRpdj5EYXRlOiAyLzE2LzIwMTYg IDU6NDQgUE0gIChHTVQtMDU6MDApIDwvZGl2PjxkaXY+VG86ICJKb2VsIE0uIEhhbHBlcm4iICZs dDtqbWhAam9lbGhhbHBlcm4uY29tJmd0OywgTHVpZ2kgSWFubm9uZSAmbHQ7Z2d4QGdpZ2l4Lm5l dCZndDsgPC9kaXY+PGRpdj5DYzogZHJhZnQtaWV0Zi1saXNwLWVpZC1ibG9ja0BpZXRmLm9yZywg bGlzcC1jaGFpcnNAaWV0Zi5vcmcsIGxpc3BAaWV0Zi5vcmcsIFRoZSBJRVNHICZsdDtpZXNnQGll dGYub3JnJmd0OywgZGFtaWVuLnNhdWNlekBnbWFpbC5jb20gPC9kaXY+PGRpdj5TdWJqZWN0OiBS ZTogQWx2YXJvIFJldGFuYSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1saXNwLWVpZC1ibG9jay0x MjogKHdpdGgKICBESVNDVVNTIGFuZCBDT01NRU5UKSA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rp dj5PbiAyLzE2LzE2LCA0OjM3IFBNLCAiaWVzZyBvbiBiZWhhbGYgb2YgSm9lbCBNLiBIYWxwZXJu Ijxicj4mbHQ7aWVzZy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqbWhAam9lbGhhbHBl cm4uY29tJmd0OyB3cm90ZTo8YnI+PGJyPkhpITxicj48YnI+Jmd0O1RvIHBocmFzZSB0aGUgZXhw ZXJpbWVudCBqdWRnbWVudCBkaWZmZXJlbnRseSwgZWl0aGVyIGFmdGVyIHRyZWUgeWVhcnM8YnI+ Jmd0O3RoZXJlIHdpbGwgYmUgc3VmZmljaWVudCBkZW1vbnN0cmF0ZWQgdmFsdWUgdG8ganVzdGlm eSBhIHBlcm1hbmVudDxicj4mZ3Q7YWxsb2NhdGlvbiwgb3IgdGhlcmUgd29uJ3QuJm5ic3A7IEl0 IHdvdWxkIHRha2UgYSBzdHJhbmdlIHNpdHVhdGlvbiB0byBleHRlbmQ8YnI+Jmd0O3RoZSBleHBl cmltZW50YWwgYWxsb2NhdGlvbiAoYWx0aG91Z2ggb2YgY291cnNlIHdlIGNhbiBub3QgZm9yZXNl ZSBldmVyeTxicj4mZ3Q7cG9zc2libGUgc2l0dWF0aW9uLik8YnI+Jmd0Ozxicj4mZ3Q7U2luY2Ug SSBkbyBub3QgZXhwZWN0IHRoZSBJRVNHIHRvIGNvbW1pdCB0byBzcGVjaWZpYyBjcml0ZXJpYSAo b3RoZXI8YnI+Jmd0O3RoYW4gdGhvc2UgYWxyZWFkeSBkb2N1bWVudGVkIGluIFJGQ3MpIGZvciBn cmFudGluZyB0aGUgcGVybWFuZW50PGJyPiZndDthbGxvY2F0aW9uLCBJIGRvbid0IHNlZSBtdWNo IHRoYXQgY2FuIGJlIHNhaWQuPGJyPiZndDs8YnI+Jmd0O0lmIHlvdSByZWFsbHkgd2FudCwgSSBz dXBwb3NlIHRoYXQgd2UgY291bGQgYWRkIGEgc2VudGVuY2Ugc2F5aW5nIHRoYXQ8YnI+Jmd0O2Fm dGVyIHRoZSBleHBlcmltZW50LCBwZXJtYW5lbnQgYWxsb2NhdGlvbiB3aWxsIGJlIGV2YWx1YXRl ZCB1c2luZyB0aGU8YnI+Jmd0O3VzdWFsIGNyaXRlcmlhIGZvciBzdWNoIHJlcXVlc3RzLjxicj48 YnI+VGhlIHBvaW50IEknbSB0cnlpbmcgdG8gbWFrZSBpcyBhYm91dCB0aGUgZXZhbHVhdGlvbiBv ZiB3aGF0IHlvdSBjYWxsPGJyPiJzdWZmaWNpZW50IGRlbW9uc3RyYXRlZCB2YWx1ZSIuJm5ic3A7 IEFzIHlvdSBzYXksIHRoZSBhbGxvY2F0aW9uIGlzIGp1c3RpZmllZDxicj5pZiB2YWx1ZSBpcyBk ZW1vbnN0cmF0ZWQsIGhvdyBpcyB0aGF0IHZhbHVlIGRlbW9uc3RyYXRlZD88YnI+PGJyPkF0IHRo aXMgcG9pbnQgaW4gdGltZSB0aGUgYWxsb2NhdGlvbiBpcyBiZWluZyBtYWRlIHRlbXBvcmFyaWx5 IHNvIHRoYXQgYW48YnI+ZXhwZXJpbWVudCBjYW4gYmUgcnVuLiZuYnNwOyBXaGF0IGlzIHRoZSBz dWNjZXNzIGNyaXRlcmlhIGZvciB0aGF0IGV4cGVyaW1lbnQ/PGJyPjxicj5UaGFua3MhPGJyPjxi cj5BbHZhcm8uPGJyPjxicj48L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_39179455904494190-- From nobody Wed Feb 17 00:57:00 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FABA1B2F0C; Wed, 17 Feb 2016 00:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.906 X-Spam-Level: X-Spam-Status: No, score=-13.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVGQnRvZ_n-9; Wed, 17 Feb 2016 00:56:58 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 095CA1ABC10; Wed, 17 Feb 2016 00:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3789; q=dns/txt; s=iport; t=1455699413; x=1456909013; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=PGOg63l0zGRdaNCKvOmH8AyHgf2CFnfiGAxxOisZTPE=; b=nEPbnXyZDT8FbeCJEe/t8wK1Z2S22D9JpvdbxRMGiEYN51hLc4p1dYbd /EdGtm8soiSu0+U2iA/qc0sPe4ktoi1EyORlJYFybv/lUqVRmqS6HkYpz xyShsDecVrFP8DwHgFwieuiF5uc/F4JFmRYGwr8ptVPi5Anvsp6BmqIGd k=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.22,459,1449532800"; d="asc'?scan'208,217";a="635547612" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2016 08:56:51 +0000 Received: from [10.61.161.180] ([10.61.161.180]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1H8uohf017315; Wed, 17 Feb 2016 08:56:50 GMT To: "jmh.direct" , "Alvaro Retana (aretana)" , "Joel M. Halpern" , Luigi Iannone References: <50sus3sgbqr0yhw275dcc7fl.1455666785804@email.android.com> From: Eliot Lear Message-ID: <56C435D1.7020708@cisco.com> Date: Wed, 17 Feb 2016 09:56:49 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <50sus3sgbqr0yhw275dcc7fl.1455666785804@email.android.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AlrnlSLS4OmITpXlpuHxkHAudfe0admLK" Archived-At: Cc: "draft-ietf-lisp-eid-block@ietf.org" , "lisp-chairs@ietf.org" , "lisp@ietf.org" , The IESG Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 08:56:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AlrnlSLS4OmITpXlpuHxkHAudfe0admLK Content-Type: multipart/alternative; boundary="------------000004030400090609030705" This is a multi-part message in MIME format. --------------000004030400090609030705 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Good morning, Joel. On 2/17/16 12:53 AM, jmh.direct wrote: > I don't think the future IESG would appreciate it if we told them that > they must allocate if condition X is met. Just as the initial request > for a permanent code point was a judgment xall, so will the future > reqest. In fact, to write the conditions, we would have to copy text > from a number of RFCS and then add specifics to the judgement calls > those prescribe. That does not sound like the right thing to do. > I did not read Alvaro's message that way, but perhaps Alvaro could clarify. I viewed his message more as a question. is the experiment successful based on the number of allocations or based on what has been done with those allocations? Maybe both. I will admit, I would find quantifying that somewhat challenging. I would imagine that future allocations/delegations would require one or more RFCs. Eliot --------------000004030400090609030705 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Good morning, Joel.

On 2/17/16 12:53 AM, jmh.direct wrote:=
I don't think the future IESG would appreciate it if we told them that they must allocate if condition X is met. =C2=A0Just as= the initial request for a permanent code point was a judgment xall, so will the future reqest. =C2=A0In fact, to write the conditions= , we would have to copy text from a number of RFCS and then add specifics to the judgement calls those prescribe. =C2=A0That does= not sound like the right thing to do.


I did not read Alvaro's message that way, but perhaps Alvaro could clarify.=C2=A0 I viewed his message more as a question.=C2=A0 is the experiment successful based on the number of allocations or based on what has been done with those allocations?=C2=A0 Maybe both.=C2=A0 I = will admit, I would find quantifying that somewhat challenging.=C2=A0 I wo= uld imagine that future allocations/delegations would require one or more RFCs.

Eliot

--------------000004030400090609030705-- --AlrnlSLS4OmITpXlpuHxkHAudfe0admLK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWxDXSAAoJEIe2a0bZ0nozUUMH/iWqw/idkxeTPdh9E9X0XmC0 40VMdotRyoxqftZfBOIbl77JlQalN5c8J3C0jGASFjs6bJrhsRDHtORyD24tQ1U2 g3AT+6CUH6/utCQHc3ZcjeJFLTMx2MYnaufRxD8xzfPbpoiMIVTBHhcQHWuthVDg E//sSiA+WnhHpD/V8+bJ0i/x/Qzq8z9BoOIUQAAN2dnfvWtLADuIswvZLbOX/OYT TMAPTwohYn9a7wltJprC9YK17PD2JJ7cH6SX+4+8n4n2j2kWL8XHlO9tazenWH/r hWYSY83OIbNgNbpyTsIVk4MAa4Xb3FR+aRTpJm2Qe3r4oeNEVh5nctEhjvk9mcE= =+H0X -----END PGP SIGNATURE----- --AlrnlSLS4OmITpXlpuHxkHAudfe0admLK-- From nobody Wed Feb 17 01:20:02 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4318E1B378A for ; Wed, 17 Feb 2016 01:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crHz-PPtcGuz for ; Wed, 17 Feb 2016 01:19:53 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0441B3787 for ; Wed, 17 Feb 2016 01:19:51 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id g62so18540287wme.0 for ; Wed, 17 Feb 2016 01:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VWnR+r0k3IdT7h/8GhIe+a/3y8VRR9TnMH2lGNrIusw=; b=RXANqlejZk0gEvyv9vPlASp4Vwsv38cauHxrfGalTKtb+QYYo32qhRLlq3k9iYSshq Kxs3MUG/qkqDbvZM7JyznfebbMIAHNhEx0cLdfqyi1U0cVzdH8V0uwaGBEGzdvaRZ8/g FC5fCqGDETaCQBoe9wUPiEqy7CGeBzwX+86Dt4H+xQLKCp+MAGmO3/vDtPv7wVY+bBZr zbIEWeGUPHvez31apC0SwQu+ZA1b/AQ8gNs0d2cnJvCwA7ISW/PJBMItNDqcaTZ8K3VO 69vnFgDpo+/jC38ri6Dw4xadQ+hBbaxTj41nR8unMcgCvMkVix5amPJu8O8H4XbfcOpt hJVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=VWnR+r0k3IdT7h/8GhIe+a/3y8VRR9TnMH2lGNrIusw=; b=Q2ixQuB8o1YnZwAhgZuTmJPoE7sJQo+2AzRikXDgqA6qWYBEODcND43o+RV+Onp3Nr VmfkfPRphqMLoqqi6uakYeHzmYHRVwd0JuKM1Yhx6L6BKekdYEOGIoPALr/zJHPHhJK2 H2nmccdVgHKSNSuYB4DfcRAIpCk62Cl5OII9SDnCARust4K0sLxXYWQnL/3ON4TdIc55 vDsutIoPN1CifAnfyD8I1mMzQlyh504VUXGPf9v9aaZi6OWszqOyEgTVxXaf4dW2TFaz +eo9XlDY4v+ajAbiGdLnuZvLGf1+vdQ0HQ+kAD1Y3j81ckGO1Cb1RXgUshUg/piqj7gs 5mvg== X-Gm-Message-State: AG10YORshA3K2+wQ0HIs9igBkaSJhTtQqGUXNZrot4cFKzfbL20Ywby/oO3GUPV4Owv9wQ== X-Received: by 10.28.23.5 with SMTP id 5mr2432095wmx.82.1455700790261; Wed, 17 Feb 2016 01:19:50 -0800 (PST) Received: from ?IPv6:2003:8:10:8500:e8cb:6fb3:e2ff:3ca8? ([2003:8:10:8500:e8cb:6fb3:e2ff:3ca8]) by smtp.gmail.com with ESMTPSA id pd1sm491043wjb.19.2016.02.17.01.19.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Feb 2016 01:19:47 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: Date: Wed, 17 Feb 2016 10:19:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0CA5BA4A-0EBC-4220-8A6F-9006F5B6C72C@gigix.net> References: <20160215224046.28084.69566.idtracker@ietfa.amsl.com> <1C8A2608-7564-4190-9CE6-698024EB9564@gigix.net> <56C396A6.1080506@joelhalpern.com> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "draft-ietf-lisp-eid-block@ietf.org" , "lisp-chairs@ietf.org" , "lisp@ietf.org" , The IESG Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 09:19:54 -0000 Hi Alvaro, > On 16 Feb 2016, at 23:44, Alvaro Retana (aretana) = wrote: >=20 >>=20 >>=20 >> If you really want, I suppose that we could add a sentence saying = that >> after the experiment, permanent allocation will be evaluated using = the >> usual criteria for such requests. >=20 > The point I'm trying to make is about the evaluation of what you call > "sufficient demonstrated value". As you say, the allocation is = justified > if value is demonstrated, how is that value demonstrated? >=20 > At this point in time the allocation is being made temporarily so that = an > experiment can be run. What is the success criteria for that = experiment? I am a bit lost in what should the process be. If it is the IESG that has to take a decision in 3 years, is it up to = the authors/WG to write how the IESG has to decide?=20 I am not sure I follow this reasoning. Shouldn=E2=80=99t the IESG decide what are the criteria?=20 Any guidance is welcome Thanks Luigi >=20 > Thanks! >=20 > Alvaro. >=20 From nobody Wed Feb 17 01:46:09 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45D61AD36F; Wed, 17 Feb 2016 01:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KegObxgvJHFq; Wed, 17 Feb 2016 01:46:05 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B0E1A88D7; Wed, 17 Feb 2016 01:46:05 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id l143so7011005lfe.2; Wed, 17 Feb 2016 01:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hq6M+s7DmK4Q4Zu3pn8IiCprbuSpoxvDkSlGa6Pbwdk=; b=ECwHiDzRpkWSxgGzhHf+MarvEKCAJMfmXC1Owpw7cqKdoesviZywgThyMyB29+C7/X 3bwKKtBPLeuhqp4/gSmrjyZLqHEZxdh30qaeY9ZbhYNU7a2DCsvNm8oG4KlxO4y0b08m wnIkso4ZqmLEaNpuhNVaQaHzqytYJlx7j0dXPOFuek8yLdQLWUvoV5lHOfNCLS7KJcsT YjPo5yblyiUGfgWLRxGN+0AMuQK/z1xBbGrBaoPdG43gCOsn7y3qKT6z9mCRoJ8SdGvU MiLzKps+G89yn/z1p2+m+qdJ41WSZrFPw4VYqH8fdatPZDc96GwQt/L1V3LsEMcUmAHL nsAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hq6M+s7DmK4Q4Zu3pn8IiCprbuSpoxvDkSlGa6Pbwdk=; b=Hij3DvRiC/MLCOgCDAVUJBDY8aUj85dhngCyaxceN/ZGcFMgzxiUnHSdDzaUqM8G/H p2QUyIVVWQ5Fe4tnVdBlTZrq+ajOQYZFWeBXyR/SlK84tjKp+K2MVyrtWjBeXMaCTNpU LhUyximgYFqz5ZtrOF3WUL31uvu69tHepZF8DBHmMSL5JwVXw6FelLpWSfrcAuKAtNpa fA9u3DTwA5Q0uCn2Z7I9gnerl3F8hOk75VIzUIGCxd4vD0Toqu1OfCcbtwWBwo2twAB0 I1dnbmaHPP+Fq3N0Qsr4thkSA0Epimq4whw/DHDw7hlVJHMi0azu96f7f4Mip7UfhPUY yI0g== X-Gm-Message-State: AG10YOSRAZRsPf+1CKrpJfZ2ikb6Q78xzPFiD4m+rDFWn0Nx54W3vAa/IXcodUXyOvpbcaq5P5s9gN5oOZKHGA== MIME-Version: 1.0 X-Received: by 10.25.80.6 with SMTP id e6mr285060lfb.91.1455702363359; Wed, 17 Feb 2016 01:46:03 -0800 (PST) Received: by 10.25.205.203 with HTTP; Wed, 17 Feb 2016 01:46:03 -0800 (PST) In-Reply-To: References: <20160215224046.28084.69566.idtracker@ietfa.amsl.com> <1C8A2608-7564-4190-9CE6-698024EB9564@gigix.net> <56C396A6.1080506@joelhalpern.com> Date: Wed, 17 Feb 2016 10:46:03 +0100 Message-ID: From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= To: "Alvaro Retana (aretana)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "draft-ietf-lisp-eid-block@ietf.org" , "lisp-chairs@ietf.org" , "lisp@ietf.org" , The IESG Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 09:46:07 -0000 On Tue, Feb 16, 2016 at 11:44 PM, Alvaro Retana (aretana) wrote: > On 2/16/16, 4:37 PM, "iesg on behalf of Joel M. Halpern" > wrote: > > Hi! > >>To phrase the experiment judgment differently, either after tree years >>there will be sufficient demonstrated value to justify a permanent >>allocation, or there won't. It would take a strange situation to extend >>the experimental allocation (although of course we can not foresee every >>possible situation.) >> >>Since I do not expect the IESG to commit to specific criteria (other >>than those already documented in RFCs) for granting the permanent >>allocation, I don't see much that can be said. >> >>If you really want, I suppose that we could add a sentence saying that >>after the experiment, permanent allocation will be evaluated using the >>usual criteria for such requests. > > The point I'm trying to make is about the evaluation of what you call > "sufficient demonstrated value". As you say, the allocation is justified > if value is demonstrated, how is that value demonstrated? > > At this point in time the allocation is being made temporarily so that an > experiment can be run. What is the success criteria for that experiment? I understand what you ask for, but I have no idea on how to formulate such criteria. What I am personally quite sure about is that the amount of assignment made from this allocation alone will not be a justification for granting this a permanent allocation. We could end up with very few assigment but the technical gain is significant. So, this experiment end in 3years time automatically and before that LISP-WG will either 1.) let it expire, 2.) ask for an extension or 3.) ask for a permanent allocation. For option 2 or 3 to happen someone will have to present a draft that can justify it technical, or option 1 will happen. Either way we would have learned something from it I hope. -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From nobody Wed Feb 17 06:32:01 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91BC1ACC80; Wed, 17 Feb 2016 06:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFvWfninU-d8; Wed, 17 Feb 2016 06:31:52 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23DFD1B2F15; Wed, 17 Feb 2016 06:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4468; q=dns/txt; s=iport; t=1455719512; x=1456929112; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=c153Wa8RVYYzn1gMQOD3MIwgZufbLx4fnSweR/8CRQo=; b=B+SFS8X8e49bvLMVpI6huezFXZy9tS0Tid284A2BsXYDdJvIy3C2FeFK onevxb8boj30eACp86VoAzHG4H5WKY/fJgExA2yQ7sYBgdOih2YlL2ZSV MA4JSaAXda7YMWGA51ZiXMZA2cxilQjx0ygCSonFPWeE9afQOr21OiifM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQCGg8RW/5FdJa1UCoM6gT8Gt36CE?= =?us-ascii?q?wENgWeGDQKBQzgUAQEBAQEBAWQcC4RCAQEEbAoDEAIBCBguIRElAgQOBYgFAxK?= =?us-ascii?q?2Tw2EWwEBAQEBAQEBAQEBAQEBAQEBARiGEoQ7gjqBUYRkAQSNYYURhBEBi2WBc?= =?us-ascii?q?45zhwSHQgEeAQFCggIZFIE0aocoJBl8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,460,1449532800"; d="scan'208";a="77850356" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2016 14:31:50 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u1HEVpR9030009 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Feb 2016 14:31:51 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 17 Feb 2016 08:31:51 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Wed, 17 Feb 2016 08:31:51 -0600 From: "Alvaro Retana (aretana)" To: "draft-ietf-lisp-eid-block@ietf.org" Thread-Topic: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) Thread-Index: AQHRaEHsoX4wm6EbUU2zdG+H0868d58u3uQA//+3JwCAAQKOAP//vsSAgAEMu4D///wWAA== Date: Wed, 17 Feb 2016 14:31:51 +0000 Message-ID: References: <20160215224046.28084.69566.idtracker@ietfa.amsl.com> <1C8A2608-7564-4190-9CE6-698024EB9564@gigix.net> <56C396A6.1080506@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.212.52] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <981ADE5B6005C049999990B44E4D6B87@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "lisp-chairs@ietf.org" , =?iso-8859-1?Q?Roger_J=F8rgensen?= , "lisp@ietf.org" , The IESG Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 14:31:59 -0000 On 2/17/16, 4:46 AM, "Roger J=F8rgensen" wrote: [Responding to Roger's e-mail..but the answer is not specifically directed at him.] >On Tue, Feb 16, 2016 at 11:44 PM, Alvaro Retana (aretana) > wrote: >> On 2/16/16, 4:37 PM, "iesg on behalf of Joel M. Halpern" >> wrote: >> >> Hi! >> >>>To phrase the experiment judgment differently, either after tree years >>>there will be sufficient demonstrated value to justify a permanent >>>allocation, or there won't. It would take a strange situation to extend >>>the experimental allocation (although of course we can not foresee every >>>possible situation.) >>> >>>Since I do not expect the IESG to commit to specific criteria (other >>>than those already documented in RFCs) for granting the permanent >>>allocation, I don't see much that can be said. >>> >>>If you really want, I suppose that we could add a sentence saying that >>>after the experiment, permanent allocation will be evaluated using the >>>usual criteria for such requests. >> >> The point I'm trying to make is about the evaluation of what you call >> "sufficient demonstrated value". As you say, the allocation is >>justified >> if value is demonstrated, how is that value demonstrated? >> >> At this point in time the allocation is being made temporarily so that >>an >> experiment can be run. What is the success criteria for that >>experiment? > >I understand what you ask for, but I have no idea on how to formulate such >criteria. > >What I am personally quite sure about is that the amount of >assignment made from this allocation alone will not be a justification for >granting this a permanent allocation. We could end up with very few >assigment but the technical gain is significant. Agreed. >So, this experiment end in 3years time automatically and before that >LISP-WG will either 1.) let it expire, 2.) ask for an extension or >3.) ask for a permanent allocation. > >For option 2 or 3 to happen someone will have to present a draft that >can justify it technical, or option 1 will happen. Either way we would >have learned something from it I hope. I hope we learn too. Putting the allocation issue aside for a second... The document itself already lists "the most relevant scenarios" in Section 3. (Rationale and Intent). For the scenarios listed, what would represent a successful experiment? What type of information would we want to collect to determine if the scenario was in fact relevant (or not)? For example, taking one of the scenarios (I chose the one with the shortest description): Avoid penalize non-LISP traffic: In certain circumstances it might be desirable to configure a router using LISP features to natively forward all packets that have not a destination address in the block, hence, no lookup whatsoever is performed and packets destined to non-LISP sites are not penalized in any manner. In this case I would assume people would want to look at the impact of the lookup -- is non-LISP traffic penalized? How much? Does having a separate router processing help? Is it significant? Answering questions like that would identify whether, for that scenario, having the block of addresses made a difference or not. If, for example, the penalty was huge and using the block reduced it significantly, then it helps the case for an extended (maybe even permanent allocation). OTOH, if the performance is about the same, then maybe that doesn't justify anything. The other potential outcome is that experience was gathered, but that the results are still inconclusive and more experience is needed, maybe justifying an extension. I'm just making all that up -- I'm sure the authors/WG know better than me why each of those scenarios is relevant. The important thing about the above is that then the future IESG is not making a decision in a vacuum about allocation. And the future lisp WG can also support their request for extension/permanent allocation with data from the experiment. In the end what I would like to see the draft talk about is not the decision for allocation itself, but about what is going to be done with it, and (given "the most relevant scenarios") how that experience can support someone's case in the future. Thanks! Alvaro. From nobody Wed Feb 17 07:33:16 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C0A1A6F30 for ; Wed, 17 Feb 2016 07:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmTpCg6cWcCw for ; Wed, 17 Feb 2016 07:33:14 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530241A21BE for ; Wed, 17 Feb 2016 07:33:06 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id a4so33537853wme.1 for ; Wed, 17 Feb 2016 07:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KHqEsjOyag8bq80P4r9LSTby0RGp2KGZmY/x7VX7Gew=; b=lOr2EggNBU8h2EEkviBOai3yUtnZCMkwiNT3RnsIaMD5rmG1S5XxahxIcsmV5MNRrE EgXqiGDzmm0MmNZXGGnxgUBcAU00jofvJFxhMj3rNe1JSLIY6w6aHJ3K5XwTD9h2OZl0 /95cag/pWon5tz2ERqSCqd/NtH4Qa6QJTLcXpwHaWqqk07ooKc08z1KiVq+w1jpFkxUx xZs4+zqyb0D2Mz7SsQBYlQP7bVrJi8NijLBQBjpZaJ1oiCHarTjSh8q74V8K1Jgdi4Pi /y9Gi0Y9mX6nvRwACdZYRJmED837HmAWrtqMbZshR1b0EI7y+Qm5VarnkoQ08KazBgd3 auPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=KHqEsjOyag8bq80P4r9LSTby0RGp2KGZmY/x7VX7Gew=; b=JOhGjsVDIjTfLFB5CCwtH+v3BP1S6Mi9ajgxPQQPDO644lDSJ8/If4ua1YVOkLypZC E3klFcqJM3Ulz/1c+ofOJrPGejPQ3Kl6O6eKtA/XBHjpSleqt5G3QgoCfALnjt3/spew oTYW9B2A1+zSYkcKj14Cq0B1+MqZ7Leta7gMhTxkX7Dp+hJ4CFPqo7izBzo6ACP2CyS0 LNtQ0He2VgP4WDuG54NL2e+jOSW4jgmujW4x0newOEIg8du8SkBB04pXfXChPYx+3poi M2riFofvcttLwYD9xJkW7kg/94bBE0h5F+e795RIKXmfgMNX0gGlHcX0+QyPCYaxHU1Q AVbA== X-Gm-Message-State: AG10YOQEakUFR8TsNuovFTGtjFdsUiqpKZIfpKNzlCTV02E5mTwyGy1exvxDxt7m8o9f0A== X-Received: by 10.28.97.135 with SMTP id v129mr26620479wmb.90.1455723184810; Wed, 17 Feb 2016 07:33:04 -0800 (PST) Received: from ?IPv6:2003:8:10:8500:5818:6f98:89bc:d05e? ([2003:8:10:8500:5818:6f98:89bc:d05e]) by smtp.gmail.com with ESMTPSA id v22sm3635648wmv.12.2016.02.17.07.33.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Feb 2016 07:33:02 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: Date: Wed, 17 Feb 2016 16:33:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9247B517-B152-4E7B-B2F5-A061A6375DDA@gigix.net> References: <20160215224046.28084.69566.idtracker@ietfa.amsl.com> <1C8A2608-7564-4190-9CE6-698024EB9564@gigix.net> <56C396A6.1080506@joelhalpern.com> To: "Alvaro Retana (aretana)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "draft-ietf-lisp-eid-block@ietf.org" , "lisp-chairs@ietf.org" , =?iso-8859-1?Q?Roger_J=F8rgensen?= , "lisp@ietf.org" , The IESG Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 15:33:15 -0000 Hi, I have a clarification question: > On 17 Feb 2016, at 15:31, Alvaro Retana (aretana) = wrote: > In this case I would assume people would want to look at the impact of = the > lookup -- is non-LISP traffic penalized? How much? Does having a > separate router processing help? Is it significant? >=20 > Answering questions like that would identify whether, for that = scenario, > having the block of addresses made a difference or not. If, for = example, > the penalty was huge and using the block reduced it significantly, = then it > helps the case for an extended (maybe even permanent allocation). = OTOH, > if the performance is about the same, then maybe that doesn't justify > anything. The other potential outcome is that experience was = gathered, > but that the results are still inconclusive and more experience is = needed, > maybe justifying an extension. Who would provide such results to the IESG? The community at large? The = LISP WG? And in which form? An I-D? Presentation?=20 thanks Luigi From nobody Wed Feb 17 16:04:30 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A111ACDA2; Wed, 17 Feb 2016 16:04:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160218000429.12257.2783.idtracker@ietfa.amsl.com> Date: Wed, 17 Feb 2016 16:04:29 -0800 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-eid-block-mgmnt@ietf.org, lisp@ietf.org Subject: [lisp] Terry Manderson's Discuss on draft-ietf-lisp-eid-block-mgmnt-06: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 00:04:29 -0000 Terry Manderson has entered the following ballot position for draft-ietf-lisp-eid-block-mgmnt-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a DISCUSS on behalf of the IANA who are questioning the clarity of text and construction of the EID registry service. From nobody Wed Feb 17 16:27:08 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D1D1B2A19 for ; Wed, 17 Feb 2016 16:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhI0WJwUgYG9 for ; Wed, 17 Feb 2016 16:27:00 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823A11B2F27 for ; Wed, 17 Feb 2016 16:26:45 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id g62so3342757wme.0 for ; Wed, 17 Feb 2016 16:26:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yf1tVgYOkYivIat5oABNWkZDH/RFx38CEujvbCkx8k8=; b=hNvj4aqNIyiZluWzqBnp8DTcKnmYsSF0d6CgKq7dkmTWe2PlqNfaY71sARrlchxjT6 tfUimPtBtEzLNM5wTfnNSefb5YjEEm9+2PoWUz4m40wgr8wX0iWzREG0+3isz1AIsiy9 vlBDRnEYgBQJjo7VFRigP4DDFdIawKMbaHSCC/d7exa7U7nm+4LtdH1Fpf83NW0W+3Do 4CUODqEt8oCF0fyzZXpO9mkSdiCfx0yiC2F/1Jy+RSIbA0JYHuBE79KUfR3FQ+cNQirE p0zJ4JcuXWMvrlXKVsBeTXPHyCBaz2MfQE2rEeWVMtEMT41vQ/M3Tsa/Wg2J4OrHvZvE lq1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yf1tVgYOkYivIat5oABNWkZDH/RFx38CEujvbCkx8k8=; b=nMNoPm4Wpd/OQzILciS68a1DNZViIGbN3tznqczhO5R+wGaLmvUQ3jc+XsUl+MPGhH yRwtTb2McliaNcmjudZz2DivAJSWUXB0QmiAnVKeMpUABeOU86O4F2eJvjEQTnq9SK8A wbaMaJjAOLImRGPylsvJMh9zCnWVBM88cK/ZdBiXqNPoLKSFM2rvSGAbyMbNCGlFbJQB 8Z/4rnx8Ph8kjT6BO4QerntBR2IKwcLt7zOHI08jikLxe1/rr0lPq5jXkCz8PG0wkJ+5 Vj9cp26ELWZertSqcIKM9r8rqap/Ig01Mie4FDGR7zQy5pIejpMNxGKnCOp7i9K4+Up4 qPMg== X-Gm-Message-State: AG10YOSVGgcOwytf1Lj6s2pL+RxEV2HAnYRIbQdvl7zCuaA8FBfwzb8JeTSy42rqBX+TfQ== X-Received: by 10.28.225.8 with SMTP id y8mr325688wmg.94.1455755204064; Wed, 17 Feb 2016 16:26:44 -0800 (PST) Received: from fatboy.intern (i577B59F2.versanet.de. [87.123.89.242]) by smtp.gmail.com with ESMTPSA id u4sm3924695wjz.4.2016.02.17.16.26.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Feb 2016 16:26:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: <20160218000429.12257.2783.idtracker@ietfa.amsl.com> Date: Thu, 18 Feb 2016 01:26:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8EB22CA3-9933-4193-84E1-BC4AAA4D1F62@gigix.net> References: <20160218000429.12257.2783.idtracker@ietfa.amsl.com> To: Terry Manderson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-eid-block-mgmnt@ietf.org, lisp@ietf.org, The IESG Subject: Re: [lisp] Terry Manderson's Discuss on draft-ietf-lisp-eid-block-mgmnt-06: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 00:27:05 -0000 HI Terry, would be possible to have more information? The latest email from IANA, dated 2nd February said: > (BEGIN IANA COMMENTS) >=20 > IESG/Authors/WG Chairs: >=20 > IANA has completed its review of = draft-ietf-lisp-eid-block-mgmnt-06.txt. If any part of this review is = inaccurate, please let us know.=20 >=20 > IANA understands that, upon approval of this document, there is a = single action which IANA must complete. >=20 > IANA understands that there is an operational requirement for an EID = registration service that ensures uniqueness of EIDs according to the = requirements described in Section 5 of the current document. = Furthermore, there is an operational requirement for EID registration = service that allows a lookup of the contact information of the entity = that registered the EID. >=20 > IANA further understands that RIPE NCC has agreed to run both the = registration service documented in this draft for the duration of the = experiment. >=20 > IANA understands that this is the only action required to be completed = upon approval of this document. >=20 > Note: The actions requested in this document will not be completed = until the document has been approved for publication as an RFC. This = message is only to confirm what actions will be performed. =20 >=20 >=20 > Thank you, >=20 > Sabrina Tanamal > IANA Specialist > ICANN >=20 > (END IANA COMMENTS) >=20 There is no question section in that mail. Anything I am missing? thanks=20 Luigi > On 18 Feb 2016, at 01:04, Terry Manderson = wrote: >=20 > Terry Manderson has entered the following ballot position for > draft-ietf-lisp-eid-block-mgmnt-06: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This is a DISCUSS on behalf of the IANA who are questioning the = clarity > of text and construction of the EID registry service. >=20 >=20 >=20 >=20 From nobody Wed Feb 17 16:31:43 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5101B1A88ED for ; Wed, 17 Feb 2016 16:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26tFpQ9EEUxS for ; Wed, 17 Feb 2016 16:31:29 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 003A81A21BC for ; Wed, 17 Feb 2016 16:31:22 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id c200so2895846wme.0 for ; Wed, 17 Feb 2016 16:31:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wLHspJPp9ncIDmjD2bF9MjnLhcYQdg78nMSjRGzcB/A=; b=F2T9d19v/jYVC3ZWgRoDRNI2q6cgDnHzLa7XmzGLX2lJ1AlUO5dXoHhdcd/zgAjAj6 ihiMWMkTZbfyE2zyT2gso67Rxw6DD5n4efJpUrr8jSZ+QchxlPz+7DkSYh8rz1xEPqWD +xufmlrr5HV/9awUdK3Rnp53tih7L8HD0Q2d3aaovM8bFExHaR8kcTtTOP8aj9/vTDj1 pzyb05xZaT0zbFYZj1Tc7JZ09XVAytKaJrofsFM23m3jrHcXsgHSHi9LvGKnNM8PEjMd 1qGh7zkUJcGtU3W6ASWyi8/tZ2oXAer0B3rfw8Z2/WYVKPF9rdOgLRfUuYDEwVKzfhs+ JUmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=wLHspJPp9ncIDmjD2bF9MjnLhcYQdg78nMSjRGzcB/A=; b=cYhoCwA7CwqySJ7VRF4LUmIdbiE1ETZCVAv+2cBf/0/3majHaAnfYThHF62ceZzHGO CkGsc1bHQdtAbWXciSfG3CNUV15j9ckTamJOyBRsaZKERPGzyZ/SN7+aOFwzwLiMUI8W tbxidsmMFgTZ1xIwwRLL8TYgYMUkmcmvng+7AQN2N7UncEpkhZnEZFsIZ6z94bVINqvj UXo90OD4rtuYEx5x4MAuwnRmnG1LhCldmXhhLTfEguuE5iUJvuJKCPVEnMEWWfIJHLYX nFPDKbuXCR7BenKoGhCR9ASddcvoXuYkTqg48ZEXaSO0Y/y2oA8GR8KZ0HoqR3z2/PYj VWzg== X-Gm-Message-State: AG10YOSaUymEkRX8lMEZOCNdtWZCP1IKircX1d3GGxhr6D0MxP+sF1vUW0+O9eb2SNyWpQ== X-Received: by 10.194.189.143 with SMTP id gi15mr4534076wjc.54.1455755481602; Wed, 17 Feb 2016 16:31:21 -0800 (PST) Received: from fatboy.intern (i577B59F2.versanet.de. [87.123.89.242]) by smtp.gmail.com with ESMTPSA id 79sm343604wmo.7.2016.02.17.16.31.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Feb 2016 16:31:20 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: <20160217210147.23818.32277.idtracker@ietfa.amsl.com> Date: Thu, 18 Feb 2016 01:31:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160217210147.23818.32277.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3112) Archived-At: Cc: draft-ietf-lisp-eid-block@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org, The IESG Subject: Re: [lisp] Ben Campbell's No Objection on draft-ietf-lisp-eid-block-12: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 00:31:35 -0000 HI Ben, thanks for reading the document. > On 17 Feb 2016, at 22:01, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-lisp-eid-block-12: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Substantive: >=20 > - section 6: > Predictions that the IETF will or will not do something are risky > propositions at best. I suggest stating a default result that will = occur > _unless_ the IETF chooses to take action. >=20 That is what the whole document aim. The 3+3 plan is: let=E2=80=99s = experiment for 3 year and finish _unless_ the IETF thinks otherwise. Certainly we can improve the wording in making that _unless_ more clear. > Editorial: > There's quite a number of grammar and word choice errors. I list some > below, but I am sure I did not catch everything. I suggest another = pass > at proofreading before publication. >=20 > -3: > s/"avoid penalize"/"avoid penalizing" > s/"ask an allocation"/"ask for an allocation" ; or "request an > allocation" > s/"avoid non-LISP domains to fragment " / "allow non-LISP domains to > avoid fragmenting" > "... which would negatively impact the BGP routing infrastructure" > Which would cause negative impact, the fragmentation, or the avoidance = of > the fragmentation? > s/"worth to mention"/"worth mentioning" >=20 > -4 > s/"Such prefix"/"Such prefixes" ; or "This prefix" > /"As the LISP adoption progress"/"As the LISP adoption progresses" >=20 > "... the EID block will potentially help in reducing the impact on the > BGP routing infrastructure with respect to the case of the same number = of > adopters using global unicast space allocated by RIRs " > Convoluted sentence. Can it be simplified? > s/"Such trend"/"Such trends" ; or "This trend" >=20 > "With the exception of PITR case (described above)" > Which case is the PITR case? This is the first use of PITR. >=20 > -5: > s/"looks as sufficiently large"/"appears sufficiently large" >=20 > -9: > s/"provided by IANA before published"/"provided by IANA before > publication" >=20 >=20 Thanks. Will fix all fo this. ciao Luigi= From nobody Wed Feb 17 16:36:37 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849F31A0AC8 for ; Wed, 17 Feb 2016 16:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwSZk0fHaTGA for ; Wed, 17 Feb 2016 16:36:25 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DA811A1A36 for ; Wed, 17 Feb 2016 16:36:19 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id g62so2992665wme.1 for ; Wed, 17 Feb 2016 16:36:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KLIHmj1CqdtZne71VJfzQ1iIvYACY85S9PvVibnpeeg=; b=kLgfoZvv3fhEZk+cXzpMa6ZnU/jZVZ8c6q6CttUEcsdGYPY6pmj85dd097GmmtbxwA S3iAPuY6c1eLG9ax8zZmXPiP882j0N2qDu7UXYWbGl0cA/f7lphQ+sI6KonIEtUu57v7 zCKIOzu5qMrtCkXtLKITvSJHOtUgrX8mryoRggMxpXVlkkq+4qkqFG9J9EVo8KZOpSCk p+WVmAuDnEBcxhoiMDSM4bI3GYPZQXdarmRcmUC9sZNRRAnHY6wuCc/F6/nhF2gMjQHK s98SYabCGGJEDhH9OEE1RI8fH8wACLIOUilByFCQ3FGCVUtQpEjO+DziSK4DMpmNiRSn 6Gzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=KLIHmj1CqdtZne71VJfzQ1iIvYACY85S9PvVibnpeeg=; b=KMIZioe+Xb2UKMJxnM+lxl3GJj9RFuaRXQ4DHZEoDJH0FMhAgV5rjlSFIYlX8gcuEy dSt0UrHfHY7iqa75koin37Kw1hzPg//hhWVFHkaooG9RSQX4cumh3e4NJLAXiKMoU3Mt x+Kd9a4WBGgpzyHBZm46dMNB8nYcesB6LUhZGJde/i7fkzWIhU22ChO4c62qvUoUfGZM XJpZ/czlJ+eFo0r7lspLM1g0Dep4VqgouMOvUFmSCxpEf7S+Eq1b7naJQLcPvR2sLzpK P6LuBma4GMwvfdUzR9Zb2rc+ufvxIQ11S60oSPugAbTYovZre0kY+VpsHtO/Mcm7/P+m MkxQ== X-Gm-Message-State: AG10YORFKlLmomjtwL5EIB1iI/ECAp4Mdw8YhTTT+1p5smWyKczq3Ng5Fu/Hc0ER2uYO/Q== X-Received: by 10.28.102.68 with SMTP id a65mr390082wmc.12.1455755777639; Wed, 17 Feb 2016 16:36:17 -0800 (PST) Received: from fatboy.intern (i577B59F2.versanet.de. [87.123.89.242]) by smtp.gmail.com with ESMTPSA id gg7sm3937108wjd.10.2016.02.17.16.36.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Feb 2016 16:36:16 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: <20160217210824.1236.47093.idtracker@ietfa.amsl.com> Date: Thu, 18 Feb 2016 01:36:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160217210824.1236.47093.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3112) Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-eid-block-mgmnt@ietf.org, lisp@ietf.org, The IESG Subject: Re: [lisp] Ben Campbell's No Objection on draft-ietf-lisp-eid-block-mgmnt-06: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 00:36:31 -0000 > On 17 Feb 2016, at 22:08, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-lisp-eid-block-mgmnt-06: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I share Alvaro's thought that this should be experimental. (And if not > that, then a BCP). >=20 Nothing against it=E2=80=A6. > -4 (and others) > The top level "MUST" follow these policies does not need the MUST. The > policies have their own 2119 keywords. As written, it implies things = like > "MUST follow this SHOULD" which is a bit awkward. >=20 you mean that we only keep 2119 keywords in the policies but on the the = very fist sentence of the section, am I right? > 4, policy 2: > I gather the point is not so much that the registrations need to be > renewed as it is they need to expire if not renewed. That is, there's = no > SHOULD level requirement for a registrant to renew it's registration > (maybe no longer needs the registration.) >=20 >=20 You mean we put the first should as lower case (non 2119 keyword) ciao Luigi From nobody Wed Feb 17 16:38:32 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E3B1A913E for ; Wed, 17 Feb 2016 16:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjG22PuGrKoW for ; Wed, 17 Feb 2016 16:38:18 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C741A9050 for ; Wed, 17 Feb 2016 16:37:57 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id g62so3029197wme.1 for ; Wed, 17 Feb 2016 16:37:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=49LZKMA+UGsehSs9jlwpjgHfkCVyaO5ZWKhjB5vj/tc=; b=iFqXZrFqRs2mST0pLDf6Aua8aFgXJw/TBNziMY8fOVYKOil5u1fcDGh0cqoMVzPuyD lba5cy9XVrC9VMKh8b2M6jL53V3Hka5sgPqoYiMRWUCoQvdNHSwvNhNbwxjOQvQ3IpYw SqGdnGZMJbdvZgefhznAb5fOyHMgXursHO30nSxHfPAjl2ARupD31EVkpV5/s8hN05up 1qkBg4bzFfj7jtH9AHLcvK8J6kG7A4jjXbQKssZnK7S2YvGlnLPiSvvo/u4KZbxm7BbH x+C8seNmELeSnTekzFRdxL2cYcoadvJqxPIZk0q9tqWqLUEtNTDfLSPSYCABz5F14opD Nn9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=49LZKMA+UGsehSs9jlwpjgHfkCVyaO5ZWKhjB5vj/tc=; b=B00tLMK0q0uKu48DNvd78zUIXKC6dhqtMZjzDEPhoGujMyneP8p1SidJTeFSU0YUGK +3Y115L3/mD0CvP0BSuVPDW6IwJvfVypM7zH+iakGMTYJkw8bmJSpfezZZVc3vpTn7Lc Jv/jz1D1w1e9UGD/MWutPz5cvpzbPixQH8B3but4BHSwNL/Jzsqyw00sj4rzAL1lt2nv GkzIpSzYEAjZW6GMkCAblSy8R7jkJCcl1BHN4vj6lMz2Uub5MvdUgzGdjdeTZQ9sJhZm maAMAfWXILYu2VdCxRLdXtGp6SJsjo+UqLwlctucsLS/VHH+Fm40Qt1EXWgc/6lBgcf7 QOXw== X-Gm-Message-State: AG10YOTNeBFd881jMaqMrWCJsjEEsOtPlpt88awm5NuIrqZoQubvy/HIaIntWZmvvgro1Q== X-Received: by 10.194.92.68 with SMTP id ck4mr4539560wjb.144.1455755876542; Wed, 17 Feb 2016 16:37:56 -0800 (PST) Received: from fatboy.intern (i577B59F2.versanet.de. [87.123.89.242]) by smtp.gmail.com with ESMTPSA id z127sm353720wme.5.2016.02.17.16.37.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Feb 2016 16:37:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: <8EB22CA3-9933-4193-84E1-BC4AAA4D1F62@gigix.net> Date: Thu, 18 Feb 2016 01:37:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <45382EC5-D365-49F4-BC3D-ACF68E25E4AE@gigix.net> References: <20160218000429.12257.2783.idtracker@ietfa.amsl.com> <8EB22CA3-9933-4193-84E1-BC4AAA4D1F62@gigix.net> To: Terry Manderson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-eid-block-mgmnt@ietf.org, lisp@ietf.org, The IESG Subject: Re: [lisp] Terry Manderson's Discuss on draft-ietf-lisp-eid-block-mgmnt-06: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 00:38:24 -0000 As a side note, RIPE NCC already implemented the registration service. = They only wait for the two I-Ds to become RFC in order to start handing = out prefixes. ciao L. > On 18 Feb 2016, at 01:26, Luigi Iannone wrote: >=20 > HI Terry, >=20 > would be possible to have more information? >=20 > The latest email from IANA, dated 2nd February said: >=20 >> (BEGIN IANA COMMENTS) >>=20 >> IESG/Authors/WG Chairs: >>=20 >> IANA has completed its review of = draft-ietf-lisp-eid-block-mgmnt-06.txt. If any part of this review is = inaccurate, please let us know.=20 >>=20 >> IANA understands that, upon approval of this document, there is a = single action which IANA must complete. >>=20 >> IANA understands that there is an operational requirement for an EID = registration service that ensures uniqueness of EIDs according to the = requirements described in Section 5 of the current document. = Furthermore, there is an operational requirement for EID registration = service that allows a lookup of the contact information of the entity = that registered the EID. >>=20 >> IANA further understands that RIPE NCC has agreed to run both the = registration service documented in this draft for the duration of the = experiment. >>=20 >> IANA understands that this is the only action required to be = completed upon approval of this document. >>=20 >> Note: The actions requested in this document will not be completed = until the document has been approved for publication as an RFC. This = message is only to confirm what actions will be performed. =20 >>=20 >>=20 >> Thank you, >>=20 >> Sabrina Tanamal >> IANA Specialist >> ICANN >>=20 >> (END IANA COMMENTS) >>=20 >=20 > There is no question section in that mail. >=20 > Anything I am missing? >=20 > thanks=20 >=20 > Luigi >=20 >=20 >=20 >> On 18 Feb 2016, at 01:04, Terry Manderson = wrote: >>=20 >> Terry Manderson has entered the following ballot position for >> draft-ietf-lisp-eid-block-mgmnt-06: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> This is a DISCUSS on behalf of the IANA who are questioning the = clarity >> of text and construction of the EID registry service. >>=20 >>=20 >>=20 >>=20 >=20 From nobody Thu Feb 18 04:57:00 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99F51A015F; Thu, 18 Feb 2016 04:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOzafU6twOu3; Thu, 18 Feb 2016 04:56:55 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4551A009F; Thu, 18 Feb 2016 04:56:55 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 57F44880C2; Thu, 18 Feb 2016 04:56:55 -0800 (PST) Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8E551328081A; Thu, 18 Feb 2016 04:56:54 -0800 (PST) To: Ben Campbell , The IESG References: <20160217210824.1236.47093.idtracker@ietfa.amsl.com> From: Brian Haberman Message-ID: <56C5BF8F.7040302@innovationslab.net> Date: Thu, 18 Feb 2016 07:56:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160217210824.1236.47093.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oMP8rKAdrqeMgm4tmQVQ4SbafQqe77eSe" Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-eid-block-mgmnt@ietf.org, lisp@ietf.org Subject: Re: [lisp] Ben Campbell's No Objection on draft-ietf-lisp-eid-block-mgmnt-06: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 12:56:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oMP8rKAdrqeMgm4tmQVQ4SbafQqe77eSe Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ben, On 2/17/16 4:08 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-lisp-eid-block-mgmnt-06: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I share Alvaro's thought that this should be experimental. (And if not > that, then a BCP). We can talk about Informational vs. Experimental on the call, but... I don't see how this could possibly be a BCP. This is guidance for the management of one block of addresses that is being used by one protocol, so BCP seems out of line. Regards, Brian --oMP8rKAdrqeMgm4tmQVQ4SbafQqe77eSe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWxb+UAAoJEBOZRqCi7goqXlsIAK8x9Jj9DrgSKtyBsbY5F3r7 xp51nlhfRPxFII/A0ED57TWJgYkgp/+/6ijjH1rM/TQhj4nqxZbcRueL+4WbRe80 +my6mV9oAT8czXFM/I6ubEC0EaaTPQyeuyOSh7USeG+eIh2yGMU6ATfBM3JbHE7p pGArg3heY5RKOoha38y4wPI0ZLIxGjpA4fy9q+8TOIVcZig/KABZ5H+7pLoaiJQA iZxwrJUMXYbYsBE1u6ZsxAoKPry8limEUGWu3x7IJtHHne3E+ROv6gZYgsNr2sgi aiWYDaTJ7cuktSkT53Z5AZ4fPrAkoqo7iWvYhhBne/Gb8X7vDxtwrf8gh1zHRbM= =tuMu -----END PGP SIGNATURE----- --oMP8rKAdrqeMgm4tmQVQ4SbafQqe77eSe-- From nobody Thu Feb 18 04:59:54 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883901A1AA3; Thu, 18 Feb 2016 04:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRIKM75IEXAd; Thu, 18 Feb 2016 04:59:47 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C271A1A9D; Thu, 18 Feb 2016 04:59:46 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id BC8A3880C2; Thu, 18 Feb 2016 04:59:46 -0800 (PST) Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 1B62F328081A; Thu, 18 Feb 2016 04:59:46 -0800 (PST) To: Luigi Iannone , Terry Manderson References: <20160218000429.12257.2783.idtracker@ietfa.amsl.com> <8EB22CA3-9933-4193-84E1-BC4AAA4D1F62@gigix.net> From: Brian Haberman Message-ID: <56C5C040.6090100@innovationslab.net> Date: Thu, 18 Feb 2016 07:59:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <8EB22CA3-9933-4193-84E1-BC4AAA4D1F62@gigix.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rv867lgPXWIaxEOurV0aEnEqF4LWmqIb9" Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-eid-block-mgmnt@ietf.org, lisp@ietf.org, The IESG Subject: Re: [lisp] Terry Manderson's Discuss on draft-ietf-lisp-eid-block-mgmnt-06: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 12:59:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rv867lgPXWIaxEOurV0aEnEqF4LWmqIb9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Luigi, To clarify... We got a request from IANA to hold the document since they "still need to double-check the IANA Considerations internally for this document." Regards, Brian On 2/17/16 7:26 PM, Luigi Iannone wrote: > HI Terry, >=20 > would be possible to have more information? >=20 > The latest email from IANA, dated 2nd February said: >=20 >> (BEGIN IANA COMMENTS) >> >> IESG/Authors/WG Chairs: >> >> IANA has completed its review of draft-ietf-lisp-eid-block-mgmnt-06.tx= t. If any part of this review is inaccurate, please let us know.=20 >> >> IANA understands that, upon approval of this document, there is a sing= le action which IANA must complete. >> >> IANA understands that there is an operational requirement for an EID r= egistration service that ensures uniqueness of EIDs according to the requ= irements described in Section 5 of the current document. Furthermore, the= re is an operational requirement for EID registration service that allows= a lookup of the contact information of the entity that registered the EI= D. >> >> IANA further understands that RIPE NCC has agreed to run both the regi= stration service documented in this draft for the duration of the experim= ent. >> >> IANA understands that this is the only action required to be completed= upon approval of this document. >> >> Note: The actions requested in this document will not be completed un= til the document has been approved for publication as an RFC. This messag= e is only to confirm what actions will be performed. =20 >> >> >> Thank you, >> >> Sabrina Tanamal >> IANA Specialist >> ICANN >> >> (END IANA COMMENTS) >> >=20 > There is no question section in that mail. >=20 > Anything I am missing? >=20 > thanks=20 >=20 > Luigi >=20 >=20 >=20 >> On 18 Feb 2016, at 01:04, Terry Manderson = wrote: >> >> Terry Manderson has entered the following ballot position for >> draft-ietf-lisp-eid-block-mgmnt-06: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut thi= s >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ >> >> >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> This is a DISCUSS on behalf of the IANA who are questioning the clarit= y >> of text and construction of the EID registry service. >> >> >> >> --rv867lgPXWIaxEOurV0aEnEqF4LWmqIb9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWxcBAAAoJEBOZRqCi7goqzZoIAKbG3F06WRwsCKn5q9LD+8r1 GrrUy/i5qbhZJwcmOFq/cqm4BrLwyEuBH28cP4DAP+Nl5usIZ/s+no8ZVdkL2Kiq 8D1SjMDrlnq+LI+pkV3kSBhy/ZP7CjLhHoixKN3kFUjYF/0lcCuQwC8tBZrXNaR/ mb8Uvy2j0DaUJ5A753lDTe2ShIHao/9kLXm5faIn2JoiqlpqlESKCUIlPyC+Xd62 xhRSPF/JcDdl1tvwh9pgu7NWXNBXAxdSSig2crhtlju1Q3ks2djubNPWdowvgq0V 2Z+RhKC8LtoLbiA/SW3QLdsN5tFAQI/p8xbKaMA+9oD09seojS0ZaIyoBQ+if4E= =pUdC -----END PGP SIGNATURE----- --rv867lgPXWIaxEOurV0aEnEqF4LWmqIb9-- From nobody Thu Feb 18 07:15:01 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153D21B29F3 for ; Thu, 18 Feb 2016 07:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPUYSsrpzzSu for ; Thu, 18 Feb 2016 07:14:58 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FBB61B29F1 for ; Thu, 18 Feb 2016 07:14:57 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id g62so29834984wme.0 for ; Thu, 18 Feb 2016 07:14:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ProHiT3fijsMCqTW4vtXKUMQX1V3fQyv/0CiCdO2G8M=; b=dZ+d9HZW6cwfDcDCusYhX5KuYYK9jinoRUmb4IiOwXn/qNW3Op1IFhXBnfkbfL3Kt2 bPQ7yxjoftjywhMhildRjq1U3n8opBWJ+JrAAm+9K6ALPmm92xwtwY2fcqzi03cjgvds 1TdesxVj+igvK7HppuHFFYFGvjZzvTJuCZ+W3n8R2hUpLaCj0Fsw4uO3RjLzYhxpTFe3 CshlXVV9VKPyYNBO0KNAEhY0qAyGAOM+QpjY43BsypwKE0SxFbhUwJeWtD2Eqf6l/sbo Z39WGJPEG8e6Py+QAc/lzAvZTEnUs5uL4mlJ3Ioe88HUXAXG2APeYTeJuwZxukjpWMSy 9cSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ProHiT3fijsMCqTW4vtXKUMQX1V3fQyv/0CiCdO2G8M=; b=KwmeBxYQlKzV9s6pyb6joYd3DgWFBZWtHKC71gIZTSWdc0EZWJGBuG4/nrsiAELV2/ 4kPN0An63XWu6j2v39gVdXcVoTHghAjvf6uUPcC3K3hPWQq0j1sw0+2Hf6VNs0dV70TN +qddfvNFqRi4L80v8ipa6REh6vH4MOs5f+eHWZ6HwD391+4YtZ8Q1B+Knphdv+cYYpcF LqKmsCPFAgHLa6cYAe9iX2lydLzrc2xCnXz9h6Zz2uStu2HfRk0uH2GdpNvTFgwKULKc v6tFQDCjqD2vXkc3dJ3giHiYSuLNsJ4q5SFLycm79E6fraC6scXOwCo7l81AeHboZZkp TAFQ== X-Gm-Message-State: AG10YOQfc+vq2YE6YiRHMAEx/yBhqNOMtjszJr4MzXcKnYMrQy4QPgvN90WcX1N5V5snDQ== X-Received: by 10.28.148.130 with SMTP id w124mr3996909wmd.71.1455808496043; Thu, 18 Feb 2016 07:14:56 -0800 (PST) Received: from fatboy.ciscolive.local ([195.243.240.22]) by smtp.gmail.com with ESMTPSA id c7sm3419703wmd.13.2016.02.18.07.14.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Feb 2016 07:14:54 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: <56C5C040.6090100@innovationslab.net> Date: Thu, 18 Feb 2016 16:14:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160218000429.12257.2783.idtracker@ietfa.amsl.com> <8EB22CA3-9933-4193-84E1-BC4AAA4D1F62@gigix.net> <56C5C040.6090100@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.3112) Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org, The IESG , draft-ietf-lisp-eid-block-mgmnt@ietf.org Subject: Re: [lisp] Terry Manderson's Discuss on draft-ietf-lisp-eid-block-mgmnt-06: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 15:15:00 -0000 OK, thanks Brian. Just to learn how the process is, why there was a previous mail saying = everything was fine? thanks=20 L. > On 18 Feb 2016, at 13:59, Brian Haberman = wrote: >=20 > Hi Luigi, > To clarify... We got a request from IANA to hold the document = since > they "still need to double-check the IANA Considerations internally = for > this document." >=20 > Regards, > Brian >=20 > On 2/17/16 7:26 PM, Luigi Iannone wrote: >> HI Terry, >>=20 >> would be possible to have more information? >>=20 >> The latest email from IANA, dated 2nd February said: >>=20 >>> (BEGIN IANA COMMENTS) >>>=20 >>> IESG/Authors/WG Chairs: >>>=20 >>> IANA has completed its review of = draft-ietf-lisp-eid-block-mgmnt-06.txt. If any part of this review is = inaccurate, please let us know.=20 >>>=20 >>> IANA understands that, upon approval of this document, there is a = single action which IANA must complete. >>>=20 >>> IANA understands that there is an operational requirement for an EID = registration service that ensures uniqueness of EIDs according to the = requirements described in Section 5 of the current document. = Furthermore, there is an operational requirement for EID registration = service that allows a lookup of the contact information of the entity = that registered the EID. >>>=20 >>> IANA further understands that RIPE NCC has agreed to run both the = registration service documented in this draft for the duration of the = experiment. >>>=20 >>> IANA understands that this is the only action required to be = completed upon approval of this document. >>>=20 >>> Note: The actions requested in this document will not be completed = until the document has been approved for publication as an RFC. This = message is only to confirm what actions will be performed. =20 >>>=20 >>>=20 >>> Thank you, >>>=20 >>> Sabrina Tanamal >>> IANA Specialist >>> ICANN >>>=20 >>> (END IANA COMMENTS) >>>=20 >>=20 >> There is no question section in that mail. >>=20 >> Anything I am missing? >>=20 >> thanks=20 >>=20 >> Luigi >>=20 >>=20 >>=20 >>> On 18 Feb 2016, at 01:04, Terry Manderson = wrote: >>>=20 >>> Terry Manderson has entered the following ballot position for >>> draft-ietf-lisp-eid-block-mgmnt-06: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> This is a DISCUSS on behalf of the IANA who are questioning the = clarity >>> of text and construction of the EID registry service. >>>=20 >>>=20 >>>=20 >>>=20 >=20 From nobody Thu Feb 18 07:42:04 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FADA1ACD14; Thu, 18 Feb 2016 07:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ry9Mc-G9ff82; Thu, 18 Feb 2016 07:41:41 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D901ACDFD; Thu, 18 Feb 2016 07:41:34 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 0A543880C2; Thu, 18 Feb 2016 07:41:34 -0800 (PST) Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 46CAD328081A; Thu, 18 Feb 2016 07:41:33 -0800 (PST) To: Luigi Iannone References: <20160218000429.12257.2783.idtracker@ietfa.amsl.com> <8EB22CA3-9933-4193-84E1-BC4AAA4D1F62@gigix.net> <56C5C040.6090100@innovationslab.net> From: Brian Haberman Message-ID: <56C5E627.9040605@innovationslab.net> Date: Thu, 18 Feb 2016 10:41:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="orhgHg5xTUMAbJT19eJSkgJGj4XbR77uu" Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org, The IESG , draft-ietf-lisp-eid-block-mgmnt@ietf.org Subject: Re: [lisp] Terry Manderson's Discuss on draft-ietf-lisp-eid-block-mgmnt-06: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 15:41:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --orhgHg5xTUMAbJT19eJSkgJGj4XbR77uu Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Luigi, On 2/18/16 10:14 AM, Luigi Iannone wrote: > OK, >=20 > thanks Brian. >=20 > Just to learn how the process is, why there was a previous mail saying = everything was fine? >=20 There was a mis-communication within IANA that led to a IANA-internal process failure. Brian > thanks=20 >=20 > L. >=20 >=20 >> On 18 Feb 2016, at 13:59, Brian Haberman wr= ote: >> >> Hi Luigi, >> To clarify... We got a request from IANA to hold the document sinc= e >> they "still need to double-check the IANA Considerations internally fo= r >> this document." >> >> Regards, >> Brian >> >> On 2/17/16 7:26 PM, Luigi Iannone wrote: >>> HI Terry, >>> >>> would be possible to have more information? >>> >>> The latest email from IANA, dated 2nd February said: >>> >>>> (BEGIN IANA COMMENTS) >>>> >>>> IESG/Authors/WG Chairs: >>>> >>>> IANA has completed its review of draft-ietf-lisp-eid-block-mgmnt-06.= txt. If any part of this review is inaccurate, please let us know.=20 >>>> >>>> IANA understands that, upon approval of this document, there is a si= ngle action which IANA must complete. >>>> >>>> IANA understands that there is an operational requirement for an EID= registration service that ensures uniqueness of EIDs according to the re= quirements described in Section 5 of the current document. Furthermore, t= here is an operational requirement for EID registration service that allo= ws a lookup of the contact information of the entity that registered the = EID. >>>> >>>> IANA further understands that RIPE NCC has agreed to run both the re= gistration service documented in this draft for the duration of the exper= iment. >>>> >>>> IANA understands that this is the only action required to be complet= ed upon approval of this document. >>>> >>>> Note: The actions requested in this document will not be completed = until the document has been approved for publication as an RFC. This mess= age is only to confirm what actions will be performed. =20 >>>> >>>> >>>> Thank you, >>>> >>>> Sabrina Tanamal >>>> IANA Specialist >>>> ICANN >>>> >>>> (END IANA COMMENTS) >>>> >>> >>> There is no question section in that mail. >>> >>> Anything I am missing? >>> >>> thanks=20 >>> >>> Luigi >>> >>> >>> >>>> On 18 Feb 2016, at 01:04, Terry Manderson wrote: >>>> >>>> Terry Manderson has entered the following ballot position for >>>> draft-ietf-lisp-eid-block-mgmnt-06: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to al= l >>>> email addresses included in the To and CC lines. (Feel free to cut t= his >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria= =2Ehtml >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ >>>> >>>> >>>> >>>> --------------------------------------------------------------------= -- >>>> DISCUSS: >>>> --------------------------------------------------------------------= -- >>>> >>>> This is a DISCUSS on behalf of the IANA who are questioning the clar= ity >>>> of text and construction of the EID registry service. >>>> >>>> >>>> >>>> >> --orhgHg5xTUMAbJT19eJSkgJGj4XbR77uu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWxeYsAAoJEBOZRqCi7goq9HoIAIBmej3O40tWyH40VNGNA3yq Iw+5yMLrgVFQfnmFKD2Ll2S6+Im34J5Qcp8zRyZ4EI32grAsc+WG9f8gDfYwiXu5 eqoGxCAdfqyxdL6CkIfUo7+khl/DJBJq/wU8vcGE8E7C7vdKZwDIPo96Xnh9xa/F ++0J5GGW9Afps+wc9UXWVE5uQkkfloXg2i22IcYm++bijbxnCOssGP95KmPrG5Q6 xeErx6L+jNTeLU0uKGULGSinYY0kpkCxb4/gHPkNYgdX2osCgzl9RWGU6KXmtzAz ABKBCEl3FS1//4saXxFAg8kLg+kv531tjMdV19F4M5x02lev0IpxCS+6HXigVl8= =3b/E -----END PGP SIGNATURE----- --orhgHg5xTUMAbJT19eJSkgJGj4XbR77uu-- From nobody Thu Feb 18 08:13:39 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFB31B2A9E; Wed, 17 Feb 2016 12:34:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160217203401.9664.89843.idtracker@ietfa.amsl.com> Date: Wed, 17 Feb 2016 12:34:01 -0800 Archived-At: X-Mailman-Approved-At: Thu, 18 Feb 2016 08:13:36 -0800 Cc: draft-ietf-lisp-eid-block@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org Subject: [lisp] Ben Campbell's No Record on draft-ietf-lisp-eid-block-12: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 20:34:01 -0000 Ben Campbell has entered the following ballot position for draft-ietf-lisp-eid-block-12: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: - section 6: Predictions that the IETF will or will not do something are risky propositions at best. I suggest stating a default result that will occur _unless_ the IETF chooses to take action. Editorial: There's quite a number of grammar and word choice errors. I list some below, but I am sure I did not catch everything. I suggest another pass at proofreading before publication. -3: s/"avoid penalize"/"avoid penalizing" s/"ask an allocation"/"ask for an allocation" ; or "request an allocation" s/"avoid non-LISP domains to fragment " / "allow non-LISP domains to avoid fragmenting" "... which would negatively impact the BGP routing infrastructure" Which would cause negative impact, the fragmentation, or the avoidance of the fragmentation? s/"worth to mention"/"worth mentioning" -4 s/"Such prefix"/"Such prefixes" ; or "This prefix" /"As the LISP adoption progress"/"As the LISP adoption progresses" "... the EID block will potentially help in reducing the impact on the BGP routing infrastructure with respect to the case of the same number of adopters using global unicast space allocated by RIRs " Convoluted sentence. Can it be simplified? s/"Such trend"/"Such trends" ; or "This trend" "With the exception of PITR case (described above)" Which case is the PITR case? This is the first use of PITR. -5: s/"looks as sufficiently large"/"appears sufficiently large" -9: s/"provided by IANA before published"/"provided by IANA before publication" From nobody Thu Feb 18 08:13:41 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E0A1B2AB5; Wed, 17 Feb 2016 13:01:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160217210147.23818.32277.idtracker@ietfa.amsl.com> Date: Wed, 17 Feb 2016 13:01:47 -0800 Archived-At: X-Mailman-Approved-At: Thu, 18 Feb 2016 08:13:36 -0800 Cc: draft-ietf-lisp-eid-block@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org Subject: [lisp] Ben Campbell's No Objection on draft-ietf-lisp-eid-block-12: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 21:01:47 -0000 Ben Campbell has entered the following ballot position for draft-ietf-lisp-eid-block-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: - section 6: Predictions that the IETF will or will not do something are risky propositions at best. I suggest stating a default result that will occur _unless_ the IETF chooses to take action. Editorial: There's quite a number of grammar and word choice errors. I list some below, but I am sure I did not catch everything. I suggest another pass at proofreading before publication. -3: s/"avoid penalize"/"avoid penalizing" s/"ask an allocation"/"ask for an allocation" ; or "request an allocation" s/"avoid non-LISP domains to fragment " / "allow non-LISP domains to avoid fragmenting" "... which would negatively impact the BGP routing infrastructure" Which would cause negative impact, the fragmentation, or the avoidance of the fragmentation? s/"worth to mention"/"worth mentioning" -4 s/"Such prefix"/"Such prefixes" ; or "This prefix" /"As the LISP adoption progress"/"As the LISP adoption progresses" "... the EID block will potentially help in reducing the impact on the BGP routing infrastructure with respect to the case of the same number of adopters using global unicast space allocated by RIRs " Convoluted sentence. Can it be simplified? s/"Such trend"/"Such trends" ; or "This trend" "With the exception of PITR case (described above)" Which case is the PITR case? This is the first use of PITR. -5: s/"looks as sufficiently large"/"appears sufficiently large" -9: s/"provided by IANA before published"/"provided by IANA before publication" From nobody Thu Feb 18 08:13:42 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC911B2E3A; Wed, 17 Feb 2016 13:08:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160217210824.1236.47093.idtracker@ietfa.amsl.com> Date: Wed, 17 Feb 2016 13:08:24 -0800 Archived-At: X-Mailman-Approved-At: Thu, 18 Feb 2016 08:13:36 -0800 Cc: lisp-chairs@ietf.org, draft-ietf-lisp-eid-block-mgmnt@ietf.org, lisp@ietf.org Subject: [lisp] Ben Campbell's No Objection on draft-ietf-lisp-eid-block-mgmnt-06: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 21:08:24 -0000 Ben Campbell has entered the following ballot position for draft-ietf-lisp-eid-block-mgmnt-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block-mgmnt/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share Alvaro's thought that this should be experimental. (And if not that, then a BCP). -4 (and others) The top level "MUST" follow these policies does not need the MUST. The policies have their own 2119 keywords. As written, it implies things like "MUST follow this SHOULD" which is a bit awkward. 4, policy 2: I gather the point is not so much that the registrations need to be renewed as it is they need to expire if not renewed. That is, there's no SHOULD level requirement for a registrant to renew it's registration (maybe no longer needs the registration.) From nobody Fri Feb 26 06:00:11 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4F41B2BFD; Fri, 26 Feb 2016 06:00:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160226140008.22240.98177.idtracker@ietfa.amsl.com> Date: Fri, 26 Feb 2016 06:00:08 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-eid-block-13.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 14:00:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol of the IETF. Title : LISP EID Block Authors : Luigi Iannone Darrel Lewis David Meyer Vince Fuller Filename : draft-ietf-lisp-eid-block-13.txt Pages : 15 Date : 2016-02-26 Abstract: This is a direction to IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as EID (Endpoint IDentifier) addressing space. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-eid-block-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-eid-block-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 26 06:09:04 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C770F1B2C37 for ; Fri, 26 Feb 2016 06:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.16 X-Spam-Level: * X-Spam-Status: No, score=1.16 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QonQUmfURMtY for ; Fri, 26 Feb 2016 06:08:57 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D461B2C34 for ; Fri, 26 Feb 2016 06:08:56 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id a4so71444737wme.1 for ; Fri, 26 Feb 2016 06:08:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=LuT6s0cq0xInf5DDB+/pRVWQ8NhDd6ZDgk6DxyhX1GE=; b=NevD7b2pPDQQ60WEyruFyntMHeu4y9iepfn7xHwmq20FsHb4FrVFbjdCZnW9EbwJlP 6ZNWm3r0TkCbPjCjjqSqnjhbZuTiiIEpgcfLniVrhg9sNzN8jW4Cz3FgI8Ids/169Dyi KBobefDFy0gvJk9IOSNSxw6vdHCInFZJegA4HvTVZJRNzEX5EADg2kRrJ29WBZlfNlst 6RbbgrYsK1IuPEs756QBgILfGzJyxbtL3AUe3d2bb5Hu8NUwNvC2iMTtjDpjS41PlHlW 90WwmkFOLFWYcQpG3LhesTZw3sT7hqTdbgrMueG2z5Dw9FqxIuqWIPeNnti34yyq95yQ 2UEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LuT6s0cq0xInf5DDB+/pRVWQ8NhDd6ZDgk6DxyhX1GE=; b=ChTTOvHQB88JtQovC1sYG1mh+ZGpPsNZMH74l+xWsGkelSEUVlmcjqDUDKQECKhKUG /04XHIc1278Sx7ewW1uochDPmdFBnOI+9T3cBi5EOx1/vtSB7UNLfRjcgdrkuFhxzrA3 HbCV2T8SDiMecbRtWBU+CejBg1vzXf6TUz13xnP7MEiPaAI0nwcT+YJvNnXZU235p+gi dT98ll5dfzONT42Yms3gFnroa+t3i/iXScTcx2b+wD7XVlWaDwzm6tU1kkV1sD6T2yEg 2D6BTRIJ+HY0wbr5tJeuKZrGuBqDWDsFGdt2U0fQykuLSQHLttY4vuklFJwJnCmScm1E BSKA== X-Gm-Message-State: AD7BkJIIw1KwcKxiDTqGo8CgYhEpoUn/55SlNHJtAqtyQ3qyOQREoOGTLD0EX884FgxD4A== X-Received: by 10.194.94.138 with SMTP id dc10mr2233969wjb.37.1456495734770; Fri, 26 Feb 2016 06:08:54 -0800 (PST) Received: from dhcp164-186.enst.fr (dhcp164-186.enst.fr. [137.194.165.186]) by smtp.gmail.com with ESMTPSA id ls5sm12534997wjb.33.2016.02.26.06.08.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Feb 2016 06:08:52 -0800 (PST) Content-Type: multipart/mixed; boundary="Apple-Mail=_629ECA72-78E3-4A2D-8694-81BFDF0971B2" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Luigi Iannone In-Reply-To: <20160215224046.28084.69566.idtracker@ietfa.amsl.com> Date: Fri, 26 Feb 2016 15:09:22 +0100 Message-Id: References: <20160215224046.28084.69566.idtracker@ietfa.amsl.com> To: Alvaro Retana X-Mailer: Apple Mail (2.3112) Archived-At: Cc: draft-ietf-lisp-eid-block@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org, The IESG Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-eid-block-12: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 14:09:03 -0000 --Apple-Mail=_629ECA72-78E3-4A2D-8694-81BFDF0971B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All, This is a reply to Alvaro=E2=80=99s mail but is actually directed to all = IESG members that had comments on the document. Thank for all of your comments. We (hopefully) addressed all of them in = the revised I-D that has been just submitted. I attach a RFCDiff to this mail so that you can easily check fixes. Please let me know if we missed anything. BTW, the document has also been changed from =E2=80=9Cinformational=E2=80=9D= to =E2=80=9Cexperimental=E2=80=9D, as request during IESG review. Have a nice weekend ciao Luigi --Apple-Mail=_629ECA72-78E3-4A2D-8694-81BFDF0971B2 Content-Disposition: attachment; filename=RFCDiff-12-13.html Content-Type: text/html; name="RFCDiff-12-13.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-eid-block-12.txt draft-ietf-lisp-eid-block-13.txt 

Network Working Group                                         L. Iannone
Internet-Draft                                         Telecom ParisTech
Intended status: Informational Experimental                                   D. Lewis
Expires: November 20, 2015 August 29, 2016                             Cisco Systems, Inc.
                                                                D. Meyer
                                                                 Brocade
                                                               V. Fuller
                                                            May 19, 2015
                                                       February 26, 2016

                             LISP EID Block
                    draft-ietf-lisp-eid-block-12.txt
                    draft-ietf-lisp-eid-block-13.txt

Abstract

   This is a direction to IANA to allocate a /32 IPv6 prefix for use
   with the Locator/ID Separation Protocol (LISP).  The prefix will be
   used for local intra-domain routing and global endpoint
   identification, by sites deploying LISP as EID (Endpoint IDentifier)
   addressing space.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 20, 2015. August 29, 2016.

Copyright Notice

   Copyright (c) 2015 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  3
   3.  Rationale and Intent . . . . . . . . . . . . . . . . . . . . .  3
   4.  Expected use . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Block Dimension  . . . . . . . . . . . . . . . . . . . . . . .  5
   6.  3+3 Allocation Plan  . . . . . . . . . . . . . . . . . . . . .  6
   7.  Routing Considerations  Allocation Lifetime  . . . . . . . . . . . . . . . . . . . . .  7
   8.  Security  Routing Considerations . . . . . . . . . . . . . . . . . . . .  7
   9.  IANA  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   10. IANA Considerations  . .  7
   10. Acknowledgments . . . . . . . . . . . . . . . . . . .  8
   11. Acknowledgments  . . . .  9
   11. References . . . . . . . . . . . . . . . . . . .  9
   12. References . . . . . . .  9
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  9
     11.2.  Informative . 10
     12.1.  Normative References  . . . . . . . . . . . . . . . . . 10
   Appendix A.  LISP Terminology . 10
     12.2.  Informative References  . . . . . . . . . . . . . . . . . 11
   Appendix B. A.  Document Change Log . . . . . . . . . . . . . . . . . 13 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

1.  Introduction

   This document directs the IANA to allocate a /32 IPv6 prefix for use
   with the Locator/ID Separation Protocol (LISP - [RFC6830]), LISP Map
   Server ([RFC6833]), LISP Alternative Topology (LISP+ALT - [RFC6836])
   (or other) mapping systems, and LISP Interworking ([RFC6832]).

   This block will be used as global Endpoint IDentifier (EID) space.

2.  Definition of Terms

   The present document does not introduce any new term with respect to
   the set of LISP Specifications ( [RFC6830], [RFC6831], [RFC6832],
   [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC6837]).  To help [RFC6837]), but assumes
   that the
   reading of reader is familiar with the present document LISP terminology.
   [I-D.ietf-lisp-introduction] provides an introduction to the terminology introduced by LISP is
   summarized in Appendix A.
   technology, including its terminology.

3.  Rationale and Intent

   Discussion within the LISP Working Group led to identify several
   scenarios in which the existence of a LISP specific address block
   brings technical benefits.  Hereafter the most relevant scenarios are
   described:

   Early LISP destination detection:  With the current specifications,
         there is no direct way to detect whether or not a certain
         destination is in a LISP domain or not without performing a
         LISP mapping lookup.  For instance, if an ITR is sending to all
         types of destinations (i.e., non-LISP destinations, LISP
         destinations not in the IPv6 EID block, and LISP destinations
         in the IPv6 EID block) the only way to understand whether or
         not to encapsulate the traffic is to perform a cache lookup
         and, in case of a LISP Cache miss, send a Map-Request to the
         mapping system.  In the meanwhile (waiting the Map-Reply),
         packets may be dropped in order to avoid excessive buffering.

   Avoid penalize penalizing non-LISP traffic:  In certain circumstances it might
         be desirable to configure a router using LISP features to
         natively forward all packets that have not a destination
         address in the block, hence, no lookup whatsoever is performed
         and packets destined to non-LISP sites are not penalized in any
         manner.

   Traffic Engineering:  In some deployment scenarios it might be
         desirable to apply different traffic engineering policies for
         LISP and non-LISP traffic.  A LISP specific EID block would
         allow improved traffic engineering capabilities with respect to
         LISP vs. non-LISP traffic.  In particular, LISP traffic might
         be identified without having to use DPI techniques in order to
         parse the encapsulated packet, performing instead a simple
         inspection of the outer header is sufficient.

   Transition Mechanism:  The existence of a LISP specific EID block may
         prove useful in transition scenarios.  A non-LISP domain would
         ask for an allocation in the LISP EID block and use it to
         deploy LISP in its network.  Such allocation will not be
         announced in the BGP routing infrastructure (cf., Section 4).
         This approach will avoid allow non-LISP domains to fragment avoid fragmenting
         their already allocated non-LISP addressing space, which may
         lead to BGP routing table inflation since it may (rightfully)
         be announced in the BGP routing infrastructure.

   Limit the impact on BGP routing infrastructure:  As described in the
         previous scenario, LISP adopters will avoid fragmenting their
         addressing space, which since fragmentation would negatively impact
         the BGP routing infrastructure.  Adopters will use addressing
         space from the EID block, which might be announced in large
         aggregates and in a tightly controlled manner only by proxy
         xTRs.

   Is worth to mention mentioning that new use cases can arise in the future, due
   to new and unforeseen scenarios.

   Furthermore, the use of a dedicated address block will give a tighter
   control, especially filtering, over the traffic in the initial
   experimental phase, while facilitating its large-scale deployment.

   [RFC3692] considers assigning experimental and testing numbers
   useful, and the request of a reserved IPv6 prefix is a perfect match
   of such practice.  The present document follows the guidelines
   provided in [RFC3692], with one exception.  [RFC3692] suggests the
   use of values similar to those called "Private Use" in [RFC5226],
   which by definition are not unique.  One of the purposes of the
   present request to IANA is to guarantee uniqueness to the EID block.
   The lack thereof would result in a lack of real utility of a reserved
   IPv6 prefix.

4.  Expected use

   Sites planning to deploy LISP may request a prefix in the IPv6 EID
   block.  Such prefix prefixes will be used for routing and endpoint
   identification inside the site requesting it.  Mappings related to
   such prefix, or part of it, will be made available through the
   mapping system in use and registered to one or more Map Server(s).

   The EID block must be used for LISP experimentation and must not be
   advertised in the form of more specific route advertisements in the
   non-LISP inter-domain routing environment.  Interworking between the
   EID block sub-prefixes and the non-LISP Internet is done according to
   [RFC6832] and [RFC7215].

   As the LISP adoption progress, progresses, the EID block will may potentially help in
   reducing the have a
   reduced impact on the BGP routing infrastructure with respect infrastructure, compared to the
   case of having the same number of adopters using global unicast space
   allocated by RIRs ([MobiArch2007]).  From a short-term perspective,
   the EID block offers potentially large aggregation capabilities since
   it is announced by PxTRs possibly concentrating several contiguous
   prefixes.  Such  This trend should continue with even lower impact from a
   long-term perspective, since more aggressive aggregation can be used,
   potentially leading at using few PxTRs announcing the whole EID block
   ([FIABook2010]).

   The EID block will be used only at configuration level, it is
   recommended not to hard-code in any way the IPv6 EID block in the
   router hardware.  This allows avoiding locking out sites that may
   want to switch to LISP while keeping their own IPv6 prefix, which is
   not in the IPv6 EID block.  Furthermore, in the case of a future
   permanent allocation, the allocated prefix may differ from the
   experimental temporary prefix allocated during the experimentation
   phase.

   With the exception of PITR case (described above) in Section 8) prefixes out
   of the EID block must not be announced in the BGP routing
   infrastructure.

5.  Block Dimension

   The working group reached consensus on an initial allocation of a /32
   prefix.  The reason of such consensus is manifold:

   o  The working group agreed that /32 prefix is sufficiently large to
      cover initial allocation and requests for prefixes in the EID
      space in the next few years for very large-scale experimentation
      and deployment.

   o  As a comparison, it is worth mentioning that the current LISP Beta
      Network ([BETA]) is using a /32 prefix, with more than 250 sites
      using a /48 sub prefix.  Hence, a /32 prefix looks as appears sufficiently
      large to allow the current deployment to scale up and be open for
      interoperation with independent deployments using EIDs in the new
      /32 prefix.

   o  A /32 prefix is sufficiently large to allow deployment of
      independent (commercial) LISP enabled networks by third parties,
      but may as well boost LISP experimentation and deployment.

   o  The use of a /32 prefix is in line with previous similar prefix
      allocation for tunneling protocols ([RFC3056]).

6.  3+3 Allocation Plan

   This document requests IANA to initially assign a /32 prefix out of
   the IPv6 addressing space for use as EID in LISP (Locator/ID
   Separation Protocol).

   IANA should assign allocates the requested address space by beginning 2015 MMMM/YYYY0 for a
   duration of 3 (three) initial years (through December 2018), MMMM/YYYY3), with an
   option to extend this period by 3 (three) more years (until
   December 2021). MMMM/
   YYYY6).  By the end of the first period, the IETF will provide a
   decision on whether to transform the prefix in a permanent assignment
   or to put it back in the free pool. pool (see Section 7 for more
   information).

   [RFC Editor: please replace MMMM and all its occurrences in the
   document with the month of publication as RFC.]

   [RFC Editor: please replace YYYY0 and all its occurrences in the
   document with the year of publication as RFC.]

   [RFC Editor: please replace YYYY3 and all its occurrences in the
   document with the year of publication as RFC plus 3 years, e.g., if
   published in 2016 then put 2019.]

   [RFC Editor: please replace YYYY6 and all its occurrences in the
   document with the year of publication as RFC plus 6 years, e.g., if
   published in 2016 then put 2022.]

   In the first case, i.e., if the IETF decides to transform the block
   in a permanent allocation, the EID block allocation period will be
   extended for three years (until December 2021) MMMM/YYYY6) so to give time to the
   IETF to define the final size of the EID block and create a
   transition plan.  The transition of the EID block into a permanent
   allocation has the potential to pose policy issues (as recognized in
   [RFC2860], section 4.3) and hence discussion with the IANA, the RIR
   communities, and the IETF community will be necessary to determine
   appropriate policy for permanent EID block allocation and management.
   Note as well that the final permanent allocation may differ from the
   initial experimental assignment, hence, it is recommended not to
   hard-code in any way the experimental EID block on LISP-capable
   devices.

   In the latter case, i.e., if the IETF decides to stop the EID block
   experimental use, by December 2018 MMMM/YYYY3 all temporary prefix allocations in
   such address range must expire and be released, so that by January
   2018 the entire
   /32 is returned to the free pool.

   The allocation and management of the EID block for the initial 3
   years period (and the optional 3 more years) is detailed in
   [I-D.ietf-lisp-eid-block-mgmnt].

7.  Routing Considerations

   In order to provide connectivity between  Allocation Lifetime

   If no explicit action is carried out by the Legacy Internet and LISP
   sites, PITRs announcing large aggregates (ideally one single large
   aggregate) end of the IPv6 EID experiment (by
   MMMM/YYYY3) it is automatically considered that there was no
   sufficient interest in having a permanent allocation and the address
   block could be deployed.  By doing so,
   PITRs will attract traffic destined be returned to the free pool.

   Otherwise, if the LISP sites Working Group recognizes that there is value
   in having a permanent allocation then explicit action is needed.

   In order to
   encapsulate and forward it toward trigger the specific destination LISP site.
   Routers process for a permanent allocation a document
   is required.  Such document has to articulate the rationale why a
   permanent allocation would be beneficial.  More specifically, the
   document has to detail the experience gained during experimentation
   and all of the technical benefits provided by the use of a LISP
   specific prefix.  Such technical benefits are expected to lay in the
   scenarios described in Section 3, however, new unforeseen benefits
   may appear during experimentation.  The description should be
   sufficiently articulate so to allow to provide an estimation of what
   should be the size of the permanent allocation.  Note however that,
   as explained in Section 6, it is up to IANA to decide which address
   block will be used as permanent allocation and that such block may be
   different from the temporary experimental allocation.

8.  Routing Considerations

   In order to provide connectivity between the Legacy Internet and LISP
   sites, PITRs announcing large aggregates (ideally one single large
   aggregate) of the IPv6 EID block could be deployed.  By doing so,
   PITRs will attract traffic destined to LISP sites in order to
   encapsulate and forward it toward the specific destination LISP site.
   Routers in the Legacy Internet must treat announcements of prefixes
   from the IPv6 EID block as normal announcements, applying best
   current practice for traffic engineering and security.

   Even in a LISP site, not all routers need to run LISP elements.  In
   particular, routers that are not at the border of the local domain,
   used only for intra-domain routing, do not need to provide any
   specific LISP functionality but must be able to route traffic using
   addresses in the IPv6 EID block.

   For the above-mentioned reasons, routers that do not run any LISP
   element, must not include any special handling code or hardware for
   addresses in the IPv6 EID block.  In particular, it is recommended
   that the default router configuration does not handle such addresses
   in any special way.  Doing differently could prevent communication
   between the Legacy Internet and LISP sites or even break local intra-
   domain connectivity.

8.

9.  Security Considerations

   This document does not introduce new security threats in the LISP
   architecture nor in the legacy Internet architecture.

9.

10.  IANA Considerations

   This document instructs the IANA to assign a /32 IPv6 prefix for use
   as the global LISP EID space using a hierarchical allocation as
   outlined in [RFC5226] and summarized in Table 1.

   This document does not specify any specific value for the requested
   address block but suggests that should come from the 2000::/3 Global
   Unicast Space.  IANA is not requested to issue an AS0 ROA (Route
   Origin Attestation [RFC6491]), since the Global EID Space will be
   used for routing purposes.

               +----------------------+--------------------+
               | Attribute            | Value              |
               +----------------------+--------------------+
               | Address Block        | XXXX:YYYY::/32 [1] 2001:5::/32        |
               | Name                 | EID Space for LISP |
               | RFC                  | [This Document]    |
               | Allocation Date      | 2015 [2]               |
               | Termination Date     | December 2018 [3] MMMM/YYYY3 [1]     |
               | Source               | True [4] [2]           |
               | Destination          | True               |
               | Forwardable          | True               |
               | Global               | True               |
               | Reserved-by-protocol | True [5] [3]           |
               +----------------------+--------------------+

    [1] XXXX and YYYY values to be provided by IANA before published as
      RFC. [2] The actual allocation date to be provided by IANA. [3] According to the 3+3 Plan outlined in this document termination
    date can be postponed to December 2021. [4] MMMM/YYYY6. [2] Can be used as a multicast
   source as well. [5] [3] To be used as EID space by LISP [RFC6830] enabled
                                 routers.

                         Table 1: Global EID Space

   This document does not specify any specific value for the requested
   address block but suggests that should come from

   [IANA: Please update the 2000::/3 Global
   Unicast Space.  IANA is not requested to issue an AS0 ROA, since Termination Date and footnote [1] in the
   Global EID Space will be used for routing purposes.
   Special-Purpose Address Registry when the I-D is published as RFC.]

   The reserved address space is requested for a period of time of three
   initial years starting in beginning 2015 MMMM/YYYY0 (until December 2018), MMMM/YYYY3), with an
   option to extend it by three years (until December 2021) MMMM/YYYY6) up on decision
   of the IETF (see Section 6). 6 and Section 7).  Following the policies
   outlined in [RFC5226], upon IETF Review, by December 2018 MMMM/YYYY3 decision
   should be made on whether to have a permanent EID block assignment.
   If no explicit action is taken or if the IETF review outcome will be
   that is not worth to have a reserved prefix as global EID space, the
   whole /32 will be taken out from the IPv6 Special Purpose Address
   Registry and put back in the free pool managed by IANA by end of January 2018. IANA.

   Allocation and management of the Global EID Space is detailed in a
   different document.  Nevertheless, all prefix allocations out of this
   space must be temporary and no allocation must go beyond December
   2018 MMMM/YYYY3
   unless the IETF Review decides for a permanent Global EID Space
   assignment.

10.

11.  Acknowledgments

   Special thanks to Roque Gagliano for his suggestions and pointers.
   Thanks to Alvaro Retana, Deborah Brungard, Ron Bonica, Damien Saucez,
   David Conrad, Scott Bradner, John Curran, Paul Wilson, Geoff Huston,
   Wes George, Arturo Servin, Sander Steffann, Brian Carpenter, Roger
   Jorgensen, Terry Manderson, Brian Haberman, Adrian Farrel, Job
   Snijders, Marla Azinger, Chris Morrow, and Peter Schoenmaker, for
   their insightful comments.  Thanks as well to all participants to the
   fruitful discussions on the IETF mailing list.

   The work of Luigi Iannone has been partially supported by the ANR-13-
   INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT-
   Labs SOFNETS Project.

11.

12.  References

11.1.

12.1.  Normative References

   [I-D.ietf-lisp-eid-block-mgmnt]
              Iannone, L., Jorgensen, R., Conrad, D., and G. Huston,
              "LISP EID Block Management Guidelines",
              draft-ietf-lisp-eid-block-mgmnt-04
              draft-ietf-lisp-eid-block-mgmnt-06 (work in progress),
              December 2014.
              August 2015.

   [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
              Understanding Concerning the Technical Work of the
              Internet Assigned Numbers Authority", RFC 2860,
              DOI 10.17487/RFC2860, June 2000. 2000,
              <http://www.rfc-editor.org/info/rfc2860>.

   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82, RFC 3692, DOI 10.17487/
              RFC3692, January 2004.

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, August 2006. 2004,
              <http://www.rfc-editor.org/info/rfc3692>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008. 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              DOI 10.17487/RFC6830, January 2013. 2013,
              <http://www.rfc-editor.org/info/rfc6830>.

   [RFC6831]  Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
              Locator/ID Separation Protocol (LISP) for Multicast
              Environments", RFC 6831, DOI 10.17487/RFC6831,
              January 2013. 2013, <http://www.rfc-editor.org/info/rfc6831>.

   [RFC6832]  Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking between Locator/ID Separation Protocol
              (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/
              RFC6832, January 2013. 2013,
              <http://www.rfc-editor.org/info/rfc6832>.

   [RFC6833]  Fuller, V. and D. Farinacci, "Locator/ID Separation
              Protocol (LISP) Map-Server Interface", RFC 6833,
              DOI 10.17487/RFC6833, January 2013. 2013,
              <http://www.rfc-editor.org/info/rfc6833>.

   [RFC6834]  Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
              Separation Protocol (LISP) Map-Versioning", RFC 6834,
              DOI 10.17487/RFC6834, January 2013. 2013,
              <http://www.rfc-editor.org/info/rfc6834>.

   [RFC6835]  Farinacci, D. and D. Meyer, "The Locator/ID Separation
              Protocol Internet Groper (LIG)", RFC 6835, DOI 10.17487/
              RFC6835, January 2013. 2013,
              <http://www.rfc-editor.org/info/rfc6835>.

   [RFC6836]  Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol Alternative Logical
              Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
              January 2013. 2013, <http://www.rfc-editor.org/info/rfc6836>.

   [RFC6837]  Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
              Routing Locator (RLOC) Database", RFC 6837, DOI 10.17487/
              RFC6837, January 2013.

11.2. 2013,
              <http://www.rfc-editor.org/info/rfc6837>.

12.2.  Informative References

   [BETA]     LISP Beta Network, "http://www.lisp4.net".

   [FIABook2010]
              L. Iannone, T. Leva, "Modeling the economics of Loc/ID
              Separation for the Future Internet.", Towards the Future
              Internet - Emerging Trends from the European Research,
              Pages 11-20, ISBN: 9781607505389, IOS Press , May 2010.

   [I-D.ietf-lisp-introduction]
              Cabellos-Aparicio, A. and D. Saucez, "An Architectural
              Introduction to the Locator/ID Separation Protocol
              (LISP)", draft-ietf-lisp-introduction-13 (work in
              progress), April 2015.

   [MobiArch2007]
              B. Quoitin, L. Iannone, C. de Launois, O. Bonaventure,
              "Evaluating the Benefits of the Locator/Identifier
              Separation", The 2nd ACM-SIGCOMM International Workshop on
              Mobility in the Evolving Internet Architecture
              (MobiArch'07) , August 2007.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056,
              February 2001, <http://www.rfc-editor.org/info/rfc3056>.

   [RFC6491]  Manderson, T., Vegoda, L., and S. Kent, "Resource Public
              Key Infrastructure (RPKI) Objects Issued by IANA",
              RFC 6491, DOI 10.17487/RFC6491, February 2001. 2012,
              <http://www.rfc-editor.org/info/rfc6491>.

   [RFC7215]  Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
              Pascual, J., and D. Lewis, "Locator/Identifier Separation
              Protocol (LISP) Network Element Deployment
              Considerations", RFC 7215, DOI 10.17487/RFC7215,
              April 2014. 2014, <http://www.rfc-editor.org/info/rfc7215>.

Appendix A.  LISP Terminology

   LISP operates on two name spaces and introduces several new network
   elements.  To facilitate the reading,  Document Change Log

   [RFC Editor: Please remove this section provides high-
   level definitions of the LISP name spaces and network elements and,
   as such, it must not be considered on publication as an authoritative source.  The
   reference RFC]

   Version 13 Posted MMMM 2016.

   o  Changed I-D type from "Informational" to "Experimental" as
      requested by A. Retana during IESG review.

   o  Dropped the authoritative document for each term is included in
   every term description.

   Legacy Internet:  The portion of appendix "LISP Terminology"; replaced by pointer to
      the Internet that does not run LISP
      and does not participate in LISP+ALT or any other mapping system.

   LISP site:  A LISP site is a set of routers in an edge network that
      are under a single technical administration. LISP routers that
      reside in the edge network are the demarcation points Introduction document.

   o  Added Section 7 to separate clarify the edge network from process after the core network.  See [RFC6830] for more
      details.

    Endpoint ID (EID):  An EID is a 32-bit (for IPv4) or 128-bit (for
      IPv6) value used in 3 years
      experimental allocation.

   o  Modified the source dates, introducing variables, so to allow RFC Editor
      to easily update dates by publication as RFC.

   Version 12 Posted May 2015.

   o  Fixed typos and destination address fields of
      the first (most inner) LISP header of a packet.  A packet that is
      emitted references as suggested by a system contains EIDs in its headers and LISP headers
      are prepended only when the packet reaches an Ingress Tunnel
      Router (ITR) on the data path to the destination EID.  The source
      EID is obtained via existing mechanisms used to set a host's
      "local" IP address.  An EID is allocated to a host from an EID-
      prefix block associated with the site where the host is located.
      See [RFC6830] for more details.

   EID-prefix:  A power-of-two block of EIDs that are allocated to a
      site by an address allocation authority.  See [RFC6830] for more
      details.

   EID-Prefix Aggregate:  A set of EID-prefixes said to be aggregatable
      in the [RFC4632] sense.  That is, an EID-Prefix aggregate is
      defined to be a single contiguous power-of-two EID-prefix block.
      A prefix and a length characterize such a block.  See [RFC6830]
      for more details.

   Routing LOCator (RLOC):  A RLOC is an IPv4 or IPv6 address of an
      egress tunnel router (ETR).  A RLOC is the output of an EID-to-
      RLOC mapping lookup.  An EID maps to one or more RLOCs.
      Typically, RLOCs are numbered from topologically aggregatable
      blocks that are assigned to a site at each point to which it
      attaches to the global Internet; where the topology is defined by
      the connectivity of provider networks, RLOCs can be thought of as
      Provider Aggregatable (PA) addresses.  See [RFC6830] for more
      details.

    EID-to-RLOC Mapping:  A binding between an EID-Prefix and the RLOC-
      set that can be used to reach the EID-Prefix.  The general term
      "mapping" always refers to an EID-to-RLOC mapping.  See [RFC6830]
      for more details.

   Ingress Tunnel Router (ITR):  An Ingress Tunnel Router (ITR) is a
      router that accepts receives IP packets from site end-systems on
      one side and sends LISP-encapsulated IP packets toward the
      Internet on the other side.  The router treats the "inner" IP
      destination address as an EID and performs an EID-to-RLOC mapping
      lookup.  The router then prepends an "outer" IP header with one of
      its globally routable RLOCs in the source address field and the
      result of the mapping lookup in the destination address field.
      See [RFC6830] for more details.

   Egress Tunnel Router (ETR):  An Egress Tunnel Router (ETR) receives
      LISP-encapsulated IP packets from the Internet on one side and
      sends decapsulated IP packets to site end-systems on the other
      side.  An ETR router accepts an IP packet where the destination
      address in the "outer" IP header is one of its own RLOCs.  The
      router strips the "outer" header and forwards the packet based on
      the next IP header found.  See [RFC6830] for more details.

   Proxy ITR (PITR):  A Proxy-ITR (PITR) acts like an ITR but does so on
      behalf of non-LISP sites which send packets to destinations at
      LISP sites.  See [RFC6832] for more details.

   Proxy ETR (PETR):  A Proxy-ETR (PETR) acts like an ETR but does so on
      behalf of LISP sites which send packets to destinations at non-
      LISP sites.  See [RFC6832] for more details.

   Map Server (MS):  A network infrastructure component that learns EID-
      to-RLOC mapping entries from an authoritative source (typically an
      ETR).  A Map Server publishes these mappings in the distributed
      mapping system.  See [RFC6833] for more details.

   Map Resolver (MR):  A network infrastructure component that accepts
      LISP Encapsulated Map-Requests, typically from an ITR, quickly
      determines whether or not the destination IP address is part of
      the EID namespace; if it is not, a Negative Map-Reply is
      immediately returned.  Otherwise, the Map Resolver finds the
      appropriate EID-to-RLOC mapping by consulting the distributed
      mapping database system.  See [RFC6833] for more details.

   The LISP Alternative Logical Topology (ALT):  The virtual overlay
      network made up of tunnels between LISP+ALT Routers.  The Border
      Gateway Protocol (BGP) runs between ALT Routers and is used to
      carry reachability information for EID-prefixes.  The ALT provides
      a way to forward Map-Requests toward the ETR that "owns" an EID-
      prefix.  See [RFC6836] for more details.

   ALT Router:  The device on which runs the ALT.  The ALT is a static
      network built using tunnels between ALT Routers.  These routers
      are deployed in a roughly-hierarchical mesh in which routers at
      each level in the topology are responsible for aggregating EID-
      Prefixes learned from those logically "below" them and advertising
      summary prefixes to those logically "above" them.  Prefix learning
      and propagation between ALT Routers is done using BGP.  When an
      ALT Router receives an ALT Datagram, it looks up the destination
      EID in its forwarding table (composed of EID-Prefix routes it
      learned from neighboring ALT Routers) and forwards it to the
      logical next-hop on the overlay network.  The primary function of
      LISP+ALT routers is to provide a lightweight forwarding
      infrastructure for LISP control-plane messages (Map-Request and
      Map-Reply), and to transport data packets when the packet has the
      same destination address in both the inner (encapsulating)
      destination and outer destination addresses ((i.e., a Data Probe
      packet).  See [RFC6836] for more details.

Appendix B.  Document Change Log

   Version 12 Posted May 2015.

   o  Fixed typos and references as suggested by the Gen-ART the Gen-ART and OPS-DIR
      review.

   Version 11 Posted April 2015.

   o  In Section 4, deleted contradictory text on EID prefix
      advertisement in non-LISP inter-domain routing environments.

   o  In Section 3 deleted the "Avoid excessive strech" bullet, because
      confusing.

   o  Deleted last bullet of the list in Section 3 because retundant
      w.r.t. global content of the document.

   Version 10 Posted January 2015.

   o  Keep alive version

   Version 09 Posted July 2014.

   o  Few Editorial modifications as requested by D. Saucez, as
      shepherd, during the write up of the document.

   o  Allocation date postponed to beginning 2015, as suggested by D.
      Saucez.

   Version 08 Posted January 2014.

   o  Modified Section 4 as suggested by G. Houston.

   Version 07 Posted November 2013.

   o  Modified the document so to request a /32 allocation, as for the
      consensus reached during IETF 88th.

   Version 06 Posted October 2013.

   o  Clarified the rationale and intent of the EID block request with
      respect to [RFC3692], as suggested by S. Bradner and J. Curran.

   o  Extended Section 3 by adding the transion scenario (as suggested
      by J. Curran) and the TE scenario.  The other scenarios have been
      also edited.

   o  Section 6 has been re-written to introduce the 3+3 allocation plan
      as suggested by B. Haberman and discussed during 86th IETF.

   o  Section 9 10 has also been updated to the 3+3 years allocation plan.

   o  Moved Section 10 11 at the end of the document.

   o  Changed the original Definition of terms to an appendix.

   Version 05 Posted September 2013.

   o  No changes.

   Version 04 Posted February 2013.

   o  Added Table 1 as requested by IANA.

   o  Transformed the prefix request in a temporary request as suggested
      by various comments during IETF Last Call.

   o  Added discussion about short/long term impact on BGP in Section 4
      as requested by B. Carpenter.

   Version 03 Posted November 2012.

   o  General review of Section 5 as requested by T. Manderson and B.
      Haberman.

   o  Dropped RFC 2119 Notation, as requested by A. Farrel and B.
      Haberman.

   o  Changed "IETF Consensus" to "IETF Review" as pointed out by Roque
      Gagliano.

   o  Changed every occurrence of "Map-Server" and "Map-Resolver" with
      "Map Server" and "Map Resolver" to make the document consistent
      with [RFC6833].  Thanks to Job Snijders for pointing out the
      issue.

   Version 02 Posted April 2012.

   o  Fixed typos, nits, references.

   o  Deleted reference to IANA allocation policies.

   Version 01 Posted October 2011.

   o  Added Section 5.

   Version 00 Posted July 2011.

   o  Updated section "IANA Considerations"

   o  Added section "Rationale and Intent" explaining why the EID block
      allocation is useful.

   o  Added section "Expected Use" explaining how sites can request and
      use a prefix in the IPv6 EID Block.

   o  Added section "Action Plan" suggesting IANA to avoid allocating
      address space adjacent the allocated EID block in order to
      accommodate future EID space requests.

   o  Added section "Routing Consideration" describing how routers not
      running LISP deal with the requested address block.

   o  Added the present section to keep track of changes.

   o  Rename of draft-meyer-lisp-eid-block-02.txt.

Authors' Addresses

   Luigi Iannone
   Telecom ParisTech

   Email: ggx@gigix.net

   Darrel Lewis
   Cisco Systems, Inc.

   Email: darlewis@cisco.com

   David Meyer
   Brocade

   Email: dmm@1-4-5.net

   Vince Fuller

   Email: vaf@vaf.net
X-Generator: pyht 0.35 --Apple-Mail=_629ECA72-78E3-4A2D-8694-81BFDF0971B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 15 Feb 2016, at 23:40, Alvaro Retana wrote: >=20 > Alvaro Retana has entered the following ballot position for > draft-ietf-lisp-eid-block-12: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This document is clearly requesting the assignment of LISP EID space = for > an experiment. Why is it not an Experimental document? [I may have > missed the discussion in the archive.] >=20 > Along the same lines, the conditions for the experiment to be = successful > and the IETF to consider whether to transform the prefix into a = permanent > assignment (Section 6. 3+3 Allocation Plan) are not defined. How = should > this decision be made? How will the IETF know the experiment is > successful? >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > An early allocation was made in October/2015. The values should be > included in the document. >=20 > The dates mentioned assumed a start date of December/2015, but the > document isn't getting approved until now =E2=80=94 is there a need to = change the > dates? Just wondering =E2=80=94 part of it is that I'm not sure if = RIPE has > already started allocating addresses or not. >=20 > Please expand ROA and put in a reference. >=20 >=20 --Apple-Mail=_629ECA72-78E3-4A2D-8694-81BFDF0971B2--