Found 2 records.

Status: Verified (1)

RFC 7542, "The Network Access Identifier", May 2015

Errata ID: 5462
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2018-08-14
Verifier Name: Benjamin Kaduk
Date Verified: 2019-12-11

Section 3 says:

The "utf8-realm" SHOULD be supplied by the "next hop" or "home"
system that also supplies the routing information necessary for
packets to reach the next hop.

It should say:

The "utf8-realm" SHOULD be supplied by the "next hop" or "home"
system that also supplies the routing information necessary for
packets to reach the next hop.

The final home system SHOULD validate the NAI in the received packet
against the list of Realms hosted by the home system.  If no match
is found, the request SHOULD be rejected.

Notes:

It doesn't explicitly say that home systems only authenticate users for their own realms. It may help to have this stated explicitly.

Some text will also be added to draft-ietf-radext-coa-proxy in order to make this clearer.

Status: Reported (1)

RFC 7542, "The Network Access Identifier", May 2015

Errata ID: 8105
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew Ogilvie
Date Reported: 2024-09-16

Section 3.4 says:

Examples of valid Network Access Identifiers include the following:
[...]
        \(user\)@example.net

It should say:

Examples of invalid Network Access Identifiers include the following:
[...]
        \(user\)@example.net

Notes:

\(user\)@example.net is listed as a valid example, but neither backslashes nor parentheses are allowed in the ABNF rules (sections 2.1 and 2.2). Obsoleted RFC 4282 had ABNF rules to allow for backslash escapes, but RFC 7542 does not. These are the only backslashes in the entire document.

Perhaps this example should be moved to the invalid examples list?

Or perhaps the ABNF rules should be extended to allow some forms of backslash escapes, although probably not to the same wide-open extent as RFC 4282?

Report New Errata