Internationalization for the NFSv4 Protocols
draft-ietf-nfsv4-internationalization-17

IETF-LC comments resulted in -17 and continue to be received.
A further revision may be needed, unless all agree the document is now ready.

Please send any comments/requests relating to this latest version by noon your time on Friday 14th August 2026

The following Last Call announcement was sent out (ends 2026-08-03):

From: The IESG
To: IETF-Announce
CC: beepee@gmail.com, draft-ietf-nfsv4-internationalization@ietf.org, gorry@erg.abdn.ac.uk, nfsv4-chairs@ietf.org, nfsv4@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Internationalization for the NFSv4 Protocols) to Proposed Standard


The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document: - 'Internationalization for the
NFSv4 Protocols'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-08-03. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the handling of internationalization for all
  NFSv4 protocols, including NFSv4.0, NFSv4.1, NFSv4.2 and extensions
  thereof, and future minor versions.

  It updates RFC7530 and RFC8881.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-internationalization/



No IPR declarations have been submitted directly on this I-D.

# Shepherd Writeup: draft-ietf-nfsv4-internationalization-16

## Document History

**1. WG consensus: strong concurrence of a few, or broad agreement?**

Rough consensus reflecting the small active participant community. The document has not been opposed, and the substantive engagement came from non-WG experts (Klensin, Gulbrandsen, Williams) who found it technically sound. No WG member has objected to publication.

**2. Was there controversy or particularly rough consensus?**

No. The fundamental technical direction has not been disputed. Review comments have been editorial, terminological, or refining; the author has been responsive across sixteen revisions.

**3. Has anyone threatened appeal or indicated extreme discontent?**

No.

**4. Existing implementations?**

The UTF8-unaware behavior codified here is universally implemented across all major NFSv4 implementations (Linux, FreeBSD, Solaris/illumos, NetApp ONTAP). The optional UTF8-aware features (canonical equivalence, case-insensitive comparison) have only limited experimental implementation.

## Additional Reviews

**5. Interaction with other groups; external reviews?**

ARTART (Arnt Gulbrandsen, "Almost Ready" on -15, 2026-05-12) and I18NDIR (Nicolás Williams, "On the right track" on the predecessor individual draft in 2020). John C. Klensin reviewed -14 ("outstanding") and provided substantive comments on -15 in February 2026. The author's disposition of the Klensin comments is reflected in -16.

**6. Formal expert review criteria (MIB, YANG, media type, URI)?**

None apply.

**7. YANG module?**

None.

**8. Formal language (XML, BNF, MIB, CDDL)?**

None.

## Document Shepherd Checks

**9. Is the document needed, clearly written, complete, correctly designed, and ready?**

Yes. The document corrects a long-standing specification/implementation divergence (RFC 8881's i18n text was never implemented; implementations followed the NFSv4.0 approach) by formally codifying actual implementation behavior across all NFSv4 minor versions. Minor editorial items remain; none are blocking.

**10. Common area-review issues identified?**

One open IDNA question warrants AD attention. Klensin's February 2026 review on -15 raised three points concerning the IDN treatment in §11: (a) awareness of three IDN standards including UTS#46, (b) U-label/A-label terminology cleanup, and (c) the "such domains do not exist" framing in light of emoji-TLD reality. The author's disposition document indicated all three would be addressed via a conversion to UTS#46. In the shipped -16, UTS#46 was instead removed from normative references, RFC 3492 (Punycode) was added as normative, and RFC 5890 (IDNA2008) became the normative IDN basis. The shepherd's view is that this is a defensible direction that did not match the disposition Noveck circulated, and the three Klensin points are not addressed in the way the disposition anticipated. The shepherd is flagging this to the AD so the IDNA direction is reviewed on its merits rather than assumed to match the original disposition.

**11. RFC type and why?**

Proposed Standard. The document updates RFC 7530 and RFC 8881 with normative specifications for i18n handling.

**12. IPR disclosures filed?**

No IPR disclosures have been filed. Authors have been reminded.

**13. Authors willing to be listed; >5 authors justified?**

Yes. Single author (David Noveck).

**14. Remaining I-D nits?**

None.

**15. Should any references change between normative and informative?**

No.

**16. Normative references not freely available?**

The Unicode Standard v17.0.0 and CaseFolding-17.0.0 are externally published but freely available from the Unicode Consortium.

**17. Downrefs not in the registry?**

None. All normative IETF references are Standards Track or BCP.

**18. Normative references to documents in unclear state?**

No.

**19. Will publication change the status of existing RFCs?**

Yes. Updates RFC 7530 (NFSv4.0) and RFC 8881 (NFSv4.1). The RFC 7530 internationalization approach was implementation-based; this document refines that with minor adjustments. The RFC 8881 internationalization text was never implemented; this document replaces it with a specification matching actual implementation behavior. NFSv4.2 (RFC 7862) is covered by implicit inheritance and does not need to be marked updated (see Appendix C).

**20. IANA Considerations review.**

§13 states no IANA actions. Verified.

**21. New IANA registries requiring Designated Expert Review?**

None.

# Shepherd Writeup: draft-ietf-nfsv4-internationalization-16

## Document History

**1. WG consensus: strong concurrence of a few, or broad agreement?**

Rough consensus reflecting the small active participant community. The document has not been opposed, and the substantive engagement came from non-WG experts (Klensin, Gulbrandsen, Williams) who found it technically sound. No WG member has objected to publication.

**2. Was there controversy or particularly rough consensus?**

No. The fundamental technical direction has not been disputed. Review comments have been editorial, terminological, or refining; the author has been responsive across sixteen revisions.

**3. Has anyone threatened appeal or indicated extreme discontent?**

No.

**4. Existing implementations?**

The UTF8-unaware behavior codified here is universally implemented across all major NFSv4 implementations (Linux, FreeBSD, Solaris/illumos, NetApp ONTAP). The optional UTF8-aware features (canonical equivalence, case-insensitive comparison) have only limited experimental implementation.

## Additional Reviews

**5. Interaction with other groups; external reviews?**

ARTART (Arnt Gulbrandsen, "Almost Ready" on -15, 2026-05-12) and I18NDIR (Nicolás Williams, "On the right track" on the predecessor individual draft in 2020). John C. Klensin reviewed -14 ("outstanding") and provided substantive comments on -15 in February 2026. The author's disposition of the Klensin comments is reflected in -16.

**6. Formal expert review criteria (MIB, YANG, media type, URI)?**

None apply.

**7. YANG module?**

None.

**8. Formal language (XML, BNF, MIB, CDDL)?**

None.

## Document Shepherd Checks

**9. Is the document needed, clearly written, complete, correctly designed, and ready?**

Yes. The document corrects a long-standing specification/implementation divergence (RFC 8881's i18n text was never implemented; implementations followed the NFSv4.0 approach) by formally codifying actual implementation behavior across all NFSv4 minor versions. Minor editorial items remain; none are blocking.

**10. Common area-review issues identified?**

One open IDNA question warrants AD attention. Klensin's February 2026 review on -15 raised three points concerning the IDN treatment in §11: (a) awareness of three IDN standards including UTS#46, (b) U-label/A-label terminology cleanup, and (c) the "such domains do not exist" framing in light of emoji-TLD reality. The author's disposition document indicated all three would be addressed via a conversion to UTS#46. In the shipped -16, UTS#46 was instead removed from normative references, RFC 3492 (Punycode) was added as normative, and RFC 5890 (IDNA2008) became the normative IDN basis. The shepherd's view is that this is a defensible direction that did not match the disposition Noveck circulated, and the three Klensin points are not addressed in the way the disposition anticipated. The shepherd is flagging this to the AD so the IDNA direction is reviewed on its merits rather than assumed to match the original disposition.

**11. RFC type and why?**

Proposed Standard. The document updates RFC 7530 and RFC 8881 with normative specifications for i18n handling.

**12. IPR disclosures filed?**

No IPR disclosures have been filed. Authors have been reminded.

**13. Authors willing to be listed; >5 authors justified?**

Yes. Single author (David Noveck).

**14. Remaining I-D nits?**

None.

**15. Should any references change between normative and informative?**

No.

**16. Normative references not freely available?**

The Unicode Standard v17.0.0 and CaseFolding-17.0.0 are externally published but freely available from the Unicode Consortium.

**17. Downrefs not in the registry?**

None. All normative IETF references are Standards Track or BCP.

**18. Normative references to documents in unclear state?**

No.

**19. Will publication change the status of existing RFCs?**

Yes. Updates RFC 7530 (NFSv4.0) and RFC 8881 (NFSv4.1). The RFC 7530 internationalization approach was implementation-based; this document refines that with minor adjustments. The RFC 8881 internationalization text was never implemented; this document replaces it with a specification matching actual implementation behavior. NFSv4.2 (RFC 7862) is covered by implicit inheritance and does not need to be marked updated (see Appendix C).

**20. IANA Considerations review.**

§13 states no IANA actions. Verified.

**21. New IANA registries requiring Designated Expert Review?**

None.

# Shepherd Writeup: draft-ietf-nfsv4-internationalization-16

## Document History

**1. WG consensus: strong concurrence of a few, or broad agreement?**

Rough consensus reflecting the small active participant community. The document has not been opposed, and the substantive engagement came from non-WG experts (Klensin, Gulbrandsen, Williams) who found it technically sound. No WG member has objected to publication.

**2. Was there controversy or particularly rough consensus?**

No. The fundamental technical direction has not been disputed. Review comments have been editorial, terminological, or refining; the author has been responsive across sixteen revisions.

**3. Has anyone threatened appeal or indicated extreme discontent?**

No.

**4. Existing implementations?**

The UTF8-unaware behavior codified here is universally implemented across all major NFSv4 implementations (Linux, FreeBSD, Solaris/illumos, NetApp ONTAP). The optional UTF8-aware features (canonical equivalence, case-insensitive comparison) have only limited experimental implementation.

## Additional Reviews

**5. Interaction with other groups; external reviews?**

ARTART (Arnt Gulbrandsen, "Almost Ready" on -15, 2026-05-12) and I18NDIR (Nicolás Williams, "On the right track" on the predecessor individual draft in 2020). John C. Klensin reviewed -14 ("outstanding") and provided substantive comments on -15 in February 2026. The author's disposition of the Klensin comments is reflected in -16.

**6. Formal expert review criteria (MIB, YANG, media type, URI)?**

None apply.

**7. YANG module?**

None.

**8. Formal language (XML, BNF, MIB, CDDL)?**

None.

## Document Shepherd Checks

**9. Is the document needed, clearly written, complete, correctly designed, and ready?**

Yes. The document corrects a long-standing specification/implementation divergence (RFC 8881's i18n text was never implemented; implementations followed the NFSv4.0 approach) by formally codifying actual implementation behavior across all NFSv4 minor versions. Minor editorial items remain; none are blocking.

**10. Common area-review issues identified?**

One open IDNA question warrants AD attention. Klensin's February 2026 review on -15 raised three points concerning the IDN treatment in §11: (a) awareness of three IDN standards including UTS#46, (b) U-label/A-label terminology cleanup, and (c) the "such domains do not exist" framing in light of emoji-TLD reality. The author's disposition document indicated all three would be addressed via a conversion to UTS#46. In the shipped -16, UTS#46 was instead removed from normative references, RFC 3492 (Punycode) was added as normative, and RFC 5890 (IDNA2008) became the normative IDN basis. The shepherd's view is that this is a defensible direction that did not match the disposition Noveck circulated, and the three Klensin points are not addressed in the way the disposition anticipated. The shepherd is flagging this to the AD so the IDNA direction is reviewed on its merits rather than assumed to match the original disposition.

**11. RFC type and why?**

Proposed Standard. The document updates RFC 7530 and RFC 8881 with normative specifications for i18n handling.

**12. IPR disclosures filed?**

No IPR disclosures have been filed. Authors have been reminded.

**13. Authors willing to be listed; >5 authors justified?**

Yes. Single author (David Noveck).

**14. Remaining I-D nits?**

Several editorial items identified by the shepherd to be cleaned up in the final pass:

- §4: broken opening sentence "The making this shift…"
- §10: missing space in `'xn--'formed`
- §11: "ACII" should be "ASCII"
- §11.2: prose reads "RFCs 7530 ... and 8811" — should be 8881 (citation tag is correct)
- §11: stray close-parenthesis in "Section 12.6) of [RFC7530]"
- Appendix A intro: "would e needed" — missing "be"
- Appendix C: "discusssed" (triple s)
- Acknowledgements: "Christoph Helwig" should be Hellwig
- Inconsistent casing of "NFsv4.1" / "NFsv4.2" in several places
- B.3: "any UTF8-to-UCS conversions" — should read "UTF-8-to-Unicode" for consistency with §12

None are normative.

**15. Should any references change between normative and informative?**

No.

**16. Normative references not freely available?**

The Unicode Standard v17.0.0 and CaseFolding-17.0.0 are externally published but freely available from the Unicode Consortium.

**17. Downrefs not in the registry?**

None. All normative IETF references are Standards Track or BCP.

**18. Normative references to documents in unclear state?**

No.

**19. Will publication change the status of existing RFCs?**

Yes. Updates RFC 7530 (NFSv4.0) and RFC 8881 (NFSv4.1). The RFC 7530 internationalization approach was implementation-based; this document refines that with minor adjustments. The RFC 8881 internationalization text was never implemented; this document replaces it with a specification matching actual implementation behavior. NFSv4.2 (RFC 7862) is covered by implicit inheritance and does not need to be marked updated (see Appendix C).

**20. IANA Considerations review.**

§13 states no IANA actions. Verified.

**21. New IANA registries requiring Designated Expert Review?**

None.

We have lined up the reviews and have positive feedback on moving this document to WGLC and headed for publication.  Let's start a 1-week WGLC since we have a number of thumbs up on the list for this document already.