Jay, Hey, it is good to hear from you.
To all, I think that I agree on all counts. Let me add that if that standard group cannot pick this up now AND we have engineers that can work on it, we can negotiate to doing the body of work and mark it as proof of concept, experimental or draft. It would be useful to folks that want to use it now and educational to the standards group when they want to formalize it. However, (I am repeating myself) we need to get a response from them. Jay?s comments lead to another point. If we have really good separation of concern, it could speed development since we can break the work up across multiple groups. It needs some coordination since we will need all of the parts working together to demonstrate the use cases. Pat From: ??? [mailto:[email protected]] Sent: Tuesday, March 03, 2015 12:55 AM To: Subramaniam, Ravi; Lankswert, Patrick Cc: iotivity-dev at lists.iotivity.org; Habib Virji Subject: Re: Re: [dev] Resource directory proposal Hi all, I do agree on the basics of Pat's ideas on "Seperating the RD from Proxy & Caching". I think the Proxy & Caching feature would be a "User" of the RD, but RD itself. We need to define the actual meaing of these features, however, I think that the Proxy & Caching feature which uses the RD can be merged with "Resource Hosting" Feature. Since the main goal of the "Resource Hosting" Feature is to host remote resource on the network, it could be utilized to proxy the resource servers & cache the data of them with help of RD. (Of course, the hosting still should be able to do their work without RD) Base on this idea & co-operating with Protocol Bridge feature, we maybe to handle several serverl items more efficient way.... 1) Handle Requests from outside the local network(Cloud, etc..) 2) Handle Requests from the heterogenous protocol(AllSeen, MQtt, etc...) ... However, I have another Pat's idea on "Let Standard people to check" this proposal. 'cause "Determin Who Do the Work" still remains even though we make Standard People to Check this. :) Any thoughts? Thank you. Jay. ------- Original Message ------- Sender : Subramaniam, Ravi<ravi.subramaniam at intel.com <mailto:ravi.subramaniam at intel.com> > Date : 2015-03-03 03:56 (GMT+09:00) Title : Re: [dev] Resource directory proposal 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 _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev Jung-hyun Oh. IoT Solution Lab. | SW R&D Center | SAMSUNG ELECTRONICS CO.,LTD Mobile +82-10-9890-6731 | Beyond your imagination, Always </patrick.lankswert at intel.com <http://ext.samsung.net/mailcheck/SeenTimeChecker?do=61dd5ae2e408a7166017e176906072454bda12c47f01351df4561a64feab150a46f49c7f7f4ce1db1fdf754ed276bbedd8c023f270a836a153cb8b1934afabac2f6aaf3d92ded142cf878f9a26ce15a0> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150303/db1188c8/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150303/db1188c8/attachment.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7198 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150303/db1188c8/attachment.p7s>
