Subject: [Roll] Home Requirements Feedback

From: Jonathan Hui <[email-masked]>
Date: Tue, 11 Mar 2008 22:42:14 -0700

Overall, great set of use-cases that define the properties of a home
automation application. However, I would prefer to see any requirement
statements (e.g. MUST/SHOULD/etc) left for the Routing Requirements
section. I think it's better to first establish the nature of the
application before going into the requirements. Though, I do think
it's appropate to suggest what requirements are important to consider
in each scenario.

This leads into my next comment, I think there should be a section
(either in use-cases or following use-cases) that clearly describes
the expected operational architecture. For example, the node
architecture (processor, radios, power, etc.), how they are physically
laid out, what environments are they expected to be in (yes, I know,
in the Home, but is outside, inside, separated by concrete walls,
etc.). I would also fold the Traffic Pattern section (Section 5) into
this. Having a clear understanding of the operational architecture,
along with the use-cases, will make it very clear in what conditions
the routing requirements must be satisfied.

The draft does state a good set of requirements (e.g. latency,
node-join times, constrained routing, etc.). Though there are places
where I think the requirements are being over-specified. My feeling is
that these documents should state the functional requirements of a
dynamic routing protocol, but leave the "how" open to the
designers/implementors of such a protocol. For example, Section 5
seems to require optimal any-to-any routing that doesn't utilize a
tree. I don't think Requirement draft is the right place to make such
specific claims. Also, we should keep the requirements concise. No
need to have too much surrounding explanation if the earlier sections
are clear about the use-cases and operational scenario.

I understand the need for groupcast, but it's unclear to me how this
will be done within the IP architecture. Have you considered,
possibly, pushing such functions to the application-layer? What this
means is that the routing topology gives the necessary support to
implement groupcast at the application, but does not implement
groupcast directly.

Specific comments:

Section 3.1: At what layer does the reference to "broadcast" refer to?
IPv6 technically doesn't have a broadcast primitive. At the physical
layer, everything is broadcast.

Section 3.2: I understand the need to support latencies at human time
scales and that multiple paths may help meet those latency
requirements. However, I think we should leave the "multiple path"
requirement out of the routing requirements. Instead, we should let
the requirements combined with the failure model drive what the
routing protocol should do.

Section 3.3: I think it would be more useful to include some notion of
route discovery time here, rather than whether or not nodes are
scanning, discovering, refining, etc.

Section 3.4: Good example that could feed into the "architecture"
section.

Section 3.5: I think this requirement needs to be reworded into
something closer to "constraint-based" routing. The current wording
now leaves a bunch of questions in my mind. For example, what if
neighboring powered routers do exist, but do not support the latency
guarantees? Is routing through battery-powered acceptable in these
cases?

Section 3.6: Another good example that can feed into the operational
architecture section.

Sections 3.7 and 3.8: Looking forward to these.

Section 4: We should distill each requirement to a concise statement,
and leave any of the explanatory text to earlier sections.

Section 4.1: What do you mean by multiple scopes? The RFC 4007 has a
clear definition of what IPv6 scopes are, but I'm not sure this is
what you mean. Also, see my earlier comment about groupcast and
whether this should really be provided completely by IP.

Section 4.2: Good requirement.

Section 4.3: The mobility scenarios should be clearly stated in the
operational scenario section. For example, how do the nodes move
w.r.t. each other, how quickly, what kind of nodes are moving. Then we
get a clear understanding of what the convergence-time requirement
really is.

Section 4.5: It's good to provide some explanation of the expected
failure model (possibly in the architecture section). Is the goal to
converge if a single link/node fails? What if multiple of them fail,
due to some local interference?

Section 5: I think you're over constraining the requirements
here. There's already a latency requirement, so why constrain how
those latency requirements are met? It's the job the
designers/implementors to choose.

--
Jonathan Hui
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Wed, 12 Mar 2008 15:42:01 -0400

Hi,

As an author of 6LoWPAN routing requirements draft, I think ROLL I-Ds
are good source to discuss and share the thought, although 6LoWPAN
work is focusing on 15.4 only.

I also put my thought under Jonathan's review lines. I have a few
questions and comments in Requirements section.

