Technical Summary
This document defines a new TLV which allows the IS-IS routers to
flood their name-to-systemID mapping information across the IS-IS
network.
Working Group Summary
This is part of a series of seven IS-IS RFCs that were originally
published as informational for historic reasons, but that are now
being updated to proposed standard. There is broad consensus in the
WG for this change.
Document Quality
This is a very simple document that provides a capability that is
useful when doing manual diagnostics / debugging.
Personnel
Chris Hopps and Dave Ward have jointly worked as document shepherds
for this bunch of seven documents. Ross Callon is the responsible AD.
RFC Editor Note
This document obsoletes RFC2763 (as you might guess by the ID name).
Thus the header on the first page should say "obsoletes RFC2673.
The title for the Abstract is centered. It should of course be on
the left.
Please replace the abstract as follows:
OLD
Currently, there does not exist a simple and dynamic mechanism for
routers running IS-IS to learn about symbolic hostnames. This
document defines a new TLV which allows the IS-IS routers to flood
their name-to-systemID mapping information across the IS-IS network.
The intention of this document is to provide an update to
[RFC 2763].
NEW
RFC2763 defined a simple and dynamic mechanism for routers running
IS-IS to learn about symbolic hostnames. RFC 2763 defined a new TLV
which allows the IS-IS routers to flood their name-to-systemID
mapping information across the IS-IS network.
This document obsoletes RFC2763. This document moves the capability
provided by RFC 2763 to the standards track.
Section 6 (Acknowledgements). Second paragraph should be deleted.
This currently reads (in its entirety):
"Others to be provided....".
Please update section 5 (security considerations) as follows:
OLD
This document raises no new security issues for IS-IS.
NEW
Since the name-to-systemID mapping relies on information provided
by the routers themselves, a misconfigured or compromised router
can inject false mapping information. Thus, this information needs
to be treated with suspicion when e.g. doing diagnostics about a
suspected security incident.
This document raises no other new security issues for IS-IS.
Security issues with IS-IS are discussed in
[draft-ietf-isis-rfc3567bis].
Please add an informative reference to
[draft-ietf-isis-rfc3567bis]. Also, please hold
publication of this document until draft-ietf-isis-rfc3567bis
is published, so that we can reference the RFC, rather than
the Internet draft. Also note that we expect approval of
draft-ietf-isis-rfc3567bis within a few days of the
approval of this draft.
Please add the following paragraph to the end of section 3:
The VALUE field is encoded in 7-bit ASCII. If a user-interface
for configuring or displaying this field permits Unicode
characters, that user-interface is responsible for applying the
ToASCII and/or ToUnicode algorithm as described in [RFC3490] to
achieve the correct format for transmission or display.
Please add an informational reference to RFC3490.
Please add the following paragraph to the end of section 4:
If a system receives a mapping for a name or systemID which is
different from the mapping in the local cache, an implementation
SHOULD replace the existing mapping with the latest information.