Subject: Some comments on draft-ietf-send-ndopt-06.txt

From: Brett Pentland <[email-masked]>
Date: Thu, 22 Jul 2004 12:27:19 +1000

Hi SEND folks,

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/

Hope this is useful.
Brett.
--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Fri, 23 Jul 2004 00:28:46 +0300

Brett,

 > earlier "MUST", and perhaps should be removed.

Agreed. Thanks for catching this.

 > or remove the text after the comma in block A.

I'd prefer the former.

 > * typo in section 9.2.4, line 5.

Oops. Thanks.

--Jari