[nfsv4] Re: Call for Agenda Items for NFSv4 WG IETF 127, San Francisco

[David Noveck <[e-mail]>]

On Monday, October 12, 2026, Rick Macklem <[e-mail]> wrote:

> On Fri, Sep 25, 2026 at 2:34 PM Brian Pawlowski <[e-mail]> wrote:
> >
> > Good day. It's time to bash the proposed agenda for IETF 127 for the
> NFSv4 Working Group:
> >
> > The chairs have requested a single two-hour session for IETF 127, 14 to
> 20 November in San Francisco. Bash proposed agenda below and send
> additions/objections/time requests to the list by Friday 2 October 2026.
> Authors please confirm you will present.
> >
> > 1. Chairs (15 min)
> >    Note Well, agenda bash.
> >
> >    Document status since Vienna: uncacheable-files (approved 17
> September, RFC Editor queue); internationalization (with the shepherd; -18
> expected); uncacheable-directories; security-15 adoption call result.
> >
> >    Milestones: the current ones are all past. Proposal to reset them to
> match the plan below.
> >
> > 2. rfc8881bis (20 min) - chairs, Noveck
> >    The question for the room: a bis that is a bounded set of corrections
> and clarifications against RFC 8881, reviewed from diffs, versus the
> current 876-page rewrite. Related: the XDR (rfc5662bis)
>
> I'll assume there is no IETF mechanism for doing revisions to a document
> instead of a complete replacement?


The normal mechanism is to raise the issue with the author on the working
group list. I don't  know about any other mechanism.  This can happen at
any time up to and including WGLC.

There is no mechanism to do a complete replacement.   Only if a document is
rejected for some reason is there an occasion to consider a replacement.
That is what the chairs are confused about.


> (This would be a lot easier if each revision could be handled separately.
>  W.r.t. revisions, I am not referring to small changes that could be
> considered
>  errata.)


What are you  referring to?


> There are changes in 8881bis, such as the ones for directory delegations,
> which I would definitely like to see accepted.


The point is that they have been effectively accepted and will be included
in the final document unless someone gives me a valid reason to remove
them.  There is no mechanism to unaccept them.  That is the reason that
this agenda item is inapproprIate..  I  have asked that it be expunged and
I hope that will soon happen.

The  chairs seem to be confused about the process both here and in item 6
where it is assumed that the chairs have the right to delay adoption calls
and WGLCs at will.

We need to clear up these mistakes.  If that doesn't happen before ietf127,
it will need to be discussed in San Francisco.


> rick
> >
> > 3. NFSv4 security (25 min) - chairs
> >    The adoption call on draft-dnoveck-nfsv4-security-15 ended with no
> consensus to adopt. Nobody disputed that the security text in RFC 8881
> needs correcting. The room decides: what document, of what size, written
> and reviewed by whom. The existing draft's material remains available as
> source (BCP 78).
> >
> > 4. NFSv4.0 (10 min) - [Haynes]
> >    Whether the WG should move RFC 7530 to Historic, and what that means
> for the "Updates: 7530" line every companion document carries.
> >
> > 5. Flexible Files v2 (20 min) - Haynes
> >    The split into a core document and companions, and the MTI encoding
> shortlist. Goal: agree to the shape so that an adoption call on the core
> document can run after the meeting.
> >
> > 6. Adoption and WGLC pipeline (10 min) - chairs
> >    Given working group bandwidth we want to meter adoption and WGLC to
> avoid overlap in future. Here is the proposed priority ordering:
> rpc-tls-othername (adoption), posix-acls (WGLC), recalldevice (adoption),
> nfs-acl (WGLC, after the meeting). Status of each and who runs it.
> >
> > 7. Open discussion (20 min)
> >
> > NFS Version 4 WG Co-chairs
> > Chuck Lever
> > Brian Pawlowski
> > _______________________________________________
> > nfsv4 mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>