Subject: [Roll] R: Detailed comments on draft-ietf-roll-home-routing-reqs

From: Porcu Giorgio <[email-masked]>
Date: Thu, 26 Jun 2008 11:44:28 +0200

Dear WG,
here there are a few comments about HA draft.
Welcome to Jakob and thank you for your help!
I wish we'll get a stable draft version before the Dublin meeting.

Anyway, my opinion is included in the discuss with JP, I'd like to see in the new revision some updates mainly in these part:
- 3.2 Energy conservation and optimizing energy consumption
- 3.9 Battery powered devices
- 4.2 Metric-based Routing

----------------------
Section 0. Abstract.
----------------------
>This document presents home control and automation application
>   specific requirements for ROuting in Low power and Lossy networks
>   (ROLL).
There is a typing error:
"ROuting" instead of "Routing" ;-)

-----------------
Section 3.2
----------------
> 6) Section 3.2
>> -> Add the example of power dynamic pricing that can be used
>> -> to regulate
>> -> the operation of a set of devices in the home.
> We already have the "start-device-when-power-is-cheap" case. I'll add "stop-device-when-power-is-expensive" case. This should be useful for air conditioning/climate control systems.
IMHO, we have to consider two different aspects here.
Of course, as JP says, it's important to focus on the power dynamic pricing using the case study "stop-device-when-power-is-expensive" (I'm looking forward to read it!), but, at the same time, I think it useful to stress, in the "Energy conservation and optimizing energy consumption." part, that the energy of the nodes involved in routing must be optimized too.
I mean, for e.g., if an application must change a home-device to stand-by mode, of course it must spend less energy than that required by the stand-by mode.
It could be a very important application scenario, which can have relevant consequences on the routing process.
Let me know what do you think about it.

Jakob wrote:
>I will change to "Most of these applications are mains powered and are thus ideal for providing reliable, always-on routing resources. Battery-powered nodes, by comparison, are constrained routing >resources and may only provide reliable routing under some circumstances."
>Giorgio - do you agree on this wording? Can we link this to a health care example of reliable routing via battery-powered devices?
Sure!
Well done.

----------------
Section 3.8
----------------
>> 11) Could you elaborate on the routing requirements here: " A plethora
>> of applications could be developed for home alarm
>> system: most of them, most of the time, have prevention and monitoring
>> activity in which routing requirements are deterministic, but all of
>> them have an alarm state in which nodes may burst an aperiodic alarm.
>> "
>I will highly appreciate contributions here, Giorgio, you probably have some thought on this. Do you want to add something?
Yes! I'd like to introduce in this scenario the panic button application to explain it better.
You'll receive asap my contribution :)

----------------
Section 3.9.
----------------
JP wrote:
>> 2.
>> 12) Section 3.9(Battery-powered devices) I guess that you meant "
>> leaving only a few 100 bytes of RAM powered during the deep sleep
>> phase."
Jakob wrote:
>I'll add "of RAM".
This point isn't so clear for me.
In this section ("battery powered devices"), it seems a strong requirement (a few 100 byte of RAM powered).
Why RAM? Why "few 100 bytes"?
The main requirement is to save up as much as possible energy... but how and, above all, how much memory RAM I  had to powered during the sleep phase seems a little extreme requirement..
It means that I'm wrong if I use a NVRAM during this phase or not?
Sorry, maybe it is only a personal gap ...

----------------
Section 4.1
----------------
Jakob wrote:
>I propose to add this section:
>"Groupcast, in the context of home automation, is defined as the ability to simultaneously transmit a message to a group of recipients without prior interaction with the group members (i.e. group setup). A >use-case for groupcast is given in Section 3.1. "
It is ok for me!

----------------
Section 4.2
----------------
Jakob wrote:
>I agree with JPs taxonomy of routing types, and I believe that we need constraint-based routing. Multi-metric routing would be too complicated for a simple network.
>If there are no objections on the ML, we'll revert back to the term "constraint-based routing" instead of "metric-based routing".
I agree with JPs taxonomy too but  it's not only a question of terminology for me.
We could use "constraing-based routing" term as well, but I think it is of no help to remove the opportunity to choose between a bandwith metric and a power metric or (why not) an hybrid.
Sorry, maybe I've misunderstood the meaning of your comment...

----------------
Section 4.7
----------------
Jakob wrote:
>" From ROLL perspective, zero-configuration means only and above all, that a node can obtain an address and join the network on its own, without human intervention."
>I propose to add this definition and keep the 0 configuration requirement.

ok.

Excuse me for my boring mail;)

Regards
 Giorgio

______________________________________________________________________________________

---
La vita è come una commedia: non importa quanto è lunga, ma come è recitata.
(Seneca)

Men do not care how nobly they live, but only how long, although it is within the reach of every man to live nobly, but within no man's power to live long
(Seneca the Younger)
________________________________________
Da: [email-masked] [[email-masked]] per conto di [email-masked] [[email-masked]]
Inviato: lunedì 23 giugno 2008 21.00
A: [email-masked]
Oggetto: Roll Digest, Vol 5, Issue 14

Send Roll mailing list submissions to
        [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/roll
or, via email, send a message with subject or body 'help' to
        [email-masked]

You can reach the person managing the list at
        [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Roll digest..."

Today's Topics:

   1. Re: Detailed comments on draft-ietf-roll-home-routing-reqs
      (Jakob Buron)
   2. ROLL WG Agenda (JP Vasseur)
   3. Re: ROLL WG Agenda (Ryuji Wakikawa)

----------------------------------------------------------------------

Message: 1
Date: Mon, 23 Jun 2008 10:30:54 +0200
From: "Jakob Buron" <[email-masked]>
Subject: Re: [Roll] Detailed comments on
        draft-ietf-roll-home-routing-reqs
To: <[email-masked]>
Message-ID:
        <[email-masked]>
Content-Type: text/plain;       charset="iso-8859-1"

Dear WG,

a new revision of the home automation I-D based on JPs comments will be posted soon. Please see my inline comments for an overview of the proposed changes by Anders and myself. Do let me know if you have any feedback at this point.

Kind regards,
Jakob

> -----Original Message-----
> From: JP Vasseur <[email-masked]>
> Date: Wed, 04 Jun 2008 17:13:45 +0200
> To: <[email-masked]>
> Subject: [Roll] Detailed comments on draft-ietf-roll-home-routing-reqs
>
> Dear WG,
>
> I made a detailed review of draft-ietf-roll-home-routing-reqs
>
> Here are my comments (not of equil importance):
>
> 1) idnits
>   Checking nits according to http://www.ietf.org/ID-Checklist.html:
>
> --------------------------------------------------------------
> --------------
>
>   ** There is 1 instance of too long lines in the document, the
> longest one
>      being 1 character in excess of 72.
>
Will fix.

> 2) Each acronym must be expanded the first time it is used (e.g. PANs
> in section 2)
OK.

> 3) Remove reference to I-D.culler-roll-routing-reqs (ID has expired)
OK

> 4) Section 3.1
> ?Some existing
>    home automation solutions use a clever mix of a "subnet groupcast"
>    message with no acknowledgement and no forwarding before sending
>    acknowledged singlecast messages to each lighting device.? This
> might be a good place to define the term ?groupcast? more carefully.
I'll add a definition of groupcast in Section 4.1.

> 5) Section 3.1
> ? Thus, a solution is needed for addressing groups of nodes without
> prior management of group membership in the receiving nodes. ? Is it a
> ?must? or a MUST?
I'll remove this sentence since requirements should not appear in use cases.

> 6) Section 3.2
> ? The power grid may experience periods where more wind-generated
> power
>    is produced than is needed. Typically this may happen during night
>    hours. The washing machine and dish washer may just as well work
>    while power is cheap. The electric car should also charge its
> batteries on cheap power. ?
> -> Add the example of power dynamic pricing that can be used
> to regulate
> -> the
> operation of a set of devices in the home.
We already have the "start-device-when-power-is-cheap" case. I'll add "stop-device-when-power-is-expensive" case. This should be useful for air conditioning/climate control systems.

