Can someone elaborate on what a "hinting mechanism" is? If there's an API that allows me to configure locally used interfaces and ports, I would expect those to be used or get an error.
-----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Dave Thaler Sent: Monday, April 25, 2016 9:49 PM To: Thiago Macieira <thiago.macieira at intel.com>; cftg at openconnectivity.org; ashok.channa at samsung.com Cc: iotivity-dev at lists.iotivity.org; Wouter van der Beek (wovander) <wovander at cisco.com> Subject: Re: [dev] [cftg] Re: Re: [cftg] Re: Re: [cftg] RE: OCF IANA Port Number Assignment I agree with Thiago here. Dave > -----Original Message----- > From: cftg at openconnectivity.org [mailto:cftg at openconnectivity.org] On > Behalf Of Thiago Macieira > Sent: Monday, April 25, 2016 8:51 AM > To: cftg at openconnectivity.org; ashok.channa at samsung.com > Cc: Wouter van der Beek (wovander) <wovander at cisco.com>; Uze Choi > <uzchoi at samsung.com>; iotivity-dev at lists.iotivity.org > Subject: Re: [cftg] Re: Re: [dev] [cftg] Re: Re: [cftg] RE: OCF IANA > Port Number Assignment > > Let me repeat, once again: > > IANA-defined ports without a hinting mechanism so that each > application can suggest which port it wants to bind to is worse than the > current situation. > Applications may race to bind to the first port. > > If a hinting mechanism is present, then your problem is solved, > without requiring IANA assignment. > > On segunda-feira, 25 de abril de 2016 12:23:43 PDT ASHOKBABU CHANNA > wrote: > > When Out-Of-Proc model feature comes into IoTivity, it will solve > > multiple applications issue with IANA defined ports. Before that, > > define specific IANA ports help to resolve multiple discoveries of > > the same resources after every restart. > > Regards, > > Ashok > > ------- Original Message ------- > > Sender : Wouter van der Beek (wovander)<wovander at cisco.com> Date : > Apr > > 25, 2016 14:26 (GMT+05:30) Title : RE: [cftg] Re: Re: [dev] [cftg] Re: > > Re: [cftg] RE: OCF IANA Port Number Assignment one can define > > multiple IANA ports? but have more android apps than defined ports. > > Does not sound right to me. > > > > Kind Regards, > > Wouter > > > > From: cftg at openconnectivity.org [mailto:cftg at openconnectivity.org] > > On Behalf Of ???(Uze Choi) Sent: 25 April 2016 09:54 > > To: cftg at openconnectivity.org; iotivity-dev at lists.iotivity.org > > Subject: RE: [cftg] Re: Re: [dev] [cftg] Re: Re: [cftg] RE: OCF IANA > > Port Number Assignment This is reason why I requested multiple ports. > > Of course, in your case, IoTivity should increase the port until > > available port found. BR, Uze Choi > > From: cftg at openconnectivity.org [mailto:cftg at openconnectivity.org] > > On Behalf Of Wouter van der Beek (wovander) Sent: Monday, April 25, > > 2016 > > 5:51 PM > > To: ???(Uze Choi); cftg at openconnectivity.org; > > iotivity-dev at lists.iotivity.org Subject: RE: [cftg] Re: Re: [dev] > > [cftg] > > Re: Re: [cftg] RE: OCF IANA Port Number Assignment Well, if multiple > > android apps are used on the same port, that just will fail. Hence > > this is not an solution that will work.. > > > > Kind Regards, > > Wouter > > > > From: cftg at openconnectivity.org [mailto:cftg at openconnectivity.org] > > On Behalf Of ???(Uze Choi) Sent: 25 April 2016 02:25 > > To: cftg at openconnectivity.org; iotivity-dev at lists.iotivity.org > > Subject: RE: [cftg] Re: Re: [dev] [cftg] Re: Re: [cftg] RE: OCF IANA > > Port Number Assignment Hi Wouter, > > > > Because of Android and iOS, we should consider multiple applications > > which is same meaning to multiple OCF/IoTivity instances. For the > > multiple instance, device will requires the other port beyond coap > > default port (e.g., 5683). So that Let?s use the registered port > > rather than system randomly assigning port. > > BR, Uze Choi > > From: cftg at openconnectivity.org [mailto:cftg at openconnectivity.org] > > On Behalf Of Wouter van der Beek (wovander) Sent: Saturday, April > > 23, > > 2016 12:49 AM > > To: uzchoi at samsung.com; cftg at openconnectivity.org; > > iotivity-dev at lists.iotivity.org Subject: RE: [cftg] Re: Re: [dev] > > [cftg] > > Re: Re: [cftg] RE: OCF IANA Port Number Assignment How will the IANA > > registration help the sandboxed android apps? > > > > Kind Regards, > > Wouter > > > > From: cftg at openconnectivity.org [mailto:cftg at openconnectivity.org] > > On Behalf Of ??? Sent: 22 April 2016 14:18 > > To: cftg at openconnectivity.org; iotivity-dev at lists.iotivity.org > > Subject: [cftg] Re: Re: [dev] [cftg] Re: Re: [cftg] RE: OCF IANA > > Port Number Assignment Hi, I think Ashok (maintainer of > > discovrry&connectivity-CA layer) testing gives us important message. > > If we consider OCF application on Android or iOS which usually > > targets multiple sandboxed concept applications from market, > > multiple ports allocation for unicast socket channel is inevitable. > > Otherwise we need to restrict OCF/IoTivity into constraint device only. > > Furthermore Current IoTivity allocate the unicast port randomly > > which always open the possibility to invade non permitted area > > (port), which requires fix before commercial product release. I > > believe OCF/IoTivity should resolve the problem with IANA > > registration. Only left issue is whether we will request single port or > > multiple ports registration. > > IoTivity perspective it will be decided by Ashok who maintains > > connectivity layer. BR Uze Choi > > > > > > ---?? ???--- > > ??? : ASHOKBABU CHANNA > > ???? : 2016/04/22 19:44 (GMT+09:00) > > ?? : Re: [dev] [cftg] Re: Re: [cftg] RE: OCF IANA Port Number > > Assignment > > > > Hi, > > > > Yes. In my opinion registering to IANA like any other services ( > > http -80, allseen ..etc) makes more usability from user perspective. > > This makes sense to not to discover all the time about resource uris > > before operating.( if its not reachable, we will discover like normal > > scenario). > > It is possible that ipv6 gets new address, but its rare instance in > > home scenarios where IPV4 is used. And also for IPV6 if it can map > > mac address, it might not get changed as suggested. > > In our testing even we use reuse address, only the last binded > > application gets the unicast data. So it ruled out using a single > > unicast port. and Registering the port via API from developer makes > > confusion as we are supporting multiple transports which might not > > require port at all. API should not be transport specific from my > > view. > > Regards, > > Ashok > > > > ------- Original Message ------- > > Sender : Markus Jung<markus.jung at samsung.com> Senior Engineer/IoT > > Lab./Samsung Electronics Date : Apr 21, 2016 23:57 (GMT+05:30) Title : > > Re: [dev] [cftg] Re: Re: [cftg] RE: OCF IANA Port Number Assignment > > > > Hi, > > i agree to Thiago's suggestion. > > Additionally, I think that IoTivity should by default use only one > > port (e.g., 5683) and not split up different functionalities on > > multiple ports (e.g., only discovery on 5683 and data transmission > > on other ports - that's how it works now). I know this has > > implications on having multiple instances running on one device, but > > the default is to have only one instance per device. I think that is > > the root cause of the evil, that leads to the request of reserving a > > set of IANA port numbers ... BR Markus > > > > ------- Original Message ------- > > Sender : Thiago Macieira<thiago.macieira at intel.com> > > Date : Apr 22, 2016 02:53 (GMT+09:00) Title : Re: [dev] [cftg] Re: > > Re: [cftg] RE: OCF IANA Port Number Assignment > > > > Hello > > > > I've already answered, but I will repeat: > > > > We need an API in IoTivity to suggest which port number to use (a > > hint). A hint means that the code will do its best effort to achieve > > that, including ignore it. The IoTivity implementation should try to > > bind to that port; if it fails, it should try with port=0 so the OS > > will assign an arbitrary port. > > > > We need an API in IoTivity for the applicationto know which ports > > the stack is actually bound to, because it might be different from the hint. > > > > We do not need IANA-assigned port numbers. > > > > On quinta-feira, 21 de abril de 2016 02:00:15 PDT ??? wrote: > > > . > > > I tested on the several router-hub environment, no experience IP > > > changed in testing condition. You misunderstand my problem. > > > I don?t know, why we need to enforce the same IP after reboot. > > > I just want good solution in usual home router-hub condition. > > > I want solution to resolve my issue, but only discussion happen > > > without answer. > > > ------- Original Message ------- > > > Sender : Thiago Macieira > > > Date : 2016-04-21 00:26 (GMT+09:00) Title : Re: [dev] [cftg] RE: > > > OCF IANA Port Number Assignment > > > > > > > > > > > > Before we discuss that, do you have a plan for enforcing that you > > > get the same IP address after reboot? > > > > > > On quarta-feira, 20 de abril de 2016 08:55:24 PDT ??? wrote: > > > > Hi, All. > > > > > > > > > > > > > > > > I'm IoTivity client developer for TV and SmartThings Hub. > > > > We find issue in our product verification phase about > > > > re-discovery problem. > > > > We should re-discovery step after target device reboot. This is > > > > very inconvenience user exprience. This issue is critical. and > > > > It makes hard to release our product. > > > > > > > > > > > > > > > > Our product needs assigned port number to reduce re-discovery > problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------- Original Message ------- Sender : Thiago Macieira Date : > > > > 2016-04-19 15:20 (GMT+09:00) Title : Re: [dev] [cftg] RE: > > > > OCF IANA Port Number Assignment > > > > > > > > > > > > > > > > That's an IoTivity problem. We chose not to provide this functionality. > > > > > > > > We can change our choice. We don't need an assigned port number > > > > to change our minds. > > > > > > > > Em ter?a-feira, 19 de abril de 2016, ?s 06:16:45 PDT, ??? escreveu: > > > > > IoTivity has already api for port setting. > > > > > However it diesnit work and we had long discussion for this > > > > > api fix with John Light before. For the implementation choice > > > > > detail please refer to my today reply mail to Ravi. BR Uze > > > > > Choi > > > > > > > > > > > > > > > ---?? ???--- > > > > > ??? : Thiago Macieira/thiago.macieira at intel.com > > > > > ???? : 2016/04/19 14:59 (GMT+09:00) ?? : Re: [cftg] RE: OCF > IANA > > > > > Port Number Assignment > > > > > > > > > > We add an API to IoTivity that informs the port numbers > > > > > (plural, since we need two) that the application would want > > > > > the stack to bind to and an API that informs which ports the stack > > > > > bound to. > > > > > Applications that desire to use the same port number after a > > > > > reboot or a server shut down must record that port number > > > > > somewhere while the stack is in operation and will just inform > > > > > it again when it's starting up. Em ter?a-feira, 19 de abril de > > > > > 2016, ?s 05:23:55 PDT, ??? escreveu: > This proposal target > > > > > the server with single IoTivity stack. > I believe most of > > > > > cases will be matched with it. > > > > > > > > > > However, could you explain for port hint in detail? > BR, Uze > > > > > Choi > > > > > > > > > > > > > ---?? ???--- > ??? : Thiago > Macieira/thiago.macieira at intel.com > > > > > > ???? > > > > > : > > > > > 2016/04/19 13:43 (GMT+09:00) > ?? : Re: [cftg] RE: OCF IANA > > > > > Port Number Assignment > > Hi Uze Note that having > > > > > IANA-assigned port numbers without a hinting system > is worse > > > > > than the current state. Upon device reboot, two processes > > > > > could > race to bind to the known ports, which means the port > > > > > numbers could invert > from boot to boot. So now a client that > > > > > tried to reach the older service > would find a responsive > > > > > server but with a different service. That would > result in an > > > > > error to the requests. So we'd need to implement the port hint > > > > > > functionality I explained. But if we do that, we don't need > > > > > the assigned > port numbers from IANA. Em ter?a-feira, > > > > > 19 de abril de 2016, ?s 04:35:49 > PDT, ??? escreveu: > Hi > > > > > Dave, > > > > > > This proposal is not for hundreds percent > guarantee. > > > > > > During we develop the client application, we found that this > > > > > > will lessen the > rediscovery step after target device reboot. > > > > > Regarding > hint (I dont know > detail > > > > > yet) > > > > > I'm > > > > > welcome to contribution also. BR Uze > Choi > > > ---?? ???--- > > > > > > > ??? : > > > > > Dave > > > > > Thaler/dthaler at microsoft.com > ???? : > 2016/04/19 13:18 > > > > > (GMT+09:00) > ?? > > > > > > > > > > RE: Re: [cftg] RE: OCF IANA Port Number > Assignment > > We > > > > > should not have an IANA assigned port (at least for any > > > > > > reason we know of > now). If a device reboots, you can?t > > > > > assume the IP > > > > > > address is necessarily > the same, let alone the port > > > > > > number, > > > > > so the peer > must be prepared to > rediscover it from a > > > > > persistent stable id other than > the IP/port. > An app asking > > > > > to reuse the same port number as last boot is > fine, as long > > > > > as > > > > > > > > > > > it?s just a hint used for optimization, an app should > not > > > > > > rely on it > > > > > > > > > > being > granted. > Dave > > From: cftg at openconnectivity.org > > > > > > [mailto:cftg at openconnectivity.org] On Behalf > Of ??? Sent: > > > > > Monday, April > > > > > > > > > > 18, 2016 9:13 PM > To: thiago.macieira at intel.com; > > > > > cftg at openconnectivity.org > > > > > > > > > > > > Cc: iotivity-dev at lists.iotivity.org; > > > > > > > ravi.subramaniam at intel.com; > > > > > > > > > > > > > > > > > > > michael.koster at smartthings.com Subject: Re: Re: [cftg] RE: OCF > > > > > IANA Port > > > > > > > > > > > Number Assignment > > Hi Thiago, > Regarding hint I cannot > > > > > > assume clearly however, if you think about the port > > > > > > > designation api, it has some issue as I explained in mail > > > > > > for answer to > Ravi just little before. > > > > > > > > > > Originally > iotivity had a logic assigning the > specific > > > > > port before, we figure out > that this port is already > > > > > registered in > > > > > > IANA with different purpose. This > is the reason why we > > > > > change the logic > into random port number assignment. > BR > > > > > Uze Choi > > > ---?? ???--- > ??? : Thiago > > > > > > Macieira/thiago.macieira at intel.com > ???? : 2016/04/19 12:02 > > > > > (GMT+09:00) > > > > > > > > > > > ?? : Re: [cftg] RE: OCF IANA Port Number Assignment > > We > > > > > > don't need > > > > > > > > > > reserved port numbers with IANA for that. As I said before, > > > > > > any number is > > > > > > > > > > > fine if the implementation can remember which one it had > > > > > > > last. We can > > > > > > > > > > add > the API to IoTivity for the implementation to provide a > > > > > > hint on which > port number to use. This assumes that the > > > > > API can store the > port number > it last had. As a hint, if > > > > > the port number isn't available, the > > > > > > > > > > > implementation will just choose another. Em ter?a-feira, 19 > > > > > > de abril de > > > > > > > > > > > > 2016, ?s 02:54:42 PDT, ??? escreveu: > Hi Thiago, > I assume > > > > > > DHCP will > > > > > > > > > > work > > most of cases currently. > This proposal does not > > > > > intend to cover every > > case but just maximize the hit > > > > > > ratio. BR Uze Choi > > > ---?? > > > > > ???--- > > > ??? : Thiago Macieira/thiago.macieira at intel.com > > ???? : > > > > > 2016/04/19 11:44 > > (GMT+09:00) > ?? : Re: [cftg] RE: OCF > > > > > IANA Port Number Assignment > > Hi > > Uze > > I don't see how > > > > > reserving port numbers will help us in that > > scenario. > > > > > > > If a device is able to keep its IP address and port number, > > > > > > > then we don't > need reserved port > > > > > numbers: > > > > > any number is fine. If a device > > isn't able to > keep the > > > > > address or the port number, then rediscovery is > > necessary > > > > > and any > port number is also fine. > > I'll also claim that > > > > > > > having a finite range is harmful because it limits us > to a > > > > > certain number > > of instances running on a given IP address. > > > > > > > > > > > > Moreover, please note > that > IPv6 with privacy extensions > > > > > enabled, it's very > likely that the > device's > IP address > > > > > will change after a reboot (it's > possible to retain > the > > > > > > information and resume using a random IP if it's > still valid > > > > > after > a > reboot, but it's not required. Linux doesn't > > > > > implement > that, for > > example). > > > > > With > > > > > IPv4, it's even worse since the decision is taken > out of > > > > > > > the device's hands completely and relies on the DHCP server > > > > > > provisioning > > with the same address. > > Em ter?a-feira, 19 > > > > > de abril de 2016, ?s > 02:06:40 > PDT, ??? escreveu: > > > > > > > Currently IoTivity use random number, but > this logic > > > > > > > > > > causes issue from > > client application , which eventually > > > > > > requires > > > > > > > > > > > finding the server device > > again when target reboot. As far > > > > > > as I > > > > > > > > > > > remember Thiago also understood this > > requirement before. > > > > > > Discussion was > not for undiscoverable service. > > > > > > > > > > > ---?? ???--- > > > ??? > > > > > > > > > > Thiago > Macieira/thiago.macieira at intel.com > > ???? : > > > > > 2016/04/19 > > > > > > 00:38 > > > > > (GMT+09:00) > > > ?? : Re: [cftg] RE: OCF IANA Port Number > > > > > Assignment > > > > > > > > > > > > > > > > > > IoTivity > decided to use random port numbers and there > > > > > > > has been no > > > > > > > > > > > > discussion to > change that. The port number is assigned by > > > > > > the OS from > > > > > > > > > > any > > of the non- > privileged unused port numbers at the > > > > > time the > application > > starts. > > > > > We had an > > > > > inconclusive discussion about > > > > > > > > > > port number for services that > > > aren't discoverable, but > > > > > instead are > > > > > > > > > > well-known, like cloud services. > > > That discussion didn't > > > > > finish, so > > > > > > > > > > there are no conclusions yet. > > > > But > for now, we don't > > > > > need assigned > > > > > > > > > > > port numbers. > > > > Em segunda-feira, 18 > de abril de > > > > > > 2016, ?s > > > > > > > > > > 16:12:27 > PDT, ???(Uze Choi) > > > > escreveu: > > > Hi > > > > > > Ravi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ok, I got it, this could be IoTivity specific > issue. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > During reboot the device. most of case, > > > > > > > > > > > > > > > > IP > > > > > > > > > > > > > > > > > will be > > > > > > > > > > same in the > local > > > network. > > > > > > For the same > > > > > port, > there are two > approaches. > > > > > > > > > > > > > > > > > One, is to store the > previously > assigned port. > > > > > > > > > > > The other is to use registered port. > > > > > > > > > > > > > > > > > > > IoTivity have decided to use the registered port > for > > > > > > several reasons. > > > (second option) > > > > > > > > > > > > > > > > > > > > In this case I?m not > > sure to define the port name with ocf naming. > > > > > > > > > > > > > > > > > > > > > > > > > > BR, > > Uze Choi > > > > > > From: > > > > > cftg at openconnectivity.org > > > > > > > [mailto:cftg at openconnectivity.org] > > > > > On > > > > > > > > > > > > > > > > > Behalf Of Subramaniam, Ravi > > Sent: Monday, April 18, 2016 > > > > > 3:38 PM > > > > > > > > > > > > > > > > > To: uzchoi at samsung.com; 'Michael > > Koster'; 'Aja Murray'; > > > > > > > > > > > > > > > > > > > > > iotivity-dev at lists.iotivity.org; > > cftg at openconnectivity.org > Subject: > > > RE: > > > > > > > > [cftg] RE: OCF IANA Port > > Number Assignment > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Uze, > > > > > > > > > > > > I > > recognize that each > > > > > > stack for > > > > > > > > > > multiple instances may require an > > > > > individual port > > > > > (each instance does not always need to have individual > > > > > > > > > > port but let?s assume they do). I don?t understand why these > > > > > need to be > > > > > registered ports. Also what happens in a > > > > > situation where there are > more > > > > than the 5 instances > > > > > (wouldn?t we have issues because we would > have > run > > > > > > > > > > > > > > > > > out of reserved ports?) > > > > > > > > > > > > From what > > > > > > > I can > > > > > > > > > > > understand from reading the thread is that > > > > > > > > > > > > > > > > > > > > > > > > > > > > a) > > > > > There > are multiple stacks on a device ? each stack has its > > > > > own IP > > > > > > > > > > > > > > > > > > > > > > address > and port. > > > > > > b) The URIs are tied to the IP > > > > > > address/port. > > > > > > > c) So when the stack reboots and > > > > > gets a new IP > > > > > > > > > > > address, the URI that > the > > > Client has does not work > > > > > > because the > > > > > > > > > > client has the URI > associated with > > > the > > > older IP address. > > > > > > > > > > > > > > > > > > > > > d) So the > Client has to do resource discovery > > > > > > > > > > again and this > > > > > > > > > > causes all > > > the OIC > Devices to respond and Client has > > > > > to process all > > > > > > > > > > > the responses > > > to > > > > get the new URIs for this > > > > > > Client. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Did I > understand the issue correctly? If > > > > > > > > > > > > > > this is the > > > > > > > > > > objective then > > > there > > > > may be other ways to solve > > > > > this ?same > > > > > > > > > > objective?. If I have > > > > misunderstood, > > > could you > > > > > try explaining > > > > > > > > > > > again? > > > > > > > > > > > > > Ravi > > > > > > > > > > > > From: > > > > > > > > > > > > > > > > > cftg at openconnectivity.org > [mailto:cftg at openconnectivity.org] > > > > > On > > > > > > > > > > > > > > > > > > Behalf Of ???(Uze Choi) Sent: > Sunday, April 17, 2016 11:17 > > > > > PM > > > > > > > > > > > > > To: > > > > > > > > > > Subramaniam, Ravi ; 'Michael > Koster' > > > ; 'Aja Murray' ; > > > > > > > > > > > > > > > > > > > > > iotivity-dev at lists.iotivity.org; > cftg at openconnectivity.org > > > > > Subject: > > RE: > > > > > > > > [cftg] RE: OCF IANA Port > Number Assignment > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi > Ravi > > > > > > Could you > clarify your declaration of > > > > > ?same objective?? > > > > > > > This is proposed > for > > > > > multiple IoTivity instance(stack)s in a > single > > > device. > > > > > > > > Each > > > > > > stack needs to assign individual port. > > > > > > > BR, Uze > > > > > Choi > > > > > > > From: > > > > > cftg at openconnectivity.org > [mailto:cftg at openconnectivity.org] > > > > > On > > > > > > > > > > > > > > > > > > Behalf Of Subramaniam, Ravi > Sent: Monday, April 18, 2016 > > > > > 3:08 PM > > > > > > > > > > > > > To: > uzchoi at samsung.com; > 'Michael Koster'; 'Aja Murray'; > > > > > > > > > > > > > > iotivity-dev at lists.iotivity.org; > cftg at > > > > > > > openconnectivity.org Cc: > > > > > '???'; > > > > > > > > > > > > '??'; > > > '????'; '???'; > '???'; '???'; '???'; > > > > > > > rami.jung at samsung.com > > > > > > > > > > > > Subject: RE: > > > [cftg] RE: > OCF IANA Port Number > > > > > > Assignment > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Uze, > > > > > > > > > > > > > Shouldn?t we > > > > > > > > > > > > > explore > > > > > > > > > > other ways > of achieving the same > objective? I may > > > > > > > > need > > > > > > > > to understand the > details better .. but > this > > > > > > > > multiple > > > > > reserved ports use > > > > > > > > > > > > seems rather > heavy. > > > > > > > > > > > > > The idea > > > > > > > of using only > > > > > > > > > > fixed Device ID in > the URI as in the OIC > URI and > > > > > > > > resolving to endpoints in the transport > layer was meant to > > > > > > solve this > > > very > > > > > > > > > > > problem (multiple OIC > Devices or stack > instances on a > > > > > > single > > > > > > > > > > platform). > > > In > > > addition, > for the case > where > > > > > there are multiple OIC Device from a single > > > > IP/port, > > > > > the > device ID in the URI is used to select the right OIC > > > > > > > > > Device. > > > > > > > > > > > > > > > > > > > > > > > > > > Ravi > > > > > > > > > > > > From: > > > > > > > > cftg at openconnectivity.org > > > > > > > > > > [mailto:cftg at openconnectivity.org] On > > > > > Behalf Of > > > > > ???(Uze > > > > > Choi) > > > > > Sent: Sunday, April 17, 2016 10:46 PM > > > To: > > 'Michael > > > > > Koster' ; 'Aja Murray' > > > ; > > > > > iotivity-dev at lists.iotivity.org; > > > > > > > > > > cftg at openconnectivity.org Cc: '???' ; '??' > > > ; > > > > > '????' ; '???' > > > > > > > > > > > > > > > > > > > > > > > ; '???' ; '???' > > > ; '???' ; > > > rami.jung at samsung.com > > > > > Subject: > [cftg] > RE: OCF IANA Port Number > > > Assignment > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi > Michael, > > > > > > > > > > > > Let me extend the > > > > > > discussion > > > > > > > > > > channel > into > Core TG and IoTivity. This > > > sounds > > > > > > > > related with > > > > > > > > > > > specification > also. > > > > > > > > > > > > Michael, > > > > > > > > > > > > > > > > > > I > > > > > > > > > > > > > > > > > understand why we > separate the port for secure and > > > > > non-secure channel. > > > > > > > > > > > > > > > > However, > we need to avoid the consecutive port > > > > > > > > > > > number from > > > > > > > > > > non-secure > > > port > > > > to secure port as follows. > > > > > > > > > > > > > > > > From > > > > > > > > > > IoTivity start, stack will > internally assign the port number > > > > > by +1 > > > > > > > > > > > > > > > > > > increasing if port is already > occupied. > > > > > > So > > > > > > that port > > > > > > 4380 > > > > > > > > > > is > already occupied in the > non-secure mode, then stack > > > > > > > > will assign the > port 4381 which will > cause conflict with > > > > > port ?4381 UDP > > > > > > > > > > > > > > > > > - > > > > ocf-coaps-1? > > > > > > > Please update the final > > > > > > port > > > > > > > > > > proposal. > > > > > > > > > > > > > Proposal > > > > > > > > > > > > port > > > > > 4380 UDP > > > > > - > > > > > ocf-coap-1 > > > > > > > port 4380 TCP - ocf-coap-1 > > > > > > > > > > > > > > > > > port > > > > > 4381 > > > > > UDP - ocf-coap-2 > > > > > > > port 4381 TCP - ocf-coap-2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > port 7380 UDP - > ocf-coaps-1 (7380 is arbitrary > > > > > > > > > > number, please > > > > > > > > > > assign > > > appropriate > one.) > > > > > > port 7380 TCP - > > > > > > ocf-coaps-1 > > > > > > > > > > > > > > > > port 7381 UDP - > ocf-coaps-2 > > > > > > port > > > > > > > > > > > 7381 > > > > > > > > > > > > TCP > > > > > > > > > > > - > > > > > > > > > > ocf-coaps-2 > > > > > > > (more..port). > > > > > > > > > > > > > > > > > ?We may > > > > > > > > > > need to justify why we need > so many ports.? > > > > > > ? > > > > > Should we > > > > > > > > > > > describe why this is required? > > > > > > > > > > > > > > > > > > Ashok, > > > > > > > > > > > > > > > > > > > > > > > > > I?ll create on the issue on Jira > once port proposal is > > > > > > updated from > > > > > > > > > > > > > Michael. > > > > > > Please > handle it. > > > > > > From > > > > > > > the CA stack > > > > > > > > > > please > check whether it is > possible to assign the port > > > > > > > > incrementally with > separation between > secure port and > > > > > non-secure port. > > > > > > > > > > > > > > > > > > > > > > > BR, Uze Choi > > > > > > > From: > > > > > > > > > > > > > > > > > > Michael Koster > > > > > > > > > > [mailto:michael.koster at smartthings.com] > > > > Sent: Tuesday, > > > > > March 01, > > > > > 2016 > 7:50 AM > > > To: Aja Murray > > > Cc: > ???; ??; > ????; > > > > > ???; ???; ???; ???; > uzchoi at samsung.com > > > > Subject: Re: > > > > > > Introducing Uze Choi > > > > > - > > > > > IANA Port > Number Assignment > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > There are no legal obligations and > there is no cost. > > > > > > > > > > > > We > > > > > > > > > > should get > > > > consensus on what we want to do, so > it > > > > > would be great if OSWG and SWG > > > > agree on the > > > > > registration. > > > > > > > > > > > > > > > > > > > > > > > > > > > I guess my question is > if we really need 5 ports for > the > > > > > > same > > > > > > > > > > service. > > > IESG > > > makes it > clear that IP endpoints > > > > > are > > > > > > expected to multiplex users of a > > > service > on a port. > > > > > > I > > > > > understand we > want multiple service *instances* and > > > > > > > > each > > > > > > to have it's own port. > > > > > > > > > > > > > > > > > > > > > > > > > > > I would think we would > allocate one > > > > > > > > > > > > > > > non-secure port > > > > > > > > > > for testing but > > > mostly > > > would need > secure ports. > > > > > I would > > > > > > > > > > > propose to reserve one port each TCP > > > and > > > > UDP for > > > > > non-secure > > > > > > > > > > coap, and the other ports for secure coaps on both > > > > UDP > > > > > > > > > > > > > and > > > > > > > > > > TCP. By doing this we are actually requesting up to 10 ports > > > > > > and > > > > > > > > > > > > > > > > > > submitting 10 forms. We may need to justify why we need so > > > > > many > > > > > > ports. > > > > > > > > > > > > > > > > > > > > > > So specifically: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > port > > > > > > > > > > 4380 > UDP - ocf-coap > > > > > > port 4380 TCP - ocf-coap > > > > > > > > > > > > > > > > > > > > > > > > > > > port 4381 > UDP - ocf-coaps-1 > > > > > > port 4381 TCP - > > > > > ocf-coaps-1 > > > > > > > > > > > > > > > > > > > > > port 4382 UDP - ocf-coaps-2 > > > > > > port 4382 > > > > > > > > > > TCP > > > > > > > > > > - > > > > > > > > > > ocf-coaps-2 > > > > > > > > (and of we need more) > > > > > > > > > > > port > > > > > 4383 > > > > > UDP > > > > > - ocf-coaps-3 > > > > > > > > port 4383 TCP - ocf-coaps-3 > > > > > > > > > > > > > > > > port > > > > > 4384 UDP - ocf-coaps-4 > > > > > > > > port 4384 TCP - > > > > > ocf-coaps-4 > > > > > > > > > > > > > > > > > > > > > > > > > > Is this > what > is intended? Do we need to > > > > > > > > > > > > > make a request > > > > > > > > > > to review this? > > > > > > > > > > > > > > Michael > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Feb 29, > 2016, at 2:15 > PM, Aja Murray wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Michael, > > > > > > > > > > > > > > I would > > > > > > > > > > > still like to > > > > > > > > > > know if there is any cost or > legal implications > > > > for > > > > > > > > > > > > > reserving these port numbers, and if > we need OSWG and/or > > > > > > > > > > > > > SWG approval > > > > > > > > > > > > before deciding on them. > > > > > > > > > > > > > When > > > > > > > > the time > > > > > > > > > > comes, here is the address information you > requested for > > > > > > > > > > > > > > > OCF: > > > > > > > > > Mailing Address: 3855 SW 153rd > Drive, Beaverton, OR > > > > > > > > > 97003, > USA > > > > > > > > > > > > > > > > > > > > Email: > admin at openinterconnect.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > Aja > > > > > > > > > > > > From: > > > > > Michael Koster [ > > > > > > > > > > > > > > mailto:michael.koster at smartthings.com] Sent: Saturday, > > > > > > > > > February 27, > > > > > > > > > > 2016 > > > > > 5:25 PM > > > To: uzchoi at samsung.com > > > Cc: > > > > > ??? < > > > > > > > > > > > > jinchoe at samsung.com>; ?? < > > > > ashok.channa at samsung.com>; ???? > > > > > < > > > > > > > > > > > > > > > > > > > markus.jung at samsung.com>; ??? < > > > > > > > > > junghyun.oh at samsung.com>; ??? < > > > > > > > > > > > > > > jjack.lee at samsung.com>; Aja Murray < > > > > > > > > > > > amurray at vtmgroup.com>; ??? > > > > > > > > > > < > > > > > soohong.park at samsung.com>; ??? < > > > > > > > > jinguk.jeong at samsung.com> > Subject: > Re: > > > Introducing > > > > > Uze Choi > > > > > - > > > > > IANA Port Number Assignment > > > > > > > > > > > > > > OK, I > > > > > have a couple of questions before I fill out > the requests. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I > > > > > can make the OCF organization the > assignee, and I > can be > > > > > the contact. > > > > > > > > > > > > I > > > just need an address > and email for OCF. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > There are no contiguous blocks > of unassigned port > > > > > > > > numbers below > > > > > > > > > > > > 4380-4388. > > > Does it matter > what the port numbers > are? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also, IANA won't > assign a block of ports, each > > > > > > > > > > > > > port needs > > > > > > > > > > to have a > > > service > > > > name. > > > > > > > > > > > > > > > > > Why > 5 ports? How should we construct the > service names? I > > > > > assume they > > > > > > > > > > > > > are > > > > > > > > > > > > > > instances of the same OCF > CoAP service, so is it > > > > > > > > > simply > > > > > > > > > > > > > > > > > > > > > > ocf-coap-instance-1, > ocf-coap-instance-2, etc? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Are > multiple devices > distinguished by the device ID? If > > > > > the URIs are > > > > > > > > > > > > > discinct between > devices, do we need more than one port? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ports are > now assigned for use by one or > > > > > > > > > > > > > more transport > > > > > > > > > > protocols. > Will > > > we > > > > need to assign TCP use of > > > > > these ports as well? > > > > > > > > > > > > > > Do we need > > > > > non-secure ports in this new range? > > > > > > > > > > > > > > > > > > > Michael > > > > > > > > > > > > On Feb 24, 2016, at 5:26 PM, > > > > > > ??? < > > > > uzchoi at samsung.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Is it > standard stuff > or open source stuff > > > > > > > > > > > > otherwise > > > > > > > > > > common stuff? > > > > > > > Daniel and Jin > any opinion? > > > > > > > > > > > > > > > > BR Uze Choi > > > > > > > > > > > > > ---?? ???--- > > > > > > > > > > > > > > > > > ??? : Michael > > > > > > > > > > > > > > > > > Koster/michael.koster at smartthings.com ???? : > 2016/02/24 > > > > > > 22:57 > > > > > > > > > > > > > > > > > > > (GMT+09:00) > > > ?? : Re: Introducing Uze Choi > > > > > > > > > > > > We will require > an assignee and a contact for these. I can > > > > > be > the > > > contact, > > > to > answer questions from IANA > > > > > and track the > process. > > > > > > > > > > > > > > > > > > > > > However, the assignee should probably be > > > > > > > > > > > > > > > > > a > > > > > > > > > > persistent administrative > > > > role > > > at OCF. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Aja, who should be the OCF > assignee when we register > > > > > > > identifiers like > > > > > > > > > > > > > > > > port > > > numbers and > content formats with bodies > > > > > > > > > like IANA and > > > > > > > > > > > > IETF? > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > Michael > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Feb 24, 2016, at 5:39 > > > > > > > > > > > > > > > > > > > > > > > > AM, Michael > > > > > > > > > > > > Koster < > > > > michael.koster at smartthings.com> > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi > Uze, > > > > > > > > > > > > Sorry, I was > > > > > > > > > > > > checking into > > > > > > > > > > some > procedural > questions. It will require a > > > > > > > > separate application for > each port and > there is a review > > > > > process. I will > > > start the process > today. > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > Michael > > > > > > > > > > > > > > > > > > > On Feb > > > > > > > > > 24, 2016, at > > > > > > > > > > 2:07 AM, > ??????(Uze Choi) < > > > > > > > > > > > > uzchoi at samsung.com> > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Michael, > > > > > > > We should > > > > > > > > > > > > > > > > finalize the code by > > > > > > > > > > this week for > this upcoming IoTivity > > > > release. Could > > > > > you check it ASAP if > possible? > > > > > > BR, Uze Choi > > > > > > > > > > > > > > > > > From: > > > > > ???(Uze > > > > > Choi) [ > > > > mailto:uzchoi at samsung.com] Sent: > Tuesday, > > > > > February 23, > > > > > 2016 8:50 PM > > > > To: ' jinchoe at samsung.com'; ' > > > > > > > > > michael.koster at smartthings.com' > > > > Cc: > > > ASHOKBABU > > > > > CHANNA ( > > > > > > > > > > > > > > > > > > ashok.channa at samsung.com); > > > > markus.jung at samsung.com; > > > > > > ??? ( > > > > > > > > > > > > > > > > > > junghyun.oh at samsung.com); ???( > > > > > jjack.lee at samsung.com) Subject: > > RE: > > > > > > Introducing Uze Choi > > > > > > > > > > > > > Hi Michael, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As > > > > > > > > > > Jin > explained, I need to register the > port region for UDP > > > > > unicast > > > > > > > > > > > > > > > > > > > > > port > > > > for OIC(IoTivity) Server as > follows. > > > > > > > > > > > There are some > requirement for port assignment for > OIC > > > > > communication to > > > > > > > > > > > > > IANA. > > > > > > > As a UDP multicast socket, > IoTivity uses > > > > > Port > > > > > 5683 > > > > > which is CoAP > default > > > port registered in > IANA, > > > > > > > > > > > > > > > > and for unicast socket, > OIC stack(IoTivity) randomly > > > > > > assign the port > > > > > > > > > > > > > > > > > from > > > the system > currently. > > > > > > > Sometime, > > > > > single device can launch multiple OIC > instances which > > > > > requires > > > > > > > > > multiple unicast sockets assignment. > (multicast > > > > > > > > > socket > > > > > is shared > > > > commonly) > > > > > > > > > > > > > > > > > > > However, this > random port assignment policy > makes the > > > > > > > OIC client > > > > > > > > > > > > > > re-discover > whenever OIC server restart, which > is very > > > > > > > cumbersome > > > > > > > > > > task. > > > > > > > > > > > > > I propose the default > UDP > > > > > unicast port for OIC for example > 3333~3337, > > > OIC > > > > > > > > server > assign the port from 3333 always. > > > > > > > I > > > > > heard that you are the > person to know how to register the > > > > > port into > > > > > > > > > IANA > > > and > understand the related context. > > > > > > > > > > > > > > > > > > > > Could you > help me for this > task? > > > > > > > > > > > > > > > > > > > BR, Uze Choi > > > > > > From: ??? [ > > > > > > > > mailto:jinchoe at samsung.com] > > > > > > > > > > > > > > > > > > > Sent: Tuesday, February 23, 2016 7:45 PM > > > > > To: ???; > > > > > > > > > > > > > > > > > > > > > > > > > michael.koster at smartthings.com Subject: Introducing > > Uze > > > > > Choi > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Michael > > > > > > > > > > > > Let me > > > > > > > > > > > > > > introduce my > > > > > > > > > > colleague Uze Choi > > > > > > > > > > > > Uze Choi > > > > > > > > > > > > > > > > > > uzchoi at samsung.com > > > > > > > > > > > > who belongs to > > > > > SWG (Software > > > > > > > > > > > > > > > Center) & > > > > > > is a (?THE) core member of Samsung > > > > > IoTivity > activity. > > > > > > > > > > > > > He contacted me > > > > > with an issue > > > > > > > > > > > > > > > > > > > > & I > recommended to contact you in turn. > > > > > > > > > > > > > > > > > > > > > > > > > > In > > > > > > > > > > short he has > in mind > > > > > > allocating certain UDP port > > > > > numbers > > > > > > > > > > > (maybe 5) > > > > > > > for exclusive CoAP or OIC usage > > > > > > > > > > > > > > > > because > > > > > > > > > > > of the following. > > > > > > > > > > > > > One physical > > > > > > platform may > > > > > > > > > > have > multiple (logical) OIC > devices > > > > > > (i.e. > > > > > IoTivity instance), then > for unicast CoAP > message, > > > > > > > > > > > > > > > > a way for URI to differentiate each > instance is > required. > > > > > > > > > > > > > > > > > Right now IoTivity uses > different > > > > > > > > > > > > > > > > > port > > > > > > number for different instance > > > > > > > > > > > > > > > > > > > > but due to > dynamic nature of port > number assignment, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > upon rebooting, > sender may forget the > receiver's port > > > > > number > > > > > > > > > > > > > > > > > > > > > > > > > & have to find > it again. > > > > > > > > > > > > > It > > > > > > would help to > > > > > > > > > > assign a certain block > of UPD port number for such > > > > > > > > > usage. > > > > > > > > > > > > > > > > > > > We may ask IANA to > allocate 5 UPD port numbers > > > > > > > > exclusively for CoAP > > > > > > > > > > or > > > OIC > > > > usage. > > > > > > > > > > > > I > > > > > > recommended Uze Choi to ask you, Samsung > IETF expert, > > > > > > > > > > > > > > > > whether > the approach is feasible & > > > > > > > if so, > > > > > how to proceed in IETF & > IANA. > > > > > > > > > > > > > > > > > > > > > > > > > He will > send you a mail with more detail. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks in > advance for your kind consideration. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > best regards > > > > > > > > > > > > > JinHyeock > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <~WRD174.jpg> > > > > -- > > Thiago > Macieira - > > > > > thiago.macieira > > > > > (AT) > > > > > > > > > > > intel.com > > Software Architect - Intel > Open Source > > > > > Technology Center > > > > > > > > > > > > -- > Thiago Macieira - thiago.macieira > (AT) intel.com > > > > > > > > Software > > > > > > > > > > Architect > - Intel Open Source Technology Center > -- Thiago > > > > > Macieira > > > > > - > > > > > thiago.macieira > (AT) intel.com Software Architect - > Intel > > > > > Open Source Technology Center -- Thiago Macieira - > > > > > thiago.macieira > (AT) intel.com Software Architect - Intel > > > > > Open Source Technology Center -- Thiago Macieira > > > > > - thiago.macieira (AT) intel.com Software Architect - Intel > > > > > Open Source Technology Center > > > > > > > > -- > > > > Thiago Macieira - thiago.macieira (AT) intel.com > > > > > > > > Software Architect - Intel Open Source Technology Center > > > > > > > > _______________________________________________ > > > > iotivity-dev mailing list > > > > iotivity-dev at lists.iotivity.org > > > > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > > > > > > -- > > > Thiago Macieira - thiago.macieira (AT) intel.com > > > > > > Software Architect - Intel Open Source Technology Center > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > > iotivity-dev mailing list > > iotivity-dev at lists.iotivity.org > > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > > > > Best Regards, > > > > Dr.techn. Markus Jung > > IoT, IoTivity, OIC | IoT Lab > > Software R&D Center | Samsung Electronics Co., Ltd Mobile +82 10 > > 3304 > > 8502 markus.jung at samsung.com > > > > > > -------------------------------------------------------------------- > > -- > > ------ > > ------ Sr. Technical Manager, Software Architect. > > SRI-B, IoT Division/ IoTivity, Samsung Electronics Co., Ltd. > > +91-9880709710 > > -------------------------------------------------------------------- > > -- > > ------ > > ------ > > > > > > > > > > -------------------------------------------------------------------- > > -- > > ------ > > ------ Sr. Technical Manager, Software Architect. > > SRI-B, IoT Division/ IoTivity, Samsung Electronics Co., Ltd. > > +91-9880709710 > > -------------------------------------------------------------------- > > -- > > ------ > > ------ > > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
