From pppext-bounces@ietf.org Mon Oct 02 05:04:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUJhg-00061f-CF; Mon, 02 Oct 2006 05:03:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUJhe-00060m-La for pppext@ietf.org; Mon, 02 Oct 2006 05:03:10 -0400 Received: from ememr1003.accenture.com ([170.252.72.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUJfC-000665-Nb for pppext@ietf.org; Mon, 02 Oct 2006 05:00:40 -0400 Received: from EMEXV1004.dir.svc.accenture.com (emexv1004.dir.svc.accenture.com [10.130.16.107]) by ememr1003.accenture.com (8.13.7/8.13.7) with ESMTP id k9290Hff028716 for ; Mon, 2 Oct 2006 10:00:35 +0100 (WEST) Received: from emexr1002.dir.svc.accenture.com ([10.130.16.111]) by EMEXV1004.dir.svc.accenture.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 11:00:13 +0200 Received: from emexm1103 ([10.130.16.19]) by emexr1002.dir.svc.accenture.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 11:00:13 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Content-class: urn:content-classes:message MIME-Version: 1.0 Importance: normal Priority: normal Date: Mon, 2 Oct 2006 11:00:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TISPAN proposal for PPP IPCP extension to handle P-CSCF address??? thread-index: AcbmAUTeMFiUrRIOTU2Nxmy10bwvug== From: To: X-OriginalArrivalTime: 02 Oct 2006 09:00:13.0013 (UTC) FILETIME=[2BC20850:01C6E601] X-Spam-Score: 0.2 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [Pppext] TISPAN proposal for PPP IPCP extension to handle P-CSCF address??? X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1695301242==" Errors-To: pppext-bounces@ietf.org This is a multi-part message in MIME format. --===============1695301242== Content-Transfer-Encoding: 7bit Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E601.2B73B3B4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E601.2B73B3B4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear members =20 I found on the Internet JUNHYUK SONG draft proposal on PPP IPCP extensions for SIP server address (draft-song-pppext-sip-support-02.txt), and I also saw that the proposal was rejected by IESG (http://www.ietf.org/IESG/Announcements/rfcno-draft-song-pppext-sip-supp ort.txt). =20 However I was surprised to read that TISPAN standard ETSI ES 282 004 V1.1.1 (2006-06) is suggesting to use PPP IPCP extensions for provisioning of P-CSCF IP address (pag 27, section 7.2 "PPP based authentication", last bullet: "AMF sends the IP address of a TISPAN NGN Service/Applications Subsystems (e.g. P-CSCF) to UE/CNG within PPP IPCP configuration option extension."). =20 Isn't it strange? Do you know if TISPAN is actually thinking of extending the PPP IPCP protocol? =20 Best Regards =20 Alessandro Cotroni=20 This message is for the designated recipient only and may contain = privileged, proprietary, or otherwise private information. If you have = received it in error, please notify the sender immediately and delete = the original. Any other use of the email by you is prohibited. ------_=_NextPart_001_01C6E601.2B73B3B4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear=20 members
 
I found on the Internet JUNHYUK SONG draft=20 proposal on PPP IPCP extensions for SIP server address=20 (draft-song-pppext-sip-support-02.txt), and I also saw that the proposal = was=20 rejected by IESG (http://www.ietf.org/IESG/Announcements/rfcno-draft-song-pp= pext-sip-support.txt).
 
However I was=20 surprised to read that TISPAN standard ETSI ES 282 004 V1.1.1 (2006-06)=20 is suggesting to use PPP IPCP extensions for provisioning of P-CSCF = IP=20 address (pag 27, section 7.2 "PPP based authentication", last bullet: = "AMF sends=20 the IP address of a TISPAN NGN Service/Applications Subsystems (e.g. = P-CSCF) to=20 UE/CNG within PPP IPCP configuration option = extension.").
 
Isn't = it=20 strange? Do you know if TISPAN is actually thinking of extending = the PPP=20 IPCP protocol?
 
Best=20 Regards
 
Alessandro=20 Cotroni 

This message is for the designated = recipient only and may contain privileged, proprietary, or otherwise = private information. If you have received it in error, please notify the = sender immediately and delete the original. Any other use of the email = by you is prohibited.

------_=_NextPart_001_01C6E601.2B73B3B4-- --===============1695301242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext --===============1695301242==-- From pppext-bounces@ietf.org Mon Oct 02 07:42:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMB6-0005aQ-36; Mon, 02 Oct 2006 07:41:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMB4-0005aF-9j for pppext@ietf.org; Mon, 02 Oct 2006 07:41:42 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUMB0-0005lZ-Ss for pppext@ietf.org; Mon, 02 Oct 2006 07:41:42 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k92Bfbbe029928 for ; Mon, 2 Oct 2006 04:41:38 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k92Bfa9R020857 for ; Mon, 2 Oct 2006 07:41:37 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k92Bi43m011817; Mon, 2 Oct 2006 07:44:04 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k92Bi4bF011814; Mon, 2 Oct 2006 07:44:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17696.64388.330282.574221@gargle.gargle.HOWL> Date: Mon, 2 Oct 2006 07:44:04 -0400 From: James Carlson To: alessandro.cotroni@accenture.com Subject: Re: [Pppext] TISPAN proposal for PPP IPCP extension to handle P-CSCF address??? In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pppext-bounces@ietf.org alessandro.cotroni@accenture.com writes: > However I was surprised to read that TISPAN standard ETSI ES 282 004 > V1.1.1 (2006-06) is suggesting to use PPP IPCP extensions for > provisioning of P-CSCF IP address (pag 27, section 7.2 "PPP based That's really unfortunate. Their plan won't be interoperable. > Isn't it strange? Do you know if TISPAN is actually thinking of > extending the PPP IPCP protocol? It's not unusual for folks to write their own extensions to IETF-controlled protocols without bothering with the standardization process. We don't have any IETF police out there to stop them. If they care at all about interoperability, they won't do something like this. Thanks for the pointer, though; I'll forward it around to see if we can't get clarification. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Oct 02 10:00:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOL4-0006f0-Oj; Mon, 02 Oct 2006 10:00:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOL3-0006an-9w for pppext@ietf.org; Mon, 02 Oct 2006 10:00:09 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOL2-000666-08 for pppext@ietf.org; Mon, 02 Oct 2006 10:00:09 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 02 Oct 2006 06:57:48 -0700 X-IronPort-AV: i="4.09,244,1157353200"; d="scan'208"; a="595993876:sNHT43748360" Received: from antipi.jnpr.net ([10.10.2.34]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 10:00:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] TISPAN proposal for PPP IPCP extension to handle P-CSCFaddress??? Date: Mon, 2 Oct 2006 10:00:04 -0400 Message-ID: <6B8F46B46D292A438250E42591ABB59D07A69BEE@antipi.jnpr.net> In-Reply-To: <17696.64388.330282.574221@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pppext] TISPAN proposal for PPP IPCP extension to handle P-CSCFaddress??? Thread-Index: AcbmF9q/zO4kb6qTSDuLTQuOwk/zKQAEp2Wg From: "Jerome Moisand" To: , X-OriginalArrivalTime: 02 Oct 2006 14:00:06.0581 (UTC) FILETIME=[10C29E50:01C6E62B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pppext-bounces@ietf.org Providing a SIP-proxy (P-CSCF) server @ via IPCP does make sense though. Might be a good idea to address the problem in a constructive manner, adding a mechanism for vendor-specific (or organization-specific) parameters that could be conveyed via IPCP. Allowing extensions without creating interoperability problems, and without the burden of having to go to IETF for defining such extensions.=20 DHCP and many other protocols have such extensibility, why not IPCP? Was this topic discussed in the past? -----Original Message----- From: James Carlson [mailto:james.d.carlson@sun.com]=20 Sent: Monday, October 02, 2006 7:44 AM To: alessandro.cotroni@accenture.com Cc: pppext@ietf.org Subject: Re: [Pppext] TISPAN proposal for PPP IPCP extension to handle P-CSCFaddress??? alessandro.cotroni@accenture.com writes: > However I was surprised to read that TISPAN standard ETSI ES 282 004 > V1.1.1 (2006-06) is suggesting to use PPP IPCP extensions for > provisioning of P-CSCF IP address (pag 27, section 7.2 "PPP based That's really unfortunate. Their plan won't be interoperable. > Isn't it strange? Do you know if TISPAN is actually thinking of > extending the PPP IPCP protocol? It's not unusual for folks to write their own extensions to IETF-controlled protocols without bothering with the standardization process. We don't have any IETF police out there to stop them. If they care at all about interoperability, they won't do something like this. Thanks for the pointer, though; I'll forward it around to see if we can't get clarification. --=20 James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Oct 02 10:10:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOVQ-0005L0-Aq; Mon, 02 Oct 2006 10:10:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOVO-0005JM-Fr for pppext@ietf.org; Mon, 02 Oct 2006 10:10:50 -0400 Received: from ememr1002.accenture.com ([170.252.72.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOVL-0006wy-Va for pppext@ietf.org; Mon, 02 Oct 2006 10:10:50 -0400 Received: from EMEXV1001.dir.svc.accenture.com (emexv1001.dir.svc.accenture.com [10.130.16.104]) by ememr1002.accenture.com (8.13.7/8.13.7) with ESMTP id k92EA1Sq023525; Mon, 2 Oct 2006 15:10:45 +0100 (WEST) Received: from emexr1001.dir.svc.accenture.com ([10.130.16.110]) by EMEXV1001.dir.svc.accenture.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 16:10:24 +0200 Received: from emexm1103 ([10.130.16.19]) by emexr1001.dir.svc.accenture.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 16:10:24 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Importance: normal Priority: normal Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] TISPAN proposal for PPP IPCP extension to handle P-CSCFaddress??? Date: Mon, 2 Oct 2006 16:11:05 +0200 Message-ID: In-Reply-To: <6B8F46B46D292A438250E42591ABB59D07A69BEE@antipi.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pppext] TISPAN proposal for PPP IPCP extension to handle P-CSCFaddress??? thread-index: AcbmF9q/zO4kb6qTSDuLTQuOwk/zKQAEp2WgAABh1tA= From: To: , X-OriginalArrivalTime: 02 Oct 2006 14:10:24.0295 (UTC) FILETIME=[80F24B70:01C6E62C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pppext-bounces@ietf.org Yes this topic was already discussed (http://www.atm.tut.fi/list-archive/pppext-2005/msg00109.html) The conclusion was that it has no sense to extend PPP IPCP protocol, because other mechanisms are already in place like for example DHCPINFORM. However I was surprised by the fact that TISPAN is suggesting a PPP IPCP extension, when this ipothesis was already rejected and I was only wondering if this decision was being revised due to TISPAN work. Alessandro Cotroni ------------------------------------------------ Alessandro Cotroni Accenture Via del Tintoretto 200, Roma ------------------------------------------------- =20 -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net]=20 Sent: 2 ottobre 2006 16.00 To: pppext@ietf.org; Cotroni, Alessandro Subject: RE: [Pppext] TISPAN proposal for PPP IPCP extension to handle P-CSCFaddress??? Providing a SIP-proxy (P-CSCF) server @ via IPCP does make sense though. Might be a good idea to address the problem in a constructive manner, adding a mechanism for vendor-specific (or organization-specific) parameters that could be conveyed via IPCP. Allowing extensions without creating interoperability problems, and without the burden of having to go to IETF for defining such extensions.=20 DHCP and many other protocols have such extensibility, why not IPCP? Was this topic discussed in the past? -----Original Message----- From: James Carlson [mailto:james.d.carlson@sun.com] Sent: Monday, October 02, 2006 7:44 AM To: alessandro.cotroni@accenture.com Cc: pppext@ietf.org Subject: Re: [Pppext] TISPAN proposal for PPP IPCP extension to handle P-CSCFaddress??? alessandro.cotroni@accenture.com writes: > However I was surprised to read that TISPAN standard ETSI ES 282 004 > V1.1.1 (2006-06) is suggesting to use PPP IPCP extensions for=20 > provisioning of P-CSCF IP address (pag 27, section 7.2 "PPP based That's really unfortunate. Their plan won't be interoperable. > Isn't it strange? Do you know if TISPAN is actually thinking of=20 > extending the PPP IPCP protocol? It's not unusual for folks to write their own extensions to IETF-controlled protocols without bothering with the standardization process. We don't have any IETF police out there to stop them. If they care at all about interoperability, they won't do something like this. Thanks for the pointer, though; I'll forward it around to see if we can't get clarification. --=20 James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext This message is for the designated recipient only and may contain = privileged, proprietary, or otherwise private information. If you have = received it in error, please notify the sender immediately and delete = the original. Any other use of the email by you is prohibited. _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Oct 02 10:18:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOcT-0003GG-Fz; Mon, 02 Oct 2006 10:18:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOcR-0003G4-I1 for pppext@ietf.org; Mon, 02 Oct 2006 10:18:07 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOcQ-0007zI-7j for pppext@ietf.org; Mon, 02 Oct 2006 10:18:07 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k92EI5Ox005958 for ; Mon, 2 Oct 2006 08:18:05 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k92EI56s020168 for ; Mon, 2 Oct 2006 10:18:05 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k92EKYMu012403; Mon, 2 Oct 2006 10:20:34 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k92EKYla012400; Mon, 2 Oct 2006 10:20:34 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17697.8241.936164.490576@gargle.gargle.HOWL> Date: Mon, 2 Oct 2006 10:20:33 -0400 From: James Carlson To: Jerome Moisand Subject: RE: [Pppext] TISPAN proposal for PPP IPCP extension to handle P-CSCFaddress??? In-Reply-To: <6B8F46B46D292A438250E42591ABB59D07A69BEE@antipi.jnpr.net> References: <17696.64388.330282.574221@gargle.gargle.HOWL> <6B8F46B46D292A438250E42591ABB59D07A69BEE@antipi.jnpr.net> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pppext-bounces@ietf.org Jerome Moisand writes: > Providing a SIP-proxy (P-CSCF) server @ via IPCP does make sense though. Not to me. > Might be a good idea to address the problem in a constructive manner, > adding a mechanism for vendor-specific (or organization-specific) > parameters that could be conveyed via IPCP. See RFC 2153. We already have a vendor-specific extension mechanism for PPP. > Allowing extensions without > creating interoperability problems, and without the burden of having to > go to IETF for defining such extensions. Actually, it still does cause interoperability problems, as it forces everyone else (over time) to implement these unnecessary extensions. > DHCP and many other protocols have such extensibility, why not IPCP? IPCP configures the network layer. IP addresses on the link are network layer properties, but SIP server addresses are application properties. Note that RFC 1877 is a Microsoft-proprietary extension. > Was this topic discussed in the past? Many, many times; see the archives for discussions about SIP server addresses, DNS server addresses, and other bits of application configuration. You can use DHCP to handle this application issue, and it works fine over PPP. DHCPINFORM seems particularly well-suited to the job, and it's the long-established consensus of the working group participants that we don't need IPCP extensions like that. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Oct 02 10:23:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOhR-0005Q2-Mg; Mon, 02 Oct 2006 10:23:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOcA-0003By-AS for pppext@ietf.org; Mon, 02 Oct 2006 10:17:50 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOc7-0007wr-Vp for pppext@ietf.org; Mon, 02 Oct 2006 10:17:50 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 02 Oct 2006 07:17:47 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92EHlTY008687; Mon, 2 Oct 2006 07:17:47 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k92EHkYv008224; Mon, 2 Oct 2006 07:17:47 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 07:17:43 -0700 Received: from [10.21.153.31] ([10.21.153.31]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 07:17:43 -0700 Message-ID: <45211F85.4030103@cisco.com> Date: Mon, 02 Oct 2006 10:17:41 -0400 From: Craig Fox User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jerome Moisand Subject: Re: [Pppext] TISPAN proposal for PPP IPCP extension to handle P-CSCFaddress??? References: <6B8F46B46D292A438250E42591ABB59D07A69BEE@antipi.jnpr.net> In-Reply-To: <6B8F46B46D292A438250E42591ABB59D07A69BEE@antipi.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Oct 2006 14:17:43.0371 (UTC) FILETIME=[86A7F9B0:01C6E62D] DKIM-Signature: a=rsa-sha1; q=dns; l=1763; t=1159798667; x=1160662667; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fox@cisco.com; z=From:Craig=20Fox=20 |Subject:Re=3A=20[Pppext]=20TISPAN=20proposal=20for=20PPP=20IPCP=20extension=20to =20handle=09P-CSCFaddress???; X=v=3Dcisco.com=3B=20h=3D2VRerKqhwotoObO8sPvkEvvHIc0=3D; b=KPDRli6hox5rbQY9wIKrRF/cqwDmOI/2+XxECucZT8EYKJJ6svjg1E9u/5DspGNt4I7xmCIS IxyrKsrWhUrls442d3+jHGI6Z1C7RMLqTKtPMUNUqZg+IImVypmhLCEy; Authentication-Results: sj-dkim-4.cisco.com; header.From=fox@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-Mailman-Approved-At: Mon, 02 Oct 2006 10:23:16 -0400 Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pppext-bounces@ietf.org Jerome Moisand wrote: > Providing a SIP-proxy (P-CSCF) server @ via IPCP does make sense though. > > Might be a good idea to address the problem in a constructive manner, > adding a mechanism for vendor-specific (or organization-specific) > parameters that could be conveyed via IPCP. Allowing extensions without > creating interoperability problems, and without the burden of having to > go to IETF for defining such extensions. > > DHCP and many other protocols have such extensibility, why not IPCP? Do you mean something like RFC 2153, PPP Vendor Extensions? Craig > > Was this topic discussed in the past? > > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@sun.com] > Sent: Monday, October 02, 2006 7:44 AM > To: alessandro.cotroni@accenture.com > Cc: pppext@ietf.org > Subject: Re: [Pppext] TISPAN proposal for PPP IPCP extension to handle > P-CSCFaddress??? > > alessandro.cotroni@accenture.com writes: >> However I was surprised to read that TISPAN standard ETSI ES 282 004 >> V1.1.1 (2006-06) is suggesting to use PPP IPCP extensions for >> provisioning of P-CSCF IP address (pag 27, section 7.2 "PPP based > > That's really unfortunate. Their plan won't be interoperable. > >> Isn't it strange? Do you know if TISPAN is actually thinking of >> extending the PPP IPCP protocol? > > It's not unusual for folks to write their own extensions to > IETF-controlled protocols without bothering with the standardization > process. We don't have any IETF police out there to stop them. > > If they care at all about interoperability, they won't do something > like this. > > Thanks for the pointer, though; I'll forward it around to see if we > can't get clarification. > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Oct 02 10:30:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOnv-0007an-Uj; Mon, 02 Oct 2006 10:29:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOnu-0007ZL-Km for pppext@ietf.org; Mon, 02 Oct 2006 10:29:58 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOnt-0000zw-Bg for pppext@ietf.org; Mon, 02 Oct 2006 10:29:58 -0400 Received: from unknown (HELO pi-smtp.jnpr.net) ([10.10.2.36]) by kremlin.juniper.net with ESMTP; 02 Oct 2006 07:27:37 -0700 X-IronPort-AV: i="4.09,244,1157353200"; d="scan'208"; a="589231656:sNHT52270406" Received: from antipi.jnpr.net ([10.10.2.34]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Oct 2006 10:29:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] TISPAN proposal for PPP IPCP extension to handleP-CSCFaddress??? Date: Mon, 2 Oct 2006 10:29:55 -0400 Message-ID: <6B8F46B46D292A438250E42591ABB59D07A69BF2@antipi.jnpr.net> In-Reply-To: <17697.8241.936164.490576@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pppext] TISPAN proposal for PPP IPCP extension to handleP-CSCFaddress??? Thread-Index: AcbmLbmwr095kq1TQEmQlEzTn51lmgAAEYGg From: "Jerome Moisand" To: "James Carlson" X-OriginalArrivalTime: 02 Oct 2006 14:29:56.0018 (UTC) FILETIME=[3B590920:01C6E62F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pppext-bounces@ietf.org All right, DHCPINFORM would work, sounds a bit contorted to mix PPP and DHCP, but why not. This is what 3GPP2 does, I believe.=20 Thanks for the historical background. -----Original Message----- From: James Carlson [mailto:james.d.carlson@sun.com]=20 Sent: Monday, October 02, 2006 10:21 AM To: Jerome Moisand Cc: pppext@ietf.org; alessandro.cotroni@accenture.com Subject: RE: [Pppext] TISPAN proposal for PPP IPCP extension to handleP-CSCFaddress??? Jerome Moisand writes: > Providing a SIP-proxy (P-CSCF) server @ via IPCP does make sense though. Not to me. > Might be a good idea to address the problem in a constructive manner, > adding a mechanism for vendor-specific (or organization-specific) > parameters that could be conveyed via IPCP. See RFC 2153. We already have a vendor-specific extension mechanism for PPP. > Allowing extensions without > creating interoperability problems, and without the burden of having to > go to IETF for defining such extensions.=20 Actually, it still does cause interoperability problems, as it forces everyone else (over time) to implement these unnecessary extensions. > DHCP and many other protocols have such extensibility, why not IPCP? IPCP configures the network layer. IP addresses on the link are network layer properties, but SIP server addresses are application properties. Note that RFC 1877 is a Microsoft-proprietary extension. > Was this topic discussed in the past? Many, many times; see the archives for discussions about SIP server addresses, DNS server addresses, and other bits of application configuration. You can use DHCP to handle this application issue, and it works fine over PPP. DHCPINFORM seems particularly well-suited to the job, and it's the long-established consensus of the working group participants that we don't need IPCP extensions like that. --=20 James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Oct 02 10:46:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP3S-0008Qt-MR; Mon, 02 Oct 2006 10:46:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP3Q-0008Ql-F3 for pppext@ietf.org; Mon, 02 Oct 2006 10:46:00 -0400 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUP3N-0002Vy-1V for pppext@ietf.org; Mon, 02 Oct 2006 10:46:00 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k92Ejt7e004000 for ; Mon, 2 Oct 2006 07:45:56 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k92EjtbI002477 for ; Mon, 2 Oct 2006 10:45:55 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k92EmMix012504; Mon, 2 Oct 2006 10:48:22 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k92EmMEw012501; Mon, 2 Oct 2006 10:48:22 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17697.9910.353804.516276@gargle.gargle.HOWL> Date: Mon, 2 Oct 2006 10:48:22 -0400 From: James Carlson To: Jerome Moisand Subject: RE: [Pppext] TISPAN proposal for PPP IPCP extension to handleP-CSCFaddress??? In-Reply-To: <6B8F46B46D292A438250E42591ABB59D07A69BF2@antipi.jnpr.net> References: <17697.8241.936164.490576@gargle.gargle.HOWL> <6B8F46B46D292A438250E42591ABB59D07A69BF2@antipi.jnpr.net> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pppext-bounces@ietf.org Jerome Moisand writes: > All right, DHCPINFORM would work, sounds a bit contorted to mix PPP and > DHCP, but why not. It doesn't really sound contorted to me. In fact, it has a history. Before PPP was deployed, people used BOOTP over SLIP to handle these sorts of application configuration issues. The RFC 1877 feature is ahistorical because it ignores that practice. The implication of the bolt-it-onto-IPCP approach is that we must have an IPCP extension for each defined DHCP option. Otherwise, we've got a poor step-child on our hands, as DHCP will always be more capable. Such an effort seems to me to be quite wasteful, and likely confusing as well. (On a multihomed machine, for instance, how do you set policy for DHCP-like information that may arrive via different protocols?) It's not really a question of whether it "would work." It's a question of whether the protocols are being used as they're designed to be used (DHCP is the standard for distributing network-related configuration options of this sort), and whether the proposed new feature (IPCP extension) is needed. In this case, the existing protocols solve the job nicely, and the newly-proposed feature has no notable benefits over the existing protocols. (The sole exception is apparently among the folks who think that it's easier for them to add a brand-new PPP extension that all other vendors will eventually be forced to implement, rather than send and receive a single UDP datagram in an already-defined format that needs no additional standardization work. It's that false economy that causes this sort of proposal to come up time and again.) (Why not bolt SIP addresses onto ARP? After all, on non-PPP media, you'll need an equivalent solution to avoid using DHCP.) -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Oct 02 10:47:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP55-0000e1-T4; Mon, 02 Oct 2006 10:47:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP54-0000dH-E3 for pppext@ietf.org; Mon, 02 Oct 2006 10:47:42 -0400 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUP52-0002gS-5m for pppext@ietf.org; Mon, 02 Oct 2006 10:47:42 -0400 Received: from [192.4.8.161] (adutta-laptop.research.telcordia.com [192.4.8.161]) by thumper.research.telcordia.com (8.13.6/8.13.5) with ESMTP id k92Eldui024153; Mon, 2 Oct 2006 10:47:39 -0400 (EDT) Message-ID: <4521268F.8070606@research.telcordia.com> Date: Mon, 02 Oct 2006 10:47:43 -0400 From: Ashutosh Dutta User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jerome Moisand Subject: Re: [Pppext] TISPAN proposal for PPP IPCP extension to handleP-CSCFaddress??? References: <6B8F46B46D292A438250E42591ABB59D07A69BF2@antipi.jnpr.net> In-Reply-To: <6B8F46B46D292A438250E42591ABB59D07A69BF2@antipi.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: pppext@ietf.org, James Carlson X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pppext-bounces@ietf.org Folks, since somebody referred to my earlier posting, let me throw some of our experience. After the discussion in the mailing list in 2005, we ended up using DHCPINFORM instead for P-CSCF discovery in our testbed. It works. We had some problem in making the DHCPINFORM working over PPP link however, but we sorted it out later on. Thanks Ashutosh Jerome Moisand wrote: > All right, DHCPINFORM would work, sounds a bit contorted to mix PPP and > DHCP, but why not. This is what 3GPP2 does, I believe. > > Thanks for the historical background. > > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@sun.com] > Sent: Monday, October 02, 2006 10:21 AM > To: Jerome Moisand > Cc: pppext@ietf.org; alessandro.cotroni@accenture.com > Subject: RE: [Pppext] TISPAN proposal for PPP IPCP extension to > handleP-CSCFaddress??? > > Jerome Moisand writes: >> Providing a SIP-proxy (P-CSCF) server @ via IPCP does make sense > though. > > Not to me. > >> Might be a good idea to address the problem in a constructive manner, >> adding a mechanism for vendor-specific (or organization-specific) >> parameters that could be conveyed via IPCP. > > See RFC 2153. We already have a vendor-specific extension mechanism > for PPP. > >> Allowing extensions without >> creating interoperability problems, and without the burden of having > to >> go to IETF for defining such extensions. > > Actually, it still does cause interoperability problems, as it forces > everyone else (over time) to implement these unnecessary extensions. > >> DHCP and many other protocols have such extensibility, why not IPCP? > > IPCP configures the network layer. IP addresses on the link are > network layer properties, but SIP server addresses are application > properties. > > Note that RFC 1877 is a Microsoft-proprietary extension. > >> Was this topic discussed in the past? > > Many, many times; see the archives for discussions about SIP server > addresses, DNS server addresses, and other bits of application > configuration. You can use DHCP to handle this application issue, and > it works fine over PPP. DHCPINFORM seems particularly well-suited to > the job, and it's the long-established consensus of the working group > participants that we don't need IPCP extensions like that. > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From zbt_shizhuku@yahoo.co.jp Fri Oct 06 07:03:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVnUL-0004ew-SU for pppext-archive@lists.ietf.org; Fri, 06 Oct 2006 07:03:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVnUL-0003jd-R7 for pppext-archive@lists.ietf.org; Fri, 06 Oct 2006 07:03:33 -0400 Received: from [222.171.146.60] (helo=lists.ietf.org) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GVnUJ-0001ZJ-47 for pppext-archive@lists.ietf.org; Fri, 06 Oct 2006 07:03:33 -0400 To: From: =?iso-2022-jp?B?GyRCJGokRCQzGyhC?= Subject: =?iso-2022-jp?B?GyRCOnJGfDtkJE4lIiVJJWwlOTA4JEYkSyVhITwlayQsRk8kJCRGJCQkRiEiMDhAaCQsJDMkTiUiJUklbCU5JEskSiRDJEYkJCReJDckPyEjGyhC?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 メール送信先に間違いありませんか？ 昨日私のアドレス宛てにメールが届いていて、宛先がこのアドレスになっていました。 私は加納といいます。どこで私のアドレスを知ったのでしょうか、掲示板でしょうか？ もし掲示板を見てのメールなら、初めて直接連絡をもらえたことになります。 私は不倫希望なので連絡先を教えてくれる人がまったくいませんでした。 貴方からメールが来たときには驚きましたけど、正直嬉しい気持ちもありました。 掲示板を通す事で秘密を守りながら会えると思っていましたが、ずっと出会いもありませんでした。 その掲示板でブログを作ることができたので一応載せておきます。 http://www.i-sobani.com/r_room 初めてなのに急に不倫をお願いしたりはしません、お話しだけでもいいですか？ はじめはメールだけでもいいですから。 送信先が私であってるようならと願っています。お話できたら嬉しいです。 加納律子