Subject: [Roll] Questions on DAO operations

From: "JeongGil Ko (John)" <[email-masked]>
Date: Tue, 23 Feb 2010 18:25:37 -0800

Hi!

I was reading through the downwards route section in draft 6 (section 6) and had a few questions in mind.

1. How is the DAO rank (in Figure 11) computed and what does this rank value represent? By having this rank value, does it mean that all nodes keep a rank for the DODAG (constructed using DIO exchanges) separately and also maintain rank values for each 'downwards tree' that it participates in (for example if I have two nodes that rely on me to receive downwards packets, I would be maintaining one DODAG rank and two separate rank values for each of the two nodes)? Is this to assure that the downwards packets will make 'forward' progress? Why can't this be achieved with the DODAG rank values?

2. In 6.2.5.1.2 of draft version 6, it states that a non-storing forwarding node will append, on the DAO packet, the address of the 'child' to the RRstack. Why should we add the address of the child and not the node that is forwarding the packet itself? Is there an intuition behind this design? If there is a reason for this design, how would I retrieve the IP address of the previous hop (for sure it is not included in the IP address fields unless I am the first hop of the node)?

Sorry for the massive amount of question marks in the message but this downwards route part is really confusing me :)

Thanks for all your help in advance!

-John

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 23 Feb 2010 18:41:46 -0800

Hi John,

On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote:

> I was reading through the downwards route section in draft 6  
> (section 6) and had a few questions in mind.
>
> 1. How is the DAO rank (in Figure 11) computed and what does this  
> rank value represent? By having this rank value, does it mean that  
> all nodes keep a rank for the DODAG (constructed using DIO  
> exchanges) separately and also maintain rank values for each  
> 'downwards tree' that it participates in (for example if I have two  
> nodes that rely on me to receive downwards packets, I would be  
> maintaining one DODAG rank and two separate rank values for each of  
> the two nodes)? Is this to assure that the downwards packets will  
> make 'forward' progress? Why can't this be achieved with the DODAG  
> rank values?

One of the main purposes of including ranks towards downwards  
destinations in a DAO is so that a node receiving two DAOs for the  
same downwards destination can use rank to make a more intelligent  
decision if the rank differs (i.e. preferring the one with lesser rank).

> 2. In 6.2.5.1.2 of draft version 6, it states that a non-storing  
> forwarding node will append, on the DAO packet, the address of the  
> 'child' to the RRstack. Why should we add the address of the child  
> and not the node that is forwarding the packet itself? Is there an  
> intuition behind this design? If there is a reason for this design,  
> how would I retrieve the IP address of the previous hop (for sure it  
> is not included in the IP address fields unless I am the first hop  
> of the node)?

The IP address of the forwarding node is included in the IP header -  
it would be redundant to include the forwarding node's address in the  
RRstack as well.

--
Jonathan Hui

---

From: Philip Levis <[email-masked]>
Date: Tue, 23 Feb 2010 18:54:35 -0800

On Feb 23, 2010, at 6:41 PM, Jonathan Hui wrote:

> One of the main purposes of including ranks towards downwards destinations in a DAO is so that a node receiving two DAOs for the same downwards destination can use rank to make a more intelligent decision if the rank differs (i.e. preferring the one with lesser rank).

Let's back up -- the purpose is clear but how it achieves that purpose isn't. How is this value computed/filled in? Should -07 specify this? Is it correct that DAO Rank is the rank advertised in DIOs? Does that mean that a node sending DAOs to multiple DAO parents may specify different DAO Rank values. How does this work for aggregated prefixes?

Phil

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 23 Feb 2010 19:22:01 -0800

On Feb 23, 2010, at 6:54 PM, Philip Levis wrote:

> Let's back up -- the purpose is clear but how it achieves that  
> purpose isn't. How is this value computed/filled in? Should -07  
> specify this? Is it correct that DAO Rank is the rank advertised in  
> DIOs? Does that mean that a node sending DAOs to multiple DAO  
> parents may specify different DAO Rank values. How does this work  
> for aggregated prefixes?

