Re: [Netrqmts] New Version Notification for draft-odonoghue-netrqmts-02.txt

Tim Wattenberg <mail@timwattenberg.de> Fri, 22 November 2019 05:02 UTC

Return-Path: <mail@timwattenberg.de>
X-Original-To: netrqmts@ietfa.amsl.com
Delivered-To: netrqmts@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E67612022E for <netrqmts@ietfa.amsl.com>; Thu, 21 Nov 2019 21:02:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Y7fCN3q_cZxn for <netrqmts@ietfa.amsl.com>; Thu, 21 Nov 2019 21:02:38 -0800 (PST)
Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [IPv6:2001:67c:2050::465:202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86160120103 for <netrqmts@ietf.org>; Thu, 21 Nov 2019 21:02:38 -0800 (PST)
Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 47K4702X2YzQlB9; Fri, 22 Nov 2019 06:02:36 +0100 (CET)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) (amavisd-new, port 10030) with ESMTP id o0yQvAtoOKpr; Fri, 22 Nov 2019 06:02:31 +0100 (CET)
From: Tim Wattenberg <mail@timwattenberg.de>
Message-Id: <6E2A34C0-4D2C-415A-9D14-52AA1AAE4982@timwattenberg.de>
Content-Type: multipart/signed; boundary="Apple-Mail=_F938EA1B-3C63-4FE2-884A-E1A2E462A175"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 22 Nov 2019 13:02:26 +0800
In-Reply-To: <08D065C1-16EE-4CC0-8941-FD92B5EA167E@cisco.com>
Cc: "Livingood, Jason" <Jason_Livingood@comcast.com>, "netrqmts@ietf.org" <netrqmts@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, Karen O'Donoghue <odonoghue@isoc.org>
To: "Joe Clarke (jclarke)" <jclarke@cisco.com>
References: <157290772945.13855.16351216204560466911.idtracker@ietfa.amsl.com> <55AACF28-576A-42E4-8FD7-E082482AF43B@gmail.com> <B53C5F5D-0C2E-4395-A778-967948D4DB4D@cable.comcast.com> <08D065C1-16EE-4CC0-8941-FD92B5EA167E@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netrqmts/1KDoDxclNAyYn-BxySS2GeLkE2Y>
Subject: Re: [Netrqmts] New Version Notification for draft-odonoghue-netrqmts-02.txt
X-BeenThere: netrqmts@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Meeting Network Requirements <netrqmts.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netrqmts>, <mailto:netrqmts-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netrqmts/>
List-Post: <mailto:netrqmts@ietf.org>
List-Help: <mailto:netrqmts-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netrqmts>, <mailto:netrqmts-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Nov 2019 05:02:41 -0000

Joe, thanks for responding. Some comments below.

> Am 22.11.2019 um 12:16 schrieb Joe Clarke (jclarke) <jclarke@cisco.com>om>:
> 
> First, with respect to logging/DPI/packet captures, we should not have a hard and fast rule on this.  We _do_ do some packet capturing and DPI sometimes when we’re trying to troubleshoot certain issues.  We _always_ log PII as the meeting goes on (like IPs and MACs).  What we don’t do is retain this data beyond its useful lifetime and definitely not beyond the meeting time (without some anonymization).
> 
> What we can state is that any and all PII must be destroyed or randomized and not transported off in its unanonymized form from the meeting venue.

Personally, that’s perfectly fine with me. With my comments I didn’t meant to oppose any hurdles against running a reliable and functional network (as this is what we ultimately need).
But I think there is value in specifying just *what* is done (something along your lines)  – like a "privacy policy".
Let it be just as documentation for whom it is important (for personal or whatever reasons).

> As to more on the doc, I think in some places we are too specific.  For example, in Section 4.3, we talk about providing VMs for remote participation and DHCPv4 and v6.  Today we use VMs for Meetecho, but we may not always do that.  I don’t think DHCPv4 is going anywhere, but again, it’s what we do today.  In general, we need to provide compute infrastructure to support remote participation, and we need to provide a way to scalable address client hosts and provide name resolution.  For example, we may drop DHCPv6 at some point as RDNSS is fairly well-supported in RAs.
> 
> Likewise, in Section 4, getting into separate VLANs for wired/wireless seems too specific.  Today we do that, but we may not as we evolve the network.  Changing VLAN architecture should not be user-impacting, and thus I don’t think we need to explicitly call it out in the requirements doc.

I tend to agree with you here. However, I also remember the BoF in Montreal where there actually *was* a detailed discussion around specific services.
In the end, it’s somehow a matter of taste if people like to have a very strict requirements document, or rather something more general.
(As said, personally I lean towards the latter – at least for a start.)

I’m sitting in the last Friday session, so:
Thanks to the NOC for yet another meeting!

	– Tim