Subject: [Int-area] Remarks on draft-winfaa-intarea-broadcast-consider-02

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 9 Sep 2016 15:02:48 +0200

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

---

From: Rolf Winter <[email-masked]>
Date: Thu, 15 Sep 2016 16:22:03 +0200

Hi Stephane,

thanks for the review. We just posted a new version incorporating your 
comments (see inline). We currently work on another version 
incorporating examples as suggested.

https://tools.ietf.org/html/draft-winfaa-intarea-broadcast-consider-03

> useful (you can pseudonymize them if you don't want to bash

The IEEE allows a copy of the accepted version (not the final version) 
to be posted on a personal and/or institution page. We did this, so for 
all of you that are interested in the findings, you can now download the 
paper and the presentation slides here:

paper:
http://net.hs-augsburg.de/docs/paper_trac_2016.pdf

slides:
http://net.hs-augsburg.de/docs/paper_trac_2016_slides.pdf

The next version will nevertheless contain examples as requested.

> the mailing list, URL, etc)

We have added this as a note into the document.

> problem is that the receiver group is unknown.

We added this.

> You never mention the RFC on privacy, RFC 6973, which is

Fixed.

> should be deleted. It is true but unconnected to privacy.

You are right. It is not the core of the document but important 
nevertheless. What we have done is we pulled that text from the main 
body and placed it at the end into a new section called:

"Other considerations"

> draft-ietf-dhc-dhcp-privacy has been published, as RFC 7819.

fixed

> RFC 7819 says "stable identifiers". May be using the same terminology

We use persistent identifier which also appears in RFC6973. RFC6973 also 
talks about the "persistence" of identifiers. We would stick with that 
term, as the document tries to align with the terminology used in RFC6973.

> authentified and proves nothing (see RFC 7593, section 2.1.1).

The SSID is potentially a poor choice of a configuration item but it is 
certainly better than nothing and the easiest choice to come up with. It 
will certainly protect you in cases where you e.g. allow broadcasts in 
your home network, but not in any other with a different SSID, to which 
you likely conciously attach your device to.

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>