Pekka Savola: Below are the comments based on my WGLC review of send-ndopt document.  
You may treat these either as late WGLC or early IETF LC comments .

In general, I think the document is in a pretty good shape, very 
readable etc. -- thanks!

But of course, there are a lot of tiny details to iron out 

bigger architectural considerations

1)

The SEND model requires the model that if a host sends a solicitation,
the router must remember and respect that solicitation, even if it wanted to
respond using multicast to all the nodes.  That is, if the algorithm is set
so that if a host sends a solicitation, the router always replies with a
multicast "non-solicited response" in return, there must be both the nonce 
and timestamp to the multicast advertisement.

I don't have strong objections to this model, but I just thought it might be
something that some implementations (if those exist, not sure) might find
objectionable.

-----------

Jari Arkko: I agree that there is a difference.

But I'm not sure the difference is that great. I mean, you can still
send a multicast response. And in this case the solicited/non-solicited
difference is just whether you have one or two additional ND options
in there. And other hosts that receive this can still process them
securely or do their own solicitation if timestamp was insufficient.

The only thing that is needed implementation-wise is for the multicast
RA code piece to know whether it needs to include a Nonce. But I would
expect most implementations to have some idea on why they are sending
the RA. If not, a new parameter has to be added to the function call.

In any case, I added this text to Section 5.3.3:

	  Note that routers may decide to send a multicast
	  advertisement to all nodes instead of a response to a
	  specific host. In such case the router MAY still include the
	  nonce value for the host that triggered the multicast
	  advertisement.

Is this sufficient or do you want something more?

-----------

-----------

-----------