RE: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt

[Mark Stapp <[e-mail]>]

for a number of reasons (or accidents, depending on your point of view and 
memory), dhcp has focussed on transmitting configuration information. it 
has not developed a client api that would allow arbitrary applications to 
get at the information. it has not developed server configuration database 
schemas or apis that would allow information to be configured into 
arbitrary servers in a consistent way. because it has focussed on 
transporting configuration data, dhcp has become extremely widely deployed 
and is a very successful ietf protocol. perhaps some think that that 
sentence should read "in spite of that, ...". the ietf has blessed some 
configuration protocols which addressed some of the problems that dhcp has 
skipped, but none of those has been very successful.

there are hard problems in developing an application-level dhcp api, and 
we've invested our time elsewhere. among the hardest of the problems is 
that all existing applications do not use the missing dhcp client api, so 
there's been little demand for it. and if we were to spend years developing 
one, we would also have to replace all existing applications before the api 
would be consistently used. unlike some working groups I could name, we 
have looked at that situation and decided not to do work that would have a 
very high opportunity cost and would not be worthwhile.

a hypothetical dhcp client api might allow applications to register their 
interest in dhcp options, so that the dhcp client would ask for them as it 
interacted with the dhcp server(s). the api would also allow an application 
to retrieve the values the server(s) sent back. there are problems, like 
what to do when an option used by a running daemon changes its value. and 
should the dhcp client be willing to generate INFORMs initiated by any 
user-level application? some os's offer some sort of application-level 
support, some do not. it might be difficult to get dhcp clients deployed 
that offered a standard api, or it might be welcomed with open arms by os 
vendors - I don't know.

here's what happens, mostly. someone approaches the wg, having identified 
some information that their application needs, and having found a way to 
get the information that they need into their version of an application on 
at least one os. we have pretty much limited our role to helping make the 
dhcp option sensible and configurable so that servers can distribute it to 
the clients who can use it. we expect that the clients who can use it will 
ask for it. we don't mandate that all clients start asking for it. and we 
don't make the folks who've approached the wg tell us how they do what they 
do. they're solving a problem they have, and we're helping them. in some 
cases, the options don't get used much. in other cases, distributing the 
information via dhcp, which is so very available, is so compelling and 
useful that other folks figure out how to use the data too.

as we move towards first a dual-stack and then, eventually, a v6 world, it 
might be helpful to client implementors if we worked on an 
application-level api. but I'd sort of want to hear that from the client os 
and application vendors, so that there'd be some hope that the thing would 
actually do something useful.

we have specified a consistent way to carry this nis information in a 
dhcpv6 message. we have not insisted that all nis application clients 
retrieve the information in the same way, or that all v6 dhcp clients 
export some sort of api that would make that possible. you can insist that 
we do so before allowing this particular option to move on, but I don't see 
much value in that. if the iesg wants us to develop a dhcp client api, 
that's another matter, and we should talk about that on another email thread.

-- Mark


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg