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

Job Snijders <job@instituut.net> Fri, 04 November 2016 13:40 UTC

Return-Path: <job@instituut.net>
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 BD695129521 for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 06:40:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.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 Uv56Myo1ALfZ for <idr@ietfa.amsl.com>; Fri, 4 Nov 2016 06:40:47 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 06B7A129418 for <idr@ietf.org>; Fri, 4 Nov 2016 06:40:45 -0700 (PDT)
Received: by mail-oi0-x22f.google.com with SMTP id 128so161975394oih.0 for <idr@ietf.org>; Fri, 04 Nov 2016 06:40:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cPn6EMtFAJ63ewCCdAxNsXpCWo8APC8dHBK16EE1OzQ=; b=m4xnZ6NYauUWJx1OPvfyo+VBxaKRgAcACSs7wpM7AsoKXvCSjw5VlasyeBOBycFqIm 4XFJ86DoaAvHmYZvW32xtePtiTLanrD55+2XWdghUiJpgHhoXAaeapOz7ojGZzyHvP4u RAV4tUcNXWkzBh08pMA3ZYyUuVbTR6DPREKELEIrYYj7Cm3UZFu4HWRkzdZu4rR3Kuf9 XBSTpr8sPTSu5XixBMKVnXXS25OvPQaJAszzpIz+78oiNA22yg6Bh03REI+2o5tAR2mY DDuK5vjRlJRyiJ7gEm5vBGwwpGi5JqyxX7mUPqRz9ZxmBkOxZk33TjEjNHevp6gGT7oL BIWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cPn6EMtFAJ63ewCCdAxNsXpCWo8APC8dHBK16EE1OzQ=; b=gEq0TjqMobrxOjQBjtnAF9JOW+5rT5PJVyIRiNnTM43x5QtC/FOADAkQtWzE3bSfaM cppr3wPoniqsc8pT4/02HafS96mxWCJDmvNd/Rm+RHz5oWn3t24miJasQYve4kVsFuDc tUNGSjfBKaYj6S9qS3M/RPHucV3qZ5YpSfYs9Xqt8jCDaZ1PWOLl/13L6qm9qKgoHBoo WWv+fenAGypf7H5POFSUOGg2mHpIC6RqzvPMRRBPZfFeTSCrFQ6qgM4VQSScVNfPQmoI 2gOXxGZU4RkO5NeJtaWkywWTEDf0EMCGUIpegXrPXBWTfO1mAYIygP0fc8rWtkWkm0t5 aG5A==
X-Gm-Message-State: ABUngvfsiuZzjD3lfuRBHonRwYFIEW7y/k/uvv9p9M7oedeEHSuC/tC8OIVNUfkm2Rq8zyTL7fgaulWjkO2jJA==
X-Received: by 10.202.8.205 with SMTP id 196mr13626753oii.13.1478266844563; Fri, 04 Nov 2016 06:40:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.144.163 with HTTP; Fri, 4 Nov 2016 06:40:43 -0700 (PDT)
X-Originating-IP: [188.206.66.42]
In-Reply-To: <050f01d2369c$e82e1d20$4001a8c0@gateway.2wire.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>
From: Job Snijders <job@instituut.net>
Date: Fri, 4 Nov 2016 14:40:43 +0100
Message-ID: <CACWOCC8gqhJmew=rzdE8h0R362mjNQH8jVSmXOouTvUb48io2w@mail.gmail.com>
To: "t.petch" <ietfc@btconnect.com>
Content-Type: multipart/alternative; boundary=94eb2c12f99c276e97054079d239
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/G2V27abuFQGEFc7PmHqVrxjPits>
Cc: Robert Raszuk <robert@raszuk.net>, Susan Hares <shares@ndzh.com>, 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 13:40:50 -0000

For clarity, do you still oppose the proposed -02 i shared earlier?

Job

On Friday, 4 November 2016, t.petch <ietfc@btconnect.com> wrote:

> ----- Original Message -----
> From: "Susan Hares" <shares@ndzh.com <javascript:;>>
> To: "'John G. Scudder'" <jgs@juniper.net <javascript:;>>; "'Robert
> Raszuk'"
> <robert@raszuk.net <javascript:;>>
> Cc: "'IETF IDR Working Group'" <idr@ietf.org <javascript:;>>
> 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 <javascript:;>] 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
> <javascript:;>> 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
> <javascript:;>>
> 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 <javascript:;>
> > > https://www.ietf.org/mailman/listinfo/idr
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org <javascript:;>
> > https://www.ietf.org/mailman/listinfo/idr
> >
> >
> >
> >
> >
> >
>
>
> ------------------------------------------------------------------------
> --------
>
>
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org <javascript:;>
> > https://www.ietf.org/mailman/listinfo/idr
> >
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org <javascript:;>
> https://www.ietf.org/mailman/listinfo/idr
>