Hi Jay, Pay & Ravi, Yes we can work on this item and implement it if agreed upon.
Regards Habib On 05/03/15 08:22, Jung-Hyun Oh wrote: > Samsung Enterprise Portal mySingle > > *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> 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:junghyun.oh at samsung.com] > *Sent:* 04 March 2015 05:00 > *To:* Lankswert, Patrick; Subramaniam, Ravi > *Cc:* 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:junghyun.oh at samsung.com] > *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:habib.virji at samsung.com] > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150305/cf63b0da/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 13168 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150305/cf63b0da/attachment.gif>
