Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt

Robert Raszuk <robert@raszuk.net> Thu, 23 March 2017 18:35 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 6C4921294CD for <idr@ietfa.amsl.com>; Thu, 23 Mar 2017 11:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.39
X-Spam-Level:
X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 TEJEulcLBrj1 for <idr@ietfa.amsl.com>; Thu, 23 Mar 2017 11:35:21 -0700 (PDT)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 0EBFF129BB7 for <idr@ietf.org>; Thu, 23 Mar 2017 11:35:21 -0700 (PDT)
Received: by mail-it0-x235.google.com with SMTP id w124so45453783itb.1 for <idr@ietf.org>; Thu, 23 Mar 2017 11:35:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Lo97TWmo1A6zli5g3aKSgbDLmx9xqvJeCLc8sSSMh2I=; b=T0AHc/xF9Ql2Uqrnb7DwkqPSrDCGvA5Dihxhtf2i+WqZ3jn6qmzo/6vu39fdx3GSw9 Ckou+iDR5HZ5SidqNEt9LUqUNOAPow1nReETVWm/lvezSHzLjQsQMYh2g+Pg2EEQ/9hv WRYeKpLaKNjojj+Byp9PoXH4EvMmwfBYi+X/GRgO207s4JLrN/VyXpt9JfHHsQDmOVpe OWgnLDBW6pL9ZxTWb9LgfgWjde9+bpgy7KuEphlrIBanQGtG2f4gN0/7ZbJVO8etaMAu FdnqHeJ0jI5a35tOyZxXZIMzOnCrf0oqJxyVG4NedIoAMIFtEV+RH0dwrchLcw4ncDa0 kblQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Lo97TWmo1A6zli5g3aKSgbDLmx9xqvJeCLc8sSSMh2I=; b=GihSMvB/MP2anO+ye6wUYwv8NFIT7NMhyTkiZ/nV022HINLNzX2FlOJ3KtEneGJF0f bNO6FB0hykfupjSnk13igUH2kgzhvZEwle6FJZHPKw5F5kvaG90lyEAi3SKC0zqOt5ri OJFoKe6FbhfTiTP5BZSQDOEr9mJo2mJ6QQeBzOnQHY5DJIC/N5LAmLKXu7IoyIPff+6q FgqT5Ajlu39ntBYlXdhl6R2inWa3pnGrUrYjHBRv6U+WLgjLGRK5OEzCWMD1tz9P+2i8 aYY4RheNWgUMllVyTXpG2ikCnC+epNm/FO8CqlU2nER1+TWyJjZbODLcGmfs1kaIbrSS BM8w==
X-Gm-Message-State: AFeK/H16c9GVG+pkWL4IZXcSw4lvb+1VDWJCfnja0aidVnbTeiazeXXDYqQhzrd1XQZsNIyr7BDWwQob1TFBzA==
X-Received: by 10.36.238.202 with SMTP id b193mr4043966iti.39.1490294120350; Thu, 23 Mar 2017 11:35:20 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.90.71 with HTTP; Thu, 23 Mar 2017 11:35:19 -0700 (PDT)
In-Reply-To: <050901d2a3fd$734b3e10$59e1ba30$@ndzh.com>
References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <c369a60a-3ccc-bf7d-dd29-d289d7a6b67e@juniper.net> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> <E40AC551-E802-4662-A2F5-2E8EDB3C746F@juniper.net> <c8804d0b-39e0-bb56-464c-fe1d051f2d91@juniper.net> <050901d2a3fd$734b3e10$59e1ba30$@ndzh.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 23 Mar 2017 14:35:19 -0400
X-Google-Sender-Auth: IPk8K0SoeyXVKk5Gy1IEO3AzYvU
Message-ID: <CA+b+ERnbeA+1vuTh1Vyt+=g9ZhpoKzeb-fxHGQ5G20bDSeGR8w@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Cc: Eric C Rosen <erosen@juniper.net>, "John G. Scudder" <jgs@juniper.net>, idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c03783ca7a109054b6a235b
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/XcMO2t15BZHXpc39wfLPEQZRGD4>
Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 23 Mar 2017 18:35:24 -0000

Sue,

Automated checks on drafts means "*no self documented allocation*".

Folks who are implementing things even will continue to do "s*elf
undocumented allocations" *or are going to be permitted to get next code
point and proceed with implementation without any politics and reviews.

John said that your draft targets only standard action and IETF standards
track final allocations where document goes via WG last call.

