From extest-admin@lists.bell-labs.com  Wed Nov  1 06:20:35 2000
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 GAA13617
	for <iptel-archive@odin.ietf.org>; Wed, 1 Nov 2000 06:20:35 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 4691644AF9
	for <iptel-archive@lists.ietf.org>; Wed,  1 Nov 2000 05:09:30 -0500 (EST)
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: <20001101100930.4691644AF9@lists.bell-labs.com>
Date: Wed,  1 Nov 2000 05:09:30 -0500 (EST)

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  Fri Nov  3 14:29:47 2000
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 OAA20053
	for <iptel-archive@odin.ietf.org>; Fri, 3 Nov 2000 14:29:46 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C446044361; Fri,  3 Nov 2000 13:29:01 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66])
	by lists.bell-labs.com (Postfix) with ESMTP id 1CBC544336
	for <iptel@lists.bell-labs.com>; Fri,  3 Nov 2000 13:28:48 -0500 (EST)
Received: by dnspri.npac.com; id NAA22985; Fri, 3 Nov 2000 13:28:41 -0600 (CST)
Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0)
	id xma022785; Fri, 3 Nov 00 13:28:00 -0600
Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21)
	id <VMZFKSQN>; Fri, 3 Nov 2000 13:26:24 -0600
Message-ID: <ED88182BFF78D211A4D800A0C9E9435CB1C7F8@dc02.npac.com>
From: James Yu <james.yu@neustar.com>
To: "'drwalker@ss8networks.com'" <drwalker@ss8networks.com>
Cc: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: [iptel] draft-walker-iptel-trip-tns-00.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 3 Nov 2000 13:29:53 -0600

Dave,

In your draft, you proposed to add an attribute to the existing "routing
number (I assume that it is what we agreed through previous discussions)"
address family instead of a new address family in TRIP for the "transit
network selection."  Your reason was that this "transit network selection"
must be associated with the E.164 number because the receiving carrier may
not be able to terminate the call to an E.164 number (e.g., only handle IP
devices). 

IMHO we need a new address family in TRIP for the "transit network
selection" because it contains distinctive routing information.  If a call
is to be routed to a particular carrier (identified by the "transit network
selection") to handle a call to a called party address, which can be an
E.164 number or something else  (e.g., called party's E.164 number or sip
URL), the call should be passed to that carrier regardless of the callled
party's address type.  How that carrier uses the called party's address is
that carrier's business.  For example, even if that carrier does not
terminate the E.164 number directly, it can route the call to the PSTN or
perform an ENUM query to retrieve URLs and others for that E.164 number.
Therefore, if a switch has the "transit network selection," it should route
the call using it regardless of the called party's address or routing
number.  So the suggestion is to use a new address family for "transit
network selection."   We'll have a distinctive address family that make the
TRIP information exchange much easier and the TRIP routing simpler and
straightforward.

In draft-yu-tel-url-np-00, I proposed two extensions to the "tel" URL to
support number portability, "rn" and "npdi".  "rn" carries the routing
number, and "npdi" is to indicate whether number portability database dip
has been performed.  I'm revising that I-D to support 800 service.  One new
parameter for 800 support is the "cic" or Carrier Identification Code that
identifies the carrier and is equivalent to the "transit network selection"
(at least in the U.S.).   That same parameter can be used to carry the
"transit network selection" if it needs to be carried in the SIP message.
The "cic" or "transit network selection"  can be received in the incoming
ISUP or SIP message or resulted from a service trigger such as 800 number
translation.

I have an example where a tel or SIP URL contains the telephone number,
routing number (e.g., rn) and cic.  The example is

  tel:+1-202-533-1234;rn=+1-202-544-0000;cic=+1-5678     or
  sip:+1-202-533-1234;rn=+1-202-544-0000;cic=+1-5678@abc.com

Although the example represents a rare case, it is used to show how call
routing can be done when the three numbers/addresses are all present. The
procedure would be: 

- When all three numbers/addresses are present, "cic" is used first until
the signaling message reaches the carrier identified by the "cic" and that
carrier needs to remove the cic.  

- If only "rn" and telephone number are present, "rn" is used.  

- If only the telephone number is available, it is used as the "routing
number" to route (check against the TRIP "routing number" address family
table).  Hopefully, somewhere down the road, a switch/server will perform a
NP dip to get the "rn" in the NP environment.
  
The first step requires a new address family for the "transit network
selection" or "carrier ID code."  The second and third steps uses the
existing "routing number" address family.

For "cic" to appear in a sip URL that does not contain a telephone number
(e.g., sip:UserA@abc.com), a new parameter may need to be added.

James Yu
Principal Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue, NW,
Suite 550
Washington, D.C. 20005
USA
+1-202-533-2814 (B)
+1-202-533-2976 (Fax)
james.yu@neustar.com
http://www.neustar.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 Nov  6 06:18:00 2000
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 GAA08131
	for <iptel-archive@odin.ietf.org>; Mon, 6 Nov 2000 06:18:00 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5653844342; Mon,  6 Nov 2000 05:18:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from rj01pol04.informatica.telerj.net.br (rj01pol04.informatica.telerj.net.br [200.222.3.20])
	by lists.bell-labs.com (Postfix) with ESMTP id C2AEF44341
	for <iptel@lists.bell-labs.com>; Mon,  6 Nov 2000 05:17:23 -0500 (EST)
Received: by rj01pol04.informatica.telerj.net.br with Internet Mail Service (5.5.2650.21)
	id <WGGTKH5M>; Mon, 6 Nov 2000 09:19:25 -0200
Message-ID: <BA145EA73FA21F48A19D26BE39E026D22CE2D4@CORREIO2-RJ>
From: "Kleber Farias Pinto Jr." <kleber@telemar-rj.com.br>
To: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] unsubscribe
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 6 Nov 2000 09:16:22 -0200
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA08131

unsubscribe
please

  K l e b e r    F a r i a s  
               C OORDENADOR
           PROVISIONAMENTO
 C O M U N I C A Ç Ã O   M Ó V E L
 R C M - 2     TELEMAR - RJ
* 0 31  21   550-2253
* 0 31  21   518-3558
*  kleber@telemar-rj.com.br

    

> ----- Mensagem original -----
> De:		James Yu [SMTP:james.yu@neustar.com]
> Enviada em:		Sexta-feira, 3 de Novembro de 2000 17:30
> Para:		'drwalker@ss8networks.com'
> Cc:		'iptel@lists.bell-labs.com'
> Assunto:		[iptel] draft-walker-iptel-trip-tns-00.txt
> 
> Dave,
> 
> In your draft, you proposed to add an attribute to the existing "routing
> number (I assume that it is what we agreed through previous discussions)"
> address family instead of a new address family in TRIP for the "transit
> network selection."  Your reason was that this "transit network selection"
> must be associated with the E.164 number because the receiving carrier may
> not be able to terminate the call to an E.164 number (e.g., only handle IP
> devices). 
> 
> IMHO we need a new address family in TRIP for the "transit network
> selection" because it contains distinctive routing information.  If a call
> is to be routed to a particular carrier (identified by the "transit
> network
> selection") to handle a call to a called party address, which can be an
> E.164 number or something else  (e.g., called party's E.164 number or sip
> URL), the call should be passed to that carrier regardless of the callled
> party's address type.  How that carrier uses the called party's address is
> that carrier's business.  For example, even if that carrier does not
> terminate the E.164 number directly, it can route the call to the PSTN or
> perform an ENUM query to retrieve URLs and others for that E.164 number.
> Therefore, if a switch has the "transit network selection," it should
> route
> the call using it regardless of the called party's address or routing
> number.  So the suggestion is to use a new address family for "transit
> network selection."   We'll have a distinctive address family that make
> the
> TRIP information exchange much easier and the TRIP routing simpler and
> straightforward.
> 
> In draft-yu-tel-url-np-00, I proposed two extensions to the "tel" URL to
> support number portability, "rn" and "npdi".  "rn" carries the routing
> number, and "npdi" is to indicate whether number portability database dip
> has been performed.  I'm revising that I-D to support 800 service.  One
> new
> parameter for 800 support is the "cic" or Carrier Identification Code that
> identifies the carrier and is equivalent to the "transit network
> selection"
> (at least in the U.S.).   That same parameter can be used to carry the
> "transit network selection" if it needs to be carried in the SIP message.
> The "cic" or "transit network selection"  can be received in the incoming
> ISUP or SIP message or resulted from a service trigger such as 800 number
> translation.
> 
> I have an example where a tel or SIP URL contains the telephone number,
> routing number (e.g., rn) and cic.  The example is
> 
>   tel:+1-202-533-1234;rn=+1-202-544-0000;cic=+1-5678     or
>   sip:+1-202-533-1234;rn=+1-202-544-0000;cic=+1-5678@abc.com
> 
> Although the example represents a rare case, it is used to show how call
> routing can be done when the three numbers/addresses are all present. The
> procedure would be: 
> 
> - When all three numbers/addresses are present, "cic" is used first until
> the signaling message reaches the carrier identified by the "cic" and that
> carrier needs to remove the cic.  
> 
> - If only "rn" and telephone number are present, "rn" is used.  
> 
> - If only the telephone number is available, it is used as the "routing
> number" to route (check against the TRIP "routing number" address family
> table).  Hopefully, somewhere down the road, a switch/server will perform
> a
> NP dip to get the "rn" in the NP environment.
>   
> The first step requires a new address family for the "transit network
> selection" or "carrier ID code."  The second and third steps uses the
> existing "routing number" address family.
> 
> For "cic" to appear in a sip URL that does not contain a telephone number
> (e.g., sip:UserA@abc.com), a new parameter may need to be added.
> 
> James Yu
> Principal Technical Industry Liaison
> NeuStar Inc.
> 1120 Vermont Avenue, NW,
> Suite 550
> Washington, D.C. 20005
> USA
> +1-202-533-2814 (B)
> +1-202-533-2976 (Fax)
> james.yu@neustar.com
> http://www.neustar.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 Nov  6 14:48:02 2000
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 OAA06622
	for <iptel-archive@odin.ietf.org>; Mon, 6 Nov 2000 14:48:01 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7799744338; Mon,  6 Nov 2000 13:48:02 -0500 (EST)
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 2372444337; Mon,  6 Nov 2000 10:57:07 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA13229;
	Mon, 6 Nov 2000 11:56:59 -0500 (EST)
Message-ID: <3A06E2DC.E2EBE99D@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com, IPTEL@lists.bell-labs.com, tccc@ieee.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [IPTEL] CFP: 2nd IP Telephony Workshop - Deadline 11/27/00
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 06 Nov 2000 11:57:00 -0500
Content-Transfer-Encoding: 7bit

                               Call for Papers

                         2nd IP Telephony Workshop

            April 2-3, 2001 - Columbia University, New York City
                 http://www.fokus.gmd.de/events/iptel2001/


Objectives
----------
Internet telephony is rapidly evolving from research to design
and deployment. The objectives of the IP Telephony Workshop are
to bring together researchers, developers, vendors and service
providers active in this area and stimulate discussion on
innovation, research, implementation, deployment experiences and
future directions.

Scope & Topics
--------------
Original technical articles related to IP telephony are solicited.
Only papers with significant technical content, not "white papers"
or tutorials, will be considered for publication:

     - Research papers (unique ideas, novel algorithms,
       architectures, measurements, theoretical and/or analytical
       contributions)
     - Surveys, state-of-the-art studies, technology comparisons
     - Implementation and deployment reports
     - Standardization reports

Particular areas of interest include, but are not limited to, the
following:

     - Integration with Internet services (e.g., web, instant
       messaging, games)
     - Added-value services (e.g., call centers, conferencing)
     - Mobility and 3rd generation wireless
     - Authentication, authorization, accounting, charging,
       settlement
     - QoS support
     - Security (e.g., privacy, authentication, certification
       authorities, firewall traversal)
     - Call signaling & processing
     - Feature creation
     - Supporting services (e.g., call routing, lookup services)
     - Audio & video encoding and transmission
     - Management and provisioning
     - Interworking with the PSTN
     - Design and deployment considerations (e.g., performance,
       scalability, reliability)

Important Dates
---------------
Full paper due                November 27th, 2000
Notification of acceptance    January 12th, 2001
Final version due             January 31st, 2001
Program published and         February 5th, 2001
registration opens
Workshop                      April 2nd-3rd, 2001

Submission Instructions
-----------------------
Authors are invited to submit full papers written in English
before November 27th, 2000. The submissions will be reviewed, and
accepted papers will be included in the program. Notifications of
acceptance will be sent out on January 12th, 2000. Deadline for
submission of camera-ready copies is January 31st, 2001. Authors
of accepted papers will need to sign a Copyright Transfer Form and
submit a Netbib entry.

Papers must be submitted electronically using the Web site at 
          http://www.cs.columbia.edu/iptel
Submissions must be in PDF or Postscript; any other documents 
cannot be accepted. Postscript papers must use only standard
PostScript fonts: Times Roman, Courier, Symbol, and Helvetica.  
Papers must be formatted according to the IEEE Transactions format
except for the font size, which MUST be 11pt. Templates are
available at the Web site
          http://www.fokus.gmd.de/events/iptel2001/cfp/
Because of the size limitation on the final manuscript, and to
ensure that the reviewed paper and the final version have a
similar size, papers with more than 11 pages cannot be reviewed.
Submissions must include: title, authors, affiliation, abstract,
list of keywords, and contact information. One of the authors of
each accepted paper must present the paper at iptel'2001.

Contact Address
---------------
Please, send all your inquiries regarding iptel2001 to
               iptel2001@egroups.com.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Nov  6 16:24:59 2000
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 QAA03745
	for <iptel-archive@odin.ietf.org>; Mon, 6 Nov 2000 16:24:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2207E44339; Mon,  6 Nov 2000 15:25:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mgw-dax2.ext.nokia.com (unknown [63.78.179.217])
	by lists.bell-labs.com (Postfix) with ESMTP id 3027A44339
	for <iptel@lists.bell-labs.com>; Mon,  6 Nov 2000 15:24:20 -0500 (EST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eA6LOT628798
	for <iptel@lists.bell-labs.com>; Mon, 6 Nov 2000 15:24:30 -0600 (CST)
Received: from daebh02nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tac12f2554fb6f9fffd@davir02nok.americas.nokia.com> for <iptel@lists.bell-labs.com>;
 Mon, 6 Nov 2000 15:24:13 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <WF5Q0BTZ>; Mon, 6 Nov 2000 15:24:13 -0600
Message-ID: <E39024226822D311BC880008C77318A1AB764B@oteis01nok>
From: Cliff.Harris@nokia.com
To: iptel@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] CPL-03 Comments and Questions
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 6 Nov 2000 15:16:26 -0600

A few miscellaneous comments and questions on draft-ietf-iptel-cpl-03:

In Figures 2, 19, and 29, why doesn't the "location" node in the "voicemail"
subaction have a clear="yes" attribute? Without it, won't there often be two
locations in the location set when "redirect" is invoked?

Section 5.1.1: This section makes it sound like visual separators are
stripped from the tel subfield for tel URLs but not for sip URLs. Is that
the intention? 

Section 6: I don't suppose you'll want to be adding any new features, but
here is one that I think would fit in quite well: the ability to add a
location by modifying an address. Specifically, given an address in a
particular domain, create a new location which is the same address in a
different domain. For numeric phone numbers, this means stripping a prefix
and adding a new prefix.

Section 6.1: Should a default priority be defined?

Section 6.2: How does the source URL work? Is HTTP used to retrieve the
location URL from the source URL? How does the source URL get the
information that it needs to determine the location URL (does the CPL script
pass the addresses to the source URL)?

Section 6.3: "[Location removal] is primarily useful following a lookup
node": Could you provide an example of how this works?

Section 8.1.1, item (3): Why would the SIP From header of an incoming
message be used as the basis of the Reply-To URI?

Section 9: Should it say whether subaction names are case-sensitive?

Figure 29: Uses "address contains", but according to figure 4, "contains"
can only be used with the "display" subfield. Also, this script doesn't take
care of the "failure" case.

- Cliff Harris

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Nov  6 23:40:58 2000
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 XAA13832
	for <iptel-archive@odin.ietf.org>; Mon, 6 Nov 2000 23:40:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CEB304433A; Mon,  6 Nov 2000 22:41:02 -0500 (EST)
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 DBF5D44337
	for <iptel@lists.bell-labs.com>; Mon,  6 Nov 2000 22:40:36 -0500 (EST)
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 XAA09588;
	Mon, 6 Nov 2000 23:42:37 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <4WS2YP3Q>; Mon, 6 Nov 2000 23:38:57 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF4C3BFD@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Cliff.Harris@nokia.com'" <Cliff.Harris@nokia.com>,
        iptel@lists.bell-labs.com
Subject: RE: [IPTEL] CPL-03 Comments and Questions
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 6 Nov 2000 23:38:50 -0500



 

> -----Original Message-----
> From: Cliff.Harris@nokia.com [mailto:Cliff.Harris@nokia.com]
> Sent: Monday, November 06, 2000 4:16 PM
> To: iptel@lists.bell-labs.com
> Subject: [IPTEL] CPL-03 Comments and Questions
> 
> 
> A few miscellaneous comments and questions on draft-ietf-iptel-cpl-03:
> 
> In Figures 2, 19, and 29, why doesn't the "location" node in 
> the "voicemail"
> subaction have a clear="yes" attribute? Without it, won't 
> there often be two
> locations in the location set when "redirect" is invoked?

No. From 7.1:

   Once a proxy action completes, if control is passed on to other
   actions, all locations which have been used are cleared from the
   location set. That is, the location set is emptied of proxyable
   locations if the ordering was parallel or sequential; the highest-
   priority item in the set is removed from the set if ordering was
   first-only.  (In all cases, non-proxyable locations such as "http"
   URIs remain.)  In the case of a redirection output, the new addresses
   to which the call was redirected are then added to the location set.




> 
> Section 5.1.1: This section makes it sound like visual separators are
> stripped from the tel subfield for tel URLs but not for sip 
> URLs. Is that
> the intention? 

No. Separators should be stripped from sip URLs as well. Good catch.


> 
> Section 6: I don't suppose you'll want to be adding any new 
> features, but
> here is one that I think would fit in quite well: the ability to add a
> location by modifying an address. Specifically, given an address in a
> particular domain, create a new location which is the same 
> address in a
> different domain. For numeric phone numbers, this means 
> stripping a prefix
> and adding a new prefix.

Remember the application space here - we are talking about scripts to
describe primarily end user customized/described features.
Modification/stripping of prefixes in phone numbers is very useful, but
primarily to guide system level routing in a proxy, for which CPL is not a
good match. 


> 
> Section 6.1: Should a default priority be defined?

Yes. I believe the default is 1.0.

> 
> Section 6.2: How does the source URL work? Is HTTP used to 
> retrieve the
> location URL from the source URL?

Yes.

> How does the source URL get the
> information that it needs to determine the location URL (does 
> the CPL script
> pass the addresses to the source URL)?

Right now, there is an assumption that the source URL points to static
content that contains the location URL. Thus:

<lookup source="http://www.foo.com/mylocation.txt">

where mylocation.txt contains:

sip:jdrosen@dynamicsoft.com

In reality, thats far less useful that having a cgi script or servlet on the
web server automatically generate this URL as a result of the http query.
Doing that effectively is going to require the servlet to have additional
information about the incoming call, such as the caller, called party,
request URI, and Call-ID. Is that what you mean?

In any case, I'd suggest we update the text here to indicate that the CPL
server append some query strings to the HTTP request containing these
parameters. Thus, in the example above, the actual HTTP request would be:

GET
http://www.foo.com/mlylocation.txt?Request-URI=sip:user@host&From=sip:caller
@u.edu&Call-ID=039843809aijsd0a8shfd@1.2.3.4&To=sip:user@host HTTP/1.1

Sound reasonable?

> 
> Section 6.3: "[Location removal] is primarily useful 
> following a lookup
> node": Could you provide an example of how this works?
> 
> Section 8.1.1, item (3): Why would the SIP From header of an incoming
> message be used as the basis of the Reply-To URI?

Because the point is to be able to get back to the caller. You want to be
able to reply to the email that comes, and it gets sent to the person who
called you.


> 
> Section 9: Should it say whether subaction names are case-sensitive?
>
> Figure 29: Uses "address contains", but according to figure 
> 4, "contains"
> can only be used with the "display" subfield. Also, this 
> script doesn't take
> care of the "failure" case.
> 
> - Cliff Harris
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 

---
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  Tue Nov  7 10:32:25 2000
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 KAA27153
	for <iptel-archive@odin.ietf.org>; Tue, 7 Nov 2000 10:32:25 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C1EDD44370; Tue,  7 Nov 2000 09:31:01 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mgw-dax2.ext.nokia.com (unknown [63.78.179.217])
	by lists.bell-labs.com (Postfix) with ESMTP id E348D44337
	for <iptel@lists.bell-labs.com>; Tue,  7 Nov 2000 09:30:06 -0500 (EST)
Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eA7FUD623843
	for <iptel@lists.bell-labs.com>; Tue, 7 Nov 2000 09:30:13 -0600 (CST)
Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tac12f2564fbadc0097@davir03nok.americas.nokia.com>;
 Tue, 7 Nov 2000 09:29:56 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <WF5P50Z5>; Tue, 7 Nov 2000 09:25:57 -0600
Message-ID: <E39024226822D311BC880008C77318A1AB764E@oteis01nok>
From: Cliff.Harris@nokia.com
To: jdrosen@dynamicsoft.com, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] CPL-03 Comments and Questions
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 7 Nov 2000 09:22:10 -0600


> -----Original Message-----
> From: EXT Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Monday, November 06, 2000 11:39 PM
> To: 'Cliff.Harris@nokia.com'; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] CPL-03 Comments and Questions
> 
> 
> > -----Original Message-----
> > From: Cliff.Harris@nokia.com [mailto:Cliff.Harris@nokia.com]
> > Sent: Monday, November 06, 2000 4:16 PM
> > To: iptel@lists.bell-labs.com
> > Subject: [IPTEL] CPL-03 Comments and Questions
> > 
[snipped]
> > 
> > Section 6: I don't suppose you'll want to be adding any new 
> > features, but
> > here is one that I think would fit in quite well: the 
> > ability to add a
> > location by modifying an address. Specifically, given an 
> > address in a
> > particular domain, create a new location which is the same 
> > address in a
> > different domain. For numeric phone numbers, this means 
> > stripping a prefix
> > and adding a new prefix.
> 
> Remember the application space here - we are talking about scripts to
> describe primarily end user customized/described features.
> Modification/stripping of prefixes in phone numbers is very 
> useful, but
> primarily to guide system level routing in a proxy, for which 
> CPL is not a
> good match. 

RFC 2824 talks about administrative scripts (sections 7.2 and 9.2). They
seem like a good idea; I hadn't realized that this idea had been downgraded.
Why wouldn't CPL be a good match for guiding system-level routing?

[ snipped ]
> 
> > 
> > Section 6.2: How does the source URL work? Is HTTP used to 
> > retrieve the
> > location URL from the source URL?
> 
> Yes.
> 
> > How does the source URL get the
> > information that it needs to determine the location URL (does 
> > the CPL script
> > pass the addresses to the source URL)?
> 
> Right now, there is an assumption that the source URL points to static
> content that contains the location URL. Thus:
> 
> <lookup source="http://www.foo.com/mylocation.txt">
> 
> where mylocation.txt contains:
> 
> sip:jdrosen@dynamicsoft.com

Figure 26 in cpl-03 has the following: 
<lookup source="http://www.example.com/cgi-bin/locate.cgi?user=jones"
               timeout="8">

> 
> In reality, thats far less useful that having a cgi script or 
> servlet on the
> web server automatically generate this URL as a result of the 
> http query.
> Doing that effectively is going to require the servlet to 
> have additional
> information about the incoming call, such as the caller, called party,
> request URI, and Call-ID. Is that what you mean?

Yes, that is exactly what I mean.

> 
> In any case, I'd suggest we update the text here to indicate 
> that the CPL
> server append some query strings to the HTTP request containing these
> parameters. Thus, in the example above, the actual HTTP 
> request would be:
> 
> GET
> http://www.foo.com/mlylocation.txt?Request-URI=sip:user@host&F
> rom=sip:caller
> @u.edu&Call-ID=039843809aijsd0a8shfd@1.2.3.4&To=sip:user@host HTTP/1.1
> 
> Sound reasonable?

Sounds good. However, in your example you've used SIP fields rather than CPL
fields. Would Call ID really be useful? 

So the CPL server would always automatically add the parameters to the
source URL. In the example in Figure 26, there is already one parameter; how
would that be handled?

> > 
> > Section 6.3: "[Location removal] is primarily useful 
> > following a lookup
> > node": Could you provide an example of how this works?
[snipped]
> > 
> > Section 9: Should it say whether subaction names are case-sensitive?
> >
> > Figure 29: Uses "address contains", but according to figure 
> > 4, "contains"
> > can only be used with the "display" subfield. Also, this 
> > script doesn't take
> > care of the "failure" case.

BTW, I'm not sure why the restriction was placed on the use of "contains";
the script in Figure 29 looks quite reasonable to me.

> > 
> > - Cliff Harris
> ---
> 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  Tue Nov  7 18:10:00 2000
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 SAA27625
	for <iptel-archive@odin.ietf.org>; Tue, 7 Nov 2000 18:09:59 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 08AAD4433C; Tue,  7 Nov 2000 17:10:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mgw-dax2.ext.nokia.com (unknown [63.78.179.217])
	by lists.bell-labs.com (Postfix) with ESMTP id CEE7D4433B
	for <iptel@lists.bell-labs.com>; Tue,  7 Nov 2000 17:09:45 -0500 (EST)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eA7N9t601048
	for <iptel@lists.bell-labs.com>; Tue, 7 Nov 2000 17:09:55 -0600 (CST)
Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tac12f2544fbc80dfc2@davir01nok.americas.nokia.com> for <iptel@lists.bell-labs.com>;
 Tue, 7 Nov 2000 17:09:38 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <WF5Q0XLJ>; Tue, 7 Nov 2000 17:09:38 -0600
Message-ID: <E39024226822D311BC880008C77318A1AB764F@oteis01nok>
From: Cliff.Harris@nokia.com
To: iptel@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] CPL-03 Terminology
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 7 Nov 2000 17:01:50 -0600

I realize this may be asking too much too late (and besides, I'm pretty sure
_I've_ got it all figured out), but I wonder if some of the terminology in
draft-ietf-iptel-cpl-03 could be clarified.

The most confusing term for me was "output". This has two different
meanings: (1) it can mean a tag that is not considered a node; i.e., a
condition within a switch or the result of an action; or (2) it can mean the
next node to be processed. I think the first meaning is the normal one;
however, section 2.2 seems to be using the second meaning (maybe the term
"next node" could be used instead), and the introduction to section 5 seems
to use both meanings. The syntax figures (Figure 4, for example) are also
confusing in this regard: no outputs (second sense) are listed for an output
(first sense), but outputs (second sense) are given for _nodes_ that have no
outputs (first sense). I think this could be cleaned up by listing outputs
only for nodes that really have outputs in the first sense (switches,
proxy). For nodes with no outputs, and for outputs too, a "next node" could
be listed (either "any node" or "none allowed").

The second most confusing term was "action". This can mean (1) "top-level
action" (or "call processing action"[?]) or (2) a node that performs an
action (including "location"[?], but excluding switches). I'd suggest
reserving the word "action" for the second meaning. For the first meaning,
use the complete term (or to clarify further, perhaps replace "top-level
action" with "top-level action tree" or "top-level procedure" and replace
"call processing action" with "action tree" or "procedure").

I think "condition" is also used in two ways: (1) "switch", in section 2.2,
and (2)switch outputs ("address is" or "address contains"), in section 5.
This word is used much less, so it is less confusing but also easier to fix.

I'd also suggest eliminating unnecessary synonyms:
- call processing action / processing action 
- top-level action / top-level processing action / action
- ancillary information / meta-information
- non-signalling actions / other actions

Thanks,

Cliff Harris

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov  8 16:00:36 2000
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 QAA01934
	for <iptel-archive@odin.ietf.org>; Wed, 8 Nov 2000 16:00:36 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7CAC144361; Wed,  8 Nov 2000 14:51:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102])
	by lists.bell-labs.com (Postfix) with ESMTP id 38BB344337
	for <iptel@lists.bell-labs.com>; Tue,  7 Nov 2000 00:12:24 -0500 (EST)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate4.mot.com (motgate4 2.1) with ESMTP id XAA26257 for <iptel@lists.bell-labs.com>; Mon, 6 Nov 2000 23:12:17 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id XAA06096 for <iptel@lists.bell-labs.com>; Mon, 6 Nov 2000 23:12:15 -0700 (MST)]
Received: from beast.arc.corp.mot.com (beast.arc.corp.mot.com [217.1.10.11])
	by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id eA76BYS23512
	for <iptel@lists.bell-labs.com>; Tue, 7 Nov 2000 17:11:34 +1100 (EST)
Received: (from kwchin@localhost)
	by beast.arc.corp.mot.com (8.10.2/8.10.2) id eA76BYd15110
	for iptel@lists.bell-labs.com; Tue, 7 Nov 2000 17:11:34 +1100
From: Kwan-Wu Chin <kwchin@arc.corp.mot.com>
Message-Id: <200011070611.eA76BYd15110@beast.arc.corp.mot.com>
To: iptel@lists.bell-labs.com
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [IPTEL] TENURE TRACKs AVAILABLE AT UTA
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 7 Nov 2000 17:11:34 +1100 (EST)
Content-Transfer-Encoding: 7bit

                         FACULTY POSITIONS AVAILABLE
                  ===========================================
                  COMPUTER SCIENCE AND ENGINEERING DEPARTMENT
                      THE UNIVERSITY OF TEXAS AT ARLINGTON
                  ============================================

The University of Texas at Arlington (UTA), Computer Science and
Engineering (CSE) Department - CSE@UTA invites applications for 
multiple tenure-track faculty positions at assistant or associate 
professor levels.  Applicants with expertise in the following areas 
are preferred: software engineering; systems including architecture, 
distributed and high-performance computing; networks and telecommunications; 
database and data mining; and applied theory.  UTA, part of The University 
of Texas System, is the heart of the rapidly growing Dallas/Fort Worth area, 
one of the nation's largest high-technology regions, with a flourishing 
industrial base and excellent opportunities for industry/university collaboration.

We at CSE@UTA are committed to excellence in research, teaching, and
community service.  We recently kicked off a "Top 25 Initiative" with
the goal of reaching a national top 25 ranking.  The initiative is strongly
supported by all CSE@UTA stakeholders including the UTA administration,
our students and alumni, and our industry partners.  The highlights of the
Top 25 Initiative include significant increase in tenure track faculty
positions and PhD students; significant increase in research funds; and
establishment of endowed student fellowships, endowed faculty chairs, and
industry-sponsored laboratories.

Applicants for an assistant professor position must have an earned
doctorate in computer science, computer engineering, or closely related fields 
and a commitment to teaching and scholarly research.  Applicants for an
associate professor position must have demonstrated an excellent record of
professional accomplishments in their field of expertise.  The faculty
openings are anticipated for September 2001.  Screening of applications
will begin immediately and will continue until all positions are filled.
Interested persons should send a resume and reference letters to

Chair of Search Committee
Department of Computer Science and Engineering
P.O. Box 19015
Arlington, TX  76019-0015

Phone: 817-272-3605
FAX: 817-272-3070
Email: search@cse.uta.edu
http://www-cse.uta.edu

The University of Texas at Arlington is an Equal Opportunity/Affirmative
Action Employer.

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Nov  9 10:23:01 2000
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 KAA08307
	for <iptel-archive@odin.ietf.org>; Thu, 9 Nov 2000 10:23:00 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7411944351; Thu,  9 Nov 2000 09:23:01 -0500 (EST)
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 31BD144343
	for <iptel@lists.bell-labs.com>; Thu,  9 Nov 2000 09:22:22 -0500 (EST)
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 KAA25689;
	Thu, 9 Nov 2000 10:24:33 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <4WS2YS0Q>; Thu, 9 Nov 2000 10:20:47 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF4C3C3E@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Cliff.Harris@nokia.com'" <Cliff.Harris@nokia.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        iptel@lists.bell-labs.com
Subject: RE: [IPTEL] CPL-03 Comments and Questions
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 9 Nov 2000 10:20:46 -0500



 

> -----Original Message-----
> From: Cliff.Harris@nokia.com [mailto:Cliff.Harris@nokia.com]
> Sent: Tuesday, November 07, 2000 10:22 AM
> To: jdrosen@dynamicsoft.com; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] CPL-03 Comments and Questions
> 
> 
> 
> > -----Original Message-----
> > From: EXT Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > Sent: Monday, November 06, 2000 11:39 PM
> > To: 'Cliff.Harris@nokia.com'; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] CPL-03 Comments and Questions
> > 
> > 
> > > -----Original Message-----
> > > From: Cliff.Harris@nokia.com [mailto:Cliff.Harris@nokia.com]
> > > Sent: Monday, November 06, 2000 4:16 PM
> > > To: iptel@lists.bell-labs.com
> > > Subject: [IPTEL] CPL-03 Comments and Questions
> > > 
> [snipped]
> > > 
> > > Section 6: I don't suppose you'll want to be adding any new 
> > > features, but
> > > here is one that I think would fit in quite well: the 
> > > ability to add a
> > > location by modifying an address. Specifically, given an 
> > > address in a
> > > particular domain, create a new location which is the same 
> > > address in a
> > > different domain. For numeric phone numbers, this means 
> > > stripping a prefix
> > > and adding a new prefix.
> > 
> > Remember the application space here - we are talking about 
> scripts to
> > describe primarily end user customized/described features.
> > Modification/stripping of prefixes in phone numbers is very 
> > useful, but
> > primarily to guide system level routing in a proxy, for which 
> > CPL is not a
> > good match. 
> 
> RFC 2824 talks about administrative scripts (sections 7.2 and 
> 9.2). They
> seem like a good idea; I hadn't realized that this idea had 
> been downgraded.
> Why wouldn't CPL be a good match for guiding system-level routing?

Nothing stops administators from writing CPLs. But, its a different problem
space, and URI manipulations are just one of the issues. 

> > In any case, I'd suggest we update the text here to indicate 
> > that the CPL
> > server append some query strings to the HTTP request 
> containing these
> > parameters. Thus, in the example above, the actual HTTP 
> > request would be:
> > 
> > GET
> > http://www.foo.com/mlylocation.txt?Request-URI=sip:user@host&F
> > rom=sip:caller
> > 
> @u.edu&Call-ID=039843809aijsd0a8shfd@1.2.3.4&To=sip:user@host HTTP/1.1
> > 
> > Sound reasonable?
> 
> Sounds good. However, in your example you've used SIP fields 
> rather than CPL
> fields. Would Call ID really be useful? 

You are correct - they should be the generic versions, not the SIP versions.

Is Call-ID useful? Most definitely. This would allow me to write an apps
that require complex, call-stateful operations.

I have come to realize recently the tremendous power of the ability to fetch
CPL scripts from a remote server using http. It allows me to write fairly
complex applications through CGI or servlet scripts on the remote http
server, with the results of those scripts being the primitive call control
operations that the server should execute, in the form of CPLs. 

This model is identical to the model for VoiceXML, whereby a voiceXML
interpreter can fetch VoiceXML scripts from a web server. You can create
very dynamic IVR apps by dynamically generating the voiceXML as a result of
the HTTP queries. This allows for a very appealing model of having
applicating execution providers that run the scripts, and these scripts are
generated by their customers, who are application providers that run the web
servers that receive the http queries. I know a few companies with this
model in the VoiceXML space.

As an example, consider a really customized call screening app, that depends
on checking the identity of the caller amongst a set of known criminals
stored in some globally accessible data repository (lets assume its acessed
using HTTP). If the person is a criminal, the call is rejected, else its
proxied to wherever I am write now. CPL has no support for complex database
queries like that. However, what I can do is fetch the CPL when the INVITE
comes, using http. The web server executes a servlet that checks this
database, and if they are on the list, generates this CPL:

<cpl>
  <reject/>
</cpl>

otherwise, generates this one:

<cpl>
  <lookup source="registration">
    <success>
      <proxy/>
    </success>
  </lookup>
</cpl>

Very nice and easy. 

Now, I've also recently come to realize that what is missing from this model
is the ability to, at some point in the execution of a CPL script, go and
fetch another one and continue from there. This is needed when more complex
processing is needed after the results of a call control operation. Consider
an application whereby I do a call forward, and if the person is busy, I
update a web page with a call log, and then forward the response upstream.
This application requires a complex piece of code to be invoked after the
<busy> output of the proxy, to update this web page. So, what I would
ideally like is that the initial INVITE fetches the following CPL:

<cpl>
  <location url="sip:jdrosen@dynamicsoft.com">
    <proxy>
      <busy>
        <fetch url="http://www.dynamicsoft.com/jdrosen/myscript.pl"/>
      </busy>
    </proxy>
  </location>
</cpl>

Now, if the call returns busy, the CPL interpreter would fetch that URL,
which would return another script, which the CPL server continues processing
as if it were in the original CPL instead of the "fetch" tag.

I think its probably too late to add this kind of support to CPL; its
something I'd be interested in pursuing in an extension once CPL goes to
RFC.

Comments welcome.


> 
> So the CPL server would always automatically add the parameters to the
> source URL. In the example in Figure 26, there is already one 
> parameter; how
> would that be handled?

Parameters already there would probably not be replaced.

-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  Fri Nov 10 17:05:06 2000
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 RAA25126
	for <iptel-archive@odin.ietf.org>; Fri, 10 Nov 2000 17:05:05 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9951D44337; Fri, 10 Nov 2000 16:05:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from www.prettywoman.co.kr (unknown [211.50.137.80])
	by lists.bell-labs.com (Postfix) with ESMTP id A616B44336
	for <iptel@lists.bell-labs.com>; Fri, 10 Nov 2000 13:28:49 -0500 (EST)
Received: from e-net.co.kr (cmci012p06.toll.micron.net [206.80.120.177])
	by www.prettywoman.co.kr (8.9.3/8.9.3) with SMTP id EAA26244;
	Sat, 11 Nov 2000 04:25:24 +0900
Content-Type: text/plain;
	 charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Message-Id: <72r27cp1.s86rty5a3e4@e-net.co.kr>
From: Craig@cet.ac.il
To: Thompson@essenet.it
Subject: [IPTEL] Information You Requested
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 10 Nov 2000 14:24:50 -0500
Content-Transfer-Encoding: 8BIT




You were recently referred to me as someone who was
ready for a CHANGE, a financial breakthrough, so I'll
get right to the point.

I am the one that can help you make $125,000 plus this
year from HOME with your computer and phone. 
This is Not MLM and it IS very REAL.

Are you Serious about making $2000 plus per week 
starting Right Away with a SIMPLE system 
where customers are contacting you and 
you do absolutely ZERO selling?

Can you follow simple step-by-step instructions and put
forth the effort to make this a reality for yourself starting
today? If your answer is YES, then we need to talk.

I have few positions available on my team and its in my best
interest to train you for success.  In fact, I'm so sure that
I can do so, I'm willing to put my money where my mouth is!
Upon accepting you as a member on my team, I will provide 
you with complete Professional Training and Advertising  
Assistance to put you immediately on the road to success.

No experience necessary.... However you must have 
two qualities: moderate people skills and a serious desire 
for a personal and financial change.

Take a moment to take the next step by calling me at my 
Home Office and I will get you the details.


1-800-432-9867
24 Hrs/ 7 Days


Prosperous Regards!
Craig


"Profits are better than wages. Wages make you a living;
Profits make you a fortune"
					- Jim Rohn
					
To be removed send email to pmaimps@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 Nov 13 14:46:03 2000
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 OAA23612
	for <iptel-archive@odin.ietf.org>; Mon, 13 Nov 2000 14:46:03 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C9C5F4437B; Mon, 13 Nov 2000 13:46:01 -0500 (EST)
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 22A6C44336
	for <iptel@lists.bell-labs.com>; Mon, 13 Nov 2000 13:45:31 -0500 (EST)
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 OAA17719;
	Mon, 13 Nov 2000 14:45:22 -0500 (EST)
Received: (from lennox@localhost)
	by conrail.cs.columbia.edu (8.9.3/8.9.1) id OAA39165;
	Mon, 13 Nov 2000 14:45:22 -0500 (EST)
	(envelope-from lennox)
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14864.17617.466464.701853@conrail.cs.columbia.edu>
To: Cliff.Harris@nokia.com
Cc: iptel@lists.bell-labs.com
Subject: Re: [IPTEL] CPL-03 Comments and Questions
In-Reply-To: <E39024226822D311BC880008C77318A1AB764B@oteis01nok>
References: <E39024226822D311BC880008C77318A1AB764B@oteis01nok>
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 13 Nov 2000 14:45:21 -0500 (EST)
Content-Transfer-Encoding: 7bit

On Monday, November 6 2000, "Cliff.Harris@nokia.com" wrote to "iptel@lists.bell-labs.com" saying:

> A few miscellaneous comments and questions on draft-ietf-iptel-cpl-03:
> 
> In Figures 2, 19, and 29, why doesn't the "location" node in the "voicemail"
> subaction have a clear="yes" attribute? Without it, won't there often be two
> locations in the location set when "redirect" is invoked?

JR addressed this; the location's been removed by that point.

> Section 5.1.1: This section makes it sound like visual separators are
> stripped from the tel subfield for tel URLs but not for sip URLs. Is that
> the intention? 

Nope; I corrected this.

> Section 6: I don't suppose you'll want to be adding any new features, but
> here is one that I think would fit in quite well: the ability to add a
> location by modifying an address. Specifically, given an address in a
> particular domain, create a new location which is the same address in a
> different domain. For numeric phone numbers, this means stripping a prefix
> and adding a new prefix.

This seems like a fine extension, but I don't think it'd belong in the base
spec even if we weren't at last call.

> Section 6.1: Should a default priority be defined?

Yes; 1.0.  (I made this only SHOULD strength, though, since the server may
want to impose some policy here or something).

> Section 6.2: How does the source URL work? Is HTTP used to retrieve the
> location URL from the source URL? How does the source URL get the
> information that it needs to determine the location URL (does the CPL script
> pass the addresses to the source URL)?

I'll address this in follow-up to the subsequent discussions.

> Section 6.3: "[Location removal] is primarily useful following a lookup
> node": Could you provide an example of how this works?

There's an example of this in Section 13.8 (Figure 24).  I've added a
forward reference.

> Section 8.1.1, item (3): Why would the SIP From header of an incoming
> message be used as the basis of the Reply-To URI?

On the assumption that sip addresses and e-mail addresses often correspond.
It's a guess, but it seems more likely to be useful than the address of the
SIP server.

> Section 9: Should it say whether subaction names are case-sensitive?

Yes, it should (and they are).  Added.

> Figure 29: Uses "address contains", but according to figure 4, "contains"
> can only be used with the "display" subfield. Also, this script doesn't take
> care of the "failure" case.

For the first point, fixed to "is".  For the second point, I added a note to
the discussion in section 13.11.  (Mind you, this discussion has gotten
largely lost in the text version; I think nroff may not be handling my
figures correctly.)

Thanks for your comments!

-- 
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  Mon Nov 13 14:55:14 2000
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 OAA26689
	for <iptel-archive@odin.ietf.org>; Mon, 13 Nov 2000 14:55:13 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A05294438F; Mon, 13 Nov 2000 13:55:02 -0500 (EST)
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 042AD44338
	for <iptel@lists.bell-labs.com>; Mon, 13 Nov 2000 13:54:09 -0500 (EST)
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 OAA18299;
	Mon, 13 Nov 2000 14:53:50 -0500 (EST)
Received: (from lennox@localhost)
	by conrail.cs.columbia.edu (8.9.3/8.9.1) id OAA39172;
	Mon, 13 Nov 2000 14:53:49 -0500 (EST)
	(envelope-from lennox)
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14864.18125.294266.349353@conrail.cs.columbia.edu>
To: Cliff.Harris@nokia.com
Cc: iptel@lists.bell-labs.com
Subject: Re: [IPTEL] CPL-03 Terminology
In-Reply-To: <E39024226822D311BC880008C77318A1AB764F@oteis01nok>
References: <E39024226822D311BC880008C77318A1AB764F@oteis01nok>
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 13 Nov 2000 14:53:49 -0500 (EST)
Content-Transfer-Encoding: 7bit

On Tuesday, November 7 2000, "Cliff.Harris@nokia.com" wrote to "iptel@lists.bell-labs.com" saying:

> I realize this may be asking too much too late (and besides, I'm pretty sure
> _I've_ got it all figured out), but I wonder if some of the terminology in
> draft-ietf-iptel-cpl-03 could be clarified.

I don't have any problem with textual clarifications at this point; that's
what last call is for.

> The most confusing term for me was "output". This has two different
> meanings: (1) it can mean a tag that is not considered a node; i.e., a
> condition within a switch or the result of an action; or (2) it can mean the
> next node to be processed. I think the first meaning is the normal one;
> however, section 2.2 seems to be using the second meaning (maybe the term
> "next node" could be used instead), and the introduction to section 5 seems
> to use both meanings. The syntax figures (Figure 4, for example) are also
> confusing in this regard: no outputs (second sense) are listed for an output
> (first sense), but outputs (second sense) are given for _nodes_ that have no
> outputs (first sense). I think this could be cleaned up by listing outputs
> only for nodes that really have outputs in the first sense (switches,
> proxy). For nodes with no outputs, and for outputs too, a "next node" could
> be listed (either "any node" or "none allowed").

This was pretty easy to fix.  I had been thinking of an "output" on a higher
level -- as a description of "how you decide what happens next" -- but on
reflection I agree this is unclear.  I standardized on your usage: an
"output" is a tag which is not a node; the next node is just that, the "next
node."  In those few cases where I needed the abstract concept, I used the
term "result".  (E.g. the <mail> tag can have only one result, so it has no
outputs, but instead directly contains the next node.)

> The second most confusing term was "action". This can mean (1) "top-level
> action" (or "call processing action"[?]) or (2) a node that performs an
> action (including "location"[?], but excluding switches). I'd suggest
> reserving the word "action" for the second meaning. For the first meaning,
> use the complete term (or to clarify further, perhaps replace "top-level
> action" with "top-level action tree" or "top-level procedure" and replace
> "call processing action" with "action tree" or "procedure").

This one is more of a problem.  While I like the term "procedure" for the
current "top-level actions" and "subactions", the tag <subaction> is already
defined.  It seems like it'd be awfully confusing to change the terminology
in the way you describe, but still call the node <subaction>.  Any thoughts
on the best way to resolve this?

> I think "condition" is also used in two ways: (1) "switch", in section 2.2,
> and (2)switch outputs ("address is" or "address contains"), in section 5.
> This word is used much less, so it is less confusing but also easier to fix.

Yes; fixed.

> I'd also suggest eliminating unnecessary synonyms:
> - call processing action / processing action 
> - top-level action / top-level processing action / action

These two are part of the "action" mess.

> - ancillary information / meta-information
> - non-signalling actions / other actions

These two were easy to fix.

Thanks for your comments!

-- 
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  Mon Nov 13 15:09:00 2000
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 PAA00353
	for <iptel-archive@odin.ietf.org>; Mon, 13 Nov 2000 15:08:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E5F684438B; Mon, 13 Nov 2000 14:09:01 -0500 (EST)
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 B80C14438A
	for <iptel@lists.bell-labs.com>; Mon, 13 Nov 2000 14:08:47 -0500 (EST)
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 PAA19401;
	Mon, 13 Nov 2000 15:08:38 -0500 (EST)
Received: (from lennox@localhost)
	by conrail.cs.columbia.edu (8.9.3/8.9.1) id PAA39192;
	Mon, 13 Nov 2000 15:08:38 -0500 (EST)
	(envelope-from lennox)
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14864.19014.146634.956417@conrail.cs.columbia.edu>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Cliff.Harris@nokia.com'" <Cliff.Harris@nokia.com>,
        iptel@lists.bell-labs.com
Subject: RE: [IPTEL] CPL-03 Comments and Questions
In-Reply-To: <B65B4F8437968F488A01A940B21982BF4C3C3E@DYN-EXCH-001.dynamicsoft.com>
References: <B65B4F8437968F488A01A940B21982BF4C3C3E@DYN-EXCH-001.dynamicsoft.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 13 Nov 2000 15:08:38 -0500 (EST)
Content-Transfer-Encoding: 7bit

On Thursday, November 9 2000, "Jonathan Rosenberg" wrote to "'Cliff.Harris@nokia.com', Jonathan Rosenberg, iptel@lists.bell-labs.com" saying:

[JR Writes:]
> > > In any case, I'd suggest we update the text here to indicate that the CPL
> > > server append some query strings to the HTTP request containing these
> > > parameters. Thus, in the example above, the actual HTTP 
> > > request would be:
> > > 
> > > GET http://www.foo.com/mlylocation.txt?Request-URI=sip:user@host&From=sip:caller@u.edu&Call-ID=039843809aijsd0a8shfd@1.2.3.4&To=sip:user@host HTTP/1.1
> > > 
> > > Sound reasonable?

[CH Writes:]
> > Sounds good. However, in your example you've used SIP fields 
> > rather than CPL fields. Would Call ID really be useful? 

[JR Writes:]
> You are correct - they should be the generic versions, not the SIP versions.
> 
> Is Call-ID useful? Most definitely. This would allow me to write an apps
> that require complex, call-stateful operations.

This seems to me like a very big change to make at this point.  The
intention of the current draft is "send a GET request containing the URI in
the location parameter, verbatim."  Changing that is a fairly big deal -- it
requires a serious chunk of thought as to exactly what parameters go into
the request.

One counter-argument is that a bit of experimentation shows that HTTP
servers (or at least Apache) seem to ignore spurious parameters in a GET
request, so in the unlikely event that anyone is using the HTTP location
lookup already, this probably wouldn't break anything.

Do you have a proposal for these headers here?  And do you think that if we
change this, we should do another WG last-call?

-- 
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  Mon Nov 13 16:32:22 2000
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 QAA00761
	for <iptel-archive@odin.ietf.org>; Mon, 13 Nov 2000 16:32:21 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D40DB4435D; Mon, 13 Nov 2000 15:31:01 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by lists.bell-labs.com (Postfix) with ESMTP id A6E6444367
	for <iptel@lists.bell-labs.com>; Mon, 13 Nov 2000 15:30:27 -0500 (EST)
Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eADLUV616805
	for <iptel@lists.bell-labs.com>; Mon, 13 Nov 2000 15:30:41 -0600 (CST)
Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tac12f2564fdb0bf507@davir03nok.americas.nokia.com>;
 Mon, 13 Nov 2000 15:30:10 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <WZ6A55M4>; Mon, 13 Nov 2000 15:30:10 -0600
Message-ID: <E39024226822D311BC880008C77318A1AB7667@oteis01nok>
From: Cliff.Harris@nokia.com
To: jdrosen@dynamicsoft.com, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] CPL-03 Comments and Questions
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 13 Nov 2000 15:22:17 -0600

This appears to be a very powerful idea.

A couple of potential drawbacks:
1. Reduced performance: scripts can't be entirely pre-parsed, since a
different fragment may come back from the Perl script every single call;
2. There could be compatibility problems; namely, the Perl script might
return a fragment using a namespace not supported by the CPL server.

In some cases, there may be simpler ways of achieving the same goal. For
example, consider the following as a way of addressing your "criminals"
example:

<lookup source="http://www.criminals.com/locate.pl" timeout=5">
  <success>
    <reject/>
  </success>
  <notfound>
    <lookup source="registration">
      <success>
        <proxy/>
      </success>
    </lookup>    
  </notfound>
</lookup>

It just uses existing CPL syntax (but it assumes that the originator's URL
will be passed to the Perl script, which passes back the originator's URL if
and only if it is the URL of a criminal).

Another possibility would be to add an action to invoke a script that
returns an arbitrary string, and to add a new string-switch field to look at
the result of the script. Then you could do something like this:

<fetch-string source="http://www.phonenumbers.com/classify.pl" timeout=5">
  <success>
    <string-switch field="script-result">
      <string contains="criminal">
        <reject/>
      </string>
      <string contains="telemarketer">
        <reject/>
      </string>
    </string-switch>
  </success>
  <notfound>
    <lookup source="registration">
      <success>
        <proxy/>
      </success>
    </lookup>    
  </notfound>
</lookup>

Another thing that might be useful is a generalized non-signalling action;
i.e., invoking a script that runs in parallel to the CPL script and that
does not return a result:

<busy>
  <spawn url="http://www.example.com/busy_counter.pl">
    <!-- The following has nothing to do with the perl script -->
    <location url="sip:myself@voicemail.com">
       <redirect/>
    </location>
  </spawn>
</busy>

- Cliff Harris

> -----Original Message-----
> From: EXT Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Thursday, November 09, 2000 10:21 AM
> To: 'Cliff.Harris@nokia.com'; Jonathan Rosenberg;
> iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] CPL-03 Comments and Questions
> 
>
. . . 
> 
> I have come to realize recently the tremendous power of the 
> ability to fetch
> CPL scripts from a remote server using http. It allows me to 
> write fairly
> complex applications through CGI or servlet scripts on the remote http
> server, with the results of those scripts being the primitive 
> call control
> operations that the server should execute, in the form of CPLs. 
> 
> This model is identical to the model for VoiceXML, whereby a voiceXML
> interpreter can fetch VoiceXML scripts from a web server. You 
> can create
> very dynamic IVR apps by dynamically generating the voiceXML 
> as a result of
> the HTTP queries. This allows for a very appealing model of having
> applicating execution providers that run the scripts, and 
> these scripts are
> generated by their customers, who are application providers 
> that run the web
> servers that receive the http queries. I know a few companies 
> with this
> model in the VoiceXML space.
> 
> As an example, consider a really customized call screening 
> app, that depends
> on checking the identity of the caller amongst a set of known 
> criminals
> stored in some globally accessible data repository (lets 
> assume its acessed
> using HTTP). If the person is a criminal, the call is 
> rejected, else its
> proxied to wherever I am write now. CPL has no support for 
> complex database
> queries like that. However, what I can do is fetch the CPL 
> when the INVITE
> comes, using http. The web server executes a servlet that checks this
> database, and if they are on the list, generates this CPL:
> 
> <cpl>
>   <reject/>
> </cpl>
> 
> otherwise, generates this one:
> 
> <cpl>
>   <lookup source="registration">
>     <success>
>       <proxy/>
>     </success>
>   </lookup>
> </cpl>
> 
> Very nice and easy. 
> 
> Now, I've also recently come to realize that what is missing 
> from this model
> is the ability to, at some point in the execution of a CPL 
> script, go and
> fetch another one and continue from there. This is needed 
> when more complex
> processing is needed after the results of a call control 
> operation. Consider
> an application whereby I do a call forward, and if the person 
> is busy, I
> update a web page with a call log, and then forward the 
> response upstream.
> This application requires a complex piece of code to be 
> invoked after the
> <busy> output of the proxy, to update this web page. So, what I would
> ideally like is that the initial INVITE fetches the following CPL:
> 
> <cpl>
>   <location url="sip:jdrosen@dynamicsoft.com">
>     <proxy>
>       <busy>
>         <fetch url="http://www.dynamicsoft.com/jdrosen/myscript.pl"/>
>       </busy>
>     </proxy>
>   </location>
> </cpl>
> 
> Now, if the call returns busy, the CPL interpreter would 
> fetch that URL,
> which would return another script, which the CPL server 
> continues processing
> as if it were in the original CPL instead of the "fetch" tag.
> 
> I think its probably too late to add this kind of support to CPL; its
> something I'd be interested in pursuing in an extension once 
> CPL goes to
> RFC.
> 
> Comments welcome.
> 
> 
> -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 Nov 13 17:15:57 2000
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 RAA14238
	for <iptel-archive@odin.ietf.org>; Mon, 13 Nov 2000 17:15:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 638384433A; Mon, 13 Nov 2000 16:16:01 -0500 (EST)
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 4B1D244339
	for <iptel@lists.bell-labs.com>; Mon, 13 Nov 2000 16:15:10 -0500 (EST)
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 RAA08630;
	Mon, 13 Nov 2000 17:17:15 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <4WS2YYFR>; Mon, 13 Nov 2000 17:13:21 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF4C3C89@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Jonathan Lennox'" <lennox@cs.columbia.edu>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Cliff.Harris@nokia.com'" <Cliff.Harris@nokia.com>,
        iptel@lists.bell-labs.com
Subject: RE: [IPTEL] CPL-03 Comments and Questions
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 13 Nov 2000 17:13:17 -0500



 

> -----Original Message-----
> From: Jonathan Lennox [mailto:lennox@cs.columbia.edu]
> Sent: Monday, November 13, 2000 3:09 PM
> To: Jonathan Rosenberg
> Cc: 'Cliff.Harris@nokia.com'; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] CPL-03 Comments and Questions
> 
> 
> On Thursday, November 9 2000, "Jonathan Rosenberg" wrote to 
> "'Cliff.Harris@nokia.com', Jonathan Rosenberg, 
> iptel@lists.bell-labs.com" saying:
> 
> [JR Writes:]
> > > > In any case, I'd suggest we update the text here to 
> indicate that the CPL
> > > > server append some query strings to the HTTP request 
> containing these
> > > > parameters. Thus, in the example above, the actual HTTP 
> > > > request would be:
> > > > 
> > > > GET 
> http://www.foo.com/mlylocation.txt?Request-URI=sip:user@host&F
> rom=sip:caller@u.edu&Call-ID=039843809aijsd0a8shfd@1.2.3.4&To=
> sip:user@host HTTP/1.1
> > > > 
> > > > Sound reasonable?
> 
> [CH Writes:]
> > > Sounds good. However, in your example you've used SIP fields 
> > > rather than CPL fields. Would Call ID really be useful? 
> 
> [JR Writes:]
> > You are correct - they should be the generic versions, not 
> the SIP versions.
> > 
> > Is Call-ID useful? Most definitely. This would allow me to 
> write an apps
> > that require complex, call-stateful operations.
> 
> This seems to me like a very big change to make at this point.  The
> intention of the current draft is "send a GET request 
> containing the URI in
> the location parameter, verbatim."  Changing that is a fairly 
> big deal -- it
> requires a serious chunk of thought as to exactly what 
> parameters go into
> the request.
> 
> One counter-argument is that a bit of experimentation shows that HTTP
> servers (or at least Apache) seem to ignore spurious 
> parameters in a GET
> request, so in the unlikely event that anyone is using the 
> HTTP location
> lookup already, this probably wouldn't break anything.
> 
> Do you have a proposal for these headers here?  And do you 
> think that if we
> change this, we should do another WG last-call?

Hmm.

My proposal is the following. We leave it as it is, and get baseline CPL out
the door. As a follow up (extension, whatever), I'm very interested in
investigating, in a general sense, applying VoiceXML style models of remote
fetching using HTTP to CPL scripts. There are lots of issues and work that
needs to be addressed. Rather than do this in an ad-hoc way now, lets devote
the proper attention to it, given people are sufficiently interested.

-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 Nov 13 18:44:02 2000
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 SAA08699
	for <iptel-archive@odin.ietf.org>; Mon, 13 Nov 2000 18:44:02 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 173F944369; Mon, 13 Nov 2000 17:44:02 -0500 (EST)
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 E0ADE4435B
	for <iptel@lists.bell-labs.com>; Mon, 13 Nov 2000 17:43:59 -0500 (EST)
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 SAA02428;
	Mon, 13 Nov 2000 18:43:51 -0500 (EST)
Received: (from lennox@localhost)
	by conrail.cs.columbia.edu (8.9.3/8.9.1) id SAA48091;
	Mon, 13 Nov 2000 18:43:51 -0500 (EST)
	(envelope-from lennox)
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14864.31926.366361.334637@conrail.cs.columbia.edu>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Cliff.Harris@nokia.com'" <Cliff.Harris@nokia.com>,
        iptel@lists.bell-labs.com
Subject: RE: [IPTEL] CPL-03 Comments and Questions
In-Reply-To: <B65B4F8437968F488A01A940B21982BF4C3C89@DYN-EXCH-001.dynamicsoft.com>
References: <B65B4F8437968F488A01A940B21982BF4C3C89@DYN-EXCH-001.dynamicsoft.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 13 Nov 2000 18:43:50 -0500 (EST)
Content-Transfer-Encoding: 7bit

On Monday, November 13 2000, "Jonathan Rosenberg" wrote to "'Jonathan Lennox', Jonathan Rosenberg, 'Cliff.Harris@nokia.com', iptel@lists.bell-labs.com" saying:

> Hmm.
> 
> My proposal is the following. We leave it as it is, and get baseline CPL out
> the door. As a follow up (extension, whatever), I'm very interested in
> investigating, in a general sense, applying VoiceXML style models of remote
> fetching using HTTP to CPL scripts. There are lots of issues and work that
> needs to be addressed. Rather than do this in an ad-hoc way now, lets devote
> the proper attention to it, given people are sufficiently interested.

I'm in favor of this.

Any thoughts on the issue of the use of the term "action"?  I think that's
my only remaining open issue before sending in the new revision for IESG
last call.

-- 
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  Mon Nov 13 20:54:58 2000
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 UAA07883
	for <iptel-archive@odin.ietf.org>; Mon, 13 Nov 2000 20:54:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8F7EF44389; Mon, 13 Nov 2000 19:55:01 -0500 (EST)
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 CF4EB44387
	for <iptel@lists.bell-labs.com>; Mon, 13 Nov 2000 19:54:34 -0500 (EST)
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 UAA10485;
	Mon, 13 Nov 2000 20:56:48 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <4WS2YYRW>; Mon, 13 Nov 2000 20:52:54 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF4C3C8E@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Jonathan Lennox'" <lennox@cs.columbia.edu>, Cliff.Harris@nokia.com
Cc: iptel@lists.bell-labs.com
Subject: RE: [IPTEL] CPL-03 Terminology
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 13 Nov 2000 20:52:48 -0500



 

> -----Original Message-----
> From: Jonathan Lennox [mailto:lennox@cs.columbia.edu]
> Sent: Monday, November 13, 2000 2:54 PM
> To: Cliff.Harris@nokia.com
> Cc: iptel@lists.bell-labs.com
> Subject: Re: [IPTEL] CPL-03 Terminology
> 
> > The second most confusing term was "action". This can mean 
> (1) "top-level
> > action" (or "call processing action"[?]) or (2) a node that 
> performs an
> > action (including "location"[?], but excluding switches). 
> I'd suggest
> > reserving the word "action" for the second meaning. For the 
> first meaning,
> > use the complete term (or to clarify further, perhaps 
> replace "top-level
> > action" with "top-level action tree" or "top-level 
> procedure" and replace
> > "call processing action" with "action tree" or "procedure").
> 
> This one is more of a problem.  While I like the term 
> "procedure" for the
> current "top-level actions" and "subactions", the tag 
> <subaction> is already
> defined.  It seems like it'd be awfully confusing to change 
> the terminology
> in the way you describe, but still call the node <subaction>. 
>  Any thoughts
> on the best way to resolve this?

I do not want to change syntax at this point just for clarification
purposes.

So, lets align the wording with the syntax. "action" should refer to the top
level things, as is defined in 2.1. As for a node that does something, how
about "operation" instead of "action". So, what currently reads from 2.2:

Abstractly, a call processing action is described by a collection of
   nodes, which describe actions that can be performed or choices which
   can be made.

would instead read:

Abstractly, a call processing action is described by a collection of
   nodes, which describe operations that can be performed or choices which
   can be made.

OK? 

-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  Tue Nov 14 22:27:01 2000
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 WAA29938
	for <iptel-archive@odin.ietf.org>; Tue, 14 Nov 2000 22:27:01 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3B23F44345; Tue, 14 Nov 2000 21:27:02 -0500 (EST)
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 ADA9944336
	for <iptel@lists.bell-labs.com>; Tue, 14 Nov 2000 21:26:08 -0500 (EST)
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 WAA20784;
	Tue, 14 Nov 2000 22:28:22 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <4WS2Y5V7>; Tue, 14 Nov 2000 22:24:26 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF4C3CA8@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Cliff.Harris@nokia.com'" <Cliff.Harris@nokia.com>,
        iptel@lists.bell-labs.com
Subject: RE: [IPTEL] CPL-03 Comments and Questions
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 14 Nov 2000 22:24:23 -0500



 

> -----Original Message-----
> From: Cliff.Harris@nokia.com [mailto:Cliff.Harris@nokia.com]
> Sent: Monday, November 13, 2000 4:22 PM
> To: jdrosen@dynamicsoft.com; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] CPL-03 Comments and Questions
> 
> 
> This appears to be a very powerful idea.
> 
> A couple of potential drawbacks:
> 1. Reduced performance: scripts can't be entirely pre-parsed, since a
> different fragment may come back from the Perl script every 
> single call;

That depends on the service, of course. If you look at VoiceXML, they handle
this through caching directives that can be placed in the script. These
directives tell the server whether the fetched content can be cached, and
for how long.

> 2. There could be compatibility problems; namely, the Perl 
> script might
> return a fragment using a namespace not supported by the CPL server.

Sure. You return an error in this case (500 class most probably).

> 
> In some cases, there may be simpler ways of achieving the 
> same goal. For
> example, consider the following as a way of addressing your 
> "criminals"
> example:
> 
> <lookup source="http://www.criminals.com/locate.pl" timeout=5">
>   <success>
>     <reject/>
>   </success>
>   <notfound>
>     <lookup source="registration">
>       <success>
>         <proxy/>
>       </success>
>     </lookup>    
>   </notfound>
> </lookup>
> 
> It just uses existing CPL syntax (but it assumes that the 
> originator's URL
> will be passed to the Perl script, which passes back the 
> originator's URL if
> and only if it is the URL of a criminal).

Well, you are modifying the meaning of lookup. In any case, I'm looking for
something far more generic.


> 
> Another possibility would be to add an action to invoke a script that
> returns an arbitrary string, and to add a new string-switch 
> field to look at
> the result of the script. Then you could do something like this:
> 
> <fetch-string 
> source="http://www.phonenumbers.com/classify.pl" timeout=5">
>   <success>
>     <string-switch field="script-result">
>       <string contains="criminal">
>         <reject/>
>       </string>
>       <string contains="telemarketer">
>         <reject/>
>       </string>
>     </string-switch>
>   </success>
>   <notfound>
>     <lookup source="registration">
>       <success>
>         <proxy/>
>       </success>
>     </lookup>    
>   </notfound>
> </lookup>

This could work, but it makes CPL coding far less modular than I would like.
I really like the VoiceXML model where a fetch can actually return an
entirely new script to execute. 

-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  Tue Nov 14 22:42:59 2000
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 WAA05423
	for <iptel-archive@odin.ietf.org>; Tue, 14 Nov 2000 22:42:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 18CE94434F; Tue, 14 Nov 2000 21:43:02 -0500 (EST)
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 5C5364434D
	for <iptel@lists.bell-labs.com>; Tue, 14 Nov 2000 21:42:04 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA28724;
	Tue, 14 Nov 2000 22:41:51 -0500 (EST)
Message-ID: <3A1205FF.DFBE3B27@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Cliff.Harris@nokia.com'" <Cliff.Harris@nokia.com>,
        iptel@lists.bell-labs.com
Subject: Re: [IPTEL] CPL-03 Comments and Questions
References: <B65B4F8437968F488A01A940B21982BF4C3CA8@DYN-EXCH-001.dynamicsoft.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 14 Nov 2000 22:41:51 -0500
Content-Transfer-Encoding: 7bit

In the "loading" of scripts via HTTP, is this "stacked"? I.e., if the
loaded script returns, what happens? Does execution continue after the
invocation of the http? Is there a namespace separation (VoiceXML has
variables)? Can there be random jumps from a newly-loaded routine to an
existing subroutine? Can existing subroutines be replaced? What if the
subroutine making the http "call" itself gets replaced? What happens to
CPL predictability if there is a loop of endless retrievals?

Just questions - maybe VoiceXML has solved all of these.

I have to admit to some queasiness to a model that looks suspiciously
like the old "load a new segment" model in early Intel/DOS versions. (It
appears somewhat similar to the "load" statement in Tcl, say, too, with
potentially some of the same unpredictability.)
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 15 00:08:59 2000
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 AAA24439
	for <iptel-archive@odin.ietf.org>; Wed, 15 Nov 2000 00:08:59 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1075644338; Tue, 14 Nov 2000 23:09:02 -0500 (EST)
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 B8AE644336
	for <iptel@lists.bell-labs.com>; Tue, 14 Nov 2000 23:08:43 -0500 (EST)
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 AAA21134;
	Wed, 15 Nov 2000 00:10:57 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <4WS2Y5YS>; Wed, 15 Nov 2000 00:07:01 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF4C3CA9@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Cliff.Harris@nokia.com'" <Cliff.Harris@nokia.com>,
        iptel@lists.bell-labs.com, Peter Mataga <PMataga@dynamicsoft.com>
Subject: RE: [IPTEL] CPL-03 Comments and Questions
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 15 Nov 2000 00:06:58 -0500



I'm only a novice at VoiceXML, so any experts out there, please feel free to
correct me. 

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Tuesday, November 14, 2000 10:42 PM
> To: Jonathan Rosenberg
> Cc: 'Cliff.Harris@nokia.com'; iptel@lists.bell-labs.com
> Subject: Re: [IPTEL] CPL-03 Comments and Questions
> 
> 
> In the "loading" of scripts via HTTP, is this "stacked"? 

No.

I.e., if the
> loaded script returns, what happens?

There is no "return".

> Does execution continue after the
> invocation of the http? Is there a namespace separation (VoiceXML has
> variables)?

There can be sharing of variables, but only if those variables are defiend
in the root voicexml document, and then only if the original doc, and the
one just loaded, both share the same root. Otherwise, variables defined
within script A are not in scope when script B is loaded.

> Can there be random jumps from a newly-loaded 
> routine to an
> existing subroutine?

There is a notion of sub-dialogs, which are like subroutine calls.
Sub-dialogs are always invoked by an absolute reference - that is, the URL
of the VoiceXML script plus the name of the form within the voiceXML
document. Its possible that this document is cached, but beyond that, there
is little difference as to whether the sub-dialog is in a new document or
one previously used.


> Can existing subroutines be replaced? 

Since sub-dialogs are referred to by absolute names, they can only be
"replaced" in the sense that the VoiceXML script at the given URI is
re-fetched (since it was not cached), and a different script is returned.


> What if the
> subroutine making the http "call" itself gets replaced?

Thats a good question. I don't know.

 What 
> happens to
> CPL predictability if there is a loop of endless retrievals?

I don't think VoiceXML interpreters have any facility for handing loops. I
guess its up to the http server that is returning these things.

> I have to admit to some queasiness to a model that looks suspiciously
> like the old "load a new segment" model in early Intel/DOS 
> versions. (It
> appears somewhat similar to the "load" statement in Tcl, say, 
> too, with
> potentially some of the same unpredictability.)

I suspect these issues were considered in the design of VoiceXML, but I
personally can't comment. Anyone?

-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 Nov 15 03:59:58 2000
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 DAA22693
	for <iptel-archive@odin.ietf.org>; Wed, 15 Nov 2000 03:59:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CDE6744344; Wed, 15 Nov 2000 03:00:02 -0500 (EST)
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 EC82944336
	for <iptel@lists.bell-labs.com>; Wed, 15 Nov 2000 02:59:19 -0500 (EST)
Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 15 Nov 2000 08:59:13 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id JAA18996; Wed, 15 Nov 2000 09:57:40 +0100 (BST)
Message-ID: <3A125006.6CE85AD6@ubiquity.net>
From: James Undery <jundery@ubiquity.net>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Cliff.Harris@nokia.com'" <Cliff.Harris@nokia.com>,
        iptel@lists.bell-labs.com, Peter Mataga <PMataga@dynamicsoft.com>
Subject: Re: [IPTEL] CPL-03 Comments and Questions
References: <B65B4F8437968F488A01A940B21982BF4C3CA9@DYN-EXCH-001.dynamicsoft.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 15 Nov 2000 08:57:42 +0000
Content-Transfer-Encoding: 7bit



Jonathan Rosenberg wrote:

> > -----Original Message-----
> > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Tuesday, November 14, 2000 10:42 PM
> > To: Jonathan Rosenberg
> > Cc: 'Cliff.Harris@nokia.com'; iptel@lists.bell-labs.com
> > Subject: Re: [IPTEL] CPL-03 Comments and Questions
> >
> >
>
>  What
> > happens to
> > CPL predictability if there is a loop of endless retrievals?
>
> I don't think VoiceXML interpreters have any facility for handing loops. I
> guess its up to the http server that is returning these things.
>
> > I have to admit to some queasiness to a model that looks suspiciously
> > like the old "load a new segment" model in early Intel/DOS
> > versions. (It
> > appears somewhat similar to the "load" statement in Tcl, say,
> > too, with
> > potentially some of the same unpredictability.)
>
> I suspect these issues were considered in the design of VoiceXML, but I
> personally can't comment. Anyone?
>

Whether these issues are addressed or not, I feel that something like SIP CGI
provides the functionality you are after, CPL serves a different niche where
(reasonably) untrusted users can upload scripts. The functionality I believe you
want requires a higher degree of trust and is probably best achieved through
other means. I personally think CPL is better situated towards the centre of the
network and CGI like services nearer (or preferably at) the edge. The reason
being you don't want proxies/gateways to be affected by rogue scripts, yet the
if an UA/phone is tied up you have less of a problem (if it isn't your phone).
Proxies/gateways should only be running CGI style scripts from trusted and
accountable entities.

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 Nov 15 08:58:55 2000
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 IAA02563
	for <iptel-archive@odin.ietf.org>; Wed, 15 Nov 2000 08:58:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9A86B44361; Wed, 15 Nov 2000 07:51:02 -0500 (EST)
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 08B4844336
	for <iptel@lists.bell-labs.com>; Wed, 15 Nov 2000 05:42:11 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01704;
	Wed, 15 Nov 2000 06:41:52 -0500 (EST)
Message-Id: <200011151141.GAA01704@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-cpl-04.txt,.ps
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 15 Nov 2000 06:41:52 -0500

--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		: CPL: A Language for User Control of Internet Telephony
                          Services
	Author(s)	: J. Lennox, H. Schulzrinne
	Filename	: draft-ietf-iptel-cpl-04.txt,.ps
	Pages		: 64
	Date		: 14-Nov-00
	
The Call Processing Language (CPL) is a language that can be used to
describe and control Internet telephony services. It is designed to
be implementable on either network servers or user agent servers. It
is meant to be simple, extensible, easily edited by graphical
clients, and independent of operating system or signalling protocol.
It is suitable for running on a server where users may not be allowed
to execute arbitrary programs, as it has no variables, loops, or
ability to run external programs.
This document is a product of the IP Telephony (IPTEL) working group
of the Internet Engineering Task Force. Comments are solicited and
should be addressed to the working group's mailing list at
iptel@lists.research.bell-labs.com and/or the authors.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-04.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-cpl-04.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-cpl-04.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:	<20001114135943.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-iptel-cpl-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-iptel-cpl-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20001114135943.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  Wed Nov 15 09:27:06 2000
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 JAA14194
	for <iptel-archive@odin.ietf.org>; Wed, 15 Nov 2000 09:27:06 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8847B44371; Wed, 15 Nov 2000 08:27:01 -0500 (EST)
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 16BC044370
	for <iptel@lists.bell-labs.com>; Wed, 15 Nov 2000 08:26:16 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA00783;
	Wed, 15 Nov 2000 09:25:59 -0500 (EST)
Message-ID: <3A129CF7.83E7066A@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Cliff.Harris@nokia.com'" <Cliff.Harris@nokia.com>,
        iptel@lists.bell-labs.com, Peter Mataga <PMataga@dynamicsoft.com>
Subject: Re: [IPTEL] CPL-03 Comments and Questions
References: <B65B4F8437968F488A01A940B21982BF4C3CA9@DYN-EXCH-001.dynamicsoft.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 15 Nov 2000 09:25:59 -0500
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 

> > In the "loading" of scripts via HTTP, is this "stacked"?
> 
> No.

Then I don't understand the model. What happens if the script loaded is
"finished"? Where does the point of execution go?


>  What
> > happens to
> > CPL predictability if there is a loop of endless retrievals?
> 
> I don't think VoiceXML interpreters have any facility for handing loops. I
> guess its up to the http server that is returning these things.

The HTTP server has no clue about this. How could it know that the same
script, possibly by a different name, is loaded again and again?

Overall, unless the model is much cleaner than it currently looks to me,
this has the potential of negating one of the prime benefits of CPL,
namely predictability and provable correctness. 

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 15 09:34:45 2000
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 JAA17915
	for <iptel-archive@odin.ietf.org>; Wed, 15 Nov 2000 09:34:45 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1541244376; Wed, 15 Nov 2000 08:33:02 -0500 (EST)
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 AFEF044336
	for <iptel@lists.bell-labs.com>; Wed, 15 Nov 2000 08:32:49 -0500 (EST)
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 JAA23095
	for <iptel@lists.bell-labs.com>; Wed, 15 Nov 2000 09:35:05 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <4WS2Y6GJ>; Wed, 15 Nov 2000 09:31:09 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF4C3CAE@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: FW: [IPTEL] I-D ACTION:draft-ietf-iptel-cpl-04.txt,.ps
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 15 Nov 2000 09:31:05 -0500

Folks,

I have just sent -04 to the IESG for consideration as proposed standard.

I'd like to thank the group for everyones hard work over the past two years
(!!) in getting this specification complete. The last few months in
particular have been very productive, and the activity of the group has been
a model for successful working group operation, I think - focused work,
working towards open issues, rough consensus and working code. Jonathan
Lennox deserves special recognition for his hard work on this, especially in
the creation of the Cal-Code library that really pushed this open issue over
the edge. 

Next up is completion of TRIP.... more on that shortly.

Also, please note that I have requested a single slot at the next IETF. I'd
like to use that time primarily to discuss future directions for the group.
We will not be needing discussion on CPL, and I hope the same to be true for
TRIP. As such, I'd like to encourage people to think about future directions
for the group, and to submit drafts with any ideas they might have on where
to go from here. I am personally working on a draft that considers the
intra-domain route distribution problem.

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.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Wednesday, November 15, 2000 6:42 AM
To: IETF-Announce
Cc: iptel@lists.bell-labs.com
Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-cpl-04.txt,.ps


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		: CPL: A Language for User Control of Internet
Telephony
                          Services
	Author(s)	: J. Lennox, H. Schulzrinne
	Filename	: draft-ietf-iptel-cpl-04.txt,.ps
	Pages		: 64
	Date		: 14-Nov-00
	
The Call Processing Language (CPL) is a language that can be used to
describe and control Internet telephony services. It is designed to
be implementable on either network servers or user agent servers. It
is meant to be simple, extensible, easily edited by graphical
clients, and independent of operating system or signalling protocol.
It is suitable for running on a server where users may not be allowed
to execute arbitrary programs, as it has no variables, loops, or
ability to run external programs.
This document is a product of the IP Telephony (IPTEL) working group
of the Internet Engineering Task Force. Comments are solicited and
should be addressed to the working group's mailing list at
iptel@lists.research.bell-labs.com and/or the authors.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-04.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-cpl-04.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-cpl-04.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  Thu Nov 16 20:42:11 2000
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 UAA16978
	for <iptel-archive@odin.ietf.org>; Thu, 16 Nov 2000 20:42:10 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D0B3A4433C; Thu, 16 Nov 2000 19:42:01 -0500 (EST)
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 F18CE44336
	for <iptel@lists.bell-labs.com>; Thu, 16 Nov 2000 19:41:52 -0500 (EST)
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 UAA09740;
	Thu, 16 Nov 2000 20:44:00 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <4WS2Y94T>; Thu, 16 Nov 2000 20:40:00 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF4C3CE1@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Cc: "'stephen.thomas@transnexus.com'" <stephen.thomas@transnexus.com>,
        "'brian.rosen@marconi.com'" <brian.rosen@marconi.com>,
        "'paul@mci.net'" <paul@mci.net>, "'mat@cisco.com'" <mat@cisco.com>,
        "'jis@mit.edu'" <jis@mit.edu>,
        "'mleech@nortelnetworks.com'" <mleech@nortelnetworks.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] A plea for help from the iptel working group
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 16 Nov 2000 20:39:59 -0500

Folks,

There is only one remaining open issue with TRIP
http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-03.txt

and it is one that the authors cannot resolve without assistance.

THe issue is authentication for attributes. The authors think that this
feature is still useful. However, we need to have a set of algorithms, and a
specific encoding format for those algorithms, to be included in the spec. I
believe that this authentication encoding will need to include the
certificate for the signer, since an LS may not have a pre-arranged
relationship with the originator of a route.

We need help in coming up with a set of algorithms (we suspect DSA and RSA,
but need additional guidance on what more, if anything, needs to be said)
and their encoding, including the certs, within TRIP. Actual text for
inclusion in the draft is specifically what we want, not suggestions like
"check out protocol foo", since invariably, what protocol foo has isn't
quite right (i.e., uses ASN.1 or XML or something we don't have). 

So, this is a PLEA for assistance. 

If someone cannot contribute some text here, we may be forced to remove this
feature all together in the baseline draft, and relegate it to a separate
I-D. That may or may not go over well with the A-Ds either.

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.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  Thu Nov 16 21:06:13 2000
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 VAA23357
	for <iptel-archive@odin.ietf.org>; Thu, 16 Nov 2000 21:06:12 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7E36044342; Thu, 16 Nov 2000 20:06:03 -0500 (EST)
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 5F44544336
	for <iptel@lists.bell-labs.com>; Thu, 16 Nov 2000 20:05:32 -0500 (EST)
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id SAA27361;
	Thu, 16 Nov 2000 18:05:25 -0800 (PST)
Received: from rajneesh-nt (dhcp-71-148-191.cisco.com [171.71.148.191])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with SMTP id AAD03204;
	Thu, 16 Nov 2000 18:05:22 -0800 (PST)
Message-Id: <4.1.20001116180251.03b2a7f0@mira-sjc5-4.cisco.com>
X-Sender: rajneesh@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
To: iptel@lists.bell-labs.com
From: Rajneesh Kumar <rajneesh@cisco.com>
Cc: justinf@cisco.com, manjax@cisco.com, dhaval@cisco.com, hsalama@cisco.com
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="=====================_26804723==_"
Subject: [IPTEL] Annex O Contribution
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 16 Nov 2000 18:07:16 -0800

--=====================_26804723==_
Content-Type: text/plain; charset="us-ascii"

FYI .....

We just submitted a Contribution to ITU SG-16  for Annex O. It has an
informational section on TRIP.
Please find the contribution attached.


Thanks,
Rajneesh
--=====================_26804723==_
Content-Type: application/msword; name="TRIP-Submission-ITU-Annex-O.doc"
Content-Disposition: attachment; filename="TRIP-Submission-ITU-Annex-O.doc"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAbwAAAAAAAAAA
EAAAcQAAAAEAAAD+////AAAAAG4AAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEANyAJBAAA+BK/AAAAAAAAEAAAAAAABAAAU0QAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAA
AAAJBBYAJVgAADd8AAA3fAAACj8AAAAAAABIAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAKgBAAAAAAAAqAEAAKgB
AAAAAAAAqAEAAAAAAACoAQAAAAAAAKgBAAAAAAAAqAEAABQAAAAAAAAAAAAAALwBAAAAAAAA+gsA
AAAAAAD6CwAAAAAAAPoLAAA4AAAAMgwAAAwAAAA+DAAANAAAALwBAAAAAAAAIRcAALYAAAB+DAAA
AAAAAH4MAAAWAAAAlAwAAAAAAACUDAAAAAAAAJQMAAAAAAAATw4AAAAAAABPDgAAAAAAAE8OAAAA
AAAAoBYAAAIAAACiFgAAAAAAAKIWAAAAAAAAohYAAAAAAACiFgAAAAAAAKIWAAAAAAAAohYAACQA
AADXFwAAIAIAAPcZAACOAAAAxhYAABUAAAAAAAAAAAAAAAAAAAAAAAAAqAEAAAAAAABPDgAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAtDgAAIgAAAE8OAAAAAAAATw4AAAAAAABPDgAAAAAAAMYWAAAAAAAA
GREAAAAAAACoAQAAAAAAAKgBAAAAAAAAlAwAAAAAAAAAAAAAAAAAAJQMAACZAQAA2xYAABYAAAAZ
EQAAAAAAABkRAAAAAAAAGREAAAAAAABPDgAAkgIAAKgBAAAAAAAAlAwAAAAAAACoAQAAAAAAAJQM
AAAAAAAAoBYAAAAAAAAAAAAAAAAAABkRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAATw4AAAAAAACgFgAAAAAAABkRAABaAwAAGREAAAAAAABzFAAA
cgAAANwVAABUAAAAqAEAAAAAAACoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATBYAAAAAAACUDAAAAAAAAHIMAAAMAAAAcF94oGRL
wAG8AQAAPgoAAPoLAAAAAAAA4RAAABwAAAAwFgAADgAAAAAAAAAAAAAATBYAAFQAAADxFgAAMAAA
ACEXAAAAAAAAPhYAAA4AAACFGgAAAAAAAP0QAAAcAAAAhRoAAAAAAABMFgAAAAAAABkRAAAAAAAA
vAEAAAAAAAC8AQAAAAAAAKgBAAAAAAAAqAEAAAAAAACoAQAAAAAAAKgBAAAAAAAAAgDZAAAASVRV
IFRlbGVjb21tdW5pY2F0aW9uIFN0YW5kYXJkaXphdGlvbiBTZWN0b3IJCQkJRG9jdW1lbnQgQVBD
LTIwMjQNU3R1ZHkgR3JvdXAgMTYNUS4xMi0xNC8xNiBSYXBwb3J0ZXVyIE1lZXRpbmcNR2VuZXZh
LCA5IC0gMTAgTm92ZW1iZXIgMjAwMA0NDVF1ZXN0aW9uKHMpOglRLjEzLzE2DQ1Tb3VyY2UqOglD
aXNjbyBTeXN0ZW1zLCBJbmMuIA0NVGl0bGU6CQlUUklQIENvbnRyaWJ1dGlvbiBmb3IgQW5uZXgg
TyAvIEguMzIzDQ1QdXJwb3NlOglQcm9wb3NhbCA6IAkJDV9fX19fX19fX19fX19fX19fX18NSW50
cm9kdWN0aW9uDVRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBwb3dlciBvZiBUUklQICggVGVs
ZXBob255IFJvdXRpbmcgb3ZlciBJUCApICBhbmQgaG93IGl0IGNhbiBiZSB1c2VkIGZvciBkaXNz
ZW1pbmF0aW5nIHJlYWNoaWJpbGl0eSBpbmZvcm1hdGlvbiBvZiBQU1ROIHRlbGVwaG9ueSBwcmVm
aXhlcy4gSXQgYWxzbyBkaXNjdXNzZXMgaG93IFRSSVAgY2FuIGJlIHVzZWQgaW4gY29uanVuY3Rp
b24gd2l0aCBILjMyMyBzZXNzaW9uIHByb3RvY29sLg0NUHJvcG9zYWwNDV9fX19fX19fX19fX19f
X19fX18NDU1haW4gQ2FwYWJpbGl0aWVzIG9mIFRSSVANDVRSSVAgaXMgYSBwb2xpY3kgZHJpdmVu
IGR5bmFtaWMgcm91dGluZyBwcm90b2NvbCBmb3IgYWR2ZXJ0aXNpbmcgdGhlIHJlYWNoYWJpbGl0
eSBvZiB0ZWxlcGhvbnkgZGVzdGluYXRpb25zLCBhbmQgZm9yIGFkdmVydGlzaW5nIGF0dHJpYnV0
ZXMgb2YgdGhlIHJvdXRlcyB0byB0aG9zZSBkZXN0aW5hdGlvbnMuIFRSSVBzIG9wZXJhdGlvbiBp
cyBpbmRlcGVuZGVudCBvZiBhbnkgc2lnbmFsaW5nIHByb3RvY29sLCBoZW5jZSBUUklQIGNhbiBz
ZXJ2ZSBhcyB0aGUgdGVsZXBob255IHJvdXRpbmcgcHJvdG9jb2wgZm9yIGFueSBzaWduYWxpbmcg
cHJvdG9jb2wuDQ1UUklQIGlzIGEgcm91dGluZyBwcm90b2NvbCBiYXNlZCBvbiBhIHdlbGwta25v
d24gSW50ZXJuZXQgcm91dGluZyBwcm90b2NvbCBjYWxsZWQgQkdQLTQgdGhhdCBmb3JtcyBtdWNo
IG9mIGJhY2tib25lIG9mIHRoZSBJbnRlcm5ldCB0b2RheS4gIExpa2UgQkdQLTQsIFRSSVAgaXMg
YSBwcm90b2NvbCB0aGF0IGhlbHBzIGluIGV4Y2hhbmdlIG9mICByb3V0aW5nIGluZm9ybWF0aW9u
IGFtb25nIHZhcmlvdXMgIlRSSVAgU3BlYWtlcnMiLiBUUklQIFNwZWFrZXJzLCBhbHNvIGNhbGxl
ZCBMb2NhdGlvbiBTZXJ2ZXJzLCBleGNoYW5nZSAgYW5kIHN0b3JlIHJvdXRpbmcgaW5mb3JtYXRp
b24gZm9yIHJlYWNoaWJpbGl0eSBvZiB0ZWxlcGhvbnkgcHJlZml4ZXMuICBTZXNzaW9uIFByb3Rv
Y29scyBsaWtlIEguMzIzIGNhbiAgdGhlbiBxdWVyeSB0aGUgIExvY2F0aW9uIFNlcnZlciBmb3Ig
cm91dGVzIHRvIHJlYWNoICBhIHBhcnRpY3VsYXIgIHRlbGVwaG9ueSBwcmVmaXguICBJdCBpcyBw
b3NzaWJsZSB0aGF0IHRoZSBzZXNzaW9uIHByb3RvY29sIG1pZ2h0IGJlIGxvY2F0ZWQgb24gYW4g
ZW50aXR5LCB0eXBpY2FsbHkgYSBnYXRld2F5IG9yIGdhdGVrZWVwZXIgaW4gY2FzZSBvZiBILjMy
Mywgd2hpbGUgdGhlIExvY2F0aW9uIFNlcnZlciBtYXkgYmUgcnVubmluZyBvbiBhIHNlcGFyYXRl
IGVudGl0eS4gSW4gdGhpcyBjYXNlIGEgUkFTIGxpa2UgcHJvdG9jb2wgY2FuIHF1ZXJ5IHRoZSBM
b2NhdGlvbiBTZXJ2ZXIgKGFuYWxvZ291cyB0byBhbiBMUlEtTENGIGV4Y2hhbmdlKS4gDQ1UUklQ
IGludHJvZHVjZXMgYSBjb25jZXB0IG9mIElQIFRlbGVwaG9ueSBBZG1pbmlzdHJhdGl2ZSBEb21h
aW5zICggSVRBRHMgKS4gQW4gSVRBRCBpcyBhIHNldCBvZiByZXNvdXJjZXMgY29uc2lzdGluZyBv
ZiBnYXRld2F5cyBhbmQgYXQgbGVhc3Qgb25lIFRSSVAgTG9jYXRpb24gU2VydmVyIChhbW9uZyBv
dGhlciBWb0lQIGVsZW1lbnRzICkgdGhhdCBhcmUgY29udHJvbGxlZCBieSBhIHNpbmdsZSBhdXRo
b3JpdHkuIEluIGFuIEguMzIzIE5ldHdvcmssIGFuIElUQUQgY291bGQgY29uc2lzdHMgb2YgYSBz
ZXQgb2YgSC4zMjMgZ2F0ZXdheXMgaW50ZXJlc3RlZCBpbiBhZHZlcnRpc2luZyBwcmVmaXhlcyB2
aWEgdGhlIFRSSVAgU3BlYWtlci4gR2F0ZXdheXMgaW50ZXJlc3RlZCBpbiBhZHZlcnRpc2luZyB0
aGUgcHJlZml4ZXMgdGhleSB0ZXJtaW5hdGUgY2FuICJyZWdpc3RlciIgd2l0aCB0aGUgVFJJUCBT
cGVha2VyLiBQcm90b2NvbCBmb3Igc3VjaCByZWdpc3RyYXRpb24gaXMgbm90IHNwZWNpZmllZC4g
QSBSQVMgbGlrZSBwcm90b2NvbCBjYW4gYmUgdXNlZCBmb3Igc3VjaCBwdXJwb3Nlcy4gDQ1BbiAg
SVRBRCBjYW4gc3BhbiBtdWx0aXBsZSBILjMyMyB6b25lcy4gIE9uIHRoZSBvdGhlciBoYW5kLCBh
biBJVEFEIG1heSBvciBtYXkgbm90IGhhdmUgdGhlIHNhbWUgYm91bmRhcmllcyBhcyB0aGF0IG9m
IGFuIEFubmV4LUcgZG9tYWluLiAgQSBUUklQIHNwZWFrZXIgY29tbXVuaWNhdGVzIHdpdGggb3Ro
ZXIgVFJJUCBzcGVha2VycywgYm90aCB3aXRoaW4gdGhlIHNhbWUgSVRBRCAoIGludHJhLWRvbWFp
biApICBhbmQgdG8gc3BlYWtlcnMgb3V0c2lkZSB0aGUgSVRBRCAoIGludGVyLWRvbWFpbiApLiAN
DVRSSVAgUGVlcnMgIA0NQSBUUklQIFNwZWFrZXIgZXN0YWJsaXNoZXMgaW50cmEtZG9tYWluIGFu
ZCBpbnRlci1kb21haW4gInBlZXJpbmcgc2Vzc2lvbnMiIHdpdGggb3RoZXIgVFJJUCBTcGVha2Vy
cyB0byBleGNoYW5nZSByb3V0aW5nIGluZm9ybWF0aW9uLiAgVGhlIHBlZXJpbmcgc2Vzc2lvbnMg
YXJlIGVzdGFibGlzaGVkIHRvIGV4Y2hhbmdlIHJvdXRlcyB0byB0ZWxlcGhvbnkgZGVzdGluYXRp
b25zLiAgVHdvIHBlZXJzIHVwZGF0ZSBlYWNoIG90aGVyIG9mIG5ldyByb3V0ZXMgdGhleSBsZWFy
bi4gRWFjaCBwZWVyIG1heSBpbi10dXJuIGxlYXJuIGFib3V0IG5ldyByb3V0ZXMgZnJvbSBvdGhl
ciBwZWVycyBvciB0aHJvdWdoIGdhdGV3YXlzIHJlZ2lzdGVyaW5nIHRlbGVwaG9ueSBwcmVmaXhl
cyB0byB0aGVtIG9yIHRocm91Z2ggYSBzdGF0aWMgY29uZmlndXJhdGlvbiBvbiB0aGUgTG9jYXRp
b24gU2VydmVycy4gVGhlIHBlZXJzIGFsc28gIndpdGhkcmF3IiB0aGUgcm91dGVzIHRoZXkgYWR2
ZXJ0aXNlZCB0byB0aGUgb3RoZXIgcGVlciBvbiBsZWFybmluZyBhYm91dCB0aGUgdW5hdmFpbGFi
aWxpdHkgb2YgdGhlIHJvdXRlcy4gIFRSSVAgZG9lcyBub3QgcmVxdWlyZSBwZXJpb2RpYyByZWZy
ZXNoIG9mIHRoZSByb3V0ZXMuIFRoZSBzcGVha2VycyBwZXJpb2RpY2FsbHkgZXhjaGFuZ2Uga2Vl
cC1hbGl2ZSBtZXNzYWdlcyB0byBlbnN1cmUgdGhhdCB0aGUgcGVlcnMgYXJlIG9wZXJhdGlvbmFs
Lg0NVFJJUCBwZWVyaW5nIHNlc3Npb25zIHVzZSBUQ1AgZm9yIHRyYW5zcG9ydC4gVGh1cyB0aGUg
cmVsaWFiaWxpdHkgb2YgaW5mb3JtYXRpb24gaXMgZW5zdXJlZC4gDQ1BcGFydCBmcm9tIGNvbnZl
eWluZyB0aGUgdGVsZXBob255IGRlc3RpbmF0aW9ucyAoIHByZWZpeGVzICkgdGhhdCBhIExvY2F0
aW9uIFNlcnZlciBjYW4gcmVhY2gsIGEgcm91dGluZyB1cGRhdGUgYWxzbyBjYXJyaWVzIHNvbWUg
bW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGF0IHJvdXRlLCBjYWxsZWQgdGhlICJhdHRyaWJ1dGVz
IiBhc3NvY2lhdGVkIHdpdGggdGhlIHJvdXRlLiAgQXMgd2lsbCBiZSBkaXNjdXNzZWQgbGF0ZXIs
IHRoZXNlIGF0dHJpYnV0ZXMgYXJlIGhlbHBmdWwgaW4gZGVzY3JpYmluZyBjaGFyYWN0ZXJpc3Rp
Y3Mgb2YgdGhlIHJvdXRlIGFzIHdlbGwgYXMgaW4gY29ycmVjdCBvcGVyYXRpb24gb2YgdGhlIHBy
b3RvY29sLiBUaGV5IGFsc28gaGVscCBpbiBlbmZvcmNpbmcgcG9saWNpZXMgYW5kIG5ldHdvcmsg
ZGVzaWduLiANDSBUUklQIHF1YWxpZmllcyBpbnRlci1kb21haW4gc2Vzc2lvbnMgYXMgcnVubmlu
ZyBFLVRSSVAgc2Vzc2lvbnMgKCBFeHRlcm5hbCBUUklQICkgYW5kICBpbnRyYS1kb21haW4gc2Vz
c2lvbnMgYXMgSS1UUklQIChpbnRlcm5hbCBUUklQICkuRmlndXJlIDEgc2hvd3MgdHdvIElUQURz
LiBJVEFEIDEgIGhhcyB0d28gTG9jYXRpb24gU2VydmVycy4gIEdhdGV3YXlzIEcxIGFuZCBHMiBy
ZWdpc3RlciB3aXRoIExTMiBhbmQgR2F0ZXdheXMgRzMgYW5kIEc0IHJlZ2lzdGVyIHdpdGggTFMx
LiAgTFMxIGFuZCBMUzIgaGF2ZSBJLVRSSVAgcGVlcmluZy4gIExTMSBwZWVycyB3aXRoIExTMyBp
biBJVEFEMiAoIEUtVFJJUCBwZWVyaW5nICkuIA0NIEludGVybmFsIFRSSVAgdXNlcyBhIGxpbmsg
c3RhdGUgbWVjaGFuaXNtIHRvIGZsb29kIGRhdGFiYXNlIHVwZGF0ZXMgb3ZlciBhbiBhcmJpdHJh
cnkgdG9wb2xvZ3kuIEFuIGF0dGVtcHQgaXMgbWFkZSB0byBzeW5jaHJvbml6ZSByb3V0aW5nIGlu
Zm9ybWF0aW9uIGFtb25nIFRSSVAgTFNzIHdpdGhpbiBhbiBJVEFEIHRvIG1haW50YWluIGEgc2lu
Z2xlIHVuaWZpZWQgdmlldy4gVG8gYWNoaWV2ZSBpbnRlcm5hbCBzeW5jaHJvbml6YXRpb24sIGlu
dGVybmFsIHBlZXIgY29ubmVjdGlvbnMgYXJlIGNvbmZpZ3VyZWQgYmV0d2VlbiBMU3Mgb2YgdGhl
IHNhbWUgSVRBRCBzdWNoIHRoYXQgdGhlIHJlc3VsdGluZyBpbnRyYS1kb21haW4gTG9jYXRpb24g
U2VydmVyIHRvcG9sb2d5IGlzIGNvbm5lY3RlZCBhbmQgc3VmZmljaWVudGx5IHJlZHVuZGFudC4g
V2hlbiBhbiB1cGRhdGUgaXMgcmVjZWl2ZWQgZnJvbSBhbiBpbnRlcm5hbCBwZWVyLCB0aGUgcm91
dGVzIGluIHRoZSB1cGRhdGUgYXJlIGNoZWNrZWQgdG8gZGV0ZXJtaW5lIGlmIHRoZXkgYXJlIG5l
d2VyIHRoYW4gdGhlIHZlcnNpb24gYWxyZWFkeSBpbiB0aGUgZGF0YWJhc2UuIE5ld2VyIHJvdXRl
cyBhcmUgdGhlbiBmbG9vZGVkIHRvIGFsbCBvdGhlciBwZWVycyBpbiB0aGUgc2FtZSBJVEFELiAN
DSBXaGlsZSB1cGRhdGVzIHdpdGhpbiBhbiBJVEFEIGFyZSBmbG9vZGVkIG9udG8gaW50ZXJuYWwg
cGVlcnMsIEV4dGVybmFsIFRSSVAgdXBkYXRlcyBhcmUgcG9pbnQtdG8tcG9pbnQuDQ0gVFJJUCB1
cGRhdGVzIHJlY2VpdmVkIGJ5IGFuIElUQUQgWCBmcm9tIElUQUQgWSBjYW4gYmUgcGFzc2VkIG9u
IHRvIElUQUQgWiB3aXRoIG9yIHdpdGhvdXQgYW55IG1vZGlmaWNhdGlvbnMgKCB3aXRoIFggYW5k
IFogbm90IHNoYXJpbmcgYW55IHBlZXJpbmcgcmVsYXRpb24gKS4gIFRodXMgYSByb3V0ZSAiYWR2
ZXJ0aXNlbWVudCIgbWlnaHQgcmVhY2ggYSBwZWVyIGFmdGVyIGhvcHBpbmcgdGhyb3VnaCB2YXJp
b3VzIFRSSVAgU3BlYWtlcnMgaW4gZGlmZmVyZW50IElUQURzLiAgVGhlIGxpc3Qgb2YgSVRBRHMg
dGhyb3VnaCB3aGljaCBhbiB1cGRhdGUgdHJhdmVyc2VzIGZvciBhIGdpdmVuIHJvdXRlIGlzIHJl
Y29yZGVkIGluIGFuIGF0dHJpYnV0ZSBhc3NvY2lhdGVkIHdpdGggdGhhdCByb3V0ZSwgY2FsbGVk
IHRoZSBBZHZlcnRpc21lbnRQYXRoLiAgRWFjaCByb3V0ZSBhbHNvIGhhcyBhICJOZXh0SG9wU2Vy
dmVyIiBhdHRyaWJ1dGUgYXNzb2NpYXRlZCB3aXRoIGl0LiAgSXQgc2lnbmlmaWVzIHRoZSBhZGRy
ZXNzIG9mIHRoZSBuZXh0IHNpZ25hbGluZyBlbnRpdHkgdGhhdCBuZWVkcyB0byBiZSBjb250YWN0
ZWQgaW4gb3JkZXIgdG8gc2V0dXAgYSBjYWxsLiBJdCBpcyB1cHRvIHRoZSBMb2NhdGlvblNlcnZl
ciBhdCB0aGUgYm91bmRhcnkgb2YgdGhlIElUQUQgaWYgaXQgd2FudHMgdG8gYWRkIGEgbmV3IHNp
Z25hbGxpbmcgZWxlbWVudCBpbiB0aGUgc2lnbmFsaW5nIHBhdGggZm9yIHRoZSByb3V0ZSBpbiBx
dWVzdGlvbi4gRm9yIGV4YW1wbGUsIGFuIExTIGNvdWxkIGNoYW5nZSB0aGUgTmV4dEhvcFNlcnZl
ciBmb3IgYWxsIHRoZSByb3V0ZXMgdGhhdCBpdCBpcyBkaXNzZW1pbmF0aW5nIHRvIHBvaW50IHRv
IGEgZ2F0ZWtlZXBlciBzbyB0aGF0IGFsbCB0aGUgY2FsbHMgZm9yIGRlc3RpbmF0aW9uIHByZWZp
eGVzIGluIHRoYXQgSVRBRCBsYW5kIG9uIHRoZSBnYXRla2VlcGVyIGZvciBiaWxsaW5nIHB1cnBv
c2VzLiBJbiBvcmRlciB0byBkbyB0aGlzLCB0aGUgTFMgd291bGQgb3ZlcndyaXRlIHRoZSBOZXh0
SG9wU2VydmVyIG9mIHRoZSByb3V0ZSAoIHdpdGggdGhlIGFkZHJlc3Mgb2YgdGhpcyBuZXcgc2ln
bmFsaW5nIGVsZW1lbnQgKSBiZWZvcmUgc2VuZGluZyBvdXQgdGhlIHVwZGF0ZSB0byBpdHMgcGVl
cnMuIFRodXMsIGEgc2lnbmFsaW5nIG1lc3NhZ2UgKCBsaWtlIEguMjI1IFNldHVwICkgZm9yIGEg
Z2l2ZW4gdGVsZXBob255IGRlc3RpbmF0aW9uIHNoYWxsIG9ubHkgZ28gdGhyb3VnaCBJVEFEcyB3
aGljaCBoYXZlIGNoYW5nZWQgdGhlIE5leHRIb3BTZXJ2ZXIgYXR0cmlidXRlIGZvciB0aGUgcm91
dGUgaW4gcXVlc3Rpb24uIFRoaXMgbGlzdCBvZiBJVEFEcyBpcyByZWNvcmRlZCBpbiBhbm90aGVy
IGF0dHJpYnV0ZSBjYWxsZWQgUm91dGVkUGF0aC4gDQ1BIFRSSVAgU3BlYWtlciBvbiB0aGUgYm91
bmRhcnkgb2YgdGhlIElUQUQgIG1heSAgb3B0aW9uYWxseSAgImFnZ3JlZ2F0ZSIgc29tZSByb3V0
ZXMgYmVmb3JlIHNlbmRpbmcgb3V0IGEgcm91dGluZyB1cGRhdGUgdG8gYW4gZXh0ZXJuYWwgc3Bl
YWtlci4gSW4gRmlndXJlIDEgd2Ugc2VlIExTMSBhZ2dyZWdhdGluZyByb3V0ZXMgZnJvbSBHMSAo
IDg1ODEqIHRocm91Z2ggODU4NyogKSAgYW5kICBHMiAoIDg1ODgqICB0aHJvdWdoIDg1ODAqICkg
IGJlZm9yZSBzZW5kaW5nIHRoZSBFVFJJUCB1cGRhdGUgdG8gTFMzIGFzIGEgIDg1OCogcm91dGUu
IA0NVGh1cyBUUklQIGNhbiBiZSB1c2VkIGZvciBpbnRlci1kb21haW4gYXMgd2VsbCBhcyBpbnRy
YS1kb21haW4gcm91dGluZy4gSXQgaXMgYWxzbyBwb3NzaWJsZSB0byB1c2UgVFJJUCBvbiBhIGdh
dGV3YXkgYXMgYSByZWdpc3RyYXRpb24gcHJvdG9jb2wuICBXaGVuIHVzZWQgaW4gdGhpcyB3YXks
IHRoZSBUUklQIFByb3RvY29sIHNoYWxsIHJ1biBvbiB0aGUgZ2F0ZXdheSBpbiBhICJzZW5kLW9u
bHkiIG1vZGUsIG9ubHkgc2VuZGluZyByb3V0aW5nIGluZm9ybWF0aW9uICggcHJlZml4ZXMgc3Vw
cG9ydGVkIGJ5IHRoZSBnYXRld2F5ICkgdG8gaXQncyBwZWVyICggYSBMb2NhdGlvbiBTZXJ2ZXIg
KS4NDQ0BDQ0NDSBSb3V0ZXMgYW5kIFJvdXRlIFNlbGVjdGlvbg0NQSByb3V0ZSBpbiBUUklQICBp
cyBkZWZpbmVkIGFzIHRoZSBjb21iaW5hdGlvbiBvZiAgKGEpIGEgdGVsZXBob255IGRlc3RpbmF0
aW9uICBhZGRyZXNzZXMsIGdpdmVuIGJ5IGFuIGFkZHJlc3MgZmFtaWx5IGluZGljYXRvciBhbmQg
YW4gYWRkcmVzcyAoIHRlbGVwaG9ueSApICBwcmVmaXggYW5kIChiKSBhbiBhcHBsaWNhdGlvbiBw
cm90b2NvbCAoIGUuZyBILjMyMywgU0lQIGV0Yy4gKS4gVGhlIHRyYW5zcG9ydCBhZGRyZXNzIGFz
c29jaWF0ZWQgd2l0aCB0aGlzIHRlbGVwaG9ueSBkZXN0aW5hdGlvbiBpcyBpbmNsdWRlZCBpbiB0
aGUgIk5leHRIb3BTZXJ2ZXIiIGF0dHJpYnV0ZSBvZiB0aGUgcm91dGUuIFRSSVAgc3VwcG9ydHMg
dHdvIGFkZHJlc3MgZmFtaWxpZXM6IFBPVFMgbnVtYmVycyBhbmQgUm91dGluZyBudW1iZXJzLiAg
UE9UUyBudW1iZXJzIGFkZHJlc3MgZmFtaWx5IGlzIGEgc3VwZXIgc2V0IG9mIGFsbCBFLjE2NCBu
dW1iZXJzLCBuYXRpb25hbCBudW1iZXJzLCBsb2NhbCBudW1iZXJzIGFuZCBwcml2YXRlIG51bWJl
cnMuICBUaGUgdHlwZSBvZiBQT1RTIG51bWJlciAocHJpdmF0ZSwgbG9jYWwsIG5hdGlvbmFsIG9y
IGludGVybmF0aW9uYWwpIGNhbiBiZSBkZWR1Y2VkIGZyb20gdGhlIGZpcnN0IGZldyBkaWdpdHMg
b2YgdGhlIFBPVFMgcHJlZml4LiBSb3V0aW5nIE51bWJlcnMgZmFtaWx5IGlzIHVzZWQgdG8gcmVw
cmVzZW50IHJvdXRpbmcgbnVtYmVycyB1c2VkIGluIGNvbmp1bmN0aW9uIHdpdGggTnVtYmVyIFBv
cnRhYmlsaXR5LiBSb3V0aW5nIE51bWJlcnMgYXJlIHVzZWQgdG8gaWRlbnRpZnkgc3dpdGNoZXMg
YW5kIGxpbmUgY2FyZHMgaW4gdGhlIHN3aXRjaGVzLiAgSXQgaXMgcG9zc2libGUgdG8gZXh0ZW5k
IFRSSVAgdG8gc3VwcG9ydCBuZXcgYWRkcmVzcyBmYW1pbGllcyBpZiBuZWVkZWQuIA0NQXMgbWVu
dGlvbmVkIGVhcmxpZXIsIFRSSVAgaXMgYSBnZW5lcmFsIHJvdXRpbmcgcHJvdG9jb2wgdGhhdCBj
YW4gYmUgdXNlZCBmb3IgZGlzc2VtaW5hdGluZyByZWFjaGliaWxpdHkgaW5mb3JtYXRpb24gb2Yg
dGVsZXBob255IGRlc3RpbmF0aW9ucywgaXJyZXNwZWN0aXZlIG9mIHRoZSBhcHBsaWNhdGlvbiAo
c2lnbmFsaW5nKSAgcHJvdG9jb2wgaW4gdXNlLiBUaGUgVFJJUCBMb2NhdGlvbiBTZXJ2ZXIgY2Fu
IGJlIHF1ZXJpZWQgdG8gZmV0Y2ggYSByb3V0ZSBmb3IgYSBwYXJ0aWN1bGFyIHRlbGVwaG9ueSBw
cmVmaXggYW5kIGFwcGxpY2F0aW9uIHByb3RvY29sIGNvbWJpbmF0aW9uLlRSSVAgc3VwcG9ydHMg
Zm91ciBhcHBsaWNhdGlvbiBwcm90b2NvbHM6ICBTSVAsIEguMzIzLVEuOTMxLCBILjMyMy1SQVMs
IGFuZCBILjMyMy1Bbm5leC1HLiAgVGh1cyBUUklQIGNhbiBoZWxwIGluIHByb3BhZ2F0aW9uIG9m
IHJvdXRlcyBldmVuIHdoZW4gUkFTIG9yIEguMzIzLUFubmV4RyBpcyB1c2VkICAoIEZvciBpbGx1
c3RyYXRpdmUgZXhhbXBsZXMsIHBsZWFzZSByZWZlciB0byB0aGUgc2VjdGlvbiAiVFJJUCBpbiBh
biBILjMyMyBOZXR3b3JrIiApDQ1BIFJvdXRlIFNlbGVjdGlvbiBhbGdvcml0aG0gcnVucyBvbiB0
aGUgTG9jYXRpb24gU2VydmVyLiBUaGUgcHVycG9zZSBvZiB0aGlzIGFsZ29yaXRobSBpcyB0byBn
ZW5lcmF0ZSB0aGUgYmVzdCByb3V0ZSBmb3IgYSBnaXZlbiBwcmVmaXggKGFuZCBhcHBsaWNhdGlv
biBwcm90b2NvbCkgYmFzZWQgb24gdGhlIGluZm9ybWF0aW9uIHN0b3JlZCBpbiB0aGUgZGF0YWJh
c2UuIExTIHJldHVybnMgdGhpcyBhcyB0aGUgcm91dGUgZm9yIGEgcHJlZml4IHdoZW4gcXVlcmll
ZCBieSBhbiBhcHBsaWNhdGlvbiBwcm90b2NvbC4gVGhlIHJvdXRlIHRodXMgb2J0YWluZWQgaXMg
YWxzbyB0aGUgb25lIHRvIGJlIGFkdmVydGlzZWQgYnkgdGhlIExTIHRvIGl0cyBwZWVycywgc3Vi
amVjdCB0byBwb2xpY3kgY29uZmlndXJhdGlvbi4gVGhlIGFsZ29yaXRobSBjb21lcyBpbnRvIHBs
YXkgd2hlbmV2ZXIgc29tZSByb3V0aW5nIGluZm9ybWF0aW9uIGNoYW5nZXMgYmVjYXVzZSBvZiBu
ZXcgcm91dGluZyB1cGRhdGVzLCBpbnRyb2R1Y2luZyBvciB3aXRoZHJhd2luZyByb3V0ZXMgdG8g
Y2VydGFpbiBwcmVmaXhlcy4gIEl0IGJhc2VzIGl0J3MgZGVjaXNpb24gb24gY2VydGFpbiBhdHRy
aWJ1dGVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgcm91dGVzIHRoYXQgZGVmaW5lIHRoZSBjaGFyYWN0
ZXJpc3RpY3Mgb2YgdGhlIHBhdGggYXNzb2NpYXRlZCB3aXRoIHRoZSByb3V0ZS4gDQ1UaGUgbm90
aW9uIG9mIGF0dHJpYnV0ZXMgaW4gVFJJUCBwbGF5cyBhbiBpbXBvcnRhbnQgcm9sZSBpbiBjb3Jy
ZWN0IGFuZCBlZmZpY2llbnQgZnVuY3Rpb25pbmcgb2YgdGhlIHByb3RvY29sLiBUaGUgUm91dGVk
UGF0aCBhdHRyaWJ1dGUgaXMgdXNlZCB0byBzcGVjaWZ5IHRoZSBpbnRlcm1lZGlhdGUgSVRBRHMg
IHRvIGJlIHRha2VuIGJ5IHRoZSBzaWduYWxpbmcgcHJvdG9jb2wgdG8gcmVhY2ggdGhlIGRlc3Rp
bmF0aW9uIHByZWZpeC4gUm91dGVkUGF0aCBtYXkgYmUgdXNlZCBpbiBzZWxlY3Rpb24gb2YgYSBy
b3V0ZSB3aGVuIG11bHRpcGxlIHJvdXRlcyBhcmUgcHJlc2VudDogQW4gTFMgbWF5IHByZWZlciBy
b3V0ZSB3aXRoIGEgbG93ZXIgbnVtYmVyIG9mIElUQURzIGluIHRoZSBSb3V0ZWRQYXRoIGF0dHJp
YnV0ZSBzbyB0aGF0IGEgc2lnbmFsaW5nIGNhbGwgaGFzIHRvIGdvIHRocm91Z2ggbWluaW1hbCBo
b3BzLiAgQW4gQWR2ZXJ0aXNlbWVudCBQYXRoIHRyYWNlcyB0aGUgIElUQURzIHRoYXQgYSByb3V0
ZSBhZHZlcnRpc2VtZW50ICggdXBkYXRlICkgaGFzIHRyYXZlbGVkIHNvIGZhci4gQWR2ZXJ0aXNl
bWVudFBhdGggaXMgdXNlZnVsIGluIGRldGVjdGluZyBsb29wcyBpbiB0aGUgcm91dGVzLiBMb2Nh
bCBQcmVmZXJlbmNlIGF0dHJpYnV0ZSBoZWxwcyBpbiBkZXRlcm1pbmluZyBhIHBhcnRpY3VsYXIg
TFMncyBwcmVmZXJlbmNlIGZvciBhIHJvdXRlLiBUaGlzIGNhbiBoZWxwIGRpdmVydCBpbnRyYS1k
b21haW4gc2lnbmFsaW5nIHRyYWZmaWMgdG8gYSBwYXJ0aWN1bGFyIEVUUklQIHBlZXIgd2hlbiBt
b3JlIHRoYW4gb25lIHJvdXRlIGZvciBhIHRlbGVwaG9ueSBkZXN0aW5hdGlvbiBpcyBhdmFpbGFi
bGUuIERpdmVyc2lvbiBvZiB0cmFmZmljIG1pZ2h0IGJlIGhlbHBmdWwgaWYgc2lnbmFsaW5nIGVs
ZW1lbnRzIGluIGEgY2VydGFpbiBuZWlnaGJvcmluZyBJVEFEIGhhdmUgaGlnaGVyIGNhcGFjaXR5
IHRvIGhhbmRsZSBzaWduYWxpbmcgdHJhZmZpYy4gVFJJUCBhbHNvIHN1cHBvcnRzIGxvYWQgYmFs
YW5jaW5nIG9mIHRyYWZmaWMgYWNyb3NzIHR3byBvciBtb3JlIGxpbmtzIGJldHdlZW4gdHdvIElU
QURzLiBUaGlzIGlzIGFjaGlldmVkIGJ5IHRoZSB1c2Ugb2YgYW4gYXR0cmlidXRlIGNhbGxlZCBN
dWx0aUV4aXREaXNjLiBPdGhlciBhdHRyaWJ1dGVzIGxpa2UgQXRvbWljIEFnZ3JlZ2F0ZSBhbmQg
Q29tbXVuaXRpZXMgYXJlIGFsc28gaGVscGZ1bCBpbiBmYWNpbGl0YXRpbmcgZWZmaWNpZW50IHJv
dXRpbmcuICBUaHVzIGF0dHJpYnV0ZSBpbmZvcm1hdGlvbiBjYW4gYmUgdmVyeSBoZWxwZnVsIGlu
IHRyYWZmaWMgZW5naW5lZXJpbmcgb2YgbmV0d29ya3MuIA0NVGhlIFRSSVAgc3BlY2lmaWNhdGlv
biBsZW5kcyBpdHNlbGYgdG8gZXh0ZW5zaWJpbGl0eSBieSBkZWZpbmluZyBuZXcgYXR0cmlidXRl
cy4gRm9yIGV4YW1wbGUgYXR0cmlidXRlcyBmb3IgZGVmaW5pbmcgY29zdCBhbmQgY2FwYWNpdHkg
Y291bGQgYmUgYWRkZWQgaW4gdGhlIGZ1dHVyZS4gIENvZGVzIGZvciB0aGUgbmV3IGF0dHJpYnV0
ZXMgY2FuIGJlIG9idGFpbmVkIGZyb20gSUFOQS4gIA0NQXMgbWVudGlvbmVkIGVhcmxpZXIgVFJJ
UCwgbGlrZSBCR1AsIGlzIGEgcG9saWN5IGRyaXZlbiBwcm90b2NvbC4gRm9yIGEgcGVlcmluZyBz
ZXNzaW9uLCBpdCBpcyBwb3NzaWJsZSB0byBkZWZpbmUgZmlsdGVycyBmb3IgaW5jb21pbmcgYW5k
IG91dGdvaW5nIHJvdXRpbmcgaW5mb3JtYXRpb24uIEZvciBleGFtcGxlLCBhIExvY2F0aW9uIFNl
cnZlciBtYXkgd2FudCB0byBhY2NlcHQgYSByb3V0aW5nIHVwZGF0ZSBvbmx5IGlmIHRoZSBhdHRy
aWJ1dGVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgcm91dGUgc3VnZ2VzdHMgdGhhdCB0aGUgc2lnbmFs
aW5nIHByb3RvY29sIHRyYWZmaWMgd2lsbCBub3QgdHJhdmVyc2UgdGhyb3VnaCBjZXJ0YWluIElU
QURzLiBUaGlzIGNhbiBiZSBlbnN1cmVkIGJ5IGNoZWNraW5nIHRoZSBSb3V0ZWRQYXRoIGF0dHJp
YnV0ZSBmb3IgdGhlIHByb2hpYml0ZWQgSVRBRHMgYXMgc29vbiBhcyB0aGUgcm91dGluZyB1cGRh
dGUgaXMgcmVjZWl2ZWQgb24gdGhlIEVUUklQIHNlc3Npb24uDQ1UaGlzIGFiaWxpdHkgdG8gZmls
dGVyIHJvdXRlcyBiYXNlZCBvbiBhdHRyaWJ1dGVzICggZm9yIGJvdGggaW5jb21pbmcgYW5kIG91
dGdvaW5nIHVwZGF0ZXMgKSBjYW4gYmUgdmVyeSAgaGVscGZ1bCBpbiBwbGFubmluZyBhbmQgb3B0
aW1pemluZyBuZXR3b3JrIGRlc2lnbnMgZm9yIGNhcGFjaXR5IHBsYW5uaW5nIGFuZCAgZmF1bHQt
dG9sZXJhbmNlLiAgSXQgY2FuIGFsc28gY29tZSBoYW5keSBpbiBlbmZvcmNpbmcgc2V0dGxlbWVu
dCBydWxlcyBiZXR3ZWVuIGFkbWluaXN0cmF0aXZlIGRvbWFpbnMuICANIA1TZWN1cml0eSBpbiBU
UklQDQ1TaW5jZSBUUklQIExTcyBwZWVyIHdpdGggZWFjaCBvdGhlciB0byBleGNoYW5nZSByb3V0
aW5nIGluZm9ybWF0aW9uIHRoYXQgaXMgY3JpdGljYWwgdG8gdGhlIGNvcnJlY3QgYW5kIGVmZmlj
aWVudCBvcGVyYXRpb24gIG9mICBhbiBJVEFELCBpdCBpcyBpbXBvcnRhbnQgdGhhdCBUUklQIHNh
ZmVndWFyZCBpdHNlbGYgZnJvbSBhbnkgdW5hdXRob3JpemVkIHBlZXJpbmcgb3IgInNuaWZmaW5n
IiBvZiB0aGUgaW5mb3JtYXRpb24gYmVpbmcgZXhjaGFuZ2VkLiBUUklQIHN1Z2dlc3RzIHRoZSB1
c2Ugb2YgIElQU2VjIHRvIHNlY3VyZSBpbmZvcm1hdGlvbi4gSVBTZWMgaXMgYSBzdGFuZGFyZGl6
ZWQgc2VjdXJpdHkgbWVjaGFuaXNtIGF2YWlsYWJsZSBmb3IgSVAgbmV0d29ya3MuDQ1UUklQIGFs
c28gdGFrZXMgY2FyZSBvZiBwcm90ZWN0aW5nIFRSSVAgUm91dGVzIGZyb20gYmVpbmcgdGVtcGVy
ZWQgYnkgYW4gdW5hdXRob3JpemVkIGVudGl0eS4gSW4gbWFueSBzaXR1YXRpb25zLCBhbiBMUyBy
ZWNlaXZlcyBhIHJvdXRlLCB3aGljaCBoYXMgYmVlbiBvcmlnaW5hdGVkIGJ5IHJlbW90ZSBMUyB0
aGF0IGlzIG5vdCBhIGRpcmVjdCBwZWVyIG9mIHRoZSByZWNlaXZpbmcgTFMuIEluIGFkZGl0aW9u
LCBhdHRyaWJ1dGVzIG1heSBoYXZlIGJlZW4gaW5zZXJ0ZWQgb3IgYWx0ZXJlZCBhbG9uZyB0aGUg
YWR2ZXJ0aXNlbWVudCBwYXRoLiBUaGUgcmVjZWl2aW5nIExTcyBtYXkgd2lzaCB0byBhdXRoZW50
aWNhdGUgdGhlIHJvdXRlIGJ5IHZlcmlmeWluZyBib3RoIHRoZSBvcmlnaW5hdG9yIG9mIGFuIGF0
dHJpYnV0ZSBhbmQgZmFjdCB0aGF0IHRoZSBjb250ZW50cyBvZiB0aGUgYXR0cmlidXRlIGhhdmUg
bm90IGJlZW4gYWx0ZXJlZCBieSBvdGhlciBpbnRlcm1lZGlhdGUgTFNzLiBUaGUgQXV0aGVudGlj
YXRpb24gYXR0cmlidXRlIGNhcnJpZXMgYSBsaXN0IG9mIHNpZ25hdHVyZXMgc28gdGhhdCBhIHJl
Y2VpdmluZyBMUyBtYXkgdmFsaWRhdGUgcGFydGljdWxhciBhdHRyaWJ1dGVzLg0gDVRSSVAgaW4g
YW4gSC4zMjMgTmV0d29yaw0NSW4gdGhpcyBzZWN0aW9uLCB3ZSBhZGRyZXNzIGhvdyBUUklQIGNh
biBiZSBpbmNvcnBvcmF0ZWQgaW50byB0aGUgSC4zMjMgd29ybGQgdG8gb2ZmZXIgYSBjYWxsIHJv
dXRpbmcgc29sdXRpb24uIFdlIGZpcnN0IGxvb2sgYXQgaG93IHRoZSBILjMyMyBuZXR3b3JrIHdv
dWxkIGxvb2sgbGlrZSBhbmQgdGhlbiBkZW1vbnN0cmF0ZSB1c2luZyBzYW1wbGUgY2FsbCBmbG93
cywgaG93IFRSSVAgY2FuIGJlIHVzZWQgdG8gcm91dGUgYSBjYWxsLg0NQW4gSW50ZXJuZXQgVGVs
ZXBob255IEFkbWluaXN0cmF0aXZlIERvbWFpbiAoSVRBRCksIGFzIGl0IGFwcGxpZXMgdG8gSC4z
MjMsIGNhbiBiZSB0aG91Z2h0IG9mIGFzIGNvbnN0aXR1dGluZyBvbmUgb3IgbW9yZSBILjMyMyB6
b25lcy4gQW4gSVRBRCBlbmNvbXBhc3NpbmcgYW4gSC4zMjMgbmV0d29yayBjYW4gaGF2ZSBvbmUg
b3IgbW9yZSBUUklQIExvY2F0aW9uIFNlcnZlcnMgKExTKSwgSC4zMjMgR2F0ZXdheXMsIG9uZSBv
ciBtb3JlIEdhdGVrZWVwZXJzIGFuZCBBbm5leCBHIEJvcmRlciBFbGVtZW50KHMpLiBUaGVzZSBM
b2NhdGlvbiBTZXJ2ZXJzIGNvdWxkIGV4aXN0IGFzIHN0YW5kLWFsb25lIGVudGl0aWVzIGluIHRo
ZSBuZXR3b3JrIG9yIGNvdWxkIGJlIGNvLWxvY2F0ZWQgd2l0aCBvbmUgb2YgdGhlIEguMzIzIG5l
dHdvcmsgZW50aXRpZXMgKGZvciBleGFtcGxlLCB3aXRoIGEgR2F0ZWtlZXBlcikNDVdoZW4gYSBj
YWxsIGlzIHRvIGJlIHBsYWNlZCwgaXQgaXMgcG9zc2libGUgZm9yIGFueSBILjMyMyBlbnRpdHkg
dG8gcXVlcnkgdGhlIFRSSVAgTFMgdG8gZmV0Y2ggdGhlIGJlc3Qgcm91dGUgZm9yIHRoYXQgdGVs
ZXBob255IHByZWZpeC4gVGhlIHByb3RvY29sIHRvIHF1ZXJ5IGEgVFJJUCBzcGVha2VyIGlzIHVu
c3BlY2lmaWVkLiBBIFJBUy1saWtlIHByb3RvY29sIGNvdWxkIGJlIGNvbnNpZGVyZWQgZm9yIHRo
aXMgcHVycG9zZS4gQWxzbywgdGhlIEguMzIzIGVudGl0eSB0byBpbnRlcmZhY2Ugd2l0aCB0aGUg
VFJJUCBMUyBzaG91bGQgYmUgZGV0ZXJtaW5lZCBiYXNlZCBvbiB0aGUgZGVzaWduIG9mIHRoZSBI
LjMyMyBuZXR3b3JrLg0NSW4gcmVzcG9uc2UgdG8gYSBxdWVyeSwgYSBUUklQIExTIGNvdWxkIHJl
dHVybiBhIHJvdXRlIHNwZWNpZnlpbmcgb25lIG9mIHRoZSBmb2xsb3dpbmcgSC4zMjMgc2lnbmFs
aW5nIHByb3RvY29scyB0byBiZSB1c2VkIHRvIGNvbnRhY3QgdGhlIFNpZ25hbGluZyBTZXJ2ZXIg
b24gdGhlIG5leHQgaG9wIJYgSC4zMjMtUS45MzEsIEguMzIzLVJBUyBvciBILjMyMy1Bbm5leEcu
IFRoaXMgbWVhbnMgdGhhdCB0byBwcm9ncmVzcyB3aXRoIHRoZSBjYWxsIHNldCB1cCBmb3IgdGhh
dCB0ZWxlcGhvbnkgcHJlZml4LCB0aGUgcXVlcnlpbmcgZW50aXR5IHdvdWxkIGJlIHJlcXVpcmVk
IHRvIGVzdGFibGlzaCBhIHNlc3Npb24gd2l0aCB0aGUgU2lnbmFsaW5nIFNlcnZlciBwcm92aWRl
ZCB1c2luZyB0aGUgc3BlY2lmaWVkIHNpZ25hbGluZyBwcm90b2NvbC4gDQ1UaGUgcmVzdCBvZiB0
aGUgZG9jdW1lbnQgZGlzY3Vzc2VzIHNvbWUgY2FsbCBzY2VuYXJpb3MgZGVtb25zdHJhdGluZyB0
aGUgdXNlIG9mIFRSSVAgaW4gcm91dGluZyBhIGNhbGwgaW4gYW4gSC4zMjMgTmV0d29yay4NDUNh
bGwgRmxvdyAgd2l0aCBILjMyMy1RLjkzMSBpbiBhIFRSSVAgcm91dGUNDUZpZ3VyZSAyIHNob3dz
IElUQURzIElUQUQxIGFuZCBJVEFEMiwgZWFjaCBoYXZpbmcgYSBUUklQIExvY2F0aW9uIFNlcnZl
ci4gVGhlIGdhdGV3YXlzIGluIGVhY2ggSVRBRCByZWdpc3RlciB0aGUgdGVsZXBob255IHByZWZp
eGVzIHRoYXQgdGhleSBjYW4gdGVybWluYXRlIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcgTFMuIElu
IGFkZGl0aW9uLCB0aGUgZ2F0ZXdheXMgYXJlIHNldHVwIHRvIHF1ZXJ5IHRoZSBUUklQIExTIHdo
ZW4gYSBjYWxsIGlzIHRvIGJlIHBsYWNlZC4gV2UgaGF2ZSBhIHNhbXBsZSBjYWxsIGZsb3cgZGVt
b25zdHJhdGVkIGJlbG93LCB3aGVyZSBhIGNhbGwgZnJvbSB0aGUgUFNUTiBpcyBoYW5kbGVkIGJ5
IHF1ZXJ5aW5nIFRSSVAgYnkgdGhlIGdhdGV3YXkuIFRoZSBmb2xsb3dpbmcgYXJlIHRoZSBzdGVw
cyB0YWtlbiB0byByb3V0ZSBhIGNhbGwgaW4gdGhpcyBzY2VuYXJpby4NAQ0NCA1HYXRld2F5IEcz
IGluIElUQUQyIHJlY2VpdmVzIGEgY2FsbCBmb3IgcHJlZml4IDYxOSogZnJvbSB0aGUgUFNUTg1H
MyBxdWVyaWVzIExTMg1MUzIgcmV0dXJucyBhIHJvdXRlIHtOZXh0SG9wOkcxLCBTaWduYWxpbmc6
SDMyMy1ROTMxfQ1HMyBzZW5kcyBhIFEuOTMxIFNFVFVQIG1lc3NhZ2UgdG8gR2F0ZXdheSBHMQ0N
Q2FsbCBGbG93IHdpdGggSDMyMy1SQVMgaW4gYSBUUklQIHJvdXRlDQ1JbiB0aGlzIGNhc2UsIHdl
IGNvbnNpZGVyIGEgdG9wb2xvZ3kgc2ltaWxhciB0byB0aGUgcHJldmlvdXMgY2FzZSwgYnV0IHdp
dGggdGhlIGluY2x1c2lvbiBvZiBHYXRla2VlcGVycyAoIEZpZ3VyZSAzICkuIFRoZSBuZXR3b3Jr
IGNvbnNpc3RzIG9mICAgdHdvIEguMzIzIHpvbmVzLCB3aXRoIElUQUQxIGVuY29tcGFzc2luZyBv
bmUgem9uZSBhbmQgSVRBRDIgZW5jb21wYXNzaW5nIHRoZSBvdGhlci4gRWFjaCB6b25lIGhhcyBh
IGdhdGVrZWVwZXIgdGhhdCBpbnRlcmFjdHMgd2l0aCB0aGUgTG9jYXRpb24gU2VydmVyIGluIGl0
cyBJVEFELiBUaGUgZ2F0ZXdheXMgYXJlIHNldHVwIHRvIGNvbnN1bHQgdGhlIGdhdGVrZWVwZXIg
Zm9yIHJvdXRpbmcgYSBjYWxsLiBJbiB0aGlzIHNhbXBsZSBjYWxsIGZsb3csIHdlIGRlbW9uc3Ry
YXRlIHVzZSBvZiBhIFRSSVAgcm91dGUgdGhhdCBzcGVjaWZpZXMgdXNlIG9mIEgzMjMtUkFTIHRv
IHJlYWNoIHRoZSBuZXh0IGhvcCBzaWduYWxpbmcgcG9pbnQgZm9yIGEgY2FsbCByZWNlaXZlZCBm
cm9tIHRoZSBQU1ROLg0BDQ1HYXRld2F5IEczIGluIElUQUQyIHJlY2VpdmVzIGEgY2FsbCBmb3Ig
cHJlZml4IDYxOSogZnJvbSB0aGUgUFNUTg1HMyBzZW5kcyBhbiBBUlEgdG8gR0syDUdLMiBzZW5k
cyBhIFRSSVAgUXVlcnkgdG8gTFMyDUxTMiByZXR1cm5zIGEgcm91dGUge05leHRIb3A6R0sxLCBT
aWduYWxpbmc6SDMyMy1SQVN9DUdLMiBzZW5kcyBhIFJBUyBMUlEgdG8gR0sxDUdLMSByZXNwb25k
cyB3aXRoIExDRiB3aXRoIElQIGFkZHJlc3Mgb2YgR2F0ZXdheSBHMQ1HSzIgc2VuZHMgYW4gQUNG
IHRvIEdhdGV3YXkgRzMgd2l0aCBJUCBhZGRyZXNzIG9mIEdhdGV3YXkgRzENRzMgc2VuZHMgYSBR
LjkzMSBTRVRVUCBtZXNzYWdlIHRvIEdhdGV3YXkgRzENDVRoZSBhYm92ZSBjYWxsIGZsb3dzIHNo
b3cgYSBzdGFuZC1hbG9uZSBUUklQIExTIGluIGVhY2ggSVRBRC4gSG93ZXZlciwgaXQgaXMgcG9z
c2libGUgdG8gaGF2ZSBhIFRSSVAgTFMgY28tbG9jYXRlIHdpdGggYW4gSC4zMjMgZ2F0ZWtlZXBl
ci4NDRMgUEFHRSAUNxUNDSpDb250YWN0OiAHUmFqbmVlc2ggS3VtYXINVGVsIDogKzEgNDA4IDUy
NyA2MTQ4DUU6IHJham5lZXNoQGNpc2NvLmNvbQ0HTWFuanVuYXRoIEJhbmdhbG9yZQ1UZWwgOiAr
MSA0MDggNTI3IDgzNjQNRTogbWFuamF4QGNpc2NvLmNvbQ0HRGhhdmFsIFNoYWgNVGVsIDogKzEg
NDA4IDUyNyAwNDM2DUU6IGRoYXZhbEBjaXNjby5jb20NB0h1c3NpZW4gRi4gU2FsYW1hDVRlbCA6
ICsxIDQwOCA1MjcgNzE0Nw1FOiBoc2FsYW1hQGNpc2NvLmNvbQ0HBwlGYXggOiArMSA0MDggNTI3
IDE3MTQNCTE3MCBXIFRhc21hbiBEci4gDQlTYW4gSm9zZSwgQ0EgOTUxMzQNDQ0NAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAQwYAAEQGAABeBgAACQ4AABYOAABrHwAAbB8AAHAfAACN
HwAAmzEAAK0xAAC7NQAAvDUAAB08AABJPAAASjwAABE+AAASPgAAFD4AABU+AADLPgAA8j4AAPM+
AAATQQAAFEEAAApDAAALQwAAEUMAABJDAAATQwAAFEMAABZDAAAXQwAAIEMAABJEAAATRAAAKEQA
ACpEAABQRAAAUkQAAFNEAAAA/fn98/3s/fP98/0A/fP5/eX92P3z1P3N/cbDxrvGALi0uAC4ALgA
/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHNQiBQ0oSAARDShIAAA8wShEA
bUgABG5IAAR1CAEEMEoRAAANA2oAAAAAMEoRAFUIAQ0Dam0vAABDShYAVQgBBzYIgUNKFgAYA2oA
AAAAQ0oWAFUIAW1IAARuSAAEdQgBAA0DauYbAABDShYAVQgBDQNqAAAAAENKFgBVCAEKNQiBNgiB
Q0oWAAAHNQiBQ0oWAARDShYAKQAEAABCBAAAUQQAAG8EAACMBAAAjQQAAI4EAACjBAAApAQAAMIE
AADDBAAA8QQAAPIEAAAJBQAAHQUAACoFAAAkBgAAJQYAAC4GAAAvBgAAQwYAAEQGAABeBgAAXwYA
AJ0HAACeBwAArAoAAK0KAADmDAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA
AAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcA
AAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAA
AAAAAAAA9wAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAA
AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAA
AAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAAABAQAABAAAAyQBYSQB
AAEAAAYPAA3GBgLgEMAhAAAcAAQAAApDAABSRAAA/f0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAEBAABAQLmDAAA5wwAAAgOAAAJDgAAFg4AABcOAADvEAAA8BAAAE4RAABPEQAA
9xIAAPgSAABhFAAAYhQAAPAWAADxFgAAWhcAAFsXAADZHAAA2hwAABIeAAATHgAAaR8AAGofAABr
HwAAbR8AAG4fAABvHwAAcB8AAIwfAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AAAAAAAAAAAAAAABAAAAHYwfAACNHwAAKCMAACkjAAB8JQAAfSUAAEYoAABHKAAAkC0AAJEtAABx
LgAAci4AAHcwAAB4MAAAmTEAAJsxAACsMQAArTEAAC8zAAAwMwAAoDUAAKI1AAC7NQAAvDUAALc2
AAC4NgAAhjgAAIc4AADzOQAA9DkAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
AAAAAAAAAQEAAAEAAAAd9DkAAJ87AACgOwAAHDwAAB08AABJPAAASjwAABE+AAATPgAAFD4AABY+
AABYPgAAZz4AAJ0+AADKPgAAyz4AAPM+AAD0PgAAE0EAABVBAAAWQQAAWEEAAG9BAACNQQAAw0EA
AN5BAAASQgAAT0IAAHxCAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAA
AAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPMAAAAAAAAA
AAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA
8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAAAAAAAAAABQAACiYAC0YDAAUA
AAomAAtGBAAAAQAAABx8QgAAfUIAAAlDAAAKQwAAFUMAABZDAAAhQwAAMEMAAEZDAABcQwAAXUMA
AHFDAACHQwAAm0MAAJxDAACoQwAAvkMAANJDAADTQwAA5UMAAPtDAAAQRAAAEUQAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
7AAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAOIAAAAA
AAAAAAAAAADiAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADiAAAAAAAAAAAA
AAAA4gAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAOIA
AAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAoAAA3GBQABPhwBFiQBSWYBAAAABgAAFiQBSWYBAAAAAAQQAAMkAWEkAQYPAA3G
BgLgEMAhAAABAAAAFhFEAAASRAAAKUQAADxEAABQRAAAUUQAAFJEAABTRAAAWQAAAAAAAAAAAAAA
AFcAAAAAAAAAAAAAAABXAAAAAAAAAAAAAAAAVwAAAAAAAAAAAAAAAFUAAAAAAAAAAAAAAABVAAAA
AAAAAAAAAAAATwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Bg8ADcYGAuAQwCEAAAEAAAABEACmAAAWJAEXJAFJZgEAAAAClmwAAzQBBdYYBgEAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAB5TFAgjWcgAFlP+EA0AL/BK4GigjAAbwAwAAAAAAAAAAAAAAAAAAAAAABrwH
AAAAAAAAAAAAAAAAAAAAAAAGvAcAAAAAAAAAAAAAAAAAAAAAAAa8BwAAAAAAAAAAAAAAAAAAAAAA
BnAIAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8GAQAAAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAA
/wAAAAAAAAD/AAAAABT2AQAAGtYUAAAA/wAAAP8AAAD/AAAA/wAAAP8b1hQAAAD/AAAA/wAAAP8A
AAD/AAAA/xzWFAAAAP8AAAD/AAAA/wAAAP8AAAD/HdYUAAAA/wAAAP8AAAD/AAAA/wAAAP801gYA
AQoDbABh9gMAAAAHIwAKMAExkGgBH7DQLyCw4D0hsKAFIrCgBSOQoAUkkKAFJbAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAADmGwAARABkAAAAAAAAAAIAAAAAAAAAAAAAAAAA3iaOFqwDrAMAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPA8AAAAsgQK8AgAAAABBAAAAAoAAEMAC/AYAAAABEEB
AAAAgQERAAAQvwEAABAA/wEAAAgAAAAQ8AQAAAAAAACAMgAH8FYbAAADBMxGt+NoJ1YaDa6UfRXn
N9j/ADIbAAABAAAARAAAAAAAcAFgIRvwKhsAAMxGt+NoJ1YaDa6UfRXnN9jyegAA/P8AAPz/AAAu
EAEAYgkBABhpYACo8jcA+BoAAAD+eJzMXAl0VEXWrnp1b3WSfkRAZEkQgYSwhS2shiUCiaARZIfR
YXVAUUNkEfDXf0RcUFxAiSj7IrJEAUVBxRARh0WigkNYhHH0BxcgQFBUVpP/e93p7iwN3em2z0mf
852u+u7ybtW7Ve++OulIES6EeqSzEHahpcCnGhCnrxN1RCE+5OgPTp/wj0jRa+w9E9Inpo+ZVNfq
M3i7caXwSqHVMo0x4QmVa6N12agsbJYjkWUI58fo/8jESaPThAizNMVMXCdC6GJtQrsZWpYnQ1ph
OD2tLXQ6mO2IjG4RVQeMTRs9sW7v0VPq9ktPGzlOHHns9JS99+ZP6W5GDPJ4kg5P4Y7re3xWLhpZ
dcfIhMhDvx1QCeH2tDmjs+S6SG71LxksZNEwnL4Nx+iuGCVZ5biOTVo97fATJwzhjIOkZeG0EsLh
usiKMANCxCoS+SJRhNssJNvyRbLN48PlT1a22s6YnFe2PDn9cNF17EXjjdPWYK37GaueEJdVotin
Ooq3VJJ4SiWLYeoO0UENEterUSLfGC9yjCfEGmOOmGGsEmOMLNHDyBWNjNO4u2HyjIyV+2Q3uVmO
lMvkdDlTrpCT5E45QubJXrKK0Ul2MOLlCKOOfM6oKjfA4lujUISrC6KtOidGqbNitsoX2fg+hX4U
XRA9qFBMpDC5hKrK3VRHnqN4WZs7yWTuJR/gEfJlniQ38kx5iJfJS7xZRut9MlGfkUO03ZikGxmz
dA9jtR5jbNUzjP16jXFC5xiXdb5ht12vomwdVJxtmGppe0p1sL2lOtv2qa62y6qbLYa62lKps20C
dbC9Ti1t2RRnO0ZRNhvbbU35su7FJ3Q679ezeatez6v1VzxL5/EkHaaH6BidqDvpaD1QX+IH9SGe
rjfyXP0yr9EP8GadzLt1bT6kz9EPejed0UvovJ5IBboHKVsUadspZbNlK22brZRtlCrQbdV5Ha7O
6G+NH/QG45B+ztitRxibdQdjja5izNV5crreKR/UK+RAPV120iNljO4mw3SszOMw+RWfFus5V8zm
LJHOq0QvniOa8hPCxuPFMRolsmmQeJ3uEBMoWaRSkoihjo77X9WRFUblKHxLycL1kcLz8eSZ4c71
srkcXiLDoQV0c3hsVJSfYQ6/Ts91RdmPcwUIMRDIvMa3Mwbt+D6LtVI8Fms11aTutjCsmfwS8fha
cU5v2sfKs2ZBute2KwKn70ql1qEo5t3bNXXR3iBF6T1Guv3oEn5s7iuXHGfJMdjc/kt7VejXcdhW
pxj9B98lheHZB61WNWNYEVet1C5p+WwoCwu9jcRWOl7DyYcVxdk6LL7yZHEwvOSds5WKO8zrLF3b
dzQd4Z4qjgcbvnwXH/tHHKZ68lyj5OjKPh+qGalFWs0dWpFAQoTFOVeCEC0rjwnv0aaTaCKcWh5L
4/Gwo2Vnr8yzBoLJ4Aqg2tjwnps296pz9a21dqOuJ86Ku8R5kSHzqKRm2Vkofd2TEGQgsGO47hkZ
uute+45a/m67rV2pO3pCfscLZD75uqOls9vb3D6MsVmFyKuy9HO6dEzWvY1VDKsMWUAPywJ+WB5l
a4wZsviVi0fkK4KfoPiQdWWk7nzppdKocBGGJoJi97rMTmb5bOCHz2vta75GuQDzm4XR/Rffn3sZ
pfPjisxatVpatOtZcIh3oO7YIpfyJ8Au6dTw7Bvln3dra3Dd+Xy/5/0on8H8fOqeI6sfaATfsufO
/+YlNytehKGJwJ/c9OUzmNy09oDvMLodGG1tw/8VGG3Y+Du5HVjD0YbVD2YPOIwIchBBPcP7LlWx
IgxNBP7tUtf2GUwmrGHPPDf1e5RruImxHfnoisjqBzrPK9gzzy29ZELFizA0EfiTCb58licTylt9
XSeyhZV7gVR90bhOJmavSQDVpr/XDaTqizVWcj0j+KqvStFz65ty1VRVsKvHYnc/BGxH2+oHmqNm
0XPLqja8VX0VL8LQROC616JMbnlWkS+fweyn1jxPAbcX33OF/6N8VcTyFLEHyELb6gczzxPA7cf3
AuE9EypWhKGJwJ/91JfP4PfTa+8/6XI9LxB29rX/BOK7r1zIH4k6Pn2XvjtZxfJjht/rNIufkXt4
jHTNpNUPND8+KJYfL3jZyypehKGJwJ8M9uUzmL1sPQzjMMJtwDc6sPOaZL2+3BXDOgiScb1VuO7i
EF43kFU1T7/Bqfq9oCsGa24bYGyfYYwp2t8MWk/Jehs10Nu4gV7J1hiTdaA5nAnFurjyLkRwuy67
yipehKGJwJ9V5stnMKtsOEb3IEa3HN+PeBml8+OKrOw50UKerBdymv4HpwNTdfDnRCvZc+eX+D3v
K3kx5me8e46sfqARLGPPnV/hJTcrXoShicCf3PTlM9gnwCyMbiZG+UU5VmCOzqFZ+jmepdM4R1v9
YPaAmbjyLETw9VV2qYoVYWgi8G+XurbPYDIhjT3zfMTvUabxYUSz2B2R1Q90nu9jzzx/7yUTKl6E
oYnAn0zw5TPU50Q5AVZ9OZi1cdZpWwBVn7/XDaTqy9X389d/QdW3v6imWlSummo/qo3jqD4WYod/
Djv8/iBqqr1FNdXyq1R9FS/C0ETgzzmRL5/B7KfWPDfECDOAW9n/UabwcWrIc7ghT+MUtvrBzHN9
XHkekMreM6FiRRiaCPzZT335DPU50U16IqfyHp/7TyC+pR7BY/moT9+l78409uRHe7/X6TRup+dw
de2aSasfaH48yp786ORlL6t4EYYmAn8y2JfPYPayJLvznKifGcw5UZK9vBVDF7vznKi9Gcw5ke/r
BnZO1NpM1d3twVYM1txaz+P+Znmex0n2ZN3P3kD3MxvodqY1xsCfx4l25/N4iOm9Yqh4EYYmAn9W
mS+fwayyfLvznCjBDOycKN6crOPNNP2bPR34K86J2pmeO+//KUw7czHmZ7x7jqx+oBG0Mj133ts5
UcWLMDQR+JObvnwG+wSw3r2jzPKcwiTZc/Td9lm6ljlL/4m21Q9mD7DevW8yvZ8TVbwIQxOBf7vU
tX0Gkwl/Fptn/09h/rQfRjSL3RFZ/UDn+UKxefZ2TlTxIgxNBP5kgi+foT8nCqzqs86JCuzBnBOF
purL1ZfsX/8FVd/oopqqWblqqtGoNqai+ojHDl8LO/zoIGqqEUU1VcJVqr6KF2FoIvDnnMiXz2D2
U2uerXfYWLM8pzCj7Sk81d6QY8yGXNlMYasfzDxb77CNTe/nRBUvwtBE4M9+6stn6M+JlJnKw33u
P4GdE521j+UJPn2XvjuVTU9++H8KU9lsp2PM6to1k1Y/0Pywm5788HZOVPEiDE0E/mSwL5/B7GU2
jLA6YnjS+ktuL+u05C7reYNt5BhvVTGS7zJG8t+METzEGM6DjWE8yIGhaP8d3N2Q/Y0fAsYbd/EE
9CeCnwT5JOhNhM0EYLzh8jeMnwQ/HfInoDcN+tNgNw3204wh4IZANojnAwuAhcZgXgRuMeSLobcI
+gtht8Dt725eC+5tyN6CTiZ0M2GTCdtMYyC4gZD1538B24EdxgDeCW4X5LugtxP6O2C33e1vMB8E
fwDYD51c6ObCJhe2uUY/cH0h68NngHzgLPq/gP8V8l+h9wv0z8Iu3+1vAEs1gAVQCJ0C6BbApgC2
Bcad4HpDdgfXBGqpXhylenO0uhPoA/QF+oHrB5nLX19uCr4J5I2h1wj6DWHXEPaNVCq4VMhu425A
d3U7J6OfAlkKdFKgmwKbZKC7219vHgh+AOT9odcP+n1h1xf2/VRPcD0hu5UfBNKAcaoHp4NLhzwd
eunQHwe7NLe/VH4c3D8h+1/oPAbdR2HzKGwfUyngUiDrznOB14DXVTLPAzcP8nnQmwf912H3mttf
D14DfjWwCjorofsmbN6E7UrVDVxXyG7hT4CtwKfobwP/GeSfQW8b9D+F3Va3v2T+N/ivgb3Q2QPd
PbDZA9s9KglcF8g68QngpOrMeeifAn8a8tPQOwX9POCk219XvgL+MuSXoHcR+hdhdxH2F1VHcB0h
u5mvp5u5GiXyDdSRq1MnrkGdgS5oJ4FLgszlrwvHgW8AeSz0YqAfA7sY2MdQB3AdIGvHnYEuQBK1
51vAdYW8K/RugX4S7Lq4/XXkPuDuhKw3dHpBtxdsesG2F7UF1xay1nwvcB8wltrw/eDuh/x+6N0P
/bGwu8/trz3/D/hHgKnQmQLdybCZDNsplACuFWQt+WXgFWAO+hngMyDPgF4G9OfA7hW3vza8Avwb
wHLoLIPuUtgshe0yagGuOWTx/DGQRc14C/rZ4LMhz4ZeNvS3AFluf634K/BfQv4F9HKgvxt2u2Gf
Q03BNYWsMf8I/ERN+Gf0j0N2HDrHoXscNj8DP5HnpC7C4VmJx3mocQ9HGV2w67k4Ox+jhhzHd8Ay
0OdQLjt/p2FHRWUP4Iyxic7lJvp7nulALrv4dWivAxdps+DhE9BOAPeKAx5+E9qbwFUPs+DhE9FO
BDffAQ+fjXY2uDrhFjx8N7S7gVvugIffgfYOcHERFjz87WjfDi7TgVwuO/Px+l0+woc5XhvaxW2I
UFrZD/OGiA1+17CB/Op8PV1Rl5Rd+arAiv/q/EXKUrXpdmWN5Nq/Or+xSKv4r84trsSvzlv7/tW5
t5blIbDf8UfTvXISbRBPlmvUKbIN5YptxUbt/B8uWwqdl/D9P1zeNSPOeP6Hi63MbB0o8l58tiyu
xGy1aiHqe50tZzQ7/I5mnBnRyBNNmJ8zG36VmY0omtk9xhUVZZTOp/BSMxtRYmbXGlmqk+FPPiUZ
ZfPJ4krMUIL//8UgkBHew3dErqO7K5VnhF3ZjNxL8yv5HuG+Iq3iI7S4EiNsF9oRtqcfzOnqnL08
I7yBVpgrVILpe4SrirSKj9DiSoywbeD/iaI7wpoPtalQqOfjeRPu5Y2gp1rAPYBb1ULUk4tQTy52
IEUtAbcUsmU8VGXyMGC4WsMj1GpgFbASeBPcCshWsMtfOvTGAWnqLdSZb/MDai2wDu314N6B7B1+
Sn3ETwPPADPUh8AHwCZgI7j3IXvP7W+u2syvAhnAHPUxv6KygC1oZ4P7BLKt/Jb6nN8G1qpdvE7t
BHYA24F/gfsMss/c/rZALwv4WO3mzSqHP1JfAF+i/RW4PZDtQU15iPcBucB+dRA4AOwHcsHtg+zf
bn8/qG/4GHAU+D91mL9XR4D/oP0tuP9C9h1qx+OoHY+jdvwZ9eVPwI/AD8AxcEchO+r2Z6fjHAGE
0wkOo5NsozzgFNqnwZ2B7AzXpfNcD6gPxNAfqCN/B35D+xy4XyH7xe0vgS5wK6Al0IIucnO6BFxG
+wq4PyEr4JtJaguJJHRHKuRO4Cx0hDwReonQL/scb0K19USqrrvT91d5Zof7rJbOI3vHQfl94F4f
77PesrdAjccT/SG6rNIduIT2RXAX1AQHLqpJZKMZFEbPUjgQAdgBE5xJzwBPA0+5680a9ApVp5ex
vl+masD1QFVwVWgOkIH2q1SXVlM9WkP1KZNigFi0G4CLo1XASrTfdPtrSe9TC3qPmtMGagbEo90U
XFPaCGwCPqCbaTclUg51BDoBnYEu4JLoc2AX2jvd/m6j/dSTcqkHcCuQAiSDS6YDwEHgEPWnPBpA
p2ggnaZBwGC0h4AbQieBE8Bxt7976DyNoj9oJP1OI4DhaA8DN5QuABfRvkQPUiVOo0geB6QDDwHj
wY0nE7ADEe5se4xq8qNUA28VNfDmUANvEDXwJlETbxS1gCi0o/lpVObPoCqfgar+WeA5tGeCex5V
+/Oo3meiii+bbeOoG6+nUXiHiA4429LJ+V/UzuK7j4//J+It2yZRQzkRmECN5HhqLB+iJg6Mp6bg
4iFrJmcCGIl8AXgR3EuQvQSdF6H/Auyeh73L3yK0FwILwM+HfD705kN/PuwWwH4h8HYR1oJbB9l6
6FhYB/21sFsL+7KzlUmpMg9amRRxld/H+bc2RxXN1k1G+WfrkqppXFS1jAuokCxcVNHGJVXbuKxu
dOBPoDJFGlWoEmACdiACXLhxHRAJVAJc/qKpQEZRISCMKJKAYUSTMmoTofImow7areh3mUC/ydZ0
DvgV7V9kKzorW1K+bAE0R9vlrzP9KDvRT7Ij/QwcR/uE7EwnZRcgCbgF6E//kQPoCHAY+AY4BO6g
7EcHZF+gD9ruszD6Qg6lL4GvgD3AXjmMvpbDgRHASGASbZMP06dyMm0FPkE7G9wWZM4WZNAWZNIW
t79ptEE+Tu/Jf9L7wEa0N8lp9IF8gj6U04En0Z5La+RrtBpYBawE3gS3Qr4KZABzAJe/ZTRPLqX5
wAJgIbBILqPFcjktkW8AK9D+gGbLD2mW/IheAl5E+wVwz8tNNFNuBN5Hu2y25eDqeTQGHiYGnG3f
4X05AcptTN8nm96yLcFsTwlmO2pltqWWZhtqYbZ2oDnazcDFQxZn9gJ6U0PzTmpk9qHGQBOgKRAP
Lh4yl79G5nDoDIPuUNj8nRoAsUAMUB9cfchqm5OBKXSjOZXqmI/QTUBdoB5QH1x9yFz+6pjPQmcG
dJ+BzdMUDUQBtYCa4GpCVtVcDCyh682lVM1cRjeYy6k6UAPtmuBqQubyV818FzrvQHc9bNZRFXMt
VQauQzsSXCRkYeZOYBeFm59ThLmb7GYOmUAltCPBRULm8hdhHobON9A9BJuDZDMPkAYYbQJHkAnz
hAPSPEnG/3d3rbFRVGH07sx8s7O7dyAQECONrJBWWGxLCwICQjAoYEhAREA0IK2NFpBCKQ/L+yGi
IJSHvFEQlZfWR5GHKPh+JIZWSDTRBDTEgMEExQSRH67n29kp091td7vL1tiQQ2+/uT0z55s59965
s3NXXtRU+VsIGsqEmA5EXx3nfGe1P31Z1FFeqmdWJf7V0RVXxXhQbzeFuJDE1bHZLKLN5uO0xSyk
rWZBCFvMiYg9RpvMCSEsMp+ghcAC80mabxYDk1CejNgUbHuKFgM23zSzlKYDpeZ0YBpQAkxF7Cma
hvolwFizjMYAo82Z9JA5C5iN8hzEnsa2cnoYqB2FmwtpKHC/uQCYD8wD5iJWTkNQfzDQzVxMuUCO
uYSyzaXAMpSfQWw5tj1LeYDN5zdX0W1AR3Ml8DzwHLACsWfJj/odAMNcTW5zDelmBbAWWAesR2wD
tm0gD2DzXZVb6W+5ha7JzcAmYCPwImIb6CrwF/CT3EZn5XY6I3cALwEvAzsR24Vtu+hnwOarkXvo
W/k6nZKv0Wn5KrAb5VcQ20U1QDVwRO6lw3IfHZL7gQPAG8CbiFViWyUdBWy+vfIg7ZNVtF++Swfk
O8DbKL+FWCXtBfYAFfI9WiMP0Wp5GDgCHAXeR+wYth2jtUBt2ys/psXAEvkRLZUngOMof4jYB7QI
9RYCk+UnNEl+SsXyM3pSfh5CsfwCsS+x7SuaAkS7oQCqc+UPNFueS3gcE/+uFlsi7mrf0ir0a2oh
RXI3dFf7gjZCz9Beofh3tR3CtXJqV+LN93JMddzVDnswz8wXOTfw3j1aZZUw3P8Ef2yUyrXiK90v
btHjq+wUruVUybG6KvPTrvKiNs/XUxvubYzKr7V+vrHaam98lY+EazlVcqyuyu5pVzlYXdFinTKg
UfMwmeqQFgeVBb74Kg+Ha1kq/SGVHGvhUNmjW++8gL+sxI/CnYGAsP51Fm1FO/xsK65H0peFGdrB
lsfVDo2ab3tAK2v5kzo+gfm2c+FazixwLCILPe0sdLsBWYjsy8cgAX0gvj1GfLe6o9fptvt262dy
K3F7ap+nlBgjddXH0N0lhl7vStzW38VeedvJxRzMxZz/31WYvbXXlfNYrCvQ7dZ8IZ2O44mXbfuq
bDjrsVZh9jhWYY7sD60zH2+dZT4S53HY6yxfV1LXO55a/khWp6d+0T/zlumVRnxPzQ7Xyql9SpLv
5ZjP4amHRgwaOOpedlRA9BO5QF/RQ3SvdVOyXjoHCdlIwk5cQLN0ETnTHZUX3p6pKmKbZ6SeBTi9
xpmJPZ62xy6dPXn6eZzZzp7Sej4lE38kz+uSbkTlKhxxOaXb/e30Sm2bh1FA7fQCSsX9zMUczMWc
zdP9hbTdwzpTcX/srDe1+20lybh/ID3qqdFGJzBGPB2uZbk/U1hPsEbrraLd3zPvrsAd/t539g5c
iN0GtE25PViJlPRHtY8gYwUl3h6swVma5y6gxrUH5e6ldAx/Ve6+J+k5WV69rjUkTUD6r7jS3R5U
iYBrsMo446oSZ1yptAfMxRzMxZzNsz046xqiss5U2oPYWW/q9sBWkkx78KHLUIe5Lov47cHwcC3n
CJtjzhE2mgDrPgOFXmkYYZ/H//1xTOeBjmq6PRUMjlaqFYZXDQa9aiqeYi7mYC7mbJ6e8qk1CutM
xVOxs97UnrKVJOOpX5UKZY7SPwFPzQ3XcnqKYxGe6m17Kh13rd/j98s4pm2Q8F3aPXVJeNWlKuN4
6PuWUvEUczEHczFn8/TUCXWZyjpT8VTsrDe1p2wlyXhqhzpIvUPNccX3VG64ltNTHHN6CgNWq59C
4UbMh8Xqp8ZpVj/VP+33gsFgqVatMLIoGMxK6V6QuZiDuZizeXrqdqpRWGdq/VSsrDe1p2wlyXiK
qELZoCXST23SovspjkV4qqftqXT0U/z23iE+K0ZT9FOFdFI5bzCOq4WUWj/FXMzBXMzZPD11Qr1g
sM5UPBU7603fT1lKkuun9hq/K4k8afxDcT5p5G8vzfdyTHd4aujUstKJ2RmiCzyUITJF+3q9w3zj
HPM1t4T5xuleB9/j/Mlx/6iRQ0cERFcxQGSBua3oIXqBPTeK2y7F+ux+G2WE6jz+m0L745jbsb8Z
RTNmFJdMxZWXCfihoiv22PB+bP8n84zpmHuVV3ev0SPnauqeybrPmLa4h3k7u08mMCPWJVzLOSPG
sVZ1z1hRaTbnudhK9AXr7GUiw+2FlfVMcXODeW/onYk2yoo6R2HlnWP/Zd67G2XaAvd6pTF5b2X0
0Ha6TyXwnYe7w7WcTuFYHaeMGjjIn5eBnPYV/UK9TWK9TDJqO3k2m1ONw416nuvyjDUrjCsJPM9d
H67lVMuxKLX5TaN2gueIb78xuFFvgtztmeP7xlge9Y6N/T3JH4T0NvRWywHpzb7+VosnKkvVRnTr
wzGnC+4rfmJmaZFfdA+NQHLghUzkqv4WtNrY7XBWVphzt97awZnn7xOytX/4tKLSiWUwGY9tMoBe
OBP+0Kz3wPC+Aohbe07MeZZWEcqkEP8CqU0JKocTAABEAGQAAAAAAAAAAgAAAAAAAAAAAAAAAACe
JAEW6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8DwAAACyBArwCAAAAAIE
AAAACgAAQwAL8BgAAAAEQQIAAACBAREAABC/AQAAEAD/AQAACAAAABDwBAAAAAEAAIAyAAfw9xIA
AAMETXI2UbT3JOEVcYhklUFKK/8A0xIAAAEAAAAqHAAAAABwAWAhG/DLEgAATXI2UbT3JOEVcYhk
lUFKK1xVAAD+/wAA//8AAEAPAQAqCQEAWNRaAICUNgCZEgAAAP54nN1cCXhUVbI+92y3u09nYQlb
EmyRNQKSDQKGsAgKGiIoyKafjxmTiAKBBAREERQzuKKBEdGAgqIOM6hsMy6gIOrTeYyi4jh+M/oY
HrjME8SnoOMIef+53Z1e0qRvd9t+GZvvp8+tU7duVZ2qOku62yBOQtjTOQTv0iB4tQW6yzTSmTTg
xa3riVXV16SSMdN/WV1VU1Ux16OvBeiKNjScbtAtNz3XOTwtC61/0c0NxHrdZ8njQ0nr8dNnltd4
ysrney6rmjltFvnrTUfn76/8cv7MNFc6IS7CwdcH3FoSNfRtuuWkhATT0n2atbM0I+RUg356Q8NZ
En0mIQ5fv/T16+vvqSCGVx3fUwwCVvIDDaVS6zmmoa+kJac7obhTU7mh7/DeRYgl2ncXI268d2Uc
nJRkSg23aRC3GZDhl2ek67ZXJ++TtSSvHO57jvLZ211qY/V4dGVLSQqj5AhlZBc1yQPUTWbTtuRi
2pl0oznEoAPJR8Zo8qIxlawxqsgCYxmZbNSTQcYOkm3sJ8T4ghwhLmMf6WVsIxejZ4ZRS1YY1WSb
cTX50CiDc0tIT9qPjKNdyY20E9lIW5F3qIucgudy8ORJzCC1eN/OBDnEXCSNtyLFvBOp5F1JHe9H
dvIScoSXkRRxNckX1WSyqCWLRT1ZL7aRvWIfOSyOECaJcbbMNgbLQcYkOdmYIxcYy+UaY5180dgi
PzL2SoMekN3oIXkxPSZn0+/kA5SYu6gwj1CnmcJcZiFzmlcxYS5jxNzEvpP72TF5gh2SHfkBOZjv
lVfzLXIpXyc38OVyD58jD/JJ8hQfLDuJs2WhYLJMHBaVYq9YLNaLVfj/KTFZvCjyxT6RIv4mjvB/
iJ38pKjjRFZypyzm6TKNZ8hDrIPczjrKWrxPYhkyh6XLU9Qp36FEbqQnxY30H2Ic/ZvoSfcJQl8U
HxpPiW3GKrHCWCxmGJXiYqNM9DIKhcvoJL4gp/h+cpDvIHt4PdnAl5GlvIpczaeSwXw06cgHkhMs
h+xnnckm1pYsY25yFTNJIWPW+Le2ooKmd8K7YQjifxkk8ArEGW2M9aax7AyJcHABwy2JPX3x6bDk
eiV7SNOXNwMImQBsaubdq4Ow3o8jV4J10dnUgSuzk9RXwfpEyzivNBEl87QXjMbc9mvglZ0Slock
SHqkZwpfbTBIeI0xGuXIEDmy8cmhdobaIBvlh0tluO5s3duO/69wii5GayO0Nnpb+v4eRkNDJK1l
uG7USzd9Ov1glqQNIZ87QkdJhulohuiyR3ZNXWAwV6gG/sodXq/j1y6TPy6m0C/5dCMW7ZaKTJou
njKiadeWtvFx9bW4UoE8l6Z5IwX5kNbXeVFeMckhXq7AnfQWx6GmFobPTJ+goxps2S5CDojwmSc0
5qQlGQUQ//tjuljUi2LUqHoL9cJP3432btA8UiNAH4H2CNAetxCgv4H2G6D1NDUC9FK0S0H7nfkb
YG0jfT/a+0Hr59AI0MejPR607RYC9L+g/RfQipwaAfqVaF8J2k4La4XXQu0xl8XBSIlYKI7yDaJE
/FH4aa8694kM12PiVeciETzOweMfninxxNYCnsr2smwaS2xN4G/Tw+xKGj22jvi4gmNL00JiKzd6
bDWX7+HxNgHP/wXY7oTKn8cQbz0tz7cmU+gvxWRgEr1GTKTl4gpaYWEirQTtWvRNF1W0WswG5tA5
oprOBqqAWcBM0Gagb4bwy1sKviXALbRGLKZzxc10HnAD2vNBW4C+BeIBulSsBh4E1tAlwC3AYuBm
0G5C36JGeU/RW8WTwBPARnqbeJwuA25Huxa0X6FvudhF7xcvAS/T+8RuugK4F7gHuBu0u9B3V6O8
t8H3FvAnWif20ZXiv+gq4NdoPwDaavStFofpo+II8AnwKX0EWAesBepBexh9DzXKO0nXixPAN8DX
dIP4P/oY8DjaG0F7An1PCsWeFW4ghT0jUtnTwGbgd8BvQduEvk2N8rLBlwVksi2iE9sqOrJtwHa0
d4D2e/T9XuSxl0U+UAAUspdEf7YL2In2i6C9gL7nG+WNYLvFBcBwYBjbI4ayV4C9aL8K2mvoe11c
wt60UMreEGPYf4oy0DTGoL8UfKXgb5rHxeywuJ19LCawp37EnEVPWM66zdNsItZdseTs5/JltkCm
s+g5u8jH1bdxn5Hn0jQWlLOll+eyPNLX9pwQj5XLzDz321KoWKycZn6tjssRKrqVX/u4gq3UtFAr
85JuZTqb5V5Nh8Vk5VF6nvs5ukR5d5i7bO8wl6S5nIEdpoyywzxTfe0DJSiM6YOw/0Q23Wn6620i
e0mzcfYfidVihkvjLTnSfEueaS/Z3N4xWJaWoWVpmf+++whHY1yE7yMy+duynUvbaX8fYfqkOaJ4
PdI+wgzaR4TXPHs7hcDO3wzZKQQsCc8FOzuFzfIDZ7FcZkavBEN8XN5KoHMqz6VpKqgSTBg7Ytj4
kZ6CfkU5pJicB5xPCkg+yUBt0P96xrk2PgFlT4JtK0wZIskZdlABv+j+btgBb3Z0kkWOTBmca8d9
NSV8jWM2zk+DHN+Lf5qZcpDjfBl5fjKb+DRc41bQ9iEwvwbGxSLZ2d9LbOWbHRoVopeoEIlkv5al
ZWhZWubPM/srxdMObWci2R/Z6z919vstiSf7R4oqxwF+rYie/R/4uLzZ343o7Ne0Vk2zv3/uwJze
nqLCopzPIteAjITrwVqw6GL0LlwzTtivB+tFjrhXnitiqwd3y1LxJ9x1t1RnWK82rQeRIyjyGsfh
G8nlbAp9j37VRHboyDpCRrCcZdJvaD8b5xff+ri8I9jKGkFN40EjqIcusZGZhutPoOA/wfRHnuy6
t5CcZn83NLbyhWQrT6TuaVlahpalZf486942fsjQdiZS9yJ7/aeue35L4ql79/PHDA9/jkTPmnN8
XMFZo2nBWaNLXWxZE091WGb+wvm2XC9iqQ7TzHOcx+VBG/X9Kx9XcH3XtOD6PnrW3PLqPtdgrzR9
lmf8ZaPHfpZFepH24M4imbD+XDIE7Q6gZaDiDwD1vJjOq9rSsWawFu0sLTTNDNKiprymZnrVrGoP
nuXBv/Z4bq8mzyEk0h4tHr//YNayi8yNRix+/9C8iF1rHrZRla/3cXktbmtZrGky2O/jh43w5GbB
p+djNs1IaJ8dzdovHJvcAxxvumKx9k3H9e5JDoeN04SpPq5gazWtibV5sVsbPhMNhoEvUO/+ex1L
9kw0Qb5LM1watWyCrGWJzERalpahZWmZP8+Z6FesnUvbmchMFNnrP/VM5LcknpmonH3g/IauknbW
b14ub+50J9712yrZOih3Lh85fsLYQXoF7skvKCwaUJDXFyvvAmsv3h755p2lvO+9Gv+3l1/B/vT/
nSAT02BZ6pPGiZBzOe2DYBsPstaprxm57ug2+rm8Np5l2ahpKUE2XjBtxgxPRVW1tc/ALNMNlrVH
ndAzUJbtnUX4zNODBj+5o/VkTXMGPbmiumqmZ+zl48vwrCxrtsuAX/ta/rU3/4TXqGMoACvAuwUB
fS9r/m8wZoS/+W12P0w3uuuox30B6+kuZV6O4LN24e7DTqhadqH7KpbY3iW0Xpr6M0AkW55NjpNJ
dBL2Lb9xh3I2nTuCY8ItXk/9ih6JGhN2ZrTmNZvP/Wfj9jR7VnZJWcWH2ZjNVvu4vDGTbcWMprmD
YsZjLZQ84+aVVy/M8K2LMhE1GYiZXtbKKbE145ltP056G1Opfya3Z3tv9oJaQIUN2xf5uILXxZoW
vC7Wx4CJ7SZzkR/fQ8E38H59DPv8x9UgPkHlxLjP36su5M+r06xW5XI/rb/qLIapClGj8mzv/cOt
GAkLbgVcsOIws2+FQN4uZ7tZbFbcwR5ho9kr7C520HbGh2s8DsK+BPM10HiDbG42jhx7U8i3xC3H
RY298OeOxXPdeN5oPLciic9tfmWs5Y0e3T9sZfwfcqRqIydEXRnb8e1RxHIFbEyRTWt+qE6p1qgK
3OWW17iOinJ1VIxS2kZ33GfTpdDgM2hwPTRoLZt+RrLlaZgcDYLGukkOplo5GF1mc+u8aFbq5X8B
rBuJ92ERrAzN76az/xBVIoeoQinVAGCoDMz+8fp9lAqMfKVtv49SFbJcDZR+H+nreDW4QAVGfkaE
2Gx5GiZHAzuxGU1mIrGpa8BE/ddrWLkyhgysk7NcE2VvNVGmqzqprxOpAZfhyXnQ4MEzVKmWpWFy
NLBXpZqXmUgkpKuAnzfYtjJdrYc2FT6NVkp9Ha+flQr4+ckIkdDyNEyOBnYiIZrMWCIh1tVXGnkZ
mRjfqq8OXmsV52rT7nPjWfXVyxS15kdY9c33ramGxrSmmo/Vxp1YfQxBhe+NCj8/gTVVtW9NNfIM
q76Wp2FyNPCPNWkSW4EsiiYzkXqq/XwMN/fXfhYxWCnudB3jheoY76LcQl8n4ufPwXy+9rOIHAkt
S8PkaGCnnkaTmXg9bb7+fCraqTaiOmr9iUf2m4KpXHF7VNnho9NFBeLjtO3R6aJOiUL1sfB7Ul/H
Gx/ZKhAfLEIta3kaJkcDOxEcTWYyVwTbSW9jG/81DeVs/gxylKhl+/k7Nr418Z6PK/izyZoW/Nnk
y0ZepAaQ/Agn9PZOIJ1QrT86X8f7eREiyfvy2xfYo/s/RZ/OBvJUVsRT2AALbrQVaC42yIJixbwj
u5R3YmN5JpAFZAOdQevMyoAxQCn3y+vFpvCebDLvAXQHugFdQTuHTQWuRPsqnsdm83w2hxewal4I
9Ed7AGhFrAqYhfbMRnnD2U18GFvEh7Ib+RCgBO3BoA1mNwOLgVv4JayOl7KVfAxQBlwKjAVtHLsf
uA/tFY3yprK1fAqr55OBScBE4ArQrmDrgEeAR3k528Yr2HZeyXbwa4HpaF8H2nVsK7AFeLZR3jz2
Mp/LXuI1bBevBuagPRu0KrYb2IP2K3wxe5/fwv7MlwBLgVuB20C7jR0A3gPebZR3LzvI72H/ze8G
7gLuBO4AbTn7O3AI7f/hq9lJ/iD7lq9h3/GHgIfRrgdtLTsBfIP217zpX1qWMJfYw3LEdkiwWzXi
yacGlhHTmf4qLlU2Hxf1+3dt6Vk+ruB80rSwfGKJ5NMe5j1ZPsATOVnew2LdY+xm3pPl53kiJ8vR
nxvfyfIO3ka+xqLNw9HmHO1bvYL/M49lBb+HueUBdlS8z4+K57i2Mf4V/E7mXcH/lUfeY7Q8DZOj
gZ15OZrMRPYYc7j3ZHkHj+9k+RleIp/hhfIGPgD4MU6Wn+OBkbd/bvscr5Dv84HS7yN9Ha8G23hg
5COdLLc8DZOjgZ3YjCYzkdjUNUCf1q3lsZzb7mF18mM2UWJFIZfwOqmvE6kB+rRuA498stzyNEyO
BvaqVPMyE4mEJTzgZ/vntkv4emhT4dNopdTX8fp5EQ/4OdLJcsvTMDka2ImEaDKTf7Ic36pPnywv
5YmcLCdn1Vcvb+ZrfoRV36e+NdWzMa2pPsVq43usPp5Bha9Hhf80gTXVId+aagePvOpreRomRwM7
J8vRZCZST7Wf9anXEzyWc1toIL5nx/hGfozXcbfQ14n4WZ96/ZZHPllueRomRwM79TSazOSfLNfy
NuJQ1PoT38lyDc8VJ6LKDh+dOh6ID/vntnX8lNjIPxZ+T+rreOPjHh6Ij0gnyy1Pw+RoYCeCo8lM
pJZ95fJ+8vNCRcjXPPZz1xGqgY1Qp9kF6hQbrn5gw9S/LAxFewhoJegrUhm8SLXjA1V7Pkh14OcD
xcBgoAS0EvT55Q1SPcDTHbzdcE9XPgDoDxQCBaAVoK+vKgGG8PPUUN5PDeO5QB6QDxSAVoA+v7x+
aix4LgVvGe4Zw/sAvYFzgRzQctDXVVUAlbybupZ3V9N5D3Ud7wn0QjsHtBz0+eV1VwvBswC883HP
DfwcNY93Ac5G2wOaB32d1ArgPp6p7udZqo5nq5W8M3AW2h7QPOjzy8tSG8CzHryP4p5HeEe1jncA
2qPdDrR26Guttlhoo7bytmobz1DbLbRDuz1oHYCm56QnXE9yoY7BG39I8Jw07HO0YTWI8JPqEhb+
uyjNf5PpI/YHNYPZ+V2UKhb8uyjeX2zStJBfbMq3/2tg8XxXq6fzXleNY3TUKhtsoXBe6lrlWM5C
f3Vzp2UZb+Y3UZamuc4N/CaKecbfRGlLV0N6wDPe7/BpWvB3+C6cXjmvutxD8kl7eKgv6YZ/GWf0
lJZ5Bw/ILPLJvIN3DpKZ5xnkGZWfl99nXN+B+bme6bM807yfvb+sat7c8hzI198OGer7fkgWWhm+
779kQIu+1lUGGUCKicf6tnqxpVkWNLP33Q6vR9MtP/s9qpkuX1gzt3wmmV+VVpHmJnca2ot6PP1t
/5gyi/3/AX/quWlBFgAARABkAAAAAAAAAAIAAAAAAAAAAAAAAAAAniSRFugD6AMAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPA8AAAAsgQK8AgAAAADBAAAAAoAAEMAC/AYAAAABEED
AAAAgQERAAAQvwEAABAA/wEAAAgAAAAQ8AQAAAACAACAMgAH8LEVAAADBKJcMn1JwVx7atMarZ/x
dAv/AI0VAAABAAAAsS8AAAAAcAFgIRvwhRUAAKJcMn1JwVx7atMarZ/xdAsGYwAA/v8AAP//AABA
DwEAZgkBAFjUWgCw+TcAUxUAAAD+eJzcXAl8FEXWr65rZromJBwBSQBHBIQICCGBgCEQERUFJMqt
/tCVJIBAIIDgAYIoIp4EF8UNCijquosoh8fiAV6fuqgIHstvVxcjiK5L1gu8FvP9a86eySTTM+P4
5XP4/Znq169fv1f13qtXNd0xiIsQtrQ3IRlEGgSfVkAXmU46kDp8uPd4XEXl5GZkxNTLKyvmVJTN
9ehjAbqidXU/1+mWm5a7zkhvh9ZPNIM4tCDyLCW+D73wqjlzS2cQ4tScZAXuYxJpaXO0e6ClJVFD
q+GTtKnOJ+BOr2Z8MGkxeuqM0jmekaXzPRdUzLhsJvn7tUfm7yn/z/wZ6WZGSJLhleTy3j8kM8Nv
WWuvZYQcr9Pa19WdCFUyHD7t9HnpP6+Pf6SCGH4zfLKp17r/0nAq897HYegj6ZXThVDi04Mb+grf
VYR4Rfuv4ugBQjoxDk5KsqWG22EQtyMkIyDPyNBtn06+O2tJPjnCfx/lt7eL1Mbq8ezElpA0Rskh
yshz1EFWUzeZRVuRc2kH0pnmEIP2Jx8aw8gO4yKyxqggC4wbyASjmgwwtpP2xh5CjH+TQ8Q0dpNu
xlZyLs5MN5aRO4xKstWYRPYbI9G5RaQr7UVKaCdyNc0iG2lz8g41yXH0XA7uPJ4ZZBm+tzFBaphJ
0nlzcjrPIuW8E6nivcgOXkQO8pHELSaRPqKSTBDLyEJRTdaJreRFsZt8Ig4RKonhke2NQjnAGCcn
GLPkAmO5XGOslTuMJ+SHxkvSoPtkZ1ojz6W1chb9Xq7GMD1HheMQdTnSmOnIZy7HJUw4bmDE8Sj7
Xu5htfIoq5Ft+T45kL8kJ/En5BK+Vm7gy+UuPkse4OPkcV4os4RH5gsqR4pPRLl4USwS68RdYqF4
REwQO0QfsVu4xT/EQf4vsYMfE1WcyHLukqfzDJnOM2UNO0FuY23lMnyPZ5kyh2XI49Ql36FEbqTH
xNX0X6KE/kN0pbsFoTvEfuMRsdW4S9xhLBLTjXJxrjFSdDPyhWlkiX+T43wPOcC3k128mmzgN5Al
vIJM4heRgXwYacv7k6Msh+xhHcijrBW5gbnJJcxB8hnzjn8Lr1fQjCx8G4YggY9BQp+Qn9Ggr9f3
ZVeYh4MLOMMrsavfP51euT7JHlL/44sAQsYAjzby7dNBer+/RKxYddHRdAJXjiypj6z6xIo4nzQZ
I/J0LxjB2A5o4JOdFhGHxCI92j2lPzcYJDLHGEE5MkyOI3jncDvDbXAE5UdKZTju4L22Nf9CuERH
o4URyoOhlr7+FKOuLprWjkjdqI/u9Ov0k6MovYh87gwfJUeEjs4wXXbKTs0WGMwM16ChfJ24dtn8
ATGR1vKpRjzaLRHZNEM8YsTSrhVt6efq6eVqBuSamuaLG8RDepnr7NxCkkN8XKEr6XXOmvoWRs5M
u6BWLU6+C6yX0T3ZEYzRwLGOzPbyJPIlmUi+I265i4Vz1u+FyPvuxH3duN8zYChL4X0bH1Etb9iw
vhEjeqnczlvKV1isEY2MhWh9ewRD8D4uSJORs3qkTnpsO2Hm2sXc8l12RLzHj4inubbRLa13tmoU
S4NnocFn0ODvuKCFrF+XND0NU6OBZazr5T0ts7MNmY1lwVhWzsaFebBuO76Lo1jp+wQ001GLMoOQ
4MyxmRfJzTxfXsn7AYOljyOUN+Lv96d5aOTLbff707xMvsf7y0Af6eNENdjKQyM/PYpvNj0NU6OB
Hd+MJTMZ39Q5YBysWwsBq+KIwCr5ERsnq1G9LuZVUh8nkwMuwJ034IJ7GshSTUvD1GhgL0s1LjMZ
T1jMQ/28wbaVi/l6aFPm12iV1MeJ9vM1PNTPD0fxhKanYWo0sOMJsWTG4wnxVl/p5AVEYmJVXxV6
bYl//FJ130Sqvmq5kK/5Baq+w/6a6vG4aqrDqDZ+RPWxGRm+Ghn+cBI1VY2/ptrOo1d9TU/D1GgQ
GGtSz7dCURRLZjL59LB/bfWQ7mcRh5XiR1bLN/JaXsXdQh8n08+fg/lPup9FdE9oWhqmRgM7+TSW
zOTzaeP557BYxluKmpj5JxHZr4s5vLc4GlN25OhU8ZB//Gx7dKr4cbGRfyQCPamPE/WP23jIP1iU
XNb0NEyNBnY8OJbMZHJZienr58kqmX2iEjPeimGU6dsnGqaS2SeKfd/E9omGqpZyjJlsxaD7Vs/H
ZSqe+bjEdMvJ5hFRqo6Ic5S2MfH5eLjpm4+vUNErhqanYWo0sBNlsWQmE2X6ZzW9TzRUJbZPNEgV
yUEqX0rVD/gl9onOUaGRt78Lc44qk6Wqvwz0kT5OVIMhKjTy0faJmp6GqdHAjm/GkpnsDKDX3j1U
PLswJWaVnGmOk93VOJmhqqQ+TiYH6LV3roq+T9T0NEyNBvayVOMyk/GEDBXqZ/u7MBlqPbQp82u0
SurjRPtZqVA/R9snanoapkYDO54QS2bq94kSq/r0PlFzlcw+UWqqvmqZptb8AlXffH9NNTiummo+
qo0VqD4GIcN3R4afn0RNVemvqYY2UPU1PQ1To4GdfaJYMpPJp/P9a6u+Kp5dGGggVpi1PF/V8o7K
LfRxMv2s17Cnq+j7RE1Pw9RoYCefxpKZ+n2i1qqlqIyZfxLbJ2Kqt7gxpuzI0emoQv5hfxemozou
8tVHItCT+jhR/2ivQv4RbZ+o6WmYGg3seHAsmcnksk9xYSX6tz3idV+Ufg7PsvVXsIWiWhSKR/C/
RrUI0HeivRM0j9QI0c9E+0zQHvQiRH8N7ddA6+rQCNGHoz0ctD97EaLvQXsPaL2cGiH6aLRHg7bN
ixD9b2j/DbQCl0aIfjHaF4P2rBfVIrQCN70cjBSJq8QRvkEUiTdEgPay668i09wgXnZdbdu/EnlW
bT5vxl5k7Wms+LY+qzaGv00Psotp7GfVAlzWZ9U0LexZtd6xn1Vr7PnBSH8bg/v/Dmwr9O8Icfhb
V2/PtyAT6eViAjCeThbjaKkYS8u8GEfLQZuCc1NFBa0Us4DZdLaopLOACmAmMAO06Tg3XQTkLQHf
YuA6OkcsonPFQjoPuBLt+aAtwLkFYjVdIu4G7gHW0MXAdcAiYCFo1+LcNUF5j9DrxcPAQ8BGulQ8
SG8AbkR7GWg34dxy8RxdKZ4HXqB3ip30DuB24DbgVtBuwblbgvLeBt9bwJu0Suymq8Rf6V3A79Fe
DdrdOHe3OEjXiUPAp8Bhej9wH7AWqAbtDzh3b1DeMbpeHAW+Bb6hG8TX9AHgQbQ3gvYQzj0sFHtc
uIE0tlk0Y48Bm4A/A38C7VGcezQorz342gHZ7AmRxbaItmwrsA3t7aA9iXNPilz2gugD5AH57HnR
lz0HPIv2DtD+gnPPBOWdyXaKIcAZQDHbJQazF4GX0H4ZtFdw7lVxHnvdi+HsNTGC/Y8YCZrGCJwf
Dr7h4K8fx4XsoLiRfSTGsEd+wZjFmYiY3cpzxM/seMzfbqwxu5J/wT28kMeO2Y5+rp7B9xZyTU1j
lpgdfmFvlkt62n7GNBErlzoWqbeCKzZ7Vl7mGKS+lHfGfMa3Ff3az2W1UtPCrcxNuZXpbKZ7NS1W
8Vh5hJ7mfpouVpFvrDxX58ttsd9YWZxuukJvrDgafQI6Mr/2gBJU76TA7T+V9d9cCeTbQI2RyLsp
zuDsP9SRJTNNjbfkUMdbsqF3U3zXRX8XxSpLy9CytMz/v+8luIJ+EfleQjZ/W7Y2tZ3230tw+qW5
YvR6tPcSnJb3EiJznr03D7QmVj0Cbx6ELImMhYYqUWuMbJIfuArlDY7YmWCQn6tnMJJyTU1Tlkww
ZtSZxaOHevJ6FeSQQnIacDrJI31IJnKD/tc1wWftj0LZo2DbAlOKJIms1er1iz7fmVGyyZklCwBr
rFlXeOFXB+anAc4fxA8Y2QHOAQ3sfsTeo2oObe8F8ytgXCRSHf3dxBa+yalRJrqJMpFM9GtZWoaW
pWX+NqO/XDzm1HYmE/3Re/3Xjv6AJYlE/1BR4XyXTxGxo/99P5cv+jsTHf2a1rx+9Pft3T+nu6cg
vyDns+g5IDPpfLAWLPon2r3omlHCfj5YL3LE7TJHxJcPbpXniTdx1a3SbKBerZ8PontQ9BrH5R/J
m9hEupd+VU92+Mi6wkawlGXTb2kvG+9DHfNz+UawuXcENY1bRlAPXXIjcxmOP4WCP4DpDZ7qvHcV
+Zl9bGhs4VeRLTyZvKdlaRlalpb528x7W3mNoe1MJu9F7/VfO+8FLEkk763kDxge/jSJHTUd/VzW
qNE0a9ToVBdf1CSSHZY6fud6S64X8WSHyxwnu76UB2zk9wCXNb9rmjW/D5s5t7Syx2SskKbO9Iy+
YNioz9qRbqQNuNuRbFh/KhmE9gmgZSLj9wP1tLj2q1rRUQ6rFq29Wmiaw6LFnNI5c6ZWzKz04F4e
/GuD+3ardx9Coq3REun3nxzL2FmOjUY8/b7fcTab4jhoIytf4efyWdzKa7GmSWu/jy4+09O7Hfr0
dMymmUmts2NZ+4XzUXdf5+tmPNa+7rzCPd7pVLGtnejnslqrafWszY3f2siZaCAM/Av1rb/vY6me
icbIvTTT1FjGxshlLJmZSMvSMrQsLfO3ORPdxFqb2s5kZqLovf5rz0QBSxKZiUrZB65v6V3STv3m
4/LFThfiq9/uki0ssXPh0NFjRg3QFbinT15+Qb+83J6ovPO8a/E2iDffLOX77hb83158Wfsz8DtB
Nn+JvdpsmjHDbc0Xug+sNj7IVjRbbvzRHdvGm/1cPhtP9NqoaWkWG4dcNn26p6yi0rvOwCzTGZa1
QZ7QM1A72yuLyJnni7A7t/XeWdNcljuXVVbM8Iy6cPRI3Kudd7bLRL/29PavvfknMkfVIgFcCN4j
cOjbWeO/wTij/Ob3uXsS/dg9lnZ0D2U57pHMx2Hda3e6e7Cjahk7230pS27tEp4vnZZnhsbT8Vi3
/NEdzll/7rD6hFu82uxLeiimT9iZ0RrWbBt060BnO+PRbBu93Sykm5w2dsT8XD6fae/1GU1zW3zG
4y2UPCXzSiuvyvTXRdnwmkz4TDdv5ZRczdiw7VOMB42x8hkVj+3rHB3T5sqjNmbyBX4ua12sada6
WG8DJrea/Apu/CMUPAtx8g23Hx/B37BUHTtT/cyGqOPsDPVfVqx+8mIw2oNAK8K5ApXJC1Rr3l+1
4QPUCfx0oBAYCBSBVoRzAXkD1Cng6QLezrimE+8H9AXygTzQ8nCupyoCBvHT1GDeSxXz3kAu0AfI
Ay0P5wLyeqlR4DkfvCNxzQjeA+gOnArkgJaDc51UGVDOO6spvIuayk9R03hXoBvaOaDl4FxAXhd1
FXgWgHc+rrmSn6zm8Y7ASWh7QPPgXJa6A7iTZ6uVvJ2q4u3VKt4BOBFtD2genAvIa6c2gGc9eNfh
mvt5W3UfPwFog3Zr0FrjXAv1hBct1RbeSm3lmWqbF63RbgPaCUD9vHTUfJgLVYveeIrbzUuR3jEU
nnE9YMI7DjL7u0AC+XA528mssRN7F+hmdj8bxl5kt7ADtjNppMbvITxrQXseGk+iDWscLdZDVc/r
5tdkv+sh43VzIn1GPWQ0VHcEqqXG6o//GB3VJcZsG78EXurnsv4SqGnWXwLPPi9XFRL7f1Mn3pym
s1qNURxXTttGZ7oJXWgjpzE/l9VCTbNaWHxBCSzsF2XGT3QNRoLPmgTWYHXsmDqXCdWQddHWYB+y
p9R05LrYVs70c1mfNdG0sGdN+iT+d5H0cyVbQCsCw8kJ+/gw9iSZQKcZw1gH2p9PS8rHtxob2EnG
Vzaew+nk57J6gKaF+3hvHo+PR/ZPPk5sAMNHcGveSP9EZq3+/CHjXtc/jfiy1t0uQve7anDlC2F9
+EvWf2+iynqSrJTxROVk4zHnu+TNRtc9Vv4y1xnphNR/OnE3um0faI/BiDIjcE34yJjBEQ6NtUFD
6zkWZhvz92kL3HMlRvyAd32s6Lc/L/5Ot9x0O+yN5y9w+q6I9nc3ueXvbu5LN7vtvfbI/MCzB/o4
9OyB01INx/t3Nz9INwtCklxRK+xoY25GjLlJQj0RXmMfrwtdE02S8vuCGfT2cH81w8Z6FWlPs/0Z
1rpG6xDMuqHo1LRAdI6nm8nwC0qcuaTA9orM6rNf+vcrrOvYAF9kjATo0VaUdv12suHz2+9S6reD
Uuy38K7+Vr/Vx5HelpjfIgJyQpLctv02LcJv00ioJxry27Sokpr5/SKtAb9N+z/228D+mjsJv21s
nnL756kKo6F5yh30xcA8td81zVjAe0fMU+6o85Q7OE9dwzOM/rwnrixpYJ5y25qn3BFj7w7bDTiA
6jEwT7nryY82Ty2gfZ2ENj5PBarHN2XkKGta2JNyQ85y6VHumWDt0Afrho8M3/rh/AZXPPXH5BnU
k2NVBxrfmMxTmbRY1RgFKoembky6G6tpphnPmHRnUm2jJTbWLE/5uaxjomlhFf2Qs7wVfaJj0h3d
lYV7Xmn69ijsjkmJeQk02czjG5NKcxKu6kB74ztA62Vu4iVmLZ+Nb7vjFGnFKxA2lvp2WuLxLL0G
7aRasPiskOpEVgyfLFa0gbX0L+NZA3hgrWjPs/bwXPd4bmeteBGvv1bUNKtnXTD0bNWP9ElqrRjL
wi389zQeC88Ry9ge/o6NtdA+P5fVQk1LxsJIr3NBtb44+Sq+TxON7++5o+zvZbD+vBkr4Gmsnxdu
tBVoJhvghWKFvC07n2exUTwbaAe0BzqA1oGNBEYAw4P7Xd3YRN6VTeCnAF2AzkAn0E5mFwEXo30J
z2WzeB82m+exSp4P9EW7H2gFrAKYifaMoLwz2LW8mF3DB7Or+SCgCO2BoA1kC4FFwHX8PFbFh7NV
fAQwEjgfGAVaCVsJ3In2HUF5F7G1fCKr5hOA8cA4YCxoY9l9wP3AOl7KtvIyto2Xs+18CjAV7Wmg
TWNbgCeAx4Py5rEX+Fz2PJ/DnuOVwGy0Z4FWwXYCu9B+kS9i7/Hr2Pt8MbAEuB5YCtpS9i6wD9gb
lHc7O8BvY//ktwK3ACuAm0Fbzj4GatD+hN/NjvF72Hd8Dfue3wv8Ae1q0Nayo8C3aH8TZb9wMTPF
LpYjtkFCchkj+u/f6f69l8tdb5iPOYexhmLJd5weFlPFrlvMPc7lrKFK118zN1LpLkk3T2240m1F
9/qlW5+L0DTrcxFnTS2fV1nqQTS2ITmYzTrjX2aDcall/u86kfYvmEPN7GSRRTLTWMFKwUPP2MhY
N8gxWCEzTyERMp0RlF9akgq0RRQ84+YIn1GUYQCNjOgBxcTBJEgFaKxMAbz+zwbsLhmgu0hp40L6
RgwMAFDUdd4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAATAAoAAQBpAA8AAwAAAAAAAAAAADgA
AEDx/wIAOAAMAAYATgBvAHIAbQBhAGwAAAACAAAAGABDShgAX0gBBGFKGABtSAkEc0gJBHRICQRS
AAFAAQACAFIADAAJAEgAZQBhAGQAaQBuAGcAIAAxAAAAEAABAAYkAROk8AAUpDwAQCYAHgA1CIFD
SiAAS0ggAE9KAgBRSgIAXAiBXkoCAGFKIAAAAAAAAAAAAAAAAAAAAAAAPABBQPL/oQA8AAwAFgBE
AGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAACwA
H0ABAPIALAAMAAYASABlAGEAZABlAHIAAAANAA8ADcYIAALgEMAhAQIAAAAsACBAAQACASwADAAG
AEYAbwBvAHQAZQByAAAADQAQAA3GCAAC4BDAIQECAAAAJgApQKIAEQEmAAwACwBQAGEAZwBlACAA
TgB1AG0AYgBlAHIAAAAAACgAVUCiACEBKAAMAAkASAB5AHAAZQByAGwAaQBuAGsAAAAGAD4qAUIq
AgAAAABTQAAABQAAWAAAAAD/////AAAAAEIAAABRAAAAbwAAAIwAAACNAAAAjgAAAKMAAACkAAAA
wgAAAMMAAADxAAAA8gAAAAkBAAAdAQAAKgEAACQCAAAlAgAALgIAAC8CAABDAgAARAIAAF4CAABf
AgAAnQMAAJ4DAACsBgAArQYAAOYIAADnCAAACAoAAAkKAAAWCgAAFwoAAO8MAADwDAAATg0AAE8N
AAD3DgAA+A4AAGEQAABiEAAA8BIAAPESAABaEwAAWxMAANkYAADaGAAAEhoAABMaAABpGwAAahsA
AGsbAABtGwAAbhsAAG8bAABwGwAAjBsAAI0bAAAoHwAAKR8AAHwhAAB9IQAARiQAAEckAACQKQAA
kSkAAHEqAAByKgAAdywAAHgsAACZLQAAmy0AAKwtAACtLQAALy8AADAvAACgMQAAojEAALsxAAC8
MQAAtzIAALgyAACGNAAAhzQAAPM1AAD0NQAAnzcAAKA3AAAcOAAAHTgAAEk4AABKOAAAEToAABM6
AAAUOgAAFjoAAFg6AABnOgAAnToAAMo6AADLOgAA8zoAAPQ6AAATPQAAFT0AABY9AABYPQAAbz0A
AI09AADDPQAA3j0AABI+AABPPgAAfD4AAH0+AAAJPwAACj8AABU/AABUQAAAmAAAAA8AAAAAAAAA
AIAAAACAmAAAAAAAAAAAAAAAAIAAAACAmAAAAAAAAAAAAAAAAIAAAACAmAAAAAAAAAAAAAAAAIAA
AACAmAAAAAAAAAAAAAAAAIAAAACAmAAAAAAAAAAAAAAAAIAAAACAmAAAAAAAAAAAAAAAAIAAAACA
mAAAAAAAAAAAAAAAAIAAAACAmAAAAAAAAAAAAAAAAIAAAACAmAAAAAAAAAAAAAAAAIAAAACAmAAA
AAAAAAAAAAAAAIAAAACAmAAAAAAAAAAAAAAAAIAAAACAmAAAAAAAAAAAAAAAAIAAAACAmAAAAAAA
AAAAAAAAAIAAAACACAAAAAEAAAAAAAAAAIAAAACAmAAAAAAAAAAAAAAAAIAdAQAAmAAAAAAAAAAA
AAAAAIAdAQAACAAAAAEAAAAAAAAAAIAAAACAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAA
AIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAl
AgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAA
mAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAA
AAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAA
AAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAA
AAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAA
AIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAl
AgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAA
mAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAA
AAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAA
AAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAA
AAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAA
AIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAl
AgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAA
mAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAA
AAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAA
AAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAA
AAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAAmAAAAAAAAAAAAAAA
AIAlAgAAmAAAAAAAAAAAAAAAAIAlAgAACAAAAAEAAAAAAAAAAIAAAACAmAAAAAAAAAAAAAAAAICi
MQAAmAAAAAAAAAAAAAAAAICiMQAAmAAAAAAAAAAAAAAAAICiMQAAmAAAAAAAAAAAAAAAAICiMQAA
mAAAAAAAAAAAAAAAAICiMQAAmAAAAAAAAAAAAAAAAICiMQAAmAAAAAAAAAAAAAAAAICiMQAAmAAA
AAAAAAAAAAAAAICiMQAAmAAAAAAAAAAAAAAAAICiMQAAmAAAAAAAAAAAAAAAAICiMQAAmAAAAAAA
AAAAAAAAAICiMQAAmAAAAAAAAAAAAAAAAICiMQAAmAAAAAAAAAAAAAAAAICiMQAAmAAAAAAAAAAA
AAAAAICiMQAAmAAAAAAAAAAAAAAAAICiMQAAmAAAAAAAAAAAAAAAAICiMQAAmAAAAAAAAAAAAAAA
AICiMQAAmAAEIAAAAAAAAAAAAICiMQAAmAAEIAAAAQAAAAAAAICiMQAAmAAEIAAAAgAAAAAAAICi
MQAAmAAEIAAAAwAAAAAAAICiMQAAmAAAAAAAAAAAAAAAAICiMQAAmAAAAAAAAAAAAAAAAICiMQAA
mAAAAAAAAAAAAAAAAICiMQAAmAAAAAAAAAAAAAAAAICiMQAAmAAAAAAAAAAAAAAAAICiMQAAmAAA
AAAAAAAAAAAAAICiMQAAmAADIAAAAAAAAAAAAICiMQAAmAADIAAAAQAAAAAAAICiMQAAmAADIAAA
AgAAAAAAAICiMQAAmAADIAAAAwAAAAAAAICiMQAAmAADIAAABAAAAAAAAICiMQAAmAADIAAABQAA
AAAAAICiMQAAmAADIAAABgAAAAAAAICiMQAAmAADIAAABwAAAAAAAICiMQAAmAAAAAAAAAAAAAAA
AIAAAACAmAAAAAAAAAAAAAAAAIAAAACAmAAAAA8wAAAAAAAAAIAAAACAmkAAABAwAAAAAAAAAIAA
AACACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAwAAAAMAAAARwEAAEoBAAAABAAAU0QAACQAAAAABAAA5gwAAIwfAAD0OQAAfEIAABFEAABT
RAAAJQAAACcAAAAoAAAAKQAAACoAAAArAAAAAAQAAFJEAAAmAAAAAAAAAAcAAAAJAAAASgEAABMh
lP+VgA8AAPCYAAAAAAAG8BgAAAACCAAAAgAAAAQAAAABAAAAAQAAAAUAAAAvAAHwWAAAADIAB/Ak
AAAAAwTGqsJBrwOMdPon/vEB2nQj/wA3FwAAAAAAAP////8AAC8BMgAH8CQAAAADBKzk8M/RSh4u
zhFqRosvxJr/APYUAAAAAAAA/////wAALwFAAB7xEAAAAP//AAAAAP8AgICAAPcAABAADwAC8PAA
AAAQAAjwCAAAAAIAAAAEBAAADwAD8I4AAAAPAATwKAAAAAEACfAQAAAAEwAAAAAFAAAFAAAAAAkA
AAIACvAIAAAAAAQAAAUAAAAPAATwVgAAABIACvAIAAAAAwQAAAAKAABDAAvwGAAAAL8BEAAQAMAB
////AMsBuiIAAP8BCAAIABMAIvEGAAAAvwMAAACAAAAQ8AQAAAAAAAAAAAAR8AQAAAACAAAADwAE
8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEA
AQAAABHwBAAAAAEAAAAUOgAAU0AAAAMEAADnGQAAuhMAAGkeAABsFQAAdAAAAAAAAAAAAFwAAABm
AAAAnAEAAKgBAACkAgAAsAIAABADAAAVAwAA8AQAAPwEAADwBgAA9QYAAGEHAABlBwAAlA8AAJkP
AAAEEQAABxEAAJARAACTEQAAZRQAAGoUAAB5FAAAfhQAAPYUAAAGFQAAIBUAAC0VAAC/FQAAwxUA
AMgVAADWFQAADBYAABYWAAB0FgAAgRYAAGAXAABtFwAAQRgAAEYYAABeGAAAaxgAAJ4YAACjGAAA
zBgAANYYAABUHAAAVxwAAMAcAADNHAAAhR8AAJEfAABrIAAAeyAAALokAADEJAAA8yQAAPgkAABB
JQAASyUAAMAlAADFJQAAzSUAANclAAA+JgAAQyYAAH8mAACQJgAA+iYAAP4mAACHKAAAjCgAAMEo
AADOKAAA3isAAOMrAAAJLAAAEywAADEsAAA2LAAAuC0AALstAADMLgAA0S4AAOkuAADuLgAAdjAA
AHkwAAAmMQAAKTEAAFk4AABeOAAACT8AAAo/AAAUPwAAXT8AAGY/AABnPwAAcD8AAJw/AACiPwAA
0z8AANo/AADePwAA5D8AADBAAAA2QAAAUUAAAFRAAAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwACAAcABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwACAAAAAAAJPwAACj8AABQ/AABUQAAAAwAHAAcAAgAAAAAACT8A
AAo/AAAUPwAAVEAAAAMABwAHAAIA//8UAAAACAByAGEAagBuAGUAZQBzAGgAMABDADoAXABUAEUA
TQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAAQQBuAG4AZQB4
ACAATwAgAEYAaQBuAGEAbAAgADIALgBhAHMAZAAIAHIAYQBqAG4AZQBlAHMAaAAWAEQAOgBcAEEA
bgBuAGUAeAAgAE8AIABGAGkAbgBhAGwAIAAyAC4AZABvAGMACAByAGEAagBuAGUAZQBzAGgAFgBE
ADoAXABBAG4AbgBlAHgAIABPACAARgBpAG4AYQBsACAAMgAuAGQAbwBjAAgAcgBhAGoAbgBlAGUA
cwBoABYARAA6AFwAQQBuAG4AZQB4ACAATwAgAEYAaQBuAGEAbAAgADIALgBkAG8AYwAIAHIAYQBq
AG4AZQBlAHMAaAAWAEQAOgBcAEEAbgBuAGUAeAAgAE8AIABGAGkAbgBhAGwAIAAyAC4AZABvAGMA
CAByAGEAagBuAGUAZQBzAGgAFgBEADoAXABBAG4AbgBlAHgAIABPACAARgBpAG4AYQBsACAAMgAu
AGQAbwBjAAgAcgBhAGoAbgBlAGUAcwBoABYARAA6AFwAQQBuAG4AZQB4ACAATwAgAEYAaQBuAGEA
bAAgADIALgBkAG8AYwAIAHIAYQBqAG4AZQBlAHMAaAAwAEMAOgBcAFQARQBNAFAAXABBAHUAdABv
AFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABBAG4AbgBlAHgAIABPACAARgBpAG4A
YQBsACAAMgAuAGEAcwBkAAgAcgBhAGoAbgBlAGUAcwBoADAAQwA6AFwAVABFAE0AUABcAEEAdQB0
AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEEAbgBuAGUAeAAgAE8AIABGAGkA
bgBhAGwAIAAyAC4AYQBzAGQAAwBFAEMAUwA3AEQAOgBcAGQAYQB0AGEAXABNAGEAbgBhAGcAZQBy
AFwAUAByAG8AagBlAGMAdABzAFwAVAByAGkAcABcAGQAbwBjAHMAXABBAG4AbgBlAHgAIABPACAA
RgBpAG4AYQBsACAAMgA1AC4AZABvAGMABABWHnAGNrAkIf8PAAAAAAAAAAAAAAAAAAAAAAEA/H/h
CjawJCH/DwAAAAAAAAAAAAAAAAAAAAABAKEE+lIBAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQDCObF2
DwAJBP8PAAAAAAAAAAAAAAAAAAAAAAEAAQAAAAIAAQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E0AIR
hDD9FcYFAAHQAgZehNACYIQw/W8oAAIAAAAuAAEAAAACAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAP
hNACEYQw/RXGBQAB0AIGXoTQAmCEMP1vKAACAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAL
GAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oBAFFKAQBvKAABALfwAQAAAAAAAQAAAAAAAAAA
AAAAAAAAAAAAABgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/gIAAAAuAAQAAADCObF2AAAAAAAA
AAAAAAAAoQT6UgAAAAAAAAAAAAAAAFYecAYAAAAAAAAAAAAAAAD8f+EKAAAAAAAAAAAAAAAA////
////////////////////BAAAAAAAAAAAAAAA//8EAAAAAAAAAAAAAAAAAAAACj8AABU/AAAWPwAA
IT8AAF0/AACcPwAA0z8AABFAAAASQAAAVEAAAAEAAAAAAAAAAQAAAAgAAAACAQAAAgEAAAIBAAAC
AQAAAgEAAJYBAAH/QACAAQAAAAAAAAAAAHiYdgABAAEAAAAAAAAAAAAAAAAAAAAAAAIQAAAAAAAA
AFNAAABQAAAIAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAA
AAD//wAAAgD//wAAAAD//wAAAgD//wAAAAADAAAARxaQAQAAAgIGAwUEBQIDBId6ACAAAACACAAA
AAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRCQAQIABQUBAgEH
BgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgIC
BId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAACIABAAxCIgYAPDQAgAAaAEAAAAA
lVNLppVTS6YUEEuGAgAAAAAAHgkAAPozAAABABoAAAAEAAMQbgAAACEAAAC/AAAAAQABAAAAAQAA
AAAAAABxIwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgBaAFtAC0AIGBEjAAABAAGQBk
AAAAGQAAANQ/AADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8PgAA
AAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAygxEA8BAA3wMAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAD//xIAAAAAAAAAIgBDAG8AbgB0AHIAaQBiAHUAdABpAG8AbgAgAGYAbwByACAA
UQAxADIALQAxADQALwAxADYAIABNAGUAZQB0AGkAbgBnAAAAAAAAAA0AUABhAHUAbAAgAEUALgAg
AEoAbwBuAGUAcwADAEUAQwBTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuR
CAArJ7PZMAAAAKABAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAADMAAAABAAAANgAAAAFAAAA8AAA
AAYAAAD8AAAABwAAAAgBAAAIAAAAHAEAAAkAAAAoAQAAEgAAADQBAAAKAAAAUAEAAAsAAABcAQAA
DAAAAGgBAAANAAAAdAEAAA4AAACAAQAADwAAAIgBAAAQAAAAkAEAABMAAACYAQAAAgAAAOQEAAAe
AAAAIwAAAENvbnRyaWJ1dGlvbiBmb3IgUTEyLTE0LzE2IE1lZXRpbmcAcx4AAAABAAAAAG9udB4A
AAAOAAAAUGF1bCBFLiBKb25lcwBvch4AAAABAAAAAGF1bB4AAAABAAAAAGF1bB4AAAALAAAATm9y
bWFsLmRvdABlHgAAAAQAAABFQ1MAHgAAAAIAAAAyAFMAHgAAABMAAABNaWNyb3NvZnQgV29yZCA5
LjAAMkAAAAAAAAAAAAAAAEAAAAAAeDmxpUTAAUAAAAAAbgiBZEvAAUAAAAAAbgiBZEvAAQMAAAAB
AAAAAwAAAB4JAAADAAAA+jMAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAA
AAAcAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAjAAAAAYAAACUAAAAEQAAAJwAAAAXAAAApAAA
AAsAAACsAAAAEAAAALQAAAATAAAAvAAAABYAAADEAAAADQAAAMwAAAAMAAAA+wAAAAIAAADkBAAA
HgAAABQAAABDaXNjbyBTeXN0ZW1zLCBJbmMuAAMAAABuAAAAAwAAABoAAAADAAAA1D8AAAMAAACg
CgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAACMAAABDb250cmlidXRp
b24gZm9yIFExMi0xNC8xNiBNZWV0aW5nAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4A
AAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAA
AB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAA
KwAAACwAAAD+////LgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5
AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcA
AABIAAAASQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAP7///9RAAAAUgAAAFMAAABUAAAAVQAA
AFYAAABXAAAAWAAAAFkAAABaAAAAWwAAAFwAAABdAAAA/v///18AAABgAAAAYQAAAGIAAABjAAAA
ZAAAAGUAAAD+////ZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAP7////9////cAAAAP7////+
/////v//////////////////////////////////////////////////////////////////////
//9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAABwyZCg
ZEvAAXIAAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAALQAAAK5FAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgABAAAA//////////8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAAAhRoAAAAAAABXAG8AcgBkAEQAbwBj
AHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQYA
AAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlWAAAAAAA
AAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAXgAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA
bQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAABmAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQIAAAAHAAAA/////wAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0AFAA
bwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA////
////////////AAAAAAAAAAAAAAAAAAAAAAAAAABQ83ygZEvAAVDzfKBkS8ABAAAAAAAAAAAAAAAA
AQAAAP7/////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////8B
AP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoA
AABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
--=====================_26804723==_--


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Nov 17 09:39:00 2000
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 JAA25635
	for <iptel-archive@odin.ietf.org>; Fri, 17 Nov 2000 09:38:59 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3AF9644375; Fri, 17 Nov 2000 08:39:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from NOD.RESTON.MCI.NET (nod.reston.mci.net [166.60.6.38])
	by lists.bell-labs.com (Postfix) with ESMTP id D232544336
	for <iptel@lists.bell-labs.com>; Thu, 16 Nov 2000 21:37:30 -0500 (EST)
Received: from SKOLEM2 ([166.60.6.251])
 by shoe.reston.mci.net (PMDF V5.2-32 #40475)
 with ESMTP id <01JWMHJ3XJU69LVKN9@shoe.reston.mci.net> for
 iptel@lists.bell-labs.com; Thu, 16 Nov 2000 22:37:13 EST
From: Paul Krumviede <paul@mci.net>
In-reply-to: 
 <B65B4F8437968F488A01A940B21982BF4C3CE1@DYN-EXCH-001.dynamicsoft.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Cc: "'stephen.thomas@transnexus.com'" <stephen.thomas@transnexus.com>,
        "'brian.rosen@marconi.com'" <brian.rosen@marconi.com>,
        "'mat@cisco.com'" <mat@cisco.com>, "'jis@mit.edu'" <jis@mit.edu>,
        "'mleech@nortelnetworks.com'" <mleech@nortelnetworks.com>
Message-id: <3740814074.974403422@SKOLEM2>
MIME-version: 1.0
X-Mailer: Mulberry/2.0.5 (Win32)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-disposition: inline
Content-transfer-encoding: 7BIT
Subject: [IPTEL] Re: A plea for help from the iptel working group
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 16 Nov 2000 19:37:02 -0800
Content-Transfer-Encoding: 7BIT

one preliminary note: i'm not on the iptel mailing list, so i won't see
responses, comments, what have you, sent only there...

--On Thursday, 16 November, 2000 20:39 -0500 Jonathan Rosenberg 
<jdrosen@dynamicsoft.com> wrote:

> Folks,
>
> There is only one remaining open issue with TRIP
> http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-03.txt
>
> and it is one that the authors cannot resolve without assistance.
>
> THe issue is authentication for attributes. The authors think that this
> feature is still useful. However, we need to have a set of algorithms, and a
> specific encoding format for those algorithms, to be included in the spec. I
> believe that this authentication encoding will need to include the
> certificate for the signer, since an LS may not have a pre-arranged
> relationship with the originator of a route.

some of the smime work, particularly that on CMS (RFC 2630) would,
in some ways fit the need well (among other things one gets encoding
of the result and some algorithms), but the syntax for using that directly
might be a problem given that a syntax for an authentication attribute
already exists in TRIP.

CMS "describes an encapsulation syntax for data protection." one
nest encapsulations, which in some scenarios can come in handy.

if using the signed-data content type, signer-specific information
is collected into a particular structure, including certificates.
it isn't clear to me if the CMS authenticated-data content type
can be used in this scenario, as it requires encrypting some
keying material (for use with a MAC algorithm) for each recipient,
with the details of the encryption depending on what key management
is being used.

by "encoding format for those algorithms" i'm assuming that
one needs to be able to specify the algorithm(s) as well as
the syntax of the signature and related information (such as
certificates), not just a way to encode which algorithm(s)
were used.

> We need help in coming up with a set of algorithms (we suspect DSA and RSA,
> but need additional guidance on what more, if anything, needs to be said)
> and their encoding, including the certs, within TRIP.

as to algorithms, one issue might be how one wishes to authenticate
an attribute. in particular, should one compute some form of digest,
using something like MD5 or SHA-1, and then sign the digest? RSA
and DSA seem reasonable choices for signature algorithms.

> Actual text for
> inclusion in the draft is specifically what we want, not suggestions like
> "check out protocol foo", since invariably, what protocol foo has isn't
> quite right (i.e., uses ASN.1 or XML or something we don't have).

CMS uses ASN.1. To the extent that an implementation may have
to handle certificates, an implementation would need to support
ASN.1 (unless one wants to consider different approaches, such as the
SPKI/SDSI stuff, but that is likely to have problems). how much of a
problem would ASN.1 be?

> So, this is a PLEA for assistance.
>
> If someone cannot contribute some text here, we may be forced to remove this
> feature all together in the baseline draft, and relegate it to a separate
> I-D. That may or may not go over well with the A-Ds either.

without some better understanding of the constraints, supplying text will
be hard.

-paul


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Nov 17 10:54:01 2000
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 KAA02212
	for <iptel-archive@odin.ietf.org>; Fri, 17 Nov 2000 10:54:01 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 38B7C443A0; Fri, 17 Nov 2000 09:54:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from beluga.telepar.com.br (unknown [200.203.207.190])
	by lists.bell-labs.com (Postfix) with ESMTP id 362814439B
	for <IPTEL@lists.bell-labs.com>; Fri, 17 Nov 2000 09:53:24 -0500 (EST)
Received: by BELUGA with Internet Mail Service (5.5.2650.21)
	id <4QSNPL1W>; Fri, 17 Nov 2000 13:55:38 -0200
Message-ID: <3D98391A7EA2D31192E5000629385A9601A5D48F@correio.telepar.com.br>
From: Luiz Alberto Pasini Melek <pasini@telepar.com.br>
To: "'IPTEL@lists.bell-labs.com'" <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] unsubscribe pasini@telepar.com.br pasini
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 17 Nov 2000 13:55:25 -0200

unsubscribe pasini@telepar.com.br pasini

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Nov 17 12:54:02 2000
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 MAA20559
	for <iptel-archive@odin.ietf.org>; Fri, 17 Nov 2000 12:54:02 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 376D94439B; Fri, 17 Nov 2000 11:54:02 -0500 (EST)
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 829BD44395
	for <iptel@lists.bell-labs.com>; Fri, 17 Nov 2000 11:14:54 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04998;
	Fri, 17 Nov 2000 12:14:44 -0500 (EST)
Message-Id: <200011171714.MAA04998@ietf.org>
To: IETF-Announce: ;
Cc: iptel@lists.bell-labs.com
From: The IESG <iesg-secretary@ietf.org>
Reply-To: iesg@ietf.org
Subject: [IPTEL] Last Call: CPL: A Language for User Control of Internet
 Telephony Services to Proposed Standard
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 17 Nov 2000 12:14:44 -0500


The IESG has received a request from the IP Telephony Working Group to
consider CPL: A Language for User Control of Internet Telephony
Services <draft-ietf-iptel-cpl-04.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by December 1, 2000.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-04.txt


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Nov 17 12:58:04 2000
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 MAA22118
	for <iptel-archive@odin.ietf.org>; Fri, 17 Nov 2000 12:58:04 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BC5D8443AD; Fri, 17 Nov 2000 11:58:01 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from beluga.telepar.com.br (unknown [200.203.207.190])
	by lists.bell-labs.com (Postfix) with ESMTP id 0025344391
	for <iptel@lists.bell-labs.com>; Fri, 17 Nov 2000 11:57:48 -0500 (EST)
Received: by BELUGA with Internet Mail Service (5.5.2650.21)
	id <XC0DVW8F>; Fri, 17 Nov 2000 16:00:05 -0200
Message-ID: <3D98391A7EA2D31192E5000629385A9601A5D493@correio.telepar.com.br>
From: Luiz Alberto Pasini Melek <pasini@telepar.com.br>
To: "'iesg@ietf.org'" <iesg@ietf.org>
Cc: 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] PLEASE UNSUBSCRIBE ME pasini@telepar.com.br
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 17 Nov 2000 15:59:51 -0200

PLEASE UNSUBSCRIBE ME.
pasini@telepar.com.br



-----Mensagem original-----
De: The IESG [mailto:iesg-secretary@ietf.org]
Enviada em: sexta-feira, 17 de novembro de 2000 14:15
Cc: iptel@lists.bell-labs.com
Assunto: [IPTEL] Last Call: CPL: A Language for User Control of Internet
Telephony Services to Proposed Standard



The IESG has received a request from the IP Telephony Working Group to
consider CPL: A Language for User Control of Internet Telephony
Services <draft-ietf-iptel-cpl-04.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by December 1, 2000.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-04.txt


_______________________________________________
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  Tue Nov 21 02:14:02 2000
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 CAA05360
	for <iptel-archive@odin.ietf.org>; Tue, 21 Nov 2000 02:14:02 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B59184438F; Tue, 21 Nov 2000 01:14:02 -0500 (EST)
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 5E6B744336
	for <iptel@lists.bell-labs.com>; Tue, 21 Nov 2000 01:13:30 -0500 (EST)
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 CAA12450
	for <iptel@lists.bell-labs.com>; Tue, 21 Nov 2000 02:15:38 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X207Z8KG>; Tue, 21 Nov 2000 02:11:30 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'iptel@lists.bell-labs.com'" <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] agenda items
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 21 Nov 2000 02:11:28 -0500

Folks,

I had sent out a note a few weeks back encouraging people to submit drafts
to facilitate discussion of future directions for the group. These include
things like intra-domain routing, service routing, CPLng, etc. To date, I
know of only one draft and one agenda slot request as a result of that. If
you submitted a draft and didn't tell me, please do so. Also, if you want a
slot and haven't yet told me, please do so now.

It is likely that our time will be reduced from our current 2.5 hours to
half that. We don't need 2.5 hours (since there will not be a trip or cpl
discussion), and there is a long waiting list for BoFs that could use the
time. 

I am unsure if this will cause the group time to be moved away from its
current Monday morning 9am slot. If it does, I will advise asap.

Finally, I put out a plea for help on TRIP security on the list a while
back. Response was thin, very thin. Once again, if you know anything about
security and TRIP, please contact the authors.

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.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  Tue Nov 21 02:44:58 2000
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 CAA08688
	for <iptel-archive@odin.ietf.org>; Tue, 21 Nov 2000 02:44:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3ACED443A1; Tue, 21 Nov 2000 01:45:02 -0500 (EST)
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 B49D144336
	for <iptel@lists.bell-labs.com>; Tue, 21 Nov 2000 01:44:40 -0500 (EST)
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 CAA12540
	for <iptel@lists.bell-labs.com>; Tue, 21 Nov 2000 02:46:58 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X207Z8K5>; Tue, 21 Nov 2000 02:42:50 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AABFA@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'iptel@lists.bell-labs.com'" <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] TRIP for gateways
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 21 Nov 2000 02:42:48 -0500

Folks,

At the last two meetings, Hussein and I have presented a draft on the usage
of TRIP for gateways. The problem that the draft is trying to address comes
up more and more, and it is becoming urgent that the group come to some kind
of decision regarding this work. We can discuss this at the meeting, of
course, but I'd much prefer to start a list discussion first so we can
identify what the problems are.

As I recall from the last meeting, one of the concerns raised was that BGP
is bad for intra-domain route propagation. Since this is an intra-domain
issue (intra-ITAD in our terminology), TRIP, being a bGP4 equivalent, is ill
suited. I thought about this, and came to the conclusion that intra-domain
route propagation for VoIP is different from IP. I would expect ITADs to
have many LSs, and which routes an LS uses for a particular call is still
very much a policy issue. IP layer intra-domain protocols like OSPF are
simply topology flooding mechanisms. Policy doesn't play a role. You are
always looking to take the least cost route. Not so here; the direction a
call is routed within a domain still depends on administrative policy. So,
it seems that it would be useful to still run TRIP between LS's within an
ITAD.

Another issue raised was that SLP appeared more appropriate than TRIP, as
this was a service advertisement issue (specifically, the gateway would send
out SLP service advertisement messages to the LS). I don't think SLP is
really quite right here. For example, in SLP, service advertisements need to
be refreshed by resending the service template. This would mean that a
gateway would need to periodically resend its entire routing table. Seems
inefficient compared to the much smaller keepalive in TRIP. The smaller
keepalive means that it can be sent more often, resulting in a much more
rapid failure detection.

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.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  Tue Nov 21 03:10:58 2000
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 DAA11573
	for <iptel-archive@odin.ietf.org>; Tue, 21 Nov 2000 03:10:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B51CC4439D; Tue, 21 Nov 2000 02:11:02 -0500 (EST)
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 0ED6B44336
	for <iptel@lists.bell-labs.com>; Tue, 21 Nov 2000 02:10:04 -0500 (EST)
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 DAA12574;
	Tue, 21 Nov 2000 03:12:20 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X207Z8LC>; Tue, 21 Nov 2000 03:08:12 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AABFC@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Rajneesh Kumar'" <rajneesh@cisco.com>, iptel@lists.bell-labs.com
Cc: justinf@cisco.com, manjax@cisco.com, dhaval@cisco.com, hsalama@cisco.com
Subject: RE: [IPTEL] Annex O Contribution
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 21 Nov 2000 03:08:11 -0500

Some comments:

>TRIP introduces a concept of IP Telephony Administrative Domains ( ITADs ).
An ITAD is a 
>set of resources consisting of gateways and at least one TRIP Location
Server (among other 
>VoIP elements ) 

An ITAD need not have gateways. 

>prefixes they terminate can "register" with the TRIP Speaker. Protocol for
such 
>registration is not specified. A RAS like protocol can be used for such
purposes. 

The TRIP-GW draft is another possibility for this.

>which an update traverses for a given route is recorded in an attribute
associated with 
>that route, called the AdvertismentPath.  Each route also has a
"NextHopServer" attribute 
>associated with it.  It signifies the 

AvertisementPath (misspelled above)


You may also want to mention the recent ConvertedRoute attribute, which is
useful for H.323-SIP converters.

In fact, a call flow showing propagation of routes through a SIP-H.323
gateway would be quite useful.

Otherwise, the document is an excellent summary.

Thanks,
Jonthan 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
 

> -----Original Message-----
> From: Rajneesh Kumar [mailto:rajneesh@cisco.com]
> Sent: Thursday, November 16, 2000 9:07 PM
> To: iptel@lists.bell-labs.com
> Cc: justinf@cisco.com; manjax@cisco.com; dhaval@cisco.com;
> hsalama@cisco.com
> Subject: [IPTEL] Annex O Contribution
> 
> 
> FYI .....
> 
> We just submitted a Contribution to ITU SG-16  for Annex O. It has an
> informational section on TRIP.
> Please find the contribution attached.
> 
> 
> Thanks,
> Rajneesh
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 21 12:37:03 2000
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 MAA18384
	for <iptel-archive@odin.ietf.org>; Tue, 21 Nov 2000 12:37:02 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 83134443D2; Tue, 21 Nov 2000 11:37:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from hvmta03-stg.us.psimail.psi.net (hvmta03-ext.us.psimail.psi.net [38.202.36.27])
	by lists.bell-labs.com (Postfix) with ESMTP id 9B69844370
	for <iptel@lists.bell-labs.com>; Tue, 21 Nov 2000 11:36:22 -0500 (EST)
Received: from softwareo ([38.150.216.6]) by hvmta03-stg.us.psimail.psi.net
          (InterMail v4.01.01.00 201-229-111) with SMTP
          id <20001121173613.ZRBI24415.hvmta03-stg@softwareo>;
          Tue, 21 Nov 2000 12:36:13 -0500
Reply-To: <orit@radvision.com>
From: "Orit Levin" <orit@radvision.com>
To: "Rajneesh Kumar" <rajneesh@cisco.com>, <iptel@lists.bell-labs.com>
Cc: <justinf@cisco.com>, <manjax@cisco.com>, <dhaval@cisco.com>,
        <hsalama@cisco.com>
Subject: RE: [IPTEL] Annex O Contribution
Message-ID: <NEBBKDLIKKJGHACMNHPLKEKECHAA.orit@radvision.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
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: <4.1.20001116180251.03b2a7f0@mira-sjc5-4.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 21 Nov 2000 12:36:18 -0500
Content-Transfer-Encoding: 7bit

I would like to inform you that this informational contribution was accepted
to be included into H.323 "Annex O" during the SG-16 ITU-T meeting last week
in Geneva.

Thanks to the authors!
Best Regards,
Orit Levin
Editor, H.323 "Annex O"
RADVision Inc.
TEL: 201.529.4300 x 230
FAX:201.529.3516
mailto:orit@radvision.com
http://www.radvision.com
575 Corporate Drive Suite 420 Mahwah, NJ 07430

-----Original Message-----
From: iptel-admin@lists.bell-labs.com
[mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Rajneesh Kumar
Sent: Thursday, November 16, 2000 9:07 PM
To: iptel@lists.bell-labs.com
Cc: justinf@cisco.com; manjax@cisco.com; dhaval@cisco.com; hsalama@cisco.com
Subject: [IPTEL] Annex O Contribution

FYI .....

We just submitted a Contribution to ITU SG-16  for Annex O. It has an
informational section on TRIP.
Please find the contribution attached.


Thanks,
Rajneesh


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 21 12:59:04 2000
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 MAA23456
	for <iptel-archive@odin.ietf.org>; Tue, 21 Nov 2000 12:59:03 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0A4A7443C4; Tue, 21 Nov 2000 11:59:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31])
	by lists.bell-labs.com (Postfix) with ESMTP id 3FFF444336
	for <iptel@lists.bell-labs.com>; Tue, 21 Nov 2000 11:23:04 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA15022;
	Tue, 21 Nov 2000 10:22:55 -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA06516;
	Tue, 21 Nov 2000 09:22:52 -0800 (PST)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA06968;
	Tue, 21 Nov 2000 09:22:51 -0800 (PST)
Message-Id: <200011211722.JAA06968@nasnfs.eng.sun.com>
From: James Kempf <James.Kempf@Eng.Sun.COM>
Reply-To: James Kempf <James.Kempf@Eng.Sun.COM>
Subject: Re: [IPTEL] TRIP for gateways
To: jdrosen@dynamicsoft.com
Cc: iptel@lists.bell-labs.com, erik.guttman@germany.sun.com,
        James.Kempf@Eng.Sun.COM
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: LHaDbkfgeDWtDdIc2khuJQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 21 Nov 2000 09:22:13 -0800 (PST)

Jonathan,

I'm not on this list, so please cc me in any correspondence. Somebody
forwarded me your comments on using SLP for intradomain gateway
discovery, and I would like to correct a couple of misimpressions.

Specifically:

>Another issue raised was that SLP appeared more appropriate than TRIP, as
>this was a service advertisement issue (specifically, the gateway would send
>out SLP service advertisement messages to the LS). 

No agent in SLP "sends out" unsolicited service advertisements, with
the exception of the Directory Agent (DA). In a properly configured
network, there are very few DAs and a DA should only send unsolicited 
advertisements with a periodicity on the order of hours, if not days. An 
application that wants a service solicits the advertisements in one of two ways:

1) If there are no DAs, the application multicasts, and the services answer with 
their service URL using unicast.

2) If there is a DA, the application unicasts the request to the DA,
which then replies by unicast.

So there is no SLP traffic (and thus no network load) unless an application is 
looking for a service.

>I don't think SLP is
>really quite right here. For example, in SLP, service advertisements need to
>be refreshed by resending the service template. This would mean that a
>gateway would need to periodically resend its entire routing table. 

This is completely false. The service template is never sent anywhere,
it is like the LDAP schema, it merely describes the form of a service
advertisement for a particular service type. A DA can use service templates to 
check whether a service advertisement registered by a service matches, and 
reject it if not. In practice, service templates are not now used by any SLPv2 
implementations with which I am familar. Their exact use is somewhat 
underspecified. This was actually by design, since we did not know exactly 
whether strong type checking (such as LDAP uses) was desirable or not.
In retrospect, from most of the applications we've seen to date, weak
type checking seems like a better solution, so the service type
template is nothing more than a convention (but an important one).

>Seems
>inefficient compared to the much smaller keepalive in TRIP. The smaller
>keepalive means that it can be sent more often, resulting in a much more
>rapid failure detection.
>

Actually, it's MORE efficient. There is absolutely NO keepalive in SLP.
It is only when a query is made that a response is given.

I'm not entirely familiar with your application, but, on the surface,
it sounds to me that SLP would be an entirely appropriate way of
discovering a gateway on an intradomain basis. The kinds of applications
in which it is not the right solution generally involve interdomain
discovery (in which traffic over the Internet is involved) or when
the attributes of a service change rapidly or don't lend themselves
well to being encoded as a finite list of attribute value pairs. In
addition, if there is any service-specific negotation involved in
selecting the service, then a service-specific discovery protocol
may be a better solution.

		jak


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 21 14:10:54 2000
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 OAA06669
	for <iptel-archive@odin.ietf.org>; Tue, 21 Nov 2000 14:10:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 97DE144403; Tue, 21 Nov 2000 13:08:14 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by lists.bell-labs.com (Postfix) with ESMTP id 537C84435F
	for <iptel@lists.bell-labs.com>; Tue, 21 Nov 2000 13:07:38 -0500 (EST)
Received: from fokus.gmd.de (dhcp116 [195.37.78.244])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id UAA08588;
	Tue, 21 Nov 2000 20:07:12 +0100 (MET)
Message-ID: <3A1AC782.3963ADFF@fokus.gmd.de>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Organization: GMD Fokus
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: CPLng (was [IPTEL] agenda items)
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 21 Nov 2000 20:05:38 +0100
Content-Transfer-Encoding: 7bit

Jonathan,

I would like to see three CPL extensions:
- authentication support -- useful if signaling depends
  on user credentials
- access to external databases -- useful with long shared lists
- support for usage of CPL in end-devices -- useful if CPL services 
  are stored at a SIM card which the users put into different cell
  phones  (we already had this on the list, a solution could look 
  like <ring user_profile="ring_and_shake">)

I submitted a tiny I-D on the first two issues. Its main purpose
is to stimulate a discussion on whether these extensions are
considered needed, though some examples on how it could 
look like are also attached.

Until it appears in the I-D directory, it is available at
http://www.fokus.gmd.de/glone/employees/jiri.kuthan/draft-kuthan-iptel-cpl-auth-00.txt

Jiri

Jonathan Rosenberg wrote:
> 
> Folks,
> 
> I had sent out a note a few weeks back encouraging people to submit drafts
> to facilitate discussion of future directions for the group. These include
> things like intra-domain routing, service routing, CPLng, etc. To date, I
> know of only one draft and one agenda slot request as a result of that. If
> you submitted a draft and didn't tell me, please do so. Also, if you want a
> slot and haven't yet told me, please do so now.

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 21 15:44:59 2000
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 PAA25197
	for <iptel-archive@odin.ietf.org>; Tue, 21 Nov 2000 15:44:59 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 65661443D8; Tue, 21 Nov 2000 14:45:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by lists.bell-labs.com (Postfix) with ESMTP id 6B4B2443FA
	for <iptel@lists.bell-labs.com>; Tue, 21 Nov 2000 13:20:51 -0500 (EST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id LAA00046;
	Tue, 21 Nov 2000 11:20:38 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA07624; Tue, 21 Nov 2000 11:20:38 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14874.51974.617108.616280@thomasm-u1.cisco.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>,
        "'stephen.thomas@transnexus.com'" <stephen.thomas@transnexus.com>,
        "'brian.rosen@marconi.com'" <brian.rosen@marconi.com>,
        "'paul@mci.net'" <paul@mci.net>, "'mat@cisco.com'" <mat@cisco.com>,
        "'jis@mit.edu'" <jis@mit.edu>,
        "'mleech@nortelnetworks.com'" <mleech@nortelnetworks.com>
In-Reply-To: <B65B4F8437968F488A01A940B21982BF4C3CE1@DYN-EXCH-001.dynamicsoft.com>
References: <B65B4F8437968F488A01A940B21982BF4C3CE1@DYN-EXCH-001.dynamicsoft.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Subject: [IPTEL] A plea for help from the iptel working group
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 21 Nov 2000 11:20:38 -0800 (PST)
Content-Transfer-Encoding: 7bit


Jonathan,

Maybe this is irrelevant since the draft deadline
passed, but I predictably am in favor of avoidance
of problems that cry out for public key solutions
unless there is some absolute and unavoidable
reason why they are necessary. If this were BGP,
I would be *very* concerned about the implications
of the number of public key signatures and
verifies. However, TRIP is not BGP, so it's hard
for me to guage whether it's unavoidable or not.

Maybe it really would be the better part of valor
to leave it out until we have some operational
experience?

			Mike

Jonathan Rosenberg writes:
 > Folks,
 > 
 > There is only one remaining open issue with TRIP
 > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-03.txt
 > 
 > and it is one that the authors cannot resolve without assistance.
 > 
 > THe issue is authentication for attributes. The authors think that this
 > feature is still useful. However, we need to have a set of algorithms, and a
 > specific encoding format for those algorithms, to be included in the spec. I
 > believe that this authentication encoding will need to include the
 > certificate for the signer, since an LS may not have a pre-arranged
 > relationship with the originator of a route.
 > 
 > We need help in coming up with a set of algorithms (we suspect DSA and RSA,
 > but need additional guidance on what more, if anything, needs to be said)
 > and their encoding, including the certs, within TRIP. Actual text for
 > inclusion in the draft is specifically what we want, not suggestions like
 > "check out protocol foo", since invariably, what protocol foo has isn't
 > quite right (i.e., uses ASN.1 or XML or something we don't have). 
 > 
 > So, this is a PLEA for assistance. 
 > 
 > If someone cannot contribute some text here, we may be forced to remove this
 > feature all together in the baseline draft, and relegate it to a separate
 > I-D. That may or may not go over well with the A-Ds either.
 > 
 > 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.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  Tue Nov 21 18:34:57 2000
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 SAA25184
	for <iptel-archive@odin.ietf.org>; Tue, 21 Nov 2000 18:34:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 03B97443F1; Tue, 21 Nov 2000 17:35:02 -0500 (EST)
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 F3BAD4435F
	for <iptel@lists.bell-labs.com>; Tue, 21 Nov 2000 17:34:33 -0500 (EST)
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 SAA21002;
	Tue, 21 Nov 2000 18:36:44 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X207Z0DA>; Tue, 21 Nov 2000 18:32:35 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAC14@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Michael Thomas'" <mat@cisco.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>,
        "'stephen.thomas@transnexus.com'" <stephen.thomas@transnexus.com>,
        "'brian.rosen@marconi.com'" <brian.rosen@marconi.com>,
        "'paul@mci.net'" <paul@mci.net>, "'jis@mit.edu'" <jis@mit.edu>,
        "'mleech@nortelnetworks.com'" <mleech@nortelnetworks.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] RE: A plea for help from the iptel working group
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 21 Nov 2000 18:32:34 -0500

I'm personally okay with that. 

I think that TRIP is sufficiently close to BGP in this regard, that the
security that works there should  work here too.

-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
 

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Tuesday, November 21, 2000 2:21 PM
> To: Jonathan Rosenberg
> Cc: 'iptel@lists.bell-labs.com'; 'stephen.thomas@transnexus.com';
> 'brian.rosen@marconi.com'; 'paul@mci.net'; 'mat@cisco.com';
> 'jis@mit.edu'; 'mleech@nortelnetworks.com'
> Subject: A plea for help from the iptel working group
> 
> 
> 
> Jonathan,
> 
> Maybe this is irrelevant since the draft deadline
> passed, but I predictably am in favor of avoidance
> of problems that cry out for public key solutions
> unless there is some absolute and unavoidable
> reason why they are necessary. If this were BGP,
> I would be *very* concerned about the implications
> of the number of public key signatures and
> verifies. However, TRIP is not BGP, so it's hard
> for me to guage whether it's unavoidable or not.
> 
> Maybe it really would be the better part of valor
> to leave it out until we have some operational
> experience?
> 
> 			Mike
> 
> Jonathan Rosenberg writes:
>  > Folks,
>  > 
>  > There is only one remaining open issue with TRIP
>  > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-03.txt
>  > 
>  > and it is one that the authors cannot resolve without assistance.
>  > 
>  > THe issue is authentication for attributes. The authors 
> think that this
>  > feature is still useful. However, we need to have a set of 
> algorithms, and a
>  > specific encoding format for those algorithms, to be 
> included in the spec. I
>  > believe that this authentication encoding will need to include the
>  > certificate for the signer, since an LS may not have a pre-arranged
>  > relationship with the originator of a route.
>  > 
>  > We need help in coming up with a set of algorithms (we 
> suspect DSA and RSA,
>  > but need additional guidance on what more, if anything, 
> needs to be said)
>  > and their encoding, including the certs, within TRIP. 
> Actual text for
>  > inclusion in the draft is specifically what we want, not 
> suggestions like
>  > "check out protocol foo", since invariably, what protocol 
> foo has isn't
>  > quite right (i.e., uses ASN.1 or XML or something we don't have). 
>  > 
>  > So, this is a PLEA for assistance. 
>  > 
>  > If someone cannot contribute some text here, we may be 
> forced to remove this
>  > feature all together in the baseline draft, and relegate 
> it to a separate
>  > I-D. That may or may not go over well with the A-Ds either.
>  > 
>  > 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.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  Tue Nov 21 21:12:42 2000
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 VAA16204
	for <iptel-archive@odin.ietf.org>; Tue, 21 Nov 2000 21:12:42 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C5DC744447; Tue, 21 Nov 2000 20:02:02 -0500 (EST)
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 E198044447
	for <iptel@lists.bell-labs.com>; Tue, 21 Nov 2000 20:01:08 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA07515;
	Tue, 21 Nov 2000 20:39:01 -0500 (EST)
Message-ID: <3A1B23B5.20B3A370@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Michael Thomas'" <mat@cisco.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>,
        "'stephen.thomas@transnexus.com'" <stephen.thomas@transnexus.com>,
        "'brian.rosen@marconi.com'" <brian.rosen@marconi.com>,
        "'paul@mci.net'" <paul@mci.net>, "'jis@mit.edu'" <jis@mit.edu>,
        "'mleech@nortelnetworks.com'" <mleech@nortelnetworks.com>
Subject: Re: [IPTEL] RE: A plea for help from the iptel working group
References: <B65B4F8437968F488A01A940B21982BF9AAC14@DYN-EXCH-001.dynamicsoft.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 21 Nov 2000 20:39:01 -0500
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> I'm personally okay with that.
> 
> I think that TRIP is sufficiently close to BGP in this regard, that the
> security that works there should  work here too.

It is also not clear that just signing or otherwise authenticating
requests is particularly helpful. If flybynight.com advertises 1c to
anywhere in the world, they may well have a certificate proving that
they are indeed flybynight.com. Thus, I suspect that people will limit
who they listen to, apply some sanity checks to catch errors (which no
amount of signing and crypto can prevent) and use TLS or IPsec to secure
the peer relationships if they are worried about the links. (Since most
of the information is at least semi-public, it's not even clear that
this is particularly urgent.)


> > Maybe this is irrelevant since the draft deadline
> > passed, but I predictably am in favor of avoidance
> > of problems that cry out for public key solutions
> > unless there is some absolute and unavoidable
> > reason why they are necessary. If this were BGP,
> > I would be *very* concerned about the implications
> > of the number of public key signatures and
> > verifies. However, TRIP is not BGP, so it's hard
> > for me to guage whether it's unavoidable or not.
> >
> > Maybe it really would be the better part of valor
> > to leave it out until we have some operational
> > experience?
> >
> >                       Mike
> >
> > Jonathan Rosenberg writes:
> >  > Folks,
> >  >
> >  > There is only one remaining open issue with TRIP
> >  > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-03.txt
> >  >
> >  > and it is one that the authors cannot resolve without assistance.
> >  >
> >  > THe issue is authentication for attributes. The authors
> > think that this
> >  > feature is still useful. However, we need to have a set of
> > algorithms, and a
> >  > specific encoding format for those algorithms, to be
> > included in the spec. I
> >  > believe that this authentication encoding will need to include the
> >  > certificate for the signer, since an LS may not have a pre-arranged
> >  > relationship with the originator of a route.
> >  >
> >  > We need help in coming up with a set of algorithms (we
> > suspect DSA and RSA,
> >  > but need additional guidance on what more, if anything,
> > needs to be said)
> >  > and their encoding, including the certs, within TRIP.
> > Actual text for
> >  > inclusion in the draft is specifically what we want, not
> > suggestions like
> >  > "check out protocol foo", since invariably, what protocol
> > foo has isn't
> >  > quite right (i.e., uses ASN.1 or XML or something we don't have).
> >  >
> >  > So, this is a PLEA for assistance.
> >  >
> >  > If someone cannot contribute some text here, we may be
> > forced to remove this
> >  > feature all together in the baseline draft, and relegate
> > it to a separate
> >  > I-D. That may or may not go over well with the A-Ds either.
> >  >
> >  > 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.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

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 22 00:10:59 2000
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 AAA11532
	for <iptel-archive@odin.ietf.org>; Wed, 22 Nov 2000 00:10:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 372C54433B; Tue, 21 Nov 2000 23:11:02 -0500 (EST)
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 D957C44339
	for <iptel@lists.bell-labs.com>; Tue, 21 Nov 2000 23:10:15 -0500 (EST)
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 AAA22213;
	Wed, 22 Nov 2000 00:12:22 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X207Z0LJ>; Wed, 22 Nov 2000 00:08:12 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAC19@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Michael Thomas'" <mat@cisco.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>,
        "'stephen.thomas@transnexus.com'" <stephen.thomas@transnexus.com>,
        "'brian.rosen@marconi.com'" <brian.rosen@marconi.com>,
        "'paul@mci.net'" <paul@mci.net>, "'jis@mit.edu'" <jis@mit.edu>,
        "'mleech@nortelnetworks.com'" <mleech@nortelnetworks.com>
Subject: RE: [IPTEL] A plea for help from the iptel working group
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 22 Nov 2000 00:08:11 -0500

I think we are going to move forward with that plan. Given that we are not
sure we need it, not sure how to do it, and can't locate expertise to help
us, it seems like the right thing. We can add support for this later, I
think, if the need arises.

-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
 

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Tuesday, November 21, 2000 2:21 PM
> To: Jonathan Rosenberg
> Cc: 'iptel@lists.bell-labs.com'; 'stephen.thomas@transnexus.com';
> 'brian.rosen@marconi.com'; 'paul@mci.net'; 'mat@cisco.com';
> 'jis@mit.edu'; 'mleech@nortelnetworks.com'
> Subject: [IPTEL] A plea for help from the iptel working group
> 
> 
> 
> Jonathan,
> 
> Maybe this is irrelevant since the draft deadline
> passed, but I predictably am in favor of avoidance
> of problems that cry out for public key solutions
> unless there is some absolute and unavoidable
> reason why they are necessary. If this were BGP,
> I would be *very* concerned about the implications
> of the number of public key signatures and
> verifies. However, TRIP is not BGP, so it's hard
> for me to guage whether it's unavoidable or not.
> 
> Maybe it really would be the better part of valor
> to leave it out until we have some operational
> experience?
> 
> 			Mike
> 
> Jonathan Rosenberg writes:
>  > Folks,
>  > 
>  > There is only one remaining open issue with TRIP
>  > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-03.txt
>  > 
>  > and it is one that the authors cannot resolve without assistance.
>  > 
>  > THe issue is authentication for attributes. The authors 
> think that this
>  > feature is still useful. However, we need to have a set of 
> algorithms, and a
>  > specific encoding format for those algorithms, to be 
> included in the spec. I
>  > believe that this authentication encoding will need to include the
>  > certificate for the signer, since an LS may not have a pre-arranged
>  > relationship with the originator of a route.
>  > 
>  > We need help in coming up with a set of algorithms (we 
> suspect DSA and RSA,
>  > but need additional guidance on what more, if anything, 
> needs to be said)
>  > and their encoding, including the certs, within TRIP. 
> Actual text for
>  > inclusion in the draft is specifically what we want, not 
> suggestions like
>  > "check out protocol foo", since invariably, what protocol 
> foo has isn't
>  > quite right (i.e., uses ASN.1 or XML or something we don't have). 
>  > 
>  > So, this is a PLEA for assistance. 
>  > 
>  > If someone cannot contribute some text here, we may be 
> forced to remove this
>  > feature all together in the baseline draft, and relegate 
> it to a separate
>  > I-D. That may or may not go over well with the A-Ds either.
>  > 
>  > 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.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
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 22 00:17:57 2000
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 AAA12325
	for <iptel-archive@odin.ietf.org>; Wed, 22 Nov 2000 00:17:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 72A094442E; Tue, 21 Nov 2000 23:18:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id BA35844339
	for <iptel@lists.bell-labs.com>; Tue, 21 Nov 2000 23:17:54 -0500 (EST)
Received: from mira-sjc5-5.cisco.com (mira-sjc5-5.cisco.com [171.71.163.22])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id VAA28448;
	Tue, 21 Nov 2000 21:17:36 -0800 (PST)
Received: from dhaval-nt2.cisco.com ([64.104.42.95])
	by mira-sjc5-5.cisco.com (Mirapoint)
	with ESMTP id AAL00377;
	Tue, 21 Nov 2000 21:16:57 -0800 (PST)
Message-Id: <4.3.2.7.2.20001121211430.00c80de0@mira-sjc5-5.cisco.com>
X-Sender: dhaval@mira-sjc5-5.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'Michael Thomas'" <mat@cisco.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
From: Dhaval Shah <dhaval@cisco.com>
Subject: RE: [IPTEL] A plea for help from the iptel working group
Cc: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>,
        "'stephen.thomas@transnexus.com'" <stephen.thomas@transnexus.com>,
        "'brian.rosen@marconi.com'" <brian.rosen@marconi.com>,
        "'paul@mci.net'" <paul@mci.net>, "'jis@mit.edu'" <jis@mit.edu>,
        "'mleech@nortelnetworks.com'" <mleech@nortelnetworks.com>
In-Reply-To: <B65B4F8437968F488A01A940B21982BF9AAC19@DYN-EXCH-001.dynami
 csoft.com>
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 21 Nov 2000 21:14:42 -0800

I second that.

Thanx,
Dhaval

At 12:08 AM 11/22/2000 -0500, Jonathan Rosenberg wrote:
>I think we are going to move forward with that plan. Given that we are not
>sure we need it, not sure how to do it, and can't locate expertise to help
>us, it seems like the right thing. We can add support for this later, I
>think, if the need arises.
>
>-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
> 
>
>> -----Original Message-----
>> From: Michael Thomas [mailto:mat@cisco.com]
>> Sent: Tuesday, November 21, 2000 2:21 PM
>> To: Jonathan Rosenberg
>> Cc: 'iptel@lists.bell-labs.com'; 'stephen.thomas@transnexus.com';
>> 'brian.rosen@marconi.com'; 'paul@mci.net'; 'mat@cisco.com';
>> 'jis@mit.edu'; 'mleech@nortelnetworks.com'
>> Subject: [IPTEL] A plea for help from the iptel working group
>> 
>> 
>> 
>> Jonathan,
>> 
>> Maybe this is irrelevant since the draft deadline
>> passed, but I predictably am in favor of avoidance
>> of problems that cry out for public key solutions
>> unless there is some absolute and unavoidable
>> reason why they are necessary. If this were BGP,
>> I would be *very* concerned about the implications
>> of the number of public key signatures and
>> verifies. However, TRIP is not BGP, so it's hard
>> for me to guage whether it's unavoidable or not.
>> 
>> Maybe it really would be the better part of valor
>> to leave it out until we have some operational
>> experience?
>> 
>>                       Mike
>> 
>> Jonathan Rosenberg writes:
>>  > Folks,
>>  > 
>>  > There is only one remaining open issue with TRIP
>>  > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-03.txt
>>  > 
>>  > and it is one that the authors cannot resolve without assistance.
>>  > 
>>  > THe issue is authentication for attributes. The authors 
>> think that this
>>  > feature is still useful. However, we need to have a set of 
>> algorithms, and a
>>  > specific encoding format for those algorithms, to be 
>> included in the spec. I
>>  > believe that this authentication encoding will need to include the
>>  > certificate for the signer, since an LS may not have a pre-arranged
>>  > relationship with the originator of a route.
>>  > 
>>  > We need help in coming up with a set of algorithms (we 
>> suspect DSA and RSA,
>>  > but need additional guidance on what more, if anything, 
>> needs to be said)
>>  > and their encoding, including the certs, within TRIP. 
>> Actual text for
>>  > inclusion in the draft is specifically what we want, not 
>> suggestions like
>>  > "check out protocol foo", since invariably, what protocol 
>> foo has isn't
>>  > quite right (i.e., uses ASN.1 or XML or something we don't have). 
>>  > 
>>  > So, this is a PLEA for assistance. 
>>  > 
>>  > If someone cannot contribute some text here, we may be 
>> forced to remove this
>>  > feature all together in the baseline draft, and relegate 
>> it to a separate
>>  > I-D. That may or may not go over well with the A-Ds either.
>>  > 
>>  > 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.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
>> 
>
>_______________________________________________
>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  Wed Nov 22 01:55:58 2000
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 BAA05700
	for <iptel-archive@odin.ietf.org>; Wed, 22 Nov 2000 01:55:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BE9A4443F7; Wed, 22 Nov 2000 00:56:01 -0500 (EST)
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 D2E9144339
	for <iptel@lists.bell-labs.com>; Wed, 22 Nov 2000 00:55:26 -0500 (EST)
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 BAA22504;
	Wed, 22 Nov 2000 01:57:44 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X207Z0NN>; Wed, 22 Nov 2000 01:53:34 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAC27@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'James Kempf'" <James.Kempf@Eng.Sun.COM>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: iptel@lists.bell-labs.com, erik.guttman@germany.sun.com
Subject: RE: [IPTEL] TRIP for gateways
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 22 Nov 2000 01:53:29 -0500


James,

I apologize for my errors in describing the application of SLP to this
problem. My description was sloppy. That aside, the usage of it is different
than you are talking about below. So, let me first describe the usage.

We are interested in  a PUSH protocol that pushes gateway reachability
information, along with attributes from a specific type of server (a PSTN
gateway), to an entity called a location server (LS). Note that there are
never queries for this service. Calls arrive at this location server, and
the data learned from the gateway is used to route the call. Mapping this to
SLP, the gateway is a service agent (SA). The LS is a directory agent (DA).
However, its a "lame duck" directory agent, in that there are never any
service queries from  any SLP user agents. Rather, a SIP INVITE arrives at
the DA, and the cached service registrations are searched to find the best
one for the call. The criteria for the search are not specified in the SIP
INVITE, but rather through local policy.

Now, we have a requirement here that these service registrations are always
very fresh. If the gateway dies, within seconds we want the cached
information in the LS (aka DA) to be expired. This requires a lifetime in
the service registration on the order of seconds. With TRIP, all thats sent
is a small keepalive. I don't think that there is an equivalent here in SLP;
I believe that the SA needs to re-register before the expiration. What I'm
not sure about is whether you can use incremental service registrations to
avoid resending all your service attributes. 

The second issue is that representation of the data that characterizes a
gateway using SLP seems non-trivial. A gateway has many telephone number
prefixes (each of which is called a route) it can route calls to, and
associated with each prefix is a set of attributes, like preference, cost,
or whatever. Now, you can go two ways with an SLP mapping. You can map each
route as a service in its own right, or the set of routes becomes an
attribute of the gateway service. In the former case, changes to the
availability of specific routes is easy, but the efficiency of having to
re-register each route is bad. In the latter case, the re-registrations are
more efficient, but modification of the route set (like removing a route) is
hard, even using the incremental registration feature in SLPv2.

Hopefully this makes more sense now.

Thoughts?

-Jonathan R.
 

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Eng.Sun.COM]
> Sent: Tuesday, November 21, 2000 12:22 PM
> To: jdrosen@dynamicsoft.com
> Cc: iptel@lists.bell-labs.com; erik.guttman@germany.sun.com;
> James.Kempf@Eng.Sun.COM
> Subject: Re: [IPTEL] TRIP for gateways
> 
> 
> Jonathan,
> 
> I'm not on this list, so please cc me in any correspondence. Somebody
> forwarded me your comments on using SLP for intradomain gateway
> discovery, and I would like to correct a couple of misimpressions.
> 
> Specifically:
> 
> >Another issue raised was that SLP appeared more appropriate 
> than TRIP, as
> >this was a service advertisement issue (specifically, the 
> gateway would send
> >out SLP service advertisement messages to the LS). 
> 
> No agent in SLP "sends out" unsolicited service advertisements, with
> the exception of the Directory Agent (DA). In a properly configured
> network, there are very few DAs and a DA should only send unsolicited 
> advertisements with a periodicity on the order of hours, if 
> not days. An 
> application that wants a service solicits the advertisements 
> in one of two ways:
> 
> 1) If there are no DAs, the application multicasts, and the 
> services answer with 
> their service URL using unicast.
> 
> 2) If there is a DA, the application unicasts the request to the DA,
> which then replies by unicast.
> 
> So there is no SLP traffic (and thus no network load) unless 
> an application is 
> looking for a service.
> 
> >I don't think SLP is
> >really quite right here. For example, in SLP, service 
> advertisements need to
> >be refreshed by resending the service template. This would 
> mean that a
> >gateway would need to periodically resend its entire routing table. 
> 
> This is completely false. The service template is never sent anywhere,
> it is like the LDAP schema, it merely describes the form of a service
> advertisement for a particular service type. A DA can use 
> service templates to 
> check whether a service advertisement registered by a service 
> matches, and 
> reject it if not. In practice, service templates are not now 
> used by any SLPv2 
> implementations with which I am familar. Their exact use is somewhat 
> underspecified. This was actually by design, since we did not 
> know exactly 
> whether strong type checking (such as LDAP uses) was desirable or not.
> In retrospect, from most of the applications we've seen to date, weak
> type checking seems like a better solution, so the service type
> template is nothing more than a convention (but an important one).
> 
> >Seems
> >inefficient compared to the much smaller keepalive in TRIP. 
> The smaller
> >keepalive means that it can be sent more often, resulting in 
> a much more
> >rapid failure detection.
> >
> 
> Actually, it's MORE efficient. There is absolutely NO 
> keepalive in SLP.
> It is only when a query is made that a response is given.
> 
> I'm not entirely familiar with your application, but, on the surface,
> it sounds to me that SLP would be an entirely appropriate way of
> discovering a gateway on an intradomain basis. The kinds of 
> applications
> in which it is not the right solution generally involve interdomain
> discovery (in which traffic over the Internet is involved) or when
> the attributes of a service change rapidly or don't lend themselves
> well to being encoded as a finite list of attribute value pairs. In
> addition, if there is any service-specific negotation involved in
> selecting the service, then a service-specific discovery protocol
> may be a better solution.
> 
> 		jak
> 

---
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 Nov 22 05:06:57 2000
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 FAA13173
	for <iptel-archive@odin.ietf.org>; Wed, 22 Nov 2000 05:06:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 80FF14443C; Wed, 22 Nov 2000 04:07:02 -0500 (EST)
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 644DB4433E
	for <iptel@lists.bell-labs.com>; Wed, 22 Nov 2000 04:06:47 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 22 Nov 2000 10:06:40 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id LAA05487; Wed, 22 Nov 2000 11:04:56 +0100 (BST)
Message-ID: <3A1B9A4A.380F7BD2@ubiquity.net>
From: James Undery <jundery@ubiquity.net>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jiri Kuthan <kuthan@fokus.gmd.de>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com> <3A1AC782.3963ADFF@fokus.gmd.de>
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 22 Nov 2000 10:04:58 +0000
Content-Transfer-Encoding: 7bit



Jiri Kuthan wrote:

> Jonathan,
>
> I would like to see three CPL extensions:
> - authentication support -- useful if signaling depends
>   on user credentials

This is a endpoint issue, the only time I can see you'd want authentication support is in
outgoing calls, so your phone should handle it if needed. Sending authentication in a
script like this would require the script be encrypted for transmission, clearly stepping
outside of CPL's domain. If you can think of a sane case where a subscriber wants to
authenticate incoming calls I'd be impressed.

>
> - access to external databases -- useful with long shared lists

Access to external databases is supported for lookups (Unfortunately I can't contact

>
> - support for usage of CPL in end-devices -- useful if CPL services
>   are stored at a SIM card which the users put into different cell
>   phones  (we already had this on the list, a solution could look
>   like <ring user_profile="ring_and_shake">)

This is sort of demonstrated in figure 27 of the last two drafts.

>
>
> I submitted a tiny I-D on the first two issues. Its main purpose
> is to stimulate a discussion on whether these extensions are
> considered needed, though some examples on how it could
> look like are also attached.
>
> Until it appears in the I-D directory, it is available at
> http://www.fokus.gmd.de/glone/employees/jiri.kuthan/draft-kuthan-iptel-cpl-auth-00.txt
>
> Jiri
>
> Jonathan Rosenberg wrote:
> >
> > Folks,
> >
> > I had sent out a note a few weeks back encouraging people to submit drafts
> > to facilitate discussion of future directions for the group. These include
> > things like intra-domain routing, service routing, CPLng, etc. To date, I
> > know of only one draft and one agenda slot request as a result of that. If
> > you submitted a draft and didn't tell me, please do so. Also, if you want a
> > slot and haven't yet told me, please do so now.
>
> _______________________________________________
> 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  Wed Nov 22 05:14:59 2000
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 FAA14052
	for <iptel-archive@odin.ietf.org>; Wed, 22 Nov 2000 05:14:59 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C1A2F4444D; Wed, 22 Nov 2000 04:15:02 -0500 (EST)
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 5782644440
	for <iptel@lists.bell-labs.com>; Wed, 22 Nov 2000 04:14:55 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 22 Nov 2000 10:14:48 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id LAA08907; Wed, 22 Nov 2000 11:13:13 +0100 (BST)
Message-ID: <3A1B9C3B.BC102BBA@ubiquity.net>
From: James Undery <jundery@ubiquity.net>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jiri Kuthan <kuthan@fokus.gmd.de>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com> <3A1AC782.3963ADFF@fokus.gmd.de> <3A1B9A4A.380F7BD2@ubiquity.net>
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 22 Nov 2000 10:13:15 +0000
Content-Transfer-Encoding: 7bit

Oops I appear to have lost some of the last message

James Undery wrote:

>
> >
> > - access to external databases -- useful with long shared lists
>
> Access to external databases is supported for lookups (Unfortunately I can't contact
>

Unfortunately I can't contact your website to check the usage of databases you want.


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 22 09:05:57 2000
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 JAA22211
	for <iptel-archive@odin.ietf.org>; Wed, 22 Nov 2000 09:05:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E7FF64445F; Wed, 22 Nov 2000 08:06:01 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by lists.bell-labs.com (Postfix) with ESMTP id 5A82D4434E
	for <iptel@lists.bell-labs.com>; Wed, 22 Nov 2000 08:05:00 -0500 (EST)
Received: from fokus.gmd.de (dhcp116 [195.37.78.244])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id PAA07696;
	Wed, 22 Nov 2000 15:04:51 +0100 (MET)
Message-ID: <3A1BD21F.EAFB5BDC@fokus.gmd.de>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Organization: GMD Fokus
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: James Undery <jundery@ubiquity.net>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com> <3A1AC782.3963ADFF@fokus.gmd.de> <3A1B9A4A.380F7BD2@ubiquity.net>
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 22 Nov 2000 15:03:11 +0100
Content-Transfer-Encoding: 7bit

James Undery wrote:
> Jiri Kuthan wrote:
> > - authentication support -- useful if signaling depends
> >   on user credentials
> This is a endpoint issue, the only time I can see you'd want authentication support is in
> outgoing calls, so your phone should handle it if needed. 

Not necessarily. If you want to filter out some callers and do not trust 
the From field you may want to make sure a caller authenticated himself. 
The process of authentication can take place as most of other call processing 
in UAs as well as in proxies. If a user moves from a device to a device, the 
latter alternative is preferable.

> Sending authentication in a
> script like this would require the script be encrypted for transmission, clearly stepping
> outside of CPL's domain. 

Encryption is a transport rather than CPL issue. It is useful anyway --
maybe you are not eager to transport a plain-text CPL script that includes 
a list of inconvenient caller whose calls you drop.

> > - access to external databases -- useful with long shared lists
> Access to external databases is supported for lookups (Unfortunately I can't contact
> your website to check the usage of databases you want

I'd like to have access to external DBs in matching expressions as well.

The webserver is up and running again and the document is available at 
http://www.fokus.gmd.de/glone/employees/jiri.kuthan/draft-kuthan-iptel-cpl-auth-00.txt
before it appears in the IETF directory. Sorry for server outage.

> > - support for usage of CPL in end-devices -- useful if CPL services
> >   are stored at a SIM card which the users put into different cell
> >   phones  (we already had this on the list, a solution could look
> >   like <ring user_profile="ring_and_shake">)
> 
> This is sort of demonstrated in figure 27 of the last two drafts.

Exactly.

Jiri
-- 
Jiri Kuthan         http://www.fokus.gmd.de/usr/kuthan
		    tel:+49-30-34637271
Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 22 11:58:57 2000
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 LAA26613
	for <iptel-archive@odin.ietf.org>; Wed, 22 Nov 2000 11:58:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 33A934436D; Wed, 22 Nov 2000 10:59:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141])
	by lists.bell-labs.com (Postfix) with ESMTP id 00B8B44343
	for <iptel@lists.bell-labs.com>; Wed, 22 Nov 2000 10:58:08 -0500 (EST)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA01089; Wed, 22 Nov 2000 11:58:00 -0500 (EST)
Received: from mhammer-nt.cisco.com (va-dhcp198-137.cisco.com [161.44.198.137])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AEU05279;
	Wed, 22 Nov 2000 11:57:58 -0500 (EST)
Message-Id: <4.3.2.7.2.20001122120103.00b93220@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Jiri Kuthan <kuthan@fokus.gmd.de>, James Undery <jundery@ubiquity.net>
From: hammer michael <mhammer@cisco.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
In-Reply-To: <3A1BD21F.EAFB5BDC@fokus.gmd.de>
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com>
 <3A1AC782.3963ADFF@fokus.gmd.de>
 <3A1B9A4A.380F7BD2@ubiquity.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 22 Nov 2000 12:03:50 -0800

Keep in mind that encryption is a technology, not a service.  To be 
clearer, decide whether you are talking about confidentiality, 
authentication, non-repudiation, or whatever.  To say that encryption 
belongs only in the transport realm, it taking a very narrow view of its 
possibilities.

Mike


At 03:03 PM 11/22/2000 +0100, Jiri Kuthan wrote:
>James Undery wrote:
> > Jiri Kuthan wrote:
> > > - authentication support -- useful if signaling depends
> > >   on user credentials
> > This is a endpoint issue, the only time I can see you'd want 
> authentication support is in
> > outgoing calls, so your phone should handle it if needed.
>
>Not necessarily. If you want to filter out some callers and do not trust
>the From field you may want to make sure a caller authenticated himself.
>The process of authentication can take place as most of other call processing
>in UAs as well as in proxies. If a user moves from a device to a device, the
>latter alternative is preferable.
>
> > Sending authentication in a
> > script like this would require the script be encrypted for 
> transmission, clearly stepping
> > outside of CPL's domain.
>
>Encryption is a transport rather than CPL issue. It is useful anyway --
>maybe you are not eager to transport a plain-text CPL script that includes
>a list of inconvenient caller whose calls you drop.
>
> > > - access to external databases -- useful with long shared lists
> > Access to external databases is supported for lookups (Unfortunately I 
> can't contact
> > your website to check the usage of databases you want
>
>I'd like to have access to external DBs in matching expressions as well.
>
>The webserver is up and running again and the document is available at
>http://www.fokus.gmd.de/glone/employees/jiri.kuthan/draft-kuthan-iptel-cpl-auth-00.txt
>before it appears in the IETF directory. Sorry for server outage.
>
> > > - support for usage of CPL in end-devices -- useful if CPL services
> > >   are stored at a SIM card which the users put into different cell
> > >   phones  (we already had this on the list, a solution could look
> > >   like <ring user_profile="ring_and_shake">)
> >
> > This is sort of demonstrated in figure 27 of the last two drafts.
>
>Exactly.
>
>Jiri
>--
>Jiri Kuthan         http://www.fokus.gmd.de/usr/kuthan
>                     tel:+49-30-34637271
>Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt
>
>_______________________________________________
>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  Wed Nov 22 12:16:56 2000
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 MAA00360
	for <iptel-archive@odin.ietf.org>; Wed, 22 Nov 2000 12:16:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4C69344343; Wed, 22 Nov 2000 11:17:01 -0500 (EST)
Delivered-To: iptel@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id 0466744339
	for <iptel@share.research.bell-labs.com>; Wed, 22 Nov 2000 11:16:08 -0500 (EST)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Nov 22 12:14:24 EST 2000
Received: by lists.bell-labs.com (Postfix)
	id 5B32644384; Wed, 22 Nov 2000 12:01:15 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from king.research.bell-labs.com (graceland.research.bell-labs.com [135.1.152.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 034454437D
	for <iptel@lists.bell-labs.com>; Wed, 22 Nov 2000 12:01:14 -0500 (EST)
Received: from lucent.com (bryce [135.1.152.237])
	by king.research.bell-labs.com (Postfix) with ESMTP
	id 6B0175701F; Wed, 22 Nov 2000 11:01:14 -0600 (CST)
Message-ID: <3A1BFB44.BB0CA1EE@lucent.com>
From: Peter Danielsen <pdanielsen@lucent.com>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jack Kozik <jkozik@lucent.com>, jdrosen@dynamicsoft.com,
        hgs@cs.columbia.edu, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] CPL-03 Comments and Questions]
References: <3A129F0B.6CDF4917@lucent.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 22 Nov 2000 10:58:45 -0600
Content-Transfer-Encoding: 7bit

Jonathan,

Jack Kozik forwarded some of your VoiceXML discussion
to me.  Here are some comments.

Pete Danielsen

> Subject: RE: [IPTEL] CPL-03 Comments and Questions
> Date: Wed, 15 Nov 2000 00:06:58 -0500
> From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
> To: "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,Jonathan Rosenberg
> <jdrosen@dynamicsoft.com>
> CC: "'Cliff.Harris@nokia.com'"
> <Cliff.Harris@nokia.com>,iptel@lists.bell-labs.com, Peter Mataga
> <PMataga@dynamicsoft.com>
>
> I'm only a novice at VoiceXML, so any experts out there, please feel free to
> correct me.
>
> > -----Original Message-----
> > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Tuesday, November 14, 2000 10:42 PM
> > To: Jonathan Rosenberg
> > Cc: 'Cliff.Harris@nokia.com'; iptel@lists.bell-labs.com
> > Subject: Re: [IPTEL] CPL-03 Comments and Questions
> >
> >
> > In the "loading" of scripts via HTTP, is this "stacked"?
>
> No.
>
> I.e., if the
> > loaded script returns, what happens?
>
> There is no "return".

The job of a VoiceXML document is to specify a dialog to be
conducted between a voice response platform and a person.
Usually, the dialog results in the filling of a "form" of user responses
that is submitted to a web server for processing.  The web server
replies with another VoiceXML document, generated based on
the submitted form data, for the next stage of the call.

We believe the number of dynamically created documents will far
outnumber those that are static.


> > Does execution continue after the
> > invocation of the http? Is there a namespace separation (VoiceXML has
> > variables)?
>
> There can be sharing of variables, but only if those variables are defiend
> in the root voicexml document, and then only if the original doc, and the
> one just loaded, both share the same root. Otherwise, variables defined
> within script A are not in scope when script B is loaded.

The interpreter validates the response document before conducting
the dialog it contains.  If the response document is considered invalid,
an exception is thrown within the context of the first document,
which may or may not specify a handler for the exception.  If the
response document is ok, the interpreter terminates interpretation of
the first document and begins interpreting the response.

If a document does not specify a URI to submit the data to, the
interpreter terminates after the form is filled.  It is up to the interpreter's
context to decide what happens to the call (e.g. disconnect, return to
another application that has embeddded support for VoiceXML, etc.)

Associated with each session is a set of session variables.  These
are maintained by the interpreter and may be referenced by each
document encountered in the session.  Each document may have
its own set of document variables.  They are active only
during interpretation of the document in which they are declared.
They do not persist across transitions to new documents.

In most cases, call processing proceeds as described above, one
document collects data, submits it to a URI that can process the
data and return a subsequent document, with session variables being
the only client side (IVR platform) data that persists across documents.

There are two other cases worth mentioning.  One is the use of
the application root document, the other is the subdialog case.
A document may declare itself to be part of an application, which
has an application root document.  The application root document
may declare application variables that persist between documents
as long as they all belong to the same application.  The application
variables are discarded when a new document is received that
does not belong to the previous document's application.  Otherwise,
transitions between documents follows the "goto" model described
above.

The subdialog case follows a stack model.  When a subdialog is
invoked its variable environment is stacked on top of the calling
dialog. The subdialog may "return" upon completion, at which
point the calling dialog resumes.


> > Can there be random jumps from a newly-loaded
> > routine to an
> > existing subroutine?
>
> There is a notion of sub-dialogs, which are like subroutine calls.
> Sub-dialogs are always invoked by an absolute reference - that is, the URL
> of the VoiceXML script plus the name of the form within the voiceXML
> document. It's possible that this document is cached, but beyond that, there
> is little difference as to whether the sub-dialog is in a new document or
> one previously used.

The subdialog reference may be relative or absolute.

> > Can existing subroutines be replaced?
>
> Since sub-dialogs are referred to by absolute names, they can only be
> "replaced" in the sense that the VoiceXML script at the given URI is
> re-fetched (since it was not cached), and a different script is returned.

Caching control attributes within a document tell the interpreter
whether to always fetch a fresh version or to pull one from the cache, if
available.

> > What if the
> > subroutine making the http "call" itself gets replaced?
>
> Thats a good question. I don't know.

The interpreter keeps the version of the calling document in effect
when a subdialog is invoked.  If the subdialog requests a fresh
version of the calling document, it will use the fresh one, but the
previous version will be resumed when the subdialog returns.

>  What
> > happens to
> > CPL predictability if there is a loop of endless retrievals?
>
> I don't think VoiceXML interpreters have any facility for handing loops. I
> guess its up to the http server that is returning these things.

The language definition does not prevent the creation of loops either within
the document or by repetitively requesting the same document.

> > I have to admit to some queasiness to a model that looks suspiciously
> > like the old "load a new segment" model in early Intel/DOS
> > versions. (It
> > appears somewhat similar to the "load" statement in Tcl, say,
> > too, with
> > potentially some of the same unpredictability.)
>
> I suspect these issues were considered in the design of VoiceXML, but I
> personally can't comment. Anyone?
>

As mentioned earlier, an interpreter is free to do analysis of
a document that it has received and reject it by throwing an exception
within the context of the referring document.  These are generally
called "error.badfetch" exceptions, but may be extended by vendors to supply
additional information.  A document author may include an event
handler for it to specify feedback to the caller, or alternate actions to take.



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 22 16:17:01 2000
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 QAA11073
	for <iptel-archive@odin.ietf.org>; Wed, 22 Nov 2000 16:17:01 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7C7C344390; Wed, 22 Nov 2000 15:17:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31])
	by lists.bell-labs.com (Postfix) with ESMTP id 6D1E144339
	for <iptel@lists.bell-labs.com>; Wed, 22 Nov 2000 12:58:11 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA14329;
	Wed, 22 Nov 2000 11:58:02 -0700 (MST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA19464;
	Wed, 22 Nov 2000 10:57:59 -0800 (PST)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA08741;
	Wed, 22 Nov 2000 10:57:58 -0800 (PST)
Message-Id: <200011221857.KAA08741@nasnfs.eng.sun.com>
From: James Kempf <James.Kempf@eng.sun.com>
Reply-To: James Kempf <James.Kempf@eng.sun.com>
Subject: RE: [IPTEL] TRIP for gateways
To: James.Kempf@eng.sun.com, jdrosen@dynamicsoft.com
Cc: iptel@lists.bell-labs.com, erik.guttman@germany.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: yGHb267K3XB0gmRbSolN/Q==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 22 Nov 2000 10:57:21 -0800 (PST)

Hi Jonathan,


>I apologize for my errors in describing the application of SLP to this
>problem. My description was sloppy. That aside, the usage of it is different
>than you are talking about below. So, let me first describe the usage.
>

No problem.

>We are interested in  a PUSH protocol that pushes gateway reachability
>information, along with attributes from a specific type of server (a PSTN
>gateway), to an entity called a location server (LS). Note that there are
>never queries for this service. Calls arrive at this location server, and
>the data learned from the gateway is used to route the call. Mapping this to
>SLP, the gateway is a service agent (SA). The LS is a directory agent (DA).
>However, its a "lame duck" directory agent, in that there are never any
>service queries from  any SLP user agents. Rather, a SIP INVITE arrives at
>the DA, and the cached service registrations are searched to find the best
>one for the call. The criteria for the search are not specified in the SIP
>INVITE, but rather through local policy.
>

I'm curious why you need to have the gateway push the reachability info
to the location server. Why can't the location server pull it from the
gateway?

In this scenario, the location server acts as a user agent and the
gateway acts as the service agent. The service advertisement consists
of the PSTN gateway's attributes and reachability info (as I understand
it from below, telephone prefixes). The location server periodically
performs an SLP SrvRqst for gateway service URLs, then performs an
SLP AttrRqst for the attributes. Alternatively, the location server
can include the SLP attribute list extension (see 
draft-guttman-svrloc-attrlist-ext-04.txt) to have the attributes
delivered along with the service URL.

>Now, we have a requirement here that these service registrations are always
>very fresh. If the gateway dies, within seconds we want the cached
>information in the LS (aka DA) to be expired. This requires a lifetime in

The minimum granularity of the SLP advertisement lifetimes is one second.

>the service registration on the order of seconds. With TRIP, all thats sent
>is a small keepalive. I don't think that there is an equivalent here in SLP;
>I believe that the SA needs to re-register before the expiration. 

Yes, but by the scenario above, the location server would need to query
when the lifetime of its gateway advertisements ran out. The gateway
would also need to reregister periodically when the registration ran out,
if a DA was present. If no DA was present, there would be no need
for reregistration.

>What I'm
>not sure about is whether you can use incremental service registrations to
>avoid resending all your service attributes. 
>

Yes, you can do incremental SrvReg. This would allow the gateway to 
just send its service URL to refresh the registration. A SrvReg is only needed, 
however, if a DA is present. The location server would also need to periodically
resend a SrvRqst when the advertisment's lifetime ran out. 

Not having a DA would eliminate the requirement for a SrvReg. In this
case, the location server locates the gateway initially using multicast SrvRqst,
then afterwards sends the SrvRqst directly to the gateway using unicast.
If the gateway fails to respond, the location server knows it has gone down.
That would reduce the amount of messaging for the keepalive to one
SrvRqst and one SrvRply. The gateway maintains its own attributes and
doesn't need to send them to the DA.

>The second issue is that representation of the data that characterizes a
>gateway using SLP seems non-trivial. A gateway has many telephone number
>prefixes (each of which is called a route) it can route calls to, and
>associated with each prefix is a set of attributes, like preference, cost,
>or whatever. Now, you can go two ways with an SLP mapping. You can map each
>route as a service in its own right, 

This would proliferate the number of service URLs, and therefore the number
of potential network connections, so probably not a good idea.

>or the set of routes becomes an
>attribute of the gateway service. In the former case, changes to the
>availability of specific routes is easy, but the efficiency of having to
>re-register each route is bad. In the latter case, the re-registrations are
>more efficient, but modification of the route set (like removing a route) is
>hard, even using the incremental registration feature in SLPv2.

I think SLPv2 incremental registration and deregistration could handle
updating the route set.

What I think would be more of a concern is how to set up the attributes
so that particular sets of routes are associated with particular sets
of attributes. There are a number of ways I can think of to do this,
some of them involve having attribute tags that vary according to
the route type. We'd need to talk in more detail about this, particularly
about the kinds of queries that could be expected, to come up with
a definitive design. It's essentially a data modelling problem.

>
>Hopefully this makes more sense now.
>

Yes, thanx!

>Thoughts?
>

Overall, I think your application is not something that can be easily handled
by SLP, but with careful design work, it could probably be handled. There are 
still open questions about push v.s. pull and about the data model for the 
attributes. If you or anyone else in the IPTEL
group wants to pursue this, I'll be happy to talk with you in
San Diego or exchange further email. The real question is whether
the group is interested in trying to reuse an existing protocol,
with perhaps some design challenges, or whether there is more interest
in pursuing a custom protocol for this specific application.
At least, that's how I see it. 

		jak

>-Jonathan R.
> 
>
>> -----Original Message-----
>> From: James Kempf [mailto:James.Kempf@Eng.Sun.COM]
>> Sent: Tuesday, November 21, 2000 12:22 PM
>> To: jdrosen@dynamicsoft.com
>> Cc: iptel@lists.bell-labs.com; erik.guttman@germany.sun.com;
>> James.Kempf@Eng.Sun.COM
>> Subject: Re: [IPTEL] TRIP for gateways
>> 
>> 
>> Jonathan,
>> 
>> I'm not on this list, so please cc me in any correspondence. Somebody
>> forwarded me your comments on using SLP for intradomain gateway
>> discovery, and I would like to correct a couple of misimpressions.
>> 
>> Specifically:
>> 
>> >Another issue raised was that SLP appeared more appropriate 
>> than TRIP, as
>> >this was a service advertisement issue (specifically, the 
>> gateway would send
>> >out SLP service advertisement messages to the LS). 
>> 
>> No agent in SLP "sends out" unsolicited service advertisements, with
>> the exception of the Directory Agent (DA). In a properly configured
>> network, there are very few DAs and a DA should only send unsolicited 
>> advertisements with a periodicity on the order of hours, if 
>> not days. An 
>> application that wants a service solicits the advertisements 
>> in one of two ways:
>> 
>> 1) If there are no DAs, the application multicasts, and the 
>> services answer with 
>> their service URL using unicast.
>> 
>> 2) If there is a DA, the application unicasts the request to the DA,
>> which then replies by unicast.
>> 
>> So there is no SLP traffic (and thus no network load) unless 
>> an application is 
>> looking for a service.
>> 
>> >I don't think SLP is
>> >really quite right here. For example, in SLP, service 
>> advertisements need to
>> >be refreshed by resending the service template. This would 
>> mean that a
>> >gateway would need to periodically resend its entire routing table. 
>> 
>> This is completely false. The service template is never sent anywhere,
>> it is like the LDAP schema, it merely describes the form of a service
>> advertisement for a particular service type. A DA can use 
>> service templates to 
>> check whether a service advertisement registered by a service 
>> matches, and 
>> reject it if not. In practice, service templates are not now 
>> used by any SLPv2 
>> implementations with which I am familar. Their exact use is somewhat 
>> underspecified. This was actually by design, since we did not 
>> know exactly 
>> whether strong type checking (such as LDAP uses) was desirable or not.
>> In retrospect, from most of the applications we've seen to date, weak
>> type checking seems like a better solution, so the service type
>> template is nothing more than a convention (but an important one).
>> 
>> >Seems
>> >inefficient compared to the much smaller keepalive in TRIP. 
>> The smaller
>> >keepalive means that it can be sent more often, resulting in 
>> a much more
>> >rapid failure detection.
>> >
>> 
>> Actually, it's MORE efficient. There is absolutely NO 
>> keepalive in SLP.
>> It is only when a query is made that a response is given.
>> 
>> I'm not entirely familiar with your application, but, on the surface,
>> it sounds to me that SLP would be an entirely appropriate way of
>> discovering a gateway on an intradomain basis. The kinds of 
>> applications
>> in which it is not the right solution generally involve interdomain
>> discovery (in which traffic over the Internet is involved) or when
>> the attributes of a service change rapidly or don't lend themselves
>> well to being encoded as a finite list of attribute value pairs. In
>> addition, if there is any service-specific negotation involved in
>> selecting the service, then a service-specific discovery protocol
>> may be a better solution.
>> 
>> 		jak
>> 
>
>---
>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 Nov 22 21:03:58 2000
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 VAA24186
	for <iptel-archive@odin.ietf.org>; Wed, 22 Nov 2000 21:03:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1E22444359; Wed, 22 Nov 2000 20:04:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by lists.bell-labs.com (Postfix) with ESMTP id 4D55B44339
	for <iptel@lists.bell-labs.com>; Wed, 22 Nov 2000 20:03:37 -0500 (EST)
Received: from fokus.gmd.de (dhcp116 [195.37.78.244])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id DAA05189;
	Thu, 23 Nov 2000 03:03:25 +0100 (MET)
Message-ID: <3A1C7A2C.3250C215@fokus.gmd.de>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Organization: GMD Fokus
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: hammer michael <mhammer@cisco.com>
Cc: James Undery <jundery@ubiquity.net>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com>
	 <3A1AC782.3963ADFF@fokus.gmd.de>
	 <3A1B9A4A.380F7BD2@ubiquity.net> <4.3.2.7.2.20001122120103.00b93220@cia.cisco.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 23 Nov 2000 03:00:12 +0100
Content-Transfer-Encoding: 7bit

hammer michael wrote:
> 
> Keep in mind that encryption is a technology, not a service.  
> To be clearer, decide whether you are talking about confidentiality,
> authentication, non-repudiation, or whatever.  

Problem: It is dangerous to transport CPL security credentials (SC)
         or even some CPL scripts (like those that include lists of
         enemies) in clear-textover a network.
Needed service: privacy of transported CPL SCs/scripts
Recommended technology: encryption 

> To say that encryption
> belongs only in the transport realm, it taking a very narrow view of its
> possibilities.

I do not see any advantage of inventing a mechanism for
encryption of CPL scripts or SCs if I can take a generic one 
available in a transport protocol.

Jiri

> > > Sending authentication in a
> > > script like this would require the script be encrypted for
> > transmission, clearly stepping
> > > outside of CPL's domain.
> >
> >Encryption is a transport rather than CPL issue. It is useful anyway --
> >maybe you are not eager to transport a plain-text CPL script that includes
> >a list of inconvenient caller whose calls you drop.

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 22 21:05:58 2000
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 VAA24468
	for <iptel-archive@odin.ietf.org>; Wed, 22 Nov 2000 21:05:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 221D0443AA; Wed, 22 Nov 2000 20:06:03 -0500 (EST)
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 7CB2744492
	for <iptel@lists.bell-labs.com>; Wed, 22 Nov 2000 20:05:33 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA02705;
	Wed, 22 Nov 2000 21:05:21 -0500 (EST)
Message-ID: <3A1C7B61.47C85373@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jiri Kuthan <kuthan@fokus.gmd.de>
Cc: hammer michael <mhammer@cisco.com>, James Undery <jundery@ubiquity.net>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com>
		 <3A1AC782.3963ADFF@fokus.gmd.de>
		 <3A1B9A4A.380F7BD2@ubiquity.net> <4.3.2.7.2.20001122120103.00b93220@cia.cisco.com> <3A1C7A2C.3250C215@fokus.gmd.de>
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 22 Nov 2000 21:05:21 -0500
Content-Transfer-Encoding: 7bit

Jiri Kuthan wrote:
> 
> hammer michael wrote:
> >
> > Keep in mind that encryption is a technology, not a service.
> > To be clearer, decide whether you are talking about confidentiality,
> > authentication, non-repudiation, or whatever.
> 
> Problem: It is dangerous to transport CPL security credentials (SC)
>          or even some CPL scripts (like those that include lists of
>          enemies) in clear-textover a network.
> Needed service: privacy of transported CPL SCs/scripts
> Recommended technology: encryption

Already exists, as REGISTER script uploads can be encrypted, either at
transport (TLS) or application (PGP) level.


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Nov 23 11:57:58 2000
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 LAA25018
	for <iptel-archive@odin.ietf.org>; Thu, 23 Nov 2000 11:57:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0473D44362; Thu, 23 Nov 2000 10:58:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mex.italtel.it (mex.italtel.it [138.132.117.4])
	by lists.bell-labs.com (Postfix) with ESMTP id 8ADB644336
	for <iptel@lists.bell-labs.com>; Thu, 23 Nov 2000 10:57:00 -0500 (EST)
Received: .(localhost [127.0.0.1]) by mex.italtel.it (8.9.3+Sun/8.9.0) with ESMTP id RAA09481 for <iptel@lists.bell-labs.com>; Thu, 23 Nov 2000 17:56:06 +0100 (MET)
Received: from esbcnsw001.es.italtel.it (esbcnsw001.es.italtel.it [138.132.119.31])
	by mix.italtel.it (8.9.3/8.9.3) with ESMTP id RAA14824
	for <iptel@lists.bell-labs.com>; Thu, 23 Nov 2000 17:49:44 +0100 (MET)
Received: by esbcnsw001.es.italtel.it with Internet Mail Service (5.5.2650.21)
	id <WQJZYHZH>; Thu, 23 Nov 2000 17:52:08 +0100
Message-ID: <A57AD4444FDFD311BEBC00508B6575AD0E2575@esbcnsw001.es.italtel.it>
From: Juan Rendon <Juan.Rendon@italtel.it>
To: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0556D.B68FFDA0"
Subject: [IPTEL] (no subject)
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 23 Nov 2000 17:52:06 +0100

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_001_01C0556D.B68FFDA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I'm new in this mailing list. I'm working in a project of IP Telephony =
and
I'd like to ask anyone the following question.

I have read that the major problems are the integration of the =
signalling
system SS7 and the services
offered in the PSTNs that are not able to run in the IP network. I know =
that
there are some problems with the way H.323 handles
SS7. I'd like to know if MGCP or MEGACO (or any other new protocol) has
solved these problems (specially the question of the PSTN services).

Thank you for your time,

Juan Rendon














>                                                                     =20
> Juan Rend=F3n Schneir
> .Italtel
	Dpto. de Ofertas e Ingenier=EDa de Red
	juan.rendon@italtel.it             Barcelona (Spain)
> Tfno: 34.93.508.58.39  Fax: 34.93.508.58.20
=09





------_=_NextPart_001_01C0556D.B68FFDA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.75">
<TITLE></TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I'm new in this mailing list. I'm =
working in a project of IP Telephony and I'd like to ask anyone the =
following question.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have read that the major problems =
are the integration of the signalling system SS7 and the =
services</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">offered in the PSTNs that are not =
able to run in the IP network. I know that there are some problems with =
the way H.323 handles</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">SS7. I'd like to know if MGCP or =
MEGACO (or any other new protocol) has solved these problems (specially =
the question of the PSTN services).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thank you for your time,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Juan Rendon</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<UL>
<P><B><STRIKE><FONT COLOR=3D"#0000FF" SIZE=3D1 =
FACE=3D"Tahoma">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><=
/STRIKE> </B>
<BR><B><FONT COLOR=3D"#000000" SIZE=3D1 FACE=3D"Tahoma">Juan Rend=F3n =
Schneir</FONT></B>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D1 FACE=3D"TriloboP">.</FONT><FONT =
COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"TriloboP">Italtel</FONT><B></B><B></B>
<BR><B><I><FONT COLOR=3D"#0000FF" SIZE=3D1 FACE=3D"Tahoma">Dpto. de =
Ofertas e Ingenier=EDa de Red<BR>
</FONT></I></B><I></I><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Tahoma">juan.rendon@italtel.it&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Barcelona (Spain)<BR>
</FONT><B></B><B><FONT COLOR=3D"#000000" SIZE=3D1 FACE=3D"Tahoma">Tfno: =
34.93.508.58.39&nbsp; Fax: 34.93.508.58.20</FONT></B>
<BR><B><STRIKE><FONT COLOR=3D"#0000FF" SIZE=3D1 =
FACE=3D"Tahoma">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><=
/STRIKE> </B>
</P>
<BR>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C0556D.B68FFDA0--

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Nov 23 13:43:59 2000
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 NAA28610
	for <iptel-archive@odin.ietf.org>; Thu, 23 Nov 2000 13:43:59 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E261A4434F; Thu, 23 Nov 2000 12:44:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by lists.bell-labs.com (Postfix) with ESMTP id 68E9344336
	for <iptel@lists.bell-labs.com>; Thu, 23 Nov 2000 12:43:19 -0500 (EST)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA07134 for <iptel@lists.bell-labs.com>; Thu, 23 Nov 2000 11:43:12 -0700 (MST)]
Received: [from s-brc9-a.ipsg.mot.com (s-brc9-a.ipsg.mot.com [138.242.16.13]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id LAA22249 for <iptel@lists.bell-labs.com>; Thu, 23 Nov 2000 11:43:11 -0700 (MST)]
Received: by s-brc9-a.ipsg.mot.com with Internet Mail Service (5.5.2650.21)
	id <W0A0X439>; Thu, 23 Nov 2000 10:43:10 -0800
Message-ID: <429C93839568D31186640000F87522E80C881C@s-brc9-a.ipsg.mot.com>
From: Young Michael-Y10724 <Michael.Young@motorola.com>
To: "'Juan Rendon'" <Juan.Rendon@italtel.it>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] (no subject)
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0557D.3740F210"
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 23 Nov 2000 10:43:05 -0800

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_001_01C0557D.3740F210
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Juan,
=20
MEGACO (or MGCP) is a control protocol between Media Gateway Controller
(MGC) and Media Gateway (MGW), there is nothing to do with SS7.  Only =
if you
have to deal with legacy PSTN network, you need to talk to SS7.  I am =
not
sure exactly what's your question, but go check sigtran group in IETF, =
you
might find some useful information about SS7 upper layer protocol over =
IP.
=20
Regards,

Michael Young=20
----------------------------------------------------------=20
System Design,  GTSS Vancouver, Motorola=20
Tel: (604)241-6032       Cel: (604)726-6609=20
Email:  michael.young@motorola.com=20
Instant Msg: myoung@fido.ca=20
----------------------------------------------------------=20

-----Original Message-----
From: Juan Rendon [mailto:Juan.Rendon@italtel.it]
Sent: Thursday, November 23, 2000 8:52 AM
To: 'iptel@lists.bell-labs.com'
Subject: [IPTEL] (no subject)



Hi,=20

I'm new in this mailing list. I'm working in a project of IP Telephony =
and
I'd like to ask anyone the following question.

I have read that the major problems are the integration of the =
signalling
system SS7 and the services=20
offered in the PSTNs that are not able to run in the IP network. I know =
that
there are some problems with the way H.323 handles

SS7. I'd like to know if MGCP or MEGACO (or any other new protocol) has
solved these problems (specially the question of the PSTN services).

Thank you for your time,=20

Juan Rendon=20














=09

Juan Rend=F3n Schneir=20
.Italtel=20
Dpto. de Ofertas e Ingenier=EDa de Red
juan.rendon@italtel.it             Barcelona (Spain)
Tfno: 34.93.508.58.39  Fax: 34.93.508.58.20=20
                                                                    =20




------_=_NextPart_001_01C0557D.3740F210
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE></TITLE>

<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3D"Comic Sans MS" size=3D2><SPAN=20
class=3D409394018-23112000>Hi Juan,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3D"Comic Sans MS" size=3D2><SPAN=20
class=3D409394018-23112000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3D"Comic Sans MS" size=3D2><SPAN=20
class=3D409394018-23112000>MEGACO (or MGCP) is a control protocol =
between Media=20
Gateway Controller (MGC) and Media Gateway (MGW), there is nothing to =
do with=20
SS7.&nbsp; Only if you have to deal with legacy PSTN network, you need =
to talk=20
to SS7.&nbsp; I am not sure exactly what's your question, but go check =
sigtran=20
group in IETF, you might find some useful information about SS7 upper =
layer=20
protocol over IP.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3D"Comic Sans MS" size=3D2><SPAN=20
class=3D409394018-23112000>Regards,</SPAN></FONT></DIV>
<P><B><FONT color=3D#000080 face=3D"Comic Sans MS" size=3D2>Michael =
Young</FONT></B>=20
<BR><FONT color=3D#808080 face=3D"Comic Sans MS"=20
size=3D1>----------------------------------------------------------</FON=
T>=20
<BR><FONT color=3D#808080 face=3D"Comic Sans MS" size=3D1>System =
Design,&nbsp; GTSS=20
Vancouver, Motorola </FONT><BR><FONT color=3D#808080 face=3D"Comic Sans =
MS"=20
size=3D1>Tel: (604)241-6032&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cel:=20
(604)726-6609</FONT> <BR><FONT color=3D#808080 face=3D"Comic Sans MS"=20
size=3D1>Email:&nbsp; michael.young@motorola.com</FONT> <BR><FONT =
color=3D#808080=20
face=3D"Comic Sans MS" size=3D1>Instant Msg: myoung@fido.ca</FONT> =
<BR><FONT=20
color=3D#808080 face=3D"Comic Sans MS"=20
size=3D1>----------------------------------------------------------</FON=
T> </P>
<BLOCKQUOTE>
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Juan Rendon=20
  [mailto:Juan.Rendon@italtel.it]<BR><B>Sent:</B> Thursday, November =
23, 2000=20
  8:52 AM<BR><B>To:</B> 'iptel@lists.bell-labs.com'<BR><B>Subject:</B> =
[IPTEL]=20
  (no subject)<BR><BR></DIV></FONT>
  <P><FONT face=3DArial size=3D2>Hi,</FONT> </P>
  <P><FONT face=3DArial size=3D2>I'm new in this mailing list. I'm =
working in a=20
  project of IP Telephony and I'd like to ask anyone the following=20
  question.</FONT></P>
  <P><FONT face=3DArial size=3D2>I have read that the major problems =
are the=20
  integration of the signalling system SS7 and the services</FONT> =
<BR><FONT=20
  face=3DArial size=3D2>offered in the PSTNs that are not able to run =
in the IP=20
  network. I know that there are some problems with the way H.323=20
  handles</FONT></P>
  <P><FONT face=3DArial size=3D2>SS7. I'd like to know if MGCP or =
MEGACO (or any=20
  other new protocol) has solved these problems (specially the question =
of the=20
  PSTN services).</FONT></P>
  <P><FONT face=3DArial size=3D2>Thank you for your time,</FONT> </P>
  <P><FONT face=3DArial size=3D2>Juan Rendon</FONT>=20
  </P><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>
  <UL>
    <P><B><STRIKE><FONT color=3D#0000ff face=3DTahoma=20
    =
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></STRIKE=
>=20
    </B><BR><B><FONT color=3D#000000 face=3DTahoma size=3D1>Juan =
Rend=F3n=20
    Schneir</FONT></B> <BR><FONT color=3D#0000ff face=3DTriloboP=20
    size=3D1>.</FONT><FONT color=3D#000000 face=3DTriloboP=20
    size=3D1>Italtel</FONT><B></B><B></B> <BR><B><I><FONT =
color=3D#0000ff=20
    face=3DTahoma size=3D1>Dpto. de Ofertas e Ingenier=EDa de=20
    Red<BR></FONT></I></B><I></I><FONT color=3D#000000 face=3DTahoma=20
    =
size=3D1>juan.rendon@italtel.it&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Barcelona (Spain)<BR></FONT><B></B><B><FONT color=3D#000000 =
face=3DTahoma=20
    size=3D1>Tfno: 34.93.508.58.39&nbsp; Fax: =
34.93.508.58.20</FONT></B>=20
    <BR><B><STRIKE><FONT color=3D#0000ff face=3DTahoma=20
    =
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></STRIKE=
>=20
    </B></P><BR><BR></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0557D.3740F210--

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Nov 23 14:40:59 2000
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 OAA20141
	for <iptel-archive@odin.ietf.org>; Thu, 23 Nov 2000 14:40:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BEBE944388; Thu, 23 Nov 2000 13:41:01 -0500 (EST)
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 0BE2844385
	for <iptel@lists.bell-labs.com>; Thu, 23 Nov 2000 13:40:13 -0500 (EST)
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 OAA03147;
	Thu, 23 Nov 2000 14:42:29 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X2075B4Q>; Thu, 23 Nov 2000 14:38:16 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAC79@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Juan Rendon'" <Juan.Rendon@italtel.it>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] (no subject)
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C05584.EC997CA3"
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 23 Nov 2000 14:38:08 -0500

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_001_01C05584.EC997CA3
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I would advise that you check out the many tutorials, papers, and
information available at these sites:
=20
http://www.cs.columbia.edu/~hgs/sip =
<http://www.cs.columbia.edu/~hgs/sip>=20
http://www.cs.columbia.edu/~hgs/rtp =
<http://www.cs.columbia.edu/~hgs/rtp>=20
http://www.fokus.gmd.de/research/cc/glone/projects/ipt/
<http://www.fokus.gmd.de/research/cc/glone/projects/ipt/>=20
http://www.packetizer.com/ <http://www.packetizer.com/>=20
=20

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 =
<http://www.cs.columbia.edu/~jdrosen>
PHONE: (973) 952-5000
http://www.dynamicsoft.com <http://www.dynamicsoft.com/>=20
 =20

-----Original Message-----
From: Juan Rendon [mailto:Juan.Rendon@italtel.it]
Sent: Thursday, November 23, 2000 11:52 AM
To: 'iptel@lists.bell-labs.com'
Subject: [IPTEL] (no subject)



Hi,=20

I'm new in this mailing list. I'm working in a project of IP Telephony =
and
I'd like to ask anyone the following question.

I have read that the major problems are the integration of the =
signalling
system SS7 and the services=20
offered in the PSTNs that are not able to run in the IP network. I know =
that
there are some problems with the way H.323 handles

SS7. I'd like to know if MGCP or MEGACO (or any other new protocol) has
solved these problems (specially the question of the PSTN services).

Thank you for your time,=20

Juan Rendon=20














=09

Juan Rend=F3n Schneir=20
.Italtel=20
Dpto. de Ofertas e Ingenier=EDa de Red
juan.rendon@italtel.it             Barcelona (Spain)
Tfno: 34.93.508.58.39  Fax: 34.93.508.58.20=20
                                                                    =20




------_=_NextPart_001_01C05584.EC997CA3
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE></TITLE>

<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D904143619-23112000><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2>I would advise that you check out the many tutorials, papers, =
and=20
information available at these sites:</FONT></SPAN></DIV>
<DIV><SPAN class=3D904143619-23112000><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D904143619-23112000><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2><A=20
href=3D"http://www.cs.columbia.edu/~hgs/sip">http://www.cs.columbia.edu/=
~hgs/sip</A></FONT></SPAN></DIV>
<DIV><SPAN class=3D904143619-23112000><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2><A=20
href=3D"http://www.cs.columbia.edu/~hgs/rtp">http://www.cs.columbia.edu/=
~hgs/rtp</A></FONT></SPAN></DIV>
<DIV><SPAN class=3D904143619-23112000><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2><A=20
href=3D"http://www.fokus.gmd.de/research/cc/glone/projects/ipt/">http://=
www.fokus.gmd.de/research/cc/glone/projects/ipt/</A></FONT></SPAN></DIV>=

<DIV><SPAN class=3D904143619-23112000><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2><A=20
href=3D"http://www.packetizer.com/">http://www.packetizer.com/</A></FONT=
></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P><FONT size=3D2>Jonathan D.=20
Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
72 Eagle Rock Ave.<BR>Chief=20
Scientist&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
First=20
Floor<BR>dynamicsoft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
East Hanover, NJ=20
07936<BR>jdrosen@dynamicsoft.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
FAX:&nbsp;&nbsp; (973) 952-5050<BR><A target=3D_blank=20
href=3D"http://www.cs.columbia.edu/~jdrosen">http://www.cs.columbia.edu/=
~jdrosen</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
PHONE: (973) 952-5000<BR><A target=3D_blank=20
href=3D"http://www.dynamicsoft.com/">http://www.dynamicsoft.com</A><BR>&=
nbsp;</FONT>=20
</P>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Juan Rendon=20
  [mailto:Juan.Rendon@italtel.it]<BR><B>Sent:</B> Thursday, November =
23, 2000=20
  11:52 AM<BR><B>To:</B> 'iptel@lists.bell-labs.com'<BR><B>Subject:</B> =
[IPTEL]=20
  (no subject)<BR><BR></FONT></DIV>
  <P><FONT face=3DArial size=3D2>Hi,</FONT> </P>
  <P><FONT face=3DArial size=3D2>I'm new in this mailing list. I'm =
working in a=20
  project of IP Telephony and I'd like to ask anyone the following=20
  question.</FONT></P>
  <P><FONT face=3DArial size=3D2>I have read that the major problems =
are the=20
  integration of the signalling system SS7 and the services</FONT> =
<BR><FONT=20
  face=3DArial size=3D2>offered in the PSTNs that are not able to run =
in the IP=20
  network. I know that there are some problems with the way H.323=20
  handles</FONT></P>
  <P><FONT face=3DArial size=3D2>SS7. I'd like to know if MGCP or =
MEGACO (or any=20
  other new protocol) has solved these problems (specially the question =
of the=20
  PSTN services).</FONT></P>
  <P><FONT face=3DArial size=3D2>Thank you for your time,</FONT> </P>
  <P><FONT face=3DArial size=3D2>Juan Rendon</FONT>=20
  </P><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>
  <UL>
    <P><B><STRIKE><FONT face=3DTahoma color=3D#0000ff=20
    =
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></STRIKE=
>=20
    </B><BR><B><FONT face=3DTahoma color=3D#000000 size=3D1>Juan =
Rend=F3n=20
    Schneir</FONT></B> <BR><FONT face=3DTriloboP color=3D#0000ff=20
    size=3D1>.</FONT><FONT face=3DTriloboP color=3D#000000=20
    size=3D1>Italtel</FONT><B></B><B></B> <BR><B><I><FONT face=3DTahoma =

    color=3D#0000ff size=3D1>Dpto. de Ofertas e Ingenier=EDa de=20
    Red<BR></FONT></I></B><I></I><FONT face=3DTahoma color=3D#000000=20
    =
size=3D1>juan.rendon@italtel.it&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Barcelona (Spain)<BR></FONT><B></B><B><FONT face=3DTahoma =
color=3D#000000=20
    size=3D1>Tfno: 34.93.508.58.39&nbsp; Fax: =
34.93.508.58.20</FONT></B>=20
    <BR><B><STRIKE><FONT face=3DTahoma color=3D#0000ff=20
    =
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></STRIKE=
>=20
    </B></P><BR><BR></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C05584.EC997CA3--

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Sun Nov 26 19:47:43 2000
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 TAA11068
	for <iptel-archive@odin.ietf.org>; Sun, 26 Nov 2000 19:47:42 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D65CD44374; Sun, 26 Nov 2000 18:42:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from tonnant.cnchost.com (tonnant.concentric.net [207.155.248.72])
	by lists.bell-labs.com (Postfix) with ESMTP id AD82344363
	for <iptel@lists.bell-labs.com>; Fri, 24 Nov 2000 17:19:53 -0500 (EST)
Received: from ss8.com (gw-ss8networks.storm.ca [209.87.234.122])
	by tonnant.cnchost.com
	id SAA01550; Fri, 24 Nov 2000 18:19:40 -0500 (EST)
	[ConcentricHost SMTP Relay 1.10]
Message-ID: <3A1EF791.7562896@ss8.com>
From: Dave Walker <drwalker@ss8.com>
Reply-To: drwalker@ss8.com
X-Mailer: Mozilla 4.75 [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] TRIP MIB
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 24 Nov 2000 18:19:45 -0500
Content-Transfer-Encoding: 7bit

We've put together a draft describing a MIB for TRIP (based on the -03 
draft of TRIP).  Unfortunately we missed the cut-off for -00 drafts, but 
if there's no objection, we'd like to give a brief presentation about it 
in San Diego.

The draft is available at 
http://ss8networks.com.cnchost.com/files/internet-drafts/draft-zinman-trip-mib-00.txt
 
Regards,

Dave Walker
SS8 Networks
Ottawa, Canada

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Nov 27 02:21:02 2000
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 CAA01842
	for <iptel-archive@odin.ietf.org>; Mon, 27 Nov 2000 02:21:01 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AF63644394; Mon, 27 Nov 2000 01:21:03 -0500 (EST)
Delivered-To: iptel@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id 0782D44336
	for <iptel@share.research.bell-labs.com>; Mon, 27 Nov 2000 01:20:55 -0500 (EST)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Nov 27 02:19:49 EST 2000
Received: by lists.bell-labs.com (Postfix)
	id 8C71E44380; Mon, 27 Nov 2000 02:07:26 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from nl0006exch001h.wins.lucent.com (nl0006exch001h.nl.lucent.com [135.85.76.62])
	by lists.bell-labs.com (Postfix) with ESMTP id ACA4D4437D
	for <iptel@lists.bell-labs.com>; Mon, 27 Nov 2000 02:07:23 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21)
	id <V0R8ZGG6>; Mon, 27 Nov 2000 08:07:22 +0100
Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0A3A2687@nl0006exch002u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: iptel@lists.bell-labs.com, drwalker@ss8.com
Subject: RE: [IPTEL] TRIP MIB
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 27 Nov 2000 08:07:17 +0100

Let me tell you immediately a few issues that I see:

- You should not use IpAddress I think. IESG wants MIBs to be
  IPv4 and IIIPv6 friendly. Take a look at RFC2851 on how to do that.
- You should not use DisplayString, but instead a UTF8 based
  string, See RFC 2571 for TC SnmpAdminString as a possible
  alternative
- you should NOT use temporray assignment { mib-2 9996 }
  Instead use something like:  { mib-2 xxx } -- to be assigned by IANA
- I think I would rename tripTraps into tripNotifications

See also: http://www.ietf.org/ID-nits.html

Just trying to get some common things right from the beginning.
I did not do any detailed review or checks at all.

Bert

> ----------
> From: 	Dave Walker[SMTP:drwalker@ss8.com]
> Reply To: 	drwalker@ss8.com
> Sent: 	Saturday, November 25, 2000 12:19 AM
> To: 	iptel@lists.bell-labs.com
> Subject: 	[IPTEL] TRIP MIB
> 
> We've put together a draft describing a MIB for TRIP (based on the -03 
> draft of TRIP).  Unfortunately we missed the cut-off for -00 drafts, but 
> if there's no objection, we'd like to give a brief presentation about it 
> in San Diego.
> 
> The draft is available at 
> http://ss8networks.com.cnchost.com/files/internet-drafts/draft-zinman-trip
> -mib-00.txt
>  
> Regards,
> 
> Dave Walker
> SS8 Networks
> Ottawa, Canada
> 
> _______________________________________________
> 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 Nov 27 09:56:58 2000
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 JAA04186
	for <iptel-archive@odin.ietf.org>; Mon, 27 Nov 2000 09:56:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 10FF444338; Mon, 27 Nov 2000 08:57:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141])
	by lists.bell-labs.com (Postfix) with ESMTP id F351344336
	for <iptel@lists.bell-labs.com>; Mon, 27 Nov 2000 08:56:30 -0500 (EST)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA24209; Mon, 27 Nov 2000 09:56:21 -0500 (EST)
Received: from mhammer-nt.cisco.com (va-dhcp198-137.cisco.com [161.44.198.137])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AEU16480;
	Mon, 27 Nov 2000 09:56:18 -0500 (EST)
Message-Id: <4.3.2.7.2.20001127094855.00b9e270@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Jiri Kuthan <kuthan@fokus.gmd.de>
From: hammer michael <mhammer@cisco.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
Cc: James Undery <jundery@ubiquity.net>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
In-Reply-To: <3A1C7A2C.3250C215@fokus.gmd.de>
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com>
 <3A1AC782.3963ADFF@fokus.gmd.de>
 <3A1B9A4A.380F7BD2@ubiquity.net>
 <4.3.2.7.2.20001122120103.00b93220@cia.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 27 Nov 2000 10:02:17 -0800

Suppose, I establish a secure session and securely transmit a script which 
then gets loaded.  Later, it turns out the script is destructive.  You 
accuse me of doing some damage.  I deny that the rogue script you are 
complaining about is mine.  The session is long gone.  You have no proof 
that the script is mine and any legal claims would be rather tenuous, 
unless you saved a recording of the session, which would waste memory.  If 
the script had been signed, then you would have a case against me.

Transport level assurance is only good if you can absolutely trust the 
sender.  I am not suggesting that you not use transport layer security, 
only that some additional level of security might be called for.

Mike Hammer

At 03:00 AM 11/23/2000 +0100, Jiri Kuthan wrote:
>hammer michael wrote:
> >
> > Keep in mind that encryption is a technology, not a service.
> > To be clearer, decide whether you are talking about confidentiality,
> > authentication, non-repudiation, or whatever.
>
>Problem: It is dangerous to transport CPL security credentials (SC)
>          or even some CPL scripts (like those that include lists of
>          enemies) in clear-textover a network.
>Needed service: privacy of transported CPL SCs/scripts
>Recommended technology: encryption
>
> > To say that encryption
> > belongs only in the transport realm, it taking a very narrow view of its
> > possibilities.
>
>I do not see any advantage of inventing a mechanism for
>encryption of CPL scripts or SCs if I can take a generic one
>available in a transport protocol.
>
>Jiri
>
> > > > Sending authentication in a
> > > > script like this would require the script be encrypted for
> > > transmission, clearly stepping
> > > > outside of CPL's domain.
> > >
> > >Encryption is a transport rather than CPL issue. It is useful anyway --
> > >maybe you are not eager to transport a plain-text CPL script that includes
> > >a list of inconvenient caller whose calls you drop.



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Nov 27 11:37:58 2000
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 LAA05808
	for <iptel-archive@odin.ietf.org>; Mon, 27 Nov 2000 11:37:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2FCA444368; Mon, 27 Nov 2000 10:38:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by lists.bell-labs.com (Postfix) with ESMTP id 122834434E
	for <iptel@lists.bell-labs.com>; Mon, 27 Nov 2000 10:37:43 -0500 (EST)
Received: from fokus.gmd.de (dhcp116 [195.37.78.244])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA29402;
	Mon, 27 Nov 2000 17:37:04 +0100 (MET)
Message-ID: <3A228D35.7304B322@fokus.gmd.de>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Organization: GMD Fokus
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: hammer michael <mhammer@cisco.com>
Cc: James Undery <jundery@ubiquity.net>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com>
	 <3A1AC782.3963ADFF@fokus.gmd.de>
	 <3A1B9A4A.380F7BD2@ubiquity.net>
	 <4.3.2.7.2.20001122120103.00b93220@cia.cisco.com> <4.3.2.7.2.20001127094855.00b9e270@cia.cisco.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 27 Nov 2000 17:35:01 +0100
Content-Transfer-Encoding: 7bit

hammer michael wrote:
> 
> Suppose, I establish a secure session and securely transmit a script which
> then gets loaded.  Later, it turns out the script is destructive.  You
> accuse me of doing some damage.  I deny that the rogue script you are
> complaining about is mine.  The session is long gone.  You have no proof
> that the script is mine and any legal claims would be rather tenuous,
> unless you saved a recording of the session, which would waste memory.  If
> the script had been signed, then you would have a case against me.

What you are asking for is a definitely useful service. Note that
it is neither specific to the proposed extensions nor to CPL.
We already have secure transport mechanisms ( E.g., TLS/PGP if you 
use SIP REGISTER for transport, draft-lennox-sip-reg-payload-01.txt )
that cover the need for security in payload-independent way.

Note that there can be a terminological confusion here -- transport does 
not necessarily imply layer 4. In this context it can be also an arbitrary 
application protocol used to transport CPL scripts from one place to another 
one.

> Transport level assurance is only good if you can absolutely trust the
> sender.  

If there is support for it you can authenticate using the transport mechanism.

> I am not suggesting that you not use transport layer security,
> only that some additional level of security might be called for.

Actually, the sip-reg I-D already mandates REGISTERs to be authenticated
and strongly recommends verification of message integrity. Of course, 
these requirements are reasonable for any other transport mechanism 
(e.g., HTTP) as well.

Jiri

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Nov 27 18:36:03 2000
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 SAA20023
	for <iptel-archive@odin.ietf.org>; Mon, 27 Nov 2000 18:36:03 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C8A764434E; Mon, 27 Nov 2000 17:36:01 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by lists.bell-labs.com (Postfix) with ESMTP id D017A44336
	for <iptel@lists.bell-labs.com>; Mon, 27 Nov 2000 17:35:29 -0500 (EST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eARNZf613688
	for <iptel@lists.bell-labs.com>; Mon, 27 Nov 2000 17:35:51 -0600 (CST)
Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tac12f255502397704c@davir02nok.americas.nokia.com> for <iptel@lists.bell-labs.com>;
 Mon, 27 Nov 2000 17:35:10 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <XMR530SK>; Mon, 27 Nov 2000 17:30:52 -0600
Message-ID: <E39024226822D311BC880008C77318A1019C59EB@oteis01nok>
From: Cliff.Harris@nokia.com
To: iptel@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] CPL Question About Priority
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 27 Nov 2000 17:26:54 -0600

The "location" node has an optional "priority" parameter, but the "lookup"
node does not. Nor does the CPL draft specify the priority of the location
initially in the location set for an outgoing call. 

Suppose I wanted to write a script that, for outgoing calls, tried some
other number first, and if that call failed, then tried the original number.
It seems to me that there is no portable way of doing that, since the
priority of the location initially in the location set is not specified.

Section 7.1 says, "The priority of locations in a set is determined by
server policy, though CPL servers SHOULD honor the priority parameter of the
location tag." Why is this only a SHOULD and not a MUST? And why are no
priorities defined for the other cases mentioned above?

- Cliff Harris 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Nov 27 18:49:59 2000
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 SAA23229
	for <iptel-archive@odin.ietf.org>; Mon, 27 Nov 2000 18:49:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8D2904437D; Mon, 27 Nov 2000 17:50:02 -0500 (EST)
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 4A13344375
	for <iptel@lists.bell-labs.com>; Mon, 27 Nov 2000 17:49:08 -0500 (EST)
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 PAA12549;
	Mon, 27 Nov 2000 15:49:00 -0800 (PST)
Received: from cisco.com (dhcp-128-107-142-56.cisco.com [128.107.142.56])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with ESMTP id AAZ08943 (AUTH hsalama);
	Mon, 27 Nov 2000 15:48:59 -0800 (PST)
Message-ID: <3A22F228.B587C15D@cisco.com>
From: "Hussein F. Salama" <hsalama@cisco.com>
Reply-To: hsalama@cisco.com
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (WinNT; U)
X-Accept-Language: en,arabic
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: [IPTEL] TRIP for gateways
References: <B65B4F8437968F488A01A940B21982BF9AABFA@DYN-EXCH-001.dynamicsoft.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 27 Nov 2000 15:45:44 -0800
Content-Transfer-Encoding: 7bit



Jonathan Rosenberg wrote:
> 
> Folks,
> 
> At the last two meetings, Hussein and I have presented a draft on the usage
> of TRIP for gateways. The problem that the draft is trying to address comes
> up more and more, and it is becoming urgent that the group come to some kind
> of decision regarding this work. We can discuss this at the meeting, of
> course, but I'd much prefer to start a list discussion first so we can
> identify what the problems are.

Before going into the details of SLP and TRIP, we need to agree on the
requirements. Here are a few questions to get started:
- Is multi-hop call routing a requirement for intra-domain calls? Or is
a single-hop sufficient?
- Is aggregation within a domain required?
- Is it required to advertise the services (e.g. voice or fax) and
capabilities (e.g. which codecs) a specific route supports?
- Dynamic attributes, e.g. residual capacity of GW?
- What's the required convergence time when a route changes?
- Gateway registration vs. intra-domain call routing, are they different
problems?

Thanks.

Hussein


> 
> As I recall from the last meeting, one of the concerns raised was that BGP
> is bad for intra-domain route propagation. Since this is an intra-domain
> issue (intra-ITAD in our terminology), TRIP, being a bGP4 equivalent, is ill
> suited. I thought about this, and came to the conclusion that intra-domain
> route propagation for VoIP is different from IP. I would expect ITADs to
> have many LSs, and which routes an LS uses for a particular call is still
> very much a policy issue. IP layer intra-domain protocols like OSPF are
> simply topology flooding mechanisms. Policy doesn't play a role. You are
> always looking to take the least cost route. Not so here; the direction a
> call is routed within a domain still depends on administrative policy. So,
> it seems that it would be useful to still run TRIP between LS's within an
> ITAD.
> 
> Another issue raised was that SLP appeared more appropriate than TRIP, as
> this was a service advertisement issue (specifically, the gateway would send
> out SLP service advertisement messages to the LS). I don't think SLP is
> really quite right here. For example, in SLP, service advertisements need to
> be refreshed by resending the service template. This would mean that a
> gateway would need to periodically resend its entire routing table. Seems
> inefficient compared to the much smaller keepalive in TRIP. The smaller
> keepalive means that it can be sent more often, resulting in a much more
> rapid failure detection.
> 
> 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.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

-- 
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  Tue Nov 28 15:35:07 2000
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 PAA05200
	for <iptel-archive@odin.ietf.org>; Tue, 28 Nov 2000 15:35:04 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6458544365; Tue, 28 Nov 2000 14:35:02 -0500 (EST)
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 8ADB244356
	for <iptel@lists.bell-labs.com>; Tue, 28 Nov 2000 14:33:56 -0500 (EST)
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 PAA27383;
	Tue, 28 Nov 2000 15:33:43 -0500 (EST)
Received: (from lennox@localhost)
	by conrail.cs.columbia.edu (8.9.3/8.9.1) id PAA75867;
	Tue, 28 Nov 2000 15:33:43 -0500 (EST)
	(envelope-from lennox)
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14884.5798.966433.783539@conrail.cs.columbia.edu>
To: Jiri Kuthan <kuthan@fokus.gmd.de>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
In-Reply-To: <3A1AC782.3963ADFF@fokus.gmd.de>
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com>
	<3A1AC782.3963ADFF@fokus.gmd.de>
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 28 Nov 2000 15:33:42 -0500 (EST)
Content-Transfer-Encoding: 7bit

On Tuesday, November 21 2000, "Jiri Kuthan" wrote to "Jonathan Rosenberg, 'iptel@lists.bell-labs.com'" saying:

> Jonathan,
> 
> I would like to see three CPL extensions:
> - authentication support -- useful if signaling depends
>   on user credentials

I agree this is useful.  One big hole in CPL as it is now is that you can
have your call handling be based on the origin, but in SIP as it exists now,
there's no guarantee that someone claiming to be kuthan@fokus.gmd.de
actually is that person.

Unfortunately, this is a bigger problem than just for CPL.  While I would
love to have some way of switching on authenticated addresses in CPL, it
first needs to be figured out how to do this in IP telephony in gneeral, or
at least in specific protocals such as SIP.  Once a framework for this is
worked out, we can figure out how best to map these things into CPL.

I don't think IPTel is the right forum for doing this sort of thing, though
certainly the needs of a CPL authentication switch would be a major
requirement sent as input to that process.  (Given that it would probably be
much the same *people* doing this, I don't think a formal liaison statement
from the IPTel working group to the SIP working group listing authentication
requirements would be too helpful, though.)

> - access to external databases -- useful with long shared lists

The idea being to have something like the "rogue site blacklists" used for
E-Mail to cooperatively block spammers?  This would be useful; I don't
really understand the syntax you were proposing, though.

> - support for usage of CPL in end-devices -- useful if CPL services 
>   are stored at a SIM card which the users put into different cell
>   phones  (we already had this on the list, a solution could look 
>   like <ring user_profile="ring_and_shake">)

I agree with this, but we need a clearer picture of what the capabilities
and requirements should be.

-- 
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 Nov 28 15:40:04 2000
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 PAA06550
	for <iptel-archive@odin.ietf.org>; Tue, 28 Nov 2000 15:40:03 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0DDFC44395; Tue, 28 Nov 2000 14:40:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7])
	by lists.bell-labs.com (Postfix) with ESMTP id 87C9344388
	for <iptel@lists.bell-labs.com>; Tue, 28 Nov 2000 14:39:11 -0500 (EST)
Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204])
	by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id UAA02241
	for <iptel@lists.bell-labs.com>; Tue, 28 Nov 2000 20:39:03 GMT
From: Jon.Peterson@Level3.com
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id UAA11601
	for <iptel@lists.bell-labs.com>; Tue, 28 Nov 2000 20:39:02 GMT
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id <XMH8R0LT>; Tue, 28 Nov 2000 13:41:00 -0700
Message-ID: <87A245E94948D3118DE30008C716B01301523CC9@c0005v1idc1.oss.level3.com>
To: iptel@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C0597B.39322150"
Subject: [IPTEL] FW: I-D ACTION:draft-jfp-trip-servicecodes-00.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 28 Nov 2000 13:38:54 -0700

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_01C0597B.39322150
Content-Type: text/plain;
	charset="iso-8859-1"


I'd like to offer an advertisement for a draft I submitted on a proposed
'ServiceCode' attribute for TRIP to be used for propagating routes from VoIP
network applications. I'd appreciate any comments.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] 
Sent: Tuesday, November 21, 2000 3:57 AM
Subject: I-D ACTION:draft-jfp-trip-servicecodes-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: The ServiceCode Attribute for TRIP
	Author(s)	: J. Peterson
	Filename	: draft-jfp-trip-servicecodes-00.txt
	Pages		: 9
	Date		: 20-Nov-00
	
Telephony Routing over IP (TRIP) [2] provides a means for entities in
a VoIP network to advertise telephony routes to their peers. No
assumption can be made about the treatment which is offered by an
endpoint propagating a route - it could intend to terminate the call
in some fashion or apply services to the call. This document proposes
an optional ServiceCode attribute propagated along with such routes
which provides more information about the services offered by the
originator.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jfp-trip-servicecodes-00.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-jfp-trip-servicecodes-00.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-jfp-trip-servicecodes-00.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_000_01C0597B.39322150
Content-Type: message/rfc822

To: 
Subject: 
Date: Tue, 28 Nov 2000 13:41:00 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C0597B.39322150"


------_=_NextPart_002_01C0597B.39322150
Content-Type: text/plain



------_=_NextPart_002_01C0597B.39322150
Content-Type: application/octet-stream;
	name="ATT33123"
Content-Disposition: attachment;
	filename="ATT33123"

Content-type: message/external-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20001120151347.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-jfp-trip-servicecodes-00.txt

------_=_NextPart_002_01C0597B.39322150
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-jfp-trip-servicecodes-00.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"


------_=_NextPart_002_01C0597B.39322150--

------_=_NextPart_000_01C0597B.39322150--

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 28 15:57:02 2000
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 PAA12147
	for <iptel-archive@odin.ietf.org>; Tue, 28 Nov 2000 15:57:01 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 13CB944375; Tue, 28 Nov 2000 14:57:03 -0500 (EST)
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 E4EB344356
	for <iptel@lists.bell-labs.com>; Tue, 28 Nov 2000 14:56:53 -0500 (EST)
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 PAA28686;
	Tue, 28 Nov 2000 15:56:36 -0500 (EST)
Received: (from lennox@localhost)
	by conrail.cs.columbia.edu (8.9.3/8.9.1) id PAA75915;
	Tue, 28 Nov 2000 15:56:35 -0500 (EST)
	(envelope-from lennox)
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14884.7171.8876.176847@conrail.cs.columbia.edu>
To: Cliff.Harris@nokia.com
Cc: iptel@lists.bell-labs.com
Subject: Re: [IPTEL] CPL Question About Priority
In-Reply-To: <E39024226822D311BC880008C77318A1019C59EB@oteis01nok>
References: <E39024226822D311BC880008C77318A1019C59EB@oteis01nok>
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 28 Nov 2000 15:56:35 -0500 (EST)
Content-Transfer-Encoding: 7bit

On Monday, November 27 2000, "Cliff.Harris@nokia.com" wrote to "iptel@lists.bell-labs.com" saying:

> The "location" node has an optional "priority" parameter, but the "lookup"
> node does not. Nor does the CPL draft specify the priority of the location
> initially in the location set for an outgoing call. 

The assumption is that lookups will supply priorities.  The model is of SIP
registrations, which have associated 'q' values.

It's true that there's no priority specified for the initial address.  I
suppose it should be 1.0.

> Suppose I wanted to write a script that, for outgoing calls, tried some
> other number first, and if that call failed, then tried the original number.
> It seems to me that there is no portable way of doing that, since the
> priority of the location initially in the location set is not specified.

No, there isn't any way to do this in the CPL.  In what circumstance would
you want to do it?  Remember that CPL is deliberately not a Turing-complete
language, and deliberately we restricted it to only the sorts of component
primitives that we thought would be useful.

> Section 7.1 says, "The priority of locations in a set is determined by
> server policy, though CPL servers SHOULD honor the priority parameter of the
> location tag." Why is this only a SHOULD and not a MUST? And why are no
> priorities defined for the other cases mentioned above?

I didn't see any reason to force a MUST, in case there were other server
policies that were invoked.

-- 
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 Nov 28 16:05:03 2000
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 QAA14022
	for <iptel-archive@odin.ietf.org>; Tue, 28 Nov 2000 16:05:01 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E6EF044396; Tue, 28 Nov 2000 15:05:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from Mitel.COM (unknown [198.53.180.100])
	by lists.bell-labs.com (Postfix) with ESMTP id 02C6244336
	for <iptel@lists.bell-labs.com>; Tue, 28 Nov 2000 15:04:18 -0500 (EST)
Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) 
	by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id QAA22110;
	Tue, 28 Nov 2000 16:03:35 -0500 (EST)
Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 852569A5.0073AE14 ; Tue, 28 Nov 2000 16:03:32 -0500
X-Lotus-FromDomain: MITEL
From: Tom_Gray@Mitel.COM
To: Jonathan Lennox <lennox@cs.columbia.edu>
Cc: Cliff.Harris@nokia.com, iptel@lists.bell-labs.com
Message-ID: <852569A5.0073AC45.00@kanmta01.software.mitel.com>
Subject: Re: [IPTEL] CPL Question About Priority
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 28 Nov 2000 16:03:27 -0500



From:  Tom Gray@MITEL on 11/28/2000 04:03 PM

This would be useful for 'one number' services in whjch a priority list of
numbers are given where  person possibly may be found.  Wheter CPL is an
appropriate mechanism to program such a feature is problematic.






Jonathan Lennox <lennox@cs.columbia.edu> on 11/28/2000 03:56:35 PM

To:   Cliff.Harris@nokia.com
cc:   iptel@lists.bell-labs.com (bcc: Tom Gray/Kan/Mitel)

Subject:  Re: [IPTEL] CPL Question About Priority



On Monday, November 27 2000, "Cliff.Harris@nokia.com" wrote to
"iptel@lists.bell-labs.com" saying:

> The "location" node has an optional "priority" parameter, but the "lookup"
> node does not. Nor does the CPL draft specify the priority of the location
> initially in the location set for an outgoing call.

The assumption is that lookups will supply priorities.  The model is of SIP
registrations, which have associated 'q' values.

It's true that there's no priority specified for the initial address.  I
suppose it should be 1.0.

> Suppose I wanted to write a script that, for outgoing calls, tried some
> other number first, and if that call failed, then tried the original number.
> It seems to me that there is no portable way of doing that, since the
> priority of the location initially in the location set is not specified.

No, there isn't any way to do this in the CPL.  In what circumstance would
you want to do it?  Remember that CPL is deliberately not a Turing-complete
language, and deliberately we restricted it to only the sorts of component
primitives that we thought would be useful.

> Section 7.1 says, "The priority of locations in a set is determined by
> server policy, though CPL servers SHOULD honor the priority parameter of the
> location tag." Why is this only a SHOULD and not a MUST? And why are no
> priorities defined for the other cases mentioned above?

I didn't see any reason to force a MUST, in case there were other server
policies that were invoked.

--
Jonathan Lennox
lennox@cs.columbia.edu

_______________________________________________
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  Tue Nov 28 16:10:16 2000
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 QAA15812
	for <iptel-archive@odin.ietf.org>; Tue, 28 Nov 2000 16:10:13 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8588C443A9; Tue, 28 Nov 2000 15:10:02 -0500 (EST)
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 EC6E244372
	for <iptel@lists.bell-labs.com>; Tue, 28 Nov 2000 15:09:09 -0500 (EST)
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 QAA29519;
	Tue, 28 Nov 2000 16:08:56 -0500 (EST)
Received: (from lennox@localhost)
	by conrail.cs.columbia.edu (8.9.3/8.9.1) id QAA75940;
	Tue, 28 Nov 2000 16:08:56 -0500 (EST)
	(envelope-from lennox)
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14884.7911.823795.463182@conrail.cs.columbia.edu>
To: Tom_Gray@Mitel.COM
Cc: Cliff.Harris@nokia.com, iptel@lists.bell-labs.com
Subject: Re: [IPTEL] CPL Question About Priority
In-Reply-To: <852569A5.0073AC45.00@kanmta01.software.mitel.com>
References: <852569A5.0073AC45.00@kanmta01.software.mitel.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 28 Nov 2000 16:08:55 -0500 (EST)
Content-Transfer-Encoding: 7bit

On Tuesday, November 28 2000, "Tom_Gray@Mitel.COM" wrote to "Jonathan Lennox, Cliff.Harris@nokia.com, iptel@lists.bell-labs.com" saying:

> 
> 
> From:  Tom Gray@MITEL on 11/28/2000 04:03 PM
> 
> This would be useful for 'one number' services in whjch a priority list of
> numbers are given where  person possibly may be found.  Wheter CPL is an
> appropriate mechanism to program such a feature is problematic.

'One number' services are a standard CPL feature -- on the *destination*
side, where the list of locations is provided through <location> or <lookup>
nodes.  I could even potentially see such services on an origination side,
as in "if I call Joe@home, assume I really mean both Joe@home and
Joe@hiscellphone".  But I understood the the feature Cliff was describing as
"If I call anyone at Example Industries, first place my call to the Example
Industries switchboard, then try that specific person."  It's not clear to
me why anyone would ever want such a feature for their outgoing call script.

-- 
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 Nov 28 16:43:25 2000
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 QAA29383
	for <iptel-archive@odin.ietf.org>; Tue, 28 Nov 2000 16:43:22 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F1F18443AC; Tue, 28 Nov 2000 15:42:14 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by lists.bell-labs.com (Postfix) with ESMTP id CBF0044352
	for <iptel@lists.bell-labs.com>; Tue, 28 Nov 2000 15:41:42 -0500 (EST)
Received: from fokus.gmd.de (dhcp116 [195.37.78.244])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id WAA07307;
	Tue, 28 Nov 2000 22:41:15 +0100 (MET)
Message-ID: <3A242555.34539EFD@fokus.gmd.de>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Organization: GMD Fokus
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Lennox <lennox@cs.columbia.edu>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com>
		<3A1AC782.3963ADFF@fokus.gmd.de> <14884.5798.966433.783539@conrail.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 28 Nov 2000 22:36:21 +0100
Content-Transfer-Encoding: 7bit

Jonathan Lennox wrote:
> Unfortunately, this is a bigger problem than just for CPL.  While I would
> love to have some way of switching on authenticated addresses in CPL, it
> first needs to be figured out how to do this in IP telephony in gneeral, or
> at least in specific protocals such as SIP.  Once a framework for this is
> worked out, we can figure out how best to map these things into CPL.
> 
> I don't think IPTel is the right forum for doing this sort of thing, though
> certainly the needs of a CPL authentication switch would be a major
> requirement sent as input to that process. [...]

Actually, I'd like to have authentication switching dependent on
authentication id and independent on authentication mechanism. The
place where mechanism-dependencies is unavoidable is the credential 
database. 

The authentication switch can be specified at iptel because it is 
independent on the mechanism. Authentication protocols come and go
and should not affect authentication switching. I'm not sure what 
the most appropriate place for working on a specification of the 
credential database format is.

> The idea being to have something like the "rogue site blacklists" used for
> E-Mail to cooperatively block spammers?  

Exactly.

> This would be useful; I don't really understand the syntax you were proposing, though.

The idea behind that particular proposal is to enable accessing the lists
from any place (address switches, string switches, whatever) without changing
CPL's syntax. The hack is to indicate with an escape sequence that a value
should be interpreted as a reference to a list. E.g., 
  <address is="@@http://www.nospam.org/badguys.txt">
	<reject/>

I do not insist on this particular syntax, other ideas are appreciated.

> > - support for usage of CPL in end-devices [...]
> 
> I agree with this, but we need a clearer picture of what the capabilities
> and requirements should be.

Yes. What is IMHO needed is an operation that passes signaling control
to human user and allows to specify how the user is rung in a device-
independent manner. (I.e., what Figure 27 shows in -04 I-D.) Any other 
suggestions/requirements?

Jiri

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 28 17:05:02 2000
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 RAA10695
	for <iptel-archive@odin.ietf.org>; Tue, 28 Nov 2000 17:05:01 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1F445443A1; Tue, 28 Nov 2000 16:05:03 -0500 (EST)
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 EC0114436A
	for <iptel@lists.bell-labs.com>; Tue, 28 Nov 2000 16:04:23 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA03490;
	Tue, 28 Nov 2000 17:04:05 -0500 (EST)
Message-ID: <3A242BD5.38423D7C@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jiri Kuthan <kuthan@fokus.gmd.de>
Cc: Jonathan Lennox <lennox@orion.cs.columbia.edu>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com>
			<3A1AC782.3963ADFF@fokus.gmd.de> <14884.5798.966433.783539@conrail.cs.columbia.edu> <3A242555.34539EFD@fokus.gmd.de>
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 28 Nov 2000 17:04:05 -0500
Content-Transfer-Encoding: 7bit

Jiri Kuthan wrote:
> 
> Jonathan Lennox wrote:
> > Unfortunately, this is a bigger problem than just for CPL.  While I would
> > love to have some way of switching on authenticated addresses in CPL, it
> > first needs to be figured out how to do this in IP telephony in gneeral, or
> > at least in specific protocals such as SIP.  Once a framework for this is
> > worked out, we can figure out how best to map these things into CPL.
> >
> > I don't think IPTel is the right forum for doing this sort of thing, though
> > certainly the needs of a CPL authentication switch would be a major
> > requirement sent as input to that process. [...]
> 
> Actually, I'd like to have authentication switching dependent on
> authentication id and independent on authentication mechanism. The
> place where mechanism-dependencies is unavoidable is the credential
> database.
> 
> The authentication switch can be specified at iptel because it is
> independent on the mechanism. Authentication protocols come and go
> and should not affect authentication switching. I'm not sure what
> the most appropriate place for working on a specification of the
> credential database format is.

In practice, this is not likely to be as big a deal. Authentication at
CPL level is primarily useful for rejecting spammers, as mentioned, and
possibly to give access to otherwise restricted destinations to
'special' people. For that, we have three levels of 

- make sure the caller can be reached - to prevent the SIP version of
kids ringing doorbells and running away

- make sure that the caller's SIP or H.323 address is legitimate. One
could, for example, build a UA that doesn't accept calls, but rather
returns the INVITE with the same Call-ID or other token to the caller.
Assuming intercept is not likely, this is reasonably secure and requires
no PKI.

- set up secrets ahead of time, by (e.g.,) emailing them to the caller,
similar to how most level-1 certificates work

- full-fledged PKI. Not likely except in closed communities, i.e., at
best useful for the second application of authentication.

CPL doesn't have to know anything about the details, just needs to
convey the level of authentication used to verify the identity, allowing
the script to make appropriate choices.

> 
> The idea behind that particular proposal is to enable accessing the lists
> from any place (address switches, string switches, whatever) without changing
> CPL's syntax. The hack is to indicate with an escape sequence that a value
> should be interpreted as a reference to a list. E.g.,
>   <address is="@@http://www.nospam.org/badguys.txt">
>         <reject/>
> 
> I do not insist on this particular syntax, other ideas are appreciated.

I have to admit that I find this type of URL special-casing less than
savory. If you want to check for a list, create a new qualifier other
than 'is'.


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 28 21:19:02 2000
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 VAA16465
	for <iptel-archive@odin.ietf.org>; Tue, 28 Nov 2000 21:19:01 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0004B4434F; Tue, 28 Nov 2000 20:19:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by lists.bell-labs.com (Postfix) with ESMTP id A4A1344341
	for <iptel@lists.bell-labs.com>; Tue, 28 Nov 2000 20:18:16 -0500 (EST)
Received: from fokus.gmd.de (dhcp116 [195.37.78.244])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id DAA27798;
	Wed, 29 Nov 2000 03:17:59 +0100 (MET)
Message-ID: <3A2465D8.8A2575F1@fokus.gmd.de>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Organization: GMD Fokus
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: Jonathan Lennox <lennox@orion.cs.columbia.edu>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com>
				<3A1AC782.3963ADFF@fokus.gmd.de> <14884.5798.966433.783539@conrail.cs.columbia.edu> <3A242555.34539EFD@fokus.gmd.de> <3A242BD5.38423D7C@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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 03:11:36 +0100
Content-Transfer-Encoding: 7bit

"Henning G. Schulzrinne" wrote:
> >   <address is="@@http://www.nospam.org/badguys.txt">
> >         <reject/>
> I have to admit that I find this type of URL special-casing less than
> savory. If you want to check for a list, create a new qualifier other
> than 'is'.

Why could not I indicate list iteration in the operand (as opposed
to operator) and interpret 'is=<somelist:={a,b,c,...}>' as
'is a OR is b OR is C or ...' ? 

Such an interpretation does not sound violent to me. I can also think 
of embedded lists such as is="a | b | c" -- they would save some script 
typing as opposed to an enumeration is=a, is=b, is=c.

An overview of the alternatives is attached. They differ
in whether list iteration and exteral reference are 
indicated in operator or operand. They include the possibility
of embedded lists as an option. 

Any preference? 

Jiri

----

			| External References
        Multiple Values |  by operand    |   by operator
			| (w/escape)     |  (per switch)
       -----------------+----------------+----------------
            by operand  |       A        |       B
       (redefinition of |                |
        operand meaning)|	         |
       -----------------+----------------+----------------
            by operator |       C        |       D
       (+per switch)    |                |


A) URL by operand, list by operand
remote list:	         <address is="@@http://www.nospam.org/badguys.txt">    
local list (optional):   <address is="a@ex.com | b@yahoo.com | @@http....">  

=> no new operator needed, 1-2 operand changes needed

B) URL by operator, list by operand
rl:	<address is_aturl="http://www.nospam.org/badguys.txt">	
	(the same goes for contains and subdomain-of)
ll(o.):  <address is="a@ex.com | b@yahoo.com">    

=> 3 new operators (for each switch, incl. accompanying operands), 
   0-1 operand change needed

C) URL by operand, list by operator
rl:	  <address is_anyof="@@http://www.nospam.org/badguys.txt">   
	  (the same goes for contains and subdomain-of)
ll:       <address is_anyof="a@ex.com | b@yahoo.com | @@http...."> 
	  (the same goes for contains and subdomain-of)

=> 3 new operators (for each switch, incl. accompanying operands),  
   1 operand change needed

D) URL by operator, list by operator
rl:	<address is_anyof_aturl="http://www.nospam.org/badguys.txt">   
	(the same goes for contains and subdomain-of)
ll(o.): <address is_anyof="a@ex.com | b@yahoo.com"> 
	(the same goes for contains and subdomain-of)

=> 3-6 new operators (incl. accompanying operands),  0 operand 
   change needed

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Nov 28 21:52:04 2000
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 VAA00100
	for <iptel-archive@odin.ietf.org>; Tue, 28 Nov 2000 21:52:03 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9C46A443A3; Tue, 28 Nov 2000 20:52:03 -0500 (EST)
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 DF6FF44341
	for <iptel@lists.bell-labs.com>; Tue, 28 Nov 2000 20:51:52 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA22799;
	Tue, 28 Nov 2000 21:51:41 -0500 (EST)
Message-ID: <3A246F3D.6CCC7168@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jiri Kuthan <kuthan@fokus.gmd.de>
Cc: Jonathan Lennox <lennox@orion.cs.columbia.edu>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com>
					<3A1AC782.3963ADFF@fokus.gmd.de> <14884.5798.966433.783539@conrail.cs.columbia.edu> <3A242555.34539EFD@fokus.gmd.de> <3A242BD5.38423D7C@cs.columbia.edu> <3A2465D8.8A2575F1@fokus.gmd.de>
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 28 Nov 2000 21:51:41 -0500
Content-Transfer-Encoding: 7bit

Jiri Kuthan wrote:
> 
> "Henning G. Schulzrinne" wrote:
> > >   <address is="@@http://www.nospam.org/badguys.txt">
> > >         <reject/>
> > I have to admit that I find this type of URL special-casing less than
> > savory. If you want to check for a list, create a new qualifier other
> > than 'is'.
> 
> Why could not I indicate list iteration in the operand (as opposed
> to operator) and interpret 'is=<somelist:={a,b,c,...}>' as
> 'is a OR is b OR is C or ...' ?
> 
> Such an interpretation does not sound violent to me. I can also think
> of embedded lists such as is="a | b | c" -- they would save some script
> typing as opposed to an enumeration is=a, is=b, is=c.

Yes, but the problem is that you're now making certain characters
special in the string. Leads to escaping, special syntax. Since CPL is
not primarily meant to be written by hand, I'd rather let the XML parser
do all the parsing rather than writing another expression parser.

> 
> An overview of the alternatives is attached. They differ
> in whether list iteration and exteral reference are
> indicated in operator or operand. They include the possibility
> of embedded lists as an option.
> 
> Any preference?

As I indicated above, doing expressions in "" arguments is, in my view,
a real big hack, complicated to implement and leading to escaping and
spacing nightmares (foo|bar is now possibly different than foo | bar).

> 
> Jiri
> 
> ----
> 
>                         | External References
>         Multiple Values |  by operand    |   by operator
>                         | (w/escape)     |  (per switch)
>        -----------------+----------------+----------------
>             by operand  |       A        |       B
>        (redefinition of |                |
>         operand meaning)|                |
>        -----------------+----------------+----------------
>             by operator |       C        |       D
>        (+per switch)    |                |
> 
> A) URL by operand, list by operand
> remote list:             <address is="@@http://www.nospam.org/badguys.txt">
> local list (optional):   <address is="a@ex.com | b@yahoo.com | @@http....">
> 
> => no new operator needed, 1-2 operand changes needed
> 
> B) URL by operator, list by operand
> rl:     <address is_aturl="http://www.nospam.org/badguys.txt">
>         (the same goes for contains and subdomain-of)
> ll(o.):  <address is="a@ex.com | b@yahoo.com">
> 
> => 3 new operators (for each switch, incl. accompanying operands),
>    0-1 operand change needed
> 
> C) URL by operand, list by operator
> rl:       <address is_anyof="@@http://www.nospam.org/badguys.txt">
>           (the same goes for contains and subdomain-of)
> ll:       <address is_anyof="a@ex.com | b@yahoo.com | @@http....">
>           (the same goes for contains and subdomain-of)
> 
> => 3 new operators (for each switch, incl. accompanying operands),
>    1 operand change needed
> 
> D) URL by operator, list by operator
> rl:     <address is_anyof_aturl="http://www.nospam.org/badguys.txt">
>         (the same goes for contains and subdomain-of)
> ll(o.): <address is_anyof="a@ex.com | b@yahoo.com">
>         (the same goes for contains and subdomain-of)
> 
> => 3-6 new operators (incl. accompanying operands),  0 operand
>    change needed
>

None of these ll options are, in my view, acceptable. We have nesting
and alternatives at the CPL level, so there's no need to replicated
this.


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 29 09:32:03 2000
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 JAA13915
	for <iptel-archive@odin.ietf.org>; Wed, 29 Nov 2000 09:32:02 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7DDB244351; Wed, 29 Nov 2000 08:32:02 -0500 (EST)
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 16A1844341
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 05:28:00 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29867;
	Wed, 29 Nov 2000 06:27:50 -0500 (EST)
Message-Id: <200011291127.GAA29867@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-04.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 06:27:50 -0500

--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-04.txt
	Pages		: 80
	Date		: 28-Nov-00
	
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-04.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-04.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-04.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:	<20001128133702.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-iptel-trip-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-iptel-trip-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20001128133702.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  Wed Nov 29 09:50:43 2000
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 JAA20676
	for <iptel-archive@odin.ietf.org>; Wed, 29 Nov 2000 09:50:43 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 52095443A4; Wed, 29 Nov 2000 08:50:03 -0500 (EST)
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 41B54443A4
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 08:49:41 -0500 (EST)
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 JAA23231
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 09:52:01 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X2075H1G>; Wed, 29 Nov 2000 09:47:37 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AACD4@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: FW: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-04.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C05A13.501B3416"
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 09:47:36 -0500

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_01C05A13.501B3416
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Folks,

As you can see, draft -04 of TRIP has now appeared in the archives. As =
such,
I would like to now issue a two week working group last call on this
document. We will have time at IETF to discuss any comments received, =
if
necessary.

I'd also like to thank Hussein Salama and Matt Squire for their =
continuous
work in getting this completed.

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.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
=20

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Wednesday, November 29, 2000 6:28 AM
To: IETF-Announce
Cc: iptel@lists.bell-labs.com
Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-trip-04.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-04.txt
	Pages		: 80
	Date		: 28-Nov-00
=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-04.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-04.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-04.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_01C05A13.501B3416
Content-Type: message/rfc822

To: 
Subject: 
Date: Wed, 29 Nov 2000 09:47:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C05A13.501B3416"


------_=_NextPart_002_01C05A13.501B3416
Content-Type: text/plain



------_=_NextPart_002_01C05A13.501B3416
Content-Type: application/octet-stream;
	name="ATT09985.txt"
Content-Disposition: attachment;
	filename="ATT09985.txt"

Content-type: message/external-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20001128133702.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-iptel-trip-04.txt

------_=_NextPart_002_01C05A13.501B3416
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-ietf-iptel-trip-04.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"


------_=_NextPart_002_01C05A13.501B3416--

------_=_NextPart_000_01C05A13.501B3416--

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 29 09:56:03 2000
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 JAA23063
	for <iptel-archive@odin.ietf.org>; Wed, 29 Nov 2000 09:56:02 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 69BAA443AF; Wed, 29 Nov 2000 08:51:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141])
	by lists.bell-labs.com (Postfix) with ESMTP id 0DAA8443AA
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 08:50:20 -0500 (EST)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA28027; Wed, 29 Nov 2000 09:50:10 -0500 (EST)
Received: from mhammer-nt.cisco.com (va-dhcp198-137.cisco.com [161.44.198.137])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AEY04235;
	Wed, 29 Nov 2000 09:50:09 -0500 (EST)
Message-Id: <4.3.2.7.2.20001129095126.00ba46b0@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Jonathan Lennox <lennox@cs.columbia.edu>, Tom_Gray@Mitel.COM
From: hammer michael <mhammer@cisco.com>
Subject: Re: [IPTEL] CPL Question About Priority
Cc: Cliff.Harris@nokia.com, iptel@lists.bell-labs.com
In-Reply-To: <14884.7911.823795.463182@conrail.cs.columbia.edu>
References: <852569A5.0073AC45.00@kanmta01.software.mitel.com>
 <852569A5.0073AC45.00@kanmta01.software.mitel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 09:56:10 -0800

You could potentially have a network selection based on dynamic network 
characteristics.
Route through network A (the cheapest) unless it is congested or denies me 
service,
otherwise route through network B while QoS > X, else ...

I know that bandwidth is supposed to be free and plentiful, but could you 
foresee networks of the future dynamically changing their rates based on 
demand and users selecting the better alternatives for routing?

Mike


At 04:08 PM 11/28/2000 -0500, Jonathan Lennox wrote:
>On Tuesday, November 28 2000, "Tom_Gray@Mitel.COM" wrote to "Jonathan 
>Lennox, Cliff.Harris@nokia.com, iptel@lists.bell-labs.com" saying:
>
> >
> >
> > From:  Tom Gray@MITEL on 11/28/2000 04:03 PM
> >
> > This would be useful for 'one number' services in whjch a priority list of
> > numbers are given where  person possibly may be found.  Wheter CPL is an
> > appropriate mechanism to program such a feature is problematic.
>
>'One number' services are a standard CPL feature -- on the *destination*
>side, where the list of locations is provided through <location> or <lookup>
>nodes.  I could even potentially see such services on an origination side,
>as in "if I call Joe@home, assume I really mean both Joe@home and
>Joe@hiscellphone".  But I understood the the feature Cliff was describing as
>"If I call anyone at Example Industries, first place my call to the Example
>Industries switchboard, then try that specific person."  It's not clear to
>me why anyone would ever want such a feature for their outgoing call script.
>
>--
>Jonathan Lennox
>lennox@cs.columbia.edu
>
>_______________________________________________
>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  Wed Nov 29 10:03:03 2000
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 KAA25936
	for <iptel-archive@odin.ietf.org>; Wed, 29 Nov 2000 10:03:02 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A0C8E4438F; Wed, 29 Nov 2000 09:02:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141])
	by lists.bell-labs.com (Postfix) with ESMTP id 87FE644364
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 09:01:56 -0500 (EST)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA28219; Wed, 29 Nov 2000 10:01:48 -0500 (EST)
Received: from mhammer-nt.cisco.com (va-dhcp198-137.cisco.com [161.44.198.137])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AEY04380;
	Wed, 29 Nov 2000 10:01:47 -0500 (EST)
Message-Id: <4.3.2.7.2.20001129100625.00b8bca0@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Jonathan Lennox <lennox@cs.columbia.edu>, Tom_Gray@Mitel.COM
From: hammer michael <mhammer@cisco.com>
Subject: Re: [IPTEL] CPL Question About Priority
Cc: Cliff.Harris@nokia.com, iptel@lists.bell-labs.com
In-Reply-To: <14884.7911.823795.463182@conrail.cs.columbia.edu>
References: <852569A5.0073AC45.00@kanmta01.software.mitel.com>
 <852569A5.0073AC45.00@kanmta01.software.mitel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 10:07:48 -0800

An additional thought:

What if I as a service provider wanted to differentiate service between 
paying and non-paying customers?
Based on the origination number, I give better or worse service.

Mike


At 04:08 PM 11/28/2000 -0500, Jonathan Lennox wrote:
>On Tuesday, November 28 2000, "Tom_Gray@Mitel.COM" wrote to "Jonathan 
>Lennox, Cliff.Harris@nokia.com, iptel@lists.bell-labs.com" saying:
>
> >
> >
> > From:  Tom Gray@MITEL on 11/28/2000 04:03 PM
> >
> > This would be useful for 'one number' services in whjch a priority list of
> > numbers are given where  person possibly may be found.  Wheter CPL is an
> > appropriate mechanism to program such a feature is problematic.
>
>'One number' services are a standard CPL feature -- on the *destination*
>side, where the list of locations is provided through <location> or <lookup>
>nodes.  I could even potentially see such services on an origination side,
>as in "if I call Joe@home, assume I really mean both Joe@home and
>Joe@hiscellphone".  But I understood the the feature Cliff was describing as
>"If I call anyone at Example Industries, first place my call to the Example
>Industries switchboard, then try that specific person."  It's not clear to
>me why anyone would ever want such a feature for their outgoing call script.
>
>--
>Jonathan Lennox
>lennox@cs.columbia.edu
>
>_______________________________________________
>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  Wed Nov 29 10:17:58 2000
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 KAA02532
	for <iptel-archive@odin.ietf.org>; Wed, 29 Nov 2000 10:17:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 53C9C44385; Wed, 29 Nov 2000 09:18:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by lists.bell-labs.com (Postfix) with ESMTP id 31B1644366
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 09:17:22 -0500 (EST)
Received: from fokus.gmd.de (dhcp116 [195.37.78.244])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id QAA14585;
	Wed, 29 Nov 2000 16:16:55 +0100 (MET)
Message-ID: <3A251BEF.C0C76E45@fokus.gmd.de>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Organization: GMD Fokus
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: Jonathan Lennox <lennox@orion.cs.columbia.edu>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com>
						<3A1AC782.3963ADFF@fokus.gmd.de> <14884.5798.966433.783539@conrail.cs.columbia.edu> <3A242555.34539EFD@fokus.gmd.de> <3A242BD5.38423D7C@cs.columbia.edu> <3A2465D8.8A2575F1@fokus.gmd.de> <3A246F3D.6CCC7168@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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 16:08:31 +0100
Content-Transfer-Encoding: 7bit

"Henning G. Schulzrinne" wrote:
> As I indicated above, doing expressions in "" arguments is, in my view,
> a real big hack, complicated to implement and leading to escaping and
> spacing nightmares (foo|bar is now possibly different than foo | bar).
[...]
> None of these ll options are, in my view, acceptable. We have nesting
> and alternatives at the CPL level, so there's no need to replicated
> this.

Given the priority to retain meaning of operators used with existing
operands, the extensions could look like this:
- new operators that indicate that operand is to be evaluated as a list
- if prefixed by an escape sequence a list item is interpreted as
  a reference to an external list
Examples:

<address is_anyof="a@ex.com | b@yahoo.com | @@http://www.nospam.org/badguys.txt">
<subject contains_anyof="make money | for free | @@http://www.nospam.org/dirtywords.txt">

This syntax still uses the local list:
a) it is much more convenient for "vi-powered" writers
b) since it refers to a new operator, meaning of existing operands remains unchanged.

Does this make sense? If not, than the "only-external-lists" alternative
(i.e., new operators that indicate that operand is to be evulated as
a reference to external list) would look like:

<address is_anyof_aturl="http://www.nospam.org/badguys.txt">
<subject contains_anyof_aturl="http://www.nospam.org/dirtywords.txt">

Jiri

> > C) URL by operand, list by operator
> > rl:       <address is_anyof="@@http://www.nospam.org/badguys.txt">
> >           (the same goes for contains and subdomain-of)
> > ll:       <address is_anyof="a@ex.com | b@yahoo.com | @@http....">
> >           (the same goes for contains and subdomain-of)

> 
> --
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 29 11:47:52 2000
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 LAA05971
	for <iptel-archive@odin.ietf.org>; Wed, 29 Nov 2000 11:47:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2EF7D44398; Wed, 29 Nov 2000 10:46:03 -0500 (EST)
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 2A19B4433A
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 10:45:49 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA02716;
	Wed, 29 Nov 2000 11:45:33 -0500 (EST)
Message-ID: <3A2532AD.E88D9C23@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jiri Kuthan <kuthan@fokus.gmd.de>
Cc: Jonathan Lennox <lennox@orion.cs.columbia.edu>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com>
							<3A1AC782.3963ADFF@fokus.gmd.de> <14884.5798.966433.783539@conrail.cs.columbia.edu> <3A242555.34539EFD@fokus.gmd.de> <3A242BD5.38423D7C@cs.columbia.edu> <3A2465D8.8A2575F1@fokus.gmd.de> <3A246F3D.6CCC7168@cs.columbia.edu> <3A251BEF.C0C76E45@fokus.gmd.de>
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 11:45:33 -0500
Content-Transfer-Encoding: 7bit

I made my point a few times that I find syntax within "" arguments
dangerous and a recipe for escaping and parsing nightmares. I'm not sure
what else to say. No, I still don't find the syntax acceptable. CPL can
be written by vi, but that is, in the long run, not necessarily going to
be the most common means, so I see no need to optimize for that.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 29 12:25:59 2000
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 MAA20557
	for <iptel-archive@odin.ietf.org>; Wed, 29 Nov 2000 12:25:59 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D0B17443DA; Wed, 29 Nov 2000 11:23:02 -0500 (EST)
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 B8C77443D8
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 11:22:31 -0500 (EST)
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 MAA05181
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 12:22:23 -0500 (EST)
Received: (from lennox@localhost)
	by conrail.cs.columbia.edu (8.9.3/8.9.1) id MAA77267;
	Wed, 29 Nov 2000 12:22:23 -0500 (EST)
	(envelope-from lennox)
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14885.15183.100236.150424@conrail.cs.columbia.edu>
To: iptel@lists.bell-labs.com
Subject: Re: [IPTEL] CPL Question About Priority
In-Reply-To: <4.3.2.7.2.20001129095126.00ba46b0@cia.cisco.com>
References: <852569A5.0073AC45.00@kanmta01.software.mitel.com>
	<4.3.2.7.2.20001129095126.00ba46b0@cia.cisco.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 12:22:23 -0500 (EST)
Content-Transfer-Encoding: 7bit

On Wednesday, November 29 2000, "hammer michael" wrote to "Jonathan Lennox, Tom_Gray@Mitel.COM, Cliff.Harris@nokia.com, iptel@lists.bell-labs.com" saying:

> You could potentially have a network selection based on dynamic network 
> characteristics.
> Route through network A (the cheapest) unless it is congested or denies me 
> service,
> otherwise route through network B while QoS > X, else ...
> 
> I know that bandwidth is supposed to be free and plentiful, but could you 
> foresee networks of the future dynamically changing their rates based on 
> demand and users selecting the better alternatives for routing?

Yes, absolutely, but this is way out of scope for the CPL.  Remember, CPL
controls *signalling*, and the network selection you're talking about is for
*media*.

If I place a call to sip:foo@example.com, and the 200 response to the INVITE
has 128.59.19.147 in its SDP, I'm going to send my packets to 128.59.19.147,
regardless of what route my INVITE took.

If I'm using manyfolks, I'll also set up a resource reservation to that IP
address.  That's the point at which the service provider should intervene to
figure out what route they want my packets to take.

-- 
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  Wed Nov 29 12:36:07 2000
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 MAA24759
	for <iptel-archive@odin.ietf.org>; Wed, 29 Nov 2000 12:36:07 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 01BAB443EC; Wed, 29 Nov 2000 11:34:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by lists.bell-labs.com (Postfix) with ESMTP id E0D02443EC
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 11:33:45 -0500 (EST)
Received: from fokus.gmd.de (dhcp116 [195.37.78.244])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA05184;
	Wed, 29 Nov 2000 18:33:08 +0100 (MET)
Message-ID: <3A253BB6.C47C01BF@fokus.gmd.de>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Organization: GMD Fokus
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: Jonathan Lennox <lennox@orion.cs.columbia.edu>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com>
								<3A1AC782.3963ADFF@fokus.gmd.de> <14884.5798.966433.783539@conrail.cs.columbia.edu> <3A242555.34539EFD@fokus.gmd.de> <3A242BD5.38423D7C@cs.columbia.edu> <3A2465D8.8A2575F1@fokus.gmd.de> <3A246F3D.6CCC7168@cs.columbia.edu> <3A251BEF.C0C76E45@fokus.gmd.de> <3A2532AD.E88D9C23@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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 18:24:06 +0100
Content-Transfer-Encoding: 7bit

So this is the escape-free alternative:

  Adding new parameters to address and string switches. The parameters
  indicate that a value is a URL pointing to a list of values separated
  by a well-known delimiter. The condition matches if any of list items
  matches.

Examples:
  <address is_anyof="http://www.nospam.org/badguys.txt">
  <subject contains_anyof="ftp://www.nospam.org/dirtywords.txt">

Can we agree on this?

If so, how do will we deal with error handling? Does indication of timeout
and subaction for processing of failed list access sound reasonable?
I.e., something like 
  <address is_anyof="http://www.nospam.org/badguys.txt" 
	   timeout="10" error_handler="drop_call_and_log">

Jiri

"Henning G. Schulzrinne" wrote:
> 
> I made my point a few times that I find syntax within "" arguments
> dangerous and a recipe for escaping and parsing nightmares. I'm not sure
> what else to say. No, I still don't find the syntax acceptable. CPL can
> be written by vi, but that is, in the long run, not necessarily going to
> be the most common means, so I see no need to optimize for that.

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 29 14:11:12 2000
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 OAA25734
	for <iptel-archive@odin.ietf.org>; Wed, 29 Nov 2000 14:11:12 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E09564436D; Wed, 29 Nov 2000 13:11:01 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141])
	by lists.bell-labs.com (Postfix) with ESMTP id 50CCD4433A
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 13:10:09 -0500 (EST)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA01577; Wed, 29 Nov 2000 14:10:00 -0500 (EST)
Received: from mhammer-nt.cisco.com (va-dhcp198-137.cisco.com [161.44.198.137])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AEY07074;
	Wed, 29 Nov 2000 14:09:59 -0500 (EST)
Message-Id: <4.3.2.7.2.20001129134633.00b8e520@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Jonathan Lennox <lennox@cs.columbia.edu>, iptel@lists.bell-labs.com
From: hammer michael <mhammer@cisco.com>
Subject: Re: [IPTEL] CPL Question About Priority
In-Reply-To: <14885.15183.100236.150424@conrail.cs.columbia.edu>
References: <4.3.2.7.2.20001129095126.00ba46b0@cia.cisco.com>
 <852569A5.0073AC45.00@kanmta01.software.mitel.com>
 <4.3.2.7.2.20001129095126.00ba46b0@cia.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 14:16:00 -0800

I understand to an extent the distinction you are making, that the IP 
layer, given the end-point address can figure out how to route the packets 
carrying the media along with resource reservations.  However, the 
existence of Via, Route, and Record-Route parameters and the usage for 
routes longer than two proxies would seem to undermine the purity of your 
position.  Ultimately the purpose of signaling is to establish the media 
path, so they are not so totally divorced.

I thought that one of the evolutionary goals of the IP telephony was to put 
as much control in the hands of the end-user.  If such control is in the IP 
layer, how does the user control that?  Will that be a Web-level interface 
or must he be an IP guru?  I was envisioning a little more control in the 
Application layer via some more user-friendly features.  In the current 
PSTN, there is some level of stimulus signaling for customers to activate 
and deactivate features and program-in network codes and user phone numbers 
for forwarding.  I would expect that the level of user control would be 
much higher in IP telephony.

Do you see the network cloud operating transparently and what service you 
get is what you get?
Or is there another media-specific protocol that allows the user to 
explicitly control what network routes that his packets traverse?

Mike


At 12:22 PM 11/29/2000 -0500, Jonathan Lennox wrote:
>On Wednesday, November 29 2000, "hammer michael" wrote to "Jonathan 
>Lennox, Tom_Gray@Mitel.COM, Cliff.Harris@nokia.com, 
>iptel@lists.bell-labs.com" saying:
>
> > You could potentially have a network selection based on dynamic network
> > characteristics.
> > Route through network A (the cheapest) unless it is congested or denies me
> > service,
> > otherwise route through network B while QoS > X, else ...
> >
> > I know that bandwidth is supposed to be free and plentiful, but could you
> > foresee networks of the future dynamically changing their rates based on
> > demand and users selecting the better alternatives for routing?
>
>Yes, absolutely, but this is way out of scope for the CPL.  Remember, CPL
>controls *signalling*, and the network selection you're talking about is for
>*media*.
>
>If I place a call to sip:foo@example.com, and the 200 response to the INVITE
>has 128.59.19.147 in its SDP, I'm going to send my packets to 128.59.19.147,
>regardless of what route my INVITE took.
>
>If I'm using manyfolks, I'll also set up a resource reservation to that IP
>address.  That's the point at which the service provider should intervene to
>figure out what route they want my packets to take.
>
>--
>Jonathan Lennox
>lennox@cs.columbia.edu
>
>_______________________________________________
>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  Wed Nov 29 15:26:07 2000
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 PAA20833
	for <iptel-archive@odin.ietf.org>; Wed, 29 Nov 2000 15:26:06 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5CF5F44373; Wed, 29 Nov 2000 14:26:02 -0500 (EST)
Delivered-To: iptel@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id 3A51B44362
	for <iptel@share.research.bell-labs.com>; Wed, 29 Nov 2000 14:19:01 -0500 (EST)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Nov 29 15:16:52 EST 2000
Received: by lists.bell-labs.com (Postfix)
	id 7F9B344380; Wed, 29 Nov 2000 15:04:33 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from jaguar.stc.lucent.com (jaguar.stc.lucent.com [135.3.117.5])
	by lists.bell-labs.com (Postfix) with ESMTP id 4DF2B4437D
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 15:04:33 -0500 (EST)
Received: by jaguar.stc.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id PAA23368; Wed, 29 Nov 2000 15:04:31 -0500 (EST)
Cc: iptel@lists.bell-labs.com
Received: from lucent.com by jaguar.stc.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id PAA23359; Wed, 29 Nov 2000 15:04:30 -0500 (EST)
Message-ID: <3A256FC6.5030904@lucent.com>
From: Lakshmi Krishnamurthy <lnk2@lucent.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: hammer michael <mhammer@cisco.com>
Original-CC: iptel@lists.bell-labs.com
Subject: Re: [IPTEL] CPL Question About Priority
References: <4.3.2.7.2.20001129095126.00ba46b0@cia.cisco.com>
	 <852569A5.0073AC45.00@kanmta01.software.mitel.com>
	 <4.3.2.7.2.20001129095126.00ba46b0@cia.cisco.com> <4.3.2.7.2.20001129134633.00b8e520@cia.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 15:06:14 -0600
Content-Transfer-Encoding: 7bit

I agree with this observation. The application always knows best in 
terms of the nature & type of resources it needs accomodated by the 
network. There needs to be a way of communicating this requirement to 
the IP layer.

This need not be an explicit list of QoS params, but something that is a 
user-friendly mapping could be in order.

hammer michael wrote:

> I understand to an extent the distinction you are making, that the IP 
> layer, given the end-point address can figure out how to route the 
> packets carrying the media along with resource reservations.  However, 
> the existence of Via, Route, and Record-Route parameters and the usage 
> for routes longer than two proxies would seem to undermine the purity 
> of your position.  Ultimately the purpose of signaling is to establish 
> the media path, so they are not so totally divorced.
> 
> I thought that one of the evolutionary goals of the IP telephony was 
> to put as much control in the hands of the end-user.  If such control 
> is in the IP layer, how does the user control that?  Will that be a 
> Web-level interface or must he be an IP guru?  I was envisioning a 
> little more control in the Application layer via some more 
> user-friendly features.  In the current PSTN, there is some level of 
> stimulus signaling for customers to activate and deactivate features 
> and program-in network codes and user phone numbers for forwarding.  I 
> would expect that the level of user control would be much higher in IP 
> telephony.
> 
> Do you see the network cloud operating transparently and what service 
> you get is what you get?
> Or is there another media-specific protocol that allows the user to 
> explicitly control what network routes that his packets traverse?
> 
> Mike
> 
> 
> At 12:22 PM 11/29/2000 -0500, Jonathan Lennox wrote:
> 
>> On Wednesday, November 29 2000, "hammer michael" wrote to "Jonathan 
>> Lennox, Tom_Gray@Mitel.COM, Cliff.Harris@nokia.com, 
>> iptel@lists.bell-labs.com" saying:
>> 
>>  > You could potentially have a network selection based on dynamic 
>> network
>>  > characteristics.
>>  > Route through network A (the cheapest) unless it is congested or 
>> denies me
>>  > service,
>>  > otherwise route through network B while QoS > X, else ...
>>  >
>>  > I know that bandwidth is supposed to be free and plentiful, but 
>> could you
>>  > foresee networks of the future dynamically changing their rates 
>> based on
>>  > demand and users selecting the better alternatives for routing?
>> 
>> Yes, absolutely, but this is way out of scope for the CPL.  Remember, 
>> CPL
>> controls *signalling*, and the network selection you're talking about 
>> is for
>> *media*.
>> 
>> If I place a call to sip:foo@example.com, and the 200 response to the 
>> INVITE
>> has 128.59.19.147 in its SDP, I'm going to send my packets to 
>> 128.59.19.147,
>> regardless of what route my INVITE took.
>> 
>> If I'm using manyfolks, I'll also set up a resource reservation to 
>> that IP
>> address.  That's the point at which the service provider should 
>> intervene to
>> figure out what route they want my packets to take.
>> 
>> -- 
>> Jonathan Lennox
>> lennox@cs.columbia.edu
>> 
>> _______________________________________________
>> 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



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 29 16:49:03 2000
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 QAA20811
	for <iptel-archive@odin.ietf.org>; Wed, 29 Nov 2000 16:49:02 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7B5B8443A2; Wed, 29 Nov 2000 15:49:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by lists.bell-labs.com (Postfix) with ESMTP id DEEF444393
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 15:48:40 -0500 (EST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eATLms605711
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 15:49:04 -0600 (CST)
Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tac12f255502d825b22@davir02nok.americas.nokia.com>;
 Wed, 29 Nov 2000 15:48:21 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <XMR5P4KZ>; Wed, 29 Nov 2000 15:44:01 -0600
Message-ID: <E39024226822D311BC880008C77318A1019C59F9@oteis01nok>
From: Cliff.Harris@nokia.com
To: lennox@cs.columbia.edu
Cc: iptel@lists.bell-labs.com
Subject: RE: [IPTEL] CPL Question About Priority
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 15:40:01 -0600



> -----Original Message-----
> From: EXT Jonathan Lennox [mailto:lennox@cs.columbia.edu]
> Sent: Tuesday, November 28, 2000 4:09 PM
> To: Tom_Gray@Mitel.COM
> Cc: Cliff.Harris@nokia.com; iptel@lists.bell-labs.com
> Subject: Re: [IPTEL] CPL Question About Priority
> 
> 
. . .
> But I understood the the feature Cliff 
> was describing as
> "If I call anyone at Example Industries, first place my call 
> to the Example
> Industries switchboard, then try that specific person."  It's 
> not clear to
> me why anyone would ever want such a feature for their 
> outgoing call script.

That's a good summary (in the context of base CPL) of what I was asking
about, and I agree that there is probably no use for such a feature in base
CPL. When I asked the question, I wasn't thinking of a particular feature; I
was just thinking about the language definition. 

Suppose that some future extensions to CPL made it sensible to do what I was
asking. Then there would be difficulties because the use of priorities is
not strictly defined (so that at the very least, scripts using these
hypothetical new features would not be portable--they would behave
differently on different CPL servers).

While I don't have a good example of why I might want to try some other
address first in an outgoing call (unless there's been a successful "address
is" test), I equally don't understand why a CPL server would need to
override the priorities specified in the script. A script can always proxy
to one location at a time in whatever order it wants; why would a list of
locations with explicit priorities need to be treated differently? 

Maybe there's something about server policy with respect to priorities that
I don't understand, but it seems to me that making the language a little
more deterministic would make it more extensible (and portable) in the
future.

> -----Original Message-----
> From: EXT Jonathan Lennox [mailto:lennox@cs.columbia.edu]
> Sent: Tuesday, November 28, 2000 3:57 PM
> To: Cliff.Harris@nokia.com
> Cc: iptel@lists.bell-labs.com
> Subject: Re: [IPTEL] CPL Question About Priority
> 
>
. . . 
> It's true that there's no priority specified for the initial 
> address.  I
> suppose it should be 1.0.

Then it would be impossible to add a new address with a higher priority to
the location set. (Unless the language specified that locations of equal
priority should be processed in LIFO order.)

> -----Original Message-----
> From: EXT Jonathan Lennox [mailto:lennox@cs.columbia.edu]
> Sent: Wednesday, November 29, 2000 12:22 PM
> To: iptel@lists.bell-labs.com
> Subject: Re: [IPTEL] CPL Question About Priority
> 
> 
> On Wednesday, November 29 2000, "hammer michael" wrote to 
> "Jonathan Lennox, Tom_Gray@Mitel.COM, Cliff.Harris@nokia.com, 
> iptel@lists.bell-labs.com" saying:
> 
> > You could potentially have a network selection based on 
> dynamic network 
> > characteristics.
> > Route through network A (the cheapest) unless it is 
> congested or denies me 
> > service,
> > otherwise route through network B while QoS > X, else ...
> > 
> > I know that bandwidth is supposed to be free and plentiful, 
> but could you 
> > foresee networks of the future dynamically changing their 
> rates based on 
> > demand and users selecting the better alternatives for routing?
> 
> Yes, absolutely, but this is way out of scope for the CPL.  
> Remember, CPL
> controls *signalling*, and the network selection you're 
> talking about is for
> *media*.
> 
> If I place a call to sip:foo@example.com, and the 200 
> response to the INVITE
> has 128.59.19.147 in its SDP, I'm going to send my packets to 
> 128.59.19.147,
> regardless of what route my INVITE took.
> 
> If I'm using manyfolks, I'll also set up a resource 
> reservation to that IP
> address.  That's the point at which the service provider 
> should intervene to
> figure out what route they want my packets to take.
> 

What if the form of the address affects the type of signalling which affects
the type of media? For instance, given a telephone number that could be
routed either through the PSTN or through the IP network, would it be
unreasonable to have the script change the address from a tel URL to a sip
URL to select the type of routing?


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 29 17:07:20 2000
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 RAA29007
	for <iptel-archive@odin.ietf.org>; Wed, 29 Nov 2000 17:07:20 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D8A7D443CF; Wed, 29 Nov 2000 16:07:04 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net [208.37.18.67])
	by lists.bell-labs.com (Postfix) with ESMTP id 49BD444393
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 16:06:49 -0500 (EST)
Received: from matt.ipverse.com (ts002d13.new-la.concentric.net [206.173.73.73]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id XNX7NQ58; Wed, 29 Nov 2000 14:06:40 -0800
Message-Id: <5.0.2.1.2.20001129140515.02507080@pop3.ipverse.com>
X-Sender: matt@ipverse.com@pop3.ipverse.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
From: Matt Holdrege <matt@ipverse.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
Cc: Jiri Kuthan <kuthan@fokus.gmd.de>,
        Jonathan Lennox <lennox@orion.cs.columbia.edu>,
        iptel@lists.bell-labs.com
In-Reply-To: <3A246F3D.6CCC7168@cs.columbia.edu>
References: <B65B4F8437968F488A01A940B21982BF9AABF4@DYN-EXCH-001.dynamicsoft.com>
 <3A1AC782.3963ADFF@fokus.gmd.de>
 <14884.5798.966433.783539@conrail.cs.columbia.edu>
 <3A242555.34539EFD@fokus.gmd.de>
 <3A242BD5.38423D7C@cs.columbia.edu>
 <3A2465D8.8A2575F1@fokus.gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 14:06:27 -0800

At 09:51 PM 11/28/2000 -0500, Henning G. Schulzrinne wrote:
>Yes, but the problem is that you're now making certain characters
>special in the string. Leads to escaping, special syntax. Since CPL is
>not primarily meant to be written by hand, I'd rather let the XML parser
>do all the parsing rather than writing another expression parser.

To steer this in another direction, could XMLDSIG be successfully applied 
here to solve some of the problem?


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 29 23:25:00 2000
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 XAA04206
	for <iptel-archive@odin.ietf.org>; Wed, 29 Nov 2000 23:25:00 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2CD6444376; Wed, 29 Nov 2000 22:25:03 -0500 (EST)
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 7B3F44433A
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 22:24:20 -0500 (EST)
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 XAA00683;
	Wed, 29 Nov 2000 23:26:39 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X20752X7>; Wed, 29 Nov 2000 23:22:14 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AACFE@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Lakshmi Krishnamurthy'" <lnk2@lucent.com>,
        hammer michael <mhammer@cisco.com>
Cc: iptel@lists.bell-labs.com
Subject: RE: [IPTEL] CPL Question About Priority
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 23:22:13 -0500


Correct, the application knows best what its QoS requirements are. And thats
why IETF has developed protocols like RSVP that allow the users to ask the
network for various levels of QoS. Whether it scales or not is a separate
discussion thats out of scope here.

As per senders of IP packets getting to determine the route through the IP
network; there is the possibility of such a thing using loose source IP
routing. But, in practice, this is never done and frought with problems.
There are serious topology discovery and other issues that need to be
resolved; a minor problem is that packets marked with loose source routes
are slow-path on routers, resulting in increased delay. I don't think anyone
uses loose source routing at all.

That aside, this is all completely out of scope for CPL. As Jonathan L. has
correctly observed, SIP signaling routing is completely orthogonal to media
routing, and for really, really good reasons (i.e., not re-inventing yet
another forwarding, switching, routing layer within the network just for
RTP; the IP network already knows how to deliver the RTP packets in the most
direct path from originator to recipient).

-Jonathan R.
 

> -----Original Message-----
> From: Lakshmi Krishnamurthy [mailto:lnk2@lucent.com]
> Sent: Wednesday, November 29, 2000 4:06 PM
> To: hammer michael
> Cc: iptel@lists.bell-labs.com
> Subject: Re: [IPTEL] CPL Question About Priority
> 
> 
> I agree with this observation. The application always knows best in 
> terms of the nature & type of resources it needs accomodated by the 
> network. There needs to be a way of communicating this requirement to 
> the IP layer.
> 
> This need not be an explicit list of QoS params, but 
> something that is a 
> user-friendly mapping could be in order.
> 
> hammer michael wrote:
> 
> > I understand to an extent the distinction you are making, 
> that the IP 
> > layer, given the end-point address can figure out how to route the 
> > packets carrying the media along with resource 
> reservations.  However, 
> > the existence of Via, Route, and Record-Route parameters 
> and the usage 
> > for routes longer than two proxies would seem to undermine 
> the purity 
> > of your position.  Ultimately the purpose of signaling is 
> to establish 
> > the media path, so they are not so totally divorced.
> > 
> > I thought that one of the evolutionary goals of the IP 
> telephony was 
> > to put as much control in the hands of the end-user.  If 
> such control 
> > is in the IP layer, how does the user control that?  Will that be a 
> > Web-level interface or must he be an IP guru?  I was envisioning a 
> > little more control in the Application layer via some more 
> > user-friendly features.  In the current PSTN, there is some 
> level of 
> > stimulus signaling for customers to activate and deactivate 
> features 
> > and program-in network codes and user phone numbers for 
> forwarding.  I 
> > would expect that the level of user control would be much 
> higher in IP 
> > telephony.
> > 
> > Do you see the network cloud operating transparently and 
> what service 
> > you get is what you get?
> > Or is there another media-specific protocol that allows the user to 
> > explicitly control what network routes that his packets traverse?
> > 
> > Mike
> > 
> > 
> > At 12:22 PM 11/29/2000 -0500, Jonathan Lennox wrote:
> > 
> >> On Wednesday, November 29 2000, "hammer michael" wrote to 
> "Jonathan 
> >> Lennox, Tom_Gray@Mitel.COM, Cliff.Harris@nokia.com, 
> >> iptel@lists.bell-labs.com" saying:
> >> 
> >>  > You could potentially have a network selection based on dynamic 
> >> network
> >>  > characteristics.
> >>  > Route through network A (the cheapest) unless it is 
> congested or 
> >> denies me
> >>  > service,
> >>  > otherwise route through network B while QoS > X, else ...
> >>  >
> >>  > I know that bandwidth is supposed to be free and plentiful, but 
> >> could you
> >>  > foresee networks of the future dynamically changing their rates 
> >> based on
> >>  > demand and users selecting the better alternatives for routing?
> >> 
> >> Yes, absolutely, but this is way out of scope for the CPL. 
>  Remember, 
> >> CPL
> >> controls *signalling*, and the network selection you're 
> talking about 
> >> is for
> >> *media*.
> >> 
> >> If I place a call to sip:foo@example.com, and the 200 
> response to the 
> >> INVITE
> >> has 128.59.19.147 in its SDP, I'm going to send my packets to 
> >> 128.59.19.147,
> >> regardless of what route my INVITE took.
> >> 
> >> If I'm using manyfolks, I'll also set up a resource reservation to 
> >> that IP
> >> address.  That's the point at which the service provider should 
> >> intervene to
> >> figure out what route they want my packets to take.
> >> 
> >> -- 
> >> Jonathan Lennox
> >> lennox@cs.columbia.edu
> >> 
> >> _______________________________________________
> >> 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
> 
> 
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 
---
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 Nov 29 23:27:51 2000
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 XAA05117
	for <iptel-archive@odin.ietf.org>; Wed, 29 Nov 2000 23:27:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A2197443C3; Wed, 29 Nov 2000 22:26:03 -0500 (EST)
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 DC847443BB
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 22:25:58 -0500 (EST)
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 XAA00691;
	Wed, 29 Nov 2000 23:28:16 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X20752X9>; Wed, 29 Nov 2000 23:23:51 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AACFF@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Cliff.Harris@nokia.com'" <Cliff.Harris@nokia.com>,
        lennox@cs.columbia.edu
Cc: iptel@lists.bell-labs.com
Subject: RE: [IPTEL] CPL Question About Priority
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 23:23:51 -0500

I agree that priority values should be deterministic.

Lets specify that the default q value for the initial location set (relevant
only for outgoing requests) is 1.0, and that if the lookup tag results in
URLs with no q values, the value is assigned as 1.0 as well.

-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
 

> -----Original Message-----
> From: Cliff.Harris@nokia.com [mailto:Cliff.Harris@nokia.com]
> Sent: Wednesday, November 29, 2000 4:40 PM
> To: lennox@cs.columbia.edu
> Cc: iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] CPL Question About Priority
> 
> 
> 
> 
> > -----Original Message-----
> > From: EXT Jonathan Lennox [mailto:lennox@cs.columbia.edu]
> > Sent: Tuesday, November 28, 2000 4:09 PM
> > To: Tom_Gray@Mitel.COM
> > Cc: Cliff.Harris@nokia.com; iptel@lists.bell-labs.com
> > Subject: Re: [IPTEL] CPL Question About Priority
> > 
> > 
> . . .
> > But I understood the the feature Cliff 
> > was describing as
> > "If I call anyone at Example Industries, first place my call 
> > to the Example
> > Industries switchboard, then try that specific person."  It's 
> > not clear to
> > me why anyone would ever want such a feature for their 
> > outgoing call script.
> 
> That's a good summary (in the context of base CPL) of what I 
> was asking
> about, and I agree that there is probably no use for such a 
> feature in base
> CPL. When I asked the question, I wasn't thinking of a 
> particular feature; I
> was just thinking about the language definition. 
> 
> Suppose that some future extensions to CPL made it sensible 
> to do what I was
> asking. Then there would be difficulties because the use of 
> priorities is
> not strictly defined (so that at the very least, scripts using these
> hypothetical new features would not be portable--they would behave
> differently on different CPL servers).
> 
> While I don't have a good example of why I might want to try 
> some other
> address first in an outgoing call (unless there's been a 
> successful "address
> is" test), I equally don't understand why a CPL server would need to
> override the priorities specified in the script. A script can 
> always proxy
> to one location at a time in whatever order it wants; why 
> would a list of
> locations with explicit priorities need to be treated differently? 
> 
> Maybe there's something about server policy with respect to 
> priorities that
> I don't understand, but it seems to me that making the 
> language a little
> more deterministic would make it more extensible (and portable) in the
> future.
> 
> > -----Original Message-----
> > From: EXT Jonathan Lennox [mailto:lennox@cs.columbia.edu]
> > Sent: Tuesday, November 28, 2000 3:57 PM
> > To: Cliff.Harris@nokia.com
> > Cc: iptel@lists.bell-labs.com
> > Subject: Re: [IPTEL] CPL Question About Priority
> > 
> >
> . . . 
> > It's true that there's no priority specified for the initial 
> > address.  I
> > suppose it should be 1.0.
> 
> Then it would be impossible to add a new address with a 
> higher priority to
> the location set. (Unless the language specified that 
> locations of equal
> priority should be processed in LIFO order.)
> 
> > -----Original Message-----
> > From: EXT Jonathan Lennox [mailto:lennox@cs.columbia.edu]
> > Sent: Wednesday, November 29, 2000 12:22 PM
> > To: iptel@lists.bell-labs.com
> > Subject: Re: [IPTEL] CPL Question About Priority
> > 
> > 
> > On Wednesday, November 29 2000, "hammer michael" wrote to 
> > "Jonathan Lennox, Tom_Gray@Mitel.COM, Cliff.Harris@nokia.com, 
> > iptel@lists.bell-labs.com" saying:
> > 
> > > You could potentially have a network selection based on 
> > dynamic network 
> > > characteristics.
> > > Route through network A (the cheapest) unless it is 
> > congested or denies me 
> > > service,
> > > otherwise route through network B while QoS > X, else ...
> > > 
> > > I know that bandwidth is supposed to be free and plentiful, 
> > but could you 
> > > foresee networks of the future dynamically changing their 
> > rates based on 
> > > demand and users selecting the better alternatives for routing?
> > 
> > Yes, absolutely, but this is way out of scope for the CPL.  
> > Remember, CPL
> > controls *signalling*, and the network selection you're 
> > talking about is for
> > *media*.
> > 
> > If I place a call to sip:foo@example.com, and the 200 
> > response to the INVITE
> > has 128.59.19.147 in its SDP, I'm going to send my packets to 
> > 128.59.19.147,
> > regardless of what route my INVITE took.
> > 
> > If I'm using manyfolks, I'll also set up a resource 
> > reservation to that IP
> > address.  That's the point at which the service provider 
> > should intervene to
> > figure out what route they want my packets to take.
> > 
> 
> What if the form of the address affects the type of 
> signalling which affects
> the type of media? For instance, given a telephone number 
> that could be
> routed either through the PSTN or through the IP network, would it be
> unreasonable to have the script change the address from a tel 
> URL to a sip
> URL to select the type of routing?
> 
> 
> _______________________________________________
> 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  Wed Nov 29 23:37:03 2000
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 XAA08535
	for <iptel-archive@odin.ietf.org>; Wed, 29 Nov 2000 23:37:02 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9EBEA443C9; Wed, 29 Nov 2000 22:37:02 -0500 (EST)
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 59C49443C1
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 22:36:38 -0500 (EST)
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 XAA00725;
	Wed, 29 Nov 2000 23:38:55 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X20752YG>; Wed, 29 Nov 2000 23:34:30 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAD00@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Jiri Kuthan'" <kuthan@fokus.gmd.de>,
        "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: Jonathan Lennox <lennox@orion.cs.columbia.edu>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: RE: CPLng (was [IPTEL] agenda items)
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 23:34:30 -0500

Lets slow down here.

We have wandered into "syntax no-mans land", a bad place where many working
groups spend way too much time.

I'm not yet sure what problem is being solved. Lets get agreement on what we
need this for, what fields we want to run checks against, whether the checks
are against lists inside the script or externally referenced, the general
model for how this works (i.e., can we use the lookup/location model of
modification of an implicit global variable) and so on. Once we know WHAT we
want to do, and agree to define a CPL extension to do it, we can sketch out
syntax.

So, the next person that posts a note on syntax for this thing is going to
get a really big flame from me.

-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
 

> -----Original Message-----
> From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de]
> Sent: Wednesday, November 29, 2000 12:24 PM
> To: Henning G. Schulzrinne
> Cc: Jonathan Lennox; Jonathan Rosenberg; 'iptel@lists.bell-labs.com'
> Subject: Re: CPLng (was [IPTEL] agenda items)
> 
> 
> So this is the escape-free alternative:
> 
>   Adding new parameters to address and string switches. The parameters
>   indicate that a value is a URL pointing to a list of values 
> separated
>   by a well-known delimiter. The condition matches if any of 
> list items
>   matches.
> 
> Examples:
>   <address is_anyof="http://www.nospam.org/badguys.txt">
>   <subject contains_anyof="ftp://www.nospam.org/dirtywords.txt">
> 
> Can we agree on this?
> 
> If so, how do will we deal with error handling? Does 
> indication of timeout
> and subaction for processing of failed list access sound reasonable?
> I.e., something like 
>   <address is_anyof="http://www.nospam.org/badguys.txt" 
> 	   timeout="10" error_handler="drop_call_and_log">
> 
> Jiri
> 
> "Henning G. Schulzrinne" wrote:
> > 
> > I made my point a few times that I find syntax within "" arguments
> > dangerous and a recipe for escaping and parsing nightmares. 
> I'm not sure
> > what else to say. No, I still don't find the syntax 
> acceptable. CPL can
> > be written by vi, but that is, in the long run, not 
> necessarily going to
> > be the most common means, so I see no need to optimize for that.
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Nov 29 23:45:02 2000
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 XAA11029
	for <iptel-archive@odin.ietf.org>; Wed, 29 Nov 2000 23:45:01 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6CD1B443BF; Wed, 29 Nov 2000 22:45:02 -0500 (EST)
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 240C74433A
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 22:44:17 -0500 (EST)
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 XAA00753;
	Wed, 29 Nov 2000 23:46:20 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X20752YN>; Wed, 29 Nov 2000 23:41:55 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAD01@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'hammer michael'" <mhammer@cisco.com>, Jiri Kuthan <kuthan@fokus.gmd.de>
Cc: James Undery <jundery@ubiquity.net>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: RE: CPLng (was [IPTEL] agenda items)
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 23:41:54 -0500

Michael,

This is a good point. What you are asking for is non-repudiation of script
uploads. Unfortunately, I think its harder to do than you imply. Even if I
have a signed script from you, you could argue that you did indeed sign the
script, but never uploaded it. To prove that you uploaded it, I would have
to remember the message exchanges for the transport itself. I don't think
there is a way around that.

Like many other groups that work on security, we have begun discussing
technology solutions without identifying the requirements. Mike has proposed
one requirement, which is non-repudiation of script uploads. What other
security requirements do we have? Once we know those, we can identify
whether the existing security mechanisms are sufficient.

-Jonathan R.

 

> -----Original Message-----
> From: hammer michael [mailto:mhammer@cisco.com]
> Sent: Monday, November 27, 2000 1:02 PM
> To: Jiri Kuthan
> Cc: James Undery; Jonathan Rosenberg; 'iptel@lists.bell-labs.com'
> Subject: Re: CPLng (was [IPTEL] agenda items)
> 
> 
> Suppose, I establish a secure session and securely transmit a 
> script which 
> then gets loaded.  Later, it turns out the script is 
> destructive.  You 
> accuse me of doing some damage.  I deny that the rogue script you are 
> complaining about is mine.  The session is long gone.  You 
> have no proof 
> that the script is mine and any legal claims would be rather tenuous, 
> unless you saved a recording of the session, which would 
> waste memory.  If 
> the script had been signed, then you would have a case against me.
> 
> Transport level assurance is only good if you can absolutely 
> trust the 
> sender.  I am not suggesting that you not use transport layer 
> security, 
> only that some additional level of security might be called for.
> 
> Mike Hammer
> 
> At 03:00 AM 11/23/2000 +0100, Jiri Kuthan wrote:
> >hammer michael wrote:
> > >
> > > Keep in mind that encryption is a technology, not a service.
> > > To be clearer, decide whether you are talking about 
> confidentiality,
> > > authentication, non-repudiation, or whatever.
> >
> >Problem: It is dangerous to transport CPL security credentials (SC)
> >          or even some CPL scripts (like those that include lists of
> >          enemies) in clear-textover a network.
> >Needed service: privacy of transported CPL SCs/scripts
> >Recommended technology: encryption
> >
> > > To say that encryption
> > > belongs only in the transport realm, it taking a very 
> narrow view of its
> > > possibilities.
> >
> >I do not see any advantage of inventing a mechanism for
> >encryption of CPL scripts or SCs if I can take a generic one
> >available in a transport protocol.
> >
> >Jiri
> >
> > > > > Sending authentication in a
> > > > > script like this would require the script be encrypted for
> > > > transmission, clearly stepping
> > > > > outside of CPL's domain.
> > > >
> > > >Encryption is a transport rather than CPL issue. It is 
> useful anyway --
> > > >maybe you are not eager to transport a plain-text CPL 
> script that includes
> > > >a list of inconvenient caller whose calls you drop.
> 
> 

---
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 Nov 29 23:52:04 2000
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 XAA13727
	for <iptel-archive@odin.ietf.org>; Wed, 29 Nov 2000 23:52:03 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DF1F1443D3; Wed, 29 Nov 2000 22:52:02 -0500 (EST)
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 32E1F4433A
	for <iptel@lists.bell-labs.com>; Wed, 29 Nov 2000 22:51:50 -0500 (EST)
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 XAA00775;
	Wed, 29 Nov 2000 23:54:08 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X20752YR>; Wed, 29 Nov 2000 23:49:43 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAD02@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        Jiri Kuthan <kuthan@fokus.gmd.de>
Cc: Jonathan Lennox <lennox@orion.cs.columbia.edu>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: RE: CPLng (was [IPTEL] agenda items)
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 29 Nov 2000 23:49:42 -0500

I agree that there is a use for authentication-switch. In fact, when I first
implemented CPL back at Bell Labs, I added some stuff that I needed to make
it a more administrator-centric language. One of them was, in fact,
authentication switch as Jiri has described.

I believe the authentication-switch can be independent of the mechanism. I
do not like the model of using CPL to convey shared secrets and the like, as
Jiri has done. THese things need to be configured separately on the server,
as they are orthogonal to CPL.

What makes sense to me is something like:

<authentication-switch realm="myfriends">
   <failure>
      do something
   </failure>
   <no-credentials>
      do something
   </no-credentials>
   <cleartext-password>
      go here if the authentication was with cleartext pass
   </cleartext-password>
   <digest-password>
      go here if the authentication was with digest password
   </digest-password>
   <public>
      go here if this was a public key verification
   </public>
</authentication-switch>

The tokens "cleartext-password", "digest-password", and "public" could refer
to classes of algorithms; we would map actual algorithsm to one of these
(PGP and S/MIME to "public", for example).

-Jonathan R.
    

 

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Tuesday, November 28, 2000 5:04 PM
> To: Jiri Kuthan
> Cc: Jonathan Lennox; Jonathan Rosenberg; 'iptel@lists.bell-labs.com'
> Subject: Re: CPLng (was [IPTEL] agenda items)
> 
> 
> Jiri Kuthan wrote:
> > 
> > Jonathan Lennox wrote:
> > > Unfortunately, this is a bigger problem than just for 
> CPL.  While I would
> > > love to have some way of switching on authenticated 
> addresses in CPL, it
> > > first needs to be figured out how to do this in IP 
> telephony in gneeral, or
> > > at least in specific protocals such as SIP.  Once a 
> framework for this is
> > > worked out, we can figure out how best to map these 
> things into CPL.
> > >
> > > I don't think IPTel is the right forum for doing this 
> sort of thing, though
> > > certainly the needs of a CPL authentication switch would 
> be a major
> > > requirement sent as input to that process. [...]
> > 
> > Actually, I'd like to have authentication switching dependent on
> > authentication id and independent on authentication mechanism. The
> > place where mechanism-dependencies is unavoidable is the credential
> > database.
> > 
> > The authentication switch can be specified at iptel because it is
> > independent on the mechanism. Authentication protocols come and go
> > and should not affect authentication switching. I'm not sure what
> > the most appropriate place for working on a specification of the
> > credential database format is.
> 
> In practice, this is not likely to be as big a deal. Authentication at
> CPL level is primarily useful for rejecting spammers, as 
> mentioned, and
> possibly to give access to otherwise restricted destinations to
> 'special' people. For that, we have three levels of 
> 
> - make sure the caller can be reached - to prevent the SIP version of
> kids ringing doorbells and running away
> 
> - make sure that the caller's SIP or H.323 address is legitimate. One
> could, for example, build a UA that doesn't accept calls, but rather
> returns the INVITE with the same Call-ID or other token to the caller.
> Assuming intercept is not likely, this is reasonably secure 
> and requires
> no PKI.
> 
> - set up secrets ahead of time, by (e.g.,) emailing them to 
> the caller,
> similar to how most level-1 certificates work
> 
> - full-fledged PKI. Not likely except in closed communities, i.e., at
> best useful for the second application of authentication.
> 
> CPL doesn't have to know anything about the details, just needs to
> convey the level of authentication used to verify the 
> identity, allowing
> the script to make appropriate choices.
> 
> > 
> > The idea behind that particular proposal is to enable 
> accessing the lists
> > from any place (address switches, string switches, 
> whatever) without changing
> > CPL's syntax. The hack is to indicate with an escape 
> sequence that a value
> > should be interpreted as a reference to a list. E.g.,
> >   <address is="@@http://www.nospam.org/badguys.txt">
> >         <reject/>
> > 
> > I do not insist on this particular syntax, other ideas are 
> appreciated.
> 
> I have to admit that I find this type of URL special-casing less than
> savory. If you want to check for a list, create a new qualifier other
> than 'is'.
> 
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
---
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  Thu Nov 30 02:17:57 2000
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 CAA06088
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 02:17:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1CDD244392; Thu, 30 Nov 2000 01:18:02 -0500 (EST)
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 D7E894433A
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 01:17:44 -0500 (EST)
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 CAA01384;
	Thu, 30 Nov 2000 02:20:04 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X207527X>; Thu, 30 Nov 2000 02:15:39 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAD0D@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'hsalama@cisco.com'" <hsalama@cisco.com>
Cc: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] TRIP for gateways
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 02:15:38 -0500



 

> -----Original Message-----
> From: Hussein F. Salama [mailto:hsalama@cisco.com]
> Sent: Monday, November 27, 2000 6:46 PM
> To: Jonathan Rosenberg
> Cc: 'iptel@lists.bell-labs.com'
> Subject: Re: [IPTEL] TRIP for gateways
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > Folks,
> > 
> > At the last two meetings, Hussein and I have presented a 
> draft on the usage
> > of TRIP for gateways. The problem that the draft is trying 
> to address comes
> > up more and more, and it is becoming urgent that the group 
> come to some kind
> > of decision regarding this work. We can discuss this at the 
> meeting, of
> > course, but I'd much prefer to start a list discussion 
> first so we can
> > identify what the problems are.
> 
> Before going into the details of SLP and TRIP, we need to agree on the
> requirements. Here are a few questions to get started:
> - Is multi-hop call routing a requirement for intra-domain 
> calls? Or is
> a single-hop sufficient?

I think you clearly need multihop. I know of numerous ITSP networks that are
built with many levels of proxies doing a variety of different things.



> - Is aggregation within a domain required?

Again, I would say yes. I could imagine an ITSP that has POPs around the
country, and they have LSs in each POP that propagate reachability from that
POP up to a central ITSP access point. That access point would aggregate all
these routes, and advertise them out to their customers.


> - Is it required to advertise the services (e.g. voice or fax) and
> capabilities (e.g. which codecs) a specific route supports?

Yes, but I think information like this should not be propagated beyond a
single hop from the gateways. It simply doesn't scale since it can't be
aggregated.

> - Dynamic attributes, e.g. residual capacity of GW?

Yes. Using a proxy/LS to front a gateway farm, load balancing across it, is
an absolutely critical function. To do this right, it needs to know these
residual capacities.

> - What's the required convergence time when a route changes?

Very fast. On the order of seconds. We don't want to drop calls when a box
fails.

> - Gateway registration vs. intra-domain call routing, are 
> they different
> problems?

Well, thats not a requirements question. A better question is: what are the
requirements for gateway registration, what are the requirements for
intra-domain routing, and then you can decide if they are the same.

-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  Thu Nov 30 02:22:58 2000
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 CAA08799
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 02:22:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 29C07443E6; Thu, 30 Nov 2000 01:23:03 -0500 (EST)
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 74DFE4433A
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 01:22:22 -0500 (EST)
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 CAA01400;
	Thu, 30 Nov 2000 02:24:41 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <X2075276>; Thu, 30 Nov 2000 02:20:16 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAD0E@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'James Kempf'" <James.Kempf@eng.sun.com>
Cc: iptel@lists.bell-labs.com, erik.guttman@germany.sun.com
Subject: RE: [IPTEL] TRIP for gateways
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 02:20:15 -0500



 

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@eng.sun.com]
> Sent: Wednesday, November 22, 2000 1:57 PM
> To: James.Kempf@eng.sun.com; jdrosen@dynamicsoft.com
> Cc: iptel@lists.bell-labs.com; erik.guttman@germany.sun.com
> Subject: RE: [IPTEL] TRIP for gateways
> 
> 
> I'm curious why you need to have the gateway push the 
> reachability info
> to the location server. Why can't the location server pull it from the
> gateway?
> 
> In this scenario, the location server acts as a user agent and the
> gateway acts as the service agent. The service advertisement consists
> of the PSTN gateway's attributes and reachability info (as I 
> understand
> it from below, telephone prefixes). The location server periodically
> performs an SLP SrvRqst for gateway service URLs, then performs an
> SLP AttrRqst for the attributes. Alternatively, the location server
> can include the SLP attribute list extension (see 
> draft-guttman-svrloc-attrlist-ext-04.txt) to have the attributes
> delivered along with the service URL.

Indeed, the fundamental question is push vs. pull.

I think gateway routing needs to be push primarily for performance reasons.
Calls arrive at a proxy server at potentially very high rates; if each call
needs to generate an independent query for service, you end up (1) adding
latency to each call setup for the query/response, (2) introducing a serious
processing burden for all devices, (3) add a lot of network traffic for the
queries and responses. By pushing the information as it changes, we
eliminate the additional call setup latency, reduce the processing load, and
reduce the messaging load. 

-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  Thu Nov 30 08:19:08 2000
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 IAA28673
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 08:19:07 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0BA0D44399; Thu, 30 Nov 2000 07:19:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19])
	by lists.bell-labs.com (Postfix) with ESMTP id B4BFC44357
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 07:18:42 -0500 (EST)
Received: from zhard00e.europe.nortel.com by qhars002.nortel.com;
          Thu, 30 Nov 2000 13:18:07 +0000
Received: by zhard00e.europe.nortel.com 
          with Internet Mail Service (5.5.2652.35) id <XXRHAHVZ>;
          Thu, 30 Nov 2000 13:18:06 -0000
Message-ID: <B9159C1D923DD4119EF8002048400C2D02D46592@zhard00d.europe.nortel.com>
From: "Mark Gibson" <mrg@nortelnetworks.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Lakshmi Krishnamurthy'" <lnk2@lucent.com>,
        hammer michael <mhammer@cisco.com>
Cc: iptel@lists.bell-labs.com
Subject: RE: [IPTEL] CPL Question About Priority
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C05ACF.F9BBF9F0"
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 13:18:06 -0000

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_001_01C05ACF.F9BBF9F0
Content-Type: text/plain;
	charset="iso-8859-1"

I think that there's another angle on this debate that's being ignored. I
might be willing to buy the fact that RSVP is OK to get me a QoS pipe
providing my network policy layer is working efficiently and I can provision
my core. However I think this problem also encompasses resilience to mass
calling events and alternative operator selection.

In the former case, assuming the manyfolks operation (which I'm not
massively familiar so do forgive inaccuracy), there are still some 3-4
rounds trips of SIP signalling before the RSVP layer comes back and says
"sorry, not enough bits" and the session clears down. Under mass calling
event conditions this is a lot of signalling, probably enough to bring
servers down - lets face it, the current PSTN creaks when Ticketmaster has
hot tickets for sale. Especially when you consider that this signalling is
likely to be concentrated at border Proxies. Surely its better for that
Proxy to be pre-warned that it just can't accept new sessions and reject the
call there & then.

In the latter case, I might have a preferential billing arrangement with one
core provider but will accept a provider that will route my call according
to certain service level conditions. As things like price are likely to be
cumulative and depend on trading agreements between operators, its unlikely
that we can source define a single best route so I'd like to try a number to
find the optimal one. And I will want to choose before RSVP establishes a
connection that I don't want to pay for. So I either, 

a) sort this out using the SIP signalling round trips - perhaps define an
sdp equivalence that does costing of routes and availability discovery and
extend SIP to permit forking and recombining INVITE without generating a
loop-detect error to nip call attempts that can't be handled in the bud

b) develop extensions to RSVP for its POLICY_ELEMENT to allow source routing
to be indicated (loosely) and perhaps cumulative cost and use COPS to tell
the management layer and have it signal the billing layer as to the final
route.

Note that b) runs the risk of the call blocking when its requirements cannot
be met at a point after resource has been committed by the Resv but before
the end-to-end connection is established, causing possible future call
blocking.

I appreciate that this is reasonably off topic for most of this list but its
clearly important. If anyone wants to take this offline and explore this
signalling and reservation issue in more detail perhaps we could get
together with Mike and Lakshmi.

Cheers

Mark Gibson


 -----Original Message-----
From: 	Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] 
Sent:	Thursday, November 30, 2000 4:22 AM
To:	'Lakshmi Krishnamurthy'; hammer michael
Cc:	iptel@lists.bell-labs.com
Subject:	RE: [IPTEL] CPL Question About Priority


Correct, the application knows best what its QoS requirements are. And thats
why IETF has developed protocols like RSVP that allow the users to ask the
network for various levels of QoS. Whether it scales or not is a separate
discussion thats out of scope here.

As per senders of IP packets getting to determine the route through the IP
network; there is the possibility of such a thing using loose source IP
routing. But, in practice, this is never done and frought with problems.
There are serious topology discovery and other issues that need to be
resolved; a minor problem is that packets marked with loose source routes
are slow-path on routers, resulting in increased delay. I don't think anyone
uses loose source routing at all.

That aside, this is all completely out of scope for CPL. As Jonathan L. has
correctly observed, SIP signaling routing is completely orthogonal to media
routing, and for really, really good reasons (i.e., not re-inventing yet
another forwarding, switching, routing layer within the network just for
RTP; the IP network already knows how to deliver the RTP packets in the most
direct path from originator to recipient).

-Jonathan R.
 

> -----Original Message-----
> From: Lakshmi Krishnamurthy [mailto:lnk2@lucent.com]
> Sent: Wednesday, November 29, 2000 4:06 PM
> To: hammer michael
> Cc: iptel@lists.bell-labs.com
> Subject: Re: [IPTEL] CPL Question About Priority
> 
> 
> I agree with this observation. The application always knows best in 
> terms of the nature & type of resources it needs accomodated by the 
> network. There needs to be a way of communicating this requirement to 
> the IP layer.
> 
> This need not be an explicit list of QoS params, but 
> something that is a 
> user-friendly mapping could be in order.
> 
> hammer michael wrote:
> 
> > I understand to an extent the distinction you are making, 
> that the IP 
> > layer, given the end-point address can figure out how to route the 
> > packets carrying the media along with resource 
> reservations.  However, 
> > the existence of Via, Route, and Record-Route parameters 
> and the usage 
> > for routes longer than two proxies would seem to undermine 
> the purity 
> > of your position.  Ultimately the purpose of signaling is 
> to establish 
> > the media path, so they are not so totally divorced.
> > 
> > I thought that one of the evolutionary goals of the IP 
> telephony was 
> > to put as much control in the hands of the end-user.  If 
> such control 
> > is in the IP layer, how does the user control that?  Will that be a 
> > Web-level interface or must he be an IP guru?  I was envisioning a 
> > little more control in the Application layer via some more 
> > user-friendly features.  In the current PSTN, there is some 
> level of 
> > stimulus signaling for customers to activate and deactivate 
> features 
> > and program-in network codes and user phone numbers for 
> forwarding.  I 
> > would expect that the level of user control would be much 
> higher in IP 
> > telephony.
> > 
> > Do you see the network cloud operating transparently and 
> what service 
> > you get is what you get?
> > Or is there another media-specific protocol that allows the user to 
> > explicitly control what network routes that his packets traverse?
> > 
> > Mike
> > 
> > 
> > At 12:22 PM 11/29/2000 -0500, Jonathan Lennox wrote:
> > 
> >> On Wednesday, November 29 2000, "hammer michael" wrote to 
> "Jonathan 
> >> Lennox, Tom_Gray@Mitel.COM, Cliff.Harris@nokia.com, 
> >> iptel@lists.bell-labs.com" saying:
> >> 
> >>  > You could potentially have a network selection based on dynamic 
> >> network
> >>  > characteristics.
> >>  > Route through network A (the cheapest) unless it is 
> congested or 
> >> denies me
> >>  > service,
> >>  > otherwise route through network B while QoS > X, else ...
> >>  >
> >>  > I know that bandwidth is supposed to be free and plentiful, but 
> >> could you
> >>  > foresee networks of the future dynamically changing their rates 
> >> based on
> >>  > demand and users selecting the better alternatives for routing?
> >> 
> >> Yes, absolutely, but this is way out of scope for the CPL. 
>  Remember, 
> >> CPL
> >> controls *signalling*, and the network selection you're 
> talking about 
> >> is for
> >> *media*.
> >> 
> >> If I place a call to sip:foo@example.com, and the 200 
> response to the 
> >> INVITE
> >> has 128.59.19.147 in its SDP, I'm going to send my packets to 
> >> 128.59.19.147,
> >> regardless of what route my INVITE took.
> >> 
> >> If I'm using manyfolks, I'll also set up a resource reservation to 
> >> that IP
> >> address.  That's the point at which the service provider should 
> >> intervene to
> >> figure out what route they want my packets to take.
> >> 
> >> -- 
> >> Jonathan Lennox
> >> lennox@cs.columbia.edu
> >> 
> >> _______________________________________________
> >> 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
> 
> 
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 
---
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

------_=_NextPart_001_01C05ACF.F9BBF9F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [IPTEL] CPL Question About Priority</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I think that there's another angle on this debate =
that's being ignored. I might be willing to buy the fact that RSVP is =
OK to get me a QoS pipe providing my network policy layer is working =
efficiently and I can provision my core. However I think this problem =
also encompasses resilience to mass calling events and alternative =
operator selection.</FONT></P>

<P><FONT SIZE=3D2>In the former case, assuming the manyfolks operation =
(which I'm not massively familiar so do forgive inaccuracy), there are =
still some 3-4 rounds trips of SIP signalling before the RSVP layer =
comes back and says &quot;sorry, not enough bits&quot; and the session =
clears down. Under mass calling event conditions this is a lot of =
signalling, probably enough to bring servers down - lets face it, the =
current PSTN creaks when Ticketmaster has hot tickets for sale. =
Especially when you consider that this signalling is likely to be =
concentrated at border Proxies. Surely its better for that Proxy to be =
pre-warned that it just can't accept new sessions and reject the call =
there &amp; then.</FONT></P>

<P><FONT SIZE=3D2>In the latter case, I might have a preferential =
billing arrangement with one core provider but will accept a provider =
that will route my call according to certain service level conditions. =
As things like price are likely to be cumulative and depend on trading =
agreements between operators, its unlikely that we can source define a =
single best route so I'd like to try a number to find the optimal one. =
And I will want to choose before RSVP establishes a connection that I =
don't want to pay for. So I either, </FONT></P>

<P><FONT SIZE=3D2>a) sort this out using the SIP signalling round trips =
- perhaps define an sdp equivalence that does costing of routes and =
availability discovery and extend SIP to permit forking and recombining =
INVITE without generating a loop-detect error to nip call attempts that =
can't be handled in the bud</FONT></P>

<P><FONT SIZE=3D2>b) develop extensions to RSVP for its POLICY_ELEMENT =
to allow source routing to be indicated (loosely) and perhaps =
cumulative cost and use COPS to tell the management layer and have it =
signal the billing layer as to the final route.</FONT></P>

<P><FONT SIZE=3D2>Note that b) runs the risk of the call blocking when =
its requirements cannot be met at a point after resource has been =
committed by the Resv but before the end-to-end connection is =
established, causing possible future call blocking.</FONT></P>

<P><FONT SIZE=3D2>I appreciate that this is reasonably off topic for =
most of this list but its clearly important. If anyone wants to take =
this offline and explore this signalling and reservation issue in more =
detail perhaps we could get together with Mike and Lakshmi.</FONT></P>

<P><FONT SIZE=3D2>Cheers</FONT>
</P>

<P><FONT SIZE=3D2>Mark Gibson</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&nbsp;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: &nbsp; Jonathan Rosenberg [<A =
HREF=3D"mailto:jdrosen@dynamicsoft.com">mailto:jdrosen@dynamicsoft.com</=
A>] </FONT>
<BR><FONT SIZE=3D2>Sent:&nbsp;&nbsp; Thursday, November 30, 2000 4:22 =
AM</FONT>
<BR><FONT SIZE=3D2>To:&nbsp;&nbsp;&nbsp;&nbsp; 'Lakshmi Krishnamurthy'; =
hammer michael</FONT>
<BR><FONT SIZE=3D2>Cc:&nbsp;&nbsp;&nbsp;&nbsp; =
iptel@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
RE: [IPTEL] CPL Question About Priority</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Correct, the application knows best what its QoS =
requirements are. And thats</FONT>
<BR><FONT SIZE=3D2>why IETF has developed protocols like RSVP that =
allow the users to ask the</FONT>
<BR><FONT SIZE=3D2>network for various levels of QoS. Whether it scales =
or not is a separate</FONT>
<BR><FONT SIZE=3D2>discussion thats out of scope here.</FONT>
</P>

<P><FONT SIZE=3D2>As per senders of IP packets getting to determine the =
route through the IP</FONT>
<BR><FONT SIZE=3D2>network; there is the possibility of such a thing =
using loose source IP</FONT>
<BR><FONT SIZE=3D2>routing. But, in practice, this is never done and =
frought with problems.</FONT>
<BR><FONT SIZE=3D2>There are serious topology discovery and other =
issues that need to be</FONT>
<BR><FONT SIZE=3D2>resolved; a minor problem is that packets marked =
with loose source routes</FONT>
<BR><FONT SIZE=3D2>are slow-path on routers, resulting in increased =
delay. I don't think anyone</FONT>
<BR><FONT SIZE=3D2>uses loose source routing at all.</FONT>
</P>

<P><FONT SIZE=3D2>That aside, this is all completely out of scope for =
CPL. As Jonathan L. has</FONT>
<BR><FONT SIZE=3D2>correctly observed, SIP signaling routing is =
completely orthogonal to media</FONT>
<BR><FONT SIZE=3D2>routing, and for really, really good reasons (i.e., =
not re-inventing yet</FONT>
<BR><FONT SIZE=3D2>another forwarding, switching, routing layer within =
the network just for</FONT>
<BR><FONT SIZE=3D2>RTP; the IP network already knows how to deliver the =
RTP packets in the most</FONT>
<BR><FONT SIZE=3D2>direct path from originator to recipient).</FONT>
</P>

<P><FONT SIZE=3D2>-Jonathan R.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Lakshmi Krishnamurthy [<A =
HREF=3D"mailto:lnk2@lucent.com">mailto:lnk2@lucent.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, November 29, 2000 4:06 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: hammer michael</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: iptel@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [IPTEL] CPL Question About =
Priority</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I agree with this observation. The application =
always knows best in </FONT>
<BR><FONT SIZE=3D2>&gt; terms of the nature &amp; type of resources it =
needs accomodated by the </FONT>
<BR><FONT SIZE=3D2>&gt; network. There needs to be a way of =
communicating this requirement to </FONT>
<BR><FONT SIZE=3D2>&gt; the IP layer.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This need not be an explicit list of QoS =
params, but </FONT>
<BR><FONT SIZE=3D2>&gt; something that is a </FONT>
<BR><FONT SIZE=3D2>&gt; user-friendly mapping could be in order.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; hammer michael wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I understand to an extent the distinction =
you are making, </FONT>
<BR><FONT SIZE=3D2>&gt; that the IP </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; layer, given the end-point address can =
figure out how to route the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; packets carrying the media along with =
resource </FONT>
<BR><FONT SIZE=3D2>&gt; reservations.&nbsp; However, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the existence of Via, Route, and =
Record-Route parameters </FONT>
<BR><FONT SIZE=3D2>&gt; and the usage </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; for routes longer than two proxies would =
seem to undermine </FONT>
<BR><FONT SIZE=3D2>&gt; the purity </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of your position.&nbsp; Ultimately the =
purpose of signaling is </FONT>
<BR><FONT SIZE=3D2>&gt; to establish </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the media path, so they are not so totally =
divorced.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I thought that one of the evolutionary =
goals of the IP </FONT>
<BR><FONT SIZE=3D2>&gt; telephony was </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to put as much control in the hands of the =
end-user.&nbsp; If </FONT>
<BR><FONT SIZE=3D2>&gt; such control </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; is in the IP layer, how does the user =
control that?&nbsp; Will that be a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Web-level interface or must he be an IP =
guru?&nbsp; I was envisioning a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; little more control in the Application =
layer via some more </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; user-friendly features.&nbsp; In the =
current PSTN, there is some </FONT>
<BR><FONT SIZE=3D2>&gt; level of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; stimulus signaling for customers to =
activate and deactivate </FONT>
<BR><FONT SIZE=3D2>&gt; features </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and program-in network codes and user =
phone numbers for </FONT>
<BR><FONT SIZE=3D2>&gt; forwarding.&nbsp; I </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; would expect that the level of user =
control would be much </FONT>
<BR><FONT SIZE=3D2>&gt; higher in IP </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; telephony.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Do you see the network cloud operating =
transparently and </FONT>
<BR><FONT SIZE=3D2>&gt; what service </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; you get is what you get?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Or is there another media-specific =
protocol that allows the user to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; explicitly control what network routes =
that his packets traverse?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Mike</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; At 12:22 PM 11/29/2000 -0500, Jonathan =
Lennox wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; On Wednesday, November 29 2000, =
&quot;hammer michael&quot; wrote to </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;Jonathan </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; Lennox, Tom_Gray@Mitel.COM, =
Cliff.Harris@nokia.com, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; iptel@lists.bell-labs.com&quot; =
saying:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&nbsp; &gt; You could potentially have =
a network selection based on dynamic </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; network</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&nbsp; &gt; characteristics.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&nbsp; &gt; Route through network A =
(the cheapest) unless it is </FONT>
<BR><FONT SIZE=3D2>&gt; congested or </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; denies me</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&nbsp; &gt; service,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&nbsp; &gt; otherwise route through =
network B while QoS &gt; X, else ...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&nbsp; &gt; I know that bandwidth is =
supposed to be free and plentiful, but </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; could you</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&nbsp; &gt; foresee networks of the =
future dynamically changing their rates </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; based on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;&nbsp; &gt; demand and users selecting =
the better alternatives for routing?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; Yes, absolutely, but this is way out =
of scope for the CPL. </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Remember, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; CPL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; controls *signalling*, and the network =
selection you're </FONT>
<BR><FONT SIZE=3D2>&gt; talking about </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; is for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; *media*.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; If I place a call to =
sip:foo@example.com, and the 200 </FONT>
<BR><FONT SIZE=3D2>&gt; response to the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; INVITE</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; has 128.59.19.147 in its SDP, I'm =
going to send my packets to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; 128.59.19.147,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; regardless of what route my INVITE =
took.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; If I'm using manyfolks, I'll also set =
up a resource reservation to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; that IP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; address.&nbsp; That's the point at =
which the service provider should </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; intervene to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; figure out what route they want my =
packets to take.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; -- </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; Jonathan Lennox</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; lennox@cs.columbia.edu</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; IPTEL mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; IPTEL@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; <A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/iptel" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/iptel</A><=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; IPTEL mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; IPTEL@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/iptel" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/iptel</A><=
/FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; IPTEL mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; IPTEL@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/iptel" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/iptel</A><=
/FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>---</FONT>
<BR><FONT SIZE=3D2>Jonathan D. =
Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
72 Eagle Rock Ave.</FONT>
<BR><FONT SIZE=3D2>Chief =
Scientist&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; First Floor</FONT>
<BR><FONT =
SIZE=3D2>dynamicsoft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
East Hanover, NJ 07936</FONT>
<BR><FONT =
SIZE=3D2>jdrosen@dynamicsoft.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; FAX:&nbsp;&nbsp; (973) 952-5050</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.cs.columbia.edu/~jdrosen" =
TARGET=3D"_blank">http://www.cs.columbia.edu/~jdrosen</A>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PHONE: (973) 952-5000</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.dynamicsoft.com" =
TARGET=3D"_blank">http://www.dynamicsoft.com</A></FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>IPTEL mailing list</FONT>
<BR><FONT SIZE=3D2>IPTEL@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/iptel" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/iptel</A><=
/FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C05ACF.F9BBF9F0--

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Nov 30 08:35:01 2000
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 IAA04550
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 08:35:00 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1C87544384; Thu, 30 Nov 2000 07:35:03 -0500 (EST)
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 AAAA044357
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 07:34:49 -0500 (EST)
Received: from ORANLT (oran-home-ss20.cisco.com [171.69.210.4])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id FAA13331;
	Thu, 30 Nov 2000 05:34:39 -0800 (PST)
From: "David Oran" <oran@cisco.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>, <hsalama@cisco.com>
Cc: <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] TRIP for gateways
Organization: Cisco Systems
Message-ID: <000401c05ad2$4a6970b0$04d245ab@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2202
In-Reply-To: <B65B4F8437968F488A01A940B21982BF9AAD0D@DYN-EXCH-001.dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 08:34:37 -0500
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA04550

> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com 
> [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Jonathan 
> Rosenberg
> Sent: Thursday, November 30, 2000 2:16 AM
> To: 'hsalama@cisco.com'
> Cc: 'iptel@lists.bell-labs.com'
> Subject: RE: [IPTEL] TRIP for gateways
> 
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Hussein F. Salama [mailto:hsalama@cisco.com]
> > Sent: Monday, November 27, 2000 6:46 PM
> > To: Jonathan Rosenberg
> > Cc: 'iptel@lists.bell-labs.com'
> > Subject: Re: [IPTEL] TRIP for gateways
> > 
> > 
> > 
> > 
> > Jonathan Rosenberg wrote:
> > > 
> > > Folks,
> > > 
> > > At the last two meetings, Hussein and I have presented a
> > draft on the usage
> > > of TRIP for gateways. The problem that the draft is trying
> > to address comes
> > > up more and more, and it is becoming urgent that the group
> > come to some kind
> > > of decision regarding this work. We can discuss this at the
> > meeting, of
> > > course, but I'd much prefer to start a list discussion
> > first so we can
> > > identify what the problems are.
> > 
> > Before going into the details of SLP and TRIP, we need to 
> agree on the 
> > requirements. Here are a few questions to get started:
> > - Is multi-hop call routing a requirement for intra-domain
> > calls? Or is
> > a single-hop sufficient?
> 
> I think you clearly need multihop. I know of numerous ITSP 
> networks that are built with many levels of proxies doing a 
> variety of different things.
>
I find this observation persuasive.
 
> 
> 
> > - Is aggregation within a domain required?
> 
> Again, I would say yes. I could imagine an ITSP that has POPs 
> around the country, and they have LSs in each POP that 
> propagate reachability from that POP up to a central ITSP 
> access point. That access point would aggregate all these 
> routes, and advertise them out to their customers.
>
This is certainly possible, but aggregation may or may not be needed for this level of scaling. Since aggregation is more or less the same algorithmically and configuration-wise for inter- and intra-domain  (modulo policy complexities in the inter-domain case) it seems reasonable to allow aggregation in the intra-domain case.

> 
> > - Is it required to advertise the services (e.g. voice or fax) and 
> > capabilities (e.g. which codecs) a specific route supports?
> 
> Yes, but I think information like this should not be 
> propagated beyond a single hop from the gateways. It simply 
> doesn't scale since it can't be aggregated.
>
The anti-aggregation properties of these things are tricky. If you have a set of gateways, each with a route to the same destination set, only some of which support CODEC foo, you reasonably could do an aggregate advertisement. What cannot be aggregated is partially overlapping sets of attributes since the aggregation might then be advertising a route the union of whose properties is not available for any single call.

Similarly, prohibiting multi-hop propagation because it doesn't scale without aggregation is probably unwise because many domains will be small enough for the information to propagate just fine. We should leave this in the domain of configuration, in a similar way to how IGPs don't have a hard upper bound on the size of an area when configured for hierarchical routing.


> > - Dynamic attributes, e.g. residual capacity of GW?
> 
> Yes. Using a proxy/LS to front a gateway farm, load balancing 
> across it, is an absolutely critical function. To do this 
> right, it needs to know these residual capacities.
>
Agreed. Defining the exact metrics may be a bit challenging though. A single linearly encoded scalar may or many not be sufficient.

> > - What's the required convergence time when a route changes?
> 
> Very fast. On the order of seconds. We don't want to drop 
> calls when a box fails.
>
Local convergence (e.g. between a set of gateways and a localized set of location servers) ought to be order 1-2 seconds. One trick I've seen employed to cut down on reporting latency and on overhead, is to piggyback the metric updates on the call teardown messages and route those messages through the proxies (I'm not advocating this, by any means, just pointing out that we need to be able to both have high responsiveness with reasonable overhead and reasonable stability. 

Interestingly enough, the stability properties for call routing may be enough different than for IP routing that we want different mechanisms, or at least different values of things like hold-downs. A colleague pointed out to me that in the case of IP it is important for good news to have longer hold-downs than bad news, to prevent oscillations and looping packets. By contrast, in the case of call routing, we have 486 Busy for feedback and the ability to do retry and hence holddowns may want to be shorter for good news and longer for bad news.

> > - Gateway registration vs. intra-domain call routing, are
> > they different
> > problems?
> 
> Well, that's not a requirements question. A better question 
> is: what are the requirements for gateway registration, what 
> are the requirements for intra-domain routing, and then you 
> can decide if they are the same.
>
This strikes me as equivalent to the question "are host-router protocols different from router-router protocols". In the IP world they are. In the call routing world I suspect that the protocol machinery is different (c.f. TRIP-lite), but that the message syntax and attribute semantics can (and probably should) be the same.

Dave.
> -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
> 


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Nov 30 09:46:59 2000
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 JAA04873
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 09:46:59 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E222F443DC; Thu, 30 Nov 2000 08:47:02 -0500 (EST)
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 915EF44357
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 08:46:50 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA10682;
	Thu, 30 Nov 2000 09:46:32 -0500 (EST)
Message-ID: <3A266848.7057745E@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'hammer michael'" <mhammer@cisco.com>, Jiri Kuthan <kuthan@fokus.gmd.de>,
        James Undery <jundery@ubiquity.net>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
References: <B65B4F8437968F488A01A940B21982BF9AAD01@DYN-EXCH-001.dynamicsoft.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 09:46:32 -0500
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> Michael,
> 
> This is a good point. What you are asking for is non-repudiation of script
> uploads. Unfortunately, I think its harder to do than you imply. Even if I
> have a signed script from you, you could argue that you did indeed sign the
> script, but never uploaded it. To prove that you uploaded it, I would have
> to remember the message exchanges for the transport itself. I don't think
> there is a way around that.

Without trying to play lawyer here, you rarely need absolute proof, but
rather just credible evidence, particularly in a civil suit for damages.
If your signed script shows up on a server, you have to explain how it
got there without your knowledge or consent, particularly if the server
operator can demonstrate that uploading requires some kind of
authentication, as it invariably will. "My dog stole my key and my evil
twin then uploaded the script" is not likely to convince a judge. Thus,
we should be careful not to try to impose requirements that have little
to do with the real world. Indeed, you probably don't even need a signed
script. Requiring authentication during upload means that there is a
prima facie case that you did the upload. You then have to make a
reasonable case that the operator turned your perfectly harmless script
into a monster script that brought down the phone network. Any operator
will write a clause into its contract that will say something like
"you're responsible for your account; if your account uploads a
malicious script, it's your problem".

In real life, we operate with lots of such presumptions of validity. For
example, most receipts are easily forged, as are faxes, yet they are
routinely accepted as evidence. (Most contracts don't require written
evidence at all, but that's a separate issue.)

> 
> Like many other groups that work on security, we have begun discussing
> technology solutions without identifying the requirements. Mike has proposed
> one requirement, which is non-repudiation of script uploads. What other
> security requirements do we have? Once we know those, we can identify
> whether the existing security mechanisms are sufficient.
> 
> -Jonathan R.
> 

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Nov 30 09:52:57 2000
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 JAA07095
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 09:52:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6E221443E9; Thu, 30 Nov 2000 08:53:01 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net [208.37.18.67])
	by lists.bell-labs.com (Postfix) with ESMTP id 8120D44357
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 08:52:57 -0500 (EST)
Received: from matt.ipverse.com (ts001d36.new-la.concentric.net [206.173.73.48]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id XNX7NR1X; Thu, 30 Nov 2000 06:52:49 -0800
Message-Id: <5.0.2.1.2.20001130062828.0212c600@pop3.ipverse.com>
X-Sender: matt@ipverse.com@pop3.ipverse.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
From: Matt Holdrege <matt@ipverse.com>
Subject: RE: [IPTEL] TRIP for gateways
Cc: "'James Kempf'" <James.Kempf@eng.sun.com>, iptel@lists.bell-labs.com,
        erik.guttman@germany.sun.com
In-Reply-To: <B65B4F8437968F488A01A940B21982BF9AAD0E@DYN-EXCH-001.dynami
 csoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 06:52:34 -0800

At 02:20 AM 11/30/2000 -0500, Jonathan Rosenberg wrote:
>Indeed, the fundamental question is push vs. pull.
>
>I think gateway routing needs to be push primarily for performance reasons.
>Calls arrive at a proxy server at potentially very high rates; if each call
>needs to generate an independent query for service, you end up (1) adding
>latency to each call setup for the query/response, (2) introducing a serious
>processing burden for all devices, (3) add a lot of network traffic for the
>queries and responses. By pushing the information as it changes, we
>eliminate the additional call setup latency, reduce the processing load, and
>reduce the messaging load.

You forgot to add the management aspect of push which could be a 
significant barrier in large and/or complex networks. I think we have to be 
able to pull and it is really the decision of the carrier architect. 
Hopefully we can somehow allow both methods for flexibility. I know that is 
not generally good for interoperability though.


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Nov 30 10:08:52 2000
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 KAA13460
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 10:08:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 120C3443FB; Thu, 30 Nov 2000 09:06:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 6488644357
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 08:22:59 -0500 (EST)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257)
 id <0G4U00H01D9UBR@firewall.mcit.com> for iptel@lists.bell-labs.com; Thu,
 30 Nov 2000 14:22:42 +0000 (GMT)
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0G4U00CHSD9TB3@firewall.mcit.com>; Thu,
 30 Nov 2000 14:22:41 +0000 (GMT)
Received: from CONVERSION-DAEMON by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 id <0G4U00J01D9THX@pmismtp02.wcomnet.com>; Thu,
 30 Nov 2000 14:22:41 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with SMTP id <0G4U00J01D9THW@pmismtp02.wcomnet.com>;
 Thu, 30 Nov 2000 14:22:41 +0000 (GMT)
Received: from hsinnreich ([166.44.60.141])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with SMTP id <0G4U007IGD9ES0@pmismtp02.wcomnet.com>; Thu,
 30 Nov 2000 14:22:28 +0000 (GMT)
From: Henry Sinnreich <Henry.Sinnreich@wcom.com>
Subject: RE: [IPTEL] CPL Question About Priority
In-reply-to: 
 <B9159C1D923DD4119EF8002048400C2D02D46592@zhard00d.europe.nortel.com>
To: Mark Gibson <mrg@nortelnetworks.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Lakshmi Krishnamurthy'" <lnk2@lucent.com>,
        hammer michael <mhammer@cisco.com>
Cc: iptel@lists.bell-labs.com
Message-id: <NEBBLDFFKGAJDPBENMDNCEAKDEAA.Henry.Sinnreich@wcom.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 08:22:58 -0600
Content-Transfer-Encoding: 7bit

Mark Gison writes:

>RSVP layer comes back and says "sorry, not enough bits" and the session
clears down
The new drafts
http://ietf.org/internet-drafts/draft-gross-sipaq-00.txt
http://ietf.org/internet-drafts/draft-gross-cops-sip-00.txt
clearly take the approach that if RSVP reservation fails, the caller is
given the option to continue the call without QoS.

>there are still some 3-4 rounds trips of SIP signalling
The amount of messaging has also been minimized, please see
http://ietf.org/internet-drafts/draft-johnston-sip-osp-token-01.txt

>use COPS to tell the management layer and have it signal the billing layer
Great minds think alike :-)
Please again, see the above.

The topic area around SIP-Resources-AAA is surfacing again and again  in
various drafts, so I look forward to a good discussion in the WG.

Henry

-----Original Message-----
From: iptel-admin@lists.bell-labs.com
[mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Mark Gibson
Sent: Thursday, November 30, 2000 7:18 AM
To: 'Jonathan Rosenberg'; 'Lakshmi Krishnamurthy'; hammer michael
Cc: iptel@lists.bell-labs.com
Subject: RE: [IPTEL] CPL Question About Priority


I think that there's another angle on this debate that's being ignored. I
might be willing to buy the fact that RSVP is OK to get me a QoS pipe
providing my network policy layer is working efficiently and I can provision
my core. However I think this problem also encompasses resilience to mass
calling events and alternative operator selection.
In the former case, assuming the manyfolks operation (which I'm not
massively familiar so do forgive inaccuracy), there are still some 3-4
rounds trips of SIP signalling before the RSVP layer comes back and says
"sorry, not enough bits" and the session clears down. Under mass calling
event conditions this is a lot of signalling, probably enough to bring
servers down - lets face it, the current PSTN creaks when Ticketmaster has
hot tickets for sale. Especially when you consider that this signalling is
likely to be concentrated at border Proxies. Surely its better for that
Proxy to be pre-warned that it just can't accept new sessions and reject the
call there & then.
In the latter case, I might have a preferential billing arrangement with one
core provider but will accept a provider that will route my call according
to certain service level conditions. As things like price are likely to be
cumulative and depend on trading agreements between operators, its unlikely
that we can source define a single best route so I'd like to try a number to
find the optimal one. And I will want to choose before RSVP establishes a
connection that I don't want to pay for. So I either,
a) sort this out using the SIP signalling round trips - perhaps define an
sdp equivalence that does costing of routes and availability discovery and
extend SIP to permit forking and recombining INVITE without generating a
loop-detect error to nip call attempts that can't be handled in the bud
b) develop extensions to RSVP for its POLICY_ELEMENT to allow source routing
to be indicated (loosely) and perhaps cumulative cost and use COPS to tell
the management layer and have it signal the billing layer as to the final
route.
Note that b) runs the risk of the call blocking when its requirements cannot
be met at a point after resource has been committed by the Resv but before
the end-to-end connection is established, causing possible future call
blocking.
I appreciate that this is reasonably off topic for most of this list but its
clearly important. If anyone wants to take this offline and explore this
signalling and reservation issue in more detail perhaps we could get
together with Mike and Lakshmi.
Cheers
Mark Gibson


 -----Original Message-----
From:   Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent:   Thursday, November 30, 2000 4:22 AM
To:     'Lakshmi Krishnamurthy'; hammer michael
Cc:     iptel@lists.bell-labs.com
Subject:        RE: [IPTEL] CPL Question About Priority


Correct, the application knows best what its QoS requirements are. And thats
why IETF has developed protocols like RSVP that allow the users to ask the
network for various levels of QoS. Whether it scales or not is a separate
discussion thats out of scope here.
As per senders of IP packets getting to determine the route through the IP
network; there is the possibility of such a thing using loose source IP
routing. But, in practice, this is never done and frought with problems.
There are serious topology discovery and other issues that need to be
resolved; a minor problem is that packets marked with loose source routes
are slow-path on routers, resulting in increased delay. I don't think anyone
uses loose source routing at all.
That aside, this is all completely out of scope for CPL. As Jonathan L. has
correctly observed, SIP signaling routing is completely orthogonal to media
routing, and for really, really good reasons (i.e., not re-inventing yet
another forwarding, switching, routing layer within the network just for
RTP; the IP network already knows how to deliver the RTP packets in the most
direct path from originator to recipient).
-Jonathan R.

> -----Original Message-----
> From: Lakshmi Krishnamurthy [mailto:lnk2@lucent.com]
> Sent: Wednesday, November 29, 2000 4:06 PM
> To: hammer michael
> Cc: iptel@lists.bell-labs.com
> Subject: Re: [IPTEL] CPL Question About Priority
>
>
> I agree with this observation. The application always knows best in
> terms of the nature & type of resources it needs accomodated by the
> network. There needs to be a way of communicating this requirement to
> the IP layer.
>
> This need not be an explicit list of QoS params, but
> something that is a
> user-friendly mapping could be in order.
>
> hammer michael wrote:
>
> > I understand to an extent the distinction you are making,
> that the IP
> > layer, given the end-point address can figure out how to route the
> > packets carrying the media along with resource
> reservations.  However,
> > the existence of Via, Route, and Record-Route parameters
> and the usage
> > for routes longer than two proxies would seem to undermine
> the purity
> > of your position.  Ultimately the purpose of signaling is
> to establish
> > the media path, so they are not so totally divorced.
> >
> > I thought that one of the evolutionary goals of the IP
> telephony was
> > to put as much control in the hands of the end-user.  If
> such control
> > is in the IP layer, how does the user control that?  Will that be a
> > Web-level interface or must he be an IP guru?  I was envisioning a
> > little more control in the Application layer via some more
> > user-friendly features.  In the current PSTN, there is some
> level of
> > stimulus signaling for customers to activate and deactivate
> features
> > and program-in network codes and user phone numbers for
> forwarding.  I
> > would expect that the level of user control would be much
> higher in IP
> > telephony.
> >
> > Do you see the network cloud operating transparently and
> what service
> > you get is what you get?
> > Or is there another media-specific protocol that allows the user to
> > explicitly control what network routes that his packets traverse?
> >
> > Mike
> >
> >
> > At 12:22 PM 11/29/2000 -0500, Jonathan Lennox wrote:
> >
> >> On Wednesday, November 29 2000, "hammer michael" wrote to
> "Jonathan
> >> Lennox, Tom_Gray@Mitel.COM, Cliff.Harris@nokia.com,
> >> iptel@lists.bell-labs.com" saying:
> >>
> >>  > You could potentially have a network selection based on dynamic
> >> network
> >>  > characteristics.
> >>  > Route through network A (the cheapest) unless it is
> congested or
> >> denies me
> >>  > service,
> >>  > otherwise route through network B while QoS > X, else ...
> >>  >
> >>  > I know that bandwidth is supposed to be free and plentiful, but
> >> could you
> >>  > foresee networks of the future dynamically changing their rates
> >> based on
> >>  > demand and users selecting the better alternatives for routing?
> >>
> >> Yes, absolutely, but this is way out of scope for the CPL.
>  Remember,
> >> CPL
> >> controls *signalling*, and the network selection you're
> talking about
> >> is for
> >> *media*.
> >>
> >> If I place a call to sip:foo@example.com, and the 200
> response to the
> >> INVITE
> >> has 128.59.19.147 in its SDP, I'm going to send my packets to
> >> 128.59.19.147,
> >> regardless of what route my INVITE took.
> >>
> >> If I'm using manyfolks, I'll also set up a resource reservation to
> >> that IP
> >> address.  That's the point at which the service provider should
> >> intervene to
> >> figure out what route they want my packets to take.
> >>
> >> --
> >> Jonathan Lennox
> >> lennox@cs.columbia.edu
> >>
> >> _______________________________________________
> >> 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
>
>
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
>
---
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


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Nov 30 10:23:28 2000
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 KAA19354
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 10:23:28 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B175E44397; Thu, 30 Nov 2000 09:23:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141])
	by lists.bell-labs.com (Postfix) with ESMTP id 634CA44357
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 09:22:46 -0500 (EST)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA14109; Thu, 30 Nov 2000 10:22:37 -0500 (EST)
Received: from mhammer-nt.cisco.com (va-dhcp198-137.cisco.com [161.44.198.137])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AEZ06130;
	Thu, 30 Nov 2000 10:22:36 -0500 (EST)
Message-Id: <4.3.2.7.2.20001130102255.00ba5d20@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
From: hammer michael <mhammer@cisco.com>
Subject: Re: CPLng (was [IPTEL] agenda items)
Cc: Jiri Kuthan <kuthan@fokus.gmd.de>, James Undery <jundery@ubiquity.net>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
In-Reply-To: <3A266848.7057745E@cs.columbia.edu>
References: <B65B4F8437968F488A01A940B21982BF9AAD01@DYN-EXCH-001.dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 10:28:38 -0800

Quick comment on the operator changing the script:  Normally the signature 
would be based on a hash of the message (i.e. script).  Changes to the 
script by the operator would cause the signature verification to 
fail.  Therefore, I do not think that claims that the operator changed the 
script, given a valid signature would hold.

I would agree that a claim that an operator pulled up a malicious script 
and damaged his own network would not hold water, especially if the process 
was one where the scripts are pushed to the server.

Mike


At 09:46 AM 11/30/2000 -0500, Henning G. Schulzrinne wrote:
>Jonathan Rosenberg wrote:
> >
> > Michael,
> >
> > This is a good point. What you are asking for is non-repudiation of script
> > uploads. Unfortunately, I think its harder to do than you imply. Even if I
> > have a signed script from you, you could argue that you did indeed sign the
> > script, but never uploaded it. To prove that you uploaded it, I would have
> > to remember the message exchanges for the transport itself. I don't think
> > there is a way around that.
>
>Without trying to play lawyer here, you rarely need absolute proof, but
>rather just credible evidence, particularly in a civil suit for damages.
>If your signed script shows up on a server, you have to explain how it
>got there without your knowledge or consent, particularly if the server
>operator can demonstrate that uploading requires some kind of
>authentication, as it invariably will. "My dog stole my key and my evil
>twin then uploaded the script" is not likely to convince a judge. Thus,
>we should be careful not to try to impose requirements that have little
>to do with the real world. Indeed, you probably don't even need a signed
>script. Requiring authentication during upload means that there is a
>prima facie case that you did the upload. You then have to make a
>reasonable case that the operator turned your perfectly harmless script
>into a monster script that brought down the phone network. Any operator
>will write a clause into its contract that will say something like
>"you're responsible for your account; if your account uploads a
>malicious script, it's your problem".
>
>In real life, we operate with lots of such presumptions of validity. For
>example, most receipts are easily forged, as are faxes, yet they are
>routinely accepted as evidence. (Most contracts don't require written
>evidence at all, but that's a separate issue.)
>
> >
> > Like many other groups that work on security, we have begun discussing
> > technology solutions without identifying the requirements. Mike has 
> proposed
> > one requirement, which is non-repudiation of script uploads. What other
> > security requirements do we have? Once we know those, we can identify
> > whether the existing security mechanisms are sufficient.
> >
> > -Jonathan R.
> >
>
>--
>Henning Schulzrinne   http://www.cs.columbia.edu/~hgs



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Nov 30 10:37:50 2000
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 KAA25378
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 10:37:49 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4919E4440C; Thu, 30 Nov 2000 09:37:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from southpass.baynetworks.com (ns2.BayNetworks.COM [134.177.3.16])
	by lists.bell-labs.com (Postfix) with ESMTP id F3CDA44408
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 09:14:52 -0500 (EST)
Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107])
	by southpass.baynetworks.com (8.9.1/8.9.1) with ESMTP id HAA27575
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 07:05:59 -0800 (PST)
Received: from shasta-exch.shastanets.com (mailserver.shastanets.com [47.82.16.150])
	by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id HAA12162
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 07:13:00 -0800 (PST)
Received: by mailserver.shastanets.com with Internet Mail Service (5.5.2650.21)
	id <WMLQA9QK>; Thu, 30 Nov 2000 07:12:06 -0800
Message-ID: <940E42DB5D7FD4119C420004ACE6E0A04CAA0F@mailserver.shastanets.com>
From: Reinaldo Penno Filho <rpenno@shastanets.com>
To: "'iptel@lists.bell-labs.com '" <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] TRIP for gateways
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 07:11:59 -0800

I would have to agree that trying to decide push or pull at this time is
kind of premature. Probably in the end of the day we would have to specify
both methods and operational experience will prove which one is better and
in what conditions. What we could do to guarantee interoperability is say
one is MUST and the other SHOULD. 

Reinaldo Penno
NortelNetworks
rpenno@nortelnetworks.com

-----Original Message-----
From: Matt Holdrege
To: Jonathan Rosenberg
Cc: 'James Kempf'; iptel@lists.bell-labs.com; erik.guttman@germany.sun.com
Sent: 11/30/00 6:52 AM
Subject: RE: [IPTEL] TRIP for gateways

At 02:20 AM 11/30/2000 -0500, Jonathan Rosenberg wrote:
>Indeed, the fundamental question is push vs. pull.
>
>I think gateway routing needs to be push primarily for performance
reasons.
>Calls arrive at a proxy server at potentially very high rates; if each
call
>needs to generate an independent query for service, you end up (1)
adding
>latency to each call setup for the query/response, (2) introducing a
serious
>processing burden for all devices, (3) add a lot of network traffic for
the
>queries and responses. By pushing the information as it changes, we
>eliminate the additional call setup latency, reduce the processing
load, and
>reduce the messaging load.

You forgot to add the management aspect of push which could be a 
significant barrier in large and/or complex networks. I think we have to
be 
able to pull and it is really the decision of the carrier architect. 
Hopefully we can somehow allow both methods for flexibility. I know that
is 
not generally good for interoperability though.


_______________________________________________
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 Nov 30 10:46:27 2000
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 KAA29301
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 10:46:26 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6DA5C44411; Thu, 30 Nov 2000 09:37:08 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by lists.bell-labs.com (Postfix) with ESMTP id 1CEBC44400
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 09:25:30 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10916;
	Thu, 30 Nov 2000 10:25:18 -0500 (EST)
Received: from stl-server-01.pit.comms.marconi.com (stl-server-01.pit.comms.marconi.com [169.144.36.27])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA00064;
	Thu, 30 Nov 2000 10:25:14 -0500 (EST)
Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <W83N5JPG>; Thu, 30 Nov 2000 10:24:31 -0500
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EAC1@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Matt Holdrege'" <matt@ipverse.com>
Cc: "'James Kempf'" <James.Kempf@eng.sun.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        iptel@lists.bell-labs.com, erik.guttman@germany.sun.com
Subject: RE: [IPTEL] TRIP for gateways
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 10:24:29 -0500

Could you expand on this Matt?  I don't get it.

I thought the discussion here was for gateway location WITHIN a network.
TRIP as is does the internetworking stuff.  In that environment,
what are the management reasons?  Seems to me that the BGP-like
push approach is exactly what you want for a large complex network.

Brian

> -----Original Message-----
> From: Matt Holdrege [mailto:matt@ipverse.com]
> Sent: Thursday, November 30, 2000 9:53 AM
> To: Jonathan Rosenberg
> Cc: 'James Kempf'; iptel@lists.bell-labs.com;
> erik.guttman@germany.sun.com
> Subject: RE: [IPTEL] TRIP for gateways
> 
> 
> At 02:20 AM 11/30/2000 -0500, Jonathan Rosenberg wrote:
> >Indeed, the fundamental question is push vs. pull.
> >
> >I think gateway routing needs to be push primarily for 
> performance reasons.
> >Calls arrive at a proxy server at potentially very high 
> rates; if each call
> >needs to generate an independent query for service, you end 
> up (1) adding
> >latency to each call setup for the query/response, (2) 
> introducing a serious
> >processing burden for all devices, (3) add a lot of network 
> traffic for the
> >queries and responses. By pushing the information as it changes, we
> >eliminate the additional call setup latency, reduce the 
> processing load, and
> >reduce the messaging load.
> 
> You forgot to add the management aspect of push which could be a 
> significant barrier in large and/or complex networks. I think 
> we have to be 
> able to pull and it is really the decision of the carrier architect. 
> Hopefully we can somehow allow both methods for flexibility. 
> I know that is 
> not generally good for interoperability though.
> 
> 
> _______________________________________________
> 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 Nov 30 11:52:01 2000
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 LAA02233
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 11:52:01 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5E21744425; Thu, 30 Nov 2000 10:52:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mail.storm.ca (storm.ca [209.87.239.69])
	by lists.bell-labs.com (Postfix) with ESMTP id E089744357
	for <IPTEL@lists.bell-labs.com>; Thu, 30 Nov 2000 10:45:29 -0500 (EST)
Received: from DavidZ ([209.87.228.147])
	by mail.storm.ca (8.9.3+Sun/8.9.3) with SMTP id LAA14081
	for <IPTEL@lists.bell-labs.com>; Thu, 30 Nov 2000 11:45:21 -0500 (EST)
From: "David Zinman" <david@ss8.com>
To: "IPTEL" <IPTEL@lists.bell-labs.com>
Subject: [IPTEL] FW: I-D ACTION:draft-zinman-trip-mib-00.txt
Message-ID: <NDBBIMHCHEHIBCDKLHLKCEEPCHAA.david@ss8.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_008A_01C05AC3.0677A200"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 11:45:23 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_008A_01C05AC3.0677A200
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

This is a public notice for a draft of a
proposed TRIP Management Information Base.
Comments are appreciated.

David Zinman
SS8 Networks.

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Wednesday, November 29, 2000 6:29 AM
To: IETF-Announce: ;IETF-Announce:;@loki.ietf.org
Subject: I-D ACTION:draft-zinman-trip-mib-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Management Information Base for Telephony Routing over
                          IP (TRIP)
	Author(s)	: D. Walker, D. Zinman
	Filename	: draft-zinman-trip-mib-00.txt
	Pages		: 28
	Date		: 28-Nov-00

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that are used to
manage for Telephony Routing over IP (TRIP) [17] devices.
Since TRIP [17] is modelled after the Border Gateway Protocol (BGP-4)
[20], the managed objects for TRIP are also modelled after RFC1657 -
Definitions of Managed Objects for the Fourth Version of the Border
Gateway Protocol (BGP-4) using SMIv2 [21].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zinman-trip-mib-00.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-zinman-trip-mib-00.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-zinman-trip-mib-00.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_000_008A_01C05AC3.0677A200
Content-Type: Message/External-body;
	name="ATT00122.dat"
Content-Disposition: attachment;
	filename="ATT00122.dat"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID:	<20001128133937.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-zinman-trip-mib-00.txt

------=_NextPart_000_008A_01C05AC3.0677A200
Content-Type: Message/External-body;
	name="draft-zinman-trip-mib-00.txt"
Content-Disposition: attachment;
	filename="draft-zinman-trip-mib-00.txt"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID:	<20001128133937.I-D@ietf.org>

------=_NextPart_000_008A_01C05AC3.0677A200--


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Nov 30 15:15:58 2000
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 PAA28521
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 15:15:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8F005443F4; Thu, 30 Nov 2000 14:16:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 39CEB44357
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 13:09:28 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21057;
	Thu, 30 Nov 2000 11:09:18 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA23962;
	Thu, 30 Nov 2000 11:09:14 -0800 (PST)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA29032;
	Thu, 30 Nov 2000 11:09:13 -0800 (PST)
Message-Id: <200011301909.LAA29032@nasnfs.eng.sun.com>
From: James Kempf <James.Kempf@eng.sun.com>
Reply-To: James Kempf <James.Kempf@eng.sun.com>
Subject: RE: [IPTEL] TRIP for gateways
To: James.Kempf@eng.sun.com, jdrosen@dynamicsoft.com
Cc: iptel@lists.bell-labs.com, erik.guttman@germany.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: VZSV0svo8u56VjYh1sFjXQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 11:08:46 -0800 (PST)

Jonathan,

 
>> 
>> I'm curious why you need to have the gateway push the 
>> reachability info
>> to the location server. Why can't the location server pull it from the
>> gateway?
>> 
>> In this scenario, the location server acts as a user agent and the
>> gateway acts as the service agent. The service advertisement consists
>> of the PSTN gateway's attributes and reachability info (as I 
>> understand
>> it from below, telephone prefixes). The location server periodically
>> performs an SLP SrvRqst for gateway service URLs, then performs an
>> SLP AttrRqst for the attributes. Alternatively, the location server
>> can include the SLP attribute list extension (see 
>> draft-guttman-svrloc-attrlist-ext-04.txt) to have the attributes
>> delivered along with the service URL.
>
>Indeed, the fundamental question is push vs. pull.
>
>I think gateway routing needs to be push primarily for performance reasons.
>Calls arrive at a proxy server at potentially very high rates; if each call
>needs to generate an independent query for service, you end up (1) adding
>latency to each call setup for the query/response, (2) introducing a serious
>processing burden for all devices, (3) add a lot of network traffic for the
>queries and responses. By pushing the information as it changes, we
>eliminate the additional call setup latency, reduce the processing load, and
>reduce the messaging load. 
>


In a pull model, I don't think that each call needs to necessarily cause
an independent query for services.

If each service advertisment contains a lease or timeout, then the
proxy server only needs to redo its query when the advertisement expires.
The granularity will determine what the messaging load and processing
load is, and needs to be set so that it reflects a realistic apprasial
of how often the external reachability information will change.

Of course the probability of getting stale information is higher with a pull 
model if the lifetimes are set too long,  so the tendency in situations where 
the service information changes dynamically is to decrease the lifetime, upping 
the processing load. 

If what you are trying to do is distribute routing information, then
something like a routing protocol that does push seems like it might
be the better approach, since any failure of freshness pretty much
invalidates the information. However, if what you are trying to
do is locate suitable gateway servers based on where they
can get you to, then perhaps a service discovery approach based on pull  seems 
like it would be more appropriate if the gateway servers' reachability service 
doesn't change often.

		jak
		
PS: Incidently, we have been working on a push protocol for SLP, to
allow a service client to subscribe to notifications of changes
in particular services. We are slowly moving the draft to Experimental.
The specification is in draft-kempf-srvloc-notify-04.txt. The design
pays particular attention to scalability issues, since we wanted
to avoid problems with network overload such as occured with 
Netware 4.0 SAP and at least one implementation of SLPv1 that was not
in compliance with RFC 2165.


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Nov 30 15:37:01 2000
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 PAA06215
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 15:36:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 38B4E443FD; Thu, 30 Nov 2000 14:37:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net [208.37.18.67])
	by lists.bell-labs.com (Postfix) with ESMTP id 63676443F7
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 14:36:14 -0500 (EST)
Received: from matt.ipverse.com (ts002d12.new-la.concentric.net [206.173.73.72]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id XNX7NRMZ; Thu, 30 Nov 2000 12:35:59 -0800
Message-Id: <5.0.2.1.2.20001130122933.0272f060@pop3.ipverse.com>
X-Sender: matt@ipverse.com@pop3.ipverse.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
From: Matt Holdrege <matt@ipverse.com>
Subject: RE: [IPTEL] TRIP for gateways
Cc: "'James Kempf'" <James.Kempf@eng.sun.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        iptel@lists.bell-labs.com, erik.guttman@germany.sun.com
In-Reply-To: <4FBEA8857476D311A03300204840E1CF01A6EAC1@whq-msgusr-02.pit
 .comms.marconi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 12:35:54 -0800

All of Jonathan's reasons for push are quite valid. But in large complex 
networks when you push, the pusher doesn't always know about all the 
roadbumps and policy variations in the field. Indeed when ISP's started 
using BGP they went through hell dealing with these issues. Some still do 
today. And some prefer to have manual control of the process which is 
essentially the same as pulling.

I'm sure if we think about it we can advocate the push method while 
allowing for some to pull in the information. But I don't know what bearing 
this has on SLP which is what we were originally talking about in this thread.


At 10:24 AM 11/30/2000 -0500, Rosen, Brian wrote:
>Could you expand on this Matt?  I don't get it.
>
>I thought the discussion here was for gateway location WITHIN a network.
>TRIP as is does the internetworking stuff.  In that environment,
>what are the management reasons?  Seems to me that the BGP-like
>push approach is exactly what you want for a large complex network.
>
>Brian
>
> > -----Original Message-----
> > From: Matt Holdrege [mailto:matt@ipverse.com]
> > Sent: Thursday, November 30, 2000 9:53 AM
> > To: Jonathan Rosenberg
> > Cc: 'James Kempf'; iptel@lists.bell-labs.com;
> > erik.guttman@germany.sun.com
> > Subject: RE: [IPTEL] TRIP for gateways
> >
> >
> > At 02:20 AM 11/30/2000 -0500, Jonathan Rosenberg wrote:
> > >Indeed, the fundamental question is push vs. pull.
> > >
> > >I think gateway routing needs to be push primarily for
> > performance reasons.
> > >Calls arrive at a proxy server at potentially very high
> > rates; if each call
> > >needs to generate an independent query for service, you end
> > up (1) adding
> > >latency to each call setup for the query/response, (2)
> > introducing a serious
> > >processing burden for all devices, (3) add a lot of network
> > traffic for the
> > >queries and responses. By pushing the information as it changes, we
> > >eliminate the additional call setup latency, reduce the
> > processing load, and
> > >reduce the messaging load.
> >
> > You forgot to add the management aspect of push which could be a
> > significant barrier in large and/or complex networks. I think
> > we have to be
> > able to pull and it is really the decision of the carrier architect.
> > Hopefully we can somehow allow both methods for flexibility.
> > I know that is
> > not generally good for interoperability though.
> >
> >
> > _______________________________________________
> > 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 Nov 30 15:57:58 2000
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 PAA13488
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 15:57:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B41764438A; Thu, 30 Nov 2000 14:58:01 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4])
	by lists.bell-labs.com (Postfix) with ESMTP id D82C2443F7
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 14:30:54 -0500 (EST)
Received: by mailserver.sylantro.com with Internet Mail Service (5.5.2650.21)
	id <X7PDYHZQ>; Thu, 30 Nov 2000 12:30:41 -0800
Message-ID: <79FEAA5FABA7D411BF580001023D1BBD0BFF88@mailserver.sylantro.com>
From: Sharath Rajasekar <Sharath.Rajasekar@sylantro.com>
To: James Kempf <James.Kempf@eng.sun.com>, jdrosen@dynamicsoft.com
Cc: iptel@lists.bell-labs.com, erik.guttman@germany.sun.com
Subject: RE: [IPTEL] TRIP for gateways
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 12:30:41 -0800

Hi,

I agree that a pull model for this *may* be feasible considering the load
balancing and so on but this solution as I see it will only be effective
within a single (dns) domain. Wouldnt a question of scalability arise if the
pull model were to be extended to LSs spanning multiple domains ? That is,
to solve the problem of publishing reachibility information of all gateways
serviced by say
a service provider atwww.foo.com domain. What happens when a service
provider is servicing several domains and subdomains, and has to keep track
of how many gateways etc are around in each domain ?

Is it not possible to have a system of pull within a domain wherein a LS can
pull all necessary gateway reachibility information from within a domain and

push between/among domains ?


Sharath Rajasekar



-----Original Message-----
From: James Kempf [mailto:James.Kempf@eng.sun.com]
Sent: Thursday, November 30, 2000 11:09 AM
To: James.Kempf@eng.sun.com; jdrosen@dynamicsoft.com
Cc: iptel@lists.bell-labs.com; erik.guttman@germany.sun.com
Subject: RE: [IPTEL] TRIP for gateways


Jonathan,

 
>> 
>> I'm curious why you need to have the gateway push the 
>> reachability info
>> to the location server. Why can't the location server pull it from the
>> gateway?
>> 
>> In this scenario, the location server acts as a user agent and the
>> gateway acts as the service agent. The service advertisement consists
>> of the PSTN gateway's attributes and reachability info (as I 
>> understand
>> it from below, telephone prefixes). The location server periodically
>> performs an SLP SrvRqst for gateway service URLs, then performs an
>> SLP AttrRqst for the attributes. Alternatively, the location server
>> can include the SLP attribute list extension (see 
>> draft-guttman-svrloc-attrlist-ext-04.txt) to have the attributes
>> delivered along with the service URL.
>
>Indeed, the fundamental question is push vs. pull.
>
>I think gateway routing needs to be push primarily for performance reasons.
>Calls arrive at a proxy server at potentially very high rates; if each call
>needs to generate an independent query for service, you end up (1) adding
>latency to each call setup for the query/response, (2) introducing a
serious
>processing burden for all devices, (3) add a lot of network traffic for the
>queries and responses. By pushing the information as it changes, we
>eliminate the additional call setup latency, reduce the processing load,
and
>reduce the messaging load. 
>


In a pull model, I don't think that each call needs to necessarily cause
an independent query for services.

If each service advertisment contains a lease or timeout, then the
proxy server only needs to redo its query when the advertisement expires.
The granularity will determine what the messaging load and processing
load is, and needs to be set so that it reflects a realistic apprasial
of how often the external reachability information will change.

Of course the probability of getting stale information is higher with a pull

model if the lifetimes are set too long,  so the tendency in situations
where 
the service information changes dynamically is to decrease the lifetime,
upping 
the processing load. 

If what you are trying to do is distribute routing information, then
something like a routing protocol that does push seems like it might
be the better approach, since any failure of freshness pretty much
invalidates the information. However, if what you are trying to
do is locate suitable gateway servers based on where they
can get you to, then perhaps a service discovery approach based on pull
seems 
like it would be more appropriate if the gateway servers' reachability
service 
doesn't change often.

		jak
		
PS: Incidently, we have been working on a push protocol for SLP, to
allow a service client to subscribe to notifications of changes
in particular services. We are slowly moving the draft to Experimental.
The specification is in draft-kempf-srvloc-notify-04.txt. The design
pays particular attention to scalability issues, since we wanted
to avoid problems with network overload such as occured with 
Netware 4.0 SAP and at least one implementation of SLPv1 that was not
in compliance with RFC 2165.


_______________________________________________
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 Nov 30 15:59:13 2000
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 PAA13920
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 15:59:12 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6F7E944426; Thu, 30 Nov 2000 14:58:08 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by lists.bell-labs.com (Postfix) with ESMTP id DB7A044357
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 14:43:10 -0500 (EST)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257)
 id <0G4U00601USLRY@firewall.mcit.com> for iptel@lists.bell-labs.com; Thu,
 30 Nov 2000 20:41:09 +0000 (GMT)
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0G4U0061NUSKH0@firewall.mcit.com>; Thu,
 30 Nov 2000 20:41:09 +0000 (GMT)
Received: from CONVERSION-DAEMON by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 id <0G4U00401USKP7@pmismtp02.wcomnet.com>; Thu,
 30 Nov 2000 20:41:08 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with SMTP id <0G4U00401USFO1@pmismtp02.wcomnet.com>;
 Thu, 30 Nov 2000 20:41:08 +0000 (GMT)
Received: from hsinnreich ([166.44.60.141])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with SMTP id <0G4U0045WUS10J@pmismtp02.wcomnet.com>; Thu,
 30 Nov 2000 20:40:54 +0000 (GMT)
From: Henry Sinnreich <Henry.Sinnreich@wcom.com>
Subject: RE: [IPTEL] TRIP for gateways
In-reply-to: <5.0.2.1.2.20001130062828.0212c600@pop3.ipverse.com>
To: Matt Holdrege <matt@ipverse.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'James Kempf'" <James.Kempf@eng.sun.com>, iptel@lists.bell-labs.com,
        erik.guttman@germany.sun.com
Message-id: <NEBBLDFFKGAJDPBENMDNGEBFDEAA.Henry.Sinnreich@wcom.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 14:41:19 -0600
Content-Transfer-Encoding: 7bit

>it is really the decision of the carrier architect

could not agree more :-)

The service provider should at least know where the border routers (or
gates) to other ISPs are and keep a real good eye on them if they want to
stay in business.

Henry

-----Original Message-----
From: iptel-admin@lists.bell-labs.com
[mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Matt Holdrege
Sent: Thursday, November 30, 2000 8:53 AM
To: Jonathan Rosenberg
Cc: 'James Kempf'; iptel@lists.bell-labs.com;
erik.guttman@germany.sun.com
Subject: RE: [IPTEL] TRIP for gateways


At 02:20 AM 11/30/2000 -0500, Jonathan Rosenberg wrote:
>Indeed, the fundamental question is push vs. pull.
>
>I think gateway routing needs to be push primarily for performance reasons.
>Calls arrive at a proxy server at potentially very high rates; if each call
>needs to generate an independent query for service, you end up (1) adding
>latency to each call setup for the query/response, (2) introducing a
serious
>processing burden for all devices, (3) add a lot of network traffic for the
>queries and responses. By pushing the information as it changes, we
>eliminate the additional call setup latency, reduce the processing load,
and
>reduce the messaging load.

You forgot to add the management aspect of push which could be a
significant barrier in large and/or complex networks. I think we have to be
able to pull and it is really the decision of the carrier architect.
Hopefully we can somehow allow both methods for flexibility. I know that is
not generally good for interoperability though.


_______________________________________________
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 Nov 30 16:03:17 2000
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 QAA15359
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 16:03:16 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C0D964442D; Thu, 30 Nov 2000 14:58:15 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 7F7AB44357
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 14:51:08 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28526;
	Thu, 30 Nov 2000 12:50:57 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA03426;
	Thu, 30 Nov 2000 12:50:54 -0800 (PST)
Received: from suntana (suntana [129.146.122.88])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA01914;
	Thu, 30 Nov 2000 12:50:52 -0800 (PST)
Message-Id: <200011302050.MAA01914@nasnfs.eng.sun.com>
From: James Kempf <James.Kempf@eng.sun.com>
Reply-To: James Kempf <James.Kempf@eng.sun.com>
Subject: RE: [IPTEL] TRIP for gateways
To: Brian.Rosen@marconi.com, matt@ipverse.com
Cc: James.Kempf@eng.sun.com, jdrosen@dynamicsoft.com,
        iptel@lists.bell-labs.com, erik.guttman@germany.sun.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 5EwyUWVXXigAwZl74OwpLw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc 
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 12:50:25 -0800 (PST)

Hi Matt,


>All of Jonathan's reasons for push are quite valid. But in large complex 
>networks when you push, the pusher doesn't always know about all the 
>roadbumps and policy variations in the field. Indeed when ISP's started 
>using BGP they went through hell dealing with these issues. Some still do 
>today. And some prefer to have manual control of the process which is 
>essentially the same as pulling.
>

Interesting.

>I'm sure if we think about it we can advocate the push method while 
>allowing for some to pull in the information. But I don't know what bearing 
>this has on SLP which is what we were originally talking about in this thread.
>

So then if a combination of push and pull looks like the best bet, the
question is whether SLP has what's needed (perhaps with a separate protocol
or the notification  extension for push) or whether a custom protocol is 
necessary.

		jak



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Nov 30 16:23:22 2000
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 QAA22436
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 16:23:19 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EA47544439; Thu, 30 Nov 2000 15:23:03 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by lists.bell-labs.com (Postfix) with ESMTP id B0D9F44438
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 15:22:37 -0500 (EST)
Received: from fokus.gmd.de (dhcp116 [195.37.78.244])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id WAA11348;
	Thu, 30 Nov 2000 22:22:20 +0100 (MET)
Message-ID: <3A26C3C5.526FAC4D@fokus.gmd.de>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Organization: GMD Fokus
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
        Jonathan Lennox <lennox@orion.cs.columbia.edu>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
References: <B65B4F8437968F488A01A940B21982BF9AAD00@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [IPTEL] External References (was Re: CPLng)
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 22:16:53 +0100
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
[...]
> I'm not yet sure what problem is being solved. Lets get agreement on what we
> need this for, what fields we want to run checks against, whether the checks
> are against lists inside the script or externally referenced, the general
> model for how this works (i.e., can we use the lookup/location model of
> modification of an implicit global variable) and so on. 

Sorry for that.

Particularly, I've had spam protection in my mind. In this case, there is
some 3rd party, that collects address of well-known spammers and is trusted 
by author of a CPL script. Without the ability to refer to such an external
database, users have to download the database, generate a script out of
it and upload it to a CPL server. The resulting CPL scripts become 
pretty long and difficult to read. They may be easily out of sync.

So what I'd like to have is the ability to check caller's address against 
an external list in a CPL script.

Does this sound reasonable?

Jiri

P.S. Just in case, you do not want to trust what you see in From: field
     you may want to go for the authentication switching.

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Nov 30 16:38:03 2000
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 QAA28001
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 16:38:02 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E8F36443DB; Thu, 30 Nov 2000 15:38:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by lists.bell-labs.com (Postfix) with ESMTP id B7390443DB
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 15:37:08 -0500 (EST)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eAULbO611956
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 15:37:34 -0600 (CST)
Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tac12f25750329e2ccd@davir04nok.americas.nokia.com>;
 Thu, 30 Nov 2000 15:36:50 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <XMTKZ0QK>; Thu, 30 Nov 2000 15:36:50 -0600
Message-ID: <E39024226822D311BC880008C77318A1019C59FC@oteis01nok>
From: Cliff.Harris@nokia.com
To: kuthan@fokus.gmd.de
Cc: iptel@lists.bell-labs.com
Subject: RE: [IPTEL] External References (was Re: CPLng)
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 15:28:28 -0600

Jiri,

This antispam idea was discussed recently on the list. No conclusions, mind
you. Please take a look at the following:

http://lists.bell-labs.com/pipermail/iptel/2000q4/000388.html

http://lists.bell-labs.com/pipermail/iptel/2000q4/000393.html

http://lists.bell-labs.com/pipermail/iptel/2000q4/000397.html

http://lists.bell-labs.com/pipermail/iptel/2000q4/000398.html

> -----Original Message-----
> From: EXT Jiri Kuthan [mailto:kuthan@fokus.gmd.de]
> Sent: Thursday, November 30, 2000 4:17 PM
> To: Jonathan Rosenberg
> Cc: Henning G. Schulzrinne; Jonathan Lennox; 
> 'iptel@lists.bell-labs.com'
> Subject: [IPTEL] External References (was Re: CPLng)
> 
> 
> Jonathan Rosenberg wrote:
> [...]
> > I'm not yet sure what problem is being solved. Lets get 
> agreement on what we
> > need this for, what fields we want to run checks against, 
> whether the checks
> > are against lists inside the script or externally 
> referenced, the general
> > model for how this works (i.e., can we use the 
> lookup/location model of
> > modification of an implicit global variable) and so on. 
> 
> Sorry for that.
> 
> Particularly, I've had spam protection in my mind. In this 
> case, there is
> some 3rd party, that collects address of well-known spammers 
> and is trusted 
> by author of a CPL script. Without the ability to refer to 
> such an external
> database, users have to download the database, generate a 
> script out of
> it and upload it to a CPL server. The resulting CPL scripts become 
> pretty long and difficult to read. They may be easily out of sync.
> 
> So what I'd like to have is the ability to check caller's 
> address against 
> an external list in a CPL script.
> 
> Does this sound reasonable?
> 
> Jiri
> 
> P.S. Just in case, you do not want to trust what you see in 
> From: field
>      you may want to go for the authentication switching.
> 
> _______________________________________________
> 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 Nov 30 16:51:18 2000
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 QAA02747
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 16:51:18 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 58249443F7; Thu, 30 Nov 2000 15:50:02 -0500 (EST)
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 37E4A44357
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 15:49:26 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA06183;
	Thu, 30 Nov 2000 16:49:15 -0500 (EST)
Message-ID: <3A26CB5B.6CB61A07@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jiri Kuthan <kuthan@fokus.gmd.de>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Jonathan Lennox <lennox@orion.cs.columbia.edu>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
References: <B65B4F8437968F488A01A940B21982BF9AAD00@DYN-EXCH-001.dynamicsoft.com> <3A26C3C5.526FAC4D@fokus.gmd.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [IPTEL] Re: External References (was Re: CPLng)
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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 16:49:15 -0500
Content-Transfer-Encoding: 7bit

Jiri Kuthan wrote:
> 
> Jonathan Rosenberg wrote:
> [...]
> > I'm not yet sure what problem is being solved. Lets get agreement on what we
> > need this for, what fields we want to run checks against, whether the checks
> > are against lists inside the script or externally referenced, the general
> > model for how this works (i.e., can we use the lookup/location model of
> > modification of an implicit global variable) and so on.
> 
> Sorry for that.
> 
> Particularly, I've had spam protection in my mind. In this case, there is
> some 3rd party, that collects address of well-known spammers and is trusted
> by author of a CPL script. Without the ability to refer to such an external
> database, users have to download the database, generate a script out of
> it and upload it to a CPL server. The resulting CPL scripts become
> pretty long and difficult to read. They may be easily out of sync.
> 
> So what I'd like to have is the ability to check caller's address against
> an external list in a CPL script.
> 
> Does this sound reasonable?

If you're sending an HTTP request, you might as well forward the SIP
request to the spam-checking entity (the only difference is the trust
relationship: the company offering the spam-filter service may not want
you to have access to the list and you may not want to route all your
calls to the spam-filter company...) 

> 
> Jiri
> 
> P.S. Just in case, you do not want to trust what you see in From: field
>      you may want to go for the authentication switching.

In the absence of PKI, I have a hard time picturing most calls being
authenticated. There will be high-priority "friends & family" calls that
are authenticated, but there seems to be a vast gray area of non-spam,
first-time callers. Might be easiest to do "don't call me, I'll call
you", i.e., just returning the INVITE immediately to make sure the
caller is who he claims to be.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Nov 30 19:32:59 2000
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 TAA23021
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 19:32:59 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0652D443B4; Thu, 30 Nov 2000 18:33:03 -0500 (EST)
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 3685944357
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 18:32:31 -0500 (EST)
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA22167;
	Thu, 30 Nov 2000 16:32:28 -0800 (PST)
Received: from cisco.com (dhcp-128-107-142-56.cisco.com [128.107.142.56])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with ESMTP id ABG03469 (AUTH hsalama);
	Thu, 30 Nov 2000 16:32:19 -0800 (PST)
Message-ID: <3A26F0CC.E9D01E59@cisco.com>
From: "Hussein F. Salama" <hsalama@cisco.com>
Reply-To: hsalama@cisco.com
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (WinNT; U)
X-Accept-Language: en,arabic
MIME-Version: 1.0
To: James Kempf <James.Kempf@eng.sun.com>
Cc: Brian.Rosen@marconi.com, matt@ipverse.com, jdrosen@dynamicsoft.com,
        iptel@lists.bell-labs.com, erik.guttman@germany.sun.com
Subject: Re: [IPTEL] TRIP for gateways
References: <200011302050.MAA01914@nasnfs.eng.sun.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 16:29:00 -0800
Content-Transfer-Encoding: 7bit



James Kempf wrote:
> 
> Hi Matt,
> 
> >All of Jonathan's reasons for push are quite valid. But in large complex
> >networks when you push, the pusher doesn't always know about all the
> >roadbumps and policy variations in the field. Indeed when ISP's started
> >using BGP they went through hell dealing with these issues. Some still do
> >today. And some prefer to have manual control of the process which is
> >essentially the same as pulling.
> >
> 
> Interesting.
> 
> >I'm sure if we think about it we can advocate the push method while
> >allowing for some to pull in the information. But I don't know what bearing
> >this has on SLP which is what we were originally talking about in this thread.
> >
> 
> So then if a combination of push and pull looks like the best bet, the
> question is whether SLP has what's needed (perhaps with a separate protocol
> or the notification  extension for push) or whether a custom protocol is
> necessary.

If the information is already being pushed in the background, what's the
need for an additional pull mechanism? I am assuming that all
information will be pushed. If not, what type of information should be
pushed and what type should  be pulled?

Hussein



> 
>                 jak
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel

-- 
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  Thu Nov 30 19:50:58 2000
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 TAA29052
	for <iptel-archive@odin.ietf.org>; Thu, 30 Nov 2000 19:50:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4BEDA44429; Thu, 30 Nov 2000 18:51:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 588B844357
	for <iptel@lists.bell-labs.com>; Thu, 30 Nov 2000 18:50:03 -0500 (EST)
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA17285;
	Thu, 30 Nov 2000 16:49:54 -0800 (PST)
Received: from cisco.com (dhcp-128-107-142-56.cisco.com [128.107.142.56])
	by mira-sjcm-2.cisco.com (Mirapoint)
	with ESMTP id ABG03657 (AUTH hsalama);
	Thu, 30 Nov 2000 16:49:52 -0800 (PST)
Message-ID: <3A26F4E9.A411D32E@cisco.com>
From: "Hussein F. Salama" <hsalama@cisco.com>
Reply-To: hsalama@cisco.com
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD   (WinNT; U)
X-Accept-Language: en,arabic
MIME-Version: 1.0
To: James Kempf <James.Kempf@eng.sun.com>
Cc: jdrosen@dynamicsoft.com, iptel@lists.bell-labs.com,
        erik.guttman@germany.sun.com
Subject: Re: [IPTEL] TRIP for gateways
References: <200011301909.LAA29032@nasnfs.eng.sun.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: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 30 Nov 2000 16:46:33 -0800
Content-Transfer-Encoding: 7bit



James Kempf wrote:
> 
> Jonathan,
> 
> 
> >>
> >> I'm curious why you need to have the gateway push the
> >> reachability info
> >> to the location server. Why can't the location server pull it from the
> >> gateway?
> >>
> >> In this scenario, the location server acts as a user agent and the
> >> gateway acts as the service agent. The service advertisement consists
> >> of the PSTN gateway's attributes and reachability info (as I
> >> understand
> >> it from below, telephone prefixes). The location server periodically
> >> performs an SLP SrvRqst for gateway service URLs, then performs an
> >> SLP AttrRqst for the attributes. Alternatively, the location server
> >> can include the SLP attribute list extension (see
> >> draft-guttman-svrloc-attrlist-ext-04.txt) to have the attributes
> >> delivered along with the service URL.
> >
> >Indeed, the fundamental question is push vs. pull.
> >
> >I think gateway routing needs to be push primarily for performance reasons.
> >Calls arrive at a proxy server at potentially very high rates; if each call
> >needs to generate an independent query for service, you end up (1) adding
> >latency to each call setup for the query/response, (2) introducing a serious
> >processing burden for all devices, (3) add a lot of network traffic for the
> >queries and responses. By pushing the information as it changes, we
> >eliminate the additional call setup latency, reduce the processing load, and
> >reduce the messaging load.
> >
> 
> In a pull model, I don't think that each call needs to necessarily cause
> an independent query for services.
> 
> If each service advertisment contains a lease or timeout, then the
> proxy server only needs to redo its query when the advertisement expires.
> The granularity will determine what the messaging load and processing
> load is, and needs to be set so that it reflects a realistic apprasial
> of how often the external reachability information will change.
> 
> Of course the probability of getting stale information is higher with a pull
> model if the lifetimes are set too long,  so the tendency in situations where
> the service information changes dynamically is to decrease the lifetime, upping
> the processing load.
> 
> If what you are trying to do is distribute routing information, then
> something like a routing protocol that does push seems like it might
> be the better approach, since any failure of freshness pretty much
> invalidates the information. However, if what you are trying to
> do is locate suitable gateway servers based on where they
> can get you to, 

We're not just trying to locate the suitable egress gateway. We're also
trying to determine the best route to get to that gateway. This route
may consist of multiple signaling proxies.

Hussein


> then perhaps a service discovery approach based on pull  seems
> like it would be more appropriate if the gateway servers' reachability service
> doesn't change often.
> 
>                 jak
> 
> PS: Incidently, we have been working on a push protocol for SLP, to
> allow a service client to subscribe to notifications of changes
> in particular services. We are slowly moving the draft to Experimental.
> The specification is in draft-kempf-srvloc-notify-04.txt. The design
> pays particular attention to scalability issues, since we wanted
> to avoid problems with network overload such as occured with
> Netware 4.0 SAP and at least one implementation of SLPv1 that was not
> in compliance with RFC 2165.
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel

-- 
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