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
