Subject: [Sip] Conclusion of WGLC, Call for IETF Last Call on sip-dhcpv6

From: "Dean Willis" <[email-masked]>
Date: Wed, 22 May 2002 12:46:03 -0500

We started working group last call of the sip-dhcpv6 draft on May 2.
There has been no negative veedback that I'm aware of, so let's call
WGLC complete and request IETF Last Call.

http://search.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 May 2002 12:43:24 -0400

One comment.

One of the things we need to be striving for is to move everything
consistently towards the usage of loose routing for sending requests
through intermediate hops. This has countless benefits, primarily
derived from the ability to associate parameters and other information
with the loose route URI. A local outbound proxy is most definitely a
hop that can be specified with a loose route. So, while bis does allow a
UAC to simply send requests to a configured IP/FQDN rather than use
loose routing, it recommends loose routing. 

So, my question is this: why don't we specify that the DHCP option
provides you a URI that is used as a loose route, and not a domain
name/IP address? Wouldn't that handle v6,v4 domain names and everything
else?

Also, I suspect that in many cases, local outbound proxies will be doing
compression. How does the client know whether it can send compressed sip
messages to its proxy? Well, we have a URI parameter for this purpose:

http://search.ietf.org/internet-drafts/draft-camarillo-sip-sigcomp-00.txt

Thus, if the client learns about the local outbound proxy through a URI,
it will be able to learn whether it supports compression. If only the
address/domain name are provided, separate means are needed to learn
about support for compression.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 May 2002 13:12:10 -0400

I agree that this would be useful, albeit a bit unusual compared to 
other DHCP options. There are a few issues that would need to be resolved:

- Would this apply to v6 only? I don't know that the state of the v4 
draft is in the IESG pipeline and what other "customers" there are. This 
would be the first DHCP option containing a URI, so this may cause some 
broader issues.

- It would be possible to add this mode as a third mechanism on top of 
the existing two (either as the byte identifier in v4 or as top-level 
items in v6) in both v4 and v6. That would seem to be the least likely 
to cause hick-ups.

- As the only mode, URIs would not be amenable to DNS host name 
compression, so this is not quite equivalent. I suspect that that is a 
minor issue.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 May 2002 15:26:12 -0400

> would be the first DHCP option containing a URI, so this may cause some

Understood. Its definitely not v6 specific. Maybe we need to define it
separately because its too late or controversial. My main point is that
technically, I think it is far superior to using IP addresses or domain
names.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 May 2002 15:54:38 -0400

I'm happy to add this as another option, but I'm more than a bit afraid 
of further delaying progress on something which already has seen more 
than its share of delays. If we get stuck in general debates as to 
whether DHCP should be allowed at all, we'll get another decade or so, 
so there'll be plenty of time :-)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 May 2002 18:00:14 -0400

I am fine to pursue this separately, and let the existing work continue.

-Jonathan R.