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

[Hannes Tschofenig <[e-mail]>]

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.