HI,

May be the best way is to write a CR to describe the changes U are seeking.

This way we can discuss and reach a conclusion.



I don’t think there is really much  controversy.

I think a CR will increase the participation in the discussion, and will lead to a decision.



Thanks

George





-----Original Message-----

From: oneM2M Technical Questions [mailto:[log in to unmask]] On Behalf Of Ray Xu

Sent: Tuesday, October 13, 2015 3:13 PM

To: [log in to unmask]

Subject: Re: Announced attributes in remote CSE



Thanks George.





I've checked the latest draft of above 2 docs:



[1] TS-0001 Functional Architecture-V2.2.0 [2] TS-0004-Service_Layer_Core_Protocol-V2_1_0



Basically the tables and description in regard of resource announcement have not changed since v1.x, at least not in obvious way I could tell. And the original matter in this thread still puzzles me.



After looking into the issue more closely, I convince myself two things:

1. Announced resource is a "shadow" of original resource (in Amazon IoT term). How to "shadow" is controlled by at and aa attributes of original resource.

2. Announced resource/attributes are interests of retriever of these resources, i.e., RETRIEVE/NOTIFY operation on announced resources.







    --------                     ---------------                          ---------------  announced   ---------- 

    | AE   |-------------->| Hosting-CSE |--------------->| Remote-CSE |------------>| AE/CSE |

    --------                     ---------------                          --------------     resource     ----------

                        Mca                                    Mcc                        

                                                                           



There is no need to limit the announced resourced when Hosting-CSE creates announcement resource on Remote-CSE, on behalf of originator AE. But the announced resources/attributes should be filtered out when AE/CSE retrieve announced resource from Remote-CSE, based on what attributes/resources originator AE wants to publish, specified in aa attribute.



As such, when Hosting-CSE creates announced resource on Remote-CSE, it's very similar to what AE sends CREATE request to Hosting-CSE, with at and aa attributes, except Hosting-CSE creates AEAnnc resource type, instead of AE resource. Remote-CSE would follow the create request and store the announced resource, with local ri, rn, aei, and node link to original resource on Hosting-CSE.



When other AE/CSE retrieve announced resource, Remote-CSE would filter out the attributes/resource based on aa attributes, and the MA/OA attributes in [1]. Basically all MA attributes would be published, regardless they are in aa or not; OA attributes would be sent in response if they are in aa attribute.



This would resolve the ri, rn reuse/conflict issue during resource announcement procedure in current standard.



Comments welcomed.



Regards,

Ray Xu



########################################################################



To unsubscribe from the oneM2M_TechQuestions list, click the following link:

https://list.etsi.org/scripts/wa.exe?SUBED1=oneM2M_TechQuestions&A=1



########################################################################



To unsubscribe from the oneM2M_TechQuestions list, click the following link:

https://list.etsi.org/scripts/wa.exe?SUBED1=oneM2M_TechQuestions&A=1