Hi, Agree with Pat on the separation of RD from proxy etc. Also we need to treat provisioning etc separately as capabilities - at deployment one may choose to put them on a single large device but this should not be required as the only way. Also there are some considerations for future specs to do this more generically on devices without a fixed RD.
Regarding discovery - there is already text on RD based discovery in the current Core TG spec. The intent of that text is to meet many of the objectives listed below. The current method in the spec allows any device to be a RD for discovery. Will be glad to discuss this proposal as and when required. Ravi On Mar 2, 2015, at 7:55 AM, Lankswert, Patrick <patrick.lankswert at intel.com<mailto:patrick.lankswert at intel.com>> wrote: Habib, Thank you for your proposal. I agree with you regarding the value and I have been interested in RD for some time. I proposed it in December to the PPRTG group but it did not receive enough votes to be prioritized. I am passing your proposal onto the architects and planners. We have two paths: 1) Get the standards group to add it to the roadmap. 2) Add it to iotivity without a standard definition If we add it to iotivity without a standard, we need to review your design and determine who will do the work. In any case, we need to check with the standards group first. BTW, I would like to separate resource directory, proxy and caching. However, we can talk about the design after we find that path and schedule for feature. Pat From: Habib Virji [mailto:[email protected]] Sent: Monday, March 02, 2015 7:00 AM To: Lankswert, Patrick Subject: Resource directory proposal Hi Patrick I am interested in proposing a Resource Directory (RD) as part of Discovery and Connectivity. Why resource directory ? Unconstrained device such as mobile can be asleep and may miss multicast query packets. ? Some devices cannot keep listening to multicast packets due to power constraint. ? For unidirectional communication, an IP address of the other entity holding resource has to be known. ? Power drain on the devices which cannot handle replying to multicast queries. ? RD can act as a server for provisioning, bootstrapping and access control list. ? RD can assist in being an interface for remote communication . RD can hold all local device communication and then act as an interface for remote device to connect to local device. What will it address ? Discovery of resources offered by a constrained server is very important in M2M applications where there are no humans and static interfaces are fragile. ? Allows lookups to be performed for those resources which are located on the sleeping node or has an issue with multicast traffic. ? Mechanism to provide single point of communication and provide functionality to allow: ? Services/resources information to be registered. ? Services/resources information to be queried. ? Resource directory can be used to register: ? Resource type ? Device type ? Will facilitate in local or remote discovery of resource. ? Registration and finding query at one single address. ? Will facilitate authentication and identification of devices. ? Will act as a resource broker for the remote devices to communicate with the local devices. Have worked on the full description of how RD needs to be implemented, URI schema to use for finding and querying RD. If RD need and what it can benefit to the OIC sounds pragmatic, will like to share and discuss further on the proposal. Kind Regards Habib
