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

[Henning Schulzrinne <[e-mail]>]

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.

Jonathan Rosenberg wrote:
> 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.
> 
> Dean Willis wrote:
> 
>>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 [e-mail] for questions on current sip
>>Use [e-mail] for new developments on the application of sip
> 
> 



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