Re: [Idr] Changing the allocation policy for the BGP-LS registries

Donald Eastlake <d3e3e3@gmail.com> Fri, 26 July 2019 14:01 UTC

Return-Path: <d3e3e3@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 A291512003E for <idr@ietfa.amsl.com>; Fri, 26 Jul 2019 07:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.747
X-Spam-Level:
X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 RbJkwhVo8_TV for <idr@ietfa.amsl.com>; Fri, 26 Jul 2019 07:01:41 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 1FAE5120024 for <idr@ietf.org>; Fri, 26 Jul 2019 07:01:41 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id s7so104855577iob.11 for <idr@ietf.org>; Fri, 26 Jul 2019 07:01:41 -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; bh=+UxOUl9pmHP1jQI1YQqNxQGVpxLGOwddZDFmJl8xWMs=; b=mcWZ/IoqMhZT1YBeqKeja70LLCwJAKWvLRAXFYecGYniwBLUKhbBrnu0Tb3qrC2TNF IPicr6lpRd0LToBqtOl2MucMs22AYNf+xdm5pcojOyis/kkPlJ39VdZpCNGVgb0ZQxEU oE8aK07p4BTA7kvS5D/vvCPp/5H85zoXGuQgU9LN2VrzcQfOhRS3RkXuVYSRLP8wNpcM gjGjGVClejn5Z8+CjHPlko8Gc6ELfynoao7TpWyWn4XCkXrlnRYxcp43tTV9nanxLh57 5NwQwcYwxI18iYLO/1kUA79xxguUdUafCH96RhgDK0tTHMd14EpFXIhe4grgKhoC4TcO fJjA==
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; bh=+UxOUl9pmHP1jQI1YQqNxQGVpxLGOwddZDFmJl8xWMs=; b=jYD02+W5SV3gYm3igPt9tb9A2MCQPkM6trvr6QTjUpgsRmSX+WXWfNiv7p9dLtOpou D+Z3FEkxy+1DhxzNtoEMSGM3wnM2iRY4nMqv0muHJGojjdbgmUq46biNk+JI/RERm68d w0iCqKMt9r87cnm8GyRFs3J6SUplTBRd0PmhYcQUsTuqTWdoqda6CG4BOrit8/C7Z2ME r6yEwC6aUVZ8wW8O40+HG5nUvm79+LG5n7Ybv7j50OvDfXiov0VCgBmfA8L/oxS6uHV5 Gy4MvzqcPgEDjEnSvuGTjvSgvbvtsH9eav34KsRYXIrzSkM+fQYymkKxHtcFBp9fzaam 8iVw==
X-Gm-Message-State: APjAAAXlm5olmkNPYvQQGdCu9MxLr2qAWCesMfekP0j6Bj1l3bpslD6X GmetKP0SPuaRm3knCi69pf4CaO+xZZ8fEIHvuJE=
X-Google-Smtp-Source: APXvYqzvCyPOlmwY2p+H85IsGssJJV0ySZH24Jf5m8SO5vWe9jx71NwWIqECGqYK+dA1mIP0L4D2zAvqgFJNw4ZXdok=
X-Received: by 2002:a5e:c744:: with SMTP id g4mr84946157iop.187.1564149700172; Fri, 26 Jul 2019 07:01:40 -0700 (PDT)
MIME-Version: 1.0
References: <0ab001d543a8$a2fbdf00$e8f39d00$@olddog.co.uk> <CAF4+nEHS5b_frvGnL_HRoGrxwyLyf_KD46hdodiRaeD-2_kyww@mail.gmail.com>
In-Reply-To: <CAF4+nEHS5b_frvGnL_HRoGrxwyLyf_KD46hdodiRaeD-2_kyww@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Fri, 26 Jul 2019 10:01:28 -0400
Message-ID: <CAF4+nEHeLqfua3=0kuPRr=yJqSmWyB=RRf9DB_k=cKZJi5JCCQ@mail.gmail.com>
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000412071058e95fb57"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/E_GQCuFP-gJ8NmAcfWkw_vNdtrg>
Subject: Re: [Idr] Changing the allocation policy for the BGP-LS registries
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: Fri, 26 Jul 2019 14:01:44 -0000

Hi Adrian,

