Hi, Separation of concern has been a design principle from the start and so agree with Pat. The second is that all the capabilities will be designed at the resource model level ? this keeps consistency across all the devices.
The current spec version represents ?Resource Directory? as one more way to combine the basic steps in resource based discovery i.e. as a 3rd party assisted discovery. Once the basic discovery mechanisms and remote requests/responses are implemented we can get a RD for free. ? This means that any device that has the resources can be a RD when needed and for as long as needed. The decision of which devices can be made a Resource Directory can be done at deployment or run time and need not be made by the manufacturer (a manufacturer can do that if they want but it is not required). Also this model allows for more than one device to be a RD at the same time and allows for distributed responses (and benefits that distribution can provide). Agree with Pat on the definition of cache for the most part (will have to look at if a cache is observable ? nonetheless a cache can observe). Proxy as defined below may be limiting (that is definitely a use case). We need to partition the notion of proxy into at least two other concepts based on how the ?proxying? is done. Thanks! Ravi From: Lankswert, Patrick Sent: Tuesday, March 3, 2015 7:20 AM To: Habib Virji; junghyun.oh at samsung.com; Subramaniam, Ravi Cc: iotivity-dev at lists.iotivity.org Subject: RE: Re: [dev] Resource directory proposal Habib, I am looking at separation from a services and code perspective. Ideally, a device designer should be able to look at the resources (RAM, CPU, flash, etc.) of the device and offer RD services and/or caching services and/or proxy services in any combination and with any limits OR as a client use any combination of services RD, caching, etc. It allows for use cases that we cannot anticipate now. In addition, if these service are not co-dependent, we can later update or replace one of the services without affecting the rest. BTW, we can change the terminology but this is how I am using the terms: ? Resource Directory ? offloading discovery to another device ? Cache (or push caching) ? offloading representation to another device like a temperature sensor that pushes the current temperature to another device so that it does not have to handle the requests or observation registrations ? Proxy (or designated proxy/gateway) ? Where a small device only accepts requests from a single big device (gateway) through which all other devices must send requests. If that does not make sense, let me know. We can exchange diagrams when we review the design. Pat From: Habib Virji [mailto:[email protected]] Sent: Tuesday, March 03, 2015 5:48 AM To: junghyun.oh at samsung.com<mailto:junghyun.oh at samsung.com>; Subramaniam, Ravi; Lankswert, Patrick Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: RE: Re: [dev] Resource directory proposal Hi Pat, Ravi and Jay, Attached is the initial design document. Will be interested in knowing group views. Currently it covers finding a device which is acting as a resource directory, registering and querying of resources. It also describes a resource directory backup which backup device when RD goes down. @Pat: - Regarding separation of resource directory and caching. Is it caching of resources or something else? I agree with you on proxy but would prefer it to be on same device acting as resource directory to ease in look up. @Ravi - Have tried keeping RD independent on which device it can be hosted. @Jay - Slide 5 covers the device on which RD can be hosted. It could be used as the basis for defining a rich device. - Regarding resource hosting and RD being merged, sounds pragmatic but RD should be on device which does not sleep and is probably always plugged in. But if RH is on the mobile, RD on mobile might not scale. Kind Regards Habib From: ??? [mailto:[email protected]] Sent: 03 March 2015 08:41 To: ravi.subramaniam at intel.com<mailto:ravi.subramaniam at intel.com>; patrick.lankswert at intel.com<mailto:patrick.lankswert at intel.com> Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>; Habib Virji Subject: Re: Re: [dev] Resource directory proposal One more opinion on the Ravi's idea which is "Any device can be a RD for discovery". I would like to scope down from "Any Device" to "Any Rich Device" Once we put lots of abilities even into the lite device, we may not have candidate lite devices which can execute IoTivity inside. Moreover, we are trying to make lite device connectable to other devices, not to make lite device smart. However, I think we need definituons of Rich & Lite device prior to this issue. After that, I think we may define or add more detailed device profiles in order to support such feature. :). Any thoughts? Thank you. Jay. ps. I'v corrected typos in the my previous mail :). ---?? ???--- ??? : ??? ???? : 2015/03/03 14:54 (GMT+09:00) ?? : 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 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 disagree on Pat's idea which is "Let Standard people to check". '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=61dd5ae2e408a7166017e176906072454bda12c47f01351ded81201521b94ff84e60fcf6aeb61df594c3b6ddffd7613bcb238d00164b0be48eeb9bec5ad9c75d326bbdfb2ea96a2fcf878f9a26ce15a0] [http://www.samsung.net/pt_images/C10/securityimage/MSI_20140516060336843.gif] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150303/b618046e/attachment.html>
