Subject: Protocol Action: 'Dynamic Hostname Exchange Mechanism for IS-IS' to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 22 Jul 2008 07:52:01 -0700 (PDT)

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 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce