Subject: draft-song-pppext-sip-support-02.txt

From: Thomas Narten <[email-masked]>
Date: Wed, 14 May 2003 14:32:22 -0400

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

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 14 May 2003 12:43:44 -0600 (MDT)

> From: Thomas Narten <[email-masked]>
>

Ugh.  No.  Yes.

The proposal makes no sense.  Unless SIP Is utterly broken, there must
be other means for discovering SIP proxy servers besides special
link-layer kludges.  What happens on other point to point links that
don't use PPP?  What about point-to-point links that use PPP but not
IPCP, such as only BCP?

Besides, this proposal could not and would not be widely deployed for
a long time.  Unless SIP is utterly broken, those othe mechanisms,
whatever they are, must render this mechanism irrelevant.

It's not a coincidence that proposal to stuff routing or at least
router discovery into IPCP cited this proposal as a precedent.

Vernon Schryver    [email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 14 May 2003 11:32:07 -0700 (PDT)

Personally, I don't care much for this document.

It seems to me that allowing configuration mechanisms to proliferate isn't
helpful.

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.  Great -- multiple IETF standards, but no true
interoperability.

Then there is the potential for conflict. What if DHCP doesn't agree with
IPCP?  What about security?  IPCP isn't secured -- though DHCP might be.

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.  The latency argument doesn't hold anymore either.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 14 May 2003 23:38:10 -0700

Bernard Aboba <mailto:[email-masked]> writes:

> 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.

> 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    
> 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.

> latency and furthermore was an implementation burden, so that the
> user experience would be better and ISP deployment would be easier if
> 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?
  
>> 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/

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 15 May 2003 04:33:31 -0700

Vernon Schryver <mailto:[email-masked]> writes:

> The proposal makes no sense.  Unless SIP Is utterly broken, there
> must be other means for discovering SIP proxy servers besides special
> don't use PPP?  

Who cares?

> What about point-to-point links that use PPP but not
> IPCP, such as only BCP? 

Ditto.
   
> whatever they are, must render this mechanism irrelevant.  

Vern please read the document: "This draft specifies an IPCP (PPP
Internet Protocol Control Protocol) option that allows SIP clients to
locate a list of SIP proxy servers that is to be used for all SIP
requests. This approach is applicable to a system utilizing PPP for its
link layer protocol and IP address allocation (ex. 3GPP2 Packet Data
System)."
                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Presumably, 3GPP2 will be widely deployed in less than a long time (if
not, sell your Sprint stock now ;-).  Please understand that I don't
much care for this idea either, but all of the arguments against it so
far seem at best lame.  

~gwz

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 May 2003 05:42:10 -0700 (PDT)

> will ever implement the same set of standards?

I'm claiming that requiring embedded devices to implement multiple
standards may not be practical -- so they'll choose one and not
interoperate instead.

> devices on the network support precisely the same protocols, implemented

If the network is only supporting one set of protocols for configuration,
then the device must support that set in order to obtain configuration. If
different networks use different protocols and the device is mobile, then
it must support *all* the potential configuration protocols, or when it
moves to some networks, it will be unable to obtain configuration.  Worse
yet, when it moves, it may have to try multiple mechanisms in order to
obtain configuration. This can increase the latency required for the
device to become functional on movement.

> either IPCP or DHCP causing massive meltdowns?

Presumably once a host obtains an IP address it is done.  If the host
needs more configuration than is provided by IPCP it still may need to do
DHCPINFORM.

> between the client and server, just between relays and servers.

It goes between client and server -- see RFC 3118.

> to implement the stateless server.  Is that the desired outcome?

I think it is.  We're already much of the way there -- Cisco IOS includes
support for a full fledged DHCP server,  something that was not considered
possible back in 1995 when the idea of IPCP "extensions" was first proposed.

> In what environments?  802.11, Ethernet, UMTS, CDMA-2000, 14.4K dial-up?

If the authenticator implements a DHCP server, there won't be much latency
difference between DHCPINFORM and IPCP.

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 15 May 2003 08:23:40 -0600 (MDT)

> From: "Glen Zorn" <[email-masked]>

> > What about point-to-point links that use PPP but not

Please stop the insults and think about what we've said. 

If SIP is utterly broken, then there is no need for the proposal
because it can't and won't be used.  Let's assume that SIP is not
broken, not useless, and can be used and is used.  I don't know that
SIP is good, but given the vast number of IDs and RFCs about it, I
hope it is.  That SIP is good implies that it already has perfectly
good mechanisms for finding proxies without this new, quite late idea.
Thus this new, late idea is redundant, unnecessary, extra, and can
only cause confusion and interoperation problems.

