Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129

Job Snijders <> Wed, 02 November 2016 11:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 95E081294F5 for <>; Wed, 2 Nov 2016 04:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IMHuny9oDfTP for <>; Wed, 2 Nov 2016 04:27:57 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 837AB1294F3 for <>; Wed, 2 Nov 2016 04:27:57 -0700 (PDT)
Received: by with SMTP id p190so261815340wmp.1 for <>; Wed, 02 Nov 2016 04:27:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=4RMEfaYU9Ca1J7bYCcEkSXy6qK6CcQCJqeIKZ+m83Z8=; b=FKkvbRIjpTS3c1GCENnTHWlapn0y73QK6qDufL/vezP+hQ+gmLCZ2Y3S8R+qckPiP7 SWs1jkK4T67kwQbvYz919bUs/ikDGaA2eRdSRmksE23kRUHB1mnzIn7X8j7dcVksGkvF h6s/fdfiznFgoBRFIT7rCaA/fmXDG2KJc0yMfvNFNS3clKYVm7I1CMI0DXWz2p57mFCO thiKHWGIWczT6aKKwOQ5WrHOzeUHhfXPcIHD8P7tRiH+jR3EyIu1REQ0s2BFBK3a2+3P xJkmXOn42eGTPlxQtLYGVKJrS2qXG/KCXSoqBMbK2Crq9EOhUo5iDXLdHEZ3JrSoad1U 58/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=4RMEfaYU9Ca1J7bYCcEkSXy6qK6CcQCJqeIKZ+m83Z8=; b=KW9EDAcM34r3eqsiDq+HZ2PUa9iRgnRT8c6wq9HLFzHIqOXptn7E3SpFKyqmJlZ1XR HJ9ZfPt6FOuRDHHujcGeyktsQ6FytioGeqHSwTDSY+HpK8vdLw4oD/fgPZFXp0MhZHef fw/Cirq88j8bTzT3YLHsEtlF0BxBxH4R/JfoTnmw+zWSxRXAvcgDk+TV43MJDlBZfdvq d9us490n41G27gkY6IyvB4XcZxiTWFdvONZdJzZ0kvZS/bv+SyLIaKD/2TcYR2KAPYM+ WbfNaQH+l/GaSWOw9RrkYXWWZrUYCu6QT+QqDA8OLFXj6GHjrp/EmYDjVw5vtoXs8Q3b y6ow==
X-Gm-Message-State: ABUngvc/6j4kX3ZfggP8GQqvls4qTyw5IHfcFWeqedZPtPRYe5QD1VNtLZnDGJ25cCK2lQ==
X-Received: by with SMTP id w64mr2950764wmf.13.1478086075932; Wed, 02 Nov 2016 04:27:55 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:6918:2511:d26:7937]) by with ESMTPSA id 18sm2626992wmp.24.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 04:27:55 -0700 (PDT)
Date: Wed, 2 Nov 2016 12:27:54 +0100
From: Job Snijders <>
To: Gert Doering <>
Message-ID: <>
References: <> <> <> <> <01c101d23467$9c8b0cc0$> <> <025801d234f4$78232740$> <20161102103746.GT79185@Space.Net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161102103746.GT79185@Space.Net>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <>
Cc: IETF IDR Working Group <>
Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129
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: Wed, 02 Nov 2016 11:27:59 -0000

On Wed, Nov 02, 2016 at 11:37:46AM +0100, Gert Doering wrote:
> On Wed, Nov 02, 2016 at 10:32:45AM +0000, t.petch wrote:
> > So we have a definition that has been in use for three years, in the
> > context of IANA, which is, to quote,
> > "  Specific entries in a registry can be marked as "obsolete" (no longer
> >    in use) or "deprecated" (use is not recommended). "
> > 
> > I believe that this I-D cannot be understood without reference to that
> > definition, hence my opposition to an I-D that leaves the interpretation
> > of 'deprecated' up to the reader (who may assume that the SMI definition
> > is appropriate).
> So what you're saying is "add a link to that reference, and all is good"?
> Why is that interfering with draft *adoption*?  Sounds more like wordsmithing
> for the then-WG document before WGLC to me, not a fundamental reason to not
> accept the draft.

No, it appears that Tom is saying that IDR cannot deprecate codepoints
until IETF/IANA have developed a deeper understanding of the word

Tom, can you confirm that in retrospect you would've opposed too, and that it is not clear to you
what that RFC accomplishes?

Tom, do you have an alternative strategy to prevent value 30 from being
assigned as path attribute value to the next early allocation, other
then adopting and publishing draft-snijders-idr-deprecate-30-31-129?

Kind regards,