[Netrqmts] Comments on draft-odonoghue-netrqmts-01

"Livingood, Jason" <Jason_Livingood@comcast.com> Tue, 30 July 2019 17:27 UTC

Return-Path: <Jason_Livingood@comcast.com>
X-Original-To: netrqmts@ietfa.amsl.com
Delivered-To: netrqmts@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3715812022D for <netrqmts@ietfa.amsl.com>; Tue, 30 Jul 2019 10:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=comcast.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id uuAJsMOuNqoK for <netrqmts@ietfa.amsl.com>; Tue, 30 Jul 2019 10:27:25 -0700 (PDT)
Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com []) (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 6916C120223 for <netrqmts@ietf.org>; Tue, 30 Jul 2019 10:27:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1564507644; x=2428421244; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Dxur5Mj3OUPVZsdeav8btMM+q0g9YtYdo2zrkWwoTsw=; b=BBktByvSdgav2heTrOozkXYsjwoZsqLCZ8QUX+Piplh2Ck3dncJ0oJ+EkEbvPaxT 8FnmhRnskTR9mIhz+KXNgeN2spNYEwfcaii3fqZnD6RYyuyxJcM3U7cqPAgEUx2o 2fY7VKmqw0Kc98P7r9DXKXCWUipUaTtkfeJ2vGj4SE+f2XYSgTW36zbUaKdkzqHH xlsGBhldfZUQ80xWqQcHRc9hWmfNc9Z2KPCBRsLY+Mbm1/s3ToNf5S/DNFWL8rN6 ixDtFUa/e4NP6r4MWcfaOy4+uGgxRbO0v8IbrMCt2bZxrkrHDS1Of29lqp+t2wkV V+74J+5Q+SXry2yYolB3+A==;
X-AuditID: 60729ed4-227ff700000013e0-41-5d407dfc532b
Received: from COPDCEXC37.cable.comcast.com (copdcmhoutvip.cable.comcast.com []) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 1A.87.05088.CFD704D5; Tue, 30 Jul 2019 11:27:24 -0600 (MDT)
Received: from COPDCEXC37.cable.comcast.com ( by COPDCEXC37.cable.comcast.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 30 Jul 2019 13:27:23 -0400
Received: from COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94]) by COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94%15]) with mapi id 15.01.1713.008; Tue, 30 Jul 2019 13:27:23 -0400
From: "Livingood, Jason" <Jason_Livingood@comcast.com>
To: "netrqmts@ietf.org" <netrqmts@ietf.org>
Thread-Topic: Comments on draft-odonoghue-netrqmts-01
Thread-Index: AQHVQ0FOTmuXRM7NFEa1xDGb8Xqy5KbjcZQA
Date: Tue, 30 Jul 2019 17:27:23 +0000
Message-ID: <B48CE7CE-6BAF-440C-9E75-E75C6C0BCC88@cable.comcast.com>
References: <65C5C0FC-62EC-4BE8-AA13-5459A861D5CD@cable.comcast.com>
In-Reply-To: <65C5C0FC-62EC-4BE8-AA13-5459A861D5CD@cable.comcast.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.1b.0.190715
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <14A9DB04536661428368D05D47B178B2@comcast.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42JJKJozWfdPrUOswavDVhbn/mxndWD0WLLk J1MAY1QDo01JRlFqYolLalpqXnGqHZcCBrBJSk3LL0p1TSzKqQxKzUlNxK4MpDIlNSezLLVI H6sx+ljNSehiylg6fzNTwQbVitV38hsYt6h0MXJySAiYSJx818LaxcjFISRwhEli7rRVUE4L k8Si3h/MEM5pRonLd38xg7SwCZhJ3F14BcwWEdCW6Dp+kwnEFhYwkDj0pIW9i5EDKG4qse14 AoRpJPF1ZSxIBYuAqsTJt/9YQcK8Ai4SF06XgoSFgMy1L7exg9icAq4Sz9t2gQ1kFBCT+H5q DZjNLCAucevJfCaImwUkluw5zwxhi0q8fAwykpNDVEBf4su5TSwQcUWJfR9WMIOsYhbQlFi/ Sx9ijJXEyscrGCFsRYkp3Q/B1vIKCEqcnPkEqlVc4vCRHawTGCVmIdk8C2HSLCSTZiGZNAvJ pAWMrKsY+SzN9AwNTfQMTS30jAyNNjGCk8m8KzsYL0/3OMQowMGoxMP7s9ohVog1say4MvcQ owQHs5II72Jx+1gh3pTEyqrUovz4otKc1OJDjNIcLErivHl7dWKFBNITS1KzU1MLUotgskwc nFINjM4u/C9MHq73/3f//qmsr6UuD3+s3CHw+1jjSv8wlfJlm9fHnHxlUaOfZhziJNe5O1kn trTXhO8gR91/m0rXo6cOW5Yq5j5gKijMOn31xmwFZxv5XrF5nt6r2JbG7HPdu8tUdNJz96da GTpdy6+L5vUEJpoLfLlwKysjL13qk8k3z9UrhT+vVWIpzkg01GIuKk4EAAZ4S1oiAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/netrqmts/9d2l6y5U7E2aOV3DytyztzoihT8>
Subject: [Netrqmts] Comments on draft-odonoghue-netrqmts-01
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, 30 Jul 2019 17:27:27 -0000

I sent separately to Karen last week and realize I did not cc the mailing list. Thus, I wanted to pass along some feedback regarding draft-odonoghue-netrqmts-01 for a future revision.
    Section 1
    - Strike “Version -00 represents the requirements as articulated the last time
       these requirements was documented by the IETF NOC Team
       requirements/).  The current draft plan is to update to a -01 that
       represents the requirements the IETF NOC Team currently builds to.
       Versions beyond that will represent input received from the
    - Add "These requirements are limited to the meeting venue, not any of the hotels at which IETF participants may stay during an IETF meeting. Any requirements pertaining to hotel guest rooms may be documented separately."
    Section 2
    - s/External Connectivity/Requirements for Connectivity to the Internet
    - Organized the bullets into groupings, such as Must-Have Requirements & Optional Requirements
    - Break up the bullets where the MUST ones go into the 1st grouping and the SHOULD/MAY ones go into the 2nd. This means some of them like the 1st bullet will have the 1st sentence in the MUST group and the 2nd sentence moved to the OPTIONAL group. (same MUST/OPTIONAL for all subsequent sections)
    - Move "Recent events have peaked at..." to be the lead text for this section (not a bullet). Remove the average, as it does not matter - only peak matters. And I would recommend not having the peak but 95% percentile or something like that -- use the measures that network operators use in interconnection agreements. And add something along the lines of "We expect peak bandwidth requirements to continue to grow at a roughly 40-60% CAGR." 
    - Seeing the thing on IPv6, I wonder if we need a section on IP addressing (maybe not) or at least a statement that we will bring our own IP address block and expect it to be announced & routed by the upstream provider(s). It sort of hints at that with BGP mentioned, but perhaps could be more explicit. 
    Section 3
    - Not sure the physical characteristics bit in the 1st bullet is realistic & achievable, and may need to be removed.
    - Spell out UPS power on 1st use with the acronym in parenthesis afterwards
    - The power requirement is definitely useful, as it would be if we needed datacenter power & space - same deal for meeting rooms and people w/devices. It seems good to provide, based on X participants, the total peak power demand. Past meeting venues such as in Montreal may have suggestions. The challenge is determining how many people are plugged in at any one peak time since batteries last so long these days. 
    Section 7
    - Are these services to be provided by the meeting venue? I don't think so - it is provided by our NOC, right? In which case maybe the title should be "Services to be Provided by the NOC".
    Section 10
    - Consider an optional SSID for someone to go behind a security device / firewall / malware protection border device?
    - Something to say that attendees MUST be able to use their personal VPNs / they should not be blocked or intercepted?
    - Do we need a privacy section saying we may collect netflow data but not collect PII other than in the short-term for troubleshooting (e.g. PCAPs)?