Re: [Netrqmts] updated network requirements draft

Michael Richardson <> Tue, 09 July 2019 14:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FF3912016A for <>; Tue, 9 Jul 2019 07:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qI77uHajdLbB for <>; Tue, 9 Jul 2019 07:32:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 977C9120106 for <>; Tue, 9 Jul 2019 07:32:41 -0700 (PDT)
Received: from (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by (Postfix) with ESMTP id DB0D4380BE; Tue, 9 Jul 2019 10:30:36 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id EF41A5BE; Tue, 9 Jul 2019 10:32:38 -0400 (EDT)
From: Michael Richardson <>
To: "" <>
In-Reply-To: <>
References: <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 09 Jul 2019 10:32:38 -0400
Message-ID: <2294.1562682758@localhost>
Archived-At: <>
Subject: Re: [Netrqmts] updated network requirements draft
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: Tue, 09 Jul 2019 14:32:44 -0000 <> wrote:
    > In hindsight, perhaps that wasn’t the wisest choice but hey… you live and
    > learn…

    > This document represents three sets of requirements:
    > 1) Requirements for external connectivity providers
    > 2) Requirements for the meeting venue
    > 3) Requirements for the network that the IETF NOC Team builds
    > These are perhaps not as clearly differentiated as they should be.

Surely there are some interactions in the requirements?
You've done a good job.

The original text said:
  " The primary link MUST provide at least 45Mb bandwidth in both directions,
    and SHOULD have at least 100Mb bidirectionally. (Note: Historically,
    bandwidth utilization peaked at 80Mb and averaged 35Mb."

and I found the "bidirectionally" part confusing to quickly understand.
I'm glad that it just says "both directions" now.

"The meeting facility The meeting facility SHOULD have UPS power"

Doubled words "The meeting facility"

" The IETF users MUST have access to the terminal room from ?? to ??."

I thought it was normally 24/7.

In general, I don't know what parts of the document are requirements on the
hotel/meeting space, and what parts are requirements from the IETF attendees
on the network.  Some of it reads like bits of an RFP to a contractor.

For instance, the requirement about a printer in the terminal room... I
thought that "we" normally just brought one.  Given physical drops and power,
that works fine.

Do we not now have physical drop requirements in the meeting rooms for
the chair table chromebook?  The drops for the A/V are mentioned already.
What about the RPI sensor nodes that report on wireless availability?

You asked if we are done running cables; I certainly have no idea, it's been
50 meetings since I was a NOC volunteer, but I thought it still happened when
it needed to.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]        |   ruby on rails    [

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-