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

Bob Hinden <bob.hinden@gmail.com> Tue, 05 November 2019 17:15 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 89E371200EC for <netrqmts@ietfa.amsl.com>; Tue, 5 Nov 2019 09:15:30 -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 wuGU15QYI0fv for <netrqmts@ietfa.amsl.com>; Tue, 5 Nov 2019 09:15:24 -0800 (PST)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 C812812001A for <netrqmts@ietf.org>; Tue, 5 Nov 2019 09:15:23 -0800 (PST)
Received: by mail-wm1-x333.google.com with SMTP id f3so85118wmc.5 for <netrqmts@ietf.org>; Tue, 05 Nov 2019 09:15:23 -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=OkxhDqd95N+DyyeFyJiSUWURXs87v+br15DLGk+POGE=; b=GYX6eOit58j1D1dQKichzpt8ZtkNnR4D5HCB2VgDrepBKTIaGgl1r8hVAhwF5rgiU+ dAGfVYm3Vh8eQj7mnS19TIrjZ1k9Oe3PaqhVRenkw8PQoSGH/TyLIbyvYFIs4iCf6hmr CL6R0Zq86VaMPp5n+Qs6guwkYuQGU7q7oStyMa/4za3u4/Vjua8410G11M/4A+uq1JBj xHGCn9IJ58N5l4pX5agFpU4EsON/pEFyRvsQgaN2540LZwWCf343y7GRWBWhK7GgLoAx A371obk2BSoLyFEisQXdP3/LlyW2tIDWMo1VQ/Yq5ot4AfSEGw2FY30NKFjzXIYNqzBq avVA==
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=OkxhDqd95N+DyyeFyJiSUWURXs87v+br15DLGk+POGE=; b=Un1EQQt+0CU2pqETTLf/FqP2TfJISUnnYiQ/XAuExoHHrR6qhj4TelesF49fYMCgGl ldpctjTJNP6vfG4fqqOiOQCgGZdZvdq1L19tWUgFMXg861Sq9WtE//HapVo63aUokklR 9DgV2iNkuZusr19bFDQYaZF7FBdgGC82NW9LdtWd+CLpI3TPU1lJQxmBTPExRTnGxB/y /ResY9tnEJMLaQNm61QaQHS3pH12NTl2f9kbkWx0uEz34B1BfiEtpsNgY9JfeiIAudZb zwNHkzUN54WtM4MVR7KrNGpBOD7agxdUYf6hOU6ItxjB2pYnKkCl/jv0FOd1uxqhDElH bR6g==
X-Gm-Message-State: APjAAAXl5e6P5cm5F8u089Q51vT0K8rAEotK+QL2HF9+L8qvtRshuhAY wb/kKA6KJr2Eg5+JYyEhu/Y=
X-Google-Smtp-Source: APXvYqzJy7Bf12jLpYhskzvv3BKZYFVvCjWy7FkxpbYp2cEJpxWKu3foZoNd7v1AShgnzbZ1HOcEpg==
X-Received: by 2002:a1c:ab0a:: with SMTP id u10mr102812wme.0.1572974122071; Tue, 05 Nov 2019 09:15:22 -0800 (PST)
Received: from [10.0.0.199] (c-24-5-53-184.hsd1.ca.comcast.net. [24.5.53.184]) by smtp.gmail.com with ESMTPSA id m3sm16548386wrw.20.2019.11.05.09.15.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Nov 2019 09:15:20 -0800 (PST)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <C12E994A-DA4E-4B4D-AF93-37D18C83D2E1@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_F9594E65-D7B4-4366-9219-A80577092635"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 5 Nov 2019 09:15:15 -0800
In-Reply-To: <B53C5F5D-0C2E-4395-A778-967948D4DB4D@cable.comcast.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, "netrqmts@ietf.org" <netrqmts@ietf.org>, Karen O'Donoghue <odonoghue@isoc.org>
To: Jason Livingood <Jason_Livingood@comcast.com>
References: <157290772945.13855.16351216204560466911.idtracker@ietfa.amsl.com> <55AACF28-576A-42E4-8FD7-E082482AF43B@gmail.com> <B53C5F5D-0C2E-4395-A778-967948D4DB4D@cable.comcast.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netrqmts/171AJE4kSRsoXndGO8ITpxYwRCI>
Subject: Re: [Netrqmts] Fwd: 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: Tue, 05 Nov 2019 17:15:30 -0000

Jason,

Thanks, comments inline.

Bob


> On Nov 4, 2019, at 5:23 PM, Livingood, Jason <Jason_Livingood@comcast.com> wrote:
> 
> Looks good!
> 
> Some minor nits & feedback:
> Section 2:
> - s/ IPv6 MUST be provided/ Native IPv6 MUST be provided

Sure, should we also require that Native IPv4 be provided?  For example:

    Native IPv6 and IPv4 MUST be provided

> - What are "default free zones"? Not defined.

I could add a reference to

  https://en.wikipedia.org/wiki/Default-free_zone

> - s/DPI based/DPI-based

I will change to “Deep Packet Inspection (DPI) filtering"

> - Spell out acronyms on 1st use: BGP, IRR, RTBH (same for other sections later on)

