[nfsv4] Re: numeric vs, name@domain representations of users and groups

[David Noveck <[e-mail]>]

On Sun, Jun 7, 2026 at 4:04 PM Chuck Lever <[e-mail]> wrote:

>
> On Sun, Jun 7, 2026, at 3:24 PM, David Noveck wrote:
> > *Introduction*
> > I'd like to thank everybody who participated in this discussion.  I
> think I
> > know what I'm going to say in the drafts that I will send out next. week
> .
> > *Limits on Immediate work and unacceptability of waiting for NFSv4.3*
> > What I can reasonably do affecting NFSv4.[01] is quite limited because of
> > the existence of existing implementations and the rules in RFC8178.  I
> hope
> > that, as we did with draft-POSIX ACLs is to prepare v4.1 in light of what
> > we plan to do for v4.2.  I expect the work undoubtedly needed for this
> area
> > in the respecification effort will appear in
> > *draft-noveck-nfsv4-security-15.*
> > Regarding doing major work in v4.3, I can see that being done but I'd
> like
> > to do much of the *MANDATORY* changes for v4.3 to be done on an
> *OPTIONAL*
> > basis and publish first in NFSv4,2 (as an extension) with some
> experimental
> > use, and then only flip the switch to delete things and make additions
> > *MANDATORY* as part of a small NFSv4.3.  My feeling about getting started
> > on the work to become multi-domain in practice is strengthened by:
> >
> >    - The length of time it has already taken to do the v4.2
> >    respecification effort  and the lack of an ETA due WG administration
> >    difficulties.
> >    - It is now about 25 years since "@domain" was added to the owner
> >    attribute.  Since supporting multiple domains was an important NFSv4
> goal,
> >    I think we need to enable this ASAP so waiting for an uncertain
> NFSv4.3
> >    start date is not reasonable.
> >
> > *Preparing for future work*
> > It appears that we will need some extensions to NFSv4.2.  This affects
> v4.1
> > documents (e.g. *draft-ietf-nfsv4-rfc8881bis*) and NFS-wide documents
> (e.g.
> > *draft-dnoveck-nfsv4-security*) differently"
> >
> >    - My views regarding needed future work to build on the
> respecification
> >    effort will appear in a new Appendix D.2.21 within
> >    *draft-ietf-nfsv4-rfc8881bis-08.*
> >
> > It will suggest the possibility of accepting integer@domain in a future
> > minor version and also some other helpful extensions to make management
> of
> > multi-domain configurations possible.  The intention is to avoid mapping
> > from (0, 2^32) x {d|  d is a supported domain} to (0,2^32) which is
> > difficult to manage and may be impossible for many production
> environments,
> > by a new approach to by set a of mappings from name to  numeric id and a
> > simple mapping from the set of supported domains.
> >
> > I think this can be motivated without too much dissonance by pointing out
> > the difficulties of creating and maintaining the complicated mapping of
> the
> > cross-product described above.  The existing text never says that it has
> to
> > map to that small a set although many people might assume assume file
> > system uid/gis have to be that small.  Nevertheless, we have to encourage
> > people to do what they can.   In this case the vaguenesss of te discussin
> > of internal and external forms can be helpful, with the
> > possibility "integer@domin" making it clear that expansion of the id
> space
> > is needed without getting intp too many details
>
> This is a process objection, not a technical objection:
>
> I invite and encourage the working group to consider the alternative
> of NOT adding any of this to rfc8881bis. The ID mapping proposal is an
> extension to a subsequent minor version of NFSv4, not to NFSv4.1 itself.
>

I can certainly, when the next draft is published, reduce scope of this
discussion, but, as to the idea of NOT adding *any of this* (emphasis added)
to *draft-ietf-rfc8881 bis-08* I don't believe that it is reasonable to
discuss
the problems with "name@domain" that have resulted in a situation in which,
decades later, in tthe lack of the intended multi-domain support.
The specification of users as "name@domain" had the unfortunate
result of taking two separate problems: the need for multi-domain support
and presentation of users by name as uids, and combining them so
that the multi domain problem,which requires file system work was never
addressed.

> Therefore:
>
> - Let's not add any problem statement or discussion of the requirements
>   for the ID mapping extension to rfc8881bis.
>

You're going to have to discuss the fact that there is a problem  here
without
committing oneself to a particular solution.  However, I cannot say that
there
is no problem or that we are in a hopeless situation.

- There is no normative requirement that I am aware of to announce that
>   "a future extension will introduce integer@domain".
>

True but irrelevant.  If there were a normative requirement to *not* do so,
we
could argue about that but I will inevitably do things that there are not
affected
by normative requirement until the set of such requirements expands to the
point that an event horizon forms :-(

- Working around "unexplained administrative delays" is not an excuse
>   to stretch the scope of rfc8881bis.
>

Fair enough.

>
> Instead, pursue the ID mapping extension work via documents separate
> from rfc8881bis. Start with a personal draft, as the maker intended.
>

I can do that.

>
>
> --
> Chuck Lever
>
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>