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

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

> On Nov 22, 2019, at 00:11, Bob Hinden <[e-mail]> wrote:
> 
> 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.

Thanks.

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

That sounds good.  Sets some context while being flexible.

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

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.

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

Joe