But in my opinion the genesis of squatting is not at that point in time
scale. It happens much earlier where an idea in the draft if facing early
implementation. Jeff suggested to send such draft to IANA for early
allocation individually but it will be seen in bad light.

So with all of the above we still have no way to get codepoints for early
implementations without being stuck with reviews. And implementations are
not even used to jusitfy acceptance to become a WG document in IDR ....

Cheers,
r.





On Thu, Mar 23, 2017 at 1:46 PM, Susan Hares <shares@ndzh.com>; wrote:

> Eric:
>
>
>
> Thank you for your return comments with helpful suggestions:
>
>
>
> 1)      IETF consensus trumps  DE opinion -   If you are suggesting that
> the WG chair(s) that sponsored a draft should not be the Designated
> Expert.  Good idea.
>
> 2)      Adequate review –  If you wish it to be a single working group
> assigning BGP code points, the WG chair/document shepherd method works.  By
> this comment, we would need to select one WG to approve standardization of
> BGP code points.  My proposal at IETF 97 was that IDR was such a WG since
> BGP base specifications (e.g., RFC4271) were started there.  My alternate
> proposal of shared responsibility among the BGP-focused chairs is the
> bgp-registries.
>
> 3)      On reviewing Shepherd’s work – sounds like you would be a useful
> reviewer for documents.  Please volunteer.
>
> 4)      On code point squatting, operators had real problems with the
> current situation.   Job said “automatic checks on drafts”,  Sue said “IETF
> Standard + DE of BGP chairs where IETF Consensus wins” – Got any alternate
> solutions.  Got any alternate suggestions?
>
>
>
> Sue Hares
>
>
>
> *From:* Eric C Rosen [mailto:erosen@juniper.net]
> *Sent:* Thursday, March 23, 2017 1:29 PM
> *To:* John G. Scudder
> *Cc:* Susan Hares; Adrian Farrel; idr@ietf.org
> *Subject:* Re: [Idr] Thoughts on https://www.ietf.org/id/draft-
> hares-idr-bgp-registries-01.txt
>
>
>
> On 3/22/2017 2:36 PM, John G. Scudder wrote:
>
> I think Adrian nailed it when he suggested:
>
>
>
> b. Recognition that IETF consensus trumps DE opinion. Hopefully this will never
>
> arise, but it is clear (or should be) that for a Standards Action registry, if
>
> there is IETF consensus for an assignment, then the DEs can warn and advise, but
>
> the will of the IETF takes precedence.
>
>
> According to the proposal under consideration, the DEs are the same people
> who judge whether there is IETF consensus.  The conflict of interest is
> evident.
>
>
> the reason is to try to ensure sufficient review happens before it's too late.
>
>
> I'm not opposed to additional review, but that has nothing to do with the
> codepoint allocation process.  Presumably it is already the job of the WG
> chairs and/or document shepherds to obtain an adequate level of review.
>
>
> the concept of a WG having "standing to request changes" is inoperative
>
>
> I'm looking forward to the day when you can't get a codepoint in any
> registry without the approval of the security and the operations ADs ;-)
>
>
> In parallel, Job Snijders made a useful suggestion that idnits maybe should be on the lookout for code point squatting.
>
>
> That's an interesting suggestion, but has to be used carefully.  If
> someone is squatting on a codepoint, they should be encouraged to tell the
> rest of us that they are doing so.  Encouraging them to keep it a secret
> (to avoid being tagged by idnits) would be a strange way to encourage
> interoperability.
>
> I also think that document shepherds should be on the lookout for cases
> where drafts specify codepoints or flags for new stuff without requesting
> the necessary registries to be set up.
>
>
> This leads me to wonder if we aren't going at this wrong -- if instead of using the hammer of registry policy to ensure the right WGs have been notified, we should try the screwdriver of automated tooling. The idea is registries would still be marked up with parties interested in monitoring them, but there would be no formal changes to the requirements for allocation from the registries. Those monitoring the registries (e.g., the list of people in Sue's draft) would get notifications when an allocation was proposed -- as early as possible, but no later than when the draft was sent for IETF last call. The onus would fall on them to chime in (again, as early as possible) and the regular consensus process would take its course.
>
>
> This proposal makes sense.  It encourages more review without giving
> dictatorial powers to a committee of WG chairs.
>
>
> your morbid fears of red tape
>
>
> I've seen many cases where IETF politicians wield red tape as a weapon;
> some do so quite expertly.  Ultimately all type fields will be two-octets
> long with FCFS registration; that's the ultimate solution to this
> particular red tape problem.
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>