I think it's clear that the DAO mechanism is not nearly as fleshed out  
as the DIO mechanism.  The text is intentionally vague (notice all the  
'may' text around it) about what the DAO Rank field can contain - it  
is simply a place-holder acknowledging the fact that we may want to  
convey some notion of cost towards the destination.  DAO aggregation  
is something we haven't even discussed yet.

But even before that, we need to back up even further and analyze  
whether the basic DAO mechanism fits our needs.  There is concern from  
the ROLL WG (including myself) on how DAOs are sent or triggered -  
specifically in cases where a network only caches a subset of the DAO  
information being sent around.  The main challenge is that the WG  
would like to see a solution that allows both networks where all nodes  
maintain downward routes and networks where only the root maintains  
downward routes.  Some would even like to see networks that where only  
some nodes maintain some subset of downward routes.  Unfortunately,  
there's some added complexity in requiring an implementation to  
support these different modes (e.g. nodes always have to maintain  
state to know when to trigger DAOs from their children).  There's  
certainly a number of dependencies that are not so obvious at first  
blush (e.g. a single DAG parent change could cause DAOs to be sent by  
every node in that sub-DAG).

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Feb 2010 17:51:29 +0100

Hi John and Jonathan.

I think Question 2 deserves a few more words:

the short answer 
---------------------
The point is that the record route in the DAO is for the (sole) use of
the recorder, when the RR stack has become a routing header in a packet
on the way back to Destination.
The packet will have to go between the recorder and loose Source Record
Route next_hop in the DAO stack, and the question is whether the routing
info to get there will have to be picked from the routing header in the
packet, or can be found in the routing table of the recorder.
The IP next-hop to get to the LSRR next-hop is definitively the source
of the DAO, that's what the DAO is all about. So the question is whether
the recorder has a route to the LSRR next-hop via the source of the
packet or not. 
If not, then the recorder needs to insert the next-hop information it
will need as the new LSRR next-hop on top of the LSRR stack.

The long answer
-------------------
requires an example, illustrated in the slides attached. 

Let us consider a DAO that is originated from Dest. No one below Parent
decided to cache the specific source route A->B->C->Dest.

Because nodes do not cache everything, it is acceptable, though, that
DAO routing states are installed all the way between child and A. The
result is that there's no need to additional source route to reach A
from child inside <cloud>. 

We'll see how that works by forwarding the DAO up one more time, child
to parent, and see what happens whether the parent has a DAO route to A
via Child or not.

Childs sends this to parent:  
IP header:
Source IP = Child
Dest IP = Parent
DAO:
dest = Dest
Stack = A, B, C

Case 1: Parent does a route look up for A, and that does resolves via
child. Either parent is missing a routing state, or its routing state is
obsolete. Parent updates the Stack that is now Child, A, B, C.
Case 1a) If parent decides to cache for Dest, then it stores Dest via
Child, A, B, C. 
                 Parent forwards the DAO to its ancestor as:

	IP header:
	Source IP = parent
	Dest IP = Ancestor
	DAO: 
	dest = Dest
	Stack = <empty>

	The result is that packets to Dest should come back without a
routing header, with the IP header destination set to Dest.
                When Parent forwards a packet to Dest, it changes the
destination to child, and inserts a RH A, B, C, Dest. and proceeds
forwarding the packet.
	Child being connected, the lookup resolved immediately and the
packet is passed to child.

Case 1b) If parent decides not to cache for Dest, then it forwards to
its own ancestor
	IP header:
	Source IP = parent
	Dest IP = Ancestor
	DAO: 
	dest = Dest
	Stack = child, A, B, C

	The result is that packets to Dest should come back with a
routing header child, A, B, C, and with the IP header destination set to
parent or child, depending on whether ancestor has a route to child via
parent or not.
                If Parent is the destination of the packet, then it
consumes the next entry in the RH, thus setting child as the destination
in the IP header, and proceeds forwarding the packet. 
	In any case, child being connected, the lookup is resolved
immediately and the packet is passed to child.

Case 2: Parent does a route look up for A, and that resolves via child.
Great, we have a routing state that's consistent.
Case 2a) If parent decides to cache for Dest, then it stores Dest via A,
B, C. 
                 Parent forwards the DAO to its ancestor as:

	IP header:
	Source IP = parent
	Dest IP = Ancestor
	DAO: 
	dest = Dest
	Stack = <empty>

	The result is that packets to Dest should come back without a
routing header, with the IP header destination set to Dest
                When Parent forwards a packet to Dest, it changes the
destination to A , and inserts a RH B, C, Dest , and proceeds forwarding
the packet now destined to A.
	A route lookup of A resolves in child (as verified above), so
the packet can be passed to child.

Case 2b) If parent decides not to cache for Dest, then it forwards to
its own ancestor
	IP header:
	Source IP = parent
	Dest IP = Ancestor
	DAO: 
	dest = Dest
	Stack = A, B, C

	The result is that packets to Dest should come back with a
routing header A, B, C, and with the IP header destination set to parent
or child, depending on whether ancestor has a route to child via parent
or not.
                Parent being the destination of the packet, to it
consumes the next entry in the RH, iow sets A as the destination, and
proceeds forwarding the packet now destined to A.
	A route lookup of A resolves in child (as verified above), so
the packet can be passed to child.

Note finally for the gory side of it that A, B, and C etc... are not
link local addresses.  They have to be global or ULA, because they can
be used multihop. An implementation might decide to store the connected
routes via the link locals, and the global of the children via the link
local of the children.
If that's so "Parent does a route look up for A, and that does resolves
via child" must be understood as lookup for A and lookup for child both
resolve in the same address, that is child's link local address.

This looks a bit complex said that way. I hope the slideware attached
helps.

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Hui
Sent: Wednesday, February 24, 2010 3:42 AM
To: JeongGil Ko (John)
Cc: ROLL WG
Subject: Re: [Roll] Questions on DAO operations

Hi John,

On Feb 23, 2010, at 6:25 PM, JeongGil Ko (John) wrote:

> 1. How is the DAO rank (in Figure 11) computed and what does this rank

> value represent? By having this rank value, does it mean that all 
> nodes keep a rank for the DODAG (constructed using DIO
> the two nodes)? Is this to assure that the downwards packets will make

> 'forward' progress? Why can't this be achieved with the DODAG rank 
> values?

One of the main purposes of including ranks towards downwards
destinations in a DAO is so that a node receiving two DAOs for the same
downwards destination can use rank to make a more intelligent decision
if the rank differs (i.e. preferring the one with lesser rank).

> 'child' to the RRstack. Why should we add the address of the child and

> not the node that is forwarding the packet itself? Is there an 
> is not included in the IP address fields unless I am the first hop of 
> the node)?

The IP address of the forwarding node is included in the IP header - it
would be redundant to include the forwarding node's address in the
RRstack as well.

--
Jonathan Hui

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 25 Feb 2010 08:08:43 +0100

Hi Phil:

I globally agree with you. 

I think we are pretty ripe WRT to the case where source routing is not
used. We have mechanisms that loads nodes send up their DAOs when then
like, and gather DAOs from their subDAG when they like. What's missing
there is more of a matter of recommending when those mechanisms are to
be used.

When it comes to source route, there are a lot more questions:

- should the record route mechanism be part of the DAO as it is today or
should it be part of the traffic as Richard suggested. There are
pro/cons for both approaches and we really need to discuss that in this
list.
-(as you say) optimization for the case where only the root store
states. Right now, we have an S bit mechanism that is not really spelled
out in the spec. This mechanism has assumptions that are not obvious. We
need to agree on it.
- what routing header will be used? How to compress them? This question
is holding 6LoWPAN HC at the moment.

I think we should have a number of threads to examine all of these
questions.

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Hui
Sent: Wednesday, February 24, 2010 4:22 AM
To: Philip Levis
Cc: ROLL WG
Subject: Re: [Roll] Questions on DAO operations

On Feb 23, 2010, at 6:54 PM, Philip Levis wrote:

> Let's back up -- the purpose is clear but how it achieves that purpose

> isn't. How is this value computed/filled in? Should -07 specify this? 
> Is it correct that DAO Rank is the rank advertised in DIOs? Does that 
> mean that a node sending DAOs to multiple DAO parents may specify 
> different DAO Rank values. How does this work for aggregated prefixes?

I think it's clear that the DAO mechanism is not nearly as fleshed out
as the DIO mechanism.  The text is intentionally vague (notice all the
'may' text around it) about what the DAO Rank field can contain - it is
simply a place-holder acknowledging the fact that we may want to convey
some notion of cost towards the destination.  DAO aggregation is
something we haven't even discussed yet.

But even before that, we need to back up even further and analyze
whether the basic DAO mechanism fits our needs.  There is concern from
the ROLL WG (including myself) on how DAOs are sent or triggered -
specifically in cases where a network only caches a subset of the DAO
information being sent around.  The main challenge is that the WG would
like to see a solution that allows both networks where all nodes
maintain downward routes and networks where only the root maintains
downward routes.  Some would even like to see networks that where only
some nodes maintain some subset of downward routes.  Unfortunately,
there's some added complexity in requiring an implementation to support
these different modes (e.g. nodes always have to maintain state to know
when to trigger DAOs from their children).  There's certainly a number
of dependencies that are not so obvious at first blush (e.g. a single
DAG parent change could cause DAOs to be sent by every node in that
sub-DAG).

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 24 Feb 2010 23:36:09 -0800

Hi Pascal,

> there is more of a matter of recommending when those mechanisms are to

I think there are still some concerns on the lack of compactness for  
the messages - that certainly is the case within the 6lowpan WG.   
Communicating and storing full IPv6 addresses is fine in the generic  
case, but there has to be a more efficient way.

> I think we should have a number of threads to examine all of these

Yes, I agree these are all issues.  I think Richard actually suggested  
that record-routes are unnecessary if only the root caches downward  
routing information, though record-routes can be useful in some  
situations (e.g. on-demand route discovery).

A topic that seems to come up every so often is when/where the use of  
labels show up.  That could change our thinking and/or perception.

What really worries me is the hidden complexities that result from  
needing to support both simultaneously.  I agree that piece-wise  
source-routes and being able to operate networks where nodes have  
widely varying capabilities can take on different responsibilities,  
but we need to be careful that doing so does not grow beyond our state/ 
communication complexity goals.

Looking forward to talking through these issues in depth.

--
Jonathan Hui

>> purpose
> is
> would
> support

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 25 Feb 2010 10:50:56 +0100

Hi Pascal

Thanks for taking time to explain your thoughts on DAO.
Unfortunately, I did not really get the idea of your slide deck!

You have Dest sending a RR stack back to C>B>A - but is A then
sending this to child which then sends it to Parent?
Is the distinction that Parent and Child are stateful routers
while A,B,C,Dest can only forward source routed packets?
Maybe some different colors or shapes could help clarify this ;-)

Finally another small clarification:

> Note finally for the gory side of it that A, B, and C etc... 
> are not link local addresses.  They have to be global or ULA, 
> because they can be used multihop. An implementation might 

I agree in this but should RPL do an effort on definition and 
compression of such source route stacks?
My point is that you will need to do the same source routing for
actually carrying real traffic along the same route.
As far as I understand IPv6 deprecated source routing as it was
originally defined, so how would you source route IPv6 packets
across a 6lowPan/RPL network?

