Dear Ray, 

Thank you for the comments. 

Please see inline. 

Cheers,
Med

>-----Message d'origine-----
>De : Ray Hunter [mailto:v6...@globis.net] 
>Envoyé : vendredi 5 octobre 2012 21:45
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : 6...@ietf.org
>Objet : Re: draft-boucadair-6man-sip-proxy-01
>
>I have read this draft and do not support it as-is.
>
>I do not agree with the conclusion that extending RA with a new option 
>for SIP is necessary nor desirable.
>
>IMVHO:
>
>1. There are other mechanisms available. DHCPv6 is not 
>mandatory in the 
>IPv6 node requirements, but neither is SIP. Adding a new RA 
>option would 
>mean firmware in mobile devices would have to be updated, just as they 
>would if incorporating a DHCPv6 client, so that's a wash.

Med: I have several comments here:

* The discovery of the SIP Proxy server is almost critical as the discovery of 
a DNS server (RFC6106): If no server is discovered no session can be placed. 
This may be critical for no SIM-based terminals (e.g., placing an emergency 
call).

* With the advent of Mobile VoIP, a solution which ** guarantee ** the 
provisioning of the SIP Proxy Server is needed. I would argue RA-based method 
would have less impact on terminals

* This method can be used for auto configuring SIP terminals with a SIP Proxy 
Server deployed in a homenet context.

* For Fixed-Mobile Convergence, SIP-based traffic may also be interesting to 
offload (this is similar to local breakout scenarios for the roaming context): 
having a consistent method to discover the SIP Proxy in both fixed and mobile 
access would be helpful.


>
>2. An FQDN has an indeterminate length, although encoding of 
>an FQDN in 
>RFC1035 limits this to 255 octets, it's still potentially a 
>significant 
>increase in the length of RA messages, which is undesirable for many 
>reasons (including stateless security filtering mechanisms 
>like RA-Guard).
>
>3.There's no padding specified on the FQDN encoding. AFAIK 
>RFC1035 does 
>not specify how to encode an FQDN into 8 octet blocks (required for RA 
>options length calculations).

Med: You are right, padding may be needed. We can work out better the 
specification once there is a support to use RA for SIP Proxy Server discovery.

>
>4. You can hardly talk about advantages of using an RA option rather 
>than an alternative unicast mechanism on a point to point bearer link 
>(where no other nodes can listen out for the broadcast/multicast 
>information to save on multiple transmissions). The end node 
>still also 
>has to resolve the FQDN into one or more IPv6 or IPv4 
>addresses via DNS 
>before it can transmit any SIP messages, so it's not exactly a 
>RTT start 
>up latency or packet saver either.

Med: This may or may not be considered as an issue: the reason is there is 
likely a registration phase before placing a session. Anyway, this issue can be 
solved by changing the encoding of the name into string. Doing so would:
(1) allow to convey any name (including IP address literals) that can be passed 
to an underlying resolution library
(2) not require to define two formats (one for fqdn and another one for IP 
address). One single option will do the job.

>
>Or am I missing something?

Med: Your questions are valid one. I hope I clarified some of them. Thanks for 
the review.

>
>regards,
>RayH
>
>mohamed.boucad...@orange.com wrote:
>> Dear all,
>>
>> Comments are more than welcome.
>>
>> Cheers,
>> Med
>>
>> -----Message d'origine-----
>> De : i-d-announce-boun...@ietf.org 
>[mailto:i-d-announce-boun...@ietf.org] De la part de 
>internet-dra...@ietf.org
>> Envoyé : jeudi 4 octobre 2012 09:12
>> À : i-d-annou...@ietf.org
>> Objet : I-D Action: draft-boucadair-6man-sip-proxy-01.txt
>>
>>
>> A New Internet-Draft is available from the on-line 
>Internet-Drafts directories.
>>
>>
>>      Title           : IPv6 RA Option for SIP Proxy Server
>>      Author(s)       : Mohamed Boucadair
>>                            David Binet
>>      Filename        : draft-boucadair-6man-sip-proxy-01.txt
>>      Pages           : 6
>>      Date            : 2012-10-04
>>
>> Abstract:
>>     This document specifies a new optional extension to IPv6 Router
>>     Advertisement messages to advertise SIP Proxy Server 
>(e.g., P-CSCF)
>>     addresses to IPv6 hosts.
>>
>>     The provisioning of the SIP Proxy Server address is 
>crucial for the
>>     delivery of SIP-based services.  Means to ensure 
>reliable delivery of
>>     this information to connecting SIP User Agents is a must.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-boucadair-6man-sip-proxy
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-boucadair-6man-sip-proxy-01
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=aft-boucadair-6man-sip-proxy-01
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> i-d-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to