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

Tim Wattenberg <mail@timwattenberg.de> Sun, 17 November 2019 06:53 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 A6AA812007C for <netrqmts@ietfa.amsl.com>; Sat, 16 Nov 2019 22:53:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 FDZm7VbVDdRu for <netrqmts@ietfa.amsl.com>; Sat, 16 Nov 2019 22:53:29 -0800 (PST)
Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [IPv6:2001:67c:2050::465:201]) (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 575B91200A1 for <netrqmts@ietf.org>; Sat, 16 Nov 2019 22:53:28 -0800 (PST)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 47G2qB5G2vzQl34 for <netrqmts@ietf.org>; Sun, 17 Nov 2019 07:53:26 +0100 (CET)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp2.mailbox.org ([80.241.60.241]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id CMkPP77FsT0i for <netrqmts@ietf.org>; Sun, 17 Nov 2019 07:53:22 +0100 (CET)
From: Tim Wattenberg <mail@timwattenberg.de>
Content-Type: multipart/signed; boundary="Apple-Mail=_C4856BD1-532B-4B20-A961-30750F008515"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 17 Nov 2019 14:53:19 +0800
References: <157290772945.13855.16351216204560466911.idtracker@ietfa.amsl.com> <55AACF28-576A-42E4-8FD7-E082482AF43B@gmail.com>
To: netrqmts@ietf.org
In-Reply-To: <55AACF28-576A-42E4-8FD7-E082482AF43B@gmail.com>
Message-Id: <2542B8F5-A2CD-4F7D-81F9-E60C5021384D@timwattenberg.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netrqmts/Uz9sdT6lbJsnxiJd9kq394j-gvQ>
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: Sun, 17 Nov 2019 06:53:33 -0000

Hi and sorry for the belated feedback.

> Am 05.11.2019 um 07:12 schrieb Bob Hinden <bob.hinden@gmail.com>om>:
> 
> I volunteered to be the document editor for this draft.    With Karen’s help, I just submitted a new version.  The changes include:
> 
>    o  First update since BOF at IETF 105
>    o  In each section reordered requirments in MUST to SHOULD order.
>    o  Restructured sections to be part of Internal Network Requirements.
>    o  Changes based on feedback on mailing list.
>    o  Added Robert Hinden as editor.
>    o  Editorial changes.

Bob, thanks for updating the document. The changes are much appreciated.

--- Section 2 "Requirements for Internet Connectivity“

I'd extend the bullet point "The provider(s) MUST allow the IETF to advertise (from the IETF AS number) the IETF IPv4 and IPv6 address ranges.“ with "There MUST exist RPKI ROAs for the address space announce by the IETF.“

I might misunderstand something, but could you point out the difference between "The transit provided […] MUST be capable of providing access to the IPv4 and IPv6 default free zones […]“ and "The provider(s) SHOULD carry and advertise full BGP tables.“?

Also, section 2 only talks about the measures the transit provider(s) are supposed to take. The IETF itself also can do (and probably does?) route filtering/OV. However, text for this would probably go into section 4?

"The provider(s) SHOULD implement BGP communities, especially the ability to RTBH.“
Besides from RTBH, do you have other use cases in mind to explain a little what you mean by this point?

--- Section 3 "Meeting Facility Requirements“

"All locations for network gear, with the exception of wireless APs, MUST be secure.“
I think that's *very* broad. Maybe we can add against what they must be secured (e.g. "[…] MUST be secured against unauthorized access“?).

>> - re " The meeting facility SHOULD have installed network cabling that can be used to deploy the network infrastructure." Perhaps you can be more specific? I think you are asking for at least one GigE drop in each meeting room in order to provide backhaul for WiFi APs, with ballrooms and larger meeting spaces to be able to accommodate additional GigE drops. But that sort of seems covered in Section 4?
> 
> I think having this be more specific would be good.   Can someone suggest some text?

"[…] This includes at least one wired Ethernet connection (network drop) terminating in each meeting room, with ballrooms and larger meeting spaces as well as hallways and additional common areas having multiple network drops.“. Also, we should probably raise this to a MUST have, or adjust section 4 to be aligned.

You have a double "The meeting facility“ in the last bullet point if this section.

--- Section 4 "Internal Network Requirements“

Addition: "If not provided by the meeting facility, wired Ethernet connections (network drops) MUST be provided by the IETF NOC […]“.
To make it even more clear that section 3 talks about our requirements towards the meeting facility and section 4 talks about the different use cases within the IETF.

---

There is one additional thing I’d like to see mentioned somewhere:
"The network MUST NOT log or collect user payload data.“ (or something along those lines).

	– Tim