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

[Tim Wattenberg <[e-mail]>]

Joe, thanks for responding. Some comments below.

> Am 22.11.2019 um 12:16 schrieb Joe Clarke (jclarke) <[e-mail]>:
> 
> 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.

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

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

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