Re: [dnssd] Benjamin Kaduk's No Objection on draft-ietf-dnssd-prireq-05: (with COMMENT)

[Christian Huitema <[e-mail]>]

Ben,

I am trying to incorporate your feedback, but I have issues with two of
your points.

...
> Section 3.3.2
>
> This sort of problem frequently ends up with a third-party "trusted
> introducer", though it's not clear that mentioning this in the document
> will add value.

I would rather not say that, because people are also looking at P2P
pairing systems -- for example, let your phone read a QR code from the
the screen of your friend's laptop. As you say, we can leave that to
developers, we don't need to try add value.


>
> 3.4.2
>
> I'm given to understand that for many radio technologies, multicast is
> both effectively broadcast and has specific spectrum
> requirements/properties that make it especially scarce, compared to
> unicast spectrum.

I am not sure about the spectrum requirements. AFAIK, for Wi-Fi, unicast
and multicast operate on the same frequencies and the same channel.
Multicast requires transmitting at the lowest data rate acceptable for
all recipients, which means that the transmission of a multicast message
may last longer than the transmission of a unicast message, maybe much
longer, and that means occupying the spectrum for a longer time. On the
other hand, the same transaction using unicast would require several
messages, and that too creates requirements on the channel. I am
concerned that explaining the issue with fairness would require a long
development.

MDNS does rely on multicast, and writing something about the cost of
multicast would beg the question, what about MDNS? That's a fine
discussion to have in the DNSSD working group but, again, I don't think
the privacy requirement document is the right place for that.

Now, if you have a good citation, we could point at it.

-- Christian Huitema