Dynamic Hostname Exchange Mechanism for OSPF
RFC 5642

Note: This ballot was opened for revision 04 and is now closed.

( Ron Bonica ) Yes

( Ross Callon ) Yes

( Adrian Farrel ) (was Discuss) Yes

Comment (2009-07-01 for -05)
Section 1
   It is obvious that...
I *hate* being told that something is obvious. This text does not add anything
to the I-D.

Section 2
s/DNS can be used for the same./DNS could be used for this./
s/Routers who don't understand/Routers that don't understand/

Section 3
   The Dynamic Hostname TLV (see Section 3.1) is OPTIONAL.  Upon receipt
   of the TLV a router may decide to ignore this TLV, or to install the
   symbolic name and Router ID in its hostname mapping table.
Is it worth highlighting that "ignore" means "not act on, but continue to flood
as part of the LSA." ?

Section 3.1
   Value    Hostname, a string of 1 to 255 octets, padded to 4-octet
            alignment, encoded in the US-ASCII charset.
Do you care whether this is padded with any character?

FQDN should be expanded on first use.

( Ralph Droms ) No Objection

Comment (2009-06-30 for -)
Is there any impact from name collisions if two routers use the same Dynamic
Hostname.  I don't think there is other than potential confusion in reading and
using the mapping information.  For completeness, it might be useful to add a
couple of sentences explaining that name conflicts aren't crucial and,
therefore, there is no conflict detection or resolution in the protocol.

Editorial suggestion: expand "FQDN" on first use in section 3.1?  I don't
understand this sentence in section 3.1:

   The content of this value is a domain
   name, see [RFC2181].

"this value" == value field in the Dynamic Hostname TLV?  What does it mean for
the dynamic hostname to be a "domain name"?  Can't it also be an arbitrary
identifier chosen by the OSPF admin or does it somehow have to relate to a name
from the DNS?

( Lisa Dusseault ) No Objection

Comment (2009-07-01 for -)
I agree with the comment that this draft should be more clear in the difference
between a hostname and a display name for a router.  Using the terms 'host' and
"host name" imply that the node is reachable at that host name.  OTOH if this
was just a display name, then presumably RFC3490 wouldn't apply.

( Lars Eggert ) (was Discuss) No Objection

Comment (2009-07-01 for -05)
INTRODUCTION, paragraph 2:
> Dynamic Hostname Exchange Mechanism for OSPF

  The names exchanged in this option name *routers*, not hosts. The
  terminology is hence pretty confusing.

Section 2., paragraph 5:
>    This specification provides these semantics
>    and mapping mechanisms for OSPFv2 and OSPFv3, leveraging the OSPF
>    Router Information (RI) LSA ([RFC4970]).

  Please expand acronyms on first use (LSA, etc.)

Section 3.1., paragraph 6:
>    The use of FQDN or a subset of
>    it is strongly recommended.


Section 8.2., paragraph 4:
>    [RFC2763]  Shen, N. and H. Smit, "Dynamic Hostname Exchange Mechanism
>               for IS-IS", RFC 2763, February 2000.

  Obsolete informational reference (is this intentional?): RFC 2763
  (Obsoleted by RFC 5301)

( Cullen Jennings ) No Objection

( Tim Polk ) No Objection

( Dan Romascanu ) No Objection

Comment (2009-07-02 for -)
The OPS-DIR review by David Kessens raised a number of issues that make this
document problematic although not enough to block it at this phase:

1. The authors chose to overload the protocol with an option for a problem that
looks more like a management problem and is solved in real life by good network
management techniques. The arguments about scaling issues for a stored mapping
table do not seem credible. One can expect that routers in a reasonable sized
network are already configured by use of a central database and configuring an
extra table should not be a problem at all. Furthermore, there are security
issues with the choosen approach that a configured table doesn't have and it
seems that it might be easier to avoid name conflicts with a centrally
configured table. The security concerns are apprpiately identified in the
document, ans it seems safer to use a configured table which does not have such

2. There are issues with the interpretation of what an ID to hostname mapping
actually means, and what it should and should not be used for. The term
hostname is used but there are only hints that an OSPF hostname might be the
same as what one stores in the DNS as a hostname for a particular router. Eg.
is the hostname just an easy human readible name or is it supposed to be the
same as a real hostname that also maps to an IP address used by the router.

( Robert Sparks ) (was Discuss) No Objection

Comment (2009-07-02 for -)
(moved to a comment after having it pointed out that the text limits the field
to 255 octets - potential exhaustion still exists, but is harder. Missing that
limit in the implementation of a sender could still lead to problems).

I think a little more advice in the Security Considerations section on
protection from accidental misconfiguration causing problems might be in order.

This mechanism causes routers to keep new state (adding domain names to a
table). The mechanism can provide names that are large (effectively bounded by
the size of an OSPF message). It's not hard to imagine someone fat-fingering a
configuration file (missing a quote or the equivalent) and ending up with a
very large "domain name".

( Magnus Westerlund ) No Objection

( Alexey Melnikov ) No Record

Comment (2009-06-25 for -)

   The value field identifies the symbolic hostname of the router
   originating the LSA.  This symbolic name can be the FQDN for the
   router, it can be a subset of the FQDN,

What exactly is "subset of the FQDN"?

   or it can be any string
   operators want to use for the router.

Is it actually a good idea to allow anything other than domain names in this

   The use of FQDN or a subset of
   it is strongly recommended.  The content of this value is a domain
   name, see [RFC2181].  The string is not null-terminated.  The Router
   ID of this router is derived from the LSA header, in the Advertising
   Router field of the Router Information (RI) Opaque LSA.