Found 1 record.

Status: Rejected (1)

RFC 3101, "The OSPF Not-So-Stubby Area (NSSA) Option", January 2003

Errata ID: 4767
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Chao Fu
Date Reported: 2016-08-08
Rejected by: Alia Atlas
Date Rejected: 2016-08-08

Section 2.5.(6).(e) says:

          (e) If the current LSA is functionally the same as an
              installed LSA (i.e., same destination, cost and non-zero
              forwarding address) then apply the following priorities in
              deciding which LSA is preferred:

                 1. A Type-7 LSA with the P-bit set.

                 2. A Type-5 LSA.

                 3. The LSA with the higher router ID.

              [NSSA]

It should say:

NULL (it should be deleted because no LSAs would be compared here.)

Notes:

If one LSA is Type-5 and the other is Type-7, one of them would be rejected at step (2.5.(3) ( please refer to OSPF mail list: https://mailarchive.ietf.org/arch/msg/ospf/KBoh5T75o-s7n_bL1knrc6uVlTs ). If both of them are Type-7 LSAs, one of them would be flushed according 2.4:
If two NSSA routers, both
reachable from one another over the NSSA, originate functionally
equivalent Type-7 LSAs (i.e., same destination, cost and non-zero
forwarding address), then the router having the least preferred LSA
should flush its LSA.

As a result, rule (e) would never be applied and should be removed.

--VERIFIER NOTES--
It is easy to envision a topology where an ABR for an NSSA receives an NSSA-LSA from an NSSA internal router and an AS-Exernal-LSA from originating routers that do not receive each others equivalent LSAs. Furthermore, even if this were not the case, the referenced text refers to LSAs that are both NSSA-LSAs as opposed to a
mixture of an NSSA-LSA and an AS-External-LSA.

Report New Errata