> 7) Section 3.2
> " Most of these applications are mains powered and may thus provide
> reliable routing resources."
> I would suggest to reword the sentence. Indeed, a battery node may
> still provide reliable routing but this is a constrained resource
> (battery
> operated) that the routing decision may want to avoid if an alternate
> path exist.
I will change to "Most of these applications are mains powered and are thus ideal for providing reliable, always-on routing resources. Battery-powered nodes, by comparison, are constrained routing resources and may only provide reliable routing under some circumstances."
Giorgio - do you agree on this wording? Can we link this to a health care example of reliable routing via battery-powered devices?

8) As written section 3.4 is about auto-conf rather than routing
> (requires for auto-conf)? Would you want to slightly elaborate there?
Inserted at the end of sec. 3.4:
"Distribution of unique addresses is usually performed by a central controller. In this case, it must be possible  to route the inclusion request from the joining node to the central controller even before the joining node is  assigned a unique address."

> 9) section 3.5: " ROLL resources" ? Why would the router have to wait
> for some time ? Because you make the assumption of devices in deep
> sleep mode?
"ROLL resources" changed to "ROLL devices".
The router only has to wait if the receiver is sleeping. An acknowledgment-mechanism is needed to manage this, but that is beyond the scope if this I-D.
I'll clarify that the router has to wait _if_ the receiver is sleeping.

> 10) Section 3.6
> S/ROLL devices/constrained devices or please define a "ROLL"
> device in the terminology section
I'll define a ROLL device as "A ROLL network node with constrained CPU and memory resources; potentially  constrained power resources."

> 11) Could you elaborate on the routing requirements here: " A plethora
> of applications could be developed for home alarm
> system: most of them, most of the time, have prevention and monitoring
> activity in which routing requirements are deterministic, but all of
> them have an alarm state in which nodes may burst an aperiodic alarm.
> "
I will highly appreciate contributions here, Giorgio, you probably have some thought on this. Do you want to add something?

> 12) Section 3.9: I guess that you meant " leaving only a few 100 bytes
> of RAM powered during the deep sleep phase."
I'll add "of RAM".

> 13) Section 4.1:
> " The routing protocol must provide the ability to route a packet
> towards a single device (unicast), a set of devices (also referred to
> as "groupcast"
> in this document) or all devices (broadcast) in the house.
> - Don't you mean to use a MUST here ?
Will be changed to:
"Broadcast and groupcast in home automation MAY be used to deliver the illusion that all recipients respond  simultaneously. Distant recipients out of direct range may not react to the (unacknowledged) groupcast.  Acknowledged unicast delivery MUST be used subsequently."

> - Please insert a section prior to this requirements on the definition
> of Groupcast.
I propose to add this section:
"Groupcast, in the context of home automation, is defined as the ability to simultaneously transmit a message to a group of recipients without prior interaction with the group members (i.e. group setup). A use-case for groupcast is given in Section 3.1. "

> 14) You wrote: " Alternatively, a companion specification SHOULD
> define how to indirectly address a group of nodes on the application
> layer via classic broadcast in the network layer; e.g. by use of a
> bitmap in a header extension. "
> But you cannot have a SHOULD in this document on a document defined
> somewhere else.
OK - that sentence will be removed.

> 15) You wrote:
> "[ABR NOTE: IETF-71 WG meeting indicated that the term "constrained"
> has a very specific meaning in the routing community inside IETF.
> What I understood was that the draft should be using the term
> "metric-based routing"]"
> I do not think so. The term "constrained based routing" used in this
> document is appropriate if what you require is to have the ability the
> compute the shortest path based on some metrics (there could be more
> than one metrics) taking into account some link or node constraints.
> If this is what you need, then you indeed refer to constrained based
> routing.
> Based on what you wrote
> " Simple battery-powered nodes such as movement sensors on garage
> doors and rain meters may not be able to assist in routing. Depending
> on the node type, the node never listens at all, listens rarely or
> makes contact on demand to a pre-configured target node. Attempting to
> communicate to such nodes may require long time before getting a
> response."
> You do refer to constrained based routing.
> 16)
> "The routing protocol MUST support metric-based routing taking into
> account node properties (CPU, memory, level of energy, sleep
> intervals, safety/convenience of changing battery). "
> S/metric-based routing/constrained based routing.
> The metric-based routing refers to the ability to use different
> metrics to compute the shortest path, which is a different requirement
> ?
> Is that needed for Home Automation ?
> In your case you may either need:
> 1) Constrained based routing: e.g. Avoid a node whose battery level <
> X
> 2) Multi-metric based routing: assign different metrics for a specific
> link (for example, one metric to reflect the bandwidth, one metric to
> reflect the propagation delay, ...).
I agree with JPs taxonomy of routing types, and I believe that we need constraint-based routing. Multi-metric routing would be too complicated for a simple network.
If there are no objections on the ML, we'll revert back to the term "constraint-based routing" instead of "metric-based routing".

> 17)
> " The routing protocol SHOULD make use of the fact that if not being
> able to deliver a packet, it is most likely that the sending node
> moved; rather than the rest of the network."
> You may want to be more explicit on what this actually translate to
> for the routing protocol.
A non-responsive node can either be caused by 1) a failure in the node, 2) a failed link on the path to the node or 3) a moved node. In the first two cases, the node can be expected to reappear at roughly the same location in the network, whereas it can return anywhere in the network in the latter case. The search strategy in the routing protocol will behave differently depending on this expectation.

> 18) Section 4.7. Please expand PAN when first used.
OK

> 19) " home PAN MUST provide a set of features including 0
> configuration of the routing protocol for a new node to be added to
> the network. "
> Do you really mean "0 configuration" ?? What about optional
> configuration of timers ?
We mean zero configuration, as defined by Giorgio:
" From ROLL perspective, zero-configuration means only and above all, that a node can obtain an address and join the network on its own, without human intervention."
I propose to add this definition and keep the 0 configuration requirement.

> 20) " Furthermore, a failing node MUST NOT have a global impact on the
> routing protocol. "
> This is a very strong requirement ... Are you sure that this is what
> you mean? I feel more comfortable about your second
Agreed. I propose to delete the first requirement and make the second a MUST:
"The routing protocol MUST support the ability to isolate a misbehaving node thus preserving the correct operation the overall network."
Giorgio has a very good comment on the unspecified impact of a central controller failing. This case is important for sure, but not all ROLL networks need to have a central controller, so I would propose to avoid discussing it here.

> 21) It would be nice if you could elaborate a little bit on the
> traffic pattern for the various use cases since health monitoring and
> alarm significantly differs on that aspect.
> Please provide some number of packet sizes, frequency at which packets
> are sent out, ...
I'll add some numbers for the home appliance remote control and motion sensor cases. Perhaps Giorgio could add some data on a healthcare scenario?

> 22) Could you flesh out the security requirements ?
This is still not clear from our side either. I'll add some general guidelines, though.

> 23) Acknolegment: list of people (if any) that you want to
> thank for their contribution/feed-backs/...
Good idea.

> 24) Remove [I-D.culler-roll-routing-reqs] as informative reference.
>
OK.

> Thanks.
>
> JP.
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>
>

--
Jakob Buron
Software Engineer
Zensys A/S
Emdrupvej 26
DK-2100 Copenhagen O
Phone : +45 39130043
www.zen-sys.com

------------------------------

Message: 2
Date: Mon, 23 Jun 2008 13:18:59 +0200
From: JP Vasseur <[email-masked]>
Subject: [Roll] ROLL WG Agenda
To: <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Dear WG,

