Re: [Idr] Draft IDR charter text

Christopher Morrow <morrowc.lists@gmail.com> Tue, 27 August 2019 20:53 UTC

Return-Path: <christopher.morrow@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 AD25C120130 for <idr@ietfa.amsl.com>; Tue, 27 Aug 2019 13:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 kwKrvY97k5ls for <idr@ietfa.amsl.com>; Tue, 27 Aug 2019 13:53:15 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 4C744120113 for <idr@ietf.org>; Tue, 27 Aug 2019 13:53:15 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id a13so500653qtj.1 for <idr@ietf.org>; Tue, 27 Aug 2019 13:53:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UkgZC5Z2ueQGYu5pB169EgkM3D29SLA5Zhedg/ihlZo=; b=nndAY3N9tBFyLD1ejrzQH41OBSPCAoKC0slUE6FJWLvwcfhHYlyZy4wppfSD4qsFNR EOmNfFmcYoTVAjvtz+SrE7dfEOtnO+5MWW2mQnWy4bayk1EiKUDj8rpxK+qhEqR3Pb6g 6wq3BXRio/1uP9INozRPSjJSerdg0YhBgS3IuaDBp6cnNwu1OrRbnbBc22+APcSm5o6p R4xBS7GcjfsFw/6P6EGKf3+xiCipk5zTvLKX1XA3b9C87wGb5Bc8P9YYOmj0dkxqKY5R wxwFLLMiC5drn4FDOjYbcW7f+ukx5neoV0JfuQtIvYGnpnXV2cAmZFtdbjDh5nZNtzKl T21w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UkgZC5Z2ueQGYu5pB169EgkM3D29SLA5Zhedg/ihlZo=; b=fmVXesIWWz29bEk2+hdRwMMGe2doA8NTIqZGcPlZjECugdxzkyxk0Wa2bw+vq2zYRz zr4nbIpBiFGk85ubH1djbQPuowSc5kI79+BFuzGOU55rJW/WDlJSQitPg2LBHYEho+Va vRhWJp8sNYx0/XLzuNhuQkunBR6LhyfERsFGmx165ZeexjydzHlb0g/O1RXiuxnOYjHX ApbqBfOyTEQfJvaNfM/QC3mqaKjVI+oUpTDRL/qiTDCF24fENN4IRDACezuhKr/hZ7VW TDpDhQRnGnUeTE9YfeLuiAxI1u0/Jchv+4SVS0NImSCZKREEsNYuwdIAfwQeUMxoXrTM bxsg==
X-Gm-Message-State: APjAAAXpED2Mapwub7KlGDPtuc20iXrcn99VuEmzkvKLtVXTHSIMqrhd 6rdDtWRtva8Onv/3V/IiKkY5VsFccnwu7JhmcUY=
X-Google-Smtp-Source: APXvYqzK8EJ//rLQK5OMsRgbRuTPErvi9eRG2+iolnUdz/b8m5HKILv8ij0VTIJHkv9C0dZIH5scbi/IBKg8DTYG0Go=
X-Received: by 2002:ac8:7b9c:: with SMTP id p28mr865634qtu.185.1566939194016; Tue, 27 Aug 2019 13:53:14 -0700 (PDT)
MIME-Version: 1.0
References: <9CBFDB82-5965-4D76-A85F-3A8F5C89357F@juniper.net> <833860C2-22F9-4A40-93A4-2513950774D2@juniper.net>
In-Reply-To: <833860C2-22F9-4A40-93A4-2513950774D2@juniper.net>
From: Christopher Morrow <morrowc.lists@gmail.com>
Date: Tue, 27 Aug 2019 16:53:02 -0400
Message-ID: <CAL9jLabn9FR+Fx1y8sK3JfMj+kqBOwHVvKy9+PU5Zk9mTj9puw@mail.gmail.com>
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>
Cc: idr wg <idr@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/oUoywfwFgjxzOQuaTGP6KxmwV9A>
Subject: Re: [Idr] Draft IDR charter text
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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, 27 Aug 2019 20:53:18 -0000

On Thu, Jul 25, 2019 at 11:29 PM John Scudder
<jgs=40juniper.net@dmarc.ietf.org> wrote:
>
> I received a unicast suggestion to specifically cite YANG modules, as in:
>
> OLD:
> The main objective of the working group is to support the use of BGP-4 by IP version 4 and IP version 6 networks. The working group will continue to work on improving the robustness, scalability, deployability, manageability, and security of BGP.
>
> NEW:
> The main objective of the working group is to support the use of BGP-4 by IP version 4 and IP version 6 networks. The working group will continue to work on improving the robustness, scalability, deployability, manageability (including specification of YANG modules), and security of BGP.
>

bah! yang, the new json/xml/csv... fine!

> Seems fine to me.

seems ok  to me too :)

>
> —John
>
> > On Jul 25, 2019, at 6:44 PM, John Scudder <jgs=40juniper.net@dmarc.ietf.org> wrote:
> >
> > Hi All,
> >
> > Here’s a draft of new charter text we came up with after consulting with the Routing ADs [*]:
> >
> > —
> > The Inter-Domain Routing Working Group is chartered to standardize, develop, and support the Border Gateway Protocol Version 4 (BGP-4)  [RFC 4271] capable of supporting policy based routing for TCP/IP Internets.
> >
> > The main objective of the working group is to support the use of BGP-4 by IP version 4 and IP version 6 networks. The working group will continue to work on improving the robustness, scalability, deployability, manageability, and security of BGP.
> >
> > BGP is an enabling protocol or subject of interest for a number of other working groups, including BESS, LSVR, LSR, SIDROPS, and GROW. Those (and other) groups may develop standards that make use of BGP. IDR asks that when another working group proposes changes and additions to BGP, that IDR should be informed. In particular, if another working group requests allocation of a code point from a BGP protocol registry, IDR should be consulted as soon as possible. The Border Gateway Protocol (BGP) Parameters group is the most notable example of such registries. In general, protocol changes should be progressed through IDR, whereas uses of extensible mechanisms need only notification to IDR.
> >
> > IDR desires to review extensions made to BGP in other working groups at least at WG document adoption and during working group last calls. The IDR working group will also provide advice and guidance on BGP to other working groups as requested.
> >
> > IDR welcomes advice and requirements from other working groups, particularly from GROW which is chartered for this purpose.
> > —
> >
> > The main changes vs. the prior text are,
> >
> > 1. Talks in more detail about what we expect from our peer WGs and what they can expect from us.
> > 2. Removes the “work items” section. This was largely redundant with the milestones and it just muddies the waters.
> >
> > Essentially the intent is to say “we do BGP” but a little more rigorously (or at least verbosely). :-)
> >
> > If we adopt this charter, or one like it, the next step would be to do a pass of updating our milestones, fairly extensively. Many of the suggestions that have been made so far (thank you!) would fall into that discussion.
> >
> > Regards,
> >
> > —John
> >
> > [*] Does not imply the Routing ADs have approved this text, they have not provided an opinion on it.
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr