[dhcwg] way forward for the mipshop-mos-dhcp document

[Jari Arkko <jari.arkko at piuha.net>]

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