> link layer protocol and IP address allocation (ex. 3GPP2 Packet Data

Whether 3GPP2 is deployed implies nothing that I can see.  I haven't
been buying any more stock in 3G telephones than I did in WAP telephones
and for some of the same reasons, but you should make your own investment
decisions.  This PPP proposal stinks of the same sort of Internet
Engineering that brought us WAP.  It is based on the assumption that
existing mechanisms do not exist or are irrelevant.

Perhaps the existing SIP mechanisms cannot work over PPP.  If that is
true, then this proposal must say so and provide convincing technical
reasons.

Let's cut the obscuring politeness and admit the main motive for
these IDs.  Like the old Microsoft DNS server botch, they come from
ignorance of existing standards and practices and an ambition to
see one's name in the RFC index.

The fact that this SIP proposal does not advert to the existence of
any mechanism on other link layers without broadcasts to discover
proxies suggests that the author does not know how SIP works on other
media.  The IPCP default route proposal has a similar stigmata of not
mentioning the ancient alternatives to its wonderful idea.  I'm sure
that author is not trying to hide the alternatives but was innocently
unaware of their ease, popularity, and effectiveness.  If all you know
about routing comes from the cries of anquish of people fighting with
BGP, you wouldn't consider using RIP for router discovery, not to
mention the IP router discovery protocol or the ancient mechanism of
adding routes as interfaces awaken.  If you don't really understand
IPCP, you'd not realize that it makes no sense to put the IP address
of the peer into the IPCP packet twice.  You'd also not recognize the
dangerous swamp of policy routing you'd wandered into.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 15 May 2003 15:58:17 -0700

Bernard Aboba <mailto:[email-masked]> writes:

>> How does this conclusion follow?  Are you claiming that no two
>> vendors will ever implement the same set of standards?
> 

Possibly.  So, presupposing that these devices use PPP, why would they
choose to implement DHCP instead of an IPCP option?

> 
>> 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.
> 
> If the network is only supporting one set of protocols for
> configuration, then the device must support that set in order to
> obtain configuration. If different networks use different protocols
> and the device is mobile, then it must support *all* the potential
> configuration protocols, or when it moves to some networks, it will
> be unable to obtain configuration.  Worse yet, when it moves, it may
> have to try multiple mechanisms in order to obtain configuration.
> This can increase the latency required for the device to become
> functional on movement.        
> 
>> 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?
> 
> needs more configuration than is provided by IPCP it still may need
> to do DHCPINFORM.

Exactly.
  
> It goes between client and server -- see RFC 3118.

Yup, thanks for the pointer!

> 
>> 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? 
> 
> I think it is.  We're already much of the way there -- Cisco IOS
> includes support for a full fledged DHCP server,  something that was
> not considered possible back in 1995 when the idea of IPCP
> "extensions" was first proposed.   
> 
> If the authenticator implements a DHCP server, there won't be much
> latency difference between DHCPINFORM and IPCP. 

Only if the DHCP server in the authenticator is omniscient: if the
correct values can only be provided by the home network (in a roaming
situation), then presumably the request would need to be relayed.  OTOH,
(devil's advocate hat on) if the appropriate values were returned from
the home AAA server and set in IPCP, the task would be complete before
DHCP would even have started, reducing both latency and code footprint
in the mobile device.

~gwz

I've stopped 24,785 spam messages. You can too!
Get your free, safe spam protection at
http://www.cloudmark.com/spamnetsig/

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 May 2003 15:45:43 -0700 (PDT)

> choose to implement DHCP instead of an IPCP option?

If they ever needed to move to a link which didn't support PPP.

> DHCP would even have started, reducing both latency and code footprint

In either case, assuming that the AAA protocol supported the necessary
configuration, then it could be made to work -- all that changes is the
protocol spoken between the peer and authenticator.  For example, if AAA
were to provide the address of the DNS server, then the peer could request
this via DHCP or IPCP and the authenticator could answer.  So roaming
doesn't come into it, really.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 15 May 2003 16:34:21 -0700

Vernon Schryver <mailto:[email-masked]> writes:

>>> must be other means for discovering SIP proxy servers besides
>>> special link-layer kludges.  What happens on other point to point
>>> links that don't use PPP?
>> 
>> Who cares?
>> 

I apologize if you feel that I've insulted you: that certainly wasn't my
intent; nor do I believe the questions to be facetious.  The draft in
question only addresses systems (specifically, 3GPP2 PDS) that run over
PPP/IP, so I really think that these objections are kind of irrelevant.
It seems much like calling FTP evil because it doesn't run over, say,
LU6.2.

> good mechanisms for finding proxies without this new, quite late
> idea. Thus this new, late idea is redundant, unnecessary, extra, and
> can only cause confusion and interoperation problems.     

I'm certainly not a SIP expert either, but OTOH I'm willing to entertain
the idea that some discovery/configuration methods that work perfectly
well in e.g., a high-bandwidth/low latency environment might not be
worth a damn in a more constrained one.

> 
> 
>>> Besides, this proposal could not and would not be widely deployed
>>> for a long time.  Unless SIP is utterly broken, those othe
>>> mechanisms, whatever they are, must render this mechanism
>>> irrelevant. 
>> 
>> requests. This approach is applicable to a system utilizing PPP for
>> its link layer protocol and IP address allocation (ex. 3GPP2 Packet
>>                                           Data System)."
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Presumably, 3GPP2 will be widely
>> deployed in less than a long time (if not, sell your Sprint stock
>> now ;-).  Please understand that I don't much care for this idea
>> either, but all of the arguments against it so far seem at best lame.
> 
> been buying any more stock in 3G telephones than I did in WAP
> telephones and for some of the same reasons, but you should make your
> own investment decisions.  

Whatever we think of the future of 3G, my point was that if 3GPP2 has
decided that this is way to do it, it will be deployed.

> This PPP proposal stinks of the same sort
> of Internet Engineering that brought us WAP.  It is based on the
> assumption that existing mechanisms do not exist or are irrelevant.  

Since you and I both admit that we are basically ignorant of whatever
alternative mechanisms may exist, it seems that you are assuming that
this draft is based upon an assumption, rather than careful analysis of
the options in the context of the system under design. 
 
> true, then this proposal must say so and provide convincing technical

I agree.
 
> ignorance of existing standards and practices and an ambition to see
> one's name in the RFC index.   
> 
> media.  

Another possibility is that the author thinks that it is so completely
obvious that the question needn't be broached.  It would be very good if
they addressed the question, though.

> The IPCP default route proposal has a similar stigmata of not
> unaware of their ease, popularity, and effectiveness.  If all you
> know about routing comes from the cries of anquish of people fighting
> with BGP, you wouldn't consider using RIP for router discovery, not
> to mention the IP router discovery protocol or the ancient mechanism
> of adding routes as interfaces awaken.  If you don't really
> understand IPCP, you'd not realize that it makes no sense to put the
> IP address of the peer into the IPCP packet twice.  You'd also not
> recognize the dangerous swamp of policy routing you'd wandered into. 
> 
> 

~gwz

I've stopped 24,811 spam messages. You can too!
Get your free, safe spam protection at
http://www.cloudmark.com/spamnetsig/

---

From: Barney Wolff <[email-masked]>
Date: Thu, 15 May 2003 20:44:00 -0400

> choose to implement DHCP instead of an IPCP option?

Funny, I listened to this exact debate in the ipsec wg:  whether to pass
dhcp or invent a new mechanism.  Apparently the inventive urge is
universal.

DHCP is a perfectly respectable and useful protocol.  What is there that
people don't like about it?

The IESG really needs to speak up, and promulgate a policy that inventing
new ways to do old things is BAD unless the old ways are manifestly
inferior.

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 May 2003 18:44:04 -0700 (PDT)

> dhcp or invent a new mechanism.  Apparently the inventive urge is

In the name of optimization, even reuse can be dangerous.  Given the
solutions for integrating DHCP, AAA and EAP which are now IPsec WG work
items, I'm not sure that they could have done worse inventing something new.

> people don't like about it?

Traditionally people have been adverse to the idea of DHCP relays and the
extra latency involved in DHCP exchanges.  Also there is the need for
stable storage in classical DHCPv4 servers.

Neither of those considerations apply to stateless deployments of
DHCPINFORM, though.

> new ways to do old things is BAD unless the old ways are manifestly

The IAB has been looking at issuing some architectural guidance on the
subject of IP configuration.  If you think that there is something useful
that they could do you might send mail to [email-masked] proposing what that
is.

---

From: Karl Fox <[email-masked]>
Date: 28 May 2003 20:36:16 -0400

I think the consensus is clear: Existing mechanisms are adequate to the
task.

Karl