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

[Bob Hinden <[e-mail]>]

Joe,

Thanks for the feedback.  Inline.

> On Nov 22, 2019, at 12:16 PM, Joe Clarke (jclarke) <[e-mail]> 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.

Thanks,
Bob



> Joe
> 
>> On Nov 4, 2019, at 20:23, Livingood, Jason <[e-mail]> 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 <[e-mail]> on behalf of Bob Hinden <[e-mail]>
>> Date: Monday, November 4, 2019 at 6:13 PM
>> To: "[e-mail]" <[e-mail]>
>> Cc: Bob Hinden <[e-mail]>, Karen O'Donoghue <[e-mail]>
>> 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:[e-mail]
>> 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:[e-mail]>, "Robert M. Hinden" <mailto:[e-mail]>, "Robert Hinden" <mailto:[e-mail]>
>> 
>> 
>> 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
>> 
>> 
>> --
>> Netrqmts mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netrqmts
>