Linux Documentation
 help / color / mirror / Atom feed
From: Bagas Sanjaya <bagasdotme@gmail.com>
To: Arun Ajith S <aajith@arista.com>, netdev@vger.kernel.org
Cc: davem@davemloft.net, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, dsahern@kernel.org,
	yoshfuji@linux-ipv6.org, kuba@kernel.org, pabeni@redhat.com,
	gilligan@arista.com, noureddine@arista.com, gk@arista.com
Subject: Re: [PATCH net] net/ipv6: Change accept_unsolicited_na to accept_untracked_na
Date: Fri, 27 May 2022 16:30:11 +0700	[thread overview]
Message-ID: <4ef24dae-bad0-9641-7eb9-7d8207d198be@gmail.com> (raw)
In-Reply-To: <20220527073111.14336-1-aajith@arista.com>

On 5/27/22 14:31, Arun Ajith S wrote:
> This change expands the current implementation to match the RFC. The
> sysctl knob is also renamed to accept_untracked_na to better reflect the
> implementation.
>

Say in imperative, "Expand and rename accept_unsolicited na to
accept_untracked_na" in both commit/patch subject and message.

> -accept_unsolicited_na - BOOLEAN
> +accept_untracked_na - BOOLEAN
>  	Add a new neighbour cache entry in STALE state for routers on receiving an
> -	unsolicited neighbour advertisement with target link-layer address option
> -	specified. This is as per router-side behavior documented in RFC9131.
> -	This has lower precedence than drop_unsolicited_na.
> +	neighbour advertisement with target link-layer address option specified
> +	if a corresponding entry is not already present.
> +	This is as per router-side behavior documented in RFC9131.
>  
> -	 ====   ======  ======  ==============================================
> -	 drop   accept  fwding                   behaviour
> -	 ----   ------  ------  ----------------------------------------------
> -	    1        X       X  Drop NA packet and don't pass up the stack
> -	    0        0       X  Pass NA packet up the stack, don't update NC
> -	    0        1       0  Pass NA packet up the stack, don't update NC
> -	    0        1       1  Pass NA packet up the stack, and add a STALE
> -	                        NC entry
> -	 ====   ======  ======  ==============================================
> +	This has lower precedence than drop_unsolicited_na.
>  

I think you should have made similar logical expansion of drop_unsolicited_na to
drop_untracked_na. Otherwise, ...

>  	/* RFC 9131 updates original Neighbour Discovery RFC 4861.
> -	 * An unsolicited NA can now create a neighbour cache entry
> -	 * on routers if it has Target LL Address option.
> +	 * NAs with Target LL Address option without a corresponding
> +	 * entry in the neighbour cache can now create a STALE neighbour
> +	 * cache entry on routers.
>  	 *
> -	 * drop   accept  fwding                   behaviour
> -	 * ----   ------  ------  ----------------------------------------------
> -	 *    1        X       X  Drop NA packet and don't pass up the stack
> -	 *    0        0       X  Pass NA packet up the stack, don't update NC
> -	 *    0        1       0  Pass NA packet up the stack, don't update NC
> -	 *    0        1       1  Pass NA packet up the stack, and add a STALE
> -	 *                          NC entry
> -	 * Note that we don't do a (daddr == all-routers-mcast) check.
> +	 *   entry accept  fwding  solicited        behaviour
> +	 * ------- ------  ------  ---------    ----------------------
> +	 * present      X       X         0     Set state to STALE
> +	 * present      X       X         1     Set state to REACHABLE
> +	 *  absent      0       X         X     Do nothing
> +	 *  absent      1       0         X     Do nothing
> +	 *  absent      1       1         X     Add a new STALE entry
>  	 */

The Documentation/ diff above drops behavior table but in the code comment
it is updated. Why didn't update in Documentation/ instead?

And my nitpick: for consistency, prefer en-US words over en-UK or mixed
varieties when writing (s/behaviour/behavior/gc, s/neighbour/neighbor/gc).

-- 
An old man doll... just what I always wanted! - Clara

  reply	other threads:[~2022-05-27  9:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-27  7:31 [PATCH net] net/ipv6: Change accept_unsolicited_na to accept_untracked_na Arun Ajith S
2022-05-27  9:30 ` Bagas Sanjaya [this message]
2022-05-27 11:30   ` Arun Ajith S

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ef24dae-bad0-9641-7eb9-7d8207d198be@gmail.com \
    --to=bagasdotme@gmail.com \
    --cc=aajith@arista.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=gilligan@arista.com \
    --cc=gk@arista.com \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=noureddine@arista.com \
    --cc=pabeni@redhat.com \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox