Re: [lisp] Jari Arkko's Block on charter-ietf-lisp-03-00: (with BLOCK)

Jari Arkko <> Thu, 04 February 2016 07:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B7D7E1A079D; Wed, 3 Feb 2016 23:12:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 72lH9GLaDJKh; Wed, 3 Feb 2016 23:12:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id ABDBC1A047A; Wed, 3 Feb 2016 23:12:55 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10F8C2CCBF; Thu, 4 Feb 2016 09:12:54 +0200 (EET) (envelope-from
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8zqB96S-cFox; Thu, 4 Feb 2016 09:12:53 +0200 (EET)
Received: from [] ( [IPv6:2a00:1d50:2::130]) by (Postfix) with ESMTP id 6AC0C2CC9A; Thu, 4 Feb 2016 09:12:52 +0200 (EET) (envelope-from
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: <>
Date: Thu, 4 Feb 2016 08:12:35 +0100
Message-Id: <>
References: <> <>
To: "Joel M. Halpern" <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc:, The IESG <>,
Subject: Re: [lisp] Jari Arkko's Block on charter-ietf-lisp-03-00: (with BLOCK)
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


> 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’t 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, …).

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.