On Wed, Mar 12, 2008 at 1:42 AM, Jonathan Hui <[email-masked]> wrote:
(snip)
> whether this should really be provided completely by IP.

'groupcast' is also not clear to me. do you want to say 'anycast'?

> Section 4.2: Good requirement.

The doc says "it may be preferable to choose a (potentially longer)
route via non battery powered devices or via battery powered that have
more energy."

This is related how you will keep neighbor list in your routing table,
and what will you use as routing metrics.
I also think this is an important requirements to design, but I think
it would be better if you state less philasophical way (sorry, if this
is not a right expression, please blame my english, if so). :P

> get a clear understanding of what the convergence-time requirement

I agree with Jonathan. I think I also have to change my draft, but it
would be good to see specific routing perspective of requirements for
mobility support, instead of 'support of mobility'.

> due to some local interference?

Yeah. it's a hard problem to solve. Nodes failuare can make isolated
island within the network. To solve this, with possibly endurable low
complexity for sensor nodes is not an easy task, I think. I'm not sure
it's a good way to state 'MUST' with the harsh requirements of 'few
hundreds of milliseconds'.

Section 4.6.
What does 'misbehaving node' node, you mean?

> designers/implementors to choose.

I'm not sure if you want to make another requirement in Section 5, or
just restate the importance of support the traffic pattern from the
application.

Thanks.

-eunah

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 13 Mar 2008 13:37:14 +0100

Jonathan, Eunah
 
Thanks for constructive and detailed comments.
I agree with you that the document goes too much into hard requirements.
 
Just a short comment on the groupcast issue:
The intention is to be able to instruct a number of lamps to turn on in a time correlated manner.
If limiting subnets to 255 nodes, you may address node individually with a (relatively) small bitmask
having one bit per node (255/8 = 32 bytes).
The user experience is significantly affected by light "popping up" in a room over say, 1 second.
Having many lamps in a group requires sending a (potentially) high number of singlecast messages - and remember:
in a wireless environment, you have no chance of knowing which of the nodes are close to the user.
 
I look forward to share comments with you gentlemen in the ROLL meeeting today and on the reflector in the time to come.
 
cheers,
  Anders

________________________________

From: [email-masked] on behalf of Eunsook "Eunah" Kim
Sent: Wed 12-03-2008 20:42
To: [email-masked]
Subject: Re: [Roll] Home Requirements Feedback

Hi,

On Wed, Mar 12, 2008 at 1:42 AM, Jonathan Hui <[email-masked]> wrote:
(snip)

Section 4.6.

Thanks.

-eunah

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 13 Mar 2008 06:10:46 -0700

Hi Anders,

> having one bit per node (255/8 = 32 bytes).

I'm not too clear on how you do this within the IP framework. IPv6 
multicast group IDs are only 112 bits. If we limited groups to 112, I 
guess each node could subscribe to any multicast group that has its own 
bit set. But then how do you address different nodes in different 
subnets? The IPv6 multicast address doesn't have a notion of subnet, 
only scope.

So my real question, in short, was whether you are intending to see 
groupcast implemented at L3 or is it really something that sits at the 
application layer (possibly with some support from the underlying 
routing topology).

---

From: Mikko Saarnivala <[email-masked]>
Date: Thu, 13 Mar 2008 15:29:34 +0200

Hi Jonathan,

> application layer (possibly with some support from the underlying 

This was actually my initial thought also. My personal opinion is that 
it's clearly something for the application layer as the information of 
the type of the device would be there. My point is that we wouldn't want 
the L2 or L3 to care anything whether the device is a lamp, smoke 
detector or you-name-it.

Hope that made some sense :)

Best regards,

-- 
Mikko Saarnivala

---

From: "Gopinath Rao Sinniah" <[email-masked]>
Date: Thu, 13 Mar 2008 21:53:16 +0800

I agree with Jonathan on the use-cases that are defined. I believe that
there would be more uses-cases which can be defined now and in the future
which are not covered in the draft. My suggestion is instead of specifically
mentioning the uses-cases in the draft, these can be grouped based on the
characteristics and functions of the use-cases. The reason for this is we
might encounter new use-cases which cannot be included in the draft and by
defining the groups, the new use-case can fall in any of the group.

