Netdev List
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: David 'equinox' Lamparter <equinox@diac24.net>
Cc: netdev@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH net-next 9/9] net: document RFC6724 rule 5.5 implementation
Date: Tue, 14 Jul 2026 11:31:18 -0600	[thread overview]
Message-ID: <878q7deavt.fsf@trenco.lwn.net> (raw)
In-Reply-To: <alZvBEPH86WqH56m@eidolon.nox.tf>

David 'equinox' Lamparter <equinox@diac24.net> writes:

> On Tue, Jul 14, 2026 at 07:01:13AM -0600, Jonathan Corbet wrote:
>> David 'equinox' Lamparter <equinox@diac24.net> writes:
>> >  create mode 100644 Documentation/networking/ipv6-addrsel.rst
>>
>> You need to add this new document to the index.rst file or it won't be
>> part of the docs build...you should have seen a warning when you built
>> the docs.
>
> Indeed... I missed it between the other warnings.  Downside of doing
> clean runs without a sphinx cache, sigh.

*Sigh* ... one of these years we'll clean up all those warnings, and
have them actually stay cleaned...

>> > +====================================
>> > +IPv6 source address selection trivia
>> > +====================================
>> > +
>> > +
>> > +RFC6724 rule 5.5 support
>> > +------------------------
>>
>> Please stick with the section markup guidelines in
>> Documentation/doc-guide/sphinx.rst.
>
> Oh, you mean I shouldn't skip the "Chapter" level?
>
> Now that you mention it, maybe I should include the file from ipv6.rst,
> and remove the document title entirely - it looks quite weird in the TOC
> with the direct reference from index.rst.  (Or rather, I've made weird
> choices with the headings.)  Does that sound good to you?
>
> (Or, I could just put the entire text into ipv6.rst...)

I would take that latter approach myself.  But others may differ :)

>> > +RFC6724 rule 5.5 is a very short paragraph in a complex RFC that has turned
>> > +out quite tricky, but also immensely useful in multihoming scenarios.  For
>> > +reference, it says:
>> > +
>> > +::
>> 
>> You'll likely get more visually pleasing results if you just leave out
>> the "::" here; you don't need literal formatting.
>
> I did that because RFCs are historically shipped & cited monospaced, and
> that's direct from the RFC.  My tendency is to keep it this way for
> "established convention" reasons, but I don't care that much - does
> anyone have stronger feelings?

You're writing the document, it's up to you in the end.

(But if you keep it that way, you can end the previous paragraph with
"it says::" and drop the separate "::" line).

Thanks,

jon

      reply	other threads:[~2026-07-14 17:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-14  9:40 [PATCH net-next 0/9] RFC 6724 rule 5.5 support David 'equinox' Lamparter
2026-07-14  9:40 ` [PATCH net-next 1/9] net/ipv6: fix lookup for ::/0 (non-)subtree route David 'equinox' Lamparter
2026-07-14  9:40 ` [PATCH net-next 2/9] net/ipv6: flatten ip6_route_get_saddr David 'equinox' Lamparter
2026-07-14  9:40 ` [PATCH net-next 3/9] net/ipv6: create ipv6_fl_get_saddr David 'equinox' Lamparter
2026-07-14  9:40 ` [PATCH net-next 4/9] net/ipv6: use ipv6_fl_get_saddr in output David 'equinox' Lamparter
2026-07-14  9:40 ` [PATCH net-next 5/9] net/ipv6: drop ip6_route_get_saddr David 'equinox' Lamparter
2026-07-14  9:40 ` [PATCH net-next 6/9] net/ipv6: flip IPV6_SUBTREES default to Y David 'equinox' Lamparter
2026-07-14  9:40 ` [PATCH net-next 7/9] net/ipv6: support RFC6724 rule 5.5 via subtrees David 'equinox' Lamparter
2026-07-14  9:40 ` [PATCH net-next 8/9] selftests: net: RFC6724 rule 5.5 tests David 'equinox' Lamparter
2026-07-14  9:40 ` [PATCH net-next 9/9] net: document RFC6724 rule 5.5 implementation David 'equinox' Lamparter
2026-07-14 13:01   ` Jonathan Corbet
2026-07-14 17:16     ` David 'equinox' Lamparter
2026-07-14 17:31       ` Jonathan Corbet [this message]

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=878q7deavt.fsf@trenco.lwn.net \
    --to=corbet@lwn.net \
    --cc=equinox@diac24.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=netdev@vger.kernel.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