Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft

[peter van der Stok <[e-mail]>]

Hi Hannes,

I have had some feedback on the 3rd party registration and the use of 
con= parameter.
Third party registration is a "must" for building installation and 
people are counting on it.
It is especially (but not limited to) registering very small devices and 
sleeping devices.
There is an experimental installation in which 3rd party registration 
has been tried out with very positive results supporting the 
installation process quite naturally.

The experiment only concerns the functional aspects (that you 
challenged).
It is clear that the security aspects need to be considered in more 
detail.
However, it is generally considered that both the RD and the 
commissioning tool (3rd party) will not be (very) constrained. Some 
overhead for the larger tokens is certainly allowed.

I hope that we can conclude the discussion on the presence of 3rd party 
registration for the RD; and continue the security discussion.

Peter

Hannes Tschofenig schreef op 2018-05-09 10:20:
> Hi Peter,
> 
> I have not even looked at the con parameter but I wonder how well it
> can work in practice given firewalls and NATs...
> 
> Ciao
> Hannes
> 
> -----Original Message-----
> From: peter van der Stok [mailto:[e-mail]]
> Sent: 09 May 2018 09:03
> To: Hannes Tschofenig
> Cc: [e-mail]; Kovatsch, Matthias; Mohit Sethi; 
> [e-mail]
> Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name
> in RD draft
> 
> Hi Hannes,
> 
> I share your concerns, But there are some additional aspects.
> for 3rd party registration the con= is used.
> con= will also be used to indicate alternative transports. Suppressing
> con= seems really a waste in this stage.
> On the other hand, even suppressing con= for third parties, the anchor
> attribute also permits to refer to third parties. Removing the anchor
> attribute is cumbersome to say the least.
> 
> Possibly @others want to react.
> 
> For the moment using con= for 3rd party registration creates one
> registration at the time.
> The Authorization server can also in this case assign endpoint values
> and prevent ep value stealing.
> 
> I will try to get some concrete feedback on 3rd party registration. I
> will keep you informed.
> 
> Peter
> 
> Hannes Tschofenig schreef op 2018-05-08 13:20:
>> Peter,
>> 
>> I would personally feel more comfortable if we standardize
>> functionality that some people have gained some experience already. If
>> we don't involve the domain experts then we will most likely get it
>> wrong.
>> 
>> What about separating this functionality from the RD draft, reach out
>> to these companies, and then put the result of the investigations into
>> a separate document? There are some folks in the group who work
>> closely with indoor commercial lighting companies and they could for
>> sure help.
>> 
>> Ciao
>> Hannes
>> 
>> 
>> -----Original Message-----
>> From: peter van der Stok [mailto:[e-mail]]
>> Sent: 08 May 2018 08:22
>> To: Kovatsch, Matthias
>> Cc: Hannes Tschofenig; Mohit Sethi; [e-mail]
>> Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name
>> in RD draft
>> 
>> Kovatsch, Matthias schreef op 2018-05-07 18:09:
>>> Dear Hannes,
>>> 
>>> dear list
>>> 
>>> To my knowledge, third-party provisioning functionality is in
>>> particular used for lighting systems; maybe Peter can comment on 
>>> this.
>> 
>> On request, some background.
>> For buildings, the installation is done by installation companies with
>> their own tools and procedures.
>> Installation can be done in phases by different companies.
>> Their is at this moment not one general approach or installation
>> protocol.
>> 
>> The problem is that the architect and people around have produced
>> drawings with cabling and equipment situated at precise physical
>> locations in the drawing.
>> Equipment, cabling etc are identified with numbers ,names, what have
>> you.
>> There are descriptions which discuss the functionality and the
>> relation between the equipment.
>> All this knowledge has to be transferred to the equipment without
>> making too many "one of a kind" pieces.
>> In he "olde times" much was solved by the cabling, that limited the
>> control possibilities.
>> These IP times, anything can reach anything else.
>> One approach is to store parts of this information into the RD, which
>> can be queried by the equipment.
>> 
>> I hope this make the wish for an RD with third party access
>> understandable.
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose
>> the contents to any other person, use it for any purpose, or store or
>> copy the information in any medium. Thank you.
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.