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
