Bernard Aboba <mailto:aboba@xxxxxxxxxxxxx> writes:
> Personally, I don't care much for this document.
>
> It seems to me that allowing configuration mechanisms to proliferate
> isn't helpful.
Even less helpful is attempting to force all access networks to fit a
single mold.
>
> First off, it means that devices may have to implement multiple
> mechanisms, since they can't be sure that they can get the required
> configuration via a single mechanism. Since they might need PPP
> IPCP, or maybe DHCP, or maybe something else, you have to implement
> all of them
> -- if you want to interoperate. More likely, the device chooses a
> single mechanism, which means that it won't work in a heterogenous
> vendor environment.
How does this conclusion follow? Are you claiming that no two vendors
will ever implement the same set of standards?
> Great -- multiple IETF standards, but no true
> interoperability.
your use of the term "interoperability" here seems to me to be a novel
one. At the protocol level, interoperability is ensured by the correct
implementation of the protocol and required features thereof, but you
seem to be suggesting that "true" interoperability can only exist if all
devices on the network support precisely the same protocols, implemented
in exactly the same way.
>
> Then there is the potential for conflict. What if DHCP doesn't agree
> with IPCP?
If I already have the data I need (obtained through static
configuration, IPCP, etc.), why am I going to ask DHCP for it? In real,
existing networks, is the fact that IP addresses can be obtained through
either IPCP or DHCP causing massive meltdowns?
> What about security? IPCP isn't secured -- though DHCP
> might be.
Please excuse my ignorance: I thought that DHCP security didn't go
between the client and server, just between relays and servers.
>
> Once upon a time, the logic for IPCP extension support was that
> implementing DHCP service in the ISP network would increase access
> latency and furthermore was an implementation burden, so that the
> user experience would be better and ISP deployment would be easier if
> configuration could be done by the authenticator.
>
> However, with DHCPINFORM it is possible for an authenticator to
> implement a stateless server so that it isn't required for the ISP to
> implement DHCP in their network.
It's a long jump from "possible" to "necessary", which your definition
of "true interoperability" would seem to imply. If DHCP was the only
way to get config data, of course, then _every_ authenticator would have
to implement the stateless server. Is that the desired outcome?
> The latency argument doesn't hold
> anymore either.
In what environments? 802.11, Ethernet, UMTS, CDMA-2000, 14.4K dial-up?
>
>
> On Wed, 14 May 2003, Thomas Narten wrote:
>
>> Speaking of which, the RFC editor has received a request to publish
>> the above document as an informational RFC.
>>
>> What does this WG think of this request? Should the RFC editor
>> publish this document? Or would doing so be an end-run around this
>> WG?
>>
>> Thomas
~gwz
"They that can give up essential liberty to obtain a little temporary
safety deserve neither..."
-- Benjamin Franklin, 1759
I've stopped 24,754 spam messages. You can too!
Get your free, safe spam protection at
http://www.cloudmark.com/spamnetsig/
Glen Zorn.vcf
Description: Vcard
|
