Dear Mark, Thanks for the comments.
Please see inline. Cheers, Med >-----Message d'origine----- >De : Mark ZZZ Smith [mailto:markzzzsm...@yahoo.com.au] >Envoyé : samedi 13 octobre 2012 01:16 >À : BOUCADAIR Mohamed OLNC/OLN; Ray Hunter >Cc : 6...@ietf.org; BINET David OLNC/OLN >Objet : Re: draft-boucadair-6man-sip-proxy-01 > >Hi, > >I agree with Ray, I think this is fundamentally just >re-inventing the wheel. Med: Yes, this is only a way to provision a node with another yet channel. No magic there. The question is: are we confident existing tools are sufficient to ensure access to the Internet service in a consistent and homogenous manner whatever the attachment network used by a host? BTW, I'm using the Internet service in a wider definition as defined in RFC1287 (http://tools.ietf.org/rfc/rfc1287.txt): "The Internet should be extended to support "real-time" applications like voice and video. " > >I notice that one of the justifications for this is that "DHCPv6 is not >required in all 3GPP releases." Why isn't it? Med: Because there is another channel which is supposed to provide such information during PDP Context. This assumption becomes obsolete when you attach to a non 3-GPP network. Based on this statement, >it seems to me that the 3GPP architecture doesn't recognise that there >isn't really anything special about (smart)phones - they're >just portable, >single or multi-homed hosts with one or more wireless interfaces, and >therefore should use standard and existing IPv6 mechanisms. Med: That's the point. Is there are a guarantee that based on host capabilities and diverse network attachment types, access to the telephony service will be preserved? >Making phone >calls on them is just an application running on the host. Med: The only issue is that unlike other Internet applications, provisioning the DNS is not sufficient to work: the information about the proxy server is required. > >Support for DHCPv6 is a SHOULD for hosts that support more than one >specialised application: >http://tools.ietf.org/html/rfc6434#section-7.2.1 Med: SHOULD is not a MUST. > >I think putting options like this and DNS (and of course, down the >track, most other DHCPv6 options) in RAs is a violation of the Internet >architecture. Med: I disagree: * There are already examples of protocols violating that model: TCP. (I agree this is not a reason to do it with another protocol.) * IPv5 (ST) focuses exclusively on real-time services * RFC1287 clearly extends the Internet model to real-time services. The Internet is meant to be application transparent, Med: I would love to; but IP connectivity is heavily dependent of rendezvous services (in all its forms: DNS, SIP registration, etc.) >and I think this is it's greatest strength and advantage >compared to the previous >application-specific networks such as the PSTN. Med: See my comment above. It shouldn't >be necessary >to upgrade the software/firmware in a router to be able to run a new >application residing on the hosts, yet this is what >applications/services >configuration options in RAs would require. Med: I'm not asking to include all application-related configuration in RA but only the mandatory rendezvous services for Internet service to be correctly be invoked and delivered: * DNS is already supported (RFC6106) * This I-D is claiming SIP-based configuration should also be part of this package. > >So I think the Internet needs to be kept both services/application >transparent as well as service/application configuration method >transparent. RAs should be left to just configuring the >network layer/IP >parameters, and an "over-the-top" protocol, stateless DHCPv6, used to >configure hosts' service and applications. Routers operating as >DCHPv6 relays fit within this model because they're (new) DHCPv6 option >transparent. > >Regards, >Mark. > > > >----- Original Message ----- >> From: "mohamed.boucad...@orange.com" <mohamed.boucad...@orange.com> >> To: Ray Hunter <v6...@globis.net> >> Cc: "6...@ietf.org" <6...@ietf.org>; BINET David OLNC/OLN ><david.bi...@orange.com> >> Sent: Friday, 12 October 2012 8:00 PM >> Subject: RE: draft-boucadair-6man-sip-proxy-01 >> >> 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 >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
