>       4.  The 32-bit ICMP header.

Would be better to make clear exactly what part of the header you are
referring to. ICMP has more than a 32 bit header in some cases. Also,
see below comment.

James Kempf: It's the entire header. We'll clarify.

>    o  For the purpose of constructing a signature, the following data
>       items are concatenated:
> 
> 
>       *  The 128-bit CGA Type Tag.

This is a repetition  of what was given just a page earlier. Can we
just have one definition/algorith (and make sure it is clear?)


>    o  The receiver MUST ignore any options the come after the first
>       Signature option.

s/the come/that come/


> 5.2.3 Configuration
> 
> 
>    All nodes that support the reception of the Signature options MUST be
>    configured with the following information for each separate NDP
>    message type:

must "allow the following information to be configured" (or some such,
i.e, make clear that a config interface needs to be provided).

>    TIMESTAMP_DRIFT (see Section 11.

missing closing paren.

>       In the FQDN case the Name field is an "IDN-unaware domain name

s/case/case,/

>    Note that RFC 2461 rules prevent a host from accepting a Redirect
>    message from a router that is not its default router. This prevents
>    an attacker from tricking a node into redirecting traffic when the
>    attacker is not the default router.

nit: the rules in 2461 say one only accepts a redirect from the router
a host is using to reach the destination mentioned in the
redirect. That is slightly different.

James Kempf: We'll change it.

>    This specification does not address the protection of NDP packets for
>    nodes that are configured with a static address (e.g., PREFIX::1).
>    Future certificate chain-based authorization specifications are
>    needed for such nodes.

Or addresses configured under normal stateless addrconfig...

James Kempf: We'll add that.

>    SEND nodes MUST send only secured messages.  Plain (non-SEND)
>    Neighbor Discovery nodes will obviously send only insecure messages.
>    Per RFC 2461 [7], such nodes will ignore the unknown options and will
>    treat secured messages in the same way as they treat insecure ones.
>    Secured and insecure nodes share the same network resources, such as
>    prefixes and address spaces.

Wording odd. What is a "SEND node"? One that implements this spec?
That's too strong. It should be an operational choice whether to use
SEND or not, if it is implemented.

James Kempf: How about "node that has been configured to send and
accept only secure ND messages"?

Thomas Narten: Fine.

>       flag on entries indicating whether the entry issecured. Received

s/issecured/is secured/