Thanks,
  Anders

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Pascal Thubert (pthubert)
> Sent: Wednesday, February 24, 2010 17:51
> To: Jonathan Hui; JeongGil Ko (John)
> Cc: ROLL WG
> The point is that the record route in the DAO is for the 
> (sole) use of the recorder, when the RR stack has become a 
> routing header in a packet on the way back to Destination.
> The packet will have to go between the recorder and loose 
> Source Record Route next_hop in the DAO stack, and the 
> question is whether the routing info to get there will have 
> to be picked from the routing header in the packet, or can be 
> found in the routing table of the recorder.
> The IP next-hop to get to the LSRR next-hop is definitively 
> the source of the DAO, that's what the DAO is all about. So 
> the question is whether the recorder has a route to the LSRR 
> next-hop via the source of the packet or not. 
> If not, then the recorder needs to insert the next-hop 
> information it will need as the new LSRR next-hop on top of 
> the LSRR stack.
> 
> The long answer
> -------------------
> Let us consider a DAO that is originated from Dest. No one 
> below Parent decided to cache the specific source route A->B->C->Dest.
> 
> Because nodes do not cache everything, it is acceptable, 
> though, that DAO routing states are installed all the way 
> between child and A. The result is that there's no need to 
> additional source route to reach A from child inside <cloud>. 
> 
> We'll see how that works by forwarding the DAO up one more 
> time, child to parent, and see what happens whether the 
> parent has a DAO route to A via Child or not.
> 
> Case 1: Parent does a route look up for A, and that does 
> resolves via child. Either parent is missing a routing state, 
> or its routing state is obsolete. Parent updates the Stack 
> that is now Child, A, B, C.
> Case 1a) If parent decides to cache for Dest, then it stores 
> Dest via Child, A, B, C. 
> 	The result is that packets to Dest should come back 
> without a routing header, with the IP header destination set to Dest.
>                 When Parent forwards a packet to Dest, it 
> changes the destination to child, and inserts a RH A, B, C, 
> Dest. and proceeds forwarding the packet.
> 	Child being connected, the lookup resolved immediately 
> and the packet is passed to child.
> 
> Case 1b) If parent decides not to cache for Dest, then it 
> forwards to its own ancestor
> 	IP header:
> 	Source IP = parent
> 	Dest IP = Ancestor
> 	DAO: 
> 	dest = Dest
> 	Stack = child, A, B, C
> 
> 	The result is that packets to Dest should come back 
> with a routing header child, A, B, C, and with the IP header 
> destination set to parent or child, depending on whether 
> ancestor has a route to child via parent or not.
>                 If Parent is the destination of the packet, 
> then it consumes the next entry in the RH, thus setting child 
> as the destination in the IP header, and proceeds forwarding 
> the packet. 
> 	In any case, child being connected, the lookup is 
> resolved immediately and the packet is passed to child.
> 
> 
> Case 2a) If parent decides to cache for Dest, then it stores 
> Dest via A, B, C. 
> 	The result is that packets to Dest should come back 
> without a routing header, with the IP header destination set to Dest
>                 When Parent forwards a packet to Dest, it 
> changes the destination to A , and inserts a RH B, C, Dest , 
> and proceeds forwarding the packet now destined to A.
> 	A route lookup of A resolves in child (as verified 
> above), so the packet can be passed to child.
> 
> Case 2b) If parent decides not to cache for Dest, then it 
> forwards to its own ancestor
> 	IP header:
> 	Source IP = parent
> 	Dest IP = Ancestor
> 	DAO: 
> 	dest = Dest
> 	Stack = A, B, C
> 
> 	The result is that packets to Dest should come back 
> with a routing header A, B, C, and with the IP header 
> destination set to parent or child, depending on whether 
> ancestor has a route to child via parent or not.
>                 Parent being the destination of the packet, 
> to it consumes the next entry in the RH, iow sets A as the 
> destination, and proceeds forwarding the packet now destined to A.
> 	A route lookup of A resolves in child (as verified 
> above), so the packet can be passed to child.
> 
> Note finally for the gory side of it that A, B, and C etc... 
> are not link local addresses.  They have to be global or ULA, 
> because they can be used multihop. An implementation might 
> decide to store the connected routes via the link locals, and 
> the global of the children via the link local of the children.
> If that's so "Parent does a route look up for A, and that 
> does resolves via child" must be understood as lookup for A 
> and lookup for child both resolve in the same address, that 
> is child's link local address.
> 
> This looks a bit complex said that way. I hope the slideware 
> attached helps.
> 
> Cheers,
> 
> Pascal
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jonathan Hui
> > I was reading through the downwards route section in draft 
> 6 (section
> > 6) and had a few questions in mind.
> >
> destinations in a DAO is so that a node receiving two DAOs 
> for the same downwards destination can use rank to make a 
> more intelligent decision if the rank differs (i.e. 
> preferring the one with lesser rank).
> 
> The IP address of the forwarding node is included in the IP 
> header - it would be redundant to include the forwarding 
> node's address in the RRstack as well.
> 
> --
> Jonathan Hui
>

