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

Bob Hinden <> Fri, 22 November 2019 05:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0111D12004E for <>; Thu, 21 Nov 2019 21:11:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oMNfcpW3qQMD for <>; Thu, 21 Nov 2019 21:11:52 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CBD2A120115 for <>; Thu, 21 Nov 2019 21:11:51 -0800 (PST)
Received: by with SMTP id i12so7073253wro.5 for <>; Thu, 21 Nov 2019 21:11:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=u/3fIJm0s0UTcMZ3lNN7eVHokRwmhnoWV7hHoArt2mg=; b=UeMjfcpBsYEMdy/+QdlW2kKlc6PYIdyTXnE2uwt6ACYm3APnlgtNeQVoFQgkvo53Qv PODWs40XzAvqx3UK6z+jnlZWISkgr4rz3iLRafAO+7qBolS90EeDGTnO+IeB97/ZeLR7 SV8o6v8X+39E9KMffgAQy91LvNgL3raS9Y4CJefR52YtwfeHOkdjQ61em9qW9YtU614I 3O0QoRy+F2Fle0ZJKrh2HvqZIF3bvwl1UMYpP8FFCPvtOJG2tN3xbK65HNgxq47gOQ5c hoBBVZdNuNQabZisl8NAC95iupSsjWGkhlZzvFPRqNLH81F1UWLpcccqqOiSqheyMem3 nyDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=u/3fIJm0s0UTcMZ3lNN7eVHokRwmhnoWV7hHoArt2mg=; b=Kxdn3C9M9yn2raeZyNiCbYYsXwu4ggPiVM9SRkfu+wrOhnJSEoKkLHKrLAgsZ5Jg6y DgQ+L0XbeDiwnBAZvDifF2YcfOeRLbN9EK6csnstJeAGx32FvHRp6WSyfzv2qQgQ/Kf7 iCiJWQcKxUUrA8ZlPsibqit0GAB1dQm+95JHeHypkaVuWwwP/i7jpH6SKSJ78BiN/a0d 8c60niKJr8eC6mcVc9Ab8arWTwmfBYSj+2LEEAcjVXFCmllN1yp4YjLXI5Swmr/mocW2 uJo79uLCjEWATooCdpeHOlxykdijv4FXlN+hLhZvPXAttVa32EQi6C5JxJYR80mHHW8L d0xw==
X-Gm-Message-State: APjAAAX0uVlh6bdlMAmU2OaiFisY7clcgRzATNsqnR1vQggQ4Y9iXQkJ 93YJkXAf6qWjRGfB0wDoIP8=
X-Google-Smtp-Source: APXvYqwQ0AE0toUa1yuxylE4QNxy5M1gbodi0ASRlnBsvBA9RhAINMfgNA/BZAdPjmWxyHmbUcZPCQ==
X-Received: by 2002:a5d:5391:: with SMTP id d17mr16371496wrv.382.1574399510258; Thu, 21 Nov 2019 21:11:50 -0800 (PST)
Received: from ( []) by with ESMTPSA id w4sm6091273wrs.1.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Nov 2019 21:11:49 -0800 (PST)
From: Bob Hinden <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_F392EDD8-0A45-4E2E-9B8B-A0081F38FB82"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 22 Nov 2019 13:11:42 +0800
In-Reply-To: <>
Cc: Bob Hinden <>, Jason Livingood <>, "" <>, Karen O'Donoghue <>
To: "Joe Clarke (jclarke)" <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [Netrqmts] New Version Notification for draft-odonoghue-netrqmts-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Meeting Network Requirements <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Nov 2019 05:11:56 -0000


Thanks for the feedback.  Inline.

> On Nov 22, 2019, at 12:16 PM, Joe Clarke (jclarke) <> wrote:
> I’ll jump in on this thread with my NOC member hat on.  I have read through the thread, and I have some contextual comments as well as some overall comments on the doc.
> 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.

This seems like a reasonable approach to me.  I will work on some text that captures it.

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

Would something like this be better?

   The network MUST provide support for Remote Participation
   Services.  This MAY include VMs or other techniques as appropriate.

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

Please suggest some text.   I note that the DHCPv6 requirement is a SHOULD so it could go away if no longer needed.

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

That makes sense, I will remove that text.   It is how to implement a service, but isn’t a requirement.


> Joe
>> On Nov 4, 2019, at 20:23, Livingood, Jason <> wrote:
>> Looks good!
>> Some minor nits & feedback:
>> Section 2:
>> - s/ IPv6 MUST be provided/ Native IPv6 MUST be provided
>> - What are "default free zones"? Not defined.
>> - s/DPI based/DPI-based
>> - Spell out acronyms on 1st use: BGP, IRR, RTBH (same for other sections later on)
>> 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]
>> - 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?
>> 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."
>> - 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.
>> - 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. ;-)
>> - 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?
>> - 4.2 - 1st bullet has an incomplete couple of sentences. Maybe the period was meant to be a comma?
>> 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?
>> Thanks!
>> Jason
>> From: Netrqmts <> on behalf of Bob Hinden <>
>> Date: Monday, November 4, 2019 at 6:13 PM
>> To: "" <>
>> Cc: Bob Hinden <>, Karen O'Donoghue <>
>> 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:
>> Subject: New Version Notification for draft-odonoghue-netrqmts-02.txt
>> Date: November 4, 2019 at 2:48:49 PM PST
>> To: "Karen O'Donoghue" <>, "Robert M. Hinden" <>, "Robert Hinden" <>
>> 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:  
>> Status:
>> Htmlized:
>> Htmlized:
>> Diff: 
>> 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
>> The IETF Secretariat
>> --
>> Netrqmts mailing list