The examples of the use-cases can be explained in detail in the group itself
and not separately.

--gopinath

---

From: Vincent Rossi <[email-masked]>
Date: Thu, 27 Mar 2008 08:48:35 +0100

Hi everyone,

First of all, thank you Anders for this first draft. It really helps 
writing down some specific requirements for the home automation routing 
over L2N.
I would like to add my contribution to this work. It will be divided in 
two parts.
First, I will make some comments on the current draft (and discuss about 
the comments made by others).
And finally, there is an other example/use-case that I really would like 
to appear in this draft (but even if it is a draft, the issue should be 
discussed first).

Concerning my comments, I totally agree with the idea of the group-cast 
even if it is also not very clear to me how it would be implemented (cf. 
previous comments).

About the routing protocol, I understand that this draft is oriented 
toward an inner network for the house only but it appears (c.f. Section 
3.6) that a need to connect to a wider network (e.g. Internet) will be 
required for some devices. I simply wonder how the bridge will be 
established between our network (with a wide variety of devices...) and 
the house's Internet connection. Of course, the routing can be handled 
by a more powerful unit but I think it should be stated how this should 
work (one gateway, multiple gateways...).

Furthermore, considering this approach, I think it would be nice to be 
considering sharing part of the house's state with some well-known 
entities (electricity provider, surveillance companies...), this also 
implies further thinking about the security layer of such networks.

Considering the location of the devices, as asked by Jonathan, I tend to 
think that we must take into consideration the physical and 
environmental restrictions due to the devices that will be deployed in a 
"hostile" environment. I mean that devices located outdoor may suffer 
harder radio perturbations (thicker walls with iron structure...), rain, 
variation in temperatures, all altering the battery's lifetime (and so 
much more). So a question would be: how should we deal with such 
devices? Should we prevent them to be part of a route? Should they 
forward packets?
The idea of a gateway between the Internet and the WSN seems to be 
broadly accepted. We may see several of these gw providing links to the 
Internet and management capabilities to the WSN. This reduces SPOF and 
also provide new routing issues.

About Gopinath's contribution (about the categorization of use-cases), I 
think that it would also be clearer to separate the use-cases and try to 
group them by routing topology/goal/problems. The problem is that if we 
get more and more use-cases, some of them won't probably fit in one 
particular category. I think that the use-cases must be more like 
concrete examples illustrating a particular problem about routing within 
a house (which is exactly what they are right now).

Another remark would be about the automation itself. All of the 
use-cases are oriented toward the user, providing services, often in 
response to a certain input from the user (except for the networked 
smoke alarm). I also think that future applications of home automation 
should tend to be discrete and seamless. I think that the best embedded 
systems are those you can forget about. Of course, some use-cases are 
very interesting but instead of needing the users input, some can be 
automated (especially, section 3.1 and 3.4) by a device located 
somewhere on the Internet. Is this changing the routing requirements and 
policies?

Considering the important point of energy consumption (stated in 3.5 
about the ability to change the battery), I also think that in the aim 
of an "intelligent" house (I guess we can call it like that), the 
technology should not be visible. And this rises the problem of changing 
batteries for some devices. Even if we can think about a couple of years 
of operation on a single battery, we must think about how the routing 
protocol should handle the powering state of the nodes. I mean, this 
issue has already been covered in section 4.2 in the case a node cannot 
be part of a route, but if a node is truly dead, there is a good chance 
we never know about it (because another route will be used). I think 
that a change in the route used must be considered as an anomaly as long 
as they are not repetitive. It is a real and hard problem. If a change 
of route occurs from time to time, we can assume it is because of human 
activity (like described in the middle of section 2), but if it is a 
longer route change, there are 2 main problems, first, there is a good 
chance we do not keep track that the route has changed, and then, it may 
be because a node is "dead", or simply because the node has been 
removed. My question would be how the SNMP protocol should be supported 
on such a network and/or, should this matter be raised to the 
application level. Nevertheless, it is, according to me, an important 
issue and we should really discuss it.

This leads to another comment (again!). Considering this draft is about 
routing, I think that we should define the routing elements that can 
appear in such environment. It has already been started in section 4.2 
but I think that maybe we can define some specific devices for the 
network topology (like it exists in wired networks).

