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

From: Bob Hinden <[email-masked]>
Date: Mon, 4 Nov 2019 15:12:42 -0800

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: [email-masked]
> Subject: New Version Notification for draft-odonoghue-netrqmts-02.txt
> Date: November 4, 2019 at 2:48:49 PM PST
> To: "Karen O'Donoghue" <[email-masked]>, "Robert M. Hinden" <[email-masked]>, "Robert Hinden" <[email-masked]>
> 
> 
> 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 tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 5 Nov 2019 01:23:07 +0000

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 <[email-masked]> on behalf of Bob Hinden <[email-masked]>
Date: Monday, November 4, 2019 at 6:13 PM
To: "[email-masked]" <[email-masked]>
Cc: Bob Hinden <[email-masked]>, Karen O'Donoghue <[email-masked]>
Subject: [Netrqmts] Fwd: New Version Notification for draft-odonoghue-netrqmts-02.txt

Hi,

Thanks,
Bob

Begin forwarded message:

From: mailto:[email-masked]
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:[email-masked]>, "Robert M. Hinden" <mailto:[email-masked]>, "Robert Hinden" <mailto:[email-masked]>

Abstract:

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

---

From: Bob Hinden <[email-masked]>
Date: Tue, 5 Nov 2019 09:15:15 -0800

Jason,

Thanks, comments inline.

Bob

> On Nov 4, 2019, at 5:23 PM, Livingood, Jason <[email-masked]> wrote:
> 
> Looks good!
> 

Sure, should we also require that Native IPv4 be provided?  For example:

    Native IPv6 and IPv4 MUST be provided

> - What are "default free zones"? Not defined.

I could add a reference to

  https://en.wikipedia.org/wiki/Default-free_zone

> - s/DPI based/DPI-based

I will change to “Deep Packet Inspection (DPI) filtering"

> - Spell out acronyms on 1st use: BGP, IRR, RTBH (same for other sections later on)

Will do.

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

How about:

   o  The meeting facility SHOULD support the deployment of additional
      wireless networks including techniques to limit interference such
      as limiting radio power, software-based radio control, and or
      physical separation.

> - 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 G…

I think having this be more specific would be good.   Can someone suggest some text?

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

I checked with AMS, they need a wired drop for a printer.

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

I think it’s usually open before and after scheduled IETF meeting.  If we don’t want to have it open 24 hours, then 6am to Midnight might work.  We do have lots of jet lagged people at these meetings :-)

I wonder if we have any data on usage?

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

I think we usually just have a networked color inkjet printer.   They may even buy a new one before each meeting as it’s cheaper/easier to store/ship/maintain.

I propose the following to replace this and the following item:

   o  The terminal room MUST include a networked medium capacity color
      printer with duplex capability.

Perhaps citing what we are currently use might be helpful, and better define “medium capacity”.

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

I think it is used frequently, thought the NOC folks might have some data.  I have used it :-)

We have a range of people with various technical abilities in the IETF.  They often need this kind of support.

> - 4.2 - 1st bullet has an incomplete couple of sentences. Maybe the period was meant to be a comma?

Fixed:

   o  The network design MUST anticipate simultaneous usage of 100% of
      the projected number of attendees in each meeting room.  The
      number of wireless network users in excess of 1000 simultaneous
      wireless users has been observed during a plenary session.

That said, 100% is probably too low.  I would think it should be 200%.  For example, I have my laptop and phone on the wireless.   Apple watch type devices will increase that even more.  Maybe 250% is about right.

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

Good point.  How about:

   o  Online documentation MUST be provided to attendees detailing on-
      site network configuration information, including wireless
      configuration details, services available (e.g., printing),
      instructions on how to report network issues (e.g. trouble ticket
      system interface instructions), etc.  Initial versions of this
      information SHOULD be provided in advance of the meeting.  This
      should be provided on the IETF meeting website and distributed to
      attendies via email.

---

From: Tim Wattenberg <[email-masked]>
Date: Sun, 17 Nov 2019 14:53:19 +0800

Hi and sorry for the belated feedback.

> Am 05.11.2019 um 07:12 schrieb Bob Hinden <[email-masked]>:
> 

Bob, thanks for updating the document. The changes are much appreciated.

--- Section 2 "Requirements for Internet Connectivity“

I'd extend the bullet point "The provider(s) MUST allow the IETF to advertise (from the IETF AS number) the IETF IPv4 and IPv6 address ranges.“ with "There MUST exist RPKI ROAs for the address space announce by the IETF.“

I might misunderstand something, but could you point out the difference between "The transit provided […] MUST be capable of providing access to the IPv4 and IPv6 default free zones […]“ and "The provider(s) SHOULD carry and advertise full BGP tables.“?

Also, section 2 only talks about the measures the transit provider(s) are supposed to take. The IETF itself also can do (and probably does?) route filtering/OV. However, text for this would probably go into section 4?

"The provider(s) SHOULD implement BGP communities, especially the ability to RTBH.“
Besides from RTBH, do you have other use cases in mind to explain a little what you mean by this point?

--- Section 3 "Meeting Facility Requirements“

"All locations for network gear, with the exception of wireless APs, MUST be secure.“
I think that's *very* broad. Maybe we can add against what they must be secured (e.g. "[…] MUST be secured against unauthorized access“?).

> I think having this be more specific would be good.   Can someone suggest some text?

"[…] This includes at least one wired Ethernet connection (network drop) terminating in each meeting room, with ballrooms and larger meeting spaces as well as hallways and additional common areas having multiple network drops.“. Also, we should probably raise this to a MUST have, or adjust section 4 to be aligned.

You have a double "The meeting facility“ in the last bullet point if this section.

--- Section 4 "Internal Network Requirements“

Addition: "If not provided by the meeting facility, wired Ethernet connections (network drops) MUST be provided by the IETF NOC […]“.
To make it even more clear that section 3 talks about our requirements towards the meeting facility and section 4 talks about the different use cases within the IETF.

---

There is one additional thing I’d like to see mentioned somewhere:
"The network MUST NOT log or collect user payload data.“ (or something along those lines).

	– Tim

---

From: Bob Hinden <[email-masked]>
Date: Wed, 20 Nov 2019 18:17:36 +0800

Tim,

Thanks for the feedback.

Comments below.

Bob

> On Nov 17, 2019, at 2:53 PM, Tim Wattenberg <[email-masked]> wrote:
> 

Fair question, but I note that the first one also says:

   *  The transit provided in support of the IETF MUST be capable of
      providing access to the IPv4 and IPv6 Default Free Zones [DFZ].
      without the imposition of content filtering (e.g., URL, Site,
      application, port, or Deep Packet Inspection (DPI) filtering).

I think the important part of the first paragraph is “without the imposition of content filtering…”   We want an open Internet connection without any kind of filtering.  I think this is an important requirement.

> Also, section 2 only talks about the measures the transit provider(s) are supposed to take. The IETF itself also can do (and probably does?) route filtering/OV. However, text for this would probabl…

I am not sure.  Other comments?

> Besides from RTBH, do you have other use cases in mind to explain a little what you mean by this point?

I am not sure.  Other comments?

> I think that's *very* broad. Maybe we can add against what they must be secured (e.g. "[…] MUST be secured against unauthorized access“?).

I agree this should be more clear.   Please suggest text.

> "[…] This includes at least one wired Ethernet connection (network drop) terminating in each meeting room, with ballrooms and larger meeting spaces as well as hallways and additional common areas h…

Thanks, looks good to me.

> You have a double "The meeting facility“ in the last bullet point if this section.

That is fixed in my local copy.

> To make it even more clear that section 3 talks about our requirements towards the meeting facility and section 4 talks about the different use cases within the IETF.

I am not sure it is practicable for the IETF to run cables in venues these days.

> "The network MUST NOT log or collect user payload data.“ (or something along those lines).

Maybe we need to add a Privacy Section (or similar) to the document.

> 	– Tim
> 
> --
> Netrqmts mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netrqmts

---

From: Tim Wattenberg <[email-masked]>
Date: Wed, 20 Nov 2019 18:52:31 +0800

Thanks Bob. I added some comments as well.

> Am 20.11.2019 um 18:17 schrieb Bob Hinden <[email-masked]>:
> 

Just to be sure: Might you have missed this point?

