Found 2 records.

Status: Held for Document Update (2)

RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", December 1990

Note: This RFC has been updated by RFC 1349, RFC 5302, RFC 5304

Errata ID: 683
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Joerg Ammon
Date Reported: 2003-03-04
Held for Document Update by: Stewart Bryant

Section 3.3 says:

In chapter '3.3 Addressing Routers in ISIS Packets' the RFC describes a
standard procedure
for deriving NSAP-addresses for IS in IP-only environments. However, the
DFI as well as the AA
are defined to be 'xx' and 'xx xx xx' respectively, which represents
neither a valid decimal nor
hexadecimal value.

It should say:

[not submitted]

Notes:

from pending

Errata ID: 3741
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeffrey Zhang
Date Reported: 2013-10-01
Held for Document Update by: Adrian Farrel
Date Held: 2013-10-19

Section 5.3.5 says:

5.3.5 Level 2 Link State PDU
    ...
    IP Internal Reachability Information -- IP addresses within the
    routing domain reachable directly via one or more interfaces on
    this Intermediate system.

It should say:

    IP Internal Reachability Information -- IP addresses within the
    routing domain reachable directly via one or more interfaces on
    this Intermediate system, or indirectly via level 1 routing.
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Notes:

Currently, the relevant text in 5.3.2 and 5.3.5 are identical, but the 5.3.5 text should have the above text added.

This would match the following (see the last clause):

5.2 Overview of IP-Specific Information for IS-IS

The "IP Internal Reachability Information" field ...
If included in level 1 LSPs,
this field includes only entries directly reachable by the router
which originates the LSP, via one of its interfaces. If included in
level 2 LSPs, this field includes only entries reachable by the
router which originates the LSP, either via one of its interfaces, or
indirectly via level 1 routing.


I have marked this report as "held for document update" although I do not expect any new revision to RFC 1195. This "correction" is more of a clarification. The "corrected" text can be successfully deduced from the rest of the document such that nobody reading the document in its entirety would be led to make an incorrect and/or non-interoperable implementation.

Furthermore, any clarifications necessary have previously been published in the informational RFCs 3719 and in particular 3787.

However, there is some value in retaining this record for future enquiring minds (and to stop a similar report being raised in the future).

Report New Errata