---

From: "Roger Alexander" <[email-masked]>
Date: Thu, 25 Feb 2010 17:47:40 -0500

Hi Pascal, WG,

A point of clarification on the specified DAO operation.

In Section 6.2.8. (page 51), the current text reads...

   4.  Note: it is NOT RECOMMENDED that a DAO Transmission (No-DAO) be
       scheduled when a DAO Parent is removed from the DAO Parent set.

This text, as phrased, may be redundant as there is no value to sending a
'No-DAO' in the case of a removed DAO Parent as there is no relevant DAO
Parent to whom the No-DAO would apply. However, there is potential value to
an updated DAO transmission to the remaining DAO Parents.
 
The DAO Parent set is intended to allow for some measure of downward routing
path diversity (which may nonetheless only be local). However, in the event
that a child removes a Parent from the DAO Parent Set, there can be value in
the node sending updated DAOs to the remaining Parents of the DAO Parent
Set. 

The response time benefit of updating the DAOs to the remaining DAO Parents
is that it will allow for a more ready update of the downward paths from the
common ancestor (which may be the root) to the affected node by eliminating
the downward path through the removed DAO Parent. There is also the benefit
of the potential reduction of network traffic that could otherwise result
from failed packet deliveries and subsequent destination unreachable
signaling that may occur along segments of the broken downward path. The
penalty of the proactive update is of course the additional overhead that
will be incurred in signaling to the existing DAO Parents and subsequent
ancestor nodes. 

The tradeoff between proactive path correction and reactive traffic
rerouting can be further tilted in the favor of proactive updates by
enhancing the DAO message compactness. Currently suggested work on message
address compression would be further beneficial as it would lower the
overhead of proactive updates. Similarly, if Acknowledged DAO exchanges are
supported in RPL there can be additional control options to indicate 'no' or
'incremental' DAO information changes that can be signaled in conjunction
with an incremented DAO sequence number. As the draft is updated to include
effective DAO message compression it will also assist implementation choice
in the tradeoff between proactive and reactive downward path maintenance.   

Thus within Section 6.2.8, the following text amendment should be
considered:

   4.  A Node MAY transmit a DAO message (with incremented DAO Sequence) to
the remaining DAO Parents
       when a DAO Parent is removed from the DAO Parent set.

Thanks.

Roger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Anders Brandt
Sent: Thursday, February 25, 2010 4:51 AM
To: Pascal Thubert (pthubert)
Cc: ROLL WG
Subject: Re: [Roll] Questions on DAO operations

Hi Pascal

Thanks,
  Anders

---

From: Philip Levis <[email-masked]>
Date: Thu, 25 Feb 2010 18:04:35 -0800

> there is more of a matter of recommending when those mechanisms are to

I'm sorry -- what are you agreeing with? I had a bunch of concrete  
technical questions on how DAOs work. Can you answer them?

Phil

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 26 Feb 2010 11:16:54 +0100

Same issue for me:

I am still eager to see how the current RPL proposal can guarantee that
I can - within a second or less (maybe a few) - 
reach nodes somewhere in the tree if the current routes do not work?

On Feb 24, 2010, at 11:08 PM, Pascal Thubert (pthubert) wrote:
> ... We have mechanisms that loads nodes send up their DAOs when then 
> like, and gather DAOs from their subDAG when they like...

The issue is that if a light module is not aware that routes are
broken, "when they like" may be minutes into the future.

It may be fine for data gathering and smart meters but it is
a showstopper for home and building.
Users will never appreaciate non-reactive light controls.

Cheers,
  Anders

> Behalf Of Philip Levis
> Sent: Friday, February 26, 2010 03:05
> I'm sorry -- what are you agreeing with? I had a bunch of 
> concrete technical questions on how DAOs work. Can you answer them?
> 
> Phil