Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129
"Susan Hares" <shares@ndzh.com> Fri, 04 November 2016 15:14 UTC
Return-Path: <shares@ndzh.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 28B04129470 for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 08:14:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.945
X-Spam-Level:
X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no 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 F73PYEA3VMui for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 08:14:12 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 3C8D81288B8 for <idr@ietf.org>; Fri, 4 Nov 2016 08:14:12 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.175.1;
From: Susan Hares <shares@ndzh.com>
To: "'t.petch'" <ietfc@btconnect.com>, "'John G. Scudder'" <jgs@juniper.net>, 'Robert Raszuk' <robert@raszuk.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> <034a01d23639$fa2c78e0$ee856aa0$@ndzh.com> <050f01d2369c$e82e1d20$4001a8c0@gateway.2wire.net>
In-Reply-To: <050f01d2369c$e82e1d20$4001a8c0@gateway.2wire.net>
Date: Fri, 04 Nov 2016 11:11:46 -0400
Message-ID: <01d901d236ad$c315beb0$49413c10$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQG4XNVJbFLLu0eQmTL8gVJbAkCFVwDjdK5pAXaolZsCtVg7VQEQjTOTAOpitqKgxE0yAA==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/8FJGYDC35fBSapb-2fWyDhIpHZo>
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: Fri, 04 Nov 2016 15:14:14 -0000
Tom: <WG chair hat on> The IETF list discussion of RFC5226bis is the right place to make progress on this work. Alvaro Retana (the AD for IDR) has agreed to help push this along as well. Send Alvaro notes on your concerns. With a reference to RFC5226bis, then draft-snijders-idr-deprecate-30-31-129 will be able to "deprecate" the code points at this point. When the RFC5226bis comes out, Michelle Cotton (and all the great folks at IANA) will adjust the tables. <WG Chair hat off> <individual contributor hat on> As the IDR list has indicated, deprecate needs to be carefully defined. I appreciate you working on this topic on the IETF list. Otherwise, we'll have this conversation again with 2-3 years. </individual contributor hat off> Sue Hares -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Friday, November 4, 2016 9:11 AM To: Susan Hares; 'John G. Scudder'; 'Robert Raszuk' Cc: 'IETF IDR Working Group' Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129 ----- Original Message ----- From: "Susan Hares" <shares@ndzh.com> To: "'John G. Scudder'" <jgs@juniper.net>; "'Robert Raszuk'" <robert@raszuk.net> Cc: "'IETF IDR Working Group'" <idr@ietf.org> Sent: Friday, November 04, 2016 1:22 AM > John: > > My understanding with the IESG and IANA is that this is true. The best > reference is the BIS for RFC226bis below: > > https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-11 > > The RFC5226bis-11.txt got stalled due to the IESG wandering if the revision > is needed. Based on our experience, I think it is needed. Alvaro will kick > off this work, but the process of updating a "process" document should not > impede this document's process. We need to think outside the box. > > I suggest we complete this adoption of > draft-snijders-idr-deprecate-30-31-129 draft by 11/13/2016, and do a WG LC > on the draft directly following this process draft (11/14 to 11/28). This > should allow the draft-idr-large-communities to have the necessary registry > "glue" ready so the IESG publication of large communities can go quickly. Sue The reason I am being a bit 'snarky' on this adoption call is my concern that there may be differing views of what 'deprecate' means. For example, the SMI world gives it a different (and IMO unsuitable) meaning which some on this list will know. Even the 5226bis text might not be quite right. Robert did query whether or not 'deprecate' was suitable. If we take 5226bis as gospel, then 'deprecate' is probably the option to choose but I wish that there were more alternatives. I was about to post to the main IETF list and Terry Mandelson(as responssible AD) about 5226bis (again:-) but the list has erupted with a discussion about DMARC(again) so I will hold off and see what develops. Tom Petch > > > > Sue > > > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder > Sent: Tuesday, November 1, 2016 10:24 AM > To: Robert Raszuk > Cc: IETF IDR Working Group > Subject: Re: [Idr] Working group adoption call for > draft-snijders-idr-deprecate-30-31-129 > > > > 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-30-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 > > > > > > ------------------------------------------------------------------------ -------- > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >
- [Idr] Working group adoption call for draft-snijd… John G.Scudder
- Re: [Idr] Working group adoption call for draft-s… Brian Dickson
- Re: [Idr] Working group adoption call for draft-s… Acee Lindem (acee)
- Re: [Idr] Working group adoption call for draft-s… Julian Seifert
- Re: [Idr] Working group adoption call for draft-s… Jeff Tantsura
- Re: [Idr] Working group adoption call for draft-s… Hankins, Greg (Nokia - US)
- Re: [Idr] Working group adoption call for draft-s… Zhuangshunwan
- Re: [Idr] Working group adoption call for draft-s… Peter Hessler
- Re: [Idr] Working group adoption call for draft-s… David Freedman
- Re: [Idr] Working group adoption call for draft-s… Gert Doering
- Re: [Idr] Working group adoption call for draft-s… Nick Hilliard
- Re: [Idr] Working group adoption call for draft-s… Job Snijders
- Re: [Idr] Working group adoption call for draft-s… Robert Raszuk
- Re: [Idr] Working group adoption call for draft-s… Job Snijders
- Re: [Idr] Working group adoption call for draft-s… Robert Raszuk
- Re: [Idr] Working group adoption call for draft-s… John G. Scudder
- Re: [Idr] Working group adoption call for draft-s… Peter Hessler
- Re: [Idr] Working group adoption call for draft-s… Job Snijders
- Re: [Idr] Working group adoption call for draft-s… Robert Raszuk
- Re: [Idr] Working group adoption call for draft-s… Jeffrey Haas
- Re: [Idr] Working group adoption call for draft-s… Robert Raszuk
- Re: [Idr] Working group adoption call for draft-s… John G. Scudder
- Re: [Idr] Working group adoption call for draft-s… John G. Scudder
- Re: [Idr] Working group adoption call for draft-s… Job Snijders
- Re: [Idr] Working group adoption call for draft-s… Linda Dunbar
- Re: [Idr] Working group adoption call for draft-s… Robert Raszuk
- [Idr] Early allocations and other ways to avoid s… John G. Scudder
- Re: [Idr] Working group adoption call for draft-s… John G. Scudder
- Re: [Idr] Working group adoption call for draft-s… Robert Raszuk
- Re: [Idr] Working group adoption call for draft-s… John G. Scudder
- Re: [Idr] Working group adoption call for draft-s… Jeffrey Haas
- Re: [Idr] Working group adoption call for draft-s… heasley
- Re: [Idr] Working group adoption call for draft-s… Jeffrey Haas
- Re: [Idr] Early allocations and other ways to avo… Jakob Heitz (jheitz)
- Re: [Idr] Early allocations and other ways to avo… Keyur Patel
- Re: [Idr] Working group adoption call for draft-s… marco
- Re: [Idr] Early allocations and other ways to avo… Job Snijders
- Re: [Idr] Working group adoption call for draft-s… Jared Mauch
- Re: [Idr] Working group adoption call for draft-s… Jared Mauch
- Re: [Idr] Early allocations and other ways to avo… John G. Scudder
- Re: [Idr] Working group adoption call for draft-s… t.petch
- Re: [Idr] Working group adoption call for draft-s… Job Snijders
- Re: [Idr] Working group adoption call for draft-s… John G. Scudder
- Re: [Idr] Working group adoption call for draft-s… Jakob Heitz (jheitz)
- Re: [Idr] Working group adoption call for draft-s… Jared Mauch
- Re: [Idr] Working group adoption call for draft-s… t.petch
- Re: [Idr] Working group adoption call for draft-s… Gert Doering
- Re: [Idr] Working group adoption call for draft-s… Job Snijders
- Re: [Idr] Working group adoption call for draft-s… t.petch
- Re: [Idr] Working group adoption call for draft-s… Job Snijders
- Re: [Idr] Working group adoption call for draft-s… Dickinson, Ian
- Re: [Idr] Working group adoption call for draft-s… Job Snijders
- Re: [Idr] Working group adoption call for draft-s… heasley
- Re: [Idr] Working group adoption call for draft-s… t.petch
- Re: [Idr] Working group adoption call for draft-s… John Scudder
- Re: [Idr] Working group adoption call for draft-s… Susan Hares
- Re: [Idr] Working group adoption call for draft-s… Susan Hares
- Re: [Idr] Working group adoption call for draft-s… Susan Hares
- Re: [Idr] Working group adoption call for draft-s… t.petch
- Re: [Idr] Working group adoption call for draft-s… Job Snijders
- Re: [Idr] Working group adoption call for draft-s… Susan Hares
- Re: [Idr] Working group adoption call for draft-s… John G. Scudder