Re: [OPSEC] [Tsv-art] Architectural implications of EH / filtering (was: draft-ietf-opsec-ipv6-eh-filtering)

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 12 December 2018 12:06 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8016130DDA; Wed, 12 Dec 2018 04:06:02 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 EN6sao3jSBoD; Wed, 12 Dec 2018 04:06:00 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 3DFF5130E2D; Wed, 12 Dec 2018 04:06:00 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id v5so13338608lfe.7; Wed, 12 Dec 2018 04:06:00 -0800 (PST)
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=nCN5s9IzOvJC3NFA0KLmMiot/pwF3uB7ac70+nYw+DQ=; b=lKB8DYjaOTPgPeAmiduZbCy9S0up7SDM3xtODiZRPe1DyqPVA6VmuUbdIdiaBv1FFb zq1l7sBcb94eDaK+a5I2vakbwlnWLiXrbFs+Oqu95yQY8/SS8bNEO734GlbIdTxP6zD6 WxBRihEExDXEigr5TivnnsvmnJweNBtE7wNALo7rtyTHT0mDL0QN0JHPVmrHjPUv26iI gX1/Yj0zwYJWVG5thofNlXiESk2VtOLGeYQMiAqx9iP3exHqpxXjf3GGCWGpjFYLQG/N pH4Kv8t6ukQtzcMz9wNP2+ibZ2jRywfLVhsxCZPUfKu1pShhLuPHWAt6osra9Bhf2bXt bwoA==
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=nCN5s9IzOvJC3NFA0KLmMiot/pwF3uB7ac70+nYw+DQ=; b=DqQX67oXXNx6IEEs3jkV3/SkdBwKhTK/kG/RsEhaPqYMa7NQ3mTBPFUsJkUIUlLD7V lGT5K1Al2G0sautQpLAoDtF8b+dIBtBLogD5zqti9oTIWgzjN5by08Opu7IrKaMeTR2F syGpy+GLnfAFgWpP6qYq/xS40lVA9K0JyUZtKoNzAifkLWGbJQGK2TgOrSBM0wCEa5Kh v66GzTon/QIW9QVjxxATnpgm2akhVdxGoP4v6pBPtxhMwwz1WO7Jv/lgRYLbcR+dJxxf N93uWnJLx6/0mkdEjn4UTIRx3tInZ8YOI6PWaog8UcrVsnQYm2BTxZ3ZJ7uoeqnlEriY ZdAw==
X-Gm-Message-State: AA+aEWYAxDIAANkzupTj9da2TL0kyBj6qxgwt7yB7e8TtiJCYTfA6BNz 1w0W1U7wOxMvCNOODZTO4LhthbmLvG/EoNo/Ya0=
X-Google-Smtp-Source: AFSGD/XoF6iLzKjABfB/u6ZJjQuELWSr41yups6vK9ZPUOnzl8BgI/OQE6KVJmh7DgGvcwFlxeoqZcNQOa8wf9it21E=
X-Received: by 2002:a19:d145:: with SMTP id i66mr12175963lfg.97.1544616358241; Wed, 12 Dec 2018 04:05:58 -0800 (PST)
MIME-Version: 1.0
References: <CAHw9_iK59mb2twkzkCd+at7=2=NfwvkPwuPCfT6kLx=WaBQ3zA@mail.gmail.com> <3661a5b9-9178-d20a-a781-ed773140c8af@cs.tcd.ie> <0F89B980-2C64-4EC7-B8A6-31D6FBE240CA@gmail.com>
In-Reply-To: <0F89B980-2C64-4EC7-B8A6-31D6FBE240CA@gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 12 Dec 2018 06:05:45 -0600
Message-ID: <CAKKJt-eSVukQpbP98aGeYNteL61yuPC=f0Mgv=qZDVqhXSB3eA@mail.gmail.com>
To: Tim Wicinski <tjw.ietf@gmail.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, tsv-art@ietf.org, opsec wg mailing list <opsec@ietf.org>, Warren Kumari <warren@kumari.net>, IETF Discuss <ietf@ietf.org>, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org
Content-Type: multipart/alternative; boundary="00000000000058ecf6057cd205ac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/Ve1TFHDu-Dwggc9S6DvMR83Rhtw>
Subject: Re: [OPSEC] [Tsv-art] Architectural implications of EH / filtering (was: draft-ietf-opsec-ipv6-eh-filtering)
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Dec 2018 12:06:03 -0000

Fwiw,

On Tue, Dec 11, 2018, 20:34 tjw ietf <tjw.ietf@gmail.com wrote:

> I can not agree with mr Farrell enough on this.
>
> Tim
>
> From my high tech gadget
>
> > On Dec 11, 2018, at 19:20, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
> >
> >
> > Hiya,
> >
> >> On 11/12/2018 23:58, Warren Kumari wrote:
> >> * having some presentations / discussions on "how X works when deployed
> /
> >> implementation shortcomings". As an example, at the IEPG meeting in
> >> Yokohama (IETF94) these was a presentation on "MODERN ROUTER
> ARCHITECTURE
> >> FOR PROTOCOL DESIGNERS" -
> >> http://www.iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf
> . As
> >> another example, I was recently informed of a surprising limitation in
> TLS
> >> libraries -- these are apparently well known to those who work in this
> >> space, but I'd certainly never heard of them. I think that we (IETF
> >> participants in general) sometimes fall into believing that we know how
> >> technology X works because we've helped design it, but don't necessarily
> >> know what happens once it escapes our clutches / flies out of the nest.
> >> * consider having a BoF on this / these topics.
> >> * perhaps something like a workshop?
> >
> > Maybe consider moving IEPG to a more prime-time IETF
> > meeting week slot? (Or any equivalent.) The couple of
> > times I've gotten to IEPG, I was struck by how it was
> > higher quality than average IETF presentations. For
> > me, I always really like finding out about cases where
> > reality != theory and I bet I'm far from alone.
> >
> > So, I'd argue a bit against a one-off BoF or workshop
> > and more for a recurring opportunity for fact-based
> > detailed presentations.
>

I agree with Stephen, and moving IEPG off Sunday morning actually maps onto
the stated intent of recent IESGs and IABs to improve communication and
interaction. You know this, but others may not know that the IESG has a
standing meeting on Sunday mornings each IETF week, so the IESG is less
aware of IEPG discussions than most IETF participants.

I don't think we have to choose between moving IEPG and having a workshop,
and maybe even a BOF. If we move IEPG and the community is more aware of
operator positions, workshops and BOFs might be better informed.

Is it premature to ask the nice IEPG people about this? A move would need
to work for them, too.

Spencer

>
> > S.
> > <0x5AB2FAF17B172BEA.asc>
>
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art
>