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

Robert Raszuk <robert@raszuk.net> Tue, 01 November 2016 14:30 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 A67611294C1 for <idr@ietfa.amsl.com>; Tue, 1 Nov 2016 07:30:49 -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 Ln5WnJROpEdu for <idr@ietfa.amsl.com>; Tue, 1 Nov 2016 07:30:47 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 C5C3F129565 for <idr@ietf.org>; Tue, 1 Nov 2016 07:30:46 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id a197so81442120wmd.0 for <idr@ietf.org>; Tue, 01 Nov 2016 07:30:46 -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=zs8zng9JBhG9M9uEG9D6FwcUWmUHyh/dH8sOUeKMsQQ=; b=MlvS6YGX/xhM9I6i2wR8PTosW/i3GgnAFo2G0JPs/EmBHpg2pTEqnH//T1a4IDBrnN PClf3Qt0Q7hsYglgt1aRzF36bP1VGt7uwOE0mCWjQj1MOpjWfwqW7wxNT/F7GCXSq1MM sCDBCExSxx+mLypO6mpPCjM69sNFoZrmzPXMBMDscqUfPd2vdMWX8X3wY3sfiGxLk1cq hEmuO4UxpAXKF1blffJCgoP7SLLxghkGnBTeu9KuDApgVqe765BFtksjuri0giJ8GIWW sxJDRtMM9ZshnID8Ki8XYjGOJsU13NLzs86tcxrFvK+JYD8inQT0vRWrL2vBBjBQAmYo DOrA==
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=zs8zng9JBhG9M9uEG9D6FwcUWmUHyh/dH8sOUeKMsQQ=; b=DoqD6p/1yH5fOnOPwp2r+rfj5KVwQXQ8F9NWj/BZxMaSdRMY+XIBn98BAQKvvxCScP 0+7ffmD6kn7vzxu5OY3s4eAjqdRHDCp32ftWV/RfpDOnQot0pro5ark8GxD9swIkL1h3 PJzqBXsQgz1mThJE1LkG7xP3lug+I79+Yjngu2De9BgYgGdvmLhQJL+jl/AMsvFbye5e 9NSLZVIcXhJwSJPO4VKC7IbYP+0nPaQK1GdlHZ1qSs/YKV1TwvsHrw3BWKrDEFeeB3vr uSNHHCnWdlwO97vsWiCygrYaTtSoDpReQO+3qFeenDrnDCPYDGVmFIwhjoj0qhNmb/Lf NIWQ==
X-Gm-Message-State: ABUngvfqSDXRYEaKMBraG7e5sLH4GwBhsXHgvq6z3DVCC3bxOD9ToTuBlLPTl9/kMQP7Gr2tu5EYFNYDUV+qCA==
X-Received: by 10.28.46.15 with SMTP id u15mr1931845wmu.61.1478010645262; Tue, 01 Nov 2016 07:30:45 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Tue, 1 Nov 2016 07:30:43 -0700 (PDT)
In-Reply-To: <2393790D-F279-41ED-B5B2-E427C60B4926@juniper.net>
References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <CA+b+ERnh8MMDgCoviLDRvOxbOky=8pBtHC8Z-WCQr6xFF_ZzGQ@mail.gmail.com> <2393790D-F279-41ED-B5B2-E427C60B4926@juniper.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 1 Nov 2016 15:30:43 +0100
X-Google-Sender-Auth: d0kPhzAIwxusFZGCDyrV03wNDuA
Message-ID: <CA+b+ERm8fOYrYb2tYVMZUsNyP5jdXi7aNiJ0TaqWPq8dB039hQ@mail.gmail.com>
To: "John G. Scudder" <jgs@juniper.net>
Content-Type: multipart/alternative; boundary=001a1142532c7c385a05403e2b7f
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/C93dutahpz1JE2-1dIkiv5iULpM>
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:30:50 -0000

Hi John,

>From IDR WG standpoint could you state clearly the process for Early
Allocation of Attribute Types, Message Types or AFI/SAFIs codepoints ?

Does the process differ between IETF WGs ? Say if BESS will try to do also
early allocation for given BGP Attribute Type ?

I think this is the key here and root of the problem.

If we require interoperable implementations for any draft to proceed WG
should enable authors to create those implementations in the first place.

Thx a lot,
Robert.


On Tue, Nov 1, 2016 at 3:23 PM, John G. Scudder <jgs@juniper.net> wrote:

> AFAICT the function of the draft is simply to kick the IANA code point
> state to "deprecated". It doesn't anchor it there for all time. Presumably
> a later request can move the state to assigned or whatever, as we've
> previously discussed. I don't think any update to the current "deprecate"
> document would be needed to achieve this (I guess maybe the later document
> might list this one in its "updates" header).
>
> I'll confirm this understanding with IESG and IANA before the end of the
> WG adoption call. (Unless someone can point me to chapter-and-verse of a
> reference that explains the process clearly enough, unfortunately I have
> not found such.)
>
> Thanks,
>
> --John
>
> On Nov 1, 2016, at 10:02 AM, Robert Raszuk <robert@raszuk.net> wrote:
>
> Hi Job,
>
> Have you consider marking those codepoints as "RESERVED" rather then
> "DEPRECIATED".
>
> 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.
>
> In any of the above Large Communities will get virgin BGP attribute type
> which I believe is the main point here.
>
> Cheers,
> R.
>
>
> On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders <job@instituut.net> wrote:
>
>> Dear working group,
>>
>> To prevent having multiple drafts in quick succession covering the same
>> style of issue - I'd like your feedback on the following:
>>
>> I believe that bgp path attribute 241, 242, 243 should also be added to
>> this draft for the same reasons as 30, 31 and 129 are listed.
>>
>> OLD:
>>     This document requests IANA to deprecate the following BGP Path
>>     attributes: 30, 31, and 129.
>>
>> NEW:
>>     This document requests IANA to deprecate the following BGP Path
>>     attributes: 30, 31, 129, 241, 242, and 243.
>>
>> Does anyone object? If so, why?
>>
>> Unilaterally changing the document while in its mid-flight through the
>> working group adoption process might be considered bad form, hence my
>> request for feedback on the 241,242,243 topic.
>>
>> Please note - the deprecation of an attribute can be undone if proper
>> process is followed. The priority here is to prevent IANA from assigning
>> tainted codepoints to innocent bystanders, thus a deprecation document
>> needs to exist. In time the working group has the power to undeprecate
>> them for specific purposes.
>>
>> Kind regards,
>>
>> Job
>>
>> On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote:
>> > Hi Everyone,
>> >
>> > The author has asked for the WG to adopt  draft-snijders-idr-deprecate-3
>> 0-31-129.
>> >
>> > If you support or oppose adoption please reply indicating so. Reasons
>> for your position are helpful, as volunteering to review, comment, and/or
>> shepherd. As an aside, I will note that I don't think the WG has the option
>> of doing nothing, so if you oppose adoption please address what you think
>> should be done instead.
>> >
>> > The adoption call will end November 13.
>> >
>> > Thanks,
>> >
>> > --John
>> >
>> > P.S.: https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-
>> 31-129-01
>> >
>> > Abstract
>> >
>> >    This document requests IANA to deprecate the following BGP path
>> >    attributes values: 30, 31 and 129.
>> >
>> >
>> > _______________________________________________
>> > Idr mailing list
>> > Idr@ietf.org
>> > https://www.ietf.org/mailman/listinfo/idr
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>
>
>