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

Jeffrey Haas <> Fri, 28 October 2016 14:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 323E91293F5 for <>; Fri, 28 Oct 2016 07:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.333
X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MDDD284dI0Ov for <>; Fri, 28 Oct 2016 07:51:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 29DEC124281 for <>; Fri, 28 Oct 2016 07:51:49 -0700 (PDT)
Received: by (Postfix, from userid 1001) id B22941E369; Fri, 28 Oct 2016 10:54:13 -0400 (EDT)
Date: Fri, 28 Oct 2016 10:54:13 -0400
From: Jeffrey Haas <>
To: "John G. Scudder" <>
Message-ID: <>
References: <> <> <20161027095404.GP37101@Vurt.local> <> <> <20161028110851.GA966@Vurt.local> <> <20161028122402.GB966@Vurt.local> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Cc: IETF IDR Working Group <>
Subject: Re: [Idr] Squatters (Was: BGP Attribute for Large communities (Attribute 30) was squatted on..)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Oct 2016 14:51:50 -0000

On Fri, Oct 28, 2016 at 10:40:21AM -0400, John G. Scudder wrote:
> 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.

A somewhat relevant analogy is that toxic spills tend to last in the
environment a rather long time, even with active cleanup work.  This has
been the thought behind most of my prior comments about avoiding the need to
burn attributes.

And while...

> 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.

I think we'll find that using the existing attribute range in such a way
simply will leave further toxic waste.  We're simply causing people
different sorts of pain as we move around the contamination.

For example, vendor A uses 30 for testing a feature and it escapes into the
wild.  It runs into the existing issue.

The issue is really more to do with development and testing practices than
code points in particular.  Code point hygeine simply helps mitigate issues
in those practices.

-- Jeff