From extest-admin@lists.bell-labs.com Sun Apr 1 05:00:09 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14595 for ; Sun, 1 Apr 2001 05:00:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7E8CB443B1 for ; Sun, 1 Apr 2001 05:00:08 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: iptel-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Message-Id: <20010401090008.7E8CB443B1@lists.bell-labs.com> Date: Sun, 1 Apr 2001 05:00:08 -0400 (EDT) This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, iptel-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for iptel-archive@lists.ietf.org: List Password // URL ---- -------- iptel@lists.bell-labs.com Gfcn http://lists.bell-labs.com/mailman/options/iptel/iptel-archive%40lists.ietf.org From iptel-admin@lists.bell-labs.com Mon Apr 2 15:50:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27621 for ; Mon, 2 Apr 2001 15:50:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 62AF5443A3; Mon, 2 Apr 2001 15:50:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by lists.bell-labs.com (Postfix) with ESMTP id CC9B44433E for ; Mon, 2 Apr 2001 15:49:50 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A6A5B5012A; Mon, 02 Apr 2001 15:44:37 -0400 Message-ID: <00d001c0bbad$d84c76c0$3700000a@acmepacket.com> From: "Bob Penfield" To: "Matt Squire" , Cc: "IPTEL List" References: <3AC436D8.16C80C84@cisco.com> <3AC89225.AD80B4B3@windwire.com> Subject: Re: [Fwd: [IPTEL] TRIP Sequence Numbers] MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 2 Apr 2001 15:48:08 -0400 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Matt Squire" To: ; "Bob Penfield" Sent: Monday, April 02, 2001 10:52 AM Subject: Re: [Fwd: [IPTEL] TRIP Sequence Numbers] > > > > > In section 10.1.4 of draft-ietf-iptel-trip-04.txt it states: > > > > When an LS first originates a route into its ITAD, it MUST originate > > it with a Sequence Number of MinSequenceNum. > > > > Is the LS required to do this: > > a) when it restarts/reboots, or > > b) when the route is added to its Local-Route database > > > > The intention is that new routes start off with a sequence number of > one. Assuming that when an LS restarts, its local routing database is > empty, then (b) covers (a). > For case (b), I mean when an administrator entered the route into some persistant database. The sequence number would be 1 when the route was created and incremented each time the administrator updated the route. Since the route is stored in a persitent database, the routes sequence number could survive reboots and restarts. When the LS reboots/restarts, its local routes' seq#s are not reset to 1, they have what ever seq# is recorded in the database. > > > If (b) is allowed, the situation described in 10.1.6 (where an LS receives a > > self-originated route with a seq# larger than what it currently has recorded > > for the route) could be avoided. If either (a) or (b) is permitted, I think > > section 10.1.4 should say something like "An LS MAY maintain Sequence > > Numbers that are persistent across restarts/reboots". > > > > I'm not sure how allowing (b) gets rid of the situation where an LS > receives an old self originated route. > With (b), the route (and its sequence number) lives in a persistent database that survives restarts/reboots and the LS would never advertive a route with a seq# higher than what it previously had. If the LS receives a self-originated route with a seq# higher than what it has recorded in the persistent database, then there is something very wrong (either the database has been changed, or someone else is orginating routes with the LS's TRIP ID. > > > I have no problem with allowing LSs to maintain sequence numbers across > reboots. My personal gut feeling is that it would not be worth the > trouble, but there's certainly no reason to disallow the behavior. > Hussein, it would be great if you could add this sentence to the > Sequence Numbers considerations section (10.1.4). > > > Bob > > d:-) > > > > Robert F. Penfield > > Chief Software Architect > > Acme Packet, Inc. > > 130 New Boston Street > > Woburn, MA 01801 > > bpenfield@acmepacket.com > > > > _______________________________________________ > > IPTEL mailing list > > IPTEL@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Apr 2 17:31:21 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01967 for ; Mon, 2 Apr 2001 17:31:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2B2E04433F; Mon, 2 Apr 2001 17:31:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by lists.bell-labs.com (Postfix) with ESMTP id CC42C44338 for ; Mon, 2 Apr 2001 17:30:49 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AF3B17B012E; Mon, 02 Apr 2001 17:29:31 -0400 Message-ID: <000b01c0bbbc$7ed7ede0$3700000a@acmepacket.com> From: "Bob Penfield" To: "Matt Squire" Cc: , "IPTEL List" References: <3AC436D8.16C80C84@cisco.com> <3AC89225.AD80B4B3@windwire.com> <00d001c0bbad$d84c76c0$3700000a@acmepacket.com> <3AC8DED0.AC167DEF@windwire.com> Subject: Re: [Fwd: [IPTEL] TRIP Sequence Numbers] MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 2 Apr 2001 17:33:00 -0400 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Matt Squire" To: "Bob Penfield" Cc: ; "IPTEL List" Sent: Monday, April 02, 2001 4:19 PM Subject: Re: [Fwd: [IPTEL] TRIP Sequence Numbers] > > > Bob Penfield wrote: > > > > ----- Original Message ----- > > From: "Matt Squire" > > To: ; "Bob Penfield" > > Sent: Monday, April 02, 2001 10:52 AM > > Subject: Re: [Fwd: [IPTEL] TRIP Sequence Numbers] > > > > > > > > > > > > > In section 10.1.4 of draft-ietf-iptel-trip-04.txt it states: > > > > > > > > When an LS first originates a route into its ITAD, it MUST originate > > > > it with a Sequence Number of MinSequenceNum. > > > > > > > > Is the LS required to do this: > > > > a) when it restarts/reboots, or > > > > b) when the route is added to its Local-Route database > > > > > > > > > > The intention is that new routes start off with a sequence number of > > > one. Assuming that when an LS restarts, its local routing database is > > > empty, then (b) covers (a). > > > > > For case (b), I mean when an administrator entered the route into some > > persistant database. The sequence number would be 1 when the route was > > created and incremented each time the administrator updated the route. Since > > the route is stored in a persitent database, the routes sequence number > > could survive reboots and restarts. When the LS reboots/restarts, its local > > routes' seq#s are not reset to 1, they have what ever seq# is recorded in > > the database. > > > > > > > > > If (b) is allowed, the situation described in 10.1.6 (where an LS > > receives a > > > > self-originated route with a seq# larger than what it currently has > > recorded > > > > for the route) could be avoided. If either (a) or (b) is permitted, I > > think > > > > section 10.1.4 should say something like "An LS MAY maintain Sequence > > > > Numbers that are persistent across restarts/reboots". > > > > > > > > > > I'm not sure how allowing (b) gets rid of the situation where an LS > > > receives an old self originated route. > > > > > With (b), the route (and its sequence number) lives in a persistent database > > that survives restarts/reboots and the LS would never advertive a route with > > a seq# higher than what it previously had. If the LS receives a > > self-originated route with a seq# higher than what it has recorded in the > > persistent database, then there is something very wrong (either the database > > has been changed, or someone else is orginating routes with the LS's TRIP > > ID. > > > > Got it. But just to be clear, *allowing* (b) where an LS stores info in > a persistant database does not eliminate the possibility that a > self-originated route is received with an out-of-whack sequence number. > This possiblity would only be eliminated if (b) were the required > behavior. > Agreed. An LS that does uses (b) is not relieved of the requirements of section 10.1.6. The language in 10.1.6 (which says "This should be a relatively rare occurrence and indicates that a route still exists within the ITAD since the LSs last restart/reboot") implies (a). I just want to make sure persistent sequence numbers (b) are allowed. > That said, I think your suggestions are good things and > should be incorporated into the doc. > > - Matt _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Apr 2 18:34:05 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03057 for ; Mon, 2 Apr 2001 18:34:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1B3984433F; Mon, 2 Apr 2001 18:34:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from server.windwire.com (server-eng.windwire.com [209.116.70.153]) by lists.bell-labs.com (Postfix) with ESMTP id 52F0E44338 for ; Mon, 2 Apr 2001 16:19:58 -0400 (EDT) Received: from windwire.com (msquire.windwire.com [10.153.15.20]) by server.windwire.com (8.9.3+Sun/8.9.3) with ESMTP id QAA13341; Mon, 2 Apr 2001 16:19:29 -0400 (EDT) Message-ID: <3AC8DED0.AC167DEF@windwire.com> From: Matt Squire Organization: WindWire X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield Cc: hsalama@cisco.com, IPTEL List Subject: Re: [Fwd: [IPTEL] TRIP Sequence Numbers] References: <3AC436D8.16C80C84@cisco.com> <3AC89225.AD80B4B3@windwire.com> <00d001c0bbad$d84c76c0$3700000a@acmepacket.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms57BF73C6C51C616072FDF9B7" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 02 Apr 2001 16:19:28 -0400 This is a cryptographically signed message in MIME format. --------------ms57BF73C6C51C616072FDF9B7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Penfield wrote: > > ----- Original Message ----- > From: "Matt Squire" > To: ; "Bob Penfield" > Sent: Monday, April 02, 2001 10:52 AM > Subject: Re: [Fwd: [IPTEL] TRIP Sequence Numbers] > > > > > > > > > In section 10.1.4 of draft-ietf-iptel-trip-04.txt it states: > > > > > > When an LS first originates a route into its ITAD, it MUST originate > > > it with a Sequence Number of MinSequenceNum. > > > > > > Is the LS required to do this: > > > a) when it restarts/reboots, or > > > b) when the route is added to its Local-Route database > > > > > > > The intention is that new routes start off with a sequence number of > > one. Assuming that when an LS restarts, its local routing database is > > empty, then (b) covers (a). > > > For case (b), I mean when an administrator entered the route into some > persistant database. The sequence number would be 1 when the route was > created and incremented each time the administrator updated the route. Since > the route is stored in a persitent database, the routes sequence number > could survive reboots and restarts. When the LS reboots/restarts, its local > routes' seq#s are not reset to 1, they have what ever seq# is recorded in > the database. > > > > > > If (b) is allowed, the situation described in 10.1.6 (where an LS > receives a > > > self-originated route with a seq# larger than what it currently has > recorded > > > for the route) could be avoided. If either (a) or (b) is permitted, I > think > > > section 10.1.4 should say something like "An LS MAY maintain Sequence > > > Numbers that are persistent across restarts/reboots". > > > > > > > I'm not sure how allowing (b) gets rid of the situation where an LS > > receives an old self originated route. > > > With (b), the route (and its sequence number) lives in a persistent database > that survives restarts/reboots and the LS would never advertive a route with > a seq# higher than what it previously had. If the LS receives a > self-originated route with a seq# higher than what it has recorded in the > persistent database, then there is something very wrong (either the database > has been changed, or someone else is orginating routes with the LS's TRIP > ID. > Got it. But just to be clear, *allowing* (b) where an LS stores info in a persistant database does not eliminate the possibility that a self-originated route is received with an out-of-whack sequence number. This possiblity would only be eliminated if (b) were the required behavior. That said, I think your suggestions are good things and should be incorporated into the doc. - Matt --------------ms57BF73C6C51C616072FDF9B7 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIH8AYJKoZIhvcNAQcCoIIH4TCCB90CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BcEwggKlMIICDqADAgECAgMDRt0wDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDkxODEyMzIzOVoXDTAxMDkxODEyMzIz OVowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYU bXNxdWlyZUB3aW5kd2lyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALVGeVjK oqj+D2QZrYXrQ32AN2huvBRUL36ZsgHw1iBrKz7qGJRsB6nR+vk3fqlwfNSDT8T22oTazkqF lPnrrqO80gK62zQgNCDHBJMzylvH+GiD0V4yzhoyGWYAVXRg9FAdsA+lrQviV0BLIMtFIRvD Mhx/ui/VrT3kKj7CQ6vFAgMBAAGjUjBQMB8GA1UdEQQYMBaBFG1zcXVpcmVAd2luZHdpcmUu Y29tMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJ KoZIhvcNAQEEBQADgYEAVr8FzCeDg0vzEyAb4fCd7mufnc2pGz0z8zrFsSNuOytJWTnfZJB2 yBNSTRfBAhj6RShUdcHEV27jC1ki3+4SRfxJf72oyyyY835eAPjnl4wbbTakEc0lYKnkJ1NQ U1gX8DoF8NzsvQKZPT0mMSkJ0rhOEmiHmk+aivXtr7zWD9swggMUMIICfaADAgECAgELMA0G CSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIw EAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQL Ex9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo YXd0ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMC WkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNV BAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1Bl cnNvbmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrt ZaeSBl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaF PmzzlZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAw HwYDVR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ 6TH66bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQ fGuRb4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31 AG70HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0 ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZy ZWVtYWlsIFJTQSAxOTk5LjkuMTYCAwNG3TAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDQwMjIwMTkyOVowIwYJKoZIhvcNAQkE MRYEFHkqOHH6MV00RzqHBfmPgK2CrQenMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MA0GCSqGSIb3DQEBAQUABIGAQOnujn8pllKxzCyBpAraxGFwl78Zp7pjqRxDmdR3goBy1C1k VUqUZwUAq9OrH++8qRTJoNg1ehkT2FNdYsfzRvvFoiHJA/NjAxeljZjZXNEgz6tAdnR1kkwm OA8VfZTkO1JutdhH2EvWH4IjuXZsYLFK+GODazID7WkDZQ28VKI= --------------ms57BF73C6C51C616072FDF9B7-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Apr 4 08:40:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16221 for ; Wed, 4 Apr 2001 08:40:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5AE58443BE; Wed, 4 Apr 2001 08:40:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ix.netcorps.com (ix.netcorps.com [207.1.125.106]) by lists.bell-labs.com (Postfix) with ESMTP id 1C6F6443B8 for ; Wed, 4 Apr 2001 08:39:23 -0400 (EDT) Received: from indigosw.com (194-78-202-25.pro.turboline.skynet.be [194.78.202.25]) by ix.netcorps.com (8.9.0/8.9.0) with ESMTP id FAA11560 for ; Wed, 4 Apr 2001 05:39:50 -0700 (PDT) Message-ID: <3ACB15F7.AF15A6C@indigosw.com> From: David Bertrand Organization: Indigo Software X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "'iptel@lists.bell-labs.com'" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] CPL: address matching without subfield Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 04 Apr 2001 14:39:19 +0200 Content-Transfer-Encoding: 7bit Hi, In section 5.1.1 of the last draft on CPL concerning usage of address-switch with SIP, it states: "If no subfield is specified for addresses in SIP messages, the string matched is the URI part of the address. For "sip" URLs, all parameters are stripped;" My question is : Is the port number a parameter ? and whatever the response, does an absent port match the default port number (like in the paragraph concerning port number matching)? For example: - if the port number is a parameter: If the address given in the script is "sip:john@company.com:5060" and if the URI in the SIP message (without parameters) is "sip:john@company.com", should they match ? - if the port number is not a parameter: If the address given in the script is "sip:john@company.com" and if the URI in the SIP message (without parameters) is "sip:john@company.com:5060", should they match ? Thanks in advance, David -- David Bertrand Software Engineer Indigo Software 50 Rue Wiertz Brussels, 1050 - Belgium Phone : +32 2 235 09 44 Fax: +32 2 280 26 76 david@indigosw.com http://www.indigosw.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Apr 4 08:51:03 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16678 for ; Wed, 4 Apr 2001 08:51:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0DA33443B6; Wed, 4 Apr 2001 08:51:00 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 1C0CA443AB for ; Wed, 4 Apr 2001 08:50:58 -0400 (EDT) Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 4 Apr 2001 12:50:58 UT Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id MAA23987; Wed, 4 Apr 2001 12:50:53 GMT Received: from localhost (jundery@localhost) by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id NAA02982; Wed, 4 Apr 2001 13:50:52 GMT X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs From: James Undery To: David Bertrand Cc: "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] CPL: address matching without subfield In-Reply-To: <3ACB15F7.AF15A6C@indigosw.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 4 Apr 2001 13:50:52 +0000 (GMT) On Wed, 4 Apr 2001, David Bertrand wrote: > Hi, > > In section 5.1.1 of the last draft on CPL concerning usage of > address-switch with SIP, it states: > > "If no subfield is specified for addresses in SIP messages, the string > matched is the URI part of the address. For "sip" URLs, all parameters > are stripped;" > > My question is : Is the port number a parameter ? > and whatever the response, does an absent port match the default port > number (like in the paragraph concerning port number matching)? I'd say no the port isn't a parameter, and yes an absent port matches the default port. > - if the port number is not a parameter: > If the address given in the script is "sip:john@company.com" and > if the URI in the SIP message (without parameters) > is "sip:john@company.com:5060", should they match ? Yes, although "sip:john@company.com" and "sip:john@company.com:6000" won't match. James Undery _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Apr 4 15:24:13 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29438 for ; Wed, 4 Apr 2001 15:24:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 01C6C44337; Wed, 4 Apr 2001 15:24:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 11C7244336 for ; Wed, 4 Apr 2001 15:23:20 -0400 (EDT) Received: from conrail.cs.columbia.edu (conrail.cs.columbia.edu [128.59.19.147]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA17901; Wed, 4 Apr 2001 15:23:19 -0400 (EDT) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id PAA01673; Wed, 4 Apr 2001 15:23:19 -0400 (EDT) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15051.29863.39987.251833@conrail.cs.columbia.edu> To: David Bertrand Cc: "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] CPL: address matching without subfield In-Reply-To: <3ACB15F7.AF15A6C@indigosw.com> References: <3ACB15F7.AF15A6C@indigosw.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 4 Apr 2001 15:23:19 -0400 (EDT) Content-Transfer-Encoding: 7bit On Wednesday, April 4 2001, "David Bertrand" wrote to "'iptel@lists.bell-labs.com'" saying: > Hi, > > In section 5.1.1 of the last draft on CPL concerning usage of > address-switch with SIP, it states: > > "If no subfield is specified for addresses in SIP messages, the string > matched is the URI part of the address. For "sip" URLs, all parameters > are stripped;" > > My question is : Is the port number a parameter ? > and whatever the response, does an absent port match the default port > number (like in the paragraph concerning port number matching)? > > For example: - if the port number is a parameter: > If the address given in the script is "sip:john@company.com:5060" > and if the URI in the SIP message (without parameters) is > "sip:john@company.com", should they match ? > > - if the port number is not a parameter: > If the address given in the script is "sip:john@company.com" and > if the URI in the SIP message (without parameters) > is "sip:john@company.com:5060", should they match ? I think that default ports should be omitted from the URI when doing URI matching. However, I don't think this is what the spec says. Given that there's going to have to be one more revision for the time-switch stuff, would we have to do a second IESG cycle if I changed this? -- Jonathan _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Apr 5 20:25:13 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16875 for ; Thu, 5 Apr 2001 20:25:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3AC814433F; Thu, 5 Apr 2001 20:25:08 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 0C6CB44336 for ; Thu, 5 Apr 2001 20:24:05 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id RAA08123; Thu, 5 Apr 2001 17:24:08 -0700 (PDT) Received: from cisco.com (dhcp-128-107-142-42.cisco.com [128.107.142.42]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ACO00276 (AUTH hsalama); Thu, 5 Apr 2001 17:23:19 -0700 (PDT) Message-ID: <3ACD0C72.7EEEFBBD@cisco.com> From: "Hussein F. Salama" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield Cc: Matt Squire , IPTEL List Subject: Re: [Fwd: [IPTEL] TRIP Sequence Numbers] References: <3AC436D8.16C80C84@cisco.com> <3AC89225.AD80B4B3@windwire.com> <00d001c0bbad$d84c76c0$3700000a@acmepacket.com> <3AC8DED0.AC167DEF@windwire.com> <000b01c0bbbc$7ed7ede0$3700000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 05 Apr 2001 17:23:14 -0700 Content-Transfer-Encoding: 7bit Apologize for the late response. Requiring the sequence numbers to be persistent works for routes that are statically configured on the LS. But what about routes that the LS learns from an external peer then originates into the ITAD. To make these persistent, then when an LS goes down then comes back up, we must make sure that these external routes were not withdrawn while the LS was down. Similarly, what if in the future the LS redistributes routes from another source (e.g. some intra-domain call routing protocol or from H.323 Annex G) into TRIP. Can't assume that these routes will be persistent until LS crashes then comes back up. Why isn't the TripDisableTime timer sufficient to address the issues? Whenever the TRIP process goes down (for whatever) reason, it shouldn't be started until at least TripDisableTime have elapsed which is a long enough to ensure that routed advertised by this TRIP LS into the ITAD have been withdrawn. If the TRIP LS itself can't enforce this timeout, it is sufficient that its internal peers refuse to re-establish the peering until the TripDisableTime has elapsed. Thanks. Hussein Bob Penfield wrote: > ----- Original Message ----- > From: "Matt Squire" > To: "Bob Penfield" > Cc: ; "IPTEL List" > Sent: Monday, April 02, 2001 4:19 PM > Subject: Re: [Fwd: [IPTEL] TRIP Sequence Numbers] > > > > > > > Bob Penfield wrote: > > > > > > ----- Original Message ----- > > > From: "Matt Squire" > > > To: ; "Bob Penfield" > > > Sent: Monday, April 02, 2001 10:52 AM > > > Subject: Re: [Fwd: [IPTEL] TRIP Sequence Numbers] > > > > > > > > > > > > > > > > > In section 10.1.4 of draft-ietf-iptel-trip-04.txt it states: > > > > > > > > > > When an LS first originates a route into its ITAD, it MUST > originate > > > > > it with a Sequence Number of MinSequenceNum. > > > > > > > > > > Is the LS required to do this: > > > > > a) when it restarts/reboots, or > > > > > b) when the route is added to its Local-Route database > > > > > > > > > > > > > The intention is that new routes start off with a sequence number of > > > > one. Assuming that when an LS restarts, its local routing database is > > > > empty, then (b) covers (a). > > > > > > > For case (b), I mean when an administrator entered the route into some > > > persistant database. The sequence number would be 1 when the route was > > > created and incremented each time the administrator updated the route. > Since > > > the route is stored in a persitent database, the routes sequence number > > > could survive reboots and restarts. When the LS reboots/restarts, its > local > > > routes' seq#s are not reset to 1, they have what ever seq# is recorded > in > > > the database. > > > > > > > > > > > > If (b) is allowed, the situation described in 10.1.6 (where an LS > > > receives a > > > > > self-originated route with a seq# larger than what it currently has > > > recorded > > > > > for the route) could be avoided. If either (a) or (b) is permitted, > I > > > think > > > > > section 10.1.4 should say something like "An LS MAY maintain > Sequence > > > > > Numbers that are persistent across restarts/reboots". > > > > > > > > > > > > > I'm not sure how allowing (b) gets rid of the situation where an LS > > > > receives an old self originated route. > > > > > > > With (b), the route (and its sequence number) lives in a persistent > database > > > that survives restarts/reboots and the LS would never advertive a route > with > > > a seq# higher than what it previously had. If the LS receives a > > > self-originated route with a seq# higher than what it has recorded in > the > > > persistent database, then there is something very wrong (either the > database > > > has been changed, or someone else is orginating routes with the LS's > TRIP > > > ID. > > > > > > > Got it. But just to be clear, *allowing* (b) where an LS stores info in > > a persistant database does not eliminate the possibility that a > > self-originated route is received with an out-of-whack sequence number. > > This possiblity would only be eliminated if (b) were the required > > behavior. > > > Agreed. An LS that does uses (b) is not relieved of the requirements of > section 10.1.6. The language in 10.1.6 (which says "This should be a > relatively rare occurrence and indicates that a route still exists within > the ITAD since the LSs last restart/reboot") implies (a). I just want to > make sure persistent sequence numbers (b) are allowed. > > > That said, I think your suggestions are good things and > > should be incorporated into the doc. > > > > - Matt -- Hussein F. Salama Cisco Systems Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Apr 6 15:25:10 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18086 for ; Fri, 6 Apr 2001 15:25:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6031C4433A; Fri, 6 Apr 2001 15:25:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by lists.bell-labs.com (Postfix) with ESMTP id C5EA544336 for ; Fri, 6 Apr 2001 15:24:23 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A796F1500FE; Fri, 06 Apr 2001 15:23:02 -0400 Message-ID: <003401c0becf$7a0db400$3700000a@acmepacket.com> From: "Bob Penfield" To: "Hussein F. Salama" Cc: "Matt Squire" , "IPTEL List" References: <3AC436D8.16C80C84@cisco.com> <3AC89225.AD80B4B3@windwire.com> <00d001c0bbad$d84c76c0$3700000a@acmepacket.com> <3AC8DED0.AC167DEF@windwire.com> <000b01c0bbbc$7ed7ede0$3700000a@acmepacket.com> <3ACD0C72.7EEEFBBD@cisco.com> Subject: Re: [Fwd: [IPTEL] TRIP Sequence Numbers] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 6 Apr 2001 15:26:27 -0400 Content-Transfer-Encoding: 7bit Hussein, Thank you for your response. I had not thought of external routes that a LS injects as "self-originated". In any event, I don't want TRIP to REQUIRE persistent sequence number, I just want TRIP to ALLOW persistent sequence numbers for Local Routes directly entered into a LS. Thanks, Bob d:-) Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Hussein F. Salama" To: "Bob Penfield" Cc: "Matt Squire" ; "IPTEL List" Sent: Thursday, April 05, 2001 8:23 PM Subject: Re: [Fwd: [IPTEL] TRIP Sequence Numbers] > Apologize for the late response. > > Requiring the sequence numbers to be persistent works for routes that are > statically configured on the LS. But what about routes that the LS learns from > an external peer then originates into the ITAD. To make these persistent, then > when an LS goes down then comes back up, we must make sure that these external > routes were not withdrawn while the LS was down. > > Similarly, what if in the future the LS redistributes routes from another source > (e.g. some intra-domain call routing protocol or from H.323 Annex G) into TRIP. > Can't assume that these routes will be persistent until LS crashes then comes > back up. > > Why isn't the TripDisableTime timer sufficient to address the issues? Whenever > the TRIP process goes down (for whatever) reason, it shouldn't be started until > at least TripDisableTime have elapsed which is a long enough to ensure that > routed advertised by this TRIP LS into the ITAD have been withdrawn. If the TRIP > LS itself can't enforce this timeout, it is sufficient that its internal peers > refuse to re-establish the peering until the TripDisableTime has elapsed. > > Thanks. > > Hussein > > > Bob Penfield wrote: > > > ----- Original Message ----- > > From: "Matt Squire" > > To: "Bob Penfield" > > Cc: ; "IPTEL List" > > Sent: Monday, April 02, 2001 4:19 PM > > Subject: Re: [Fwd: [IPTEL] TRIP Sequence Numbers] > > > > > > > > > > > Bob Penfield wrote: > > > > > > > > ----- Original Message ----- > > > > From: "Matt Squire" > > > > To: ; "Bob Penfield" > > > > Sent: Monday, April 02, 2001 10:52 AM > > > > Subject: Re: [Fwd: [IPTEL] TRIP Sequence Numbers] > > > > > > > > > > > > > > > > > > > > > In section 10.1.4 of draft-ietf-iptel-trip-04.txt it states: > > > > > > > > > > > > When an LS first originates a route into its ITAD, it MUST > > originate > > > > > > it with a Sequence Number of MinSequenceNum. > > > > > > > > > > > > Is the LS required to do this: > > > > > > a) when it restarts/reboots, or > > > > > > b) when the route is added to its Local-Route database > > > > > > > > > > > > > > > > The intention is that new routes start off with a sequence number of > > > > > one. Assuming that when an LS restarts, its local routing database is > > > > > empty, then (b) covers (a). > > > > > > > > > For case (b), I mean when an administrator entered the route into some > > > > persistant database. The sequence number would be 1 when the route was > > > > created and incremented each time the administrator updated the route. > > Since > > > > the route is stored in a persitent database, the routes sequence number > > > > could survive reboots and restarts. When the LS reboots/restarts, its > > local > > > > routes' seq#s are not reset to 1, they have what ever seq# is recorded > > in > > > > the database. > > > > > > > > > > > > > > > If (b) is allowed, the situation described in 10.1.6 (where an LS > > > > receives a > > > > > > self-originated route with a seq# larger than what it currently has > > > > recorded > > > > > > for the route) could be avoided. If either (a) or (b) is permitted, > > I > > > > think > > > > > > section 10.1.4 should say something like "An LS MAY maintain > > Sequence > > > > > > Numbers that are persistent across restarts/reboots". > > > > > > > > > > > > > > > > I'm not sure how allowing (b) gets rid of the situation where an LS > > > > > receives an old self originated route. > > > > > > > > > With (b), the route (and its sequence number) lives in a persistent > > database > > > > that survives restarts/reboots and the LS would never advertive a route > > with > > > > a seq# higher than what it previously had. If the LS receives a > > > > self-originated route with a seq# higher than what it has recorded in > > the > > > > persistent database, then there is something very wrong (either the > > database > > > > has been changed, or someone else is orginating routes with the LS's > > TRIP > > > > ID. > > > > > > > > > > Got it. But just to be clear, *allowing* (b) where an LS stores info in > > > a persistant database does not eliminate the possibility that a > > > self-originated route is received with an out-of-whack sequence number. > > > This possiblity would only be eliminated if (b) were the required > > > behavior. > > > > > Agreed. An LS that does uses (b) is not relieved of the requirements of > > section 10.1.6. The language in 10.1.6 (which says "This should be a > > relatively rare occurrence and indicates that a route still exists within > > the ITAD since the LSs last restart/reboot") implies (a). I just want to > > make sure persistent sequence numbers (b) are allowed. > > > > > That said, I think your suggestions are good things and > > > should be incorporated into the doc. > > > > > > - Matt > > -- > Hussein F. Salama > Cisco Systems > Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 > > > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Apr 9 09:23:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06018 for ; Mon, 9 Apr 2001 09:23:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A34354433A; Mon, 9 Apr 2001 09:23:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ix.netcorps.com (ix.netcorps.com [207.1.125.106]) by lists.bell-labs.com (Postfix) with ESMTP id D42DF44336 for ; Mon, 9 Apr 2001 09:22:14 -0400 (EDT) Received: from indigosw.com (194-78-202-25.pro.turboline.skynet.be [194.78.202.25]) by ix.netcorps.com (8.9.0/8.9.0) with ESMTP id GAA17142 for ; Mon, 9 Apr 2001 06:22:37 -0700 (PDT) Message-ID: <3AD1B77F.EA7EFF9D@indigosw.com> From: David Bertrand Organization: Indigo Software X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "'iptel@lists.bell-labs.com'" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] not present/otherwise nodes Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 09 Apr 2001 15:22:07 +0200 Content-Transfer-Encoding: 7bit Hi all, Let's suppose a CPL script contains a switch (for example based on subject) without the output but with the output . If the variable the switch is to match (in this case, subject of call) is not present in the call setup request, should the script execute the otherwise node or the default behaviour ? -- David Bertrand Software Engineer Indigo Software 50 Rue Wiertz Brussels, 1050 - Belgium Phone : +32 2 235 09 44 Fax: +32 2 280 26 76 david@indigosw.com http://www.indigosw.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Apr 9 09:30:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06191 for ; Mon, 9 Apr 2001 09:30:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3551244368; Mon, 9 Apr 2001 09:30:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id BEE4444367 for ; Mon, 9 Apr 2001 09:29:47 -0400 (EDT) Received: from gecko by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 9 Apr 2001 13:29:47 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id NAA25076; Mon, 9 Apr 2001 13:29:12 GMT Message-ID: <3AD1B921.8E4C4885@ubiquity.net> From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Bertrand Cc: "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] not present/otherwise nodes References: <3AD1B77F.EA7EFF9D@indigosw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 09 Apr 2001 14:29:05 +0100 Content-Transfer-Encoding: 7bit David Bertrand wrote: > Hi all, > > Let's suppose a CPL script contains a switch (for example based on > subject) without the output but with the output > . If the variable the switch is to match (in this case, > subject of call) is not present in the call setup request, should the > script execute the otherwise node or the default behaviour ? It should execute the otherwise node, the default behaviour is only used when there is no match to an output node and no otherwise node exists. James Undery _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Apr 9 18:43:02 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18376 for ; Mon, 9 Apr 2001 18:43:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C09644343; Mon, 9 Apr 2001 18:43:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B34EF44338 for ; Mon, 9 Apr 2001 18:42:03 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA13322; Mon, 9 Apr 2001 18:45:25 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 9 Apr 2001 18:41:56 -0400 Message-ID: From: Jonathan Rosenberg To: "'James Undery'" , David Bertrand Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] not present/otherwise nodes MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 9 Apr 2001 18:41:54 -0400 > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Monday, April 09, 2001 9:29 AM > To: David Bertrand > Cc: 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] not present/otherwise nodes > > > > > David Bertrand wrote: > > > Hi all, > > > > Let's suppose a CPL script contains a switch (for example based on > > subject) without the output but with the output > > . If the variable the switch is to match (in this case, > > subject of call) is not present in the call setup request, > should the > > script execute the otherwise node or the default behaviour ? > > It should execute the otherwise node, the default behaviour > is only used > when there is no match to an output node and no otherwise > node exists. Hmm. Thats not what we did - we perform the default action. Its not clear from the spec which one is correct. It probably doesn't matter much so long as we pick something. Jonathan L. - any comments? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Apr 9 21:08:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20597 for ; Mon, 9 Apr 2001 21:08:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3D47B44338; Mon, 9 Apr 2001 21:08:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id C26D044336 for ; Mon, 9 Apr 2001 21:07:37 -0400 (EDT) Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA02545; Mon, 9 Apr 2001 21:07:34 -0400 (EDT) Received: (from lennox@localhost) by ind.cs.columbia.edu (8.9.3+Sun/8.9.3) id VAA19508; Mon, 9 Apr 2001 21:07:33 -0400 (EDT) X-Authentication-Warning: ind.cs.columbia.edu: lennox set sender to lennox@ind.cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15058.23763.773438.85608@ind.cs.columbia.edu> To: Jonathan Rosenberg Cc: "'James Undery'" , David Bertrand , "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] not present/otherwise nodes In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 9 Apr 2001 21:07:31 -0400 (EDT) Content-Transfer-Encoding: 7bit On Monday, April 9 2001, "Jonathan Rosenberg" wrote to "'James Undery', David Bertrand, 'iptel@lists.bell-labs.com'" saying: > > -----Original Message----- > > From: James Undery [mailto:jundery@ubiquity.net] > > > > David Bertrand wrote: > > > > > > Let's suppose a CPL script contains a switch (for example based on > > > subject) without the output but with the output > > > . If the variable the switch is to match (in this case, > > > subject of call) is not present in the call setup request, > > should the > > > script execute the otherwise node or the default behaviour ? > > > > It should execute the otherwise node, the default behaviour > > is only used > > when there is no match to an output node and no otherwise > > node exists. > > > Hmm. Thats not what we did - we perform the default action. Its not clear > from the spec which one is correct. It probably doesn't matter much so long > as we pick something. > > Jonathan L. - any comments? I wanted to have the same semantics as the C/Java default: tag in a switch statement, so yes, it should cover the case if you haven't got a output. This makes using to do negated conditions a lot easier, too -- e.g. [do something to reach me] [do something to reach my voicemail] -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Apr 10 03:38:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09276 for ; Tue, 10 Apr 2001 03:38:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 953804436B; Tue, 10 Apr 2001 03:38:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 9DC2E44336 for ; Tue, 10 Apr 2001 03:37:47 -0400 (EDT) Received: from gecko by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 10 Apr 2001 07:37:47 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id HAA27635; Tue, 10 Apr 2001 07:36:37 GMT Message-ID: <3AD2B803.2659F360@ubiquity.net> From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox Cc: Jonathan Rosenberg , David Bertrand , "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] not present/otherwise nodes References: <15058.23763.773438.85608@ind.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 10 Apr 2001 08:36:35 +0100 Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: > On Monday, April 9 2001, "Jonathan Rosenberg" wrote to "'James Undery', David Bertrand, 'iptel@lists.bell-labs.com'" saying: > > > > -----Original Message----- > > > From: James Undery [mailto:jundery@ubiquity.net] > > > > > > David Bertrand wrote: > > > > > > > > Let's suppose a CPL script contains a switch (for example based on > > > > subject) without the output but with the output > > > > . If the variable the switch is to match (in this case, > > > > subject of call) is not present in the call setup request, > > > should the > > > > script execute the otherwise node or the default behaviour ? > > > > > > It should execute the otherwise node, the default behaviour > > > is only used > > > when there is no match to an output node and no otherwise > > > node exists. > > > > > > Hmm. Thats not what we did - we perform the default action. Its not clear > > from the spec which one is correct. It probably doesn't matter much so long > > as we pick something. > > > > Jonathan L. - any comments? > > I wanted to have the same semantics as the C/Java default: tag > in a switch statement, so yes, it should cover the case if > you haven't got a output. > > This makes using to do negated conditions a lot easier, too -- > e.g. > > [do something to reach me] > [do something to reach my voicemail] > I think you did specify this in the 3rd and 4th paragraphs of section 5. James Undery _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Apr 10 07:39:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11775 for ; Tue, 10 Apr 2001 07:39:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 79F004433A; Tue, 10 Apr 2001 07:39:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cse.uta.edu (cse.uta.edu [129.107.12.1]) by lists.bell-labs.com (Postfix) with ESMTP id 75BC744336 for ; Mon, 9 Apr 2001 15:51:32 -0400 (EDT) Received: from cse.uta.edu (mohan-lap.uta.edu [129.107.25.20]) by cse.uta.edu (8.9.0/8.9.0) with ESMTP id OAA18939; Mon, 9 Apr 2001 14:33:05 -0500 (CDT) Message-ID: <3AD15556.1609BB13@cse.uta.edu> From: Mohan Kumar X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: lauhow , cktoh , "randy\\"@lists.bell-labs.com, " <"@lists.bell-labs.com, randy@lists.bell-labs.com, "@eecs.berkeley.eduhaas@ee.cornell.edu\">, eroyer , wendi , djw , tudball , jj , mrp12 , ramana, mayo , sodini , arppe , mgbaker , hong , "@l, ists.bell-labs.com, L.Andrew@lists.bell-labs.com, " , "@lists.bell-labs.com, s.hanly@lists.bell-labs.com, " , yuenck , ananda , asctlau , asadas , peggy , tschudin , gminden , calvert , goodman , "@l, ists.bell-labs.com, Petri.Jokela@lists.bell-labs.com, " , javierg , "@lists.bell-labs.com, m.zukerman@lists.bell-labs.com, " , liny , gupta , bli , "@lists.bell-labs.com, J.crowcroft@lists.bell-labs.com, " , htchuah , ksk , liao , tye , lili , pretty , hasung , lin , kumar , aklmiu , snoeren , roryg , rstainov , cldavis , itc , tccc , alg , cabernet-events , cost237-transport , kuvs-elg , manet , announce , testnet , calendar , SIGMOB , eapls-request , amast , dbworld , enternet , xtp-relay , MOBILE-IP , mahmoud , dpa , rkakarap , acampora , rao , yschen , jwcho , xli2 , sharony , jace , prkumar , mjammer , iptel , pmanzoni , youngko , asj , news-announce-conferences , "@lists.bell-labs.com, andras.valko@lists.bell-labs.com, " , tripathi , aashaikh , seapahn , miodrag , rohit_dube , ieeetcpc , mobile-ip "@lists.bell-labs.com" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] Call for Papers WoWMoM 2001 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 09 Apr 2001 14:23:18 +0800 Content-Transfer-Encoding: 7bit My apologies if you receive multiple copies of this CFP. ACM's Fourth Annual International Workshop on WIRELESS MOBILE MULTIMEDIA July 21 2001, Rome, Italy (in conjunction with MobiCom 2001) URL: http://www.acm.org/sigmobile/workshops/2001/WoWMoM01/ IMPORTANT DATES: Submissions due: May 1, 2001 Notification of acceptance: June 5, 2001 Camera-ready version due: June 15, 2001 SCOPE: Technical papers describing previously unpublished, original, completed research, not currently under review by another conference or journal are solicited on the following topics: - Multimedia Network Architectures and Protocols - Quality-of-Service and Admission Control - Third and Forth Generation Systems - Video over Wireless Channels - Multimedia Applications - Wireless Network Evolution - Broadband Wireless - Wireless ATM - Multicasting in Wireless Services - Delay and Jitter Management for Multimedia Services - Synchronization of Multimedia Wireless services - Data and Header Compression Techniques - Mobility Management & Fast Handover Techniques - QoS Routing - WWW Browsing - Telemetry Services - Broadcast Data INTERNATIONAL PROGRAM COMMITTEE Hamid Aghvami, King's College London, U.K. Victor Bahl, Microsoft Research, U.S.A Andrew Campbell, Columbia University, U.S.A Marco Conti, CNUCE, Pisa, Italy Nigel Davies, Lancaster University, U.K. Lajos Hanzo, University of Southampton, U.K. Edward W. Knightly, Rice University, U.S.A Werner Mohr, Siemens AG Hiroyuki Morikawa, University of Tokyo, Japan George Polyzos, Athens University, Greece Adam Wolisz, Technical University of Berlin ---------------------------------------------------------------- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Apr 11 00:01:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03362 for ; Wed, 11 Apr 2001 00:01:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B9C0744338; Wed, 11 Apr 2001 00:01:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 87B5244336 for ; Wed, 11 Apr 2001 00:01:00 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA27978; Wed, 11 Apr 2001 00:04:26 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Apr 2001 00:00:56 -0400 Message-ID: From: Jonathan Rosenberg To: "'James Undery'" , Jonathan Lennox Cc: Jonathan Rosenberg , David Bertrand , "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] not present/otherwise nodes MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 11 Apr 2001 00:00:55 -0400 > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Tuesday, April 10, 2001 3:37 AM > To: Jonathan Lennox > Cc: Jonathan Rosenberg; David Bertrand; 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] not present/otherwise nodes > > > > > Jonathan Lennox wrote: > > > On Monday, April 9 2001, "Jonathan Rosenberg" wrote to > "'James Undery', David Bertrand, 'iptel@lists.bell-labs.com'" saying: > > > > > > -----Original Message----- > > > > From: James Undery [mailto:jundery@ubiquity.net] > > > > > > > > David Bertrand wrote: > > > > > > > > > > Let's suppose a CPL script contains a switch (for > example based on > > > > > subject) without the output but with the output > > > > > . If the variable the switch is to match > (in this case, > > > > > subject of call) is not present in the call setup request, > > > > should the > > > > > script execute the otherwise node or the default behaviour ? > > > > > > > > It should execute the otherwise node, the default behaviour > > > > is only used > > > > when there is no match to an output node and no otherwise > > > > node exists. > > > > > > > > > Hmm. Thats not what we did - we perform the default > action. Its not clear > > > from the spec which one is correct. It probably doesn't > matter much so long > > > as we pick something. > > > > > > Jonathan L. - any comments? > > > > I wanted to have the same semantics as the > C/Java default: tag > > in a switch statement, so yes, it should cover the > case if > > you haven't got a output. > > > > This makes using to do negated conditions a lot > easier, too -- > > e.g. > > > > [do something to > reach me] > > [do something to reach my voicemail] > > > > I think you did specify this in the 3rd and 4th paragraphs of > section 5. I don't think its really that clear. How about: The output otherwise, which MUST be the last output specified if it is present, matches if no other condition matched. This includes the case where the field is not present in the request, and a not-present output was not specified. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Apr 11 04:22:04 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18734 for ; Wed, 11 Apr 2001 04:22:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B02E344337; Wed, 11 Apr 2001 04:22:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ix.netcorps.com (ix.netcorps.com [207.1.125.106]) by lists.bell-labs.com (Postfix) with ESMTP id 78F3A44336 for ; Wed, 11 Apr 2001 04:21:31 -0400 (EDT) Received: from indigosw.com (194-78-202-25.pro.turboline.skynet.be [194.78.202.25]) by ix.netcorps.com (8.9.0/8.9.0) with ESMTP id BAA00940; Wed, 11 Apr 2001 01:21:21 -0700 (PDT) Message-ID: <3AD413E2.BFBD8E35@indigosw.com> From: David Bertrand Organization: Indigo Software X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'James Undery'" , Jonathan Lennox , "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] not present/otherwise nodes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 11 Apr 2001 10:20:50 +0200 Content-Transfer-Encoding: 7bit Sounds good to me. Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: James Undery [mailto:jundery@ubiquity.net] > > Sent: Tuesday, April 10, 2001 3:37 AM > > To: Jonathan Lennox > > Cc: Jonathan Rosenberg; David Bertrand; 'iptel@lists.bell-labs.com' > > Subject: Re: [IPTEL] not present/otherwise nodes > > > > > > > > > > Jonathan Lennox wrote: > > > > > On Monday, April 9 2001, "Jonathan Rosenberg" wrote to > > "'James Undery', David Bertrand, 'iptel@lists.bell-labs.com'" saying: > > > > > > > > -----Original Message----- > > > > > From: James Undery [mailto:jundery@ubiquity.net] > > > > > > > > > > David Bertrand wrote: > > > > > > > > > > > > Let's suppose a CPL script contains a switch (for > > example based on > > > > > > subject) without the output but with the output > > > > > > . If the variable the switch is to match > > (in this case, > > > > > > subject of call) is not present in the call setup request, > > > > > should the > > > > > > script execute the otherwise node or the default behaviour ? > > > > > > > > > > It should execute the otherwise node, the default behaviour > > > > > is only used > > > > > when there is no match to an output node and no otherwise > > > > > node exists. > > > > > > > > > > > > Hmm. Thats not what we did - we perform the default > > action. Its not clear > > > > from the spec which one is correct. It probably doesn't > > matter much so long > > > > as we pick something. > > > > > > > > Jonathan L. - any comments? > > > > > > I wanted to have the same semantics as the > > C/Java default: tag > > > in a switch statement, so yes, it should cover the > > case if > > > you haven't got a output. > > > > > > This makes using to do negated conditions a lot > > easier, too -- > > > e.g. > > > > > > [do something to > > reach me] > > > [do something to reach my voicemail] > > > > > > > I think you did specify this in the 3rd and 4th paragraphs of > > section 5. > > I don't think its really that clear. How about: > > The output otherwise, which MUST be the last output specified if it > is present, matches if no other condition matched. This includes the > case where the field is not present in the request, and a not-present > output > was not specified. > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- David Bertrand Software Engineer Indigo Software 50 Rue Wiertz Brussels, 1050 - Belgium Phone : +32 2 235 09 44 Fax: +32 2 280 26 76 david@indigosw.com http://www.indigosw.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Apr 20 10:11:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12155 for ; Fri, 20 Apr 2001 10:11:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8643C4433A; Fri, 20 Apr 2001 10:11:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9245A44337 for ; Fri, 20 Apr 2001 10:10:36 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA26234 for ; Fri, 20 Apr 2001 10:14:11 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Apr 2001 10:10:36 -0400 Message-ID: From: Jonathan Rosenberg To: "List Iptel (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] minutes... better late than never Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 20 Apr 2001 10:10:33 -0400 Folks, Unfortunately, I've been totally overloaded by some commitments and missed the deadline for submitting minutes of IETF 50 for inclusion in the proceedings. However, I'm sure the group would still like to see them. So, they are enclosed here. I also have a complete transcript of the session, thanks to the presence of a court stenographer in the meeting. Its a beefy document (some 76 pages of double spaced text). So, instead of posting it, I'm going to put it on the web page, along with slides. I'll send a note to the list when they become available. I owe an updated charter, which will be out in the not too distant future. Hussein has just submitted an updated TRIP spec, based on our discussions during IETF. Once it appears, I will submit it to IESG. Thanks, Jonathan R. IPTEL WG ======== CHAIR: Jonathan Rosenberg Minutes were taken by Joerg Ott. Edited by Jonathan Rosenberg. AGENDA: 1. Agenda Bashing [Rosenberg] - 5 mins 2. CPL Status and Update [Rosenberg] - 5 mins 3. TRIP Open Issue [Rosenberg] - 10 mins 4. Transit Network Selection [Walker] - 10 mins 5. TRIP MIB Update and Issues [Walker] - 10 mins 6. Service Codes [Peterson] - 10 mins 7. New Charter discussion [Rosenberg] - 30 mins CPL Update ---------- - CPL submitted to IESG in November 2000 - end of Dec: IESG reports back concerns - using a subset of iCalendar can lead to interop problems - CPL -> tools works - tools -> CPL does not - If iCalendar is too big to be implemented, it must be fixed in calsch for all - calsch group not aware of CPL efforts - calsch chair, Patricia Egen, agreeds to look at spec - discussion took off (on calsch list) - syntax: a few concerns of not using the sntax -> not considered that big a deal - only one commendator on use of subset - John Stracke - agrees that iCalendar is too large - UI can't represent all of ical - computing and memory requirements are an issue - agrees to write up subset definition - subset written by John S. and Jonathan Lennox - to be discussed this Wednesday - Proposal - agree to the proposed ical subset - re-write CPL spec to reference subset document - CPL and subset doc go to RFC simultaneously TRIP Open Issue (Jonathan) ------------------------- - WG last call ages ago - comments came up only slowly - shall be drawn to conclusion quickly - comment this meeting or this week and then be silent Issue #1: - intra-domain topology updates really only need ITADTopology attribute However, spec mandates WirhdrawnRoutes, ReachableRoutes, and other as mandatory for all messages. These will all be zero length, which is pointless. - Proposal - define new message for intradomain topology updates (1) - remove requirement for all attributes to be present (2) - Jonathan proposal on the list: remove requirement (2) Comment: text must say that there needs to be "at least one these elements" -> consensus: go with (2), modify according to comments Issue #2: Address families - decimal - penta-decimal E.164 is decimal but can be anything - what if it is defined as part of a peering agreeemnt? concern: in practice, handling anything but E.164 is hard What to do: a: define an E.164 address family b: don't define it Proposal: - keep things explicit - define an E.164 address family Q: w/ this, do we still beed decimal and penta-decimal -> YES CONSENSUS also on this one Transit network selectionm (Dave Walker) ---------------------------------------- draft-walker-iptel-trip-tns-01.txt - PSTN allows for multiple routes to a destination (e.g. different carriers) - TNS code indicates preferred carriers (Carried identification code) - users may pre-subscribe or dial carrier access code - national identification plans - ANSI ISUP - networks respect TNS except for local ermination IPTEL solution - users may access both IP and PSTN based carriers - for IP-based carriers, set the URI accorndingly - for PSTN-based carriers, IP network must route the call to the right network - need to distribute "best" route to the specified TN through TRIP - exactly the same problem as TRIP solves for dialled numbers This generated a lively discussion. Dave Oran had a concern about using a routing protocool do distribute routes to intermediate carriers. The equivalent would be BGP distributing routes to AS instead of IP addresses. The answer was that as far as the IP network is concerned, these carriers are not intermediaries, but end points (gateways to that carrier). Some argued that Dave's point implied that this was an attribute. Jon Peterson argued for an address family. One issue is whether a carrier can terminate calls to any number. If not, then we need to propagate carrier information and the routes they can reach. It was pointed out that in the US, it is mandatory for a carrier to route to any number. The problem, though, with using TNS as a route attribute is that you don't want the route with the longest prefix; you want to use the route which matches the carrier requested for the call. It was agreed to spawn this to the list. It will not go into the TRIP spec. TRIP MIB (Dave Walker) ---------------------- - update -04 draft - initial support for authentication - aplIndex from network services MIB - is it needed? -> proposal from Jonathan: YES - require generic mechanism for handling? - new attributes - new address families - new protocol families - security (suport for authentication draft) - compliance statements (to do) DW feels that this is very stable. Please, folks, take a closer look at it from your side before we go to last call. Using Service Codes in SIP (Jon Peterson) ----------------------------------------- draft-jfp-service-codes-00 investigation on what is necessary in TRIP for service routing experimental work to show requirements Overview of service codes: - proposal for attributes associated with propageted routes in TRIP which characterize the service offered by the originator of the route Why use service codes in TRIP? - feature interaction among network applications Basic TRIP service codes - update (adds service code attr; e.g. LNP) real strength if TRIP and VoIP protocol interact - definition of a service code field for the Request URI sip:jo@tzi.de;sc=x - concept of a feature proxy at which services for a particular route are composed Feature proxy: conventional 2543 proxy - acts as outbound server - acts as location server/registrar - supports service codes Henning was concerned about an approach with enumerates application names. Sounds like what telcos do today. Dave Oran was concerned that this would require running arbitrary application programs on a proxy - active networks. Do we want to go there? Henning argued that CPL should be used instead; CPL would direct this feature proxy to send calls wherever you want. Otherwise, voice mail may be code 17 with one provider, 25 with another; may have to update your CPL repeatedly. He argued that services are location independent; what we are doing here is re-inventing SLP on a global scale. Dave pointed out that we may be tripping over the meaning of the word "service". It was clear that there was a lot of difference of opinion about what was being presented, and what the value was. New Charter Discussion (JR) --------------------------- New charter was sent to the list 1. TRIP MIB (proposed) 2. TEIP operational guidelines (BCP) 3. GW registrrations (proposed) 4. (informational) Not on the charter: - CPL - Draft version of TRIP -> need much more experience first TRIP MIB --------- - proposed completion: Dec 01 - based on current TRIP MIB doc TRIP ops BCP ------------ - most complexities are in usage and policies - proposed completion: Feb 02 GW Registration --------------- - draft-rs-trip-gw-01 - proposed completion: Sep 01 VoIP Routing Framework ---------------------- - inter-domain - intra-domain - gw registers - servcie routing good to document these problems and their requirements - draft future work on service routing and intra-domain route exchange starting points: service codes and gw registration as strating points - completion Sep 01 Other proposals: tel: URL -------- - bring to draft standards - freeephone and LNP extensions - trunk group ids - basically -- SS7 extensions TRIP authentication attribute document --------------------------------------- - huge problem here; is this needed at all? - look for a real need first! Discussion points: - are these real problems to solve? - are there people willing to work on? - commitment to write text! - shutting down is a *very* acceptable result! Hennings point was that the TRIP MIB is harmless. The tel URL work needs to be done, since its broken. However, he felt that the other work was not yet working group material, since it was a little premature. Jonathan agreed that there are implementations of TRIP; but there is not yet real deployment. Dave Oran felt that we need to do the MIB, and we want the gateway registration thing. The service routing work and operational guidelines are to premature. No opinion on the tel URL. Jon Peterson argued that we should do gateway registration and the tel URL. Scott Bradner said that there shouldn't be operational guidelines at this point. Gateway registration work is OK, but he is was not clear on why the tel URL work should be here. Service routing was too premature. MIB should get done. There was some discussion on the tel URL. Scott suggested that a design team, outside of any working group, work on fixing up rfc2806. Henning expressed interest in leading that activity. Given this input, Jonathan made the following proposal for rechartering: - GW registration - TRIP MIB Now the call for volunteers. We need enough to be able to work on these. We had sufficient people to work on both items. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Apr 20 10:49:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12765 for ; Fri, 20 Apr 2001 10:49:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F1603443A4; Fri, 20 Apr 2001 10:49:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from itecid1.telecom-co.net (unknown [200.21.27.173]) by lists.bell-labs.com (Postfix) with ESMTP id C25854433A for ; Fri, 20 Apr 2001 10:40:16 -0400 (EDT) Received: from jcmm ([200.21.27.13]) by itecid1.telecom-co.net (8.9.3+Sun/8.9.1) with SMTP id JAA12897 for ; Fri, 20 Apr 2001 09:43:44 -0500 (GMT) Message-ID: <002001c0c9a7$c7bb5bc0$0d1b15c8@telecomco.net> From: "Juan Carlos" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C0C97D.DA469E50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [IPTEL] length of body of SIP Register Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 20 Apr 2001 09:39:53 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C0C97D.DA469E50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, i am developing a aplication of sip that uses a script cpl in the = body of Register but i don't know what length must have the body in = Register message, can anybody tell me? Thanks in advantage ------=_NextPart_000_001D_01C0C97D.DA469E50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, i am developing a aplication of sip = that uses a=20 script cpl in the body of Register but i don't know what length must = have the=20 body in Register message, can anybody tell me?
 