The ROLL WG will meet in Dublin. The provisional agenda is:

MONDAY, July 28, 2008
0800-1800 IETF Registration - Convention Lobby
0800-0900 Beverages - Convention Lobby

1130-1300 Break
1300-1500 Afternoon Session I
Convention 1    INT    l3vpn    Layer 3 Virtual Private Networks WG
Ballroom 2    INT    csi    Cga & Send maIntenance WG
Conservatory    IRTF    hiprg    Host Identity Protocol
Newcastle    OPS    dime    Diameter Maintenance and Extensions WG
Convention 3    RAI    speermint    Session PEERing for Multimedia
INTerconnect WG
Newcastle    RTG    roll    Routing Over Low power and Lossy networks WG
Conservatory    SEC    krb-wg    Kerberos WG
Ballroom 1    SEC    dkim    Domain Keys Identified Mail WG
Rathcoole    TSV    dccp    Datagram Congestion Control Protocol WG

If you need a slot, please let us know.

JP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/pipermail/roll/attachments/20080623/10053d51/attachment-0001.htm>

------------------------------

Message: 3
Date: Tue, 24 Jun 2008 01:22:10 +0900
From: Ryuji Wakikawa <[email-masked]>
Subject: Re: [Roll] ROLL WG Agenda
To: JP Vasseur <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

Hi JP,

We want 15min slot for  "In-Vehicle Routing Requirements".
http://tools.ietf.org/html/draft-wakikawa-roll-invehicle-reqs-00

thanks
ryuji

On 2008/06/23, at 20:18, JP Vasseur wrote:

> Dear WG,
>
> The ROLL WG will meet in Dublin. The provisional agenda is:
>
> MONDAY, July 28, 2008
> 0800-1800 IETF Registration - Convention Lobby
> 0800-0900 Beverages - Convention Lobby
>
> 1130-1300 Break
> 1300-1500 Afternoon Session I
> Convention 1    INT    l3vpn    Layer 3 Virtual Private Networks WG
> Ballroom 2    INT    csi    Cga & Send maIntenance WG
> Conservatory    IRTF    hiprg    Host Identity Protocol
> Newcastle    OPS    dime    Diameter Maintenance and Extensions WG
> Convention 3    RAI    speermint    Session PEERing for Multimedia
> INTerconnect WG
> Newcastle    RTG    roll    Routing Over Low power and Lossy
> networks WG
> Conservatory    SEC    krb-wg    Kerberos WG
> Ballroom 1    SEC    dkim    Domain Keys Identified Mail WG
> Rathcoole    TSV    dccp    Datagram Congestion Control Protocol WG
>
> If you need a slot, please let us know.
>
> JP.
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

------------------------------

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

End of Roll Digest, Vol 5, Issue 14
***********************************
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Jakob Buron" <[email-masked]>
Date: Fri, 27 Jun 2008 08:46:32 +0200

Dear Giorgio, WG,

thanks a lot for the valuable comments! It looks like we agree on most of the points. 
For the few remaining issues, I have a few follow-up questions below.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Porcu Giorgio
> Sent: 26. juni 2008 11:44
> To: [email-masked]
> Subject: [Roll] R: Detailed comments on 
> Anyway, my opinion is included in the discuss with JP, I'd 
> like to see in the new revision some updates mainly in these part:

This is actually not a typo: The capital O is part of the ROLL acronym ;-)

> 
> -----------------
> Section 3.2
> ----------------
> > 6) Section 3.2
> >> -> Add the example of power dynamic pricing that can be used to 
> >> -> regulate the operation of a set of devices in the home.
> > We already have the "start-device-when-power-is-cheap" 
> case. I'll add "stop-device-when-power-is-expensive" case. 
> This should be useful for air conditioning/climate control systems.
> Of course, as JP says, it's important to focus on the power 
> dynamic pricing using the case study 
> "stop-device-when-power-is-expensive" (I'm looking forward to 
> read it!), but, at the same time, I think it useful to 
> stress, in the "Energy conservation and optimizing energy 
> consumption." part, that the energy of the nodes involved in 
> routing must be optimized too.
> I mean, for e.g., if an application must change a home-device 
> to stand-by mode, of course it must spend less energy than 
> that required by the stand-by mode.
> It could be a very important application scenario, which can 
> have relevant consequences on the routing process.