> I think the important part of the first paragraph is “without the imposition of content filtering…”   We want an open Internet connection without any kind of filtering.  I think this is an importan…

Totally agree with you here. A subsequent observation I didn’t express before is, that one sentence uses MUST, the other one SHOULD.
To emphasize that we do not want any content filtering, how about:

"The transit provided in support by the IETF SHOULD/MUST carry and advertise full BGP tables and SHOULD/MUST be capable of providing access to the IPv4 and IPv6 Default Free Zone [DFZ]. The provider(s) MUST NOT impose any content filtering (e.g., URL, Site, application, port, or Deep Packet Inspection (DPI) filtering)."

(Please choose the desired requirements language.)

> I agree this should be more clear.   Please suggest text.

Other than the text I suggest in my original email, I’m not sure about additional security-requirements. Maybe the NOC can clarify and indicate whether my proposed addition misses something.

> I am not sure it is practicable for the IETF to run cables in venues these days.

Understood. If we do not run cables, I think we can drop this point since it should be covered in section 3 with the meeting facility requirements (or clarify it there).

> Maybe we need to add a Privacy Section (or similar) to the document.

Good idea. Who provides some text?
(I’d be happy to so, but I think I might not have sufficient insight.)

Thanks, Tim.

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Fri, 22 Nov 2019 04:16:02 +0000

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.

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

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.

Joe

> On Nov 4, 2019, at 20:23, Livingood, Jason <[email-masked]> wrote:
> 
> Looks good!
>

---

From: Tim Wattenberg <[email-masked]>
Date: Fri, 22 Nov 2019 13:02:26 +0800

Joe, thanks for responding. Some comments below.

> Am 22.11.2019 um 12:16 schrieb Joe Clarke (jclarke) <[email-masked]>:
> 

Personally, that’s perfectly fine with me. With my comments I didn’t meant to oppose any hurdles against running a reliable and functional network (as this is what we ultimately need).
But I think there is value in specifying just *what* is done (something along your lines)  – like a "privacy policy".
Let it be just as documentation for whom it is important (for personal or whatever reasons).

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

I tend to agree with you here. However, I also remember the BoF in Montreal where there actually *was* a detailed discussion around specific services.
In the end, it’s somehow a matter of taste if people like to have a very strict requirements document, or rather something more general.
(As said, personally I lean towards the latter – at least for a start.)

I’m sitting in the last Friday session, so:
Thanks to the NOC for yet another meeting!

	– Tim

---

From: Bob Hinden <[email-masked]>
Date: Fri, 22 Nov 2019 13:11:42 +0800

Joe,

Thanks for the feedback.  Inline.

> On Nov 22, 2019, at 12:16 PM, Joe Clarke (jclarke) <[email-masked]> wrote:
> 

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…

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

Thanks,
Bob

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Fri, 22 Nov 2019 07:09:25 +0000

> On Nov 22, 2019, at 00:11, Bob Hinden <[email-masked]> wrote:
> 
> Joe,
> 

Thanks.

>   Services.  This MAY include VMs or other techniques as appropriate.

That sounds good.  Sets some context while being flexible.

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

The best I could come up with is “…MUST be able to dynamically address clients”, which I admit is not good.  Maybe we can live with the DHCPv4 text as it is now and change DHCPv6 to MAY.

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

Thanks.

Joe

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Sat, 23 Nov 2019 03:40:23 +0000

> On Nov 22, 2019, at 00:02, Tim Wattenberg <[email-masked]> wrote:
> 

That makes sense.  I guess many would assume you’d have to do these things to diagnose network problems, but it’s best to be up front, especially with the fact that we do our best to destroy PII after its usefulness ends.

> (As said, personally I lean towards the latter – at least for a start.)

We wanted to provide _all the things_ in YUL.  But some of what we do, we do today because it makes sense and it’s entirely internally facing (meaning users aren’t aware).  We would like the flexibility to evolve in those areas as needed.  I’d rather the requirements doc focus more on  the user experience, only touching on engineering matters where it helps inform specific elements or that experience (such as explicitly stating single redundancy is required to ensure optimum uptime).

> Thanks to the NOC for yet another meeting!

You’re very welcome.  We love our jobs :-).  Thanks for the shout-out.

Joe