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
Am 9/9/16 um 3:02 PM schrieb Stephane Bortzmeyer:
[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...)
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.
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)
We have added this as a note into the document.
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.
We added this.
You never mention the RFC on privacy, RFC 6973, which is
strange.
Fixed.
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.
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
permanent identifier
RFC 7819 says "stable identifiers". May be using the same terminology
would be better?
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.
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).
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 protected]
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
