On Oct 11, 2016 7:03 PM, "Gregg Reynolds" <dev at mobileink.com> wrote: > > On Oct 11, 2016 2:29 AM, "Thiago Macieira" <thiago.macieira at intel.com> wrote: > > > > On segunda-feira, 10 de outubro de 2016 17:38:55 CEST Gregg Reynolds wrote: > > > consider the options: say, 2 networks NWA and NWB. each can have one or more > > > gateway nodes. Maybe you want some of the other nodes to support > > > internetworking, others not. should the other network itself be > > > representable as a resources? or should bridging nodes be invisible? I > > > guess I think this is a much larger hairball than the wiki proposals and > > > current implementation allow. > > > > Why do you want some devices not to find others? What's the use-case for that? > > > > no use-case needed. it's structurally possible, which is all we need to know, since we're talking about a protocol. if the protocol is underspecified, we're asking for trouble. > > > > one rather obvious problem: client sends a discovery message with RM option > > > ( i.e discover stuff on the other network cmd.) There are discovery options > > > here that are not currently addressed: > > > > > > 1. disover locally only > > > 2 discover remotely only > > > 3 discover locally and remotely > > > > Again, why? If a request is sent and it can be answered, it should be > > answered.
I think that glosses over the problem. whether a request "can be answered" depends on the protocol spec. I think you mean sth closer to "if it MUST be answered, then it should be answered." the RM "spec" is underspecified in this respect, IMO. The problem I see ensuring that the responses include addresses that > > the discovering client can address. As long as we're only doing IP, that's > > easy. For all non-IP connections, the GW simply operates like the Bridge that > > I described and creates an IP proxy resource. > > so here's a (possible) use-case: I want to draw a picture of my oic (inter-) network. I need to know which nodes are on which network, and what their roles are. > > Anyway my main point is that it is a mistake to treat every oic node as ipso facto a member of an internetwork. specifying oic internetworking is a completely different issue. and please note that the current proposal is not the only possible one. gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20161011/67c414be/attachment.html>
