Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..)

Job Snijders <job@instituut.net> Fri, 28 October 2016 14:45 UTC

Return-Path: <job@instituut.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE09129B0A for <idr@ietfa.amsl.com>; Fri, 28 Oct 2016 07:45:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com
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 EUfLd2hZXW-E for <idr@ietfa.amsl.com>; Fri, 28 Oct 2016 07:45:20 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 6BE2F129B14 for <idr@ietf.org>; Fri, 28 Oct 2016 07:45:19 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id y2so125520858oie.0 for <idr@ietf.org>; Fri, 28 Oct 2016 07:45:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KbYU81bt9GzmnH3zPPYrs1vaa1Og7HNf3ksJ/V6jtE8=; b=Cf+8wPHZp2TEPgkMvuXxf+Hyy8h0QLLBle4h/f+jWmb//Ny/oQm7xId/iRQaZVHbSy Ux6Nfinr5eJ0mAS+vwaP+qPMThUNSDrBV09VM8366sCWdYEj24dobIdDdS1sg1tv7ijv nKO73I65mvf3OAA1NuSUa64Au54YHG+OQLelKSQyETr+3ts/z1q4hhsaPdXo5/zsdCpA hgcEUkvQIlcWErXpETKwoVEXFChC1t+dvo7JDw0dltLHgZUlSeOsk/PgZSzqL6owXBTS R5b0gK3N7MePlQr8LIgdqgczkOjrUzTQaz+chIqOIbrVElEIw8XNJlOfBSAor2YtZugh 4hjA==
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:from:date :message-id:subject:to:cc; bh=KbYU81bt9GzmnH3zPPYrs1vaa1Og7HNf3ksJ/V6jtE8=; b=i56+RoK93me9AKvaKflfcItEXmVlAv8e/MxT8akfiy1go1hkyX4dbrmWpBwBE0qnqS eE1ozssfwi8qalYAgubnXysTHzU5D/x0DWyT2Y9N51lkPc9Z4BV0CVE3xI1fiOcJDEBY jg4s2pbHLv1dz2ZCd1tp05cXUMYK+6QL/o4iL989TUPszBV5/UkDtupiGeFmkV+qewIJ 2Sw1P+WgVhKWrjGCQQ6lvcWLGiskZ6OXp6c7dJpW7W+SgLAzcv1pvxWl4Yf4rUyfj5Pw V9BwfKXeTGbwbR3VSz8JAnZBaB4gRg8riXdDp7KtcGISrPXHHx+BwdpNBbZ5SZYA87SV MOhQ==
X-Gm-Message-State: ABUngvcjZOules+DrJi8dTz4ixXW2k6W/3D4SutXUmJLtf769lzyTiJ0IymYcExrqgVfGSjSSid2Sdpxhiizwg==
X-Received: by 10.202.81.5 with SMTP id f5mr4785985oib.24.1477665918261; Fri, 28 Oct 2016 07:45:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.86.34 with HTTP; Fri, 28 Oct 2016 07:45:17 -0700 (PDT)
X-Originating-IP: [89.200.14.188]
In-Reply-To: <5783C8A8-AB9B-4FED-AA44-EDEE052671A7@juniper.net>
References: <CAL9jLaZcCwBhUEs7cvsx3HfiPSRPXrcvOguCeuV2opSns9OZMw@mail.gmail.com> <677CE346-EFED-42B6-8A9F-75ABD2B4D6B4@cisco.com> <EBCE3CE8-1295-4CB2-9A1A-8BA2E154033D@gmail.com> <6e6a37a2a51eab848e9d498a1437365f@www.lamehost.it> <524D6F67-AAFA-4880-B977-8262333DFF5B@steffann.nl> <20161027095404.GP37101@Vurt.local> <CAH1iCipJNye8fpvFwBwoLkL3+=rWVcZac2BUFVcJXQ_9YTrXvg@mail.gmail.com> <BB1CCBAD-F278-4309-8520-06CC9FD825BD@exa.net.uk> <20161028110851.GA966@Vurt.local> <m237jgk97g.wl-randy@psg.com> <20161028122402.GB966@Vurt.local> <58136016.1070203@foobar.org> <5783C8A8-AB9B-4FED-AA44-EDEE052671A7@juniper.net>
From: Job Snijders <job@instituut.net>
Date: Fri, 28 Oct 2016 16:45:17 +0200
Message-ID: <CACWOCC-7BWV2x0mAd6Rcw69RiVqzXG5JL64N4z=bQToA7LvhLA@mail.gmail.com>
To: "John G. Scudder" <jgs@juniper.net>
Content-Type: multipart/alternative; boundary=001a113d7e8827cfc0053fede8ad
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/BrlDbYcnAgJUWjXzFa2ZmONlAdY>
Cc: IETF IDR Working Group <idr@ietf.org>
Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2016 14:45:23 -0000

If values are picked for development, I'd pick them closer to 255 rather
then apply a degenerate distribution.

It is my understanding too that deprecation is temporary in that the
working group can undeprecate them in the future.

Kind regards,

Job

On Friday, 28 October 2016, John G. Scudder <jgs@juniper.net>; wrote:

> On Oct 28, 2016, at 10:26 AM, Nick Hilliard <nick@foobar.org
> <javascript:;>> wrote:
> >
> > Job Snijders wrote:
> >> https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-00
> >
> > pls specify timeout in deprecation:
> >
> > https://www.ietf.org/mail-archive/web/idr/current/msg16576.html
>
> (Individual contributor hat)
>
> Ha, and I was just about to send a message saying I couldn't imagine
> needing to polish this document. Obviously, my imagination needs an upgrade.
>
> I'm not aware of a precedent for specifying a timeout in a deprecation, in
> fact I'm not sure what it means. I'm not sure what benefit it would bring
> either. I do see Sue's message you referenced, but the point of that, and
> also my own message around the same time, is that deprecation is one step
> in the state machine, necessary before code point reuse. I don't think we
> need to either specify either a minimum, nor a maximum, time the code point
> may spend in that state.
>
> I note that in parallel the working group has been discussing the idea of
> reusing these code points to expand the Experimental range (currently
> called "reserved for development"), so we may end up reusing them rather
> soon. In any case, deprecation is the first step toward doing that, so I
> think we may as well just get on with it with a minimum of fuss.
>
> --John
> _______________________________________________
> Idr mailing list
> Idr@ietf.org <javascript:;>
> https://www.ietf.org/mailman/listinfo/idr
>