Actually, I can see 3 types of devices:
-sensors, which are more likely to send status but not receiving 
anything (no need to listen to the radio traffic)
-actuators, which will probably only receive orders but may also send 
their status/result of action, through the network
-routers-forwarder, which are only designed to reach some dark areas of 
the network
Of course, some devices may be using a mix of these primary features.

Should they all have an IP address ? or just the micro-controler ? 
Should we stay with FFD and RFD restrictions ?
I would like your opinion on such a partition of the devices abilities. 
I think it would help hardware and software design to help achieve the 
goal of an efficient routing in the home.
Considering the network as a graph could we assume the information is 
transmitted one way, two ways...

Another comment would be about the addressing. As you probably know, the 
current motes are providing multiple way to interact with the 
environment (may it be with sensors, actuators...), but often, there is 
only one network interface and then, only one network address, but how 
about we only want to access one sensor on a mote which possesses many? 
Should the packet contain the sensor ID or can we think of a protocol 
that could address directly to a particular sensor/actuator without the 
help of an embedded DB? I mean that we might want to access not only a 
mote but a particular sensor from a mote, without pushing this to the 
application layer. This could result in a very efficient way to 
access/collect data we want and prevent use of the micro-controller of 
the mote for treating many packets and gathering information from sensor 
we do not want information.

And at last, this is the use-case I propose for this draft: it concerns 
energy efficiency in the home.
Considering the increasing need of reducing power consumption on the 
planet, home automation may be use to optimize energy consumption. This 
said, there would be several ways to do so. First, activating the 
windows shades without user intervention based on the solar energy 
available to heat the house, even if no one is actually in the home. 
Another way would be to set some levels of heating, room by room  and 
thus there we need the group-cast functionality, based on current 
temperature, moment of the day and other pieces of informations, 
provided by the sensors in the home and/or even from the Internet.
The main aspect of this application, which is quite similar to the one 
described in section 3.1, is that it should appear seamless to the user. 
Another extension would be to forward the information from the sensors, 
not directly but after some computation, to the services providers such 
as gas, water and electricity ones so that they can adjust the supplies 
furnished to the home and therefore, reduce the power consumption based 
on estimation of need.
The routing protocol should then be designed so that sensors are able to 
gather their info, transmit them to a or multiple central unit(s), and 
then, after following some model, action can be taken and orders 
distributed among actuators. Some simpler decisions can be taken by the 
sensor itself and transmitted directly to the according actuator. About 
the part on transmitting the information outside of the house, there 
must be a way to communicate securely between the inner network and the 
Internet.

Thank you if you have successfully come this far and read everything,
I can't wait for your (numerous) replies :)

Vincent

Gopinath Rao Sinniah a écrit :
> I agree with Jonathan on the use-cases that are defined. I believe 
> that there would be more uses-cases which can be defined now and in 
> the future which are not covered in the draft. My suggestion is 
> instead of specifically mentioning the uses-cases in the draft, these 
> can be grouped based on the characteristics and functions of the 
> use-cases. The reason for this is we might encounter new use-cases 
> which cannot be included in the draft and by defining the groups, the 
> new use-case can fall in any of the group.
>
> The examples of the use-cases can be explained in detail in the group 
> itself and not separately.
>
> --gopinath
>
> On Wed, Mar 12, 2008 at 1:42 PM, Jonathan Hui <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Pieter De Mil <[email-masked]>
Date: Mon, 31 Mar 2008 16:01:47 +0200

Hi Vincent, All,

Vincent Rossi wrote:
> writing down some specific requirements for the home automation 
> routing over L2N.
> I would like to add my contribution to this work. It will be divided 
> in two parts.
> First, I will make some comments on the current draft (and discuss 
> about the comments made by others).
> And finally, there is an other example/use-case that I really would 
> like to appear in this draft (but even if it is a draft, the issue 
> should be discussed first).
>
> Concerning my comments, I totally agree with the idea of the 
> group-cast even if it is also not very clear to me how it would be 
> implemented (cf. previous comments).
>
> toward an inner network for the house only but it appears (c.f. 
> Section 3.6) that a need to connect to a wider network (e.g. Internet) 
> will be required for some devices. I simply wonder how the bridge will 
> be established between our network (with a wide variety of devices...) 
> and the house's Internet connection. Of course, the routing can be 
> handled by a more powerful unit but I think it should be stated how 
> this should work (one gateway, multiple gateways...).
>