I'm not sure I don't understand your example. Could you please clarify?
Do you mean that the energy needed to transmit a command should be weighed against the energy that turn-device-X-off command will save?

> 
> Jakob wrote:
> >I will change to "Most of these applications are mains 
> powered and are thus ideal for providing reliable, always-on 
> routing resources. Battery-powered nodes, by comparison, are 
> constrained routing >resources and may only provide reliable 
> routing under some circumstances."
> >Giorgio - do you agree on this wording? Can we link this to 
> a health care example of reliable routing via battery-powered devices?
> Sure!
> Well done.
> 
> 
> 
> ----------------
> Section 3.8
> ----------------
> >> 11) Could you elaborate on the routing requirements here: " A 
> >> plethora of applications could be developed for home alarm
> >> system: most of them, most of the time, have prevention and 
> >> monitoring activity in which routing requirements are 
> deterministic, 
> >> but all of them have an alarm state in which nodes may 
> burst an aperiodic alarm.
> >> "
> >I will highly appreciate contributions here, Giorgio, you 
> probably have some thought on this. Do you want to add something?
Great! Looking forward to it.

> In this section ("battery powered devices"), it seems a 
> strong requirement (a few 100 byte of RAM powered).
> The main requirement is to save up as much as possible 
> energy... but how and, above all, how much memory RAM I  had 
> to powered during the sleep phase seems a little extreme requirement..
First: I agree with the main requirement is to save energy. Period. For me, it is also fine not to specify size of the sleep-powered RAM. The example of leaving only a small part of RAM powered is not a requirement, so it does not disallow using e.g. non-volatile RAM instead. It is just an example of _one way_ to save energy. This example is highlighted because it affects the routing requirements: Use as little routing state/memory as possible to save energy. Is this sufficient to address your concern? Otherwise, we can add a sentence to clarify this.

> >"Groupcast, in the context of home automation, is defined as 
> the ability to simultaneously transmit a message to a group 
> of recipients without prior interaction with the group 
> members (i.e. group setup). A >use-case for groupcast is 
> given in Section 3.1. "
> It is ok for me!
> 
> ----------------
> Section 4.2
> ----------------
> Jakob wrote:
> >I agree with JPs taxonomy of routing types, and I believe 
> that we need constraint-based routing. Multi-metric routing 
> would be too complicated for a simple network.
> >If there are no objections on the ML, we'll revert back to 
> the term "constraint-based routing" instead of "metric-based routing".
> We could use "constraing-based routing" term as well, but I 
> think it is of no help to remove the opportunity to choose 
> between a bandwith metric and a power metric or (why not) an hybrid.
Good question to a very important topic!

To my understanding, multi-metric and constraint-based routing are not mutually exclusive. Constraint-based routing _can_ use several different metrics (according to JPs comment 15). So we are not disallowing multi-metric because we require constraint-based. I am however convinced constraint-based is essential to avoid e.g. nodes with low battery, hence the MUST to constraint-based.

We could add "The routing protocol MAY support multi-metric-based routing where several metrics (bandwidth, latency, etc.) are assinged to each link and used for route computation.", but if we are going to be that specific I would like to see some use cases that would benefit from multi-metric routing. If anyone has such a use case, please let me know.

> 
> ----------------
> Section 4.7
> ----------------
> Jakob wrote:
> >" From ROLL perspective, zero-configuration means only and 
> above all, that a node can obtain an address and join the 
> network on its own, without human intervention."

No need to excuse, it is not boring at all!
/jakob

