Hi all,
There's a new version. This version completely removes the problems we
had with the variable encoding.
The version does keep the ability to provide both addresses and FQDNs
for the mobility servers, however, using separate options. I
personally think this issue was far less pressing than the above one;
if servers can't deal with the encoding that's a serious deployment
barrier. If there's multiple formats to deliver information, that is
an extra implementation burden and a potential interoperability issue
for nodes that choose to disobey the RFC and not implement both.
However, folks who want to deploy this could overcome these easily. As
a result, I'm fine with the document moving forward as it is. However,
the two WGs need to be OK with them as well, and when we talked about
this in DHC there were concerns about providing both addresses and
FQDNs. Can we try to close that issue and move on?
In my mind the question is whether the two formats are justified. I
have been thinking about this today and I can see an excellent
argument for why FQDNs need to be supported. There are some, but not
quite as convincing arguments for why addresses need to be supported.
The FQDNs need to be supported because DHCP simply delivers
information about the server, but has no understanding of further
details. For instance, 802.21 mobility servers may operate using
multiple transport protocols (UDP, TCP, maybe SCTP). There are SRV
record mechanisms in place to discover what transport protocols are
available and at which port they run on. However, the transport
protocol information is not carried in DHCP (nor would it make sense
to do so). And it does not help if the DHCP server resolves some of
these queries, because IMHO it would not make sense for the DHCP
server to be aware of all the details of client capabilities. As a
result, it seems that if we want to enable dynamic negotiation of
transport protocols or ports, you have to support FQDNs.
The arguments for the pure address delivery are that (1) its the
common way to deliver information in DHCP, so it could be supported as
a "base" mechanism for networks that do not need any SRV mechanisms
and (2) there may be networks that do not have DNS names for all
entities.
I personally think these reasons are sufficient to let the documents
move forward (or to be more exact, insufficient for us to block the
802.21 folks from introducing additional complexity if they really
insist on it). I do acknowledge that the arguments for pure address
delivery are on the weak side. But what does the DHC WG think? Is the
above analysis correct? Are there other means to do this that I missed?
Jari
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg