Jay, Technically, as an open source project, the only vote that matters is the maintainer?s vote. However, I like to build agreement between contributors, architects and the standards folks when and where I can.
I like the feature. So, I think that the best next step is to get into some design details. I read through the feature description that Habib has sent, but I have not read any of the design details. Habib, BTW, have you read the CoRE WG Resource Directory draft (https://tools.ietf.org/html/draft-ietf-core-resource-directory-02)? Pat From: Jung-Hyun Oh [mailto:[email protected]] Sent: Thursday, March 05, 2015 3:22 AM To: Habib Virji; Lankswert, Patrick; Subramaniam, Ravi Cc: iotivity-dev at lists.iotivity.org Subject: Re: RE: RE: Re: [dev] Resource directory proposal Hi Habib, Thanks for your reply. :) Pat & Ravi, I think the Habib's proposal has Validity for the IoTivity Project. Before we move on to detailed discusion on the design & etc, could you share us what decision should be made? Do we have to let Planners know about this and make them to put this item so that IoTivity members could vote to priortize? I think it will be okey to start working on this item without voting, if all the maintainers & architect agree on this item to be added into the IoTivity project. Moreover, since Habib proposed this item, his team, maybe, is willing to work on this so there's no issues on who to do this. :) Anyway, I will be appreciated if you let us know your opinion for the next step. Thank you. Jay. ------- Original Message ------- Sender : Habib Virji<habib.virji at samsung.com <mailto:habib.virji at samsung.com> > Senior Software Engineer/SRUK-Open Source/???? Date : 2015-03-04 21:06 (GMT+09:00) Title : RE: RE: Re: [dev] Resource directory proposal Hi Jay Thanks Jay for reviewing the document and your suggestions. First, let's try not to map the "Resource Directory Service" itself with the "the Device with Resource Directory Service". If you're proposing a type of device which should have those features then I have no issue. Yes I am proposing a type of device that can host RD service. The idea is to keep RD service independent of the device, but device that can host must match certain criteria such as not go in sleep mode and be processing capable. Resource Directory(Look-up) : * Receive registration of the resources in remote & share information of these resources when requested. (* Information : Resource URI + properties) Resource Cache(Off-loading) : Cache the representations of the resources of the network & share information of these resources when requested. (* Information : Resource URI + Representation(Attributes) of the requested resource.) Resource directory (look-up) is covered in the proposal. Regarding resource cache, communication between the alternate RD and RD could be used as a communication between RD and RC too. RD can update RC about the resources and their representation. Both can live independently of each other. I will work out proposal for the remote cache in lines of remote directory (lookup) and update soon. If not, I think you need to separate the features that you want to have into atomic level, and select what features that you want to contribute.(Only RD or RD + etc ??) Yes they are extending functionality of the RD, they are RD+ or in a sense more as a secure discovery and connectivity. The reason I combined with RD is device acting as a RD could facilitate (considering it has processing power) additional functionality and act as a - Resource broker: It is similar to the proxy but for a remote communication. A remote device that wants to communicate with a local device, it communicates to one end point. A device before allowing remote connection does user authentication i.e. the user logins with OAuth2 on the local device that allows it connect to the remote server. The remote device communicates with the remote server and does user authentication. Once these authentication are performed, user?s remote device can fetch information about the resources from the RD. Since this device is the only authenticated point, it is the one that communicates with the local device and acts as a resource broker. Authentication is not part of the RD but discovery has to be performed only when authentication is performed and adjust accordingly. The end point *could* be device hosting RD. Local Device <== Resource directory == > Remote Server <== Remote device. - Device authentication: In terms of PSK, it could be used as device authenticating with each other i.e. device requesting and device hosting RD are authenticated before registering and fetching resource. RD does not just give out details but only to the devices that are authenticated. It is independent of the RD, but kind of functionality RD needs to work along with before passing out information. The RD service itself is not the proper one to execute Security related process. It is kind of overlap, authentication task is delegated to the security module but mentioned in the RD as the discovery has to wait till authentication is performed and the role of RD is wait or ensure till these steps are performed before passing the resource information. The other thing is, I don't think we need to define a extra multi-cast IP address for RD sevice. The multicast address (224.0.1.187) used for finding RD is similar to the one used currently for finding resources. It does not need extra multicast IP address for RD. RH being co-operable with RD I agree with you RH being co-operable with the RD, but also with RC. Thanks Habib From: Jung-Hyun Oh [mailto:[email protected]] Sent: 04 March 2015 05:00 To: Lankswert, Patrick; Subramaniam, Ravi Cc: iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> ; Habib Virji Subject: Re: RE: Re: [dev] Resource directory proposal Thanks Pat. :) And , I agree on your opinion(negotiate doing body of work & mark it as proof of concept,etc till it's ready to open). Habib, Let me add more of my opinions on your proposal. First, let's try not to map the "Resource Directory Service" itself with the "the Device with Resource Directory Service". If you're proposing a type of device which should have those features then I have no issue. (Refered the p.4 in your doc.) * Resource Directory(Look-up) : Receive regisration of the resources in remote & share information of these resources when requested. * Information : Resource URI + properties * Resource Cache(Off-loading) : Cache the representations of the resources one the network & share information of these resources when requested. * Information : Resource URI + Representation(Attributes) of the requsted resource. * Device Authentication : Need more information what this is.. * Resource Broker : Needo mroe information whiat this is... If not, I think you need to seperate the features that you want to have into atomic level, and select what features that you want to contribute.(Only RD or RD + etc ??) For example, RD service may have necessary secrete information of resources which has registered so that the requester ask RD to provide that information in order to prepare for the authentication or access control process, but the RD service itself is not the proper one to execute Security related process. The other thing is, I don't think we need to define a extra multi-cast IP address for RD sevice. As Ravi mentioned in his email, default "Resource Discovery" feature can be used by a client to discover the RD Service on the network with no issue. Moreover,since the RD feature is also portable to such devices with Non-IP connectivity, I prefer to make all the opions that we can choose in using features of IoTivity to be simple. Any thought? Thank you. Jay. ------- Original Message ------- Sender : Lankswert, Patrick<patrick.lankswert at intel.com <mailto:patrick.lankswert at intel.com> > Date : 2015-03-04 00:27 (GMT+09:00) Title : RE: Re: [dev] Resource directory proposal 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 <mailto: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 Jung-hyun Oh. IoT Solution Lab. | SW R&D Center | SAMSUNG ELECTRONICS CO.,LTD Mobile +82-10-9890-6731 | Beyond your imagination, Always Jung-hyun Oh. IoT Solution Lab. | SW R&D Center | SAMSUNG ELECTRONICS CO.,LTD Mobile +82-10-9890-6731 | Beyond your imagination, Always <http://ext.samsung.net/mailcheck/SeenTimeChecker?do=61dd5ae2e408a716f1344596f0f9cbc46028e2912ab81681f4561a64feab150a46f49c7f7f4ce1db1fdf754ed276bbedd8c023f270a836a153cb8b1934afabac2f6aaf3d92ded142cf878f9a26ce15a0> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150305/4002aa23/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/20150305/4002aa23/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/20150305/4002aa23/attachment.p7s>
