[dev] [cftg] RE: OCF IANA Port Number Assignment

[이재근]

HTML ?? ??...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: 201604211100821_QKNMBDIF.gif
Type: image/gif
Size: 13168 bytes
Desc: ?? ?? .
URL: 

[dev] [cftg] RE: OCF IANA Port Number Assignment

[Jon A. Cruz]

On Wed, Apr 20, 2016, at 07:00 PM, ??? 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.

It sounds like we need to get a good idea of what exactly the details of
your issue are. I've heard a few times that there is something that
needs to be addressed, and a belief of what a required solution is.
However, the problem itself has not been clearly communicated.

Can you fill in details of what the setup is, what should happen, and
what is happening instead?

--
Jon A. Cruz
jon at joncruz.org

-- next part --
An HTML attachment was scrubbed...
URL: 

[dev] [cftg] RE: OCF IANA Port Number Assignment

[이재근]

HTML ?? ??...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: 201604201755498_Z1SFOC32.gif
Type: image/gif
Size: 13168 bytes
Desc: ?? ?? .
URL: 

[dev] [cftg] RE: OCF IANA Port Number Assignment

[Thiago Macieira]

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.

[dev] [cftg] RE: OCF IANA Port Number Assignment

[최우제]

HTML ?? ??...
URL: 

[dev] [cftg] RE: OCF IANA Port Number Assignment

[최우제]

HTML ?? ??...
URL: 

[dev] [cftg] RE: OCF IANA Port Number Assignment

[최우제]

HTML ?? ??...
URL: 

[dev] [cftg] RE: OCF IANA Port Number Assignment

[최우제]

HTML ?? ??...
URL: 

[dev] [cftg] RE: OCF IANA Port Number Assignment

[Subramaniam, Ravi]

Hi Uze,

Thank you for your note. I understand the issue better.

Others have commented on the approach.

Let me explore something different with you. Since client rediscovering the 
server seems to be the problem, would it help to discuss how we can make this 
more efficient or reduce the impact? Maybe if we do a good job here then this 
need becomes less important.

Ravi Subramaniam
Principal Engineer
Intel - (408) 765-3566

On Apr 18, 2016, at 7:27 PM, ??? mailto:uzchoi at 
samsung.com>> wrote:

Ravi.
Let me explain the problem and requirement.
Core issue is not associated with multiple port.
When server reboot, client needs to discover thapt server again because port 
number is reassigned with different port due to random port assignment logic.
Requirement is that let the server device hold the same port number when it 
reboots.
As a solution, IoTivity can provide the api to set the port number to maintain 
the same port before. However there are two holes. One is complex 
implementation across multiple layers which are maintained by different 
development group. The other is that server application should handle lots of 
logic for port management.
As alternative solution, it is suggested to define the specific port which 
IoTivity assigns by default.
Multiple port is just consideration for multiple iotivity stacks in a single 
device.
This could be either OCF or IoTivity issue.
I wish you understand my requirement.

BR Uze Choi



---?? ???---
??? : Subramaniam, Ravi/ravi.subramaniam at 
intel.com
 : 2016/04/18 22:08 (GMT+09:00)
?? : Re: [cftg] RE: OCF IANA Port Number Assignment

Hi Uze,

I am not saying or suggesting that it is an Iotivity only issue.

I am suggesting that if I understood the problem correctly then may be spec can 
help with other approaches.

Ravi Subramaniam
Principal Engineer
Intel - (408) 765-3566

On Apr 18, 2016, at 12:12 AM, ???(Uze Choi) mailto:uzchoi at samsung.com>> wrote:

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:c...@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?)

[dev] [cftg] RE: OCF IANA Port Number Assignment

[Agerstam, Mats G]

Hi Uze,

I don't think reserving port numbers for the server instance is the right 
approach to mitigate the issue raised here. 

A platform can have several IoTivity instances running independently (one 
cannot assume SO_REUSEADDR) is applied to socket options, not assume that it is 
permitted/supported on the platform. That means that a sufficient range would 
have to be allotted. Also, device presence should allow for a client to detect 
and perform a rediscovery of a server under these circumstances. It seems to be 
that locally assigned port by the OS is the best choice.

Thanks,
   Mats

> On Apr 18, 2016, at 19:44, Thiago Macieira  
> wrote:
> 
> 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?
>>> 

[dev] [cftg] RE: OCF IANA Port Number Assignment

[최우제]

HTML ?? ??...
URL: 

[dev] [cftg] RE: OCF IANA Port Number Assignment

[최우제]

HTML ?? ??...
URL: 

[dev] [cftg] RE: OCF IANA Port Number Assignment

[최우제]

HTML ?? ??...
URL: 

[dev] [cftg] RE: OCF IANA Port Number Assignment

[Thiago Macieira]

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 

[dev] [cftg] RE: OCF IANA Port Number Assignment

[Thiago Macieira]

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 > > 

[dev] [cftg] RE: OCF IANA Port Number Assignment

[Thiago Macieira]

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 

[dev] [cftg] RE: OCF IANA Port Number Assignment

[Thiago Macieira]

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 

[dev] [cftg] RE: OCF IANA Port Number Assignment

[최우제(Uze Choi)]

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:c...@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:c...@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:c...@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:c...@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 

[dev] [cftg] RE: OCF IANA Port Number Assignment

[Subramaniam, Ravi]

Hi Uze,

I am not saying or suggesting that it is an Iotivity only issue.

I am suggesting that if I understood the problem correctly then may be spec can 
help with other approaches.

Ravi Subramaniam
Principal Engineer
Intel - (408) 765-3566

On Apr 18, 2016, at 12:12 AM, ???(Uze Choi) mailto:uzchoi at samsung.com>> wrote:

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:c...@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?)

[dev] [cftg] RE: OCF IANA Port Number Assignment

[Thiago Macieira]

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 

[dev] [cftg] RE: OCF IANA Port Number Assignment

[Subramaniam, Ravi]

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?)

[dev] [cftg] RE: OCF IANA Port Number Assignment

[Subramaniam, Ravi]

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:c...@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.