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

[Bob Hinden <[e-mail]>]

Tim,

Thanks for the feedback.

Comments below.

Bob


> On Nov 17, 2019, at 2:53 PM, Tim Wattenberg <[e-mail]> wrote:
> 
> Hi and sorry for the belated feedback.
> 
>> Am 05.11.2019 um 07:12 schrieb Bob Hinden <[e-mail]>:
>> 
>> 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.
> 
> 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.“?

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

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

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.


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

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


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