Hi Rolf,
On 9/2/16 2:38 PM, Rolf Winter wrote: > Hi Eliot, > > I though a bit more about what you said. I think the suggestions to > developers were clear in my mind but maybe aren't all that clearly > formulated. Here are the most important suggestions that I read from > the text: > > - Use IETF-specified protocols if possible > - Avoid using user-specified information inside broadcast/multicast > messages > - Avoid persistent IDs in messages > - If you really must use a broadcast/multicast protocol and cannot use > an IETF-specified protocol, then: > - Be very conservative in how frequently you send messages > - Seek advice from IETF-specifies protocols such as message > supression in mDNS > - Try to design the protocol in a way that the information cannot > be correlated with other information in broadcast/multicast messages > - Let the user configure safe environments if possible (e.g. based > on the SSID) > > > The reasoning for the above list is in the text of the document. I do like the above recommendations called out in one place. That's a very nice summary. If it were just a matter of clarity, I wouldn't be concerned about adoption, because you can fix that in the WG process. What I'm hoping for is a bit more texture to this. And so: > If we spell out the above more clearly*and add examples from our > experiments, w*ould you say the document is ready for adoption? That > is something we can also do once the document has been adopted as part > of the first revision. This. Get some good examples. I haven't reviewed your experimental results, but following a few common discovery mechanisms that both do and do not get it right would be useful. I would be particularly interested in situations where the end goal is entirely understandable, but the method used is just leaky. I would expect that in some cases, there may not be alternatives, and in some cases there may be, depending on the use of the information. Classing those cases and providing quite specific recommendations would be very useful. Eliot
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