Sorry to respond to my own mail but looking into this further, in
particular to the IANA Considerations of RFC 3748 and 3575 which are
referenced as example by RFC 8126, the formula for getting around the
problem I mentioned is to reference the WG mailing list, rather than the WG
itself, and to provide that a successor mailing list can be designated by
the AD. So in this case, the formula would be:

The Designated expert will post a request to the IDR WG mailing list
(or a successor designated by the Area Director) for comment and
review, including an Internet-Draft.


Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e3e3@gmail.com


On Fri, Jul 26, 2019 at 9:32 AM Donald Eastlake <d3e3e3@gmail.com> wrote:

> Hi Adrian,
>
> When a registry is Expert Review, the normal flow is that requests are
> sent to IANA who selects an Expert from the pool of Expert. The Expert
> evaluates the request and returns an approval/disapproval. IANA then
> assigned the code point(s) or not. The general escape mechanism for denial
> of service attacks or other abuse is for IANA to go to the IESG. See the
> last paragraph of Section 3.3 of RFC 8126:
>
>    IANA always has the discretion to ask the IESG for advice or
>    intervention when they feel it is needed, such as in cases where
>    policies or procedures are unclear to them, where they encounter
>    issues or questions they are unable to resolve, or where registration
>    requests or patterns of requests appear to be unusual or abusive.
>
>
> Generally speaking, the IESG is considered to be a permanent body while,
> notwithstanding the apparent immortality of the IDR WG, Working Groups are
> considered to be ephemeral. Thus the provision in this draft naming the IDR
> Working Group seems problematic to me. The way this is handled for DNS,
> where community discussion is desired of requests for RRTYPE assignments,
> is to name a specific mailing list that the request must be posted to.
> Mailing lists can be immortal. (See Sections 3.1 and Appendix A of RFC
> 6895.)
>
> So, I think the draft is a good idea but needs some tweaking based on the
> above.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  1424 Pro Shop Court, Davenport, FL 33896 USA
>  d3e3e3@gmail.com
>
> On Fri, Jul 26, 2019 at 7:53 AM Adrian Farrel <adrian@olddog.co.uk> wrote:
> >
> > Hi team IDR,
> >
> > I'm one of the two Designated Experts for these registries.
> >
> > Chatting with the chairs yesterday there was a suggestion that we might
> > change (relax) the allocation policy for the registries.
> >
> > This draft is a straw man to do that.
> >
> > Discuss!
> >
> > Best,
> > Adrian
> > --
> > Read some fairy stories for adults of all ages
> > .. Tales from the Wood
> > .. More Tales from the Wood
> > .. Tales from Beyond the Wood
> > .. Tales from the Castle
> > Get them on line https://www.feedaread.com/profiles/8604/
> > Or buy a signed copy from me by post
> > *** Stop me in the corridor at IETF-105 to get a copy ***
> >
> >
> >
> > -----Original Message-----
> > From: I-D-Announce <i-d-announce-bounces@ietf.org> On Behalf Of
> > internet-drafts@ietf.org
> > Sent: 26 July 2019 11:47
> > To: i-d-announce@ietf.org
> > Subject: I-D Action: draft-farrel-idr-bgp-ls-registry-00.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> >         Title           : Updates to the Allocation Policy for the Border
> > Gateway Protocol - Link State (BGP-LS) Parameters Registries
> >         Author          : Adrian Farrel
> >         Filename        : draft-farrel-idr-bgp-ls-registry-00.txt
> >         Pages           : 4
> >         Date            : 2019-07-26
> >
> > Abstract:
> >    RFC 7752 defines Border Gateway Protocol - Link State (BGP-LS).  IANA
> >    created a registry consistent with that document called the "Border
> >    Gateway Protocol - Link State (BGP-LS) Parameters Registry" with a
> >    number of sub-registries.  The allocation policy applied by IANA for
> >    those policies is "Specification Required" as defined in RFC 8126.
> >
> >    This document updates RFC 7752 by changing the allocation policy for
> >    all of the registries to "Expert Review."
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-farrel-idr-bgp-ls-registry/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-farrel-idr-bgp-ls-registry-00
> >
> https://datatracker.ietf.org/doc/html/draft-farrel-idr-bgp-ls-registry-00
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > I-D-Announce@ietf.org
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
>