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

Peter Hessler <phessler@theapt.org> Tue, 01 November 2016 14:26 UTC

Return-Path: <phessler@theapt.org>
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 E02E61296FB for <idr@ietfa.amsl.com>; Tue, 1 Nov 2016 07:26:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level:
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
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 ldtQCxEsDmUO for <idr@ietfa.amsl.com>; Tue, 1 Nov 2016 07:26:01 -0700 (PDT)
Received: from gir.theapt.org (gir.theapt.org [IPv6:2001:470:1f0b:8b2::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13AB5129722 for <idr@ietf.org>; Tue, 1 Nov 2016 07:26:01 -0700 (PDT)
Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id 685BB78985; Tue, 1 Nov 2016 15:25:59 +0100 (CET)
Date: Tue, 1 Nov 2016 15:25:51 +0100
From: Peter Hessler <phessler@theapt.org>
To: Robert Raszuk <robert@raszuk.net>
Message-ID: <20161101142537.GA24817@gir.theapt.org>
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> <CA+b+ERmfW0vVXgqrxqNajZhJS3aDXD6kG7xzMFjsuk4bBNLvnQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+b+ERmfW0vVXgqrxqNajZhJS3aDXD6kG7xzMFjsuk4bBNLvnQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/PdbnsOXHXC5ZcOhUim4BIOq10_E>
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:26:03 -0000

On 2016 Nov 01 (Tue) at 15:17:30 +0100 (+0100), Robert Raszuk wrote:
:> 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.
:

Early development in support of an ID is desirable, and in this WG
pretty much required.  For that, a lab image and (in the open source
case) patches floating around is good.  Pushing these to innocent
customers is not.

Squatting on random (e.g. Huawei with code 30) codepoints *should* be
punished, imho.

Regardless if we consider it to be punishment or not-punishment, it
should be documented that these code points are tainted, and cannot be
considered pure and clean for future assignments.

I don't care either way if 129 is used for a future Early Assignment of
Wide Communities.  But I do care if 31 is assigned to someone that has
to fight the existing ecosystem.



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


-- 
Command, n.:
	Statement presented by a human and accepted by a computer in
such a manner as to make the human feel as if he is in control.