> Men do not care how nobly they live, but only how long, 
> although it is within the reach of every man to live nobly, 
> but within no man's power to live long (Seneca the Younger) 
> Da: [email-masked] [[email-masked]] per conto 
> di [email-masked] [[email-masked]]
> When replying, please edit your Subject line so it is more 
> specific than "Re: Contents of Roll digest..."
> 
> 
> Today's Topics:
> 
> a new revision of the home automation I-D based on JPs 
> comments will be posted soon. Please see my inline comments 
> for an overview of the proposed changes by Anders and myself. 
> Do let me know if you have any feedback at this point.
> 
> Kind regards,
> Jakob
> 
> We already have the "start-device-when-power-is-cheap" case. 
> I'll add "stop-device-when-power-is-expensive" case. This 
> should be useful for air conditioning/climate control systems.
> 
> > 7) Section 3.2
> I will change to "Most of these applications are mains 
> powered and are thus ideal for providing reliable, always-on 
> routing resources. Battery-powered nodes, by comparison, are 
> constrained routing resources and may only provide reliable 
> routing under some circumstances."
> Giorgio - do you agree on this wording? Can we link this to a 
> health care example of reliable routing via battery-powered devices?
> 
> "Distribution of unique addresses is usually performed by a 
> central controller. In this case, it must be possible  to 
> route the inclusion request from the joining node to the 
> central controller even before the joining node is  assigned 
> a unique address."
> 
> The router only has to wait if the receiver is sleeping. An 
> acknowledgment-mechanism is needed to manage this, but that 
> is beyond the scope if this I-D.
> I'll define a ROLL device as "A ROLL network node with 
> constrained CPU and memory resources; potentially  
> constrained power resources."
> 
> I will highly appreciate contributions here, Giorgio, you 
> probably have some thought on this. Do you want to add something?
> 
> "Broadcast and groupcast in home automation MAY be used to 
> deliver the illusion that all recipients respond  
> simultaneously. Distant recipients out of direct range may 
> not react to the (unacknowledged) groupcast.  Acknowledged 
> unicast delivery MUST be used subsequently."
> 
> "Groupcast, in the context of home automation, is defined as 
> the ability to simultaneously transmit a message to a group 
> of recipients without prior interaction with the group 
> members (i.e. group setup). A use-case for groupcast is given 
> in Section 3.1. "
> 
> I agree with JPs taxonomy of routing types, and I believe 
> that we need constraint-based routing. Multi-metric routing 
> would be too complicated for a simple network.
> If there are no objections on the ML, we'll revert back to 
> the term "constraint-based routing" instead of "metric-based routing".
> 
> > 17)
> A non-responsive node can either be caused by 1) a failure in 
> the node, 2) a failed link on the path to the node or 3) a 
> moved node. In the first two cases, the node can be expected 
> to reappear at roughly the same location in the network, 
> whereas it can return anywhere in the network in the latter 
> case. The search strategy in the routing protocol will behave 
> differently depending on this expectation.
> 
> " From ROLL perspective, zero-configuration means only and 
> above all, that a node can obtain an address and join the 
> network on its own, without human intervention."
> "The routing protocol MUST support the ability to isolate a 
> misbehaving node thus preserving the correct operation the 
> overall network."
> Giorgio has a very good comment on the unspecified impact of 
> a central controller failing. This case is important for 
> sure, but not all ROLL networks need to have a central 
> controller, so I would propose to avoid discussing it here.
> 
> I'll add some numbers for the home appliance remote control 
> and motion sensor cases. Perhaps Giorgio could add some data 
> on a healthcare scenario?
> 
> 0800-1800 IETF Registration - Convention Lobby 0800-0900 
> Beverages - Convention Lobby
> 
> 1130-1300 Break
> URL: 
> <http://www.ietf.org/pipermail/roll/attachments/20080623/10053
> d51/attachment-0001.htm>
> 
> > 0800-1800 IETF Registration - Convention Lobby 0800-0900 
> Beverages - 
> > Convention Lobby
> >
> > 1130-1300 Break