Thanks in = advantage
------=_NextPart_000_001D_01C0C97D.DA469E50-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Apr 21 01:34:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28184 for ; Sat, 21 Apr 2001 01:34:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3B25344337; Sat, 21 Apr 2001 01:34:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A26FA44336 for ; Sat, 21 Apr 2001 01:33:33 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA04706; Sat, 21 Apr 2001 01:37:02 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sat, 21 Apr 2001 01:33:27 -0400 Message-ID: From: Jonathan Rosenberg To: Jonathan Lennox , David Bertrand Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] CPL: address matching without subfield MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sat, 21 Apr 2001 01:33:16 -0400 Getting back to some old email threads... > -----Original Message----- > From: Jonathan Lennox [mailto:lennox@cs.columbia.edu] > Sent: Wednesday, April 04, 2001 3:23 PM > To: David Bertrand > Cc: 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] CPL: address matching without subfield > > > On Wednesday, April 4 2001, "David Bertrand" wrote to > "'iptel@lists.bell-labs.com'" saying: > > > Hi, > > > > In section 5.1.1 of the last draft on CPL concerning usage of > > address-switch with SIP, it states: > > > > "If no subfield is specified for addresses in SIP messages, > the string > > matched is the URI part of the address. For "sip" URLs, all > parameters > > are stripped;" > > > > My question is : Is the port number a parameter ? > > and whatever the response, does an absent port match the > default port > > number (like in the paragraph concerning port number matching)? > > > > For example: - if the port number is a parameter: > > If the address given in the script is > "sip:john@company.com:5060" > > and if the URI in the SIP message (without parameters) is > > "sip:john@company.com", should they match ? > > > > - if the port number is not a parameter: > > If the address given in the script is "sip:john@company.com" and > > if the URI in the SIP message (without parameters) > > is "sip:john@company.com:5060", should they match ? > > I think that default ports should be omitted from the URI > when doing URI > matching. Actually, I think we should specify that the matching be done based on the URI matching rules defined in the sip spec. This way, we can avoid defining a new URI matching algorithm. However, I don't think this is what the spec says. > Given that > there's going to have to be one more revision for the > time-switch stuff, > would we have to do a second IESG cycle if I changed this? I don't think this is a big deal. IESG last call exists to fix problems. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Apr 21 08:35:02 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09909 for ; Sat, 21 Apr 2001 08:35:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9919644337; Sat, 21 Apr 2001 08:35:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from web14101.mail.yahoo.com (web14101.mail.yahoo.com [216.136.172.131]) by lists.bell-labs.com (Postfix) with SMTP id 28FAC44336 for ; Sat, 21 Apr 2001 08:34:17 -0400 (EDT) Message-ID: <20010421123413.31262.qmail@web14101.mail.yahoo.com> Received: from [172.155.184.154] by web14101.mail.yahoo.com; Sat, 21 Apr 2001 05:34:13 PDT From: Conference 101 To: iptel@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [IPTEL] Video Conferencing SDK Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sat, 21 Apr 2001 05:34:13 -0700 (PDT) Hello, Does anybody have any experience with the VidShare Video Conferencing ActiveX from www.globestream.net ? This seems like a great tool and I'd like to discuss with some people that are familiar with it. Justin. __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Apr 23 13:25:07 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07467 for ; Mon, 23 Apr 2001 13:25:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0690044338; Mon, 23 Apr 2001 13:25:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by lists.bell-labs.com (Postfix) with ESMTP id 3BAF844337 for ; Mon, 23 Apr 2001 13:24:40 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A50354F0150; Mon, 23 Apr 2001 13:23:15 -0400 Message-ID: <000901c0cc1a$88389740$2300000a@acmepacket.com> From: "Bob Penfield" To: "IPTEL List" , , MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [IPTEL] TRIP MIB Question Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 23 Apr 2001 13:26:28 -0400 Content-Transfer-Encoding: 7bit The tripPeerEntry object (page 11-12 of draft-zinman-trib-mib-01.txt) only allows a single tripPeerSupportedProtocol and tripPeerAddressFamily, yet the TRIP spec provides for multiple Route Types Supported in the OPEN message. Also, the address family and protocol are joined together in the Route Types Supported capability info of the OPEN message. Shouldn't there be a list of TripAppProtocol+TripAddressFamily pairs in the tripPeerEntry object? Thanks, Bob d:-) Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Apr 25 15:29:17 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28097 for ; Wed, 25 Apr 2001 15:29:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 73396443C4; Wed, 25 Apr 2001 15:29:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by lists.bell-labs.com (Postfix) with ESMTP id 784A944336 for ; Wed, 25 Apr 2001 15:16:22 -0400 (EDT) Received: from DAVID ([192.168.1.61]) by ss8mail1.ss8ott with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JGDT59GV; Wed, 25 Apr 2001 15:19:15 -0400 From: "David Zinman" To: "Bob Penfield" , "IPTEL List" Cc: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000901c0cc1a$88389740$2300000a@acmepacket.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: [IPTEL] RE: TRIP MIB Question Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 25 Apr 2001 15:15:44 -0400 Content-Transfer-Encoding: 7bit Bob, I am going to try to tackle two problems here. The first is the issue of adding new protocols and address families. ==================================================================== I propose to remove the TC for TripAppProtocol and assign object identifiers (OIDs) to the protocols. We would have an entry in the TRIP MIB for TRIP Supported Protocols: tripSupportedProtocols OBJECT IDENTIFIER ::= { trip 100 } Then each protocol would be defined under this MIB tree branch: tripSupProtSIP OBJECT IDENTIFIER ::= { tripSupportedProtocols 1 } tripSupProtH323Q931 OBJECT IDENTIFIER ::= { tripSupportedProtocols 2 } tripSupProtH323RAS OBJECT IDENTIFIER ::= { tripSupportedProtocols 3 } tripSupProtH323ANNEXG OBJECT IDENTIFIER ::= { tripSupportedProtocols 4 } If a new protocol is used it can be defined by the private enterprise MIB implementers. Eg: myPrivateEntProtocol OBJECT IDENTIFIER ::= { privEntProts 1 } As protocols are developed it would be easy to add them using this method. Similarly for address families we would remove the TC for address families and define another OID: tripAddressFamilies OBJECT IDENTIFIER ::= { trip 101 } Then each address family would be defined under this MIB tree branch: tripAddrFamilyDecimal OBJECT IDENTIFIER ::= { tripAddressFamilies 1 } tripAddrFamilyHex OBJECT IDENTIFIER ::= { tripAddressFamilies 2 } New address families could be added into the private enterprise MIB. Eg: myPrivateEntAddrFamily OBJECT IDENTIFIER ::= { privEntAddrFamilies 1 } Again it would be easy to add more address families. TripAppProtocol+TripAddressFamily Pairs ======================================= I propose this solution to the problem of multiple TripAppProtocol+TripAddressFamily pairs outlined by Bob Penfield: - Remove tripPeerSupportedProtocol and tripPeerAddressFamily from the Peer Table. - Add a new 'sub' table to the Peer Table called tripPeerRouteTypeTable which will have the following structure: tripPeerRouteTypeTable OBJECT-TYPE SYNTAX SEQUENCE OF TripPeerRouteTypeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The TRIP peer Route Type table. This table contains one entry per supported protocol - address family pair." ::= { trip x } tripPeerRouteTypeEntry OBJECT-TYPE SYNTAX TripPeerRouteTypeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry containing information about the route type that the TRIP peer supports." INDEX { applIndex, tripPeerRemoteAddrInetType, tripPeerRemoteAddr, tripPeerRtTypeProtocolId, tripPeerRtTypeAddrFamilyId } ::= { tripPeerRouteTypeTable 1 } TripPeerRouteTypeEntry ::= SEQUENCE { tripPeerRtTypeProtocolId OBJECT IDENTIFIER, tripPeerRtTypeAddrFamilyId OBJECT IDENTIFIER, tripPeerRtTypeSupportedProtocol OBJECT IDENTIFIER, tripPeerRtTypeAddrFamily OBJECT IDENTIFIER } tripPeerRtTypeProtocolId OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier of a protocol that this peer is using." ::= { tripPeerRouteTypeEntry 1 } tripPeerRtTypeAddrFamilyId OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier of an address family that this peer belongs to." ::= { tripPeerRouteTypeEntry 2 } tripPeerRtTypeSupportedProtocol OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "A protocol that this peer is using." ::= { tripPeerRouteTypeEntry 3 } tripPeerRtTypeAddrFamily OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An address family that this peer belongs to." ::= { tripPeerRouteTypeEntry 4 } Or instead, alternatively the table could be indexed by arbitrary integers and each Protocol/AddressFamily pair would be displayed as raw integers, NOT as OIDs as described above. Eg: +--------------+--------------+-------+----------+----------------+ | PeerInetType | PeerInetAddr | index | Protocol | Address Family | +--------------+--------------+-------+----------+----------------+ | 1 | 192.1.34.55 | 1 | 1 | 1 | +--------------+--------------+-------+----------+----------------+ | 1 | 192.1.34.55 | 2 | 1 | 2 | +--------------+--------------+-------+----------+----------------+ | 2 |4e:14:00:72...| 3 | 3 | 2 | +--------------+--------------+-------+----------+----------------+ | 16 | myDnsName@so | 4 | 2 | 1 | +--------------+--------------+-------+----------+----------------+ ... This way is easier but much less descriptive because the integers would have to be looked up in all cases to map the protocol and address families to expressive names. Cheers, DZ --- David Zinman Software Designer SS8 Networks Inc. Phone: (613)592-2100 Fax: (613)592-9634 mailto:david@ss8.com http://www.ss8.com -----Original Message----- From: Bob Penfield [mailto:bpenfield@acmepacket.com] Sent: Monday, April 23, 2001 1:26 PM To: IPTEL List; drwalker@ss8.com; david@ss8.com Subject: TRIP MIB Question The tripPeerEntry object (page 11-12 of draft-zinman-trib-mib-01.txt) only allows a single tripPeerSupportedProtocol and tripPeerAddressFamily, yet the TRIP spec provides for multiple Route Types Supported in the OPEN message. Also, the address family and protocol are joined together in the Route Types Supported capability info of the OPEN message. Shouldn't there be a list of TripAppProtocol+TripAddressFamily pairs in the tripPeerEntry object? Thanks, Bob d:-) Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Apr 26 08:55:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01813 for ; Thu, 26 Apr 2001 08:55:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D918C4436E; Thu, 26 Apr 2001 08:55:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 1F0494436E for ; Thu, 26 Apr 2001 07:20:43 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27974; Thu, 26 Apr 2001 07:20:42 -0400 (EDT) Message-Id: <200104261120.HAA27974@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: iptel@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 26 Apr 2001 07:20:42 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : Telephony Routing over IP (TRIP) Author(s) : J. Rosenberg, H. Salama, M. Squire Filename : draft-ietf-iptel-trip-05.txt Pages : 82 Date : 25-Apr-01 This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIPÆs operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-trip-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-trip-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010425142732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-trip-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-trip-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010425142732.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Apr 26 11:10:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07318 for ; Thu, 26 Apr 2001 11:10:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 29C6744385; Thu, 26 Apr 2001 11:10:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by lists.bell-labs.com (Postfix) with ESMTP id 6013B44378 for ; Thu, 26 Apr 2001 11:09:23 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A9CD373014A; Thu, 26 Apr 2001 11:07:57 -0400 Message-ID: <002901c0ce63$1f519ba0$2300000a@acmepacket.com> From: "Bob Penfield" To: "David Zinman" , "IPTEL List" Cc: References: Subject: Re: [IPTEL] RE: TRIP MIB Question MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 26 Apr 2001 11:11:08 -0400 Content-Transfer-Encoding: 7bit David, I think that is an excellent solution. I'm a bit confused though. Why are there 4 fields in the tripPeerRouteTypeEntry sub-table? What is the difference between "tripPeerRtTypeProtocolId" and "tripPeerRtTypeSupportedProtocol" ? What is the difference between "tripPeerRtTypeAddrFamilyId" and "tripPeerRtTypeAddrFamily" ? Please forgive my MIB ignorance. Bob d:-) Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "David Zinman" To: "Bob Penfield" ; "IPTEL List" Cc: Sent: Wednesday, April 25, 2001 3:15 PM Subject: [IPTEL] RE: TRIP MIB Question > Bob, > > I am going to try to tackle two problems here. > > The first is the issue of adding new protocols and address families. > ==================================================================== > > I propose to remove the TC for TripAppProtocol and assign object > identifiers (OIDs) to the protocols. We would have an entry in the > TRIP MIB for TRIP Supported Protocols: > > tripSupportedProtocols OBJECT IDENTIFIER ::= { trip 100 } > > Then each protocol would be defined under this MIB tree branch: > > tripSupProtSIP OBJECT IDENTIFIER ::= { tripSupportedProtocols 1 } > tripSupProtH323Q931 OBJECT IDENTIFIER ::= { tripSupportedProtocols 2 } > tripSupProtH323RAS OBJECT IDENTIFIER ::= { tripSupportedProtocols 3 } > tripSupProtH323ANNEXG OBJECT IDENTIFIER ::= { tripSupportedProtocols 4 } > > If a new protocol is used it can be defined by the private enterprise > MIB implementers. Eg: > > myPrivateEntProtocol OBJECT IDENTIFIER ::= { privEntProts 1 } > > As protocols are developed it would be easy to add them using this method. > > > Similarly for address families we would remove the TC for address families > and define another OID: > > tripAddressFamilies OBJECT IDENTIFIER ::= { trip 101 } > > Then each address family would be defined under this MIB tree branch: > > tripAddrFamilyDecimal OBJECT IDENTIFIER ::= { tripAddressFamilies 1 } > tripAddrFamilyHex OBJECT IDENTIFIER ::= { tripAddressFamilies 2 } > > New address families could be added into the private enterprise > MIB. Eg: > > myPrivateEntAddrFamily OBJECT IDENTIFIER ::= { privEntAddrFamilies 1 } > > Again it would be easy to add more address families. > > > TripAppProtocol+TripAddressFamily Pairs > ======================================= > I propose this solution to the problem of multiple > TripAppProtocol+TripAddressFamily pairs outlined by Bob Penfield: > > - Remove tripPeerSupportedProtocol and tripPeerAddressFamily > from the Peer Table. > > - Add a new 'sub' table to the Peer Table called > tripPeerRouteTypeTable which will have the following > structure: > > tripPeerRouteTypeTable OBJECT-TYPE > SYNTAX SEQUENCE OF TripPeerRouteTypeEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The TRIP peer Route Type table. This table contains one > entry per supported protocol - address family pair." > ::= { trip x } > > tripPeerRouteTypeEntry OBJECT-TYPE > SYNTAX TripPeerRouteTypeEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Entry containing information about the route type that > the TRIP peer supports." > INDEX { applIndex, > tripPeerRemoteAddrInetType, > tripPeerRemoteAddr, > tripPeerRtTypeProtocolId, > tripPeerRtTypeAddrFamilyId } > ::= { tripPeerRouteTypeTable 1 } > > TripPeerRouteTypeEntry ::= SEQUENCE { > tripPeerRtTypeProtocolId OBJECT IDENTIFIER, > tripPeerRtTypeAddrFamilyId OBJECT IDENTIFIER, > tripPeerRtTypeSupportedProtocol OBJECT IDENTIFIER, > tripPeerRtTypeAddrFamily OBJECT IDENTIFIER > } > > tripPeerRtTypeProtocolId OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The identifier of a protocol that this peer is using." > ::= { tripPeerRouteTypeEntry 1 } > > tripPeerRtTypeAddrFamilyId OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The identifier of an address family that this peer belongs to." > ::= { tripPeerRouteTypeEntry 2 } > > tripPeerRtTypeSupportedProtocol OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A protocol that this peer is using." > ::= { tripPeerRouteTypeEntry 3 } > > tripPeerRtTypeAddrFamily OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "An address family that this peer belongs to." > ::= { tripPeerRouteTypeEntry 4 } > > > Or instead, alternatively the table could be indexed by arbitrary > integers and each Protocol/AddressFamily pair would be displayed > as raw integers, NOT as OIDs as described above. Eg: > > +--------------+--------------+-------+----------+----------------+ > | PeerInetType | PeerInetAddr | index | Protocol | Address Family | > +--------------+--------------+-------+----------+----------------+ > | 1 | 192.1.34.55 | 1 | 1 | 1 | > +--------------+--------------+-------+----------+----------------+ > | 1 | 192.1.34.55 | 2 | 1 | 2 | > +--------------+--------------+-------+----------+----------------+ > | 2 |4e:14:00:72...| 3 | 3 | 2 | > +--------------+--------------+-------+----------+----------------+ > | 16 | myDnsName@so | 4 | 2 | 1 | > +--------------+--------------+-------+----------+----------------+ > ... > > This way is easier but much less descriptive because the integers > would have to be looked up in all cases to map the protocol and > address families to expressive names. > > Cheers, > DZ > > --- > David Zinman Software Designer > SS8 Networks Inc. > Phone: (613)592-2100 Fax: (613)592-9634 > mailto:david@ss8.com http://www.ss8.com > > > > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Monday, April 23, 2001 1:26 PM > To: IPTEL List; drwalker@ss8.com; david@ss8.com > Subject: TRIP MIB Question > > > > The tripPeerEntry object (page 11-12 of draft-zinman-trib-mib-01.txt) only > allows a single tripPeerSupportedProtocol and tripPeerAddressFamily, yet the > TRIP spec provides for multiple Route Types Supported in the OPEN message. > Also, the address family and protocol are joined together in the Route Types > Supported capability info of the OPEN message. Shouldn't there be a list of > TripAppProtocol+TripAddressFamily pairs in the tripPeerEntry object? > > Thanks, > > Bob > d:-) > > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Apr 26 11:40:07 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08725 for ; Thu, 26 Apr 2001 11:40:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A3FA544378; Thu, 26 Apr 2001 11:40:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9679A44369 for ; Thu, 26 Apr 2001 11:39:09 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA20232 for ; Thu, 26 Apr 2001 11:42:46 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Apr 2001 11:39:09 -0400 Message-ID: From: Jonathan Rosenberg To: "'iptel@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] slides from IETF 50 available Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 26 Apr 2001 11:39:01 -0400 Folks, Slides from IETF 50 are now available from the iptel website: http://www.bell-labs.com/mailing-lists/iptel/ -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Apr 27 02:20:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16967 for ; Fri, 27 Apr 2001 02:20:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 12E6844339; Fri, 27 Apr 2001 02:20:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id CEE8644338 for ; Fri, 27 Apr 2001 02:19:59 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA29030 for ; Fri, 27 Apr 2001 02:23:34 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Apr 2001 02:19:56 -0400 Message-ID: From: Jonathan Rosenberg To: "List Iptel (E-mail)" Subject: FW: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0CEE2.141B24D0" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 27 Apr 2001 02:19:51 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0CEE2.141B24D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, This latest version of TRIP incorporates the changes we agreed upon at = the last IETF. I am now issuing a sort, one week working group last call on = this document in order to give people a chance to look over the new draft = (since a working group last call has already been issued on -04). I will = submit it to IESG on May 4 barring any further comments. Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, April 26, 2001 7:21 AM Cc: iptel@lists.bell-labs.com Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the = IETF. Title : Telephony Routing over IP (TRIP) Author(s) : J. Rosenberg, H. Salama, M. Squire Filename : draft-ietf-iptel-trip-05.txt Pages : 82 Date : 25-Apr-01 =09 This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIP=C6s operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-05.txt Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-trip-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-trip-05.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C0CEE2.141B24D0 Content-Type: message/rfc822 To: Subject: Date: Fri, 27 Apr 2001 02:19:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C0CEE2.141B24D0" ------_=_NextPart_002_01C0CEE2.141B24D0 Content-Type: text/plain ------_=_NextPart_002_01C0CEE2.141B24D0 Content-Type: application/octet-stream; name="ATT08202.txt" Content-Disposition: attachment; filename="ATT08202.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010425142732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-trip-05.txt ------_=_NextPart_002_01C0CEE2.141B24D0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-iptel-trip-05.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C0CEE2.141B24D0-- ------_=_NextPart_000_01C0CEE2.141B24D0-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Apr 27 09:08:05 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27435 for ; Fri, 27 Apr 2001 09:08:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE01F44339; Fri, 27 Apr 2001 09:08:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by lists.bell-labs.com (Postfix) with ESMTP id EEF3A44338 for ; Fri, 27 Apr 2001 09:07:12 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AEA63301B0; Fri, 27 Apr 2001 09:05:42 -0400 Message-ID: <00b901c0cf1b$23d06360$2300000a@acmepacket.com> From: "Bob Penfield" To: "List Iptel (E-mail)" , "Jonathan Rosenberg" Cc: References: Subject: Re: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 27 Apr 2001 09:08:20 -0400 Content-Transfer-Encoding: 8bit Hi all, David Zinman's latest proposal for Route Types Supported in the TRIP MIB: http://lists.bell-labs.com/pipermail/iptel/2001q2/000617.html includes provisions for private enterprise protocols and address families. However, TRIP does not reserve any vendor-specific name space for the protocol and address family. I know there have been a few proposals for new address families over the last year or so. I think we need to set aside some name space to experiment with new protocols and address families before permanently polluting the IANA registry. I apologize if this issue has already been debated and resolved. Thanks, Bob d:-) Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Jonathan Rosenberg" To: "List Iptel (E-mail)" Sent: Friday, April 27, 2001 2:19 AM Subject: FW: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt Folks, This latest version of TRIP incorporates the changes we agreed upon at the last IETF. I am now issuing a sort, one week working group last call on this document in order to give people a chance to look over the new draft (since a working group last call has already been issued on -04). I will submit it to IESG on May 4 barring any further comments. Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, April 26, 2001 7:21 AM Cc: iptel@lists.bell-labs.com Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : Telephony Routing over IP (TRIP) Author(s) : J. Rosenberg, H. Salama, M. Squire Filename : draft-ietf-iptel-trip-05.txt Pages : 82 Date : 25-Apr-01 This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIPÆs operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-trip-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-trip-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Apr 30 20:34:08 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29140 for ; Mon, 30 Apr 2001 20:34:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7E56544356; Mon, 30 Apr 2001 20:34:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 9121344338 for ; Mon, 30 Apr 2001 20:33:30 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f410XWj05381; Mon, 30 Apr 2001 17:33:32 -0700 (PDT) Received: from cisco.com (dhcp-128-107-141-120.cisco.com [128.107.141.120]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AJL05519 (AUTH hsalama); Mon, 30 Apr 2001 17:33:28 -0700 (PDT) Message-ID: <3AEE0454.1BAA5CB4@cisco.com> From: "Hussein F. Salama" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield Cc: "List Iptel (E-mail)" , Jonathan Rosenberg Subject: Re: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt References: <00b901c0cf1b$23d06360$2300000a@acmepacket.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 30 Apr 2001 17:33:24 -0700 Content-Transfer-Encoding: 8bit Bob Penfield wrote: > Hi all, > > David Zinman's latest proposal for Route Types Supported in the TRIP MIB: > > http://lists.bell-labs.com/pipermail/iptel/2001q2/000617.html > > includes provisions for private enterprise protocols and address families. > However, TRIP does not reserve any vendor-specific name space for the > protocol and address family. I know there have been a few proposals for new > address families over the last year or so. I think we need to set aside some > name space to experiment with new protocols and address families before > permanently polluting the IANA registry. Both the application protocol field and the address family field are 16 bits long. So I don't see a problem with setting aside a subset for vendor-specific use. Hussein > > > I apologize if this issue has already been debated and resolved. > > Thanks, > > Bob > d:-) > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "Jonathan Rosenberg" > To: "List Iptel (E-mail)" > Sent: Friday, April 27, 2001 2:19 AM > Subject: FW: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt > > Folks, > > This latest version of TRIP incorporates the changes we agreed upon at the > last IETF. I am now issuing a sort, one week working group last call on this > document in order to give people a chance to look over the new draft (since > a working group last call has already been issued on -04). I will submit it > to IESG on May 4 barring any further comments. > > Thanks, > Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Thursday, April 26, 2001 7:21 AM > Cc: iptel@lists.bell-labs.com > Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-05.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Telephony Working Group of the IETF. > > Title : Telephony Routing over IP (TRIP) > Author(s) : J. Rosenberg, H. Salama, M. Squire > Filename : draft-ietf-iptel-trip-05.txt > Pages : 82 > Date : 25-Apr-01 > > This document presents the Telephony Routing over IP (TRIP). TRIP is > a policy driven inter-administrative domain protocol for advertising > the reachability of telephony destinations between location servers, > and for advertising attributes of the routes to those destinations. > TRIPÆs operation is independent of any signaling protocol, hence > TRIP can serve as the telephony routing protocol for any signaling > protocol. > The Border Gateway Protocol (BGP-4) is used to distribute routing > information between administrative domains. TRIP is used to > distribute telephony routing information between telephony > administrative domains. The similarity between the two protocols is > obvious, and hence TRIP is modeled after BGP-4. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-05.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-iptel-trip-05.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-iptel-trip-05.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. -- Hussein F. Salama Cisco Systems Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel