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

"Livingood, Jason" <Jason_Livingood@comcast.com> Mon, 01 July 2019 15:06 UTC

Return-Path: <Jason_Livingood@comcast.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 52BA61202DE for <netrqmts@ietfa.amsl.com>; Mon, 1 Jul 2019 08:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8kj0H82faRR for <netrqmts@ietfa.amsl.com>; Mon, 1 Jul 2019 08:06:49 -0700 (PDT)
Received: from copdcmhout01.cable.comcast.com (copdcmhout01.cable.comcast.com [162.150.44.71]) (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 7EDC11202FF for <netrqmts@ietf.org>; Mon, 1 Jul 2019 08:06:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1561993596; x=2425907196; 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=cl3KxL/XPh8owLoXuRZuBQz+94ol+RTnusvAp+tIM4A=; b=k49EN6rvC+vOHqzj9IR0nC4WjzRwBu5sOZZ3T6yFLMNZZGh1AAAJkEb88Y6xCT7d irrtQS7Tx3Yhii+yEApQf/zWLSdbAuRZoAnoQvoYVrPdEtU21Ltcm2s2IkrvCvRN A6MZbISL/skdPjpbS4Bv4V/8rROZHjrBIeMKRu0e3jEvgHKs1PSDcuwoBOAlLgJH KXe54YeuZ7mHYjUuAwPlMQ88RWjuPHGmhMDAMjwvfqyTbIFz1bJ+/Mgkj9Tdwx72 Y6aG2myQh+2buazsUUfOI2mqbKh8vh91LRR8KUihWirM9BXUehCqRGh3zfJMjj2Q yZ8R3RW29BKIPF8wZ27Ofg==;
X-AuditID: a2962c47-cebff70000021564-86-5d1a217c06dd
Received: from COPDCEXC35.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id D1.49.05476.C712A1D5; Mon, 1 Jul 2019 09:06:36 -0600 (MDT)
Received: from COPDCEXC37.cable.comcast.com (147.191.125.136) by COPDCEXC35.cable.comcast.com (147.191.125.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 1 Jul 2019 11:06:47 -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.006; Mon, 1 Jul 2019 11:06:47 -0400
From: "Livingood, Jason" <Jason_Livingood@comcast.com>
To: "netrqmts@ietf.org" <netrqmts@ietf.org>
Thread-Topic: [Netrqmts] Fwd: New Version Notification for draft-odonoghue-netrqmts-00.txt
Thread-Index: AQHVKrDGmHrpmxvRLUuLbCmjndaweqa159EA
Date: Mon, 01 Jul 2019 15:06:47 +0000
Message-ID: <EAE0AE0F-7600-4F15-852E-28C5618C8520@cable.comcast.com>
References: <156139623151.17526.10949752970398150427.idtracker@ietfa.amsl.com> <8960FB5C-10D3-4C6B-99FE-BFE08DC1B677@gmail.com>
In-Reply-To: <8960FB5C-10D3-4C6B-99FE-BFE08DC1B677@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.19.0.190512
x-originating-ip: [96.114.156.7]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D5CB5EDD5FB5A247BC0646D6DD0D97C5@comcast.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsWSUDRnsm6NolSswcYL1hbn/mxndWD0WLLk J1MAY1QDo01JRlFqYolLalpqXnGqHZcCBrBJSk3LL0p1TSzKqQxKzUlNxK4MpDIlNSezLLVI H6sx+ljNSehiymiav4e14JRVxbO2xawNjB2WXYycHBICJhKnjn5mB7GFBI4wSUx4WtTFyAVk NzNJPJ32ig3COcUosfJJHzNIFZuAmcTdhVfAbBEBbYmu4zeZQGxhgWiJM8s+sEPEYyQ+vvrN BGEbSVxpOcsCYrMIqEgcm9YBVMPBwSvgIjF/bj3E/EZGiR2Tt4LN5BSwlfg69wpYPaOAmMT3 U2vA5jALiEvcejKfCeJqAYkle84zQ9iiEi8f/2MFsUUF9CV+bL/JBhFXkOiZMJ0ZZBezgKbE +l36EGOsJK7M3MYKYStKTOl+CHYyr4CgxMmZT1ggWsUlDh/ZwTqBUWIWks2zECbNQjJpFpJJ s5BMWsDIuoqR19DMSM/Q1EDPxETP3HATIzChLJqm476D8cP52EOMAhyMSjy8MpxSsUKsiWXF lbmHGCU4mJVEePevkIwV4k1JrKxKLcqPLyrNSS0+xCjNwaIkzhvULBwrJJCeWJKanZpakFoE k2Xi4JRqYOSNspzOPceleEp3414Bif6Pl6eFHC/IXNowOfPn8efnF1l8tJR7JntSouqn1j6/ HTG6K494CQZ4bHg973zp1umtp8WEy+5aC5/ljwycI1LQF3OibdPhWX2rFun81V8yrY/7mCFb suXbHWI7Yw7N7FsUtqVQqEjkytSMXwttOM7IpgnUs020DVNiKc5INNRiLipOBABwx8unJAMA AA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/netrqmts/VWjhfrVQlejOjD-feTlgX-srLLQ>
Subject: Re: [Netrqmts] Fwd: New Version Notification for draft-odonoghue-netrqmts-00.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: Mon, 01 Jul 2019 15:06:53 -0000

As you update it to current practices, a few comments for your consideration. NO reply is needed, just take this as feedback:

Section 2:
1 - The bitrate should be listed as Mbps rather than Mb. I think I would also move the floor to 100 Mbps as a must and 1 Gbps as a should.

2 -  It will likely give us more options on the backup link if the bitrate was lower - maybe 100 Mbps. For example, it may be possible to get 1 Gbps via one fiber connection but secondary providers may use the same physical path. 

3 - Is Internet2 connectivity still a factor for meetings or can it be removed to simplify this list?

4 - Given IETF guidance for reverse DNS records for IPv6, can the bullet on reverse DNS be removed?

Section 3:
5 - The 1st two bullets say 2.4 Mhz instead of 2.4GHz (the latter is correct). But in any case, there's so much WiFi stuff happening these days, especially in 2.4 GHz, that the first two bullets should simply be removed.

6 - When you say 'congruency' I think you actually may mean 'concurrency'.

Section 4:
7 - Does the registration desk really need Ethernet or will WiFi suffice? I suspect the latter.

Section 5:
8 - The sentence "Terminal Room or equivalent A terminal room MUST be provided" does not make sense grammatically. Also, no one other than an IETF attendee will know what a terminal room is - and after all who uses terminals any longer. Maybe describe this is layperson terms that a room for quiet computer use with a printer, etc.

9 - Does the terminal room really need 100 - 150 Ethernet drops? I'm pretty sure WiFi will suffice and simplify things.

10 - Does terminal room access need to be 24-hour, given that at very odd hours there will be WiFi access elsewhere? And in facilities where the venue is not inside a hotel (e.g. a conference center), 24-hour access to go to a terminal room could be problematic.

11 - There is a bullet about trouble tickets which is general and should be moved out of the terminal room section.

12 - When was the last time we had security guards manning the doors to the terminal room? That should be removed.

Section 6: 
13 - Anything saying 802.11a/b/g needs to obviously be updated. And since the radios likely doing all the protocols, just combine all these into one -- e.g. no reason to vary which 802.11 protocol is available in a room vs. common area.

14 - Again with s/congruency/concurrency.

15 - Are you really doing separate SSIDs by 802.11 protocol? It seems the current practice (outside of IETF) is to use one SSID that supports several 802.11 protocols and then let the AP and client sort out which to use. Recommend the same here - which may necessarily mean also simplifying current IETF SSID naming. 

16 - You should update the secure SSID protocol specs (i.e. remove WEP).

Section 7:
17 - Why is an SMTP relay specified? Since access is unfettered there should be no need for a relay.

18 - Since our RFCs and I-Ds are hosted in a reliable manner, why must a local copy be kept on the network?

- Jason

On 6/24/19, 1:18 PM, "Netrqmts on behalf of kodonog@pobox.com" <netrqmts-bounces@ietf.org on behalf of kodonog@gmail.com> wrote:

    Folks,
    
    The draft -00 of the network requirements has been posted. Please note 
    this draft just represents what is currently on the webpage…
    https://www.ietf.org/how/meetings/admin/meeting-network-requirements/
    
    The NOC team is going to do a pass through this document to update it 
    for what we currently build to…
    
    Thanks,
    Karen
    
    Forwarded message:
    
    > From: internet-drafts@ietf.org
    > To: Karen O'Donoghue <kodonog@pobox.com>
    > Subject: New Version Notification for draft-odonoghue-netrqmts-00.txt
    > Date: Mon, 24 Jun 2019 10:10:31 -0700
    >
    > A new version of I-D, draft-odonoghue-netrqmts-00.txt
    > has been successfully submitted by Karen O'Donoghue and posted to the
    > IETF repository.
    >
    > Name:		draft-odonoghue-netrqmts
    > Revision:	00
    > Title:		IETF Meeting Network Requirements
    > Document date:	2019-06-24
    > Group:		Individual Submission
    > Pages:		9
    > URL:            
    > https://www.ietf.org/internet-drafts/draft-odonoghue-netrqmts-00.txt
    > Status:         
    > https://datatracker.ietf.org/doc/draft-odonoghue-netrqmts/
    > Htmlized:       
    > https://tools.ietf.org/html/draft-odonoghue-netrqmts-00
    > Htmlized:       
    > https://datatracker.ietf.org/doc/html/draft-odonoghue-netrqmts
    >
    >
    > 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 tools.ietf.org.
    >
    > The IETF Secretariat
    
    -- 
    Netrqmts mailing list
    Netrqmts@ietf.org
    https://www.ietf.org/mailman/listinfo/netrqmts