I have to ask - because I've never heard it raised as an issue outside this mailing list - has anyone ever heard a *network administrator* or other customer of IETF protocols say that "configuring routers with what is titled a host specific protocol will create more confusion than it is worth."
If the name is truly a problem, I'm happy to follow up on the suggestion that we rename DHCP to "Dynamic Node Configuration Protocol" or "Dynamic Site Configuration Protocol" or "Yet Another Configuration Protocol". I'm having a hard time believing we're making technical decisions about protocol design based on the *name* of the protocols involved. Sheesh. BTW, just to review some ancient history, I added the infamous sentence "DHCP is not intended for use in configuring routers." (originally in RFC1531 and carried forward to RFC1541 and RFC2131) to limit the scope of the problem we were trying to solve. That was (literally) 10 years ago. Maybe it's OK now to reconsider that constraint. The sentence is *not* included in draft-ietf-dhc-dhcpv6-23.txt. - Ralph On Sat, 16 Feb 2002, Pekka Savola wrote: > On Fri, 15 Feb 2002, Tony Hain wrote: > > Ole Troan wrote: > > > ... > > > would you be happier if we renamed it to SNCP (Simple Node > > > Configuration Protocol)? :-) > > > > Actually, yes. Routers are not hosts, so configuring routers with what > > is titled a host specific protocol will create more confusion than it is > > worth. > > Just a point: the value of router/host toggle is interface-specific. This > was dicussed, hmm, probably around 6-9 months ago here in the context of > RFC2461. > > I also think DHCP and what not should not be used for router > configuration. > > > > > for me this boils down to picking a packet format on the wire. DHCP > > > offers a more flexible option format, is more extensible, has a > > > defined relay mechanism, offers a Reconfigure mechanism so it is > > > possible to poke the requesting router. I have no problem with using > > > ICMP PD, my point is that as we move along it is going to look awfully > > > much like DHCP. > > > > If we are going to need a stateful protocol tied to an authentication > > system, using the wire format and option richness of a widely deployed > > protocol makes more sense than inventing a new one. At the same time, > > going that route requires a serious look at the defined options to find > > any potential security holes that may exist because there was a > > historical assumption that the option applied to an end system not a > > router. If a router requesting one of the existing options opens a big > > hole, we really do need a new protocol. > > > > Tony > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to [EMAIL PROTECTED] > > -------------------------------------------------------------------- > > > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
