<html>
    <head>
      <base href="https://bugzilla.netfilter.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - add set - syntax has changed - update documentation"
   href="https://bugzilla.netfilter.org/show_bug.cgi?id=1299#c8">Comment # 8</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - add set - syntax has changed - update documentation"
   href="https://bugzilla.netfilter.org/show_bug.cgi?id=1299">bug 1299</a>
              from <span class="vcard"><a class="email" href="mailto:james@nurealm.net" title="James Feeney <james@nurealm.net>"> <span class="fn">James Feeney</span></a>
</span></b>
        <pre>Reflecting on this further, I'd say that the concepts of "address family
specific namespaces" and "table names" is the *very foundation*, the "top
level", of the nftables User Interface.

So, the man page should not just "toss off" discussion of these two
foundational concepts with one or two sentences buried in the middle of the man
page with no header.

They really ought to be the first thing that the reader sees, after the syntax
formalities:

NAMESPACES AND TABLE NAMES
...
        ADDRESS FAMILIES
        ...
                IPV4/IPV6/INET ADDRESS FAMILIES
                ...
        ...

If I understand, the set of all "nftables objects" includes, in addition to
"tables", also, basically, all of the "header" items in the man page, "chains",
"rules", "sets", "maps", etc.  And each of these exists within a distinct and
separate namespace.  So "address_family" is at the top of a hierarchy,
"table_name" is a second level object, "sets, chains, maps, etc." are third
level, "types, hooks, flags, etc." are fourth level, and "rules" are last.

It is a bit unfortunate that the configuration syntax is "TABLE
<address_family> <table_name>" instead of "FAMILY <address_family>
<table_name>", since "address family" is at the *top* of the "rule" hierarchy,
the most fundamental division.  

It's never too late to change that, or, at least, accept both key-words
equivalently.  That would smooth-out the nftables learning curve.  A mrore
consistent format would have "FAMILY <address_family> { TABLE <table_name>
{...} TABLE <table_name> {...} }".

It would be helpful to include a full list of all "nftables objects" in an
opening NAMESPACES section of the man page, categorized by their place in a
hierarchy, completely enumerating the set members, to orient the reader.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are watching all bug changes.</li>
      </ul>
    </body>
</html>