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

Robert Raszuk <robert@raszuk.net> Tue, 01 November 2016 14:17 UTC

Return-Path: <rraszuk@gmail.com>
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 415E61296FB for <idr@ietfa.amsl.com>; Tue, 1 Nov 2016 07:17:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8myFQbopUC5G for <idr@ietfa.amsl.com>; Tue, 1 Nov 2016 07:17:33 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 69F2F1296B5 for <idr@ietf.org>; Tue, 1 Nov 2016 07:17:33 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id a197so80722002wmd.0 for <idr@ietf.org>; Tue, 01 Nov 2016 07:17:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1ASam+YuYAllVSNHzmyK8x15zXlBPf62qQtfoFxuQEE=; b=GeTwoh8ohGVa88+kijCFVl/W5sNv5evOJkJfVLMNwn2VYi6Bf5vi9l0j3bq9UYeHsB Ha6EHsMKuRRFnG7Ezy63MgDzxe6IPyo3z9W/S8SJmQoBsxyIYz0/Wm1fgWsd8R3Z8oG/ mavAYgVsq3Tu5nReh22jhJ5vkmVAttwl23eMIVTmmvAgA6cHe8KdNdCC7+WZu/Dfyoeb QTeLG5cG0h5FDu+Fpig+5Z5pViCBvJaodHzP6ahX/RqjFBKW2JQaji6EsWEYExz0dFDM BnQD8baUYvKHi1j7rw/cg1XSUoTH+LdLT/feSpky7s3NPIEH1OcRlFkl+/Nk7wP9c+Kh UvtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1ASam+YuYAllVSNHzmyK8x15zXlBPf62qQtfoFxuQEE=; b=ll25l5VsVZpM4oA54u2EIX1clmeMbOrwOWuMFQFZreoPHQp9wG1mimF5qnUFlSyx9W /6HQByR5GjetsSHQKCI7JUUelBvZSwLVy8Sqvksvk94usd6DFnynjrNh4V1y1vWvebe4 +GG5FW8mt2u+v4UB9WYVP+b2ZhGdCkJAF5lFcXBwGn3tX04HqusbHkBZptmo+qwdaXoe +u5JQe1KQNLFgFn7d2HxuVh9BqBOe3kHS6W58DOdz/7OkVcKesdl7riQpuSFQrEU3vOd aiCqlvs8EEn9R9FrKcY4voYFplf0YSTEz/d4HV8ytuag4eOlMyUO3kk4wOMprPbVWQY8 uyBQ==
X-Gm-Message-State: ABUngvf+/WiKzF7hCUh90mAGr2lJ2smVwni3iNO6BALzXnGckEZw9PqDZXX/yx0W3dbHr2OBgLVl6gXy+0zo3A==
X-Received: by 10.28.163.196 with SMTP id m187mr1699284wme.73.1478009850912; Tue, 01 Nov 2016 07:17:30 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Tue, 1 Nov 2016 07:17:30 -0700 (PDT)
In-Reply-To: <20161101141229.GK1589@hanna.meerval.net>
References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <CA+b+ERnh8MMDgCoviLDRvOxbOky=8pBtHC8Z-WCQr6xFF_ZzGQ@mail.gmail.com> <20161101141229.GK1589@hanna.meerval.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 1 Nov 2016 15:17:30 +0100
X-Google-Sender-Auth: qvkaFh0Tw4FSqJthi4kgN8DklJ8
Message-ID: <CA+b+ERmfW0vVXgqrxqNajZhJS3aDXD6kG7xzMFjsuk4bBNLvnQ@mail.gmail.com>
To: Job Snijders <job@ntt.net>
Content-Type: multipart/alternative; boundary=001a114cd9a22363e105403dfcdb
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/wdg0DxJW9piALeoPJuPqSjm8MrA>
Cc: IETF IDR Working Group <idr@ietf.org>
Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129
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: Tue, 01 Nov 2016 14:17:35 -0000

> An implementor should not be rewarded with the possibility
> of laziness after they squat on a codepoint.

+

> I argue that we cannot tolerate:

Ahh got it.

So the point of the document is *punishment* for early attempts to
implement anything not to technically address the problem at hand. Thx for
clarification ...

Cheers,
R.


On Tue, Nov 1, 2016 at 3:12 PM, Job Snijders <job@ntt.net> wrote:

> On Tue, Nov 01, 2016 at 03:02:37PM +0100, Robert Raszuk wrote:
> > Have you consider marking those codepoints as "RESERVED" rather then
> > "DEPRECIATED".
>
> "DEPRECIATED" is an IANA attribute state I am not familiar with, I
> assume you mean "deprecated"? :)
>
> > Reason being that if any of the applications they have been squatted
> > on behalf of want to use them - it would be pretty easy to allocate
> > them.
> >
> > The other alternative would be to allocate them to those applications
> > now (for which the drafts exist) as IANA early allocations. If you
> > depreciate them now and we know that as example Contrail Multicast is
> > important either your draft will need to quickly be moved to historic
> > or yet another types will need to be allocated again.
>
> That is not how the process works. An implementor should not be rewarded
> with the possibility of laziness after they squat on a codepoint.
> "Laziness" being that they don't have to renumber, and that they didnt
> have to go through the normal process to obtain the codepoint.
>
> I argue that we cannot tolerate: "I'll just take this one, IANA will
> give it to me anyway later on if the product becomes popular"
>
> Also, the 'deprecate' draft (if published) would be "updated", not moved
> to historic. Only when all six proposed squatted points are returned to
> the "unassigned" pool the document can be declared historic.
>
> > In any of the above Large Communities will get virgin BGP attribute
> > type which I believe is the main point here.
>
> No, the main point is to prevent another deployment issue like Large BGP
> Communities suffered. Large BGP Communities has been resolved now (after
> considerable effort I might add).
>
> This document protects innocent bystanders from being assigned
> undeployable tainted codepoints.
>
> Kind regards,
>
> Job
>