[I'm not on intarea but I've been told there is a call for adoption going on; so here are my remarks.]
I've read draft-winfaa-intarea-broadcast-consider-02. I approve it, I hope it will be published as a RFC, but I have a few remarks. The lack of actual examples is a problem (Eliot Lear made the same remark on the list). Referencing the TRAC paper is not enough since, thanks to IEEE, it is not public. Giving a few examples would be useful (you can pseudonymize them if you don't want to bash Dropbox...) For the people who meet this draft and are not familiar with IETF internals, it would be useful to explain where to discuss it. (Name of the mailing list, URL, etc) > Broadcast and multicast messages have a large receiver group by > design. You mention several times "large". This is not the only issue, another problem is that the receiver group is unknown. You never mention the RFC on privacy, RFC 6973, which is strange. The second paragraph of 2.1 "Besides the privacy implications of frequent broadcasting, it also represents a performance problem" should be deleted. It is true but unconnected to privacy. draft-ietf-dhc-dhcp-privacy has been published, as RFC 7819. > permanent identifier RFC 7819 says "stable identifiers". May be using the same terminology would be better? > A lot of applications and services using broadcast protocols do not > include the means to declare "safe" environments (e.g. based on the > SSID of a WiFi network). I understand the problem but is the example correct? The SSID is not authentified and proves nothing (see RFC 7593, section 2.1.1). _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
