Sorry to comment so late in the game.  I haven't been involved in SEND
but I was reading through the draft yesterday and came across a few
items that seem worth mentioning.

If it's not too late then...

*  In section 8, p47, the second dot point states:

      The Neighbor Cache, Prefix List and Default Router list entries
      MUST have a secured/unsecured flag that indicates whether the
      message that caused the creation or last update of the entry was
      secured or unsecured." ...

But then the second last sentence of the same point states:

      ... "The Neighbor Cache SHOULD implement a
      flag on entries indicating whether the entry is secured." ...

The "SHOULD" in this second sentence seems to already be covered by the
earlier "MUST", and perhaps should be removed.


*  In section 5.2.4 Perfomance Considerations, there seems to be a minor inconsistancy.

At the end of the second paragraph it states:

A. ... "A large number of router
   solicitations may cause higher demand for performing asymmetric
   operations, although the base NDP protocol limits the rate at which
   responses to solicitations can be sent."

This is true for multicast RAs - they are limited by
MIN_DELAY_BETWEEN_RAS - but unicast RAs are just delayed, not
rate-limited.  This might be ok if we expect most solicted RAs to be
multicast, but the next paragraph then states:

B. ... "Typically, solicited advertisements are sent to the unicast
   address from which the solicitation was sent." ...

I'm not sure what the best way to resolve this is.  On the one hand it
might be simplest to just remove the text after the comma in block A.
However, I'm not sure about block B.  Is this an observation about
typical implementations?  RFC2461 (and the bis draft)
states in section 6.2.6 that a router may send unicast responses but the
usual case will be to multicast (which actually supports the text in
block A). Perhaps block B is mainly referring to neighbour
advertisements.

I guess my suggestion would be to either change block B with:

s/solicited advertisements/solicited neighbor advertisements/

or remove the text after the comma in block A.


* typo in section 9.2.4, line 5.

s/subnet subnet/subnet/

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

Jari Arkko:

> The "SHOULD" in this second sentence seems to already be covered by the
> earlier "MUST", and perhaps should be removed.

Agreed. Thanks for catching this.

> *  In section 5.2.4 Perfomance Considerations, there seems to be a minor 
> inconsistancy.
> 
> At the end of the second paragraph it states:
> 
> A. ... "A large number of router
>    solicitations may cause higher demand for performing asymmetric
>    operations, although the base NDP protocol limits the rate at which
>    responses to solicitations can be sent."
> 
> This is true for multicast RAs - they are limited by
> MIN_DELAY_BETWEEN_RAS - but unicast RAs are just delayed, not
> rate-limited.  This might be ok if we expect most solicted RAs to be
> multicast, but the next paragraph then states:
> 
> B. ... "Typically, solicited advertisements are sent to the unicast
>    address from which the solicitation was sent." ...
> 
> I'm not sure what the best way to resolve this is.  On the one hand it
> might be simplest to just remove the text after the comma in block A.
> However, I'm not sure about block B.  Is this an observation about
> typical implementations?  RFC2461 (and the bis draft)
> states in section 6.2.6 that a router may send unicast responses but the
> usual case will be to multicast (which actually supports the text in
> block A). Perhaps block B is mainly referring to neighbour
> advertisements.
> 
> I guess my suggestion would be to either change block B with:
> 
> s/solicited advertisements/solicited neighbor advertisements/
> 
> or remove the text after the comma in block A.

I'd prefer the former.

> * typo in section 9.2.4, line 5.
> 
> s/subnet subnet/subnet/

Oops. Thanks.

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