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

["Joe Clarke (jclarke)" <[e-mail]>]

> On Nov 22, 2019, at 00:02, Tim Wattenberg <[e-mail]> wrote:
> 
> 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).

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

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

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

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

Joe