Will do.

> 
> Section 3:
> - s/ SHOULD have physical characteristics/ SHOULD have characteristics [JL: they may be able to limit radio power and so on via software-based radio resource mgmt. tools rather than physical things]

How about:

   o  The meeting facility SHOULD support the deployment of additional
      wireless networks including techniques to limit interference such
      as limiting radio power, software-based radio control, and or
      physical separation.


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

> 
> Section 4:
> - Confirm with AMS but I suspect this can be deleted due to WiFi use: "Wired network drops MUST be provided to the registration desk.”

I checked with AMS, they need a wired drop for a printer.

> - Terminal room access "during normal IETF meeting times". That leaves it open for flexibility as the general IETF schedule changes slightly w/o having to revise this document.


I think it’s usually open before and after scheduled IETF meeting.  If we don’t want to have it open 24 hours, then 6am to Midnight might work.  We do have lots of jet lagged people at these meetings :-)

I wonder if we have any data on usage?


> - s/ network connected/ network-connected
> - Is an enterprise class printer required? -->Maybe just spec a laser printer and be done with it. I suspect print volumes are rather low. If there was a slow inkjet that may cause problems. ;-)

I think we usually just have a networked color inkjet printer.   They may even buy a new one before each meeting as it’s cheaper/easier to store/ship/maintain.

I propose the following to replace this and the following item:

   o  The terminal room MUST include a networked medium capacity color
      printer with duplex capability.

Perhaps citing what we are currently use might be helpful, and better define “medium capacity”.


> - Re There SHOULD be a manned help desk --> Why? Is this often used? Could it be a sign that directs someone to the NOC room for help? Or explains how to ticket an issue?

I think it is used frequently, thought the NOC folks might have some data.  I have used it :-)

We have a range of people with various technical abilities in the IETF.  They often need this kind of support.


> - 4.2 - 1st bullet has an incomplete couple of sentences. Maybe the period was meant to be a comma?

Fixed:

   o  The network design MUST anticipate simultaneous usage of 100% of
      the projected number of attendees in each meeting room.  The
      number of wireless network users in excess of 1000 simultaneous
      wireless users has been observed during a plenary session.

That said, 100% is probably too low.  I would think it should be 200%.  For example, I have my laptop and phone on the wireless.   Apple watch type devices will increase that even more.  Maybe 250% is about right.

> 
> Section 5:
> - A document must be provided? As in a physical piece of paper? Or can this info be on the meeting website or on a sign someplace? Maybe change document to instructions?
> 

Good point.  How about:

   o  Online documentation MUST be provided to attendees detailing on-
      site network configuration information, including wireless
      configuration details, services available (e.g., printing),
      instructions on how to report network issues (e.g. trouble ticket
      system interface instructions), etc.  Initial versions of this
      information SHOULD be provided in advance of the meeting.  This
      should be provided on the IETF meeting website and distributed to
      attendies via email.



> Thanks!
> Jason
> 
> From: Netrqmts <netrqmts-bounces@ietf.org> on behalf of Bob Hinden <bob.hinden@gmail.com>
> Date: Monday, November 4, 2019 at 6:13 PM
> To: "netrqmts@ietf.org" <netrqmts@ietf.org>
> Cc: Bob Hinden <bob.hinden@gmail.com>om>, Karen O'Donoghue <odonoghue@isoc.org>
> Subject: [Netrqmts] Fwd: New Version Notification for draft-odonoghue-netrqmts-02.txt
> 
> Hi,
> 
> 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.
> 
> Please take a look, links are below.
> 
> Thanks,
> Bob
> 
> 
> 
> 
> Begin forwarded message:
> 
> From: mailto:internet-drafts@ietf.org
> Subject: New Version Notification for draft-odonoghue-netrqmts-02.txt
> Date: November 4, 2019 at 2:48:49 PM PST
> To: "Karen O'Donoghue" <mailto:kodonog@pobox.com>, "Robert M. Hinden" <mailto:bob.hinden@gmail.com>, "Robert Hinden" <mailto:bob.hinden@gmail.com>
> 
> 
> A new version of I-D, draft-odonoghue-netrqmts-02.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
> 
> Name: draft-odonoghue-netrqmts
> Revision: 02
> Title: IETF Meeting Network Requirements
> Document date: 2019-11-04
> Group: Individual Submission
> Pages: 9
> URL:            https://www.ietf.org/internet-drafts/draft-odonoghue-netrqmts-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-odonoghue-netrqmts/
> Htmlized:       https://tools.ietf.org/html/draft-odonoghue-netrqmts-02
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-odonoghue-netrqmts
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-odonoghue-netrqmts-02
> 
> Abstract:
>  The IETF Meeting Network has become integral to the success of any
>  physical IETF meeting.  Building such a network, which provides
>  service to thousands of heavy users and their multitude of devices,
>  spread throughout the event venue, with very little time for setup
>  and testing is a challenge.  This document provides a set of
>  requirements, derived from hard won experience, as an aid to anyone
>  involved in designing and deploying such future networks.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at http://tools.ietf.org.
> 
> The IETF Secretariat
> 
>