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

Bob Hinden <bob.hinden@gmail.com> Wed, 20 November 2019 10:17 UTC

Return-Path: <bob.hinden@gmail.com>
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 D7271120B61 for <netrqmts@ietfa.amsl.com>; Wed, 20 Nov 2019 02:17:48 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 5tPsmVgMNSyc for <netrqmts@ietfa.amsl.com>; Wed, 20 Nov 2019 02:17:47 -0800 (PST)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 A0F44120B24 for <netrqmts@ietf.org>; Wed, 20 Nov 2019 02:17:46 -0800 (PST)
Received: by mail-wr1-x42e.google.com with SMTP id b3so27430470wrs.13 for <netrqmts@ietf.org>; Wed, 20 Nov 2019 02:17:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DQrAgbB+4siZDkl64wlgMikFRJ16s7Z0l+TjRInkdJ8=; b=HEytLGIMLXkRhmIuj1VMwYkuOH6n2U0+hMD/t69t5xeMIoYcmVkuI+wP7FezW4Y2V8 Fe/6J685S52mDDVb6IGMCfFAH9vXWBy2KpLVRxzRu0Z+Btfs4C1YNzS/bPUmfyqew5cz 8Uo60sfy9RFgO5K7cecdLPoqJ5wsThKSrksN5610Esy7bHFPFbnTXSxDlfs+M1aoWY3x OwEXcoHTFRIK2OG2simknQ6AppjJWSjbRjc0BlNu1cYmTRXa4ZOHUKEJHGkcxQjUlfTQ lSuQjlKHLZPZ87tIdjrt4G2zXYbqYr6VelUe60LwQL11a0aK7OSxeCZI6YnaQ/z5Y/ly YM4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DQrAgbB+4siZDkl64wlgMikFRJ16s7Z0l+TjRInkdJ8=; b=tXuYqcQ7GlvycmllhN86fmBxLZy9hJIHBrAiotxY1CkyUqUeswmW0BnPWGoUDz63R/ SqjlXB8Syfe7Q4k2as8ukPW/E2V0MdtcuAumT5tDAx3uHIy+YWSfcZrO71EwxBYiFNK1 pLehelL3LFn6Md0fzUfkKJu24P7Ts9BvuB+MyGIDO0E0gct9c3hdlUnuqG1hQykUVwo9 mrNpX9QKhdokXum5xS/tLp6lSh87NpMZBIxrNUFgfqeeY6cOitUu9MtvK7XsGBk9Rc62 7nIF8WpxGLUSa2SxvwD9Ss8cKc3vtIH3yz4V3Tl4f09eC3tv0gsGHwH0X8YVSVfSOCzZ BAWA==
X-Gm-Message-State: APjAAAXXWKlAbJr4AID6/H6mTzkp+3g7VWBeY4RqdbNSLsN2x8+nZJdr 4mGyiaIfhUhLTQVArBozY40=
X-Google-Smtp-Source: APXvYqzqgZLv9OFcQ/i1J5UoZCsXKsFFuxDnA4WJUHvzpA29ThY1yBkhMPHfaLg7Yw8S6ECix3X9+Q==
X-Received: by 2002:adf:f442:: with SMTP id f2mr2233831wrp.289.1574245064992; Wed, 20 Nov 2019 02:17:44 -0800 (PST)
Received: from ?IPv6:2001:67c:370:128:dc77:c0b4:d50c:69bd? ([2001:67c:370:128:dc77:c0b4:d50c:69bd]) by smtp.gmail.com with ESMTPSA id a6sm33754488wrh.69.2019.11.20.02.17.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Nov 2019 02:17:44 -0800 (PST)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <C7C9F643-AC91-492B-88AE-C869BD7EB468@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_666A84A4-DEBA-4084-AEED-D6634C8E9E0D"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 20 Nov 2019 18:17:36 +0800
In-Reply-To: <2542B8F5-A2CD-4F7D-81F9-E60C5021384D@timwattenberg.de>
Cc: Bob Hinden <bob.hinden@gmail.com>, netrqmts@ietf.org
To: Tim Wattenberg <mail@timwattenberg.de>
References: <157290772945.13855.16351216204560466911.idtracker@ietfa.amsl.com> <55AACF28-576A-42E4-8FD7-E082482AF43B@gmail.com> <2542B8F5-A2CD-4F7D-81F9-E60C5021384D@timwattenberg.de>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netrqmts/6jC0wplTJwQI8lloLS-tMjb0caY>
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: Wed, 20 Nov 2019 10:17:49 -0000

Tim,

Thanks for the feedback.

Comments below.

Bob


> On Nov 17, 2019, at 2:53 PM, Tim Wattenberg <mail@timwattenberg.de> wrote:
> 
> 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.“?

Fair question, but I note that the first one also says:

   *  The transit provided in support of the IETF MUST be capable of
      providing access to the IPv4 and IPv6 Default Free Zones [DFZ].
      without the imposition of content filtering (e.g., URL, Site,
      application, port, or Deep Packet Inspection (DPI) filtering).

I think the important part of the first paragraph is “without the imposition of content filtering…”   We want an open Internet connection without any kind of filtering.  I think this is an important requirement.

> 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?

I am not sure.  Other comments?

> 
> "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?

I am not sure.  Other comments?

> 
> --- 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“?).

I agree this should be more clear.   Please suggest text.

> 
>>> - 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.

Thanks, looks good to me.

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

That is fixed in my local copy.


> 
> --- 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.
> 

I am not sure it is practicable for the IETF to run cables in venues these days.

> ---
> 
> 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).
> 

Maybe we need to add a Privacy Section (or similar) to the document.


> 	– Tim
> 
> --
> Netrqmts mailing list
> Netrqmts@ietf.org
> https://www.ietf.org/mailman/listinfo/netrqmts