Re: [Add] Proposed charter and BoF request for IETF 106

Richard Barnes <rlb@ipv.sx> Wed, 09 October 2019 17:14 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A24120968 for <add@ietfa.amsl.com>; Wed, 9 Oct 2019 10:14:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 l8Q9kFCuxRIN for <add@ietfa.amsl.com>; Wed, 9 Oct 2019 10:14:36 -0700 (PDT)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 11C22120954 for <add@ietf.org>; Wed, 9 Oct 2019 10:14:36 -0700 (PDT)
Received: by mail-ot1-x32d.google.com with SMTP id c10so2369544otd.9 for <add@ietf.org>; Wed, 09 Oct 2019 10:14:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BZCVQ9KeMjEudI8T0gjJN5VuDSPK7ZUWGf3LfqJ1KQA=; b=MS1xqqDpIm7ezvwgMUBAREMapqVAm82GPG+SNzTC/+uSobxU46B8acAx5gaL6f0f7t 2sbZmNLoeZfcJxlNCPjG+EYV5eQUxITCJyx2D84APtn3Ik5j/0N0krwf+ZziZIZt9vP6 VcN52rblJCghr1/L1vyzQMdOT3aixRCq/GLDUolBwbu+Iu5PmJP2F4SatobFE0aBgUap Ge632dS5xlzTzH+XnQ4tmob3EDEGPUKft8naHpRuIOwu19Bs+8k5hUD3nx/55h3SsCoK 4o6NHEu8lfhZeSQqZx8Ro6nqML9bc9Jc6ZtHPg1Bg/jz96aWI6vfednZMopb3bKccLfV ACAA==
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=BZCVQ9KeMjEudI8T0gjJN5VuDSPK7ZUWGf3LfqJ1KQA=; b=MgYv4vKe/NU/Zyq7eLiLHQG7LkorzAi/GPb5UPAbJQrCq7cmScvEkR5di+vOqMQ6Dr AKmF+Wpss8hfwVAJN80iVQXeC64RckuuRKYJjiXMRqggkhioaidrinDNYFv6BhHAna73 k4KpAImqDX0wQRPiin0DueKAsSo8a7WFsLJpDRe+/RrIvGsMKTabURvKanf+K0bik5mi G2SG2Qg6yynb/0hiyQfj8MBRPNPv/u5Mbf+Qm63mPHkF7v9CmlR7b18WoLOCcSm/XwQN wxYuIUZOClhSQ9Yux2WRO12ZmB6tWvJ45Yli53qo2xkKuxuP3HgdcUNIqZGIe5Ij9uS1 uAfg==
X-Gm-Message-State: APjAAAWPkO9O7s/rpepYOAuVuzz9rc7QIzDxSWd18ErPKNFrjgIK9+Hf f/MEkOWyAmhoJ0HQABG/0dyCHbSbZHa9HqPisx8cg3Mp
X-Google-Smtp-Source: APXvYqx6IgHwFTo7TClnTUL3Da09fauaggDpr95l3IYzqIav9P72YI0Xdp38XIz2xgOYccVQuCl6MDHDdNpueUbFPCQ=
X-Received: by 2002:a9d:550a:: with SMTP id l10mr3879659oth.93.1570641275126; Wed, 09 Oct 2019 10:14:35 -0700 (PDT)
MIME-Version: 1.0
References: <CALaySJLxXVuHQNfTnaeKZ_R9xtBYWfbta+A1bWcE-ZQZwd3VZg@mail.gmail.com> <CABcZeBMkAFZW9mWjw92v+OR0Fa8ed+P80yc78eY07hCpsCNY6Q@mail.gmail.com> <CABcZeBOOq4FHVoxsyApzOc4VtTbMwZn7858-E+4kr21Z0r5wrA@mail.gmail.com> <CAL02cgR_61TNnPy=ios+hQFs_tjfYNXu-sBpbDL-HBY+QsY40A@mail.gmail.com> <1286342342.28404.1570639674402@appsuite-gw2.open-xchange.com>
In-Reply-To: <1286342342.28404.1570639674402@appsuite-gw2.open-xchange.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 09 Oct 2019 13:14:22 -0400
Message-ID: <CAL02cgTdhzQXaW8qLuWiKmZiW2x6eabFzzHwZ9rDugq66TJHkQ@mail.gmail.com>
To: Vittorio Bertola <vittorio.bertola@open-xchange.com>
Cc: add@ietf.org
Content-Type: multipart/alternative; boundary="000000000000461c5105947d6b3b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/ZZLMGqdsHn0fTIKoL-HTbI-5VP0>
Subject: Re: [Add] Proposed charter and BoF request for IETF 106
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Oct 2019 17:14:43 -0000

On Wed, Oct 9, 2019 at 12:47 PM Vittorio Bertola <
vittorio.bertola@open-xchange.com> wrote:

>
> Il 9 ottobre 2019 16:21 Richard Barnes <rlb@ipv.sx> ha scritto:
>
>
> I think EKR is on the right track here.
>
> There is a bright line here between technology and deployment policy.  The
> former we have some hope of progressing on, and there are meaty questions
> around how applications can discover local network capabilities and
> preferences in a way that is not open to abuse like the mechanisms we have
> today.  On questions of the latter form, the entire history of this list,
> and the meeting that preceded it demonstrate, that there is very little
> hope of consensus.
>
> The charter right now has some of both.  If this charter is to go forward,
> it should be refactored to focus on engineering questions, and avoid policy
> questions.  In particular, the BCP item needs to be struck.
>
> I see the reasons behind this line of thought, but honestly, seen from my
> viewpoint, it looks like the IETF is playing hide and seek on the
> non-technical issues. It starts a deep change in a basic technology for the
> entire Internet, with at least one AD stating in public things like "we're
> going to save dissidents and journalists with this new technology", then
> when the real world problems of that approach come up, the IETF backs away
> and says "sorry, we only deal with the engineering questions". So yes, you
> can strike any policy and deployment model discussion from the charter, but
> then you should also strike RFC 7258 - what is it, if not a policy
> statement?
>

It is indeed a policy statement -- and one around which there was strong
consensus at the time it was published.  (I expect there still is.)  It's
not that I think the IETF can't make policy statements of this character,
it's that there's no indication that there's any policy statement in this
domain around which there is consensus to be had.

--Richard



>
> (Before someone jumps at my throat, I'll stress that I'm not actually
> arguing against RFC 7258, I'm just noting that it's too late to claim that
> the IETF does not do policy, at least in this area.)
>
> This said, I do not have a firm opinion yet on this; I see that having the
> deployment model in the charter might derail technical developments that
> could instead get to consensus. So it might still be a wise decision for
> the IETF to say "we have realized that there are complex policy and
> juridical issues stemming from this and we are not well equipped to deal
> with them, so we declare them out of scope".
>
> The unavoidable consequence, however, would be that the policy discussion
> moves somewhere else, possibly somewhere in the I* galaxy, for the global,
> non-binding and opinion-making debates, and into national Parliaments for
> any hard law if required. So the IETF must then be prepared to accept that
> other parts of the ecosystem might have other views on how the DNS should
> work and which use cases it should support, and cooperate with their
> conclusions.
>
> And to be honest, even if the IETF decided to tackle the policy issues and
> managed to come up with a best practice, it could easily be that other
> policymaking entities got to different conclusions and asked the engineers
> to align.
>
> --
>
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bertola@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy
>
>