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

[Tim Wattenberg <[e-mail]>]

Thanks Bob. I added some comments as well.

> Am 20.11.2019 um 18:17 schrieb Bob Hinden <[e-mail]>:
> 
>> On Nov 17, 2019, at 2:53 PM, Tim Wattenberg <[e-mail]> wrote:
>> 
>> --- 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.“

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

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

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

>> 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?
> 
> I am not sure.  Other comments?
> 
>> "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?
> 
> I am not sure.  Other comments?
> 
>> --- 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 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.

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

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