True, we don't want that surveillance company A has access to devices 
other than the subset of devices (with your permission: smoke
detector, motion detector, keypads, siren,...) which are essential for 
the service provided by that company A (for example surveillance of your 
home).
 This approach raises the following 'problem': a motion detector can be 
useful in several scenarios: surveillance, HVAC, lighting,...
 If we are not at home and the alarm is switched on: where is the 
intelligence? Should the motion detector send a message to a (group of) 
lights, the same message (but in another packet) to the surveillance 
service provider on the Internet, and the same message (but in another 
packet) to the HVAC system controller? We probably don't want to turn on 
the heating for the potential thief. Do we care about the "popcorn" 
effect on HVAC systems?

Do we want to send one "groupcast" message (one packet) to every device 
interested in the events detected by the motion detector? Maybe 1 (if we 
don't have different types of groupcast messages) or 2 (if we have an 
"avoid popcorn effect" groupcast message type and a "best effort" 
groupcast message type) groupcast messages and one unicast to the 
central management system (CMS)? 

This central management system can:
-manage the network,
-keep a list of devices with their profiles ( a profile contains the 
capabilities of the device (battery-powered / mains-powered; part of 
route or not; ...),
-maintain the policies (restrict interactions between services, sensors 
and actuators),
-provide security & AAA.
-...

In the home environment, we can group the CMS and the bridge to the wan, 
lan, wireless, sensor,... interfaces in a single embedded device (the 
Home Gateway).
 
>
> Considering the location of the devices, as asked by Jonathan, I tend 
> to think that we must take into consideration the physical and 
> environmental restrictions due to the devices that will be deployed in 
> a "hostile" environment. I mean that devices located outdoor may 
> suffer harder radio perturbations (thicker walls with iron 
> structure...), rain, variation in temperatures, all altering the 
> battery's lifetime (and so much more). So a question would be: how 
> should we deal with such devices? Should we prevent them to be part of 
> a route? Should they forward packets?
> broadly accepted. We may see several of these gw providing links to 
> the Internet and management capabilities to the WSN. This reduces SPOF 
> and also provide new routing issues.
>
> About Gopinath's contribution (about the categorization of use-cases), 
> I think that it would also be clearer to separate the use-cases and 
> try to group them by routing topology/goal/problems. The problem is 
> that if we get more and more use-cases, some of them won't probably 
> fit in one particular category. I think that the use-cases must be 
> more like concrete examples illustrating a particular problem about 
> routing within a house (which is exactly what they are right now).
>
> should tend to be discrete and seamless. I think that the best 
> embedded systems are those you can forget about. Of course, some 
> use-cases are very interesting but instead of needing the users input, 
> some can be automated (especially, section 3.1 and 3.4) by a device 
> located somewhere on the Internet. Is this changing the routing 
> requirements and policies?
>
> technology should not be visible. And this rises the problem of 
> changing batteries for some devices. Even if we can think about a 
> couple of years of operation on a single battery, we must think about 
> how the routing protocol should handle the powering state of the 
> nodes. I mean, this issue has already been covered in section 4.2 in 
> the case a node cannot be part of a route, but if a node is truly 
> dead, there is a good chance we never know about it (because another 
> route will be used). I think that a change in the route used must be 
> considered as an anomaly as long as they are not repetitive. It is a 
> real and hard problem. If a change of route occurs from time to time, 
> we can assume it is because of human activity (like described in the 
> middle of section 2), but if it is a longer route change, there are 2 
> main problems, first, there is a good chance we do not keep track that 
> the route has changed, and then, it may be because a node is "dead", 
> or simply because the node has been removed. My question would be how 
> the SNMP protocol should be supported on such a network and/or, should 
> this matter be raised to the application level. Nevertheless, it is, 
> according to me, an important issue and we should really discuss it.
I agree that management is important, but I'm not sure if we want to run 
SNMP (as it is) on a home sensor network.
Do we want push, pull, or hybrid? We should minimize the amount of 
traffic generated by the network management function.

>
> This leads to another comment (again!). Considering this draft is 
> about routing, I think that we should define the routing elements that 
> can appear in such environment. It has already been started in section 
> 4.2 but I think that maybe we can define some specific devices for the 
> -routers-forwarder, which are only designed to reach some dark areas 
> of the network

I don't agree with this classification. Do we want to manage the sensor? 
How do we configure a sensor if it can't receive anything?
The range of devices is very broad. We can have "stupid" sensors which 
will only send status and "intelligent" sensors which we can manage and 
configure.

>
> Should they all have an IP address ?

Good question. Do you mean that, if we attach 2 sensors and 1 actuator 
on 1 physical node or mote, you assign 4 addresses (the "naked" node 
must be addressable)?
Maybe we can keep this identification to the application level 
(considering sensors and actuators as applications) and only assign a(n) 
address(es) to the node.
> or just the micro-controler ? Should we stay with FFD and RFD 
> restrictions ?

Idea: every node and every application (sensor, actuator,...) has a 
profile that defines, among other things, the restrictions for the 
routing protocol.

> I would like your opinion on such a partition of the devices 
> abilities. I think it would help hardware and software design to help 
> achieve the goal of an efficient routing in the home.
> Another comment would be about the addressing. As you probably know, 
> the current motes are providing multiple way to interact with the 
> environment (may it be with sensors, actuators...), but often, there 
> is only one network interface and then, only one network address, but 
> how about we only want to access one sensor on a mote which possesses 
> many? Should the packet contain the sensor ID or can we think of a 
> protocol that could address directly to a particular sensor/actuator 
> without the help of an embedded DB? I mean that we might want to 
> access not only a mote but a particular sensor from a mote, without 
> pushing this to the application layer. This could result in a very 
> efficient way to access/collect data we want and prevent use of the 
> micro-controller of the mote for treating many packets and gathering 
> information from sensor we do not want information.

Do you want to address a particular sensor on a  mote without using the 
micro-controller? What's the difference between addressing a mote via a 
separate IP address, or via a mote IP address + sensor ID?
If mote A possesses 30 sensors, and we want to change a setting on 15 
sensors, you'll need 15 messages. Do you want this? Can you give a use 
case where this is useful?

>
> And at last, this is the use-case I propose for this draft: it 
> concerns energy efficiency in the home.
> planet, home automation may be use to optimize energy consumption. 
> This said, there would be several ways to do so. First, activating the 
> described in section 3.1, is that it should appear seamless to the 
> user. Another extension would be to forward the information from the 
> sensors, not directly but after some computation, to the services 
> providers such as gas, water and electricity ones so that they can 
> adjust the supplies furnished to the home and therefore, reduce the 
> power consumption based on estimation of need.
> The routing protocol should then be designed so that sensors are able 
> to gather their info, transmit them to a or multiple central unit(s), 
> and then, after following some model, action can be taken and orders 
> distributed among actuators. Some simpler decisions can be taken by 
> the sensor itself and transmitted directly to the according actuator. 
> About the part on transmitting the information outside of the house, 
> there must be a way to communicate securely between the inner network 
> and the Internet.
I agree, energy management is an interesting use case. I'm working on a 
draft on routing requirements for wireless building automation, and this 
is one of the applications (I'll be happy to receive input). Using such 
a system /Vooruit/ (an arts centre in a restored monument, consisting of 
366 different rooms) has realized a saving of 35% on the gas and 
electricity bills.

> I can't wait for your (numerous) replies :)
Pieter

-- 
Pieter De Mil
Department of Information Technology (INTEC)
Ghent University
Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
tel.: +32-9331 4981; tel. secr.: +32-9331 4900
fax: +32-9331 4899
[email-masked]
http://www.ibcn.intec.ugent.be

Confidentiality Statement:
This e-mail and any attached files are confidential and may be legally privileged. If you are not the addressee, any disclosure, reproduction, copying, distribution, or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify INTEC immediately and then delete this e-mail. INTEC does not accept liability for the correct and complete transmission of the information, nor for any delay or interruption of the transmission, nor for damages arising from the use of or reliance on the information.