Re: [lisp] WG Charter

"Joel M. Halpern" <> Thu, 02 July 2015 16:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7E3351AD182 for <>; Thu, 2 Jul 2015 09:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TnZefs2zzQ0C for <>; Thu, 2 Jul 2015 09:34:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F4EC1AD1FE for <>; Thu, 2 Jul 2015 09:34:21 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FD8E251F6A; Thu, 2 Jul 2015 09:34:21 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at
Received: from Joels-MacBook-Pro.local ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1FBCE24028F; Thu, 2 Jul 2015 09:34:21 -0700 (PDT)
To: Dino Farinacci <>
References: <> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Thu, 2 Jul 2015 12:34:22 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: "" <>
Subject: Re: [lisp] WG Charter
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, 02 Jul 2015 16:34:38 -0000

Just addressing one aspect here that strikes me as being helpful to the 

On 7/2/15 12:06 PM, Dino Farinacci wrote:
>> First, there is the question of direction for the basic LISP
>> specification.  We can leave it as it is.  However, folks have
>> asked us about moving it to Proposed Standard.  Based on our
>> reading and discussion with relevant ADs, one path to do this would
>> be to refocus the specification away from the core Internet scaling
>> problems, and instead towards a scalable anxd flexible overlay
>> technology.  This would not change the technical procedures, but
>> would have significnat impact on the descriptive text.
> This is fine but I am a bit worried we’ll spend time on “texting” and
> not creating anything new. We are way overdue in progressing use-case
> documents that people want to deploy, so I would like to make sure
> one work item doesn’t gate others.
> That is, I hope we can work in parallel. Where I do believe we WILL
> NOT lose focus.

The re-focusing of of 6830 will probably be almost exclusive 
word-smithing.  The intention is not to change the protocol behaviors at 
all.  We will likely remove text that is covered by the introduction and 
similarly remove text about solving the core scaling problem.    (Yes, 
spending energy on wording is annoying, unfortunate, and sometimes 

Since it is about the wording, not about changing any formats or 
procedures, I very much agree that this can and should go on in parallel 
with the work on addressing the technical topics we want to see covered.