The IESG has approved the following document: - 'Dynamic Hostname Exchange Mechanism for IS-IS ' <draft-ietf-isis-rfc2763bis-00.txt> as a Proposed Standard This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-rfc2763bis-00.txt 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. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
