On Wed, Nov 30, 2016 at 5:20 PM, Gregg Reynolds <dev at mobileink.com> wrote: > > > On Wed, Nov 30, 2016 at 3:44 AM, Kis, Zoltan <zoltan.kis at intel.com> wrote: >> >> I also fully agree with Thiago Macieira that a resource directory should >> be mandatory in an OCF network. >> >> I'm not sure what Thiago's proposal is but it seems to me that network > structure is clearly beyond the scope of a protocol specification. A > Resource Directory is an optimization; some networks need it, some don't; > it's not for the protocol to say. For example, a single client talking to > a single server is a network that obviously does not need an RD. >
The suggestion was not about the protocol, but about the OCF network. OCF aims to develop standards that solve IoT specific use cases in an efficient manner. Protocols are one aspect of this. Network architecture is as important for that. The 2-node example is an extremely rare use case. I don't know what is the typical size of an average OCF deployment, but looking at oneiota.org and the OCF specs, they seem to be written with larger deployments in mind. I blindly guesstimate in the range of a dozen devices per gateway at least. I would try to prioritize for that kind of deployment when optimizing, rather than corner cases. Even in a 2-node network services like resource/device directory can be implemented in one or both nodes (of course it must be an efficient implementation). The reason to do this (with the added complexity) is to simplify client apps and optimize network communication. Of course I'd like to have the protocols as efficient as they could be, but there are constraints, so I see network architecture recommendations (per use case) a necessity. That also implies the point that OCF specifications should be more explicitly use case driven, with clear association between recommended solutions and deployment context. Best regards, Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20161201/78f2e929/attachment.html>
