Subject: [IPTEL] minutes... better late than never

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 20 Apr 2001 10:10:33 -0400

Folks,

Unfortunately, I've been totally overloaded by some commitments and missed
the deadline for submitting minutes of IETF 50 for inclusion in the
proceedings. However, I'm sure the group would still like to see them. So,
they are enclosed here. I also have a complete transcript of the session,
thanks to the presence of a court stenographer in the meeting. Its a beefy
document (some 76 pages of double spaced text). So, instead of posting it,
I'm going to put it on the web page, along with slides. I'll send a note to
the list when they become available.

I owe an updated charter, which will be out in the not too distant future.
Hussein has just submitted an updated TRIP spec, based on our discussions
during IETF. Once it appears, I will submit it to IESG.

Thanks,
Jonathan R.

IPTEL WG
========

CHAIR: Jonathan Rosenberg <[email-masked]>

Minutes were taken by Joerg Ott. Edited by Jonathan Rosenberg.

AGENDA:

 1. Agenda Bashing [Rosenberg] - 5 mins
 2. CPL Status and Update [Rosenberg] - 5 mins
 3. TRIP Open Issue [Rosenberg] - 10 mins
 4. Transit Network Selection [Walker] - 10 mins
 5. TRIP MIB Update and Issues  [Walker] - 10 mins
 6. Service Codes [Peterson] - 10 mins
 7. New Charter discussion [Rosenberg] - 30 mins

CPL Update
----------
- CPL submitted to IESG in November 2000
- end of Dec: IESG reports back concerns
  - using a subset of iCalendar can lead to interop problems
    - CPL -> tools works
    - tools -> CPL does not
  - If iCalendar is too big to be implemented, it must be fixed
    in calsch for all

- calsch group not aware of CPL efforts
- calsch chair, Patricia Egen, agreeds to look at spec
- discussion took off (on calsch list)
  - syntax: a few concerns of not using the sntax
    -> not considered that big a deal
  - only one commendator on use of subset - John Stracke -
    agrees that iCalendar is too large
    - UI can't represent all of ical
    - computing and memory requirements are an issue
    - agrees to write up subset definition
- subset written by John S. and Jonathan Lennox
- to be discussed this Wednesday

- Proposal
  - agree to the proposed ical subset
  - re-write CPL spec to reference subset document
  - CPL and subset doc go to RFC simultaneously

TRIP Open Issue (Jonathan)
-------------------------
- WG last call ages ago
- comments came up only slowly
- shall be drawn to conclusion quickly
- comment this meeting or this week and then be silent

Issue #1:
- intra-domain topology updates really only need ITADTopology attribute
  However, spec mandates WirhdrawnRoutes, ReachableRoutes, and other
  as mandatory for all messages. These will all be zero length, which is 
  pointless.
- Proposal
  - define new message for intradomain topology updates (1)
  - remove requirement for all attributes to be present (2)

- Jonathan proposal on the list: remove requirement (2)

Comment: text must say that there needs to be "at least one these elements"

-> consensus: go with (2), modify according to comments

Issue #2: Address families
- decimal
- penta-decimal

E.164 is decimal but can be anything
- what if it is defined as part of a peering agreeemnt?

concern: in practice, handling anything but E.164 is hard

What to do:
a: define an E.164 address family
b: don't define it

Proposal:
- keep things explicit
- define an E.164 address family

Q: w/ this, do we still beed decimal and penta-decimal

-> YES

CONSENSUS also on this one

Transit network selectionm (Dave Walker)
----------------------------------------
draft-walker-iptel-trip-tns-01.txt

- PSTN allows for multiple routes to a destination
  (e.g. different carriers)
- TNS code indicates preferred carriers (Carried identification code)
- users may pre-subscribe or dial carrier access code
- national identification plans
  - ANSI ISUP
- networks respect TNS except for local ermination

IPTEL solution
- users may access both IP and PSTN based carriers
  - for IP-based carriers, set the URI accorndingly
  - for PSTN-based carriers, IP network must route the call to the
    right network
- need to distribute "best" route to the specified TN through TRIP
- exactly the same problem as TRIP solves for dialled numbers

This generated a lively discussion. Dave Oran had a concern about
using a routing protocool do distribute routes to intermediate
carriers. The equivalent would be BGP distributing routes to AS
instead of IP addresses. The answer was that as far as the IP network
is concerned, these carriers are not intermediaries, but end points
(gateways to that carrier). Some argued that Dave's point implied that
this was an attribute. Jon Peterson argued for an address family. One
issue is whether a carrier can terminate calls to any number. If not,
then we need to propagate carrier information and the routes they can
reach. It was pointed out that in the US, it is mandatory for a
carrier to route to any number. The problem, though, with using TNS as
a route attribute is that you don't want the route with the longest
prefix; you want to use the route which matches the carrier requested
for the call. It was agreed to spawn this to the list. It will not go
into the TRIP spec.

TRIP MIB (Dave Walker)
----------------------
- update -04 draft
- initial support for authentication

- aplIndex from network services MIB
  - is it needed?
-> proposal from Jonathan: YES

- require generic mechanism for handling?
  - new attributes
  - new address families
  - new protocol families
- security (suport for authentication draft)
- compliance statements (to do)

DW feels that this is very stable.  Please, folks, take a closer look at
it from your side before we go to last call.

Using Service Codes in SIP (Jon Peterson)
-----------------------------------------
draft-jfp-service-codes-00

investigation on what is necessary in TRIP for service routing
experimental work to show requirements

Overview of service codes:
- proposal for attributes associated with propageted routes in TRIP
  which characterize the service offered by the originator of the route
Why use service codes in TRIP?
- feature interaction among network applications

Basic TRIP service codes
- update (adds service code attr; e.g. LNP)

real strength if TRIP and VoIP protocol interact
- definition of a service code field for the Request URI
  sip:[email-masked];sc=x
- concept of a feature proxy at which services for a particular route
  are composed

Feature proxy: conventional 2543 proxy
- acts as outbound server
- acts as location server/registrar
- supports service codes

Henning was concerned about an approach with enumerates application
names. Sounds like what telcos do today. Dave Oran was concerned that
this would require running arbitrary application programs on a proxy -
active networks. Do we want to go there? Henning argued that CPL
should be used instead; CPL would direct this feature proxy to send
calls wherever you want. Otherwise, voice mail may be code 17 with one
provider, 25 with another; may have to update your CPL repeatedly. He
argued that services are location independent; what we are doing here
is re-inventing SLP on a global scale. Dave pointed out that we may be
tripping  over the meaning of the word "service".

It was clear that there was a lot of difference of opinion about what
was being presented, and what the value was.

New Charter Discussion (JR)
---------------------------
New charter was sent to the list

1. TRIP MIB (proposed)
2. TEIP operational guidelines (BCP)
3. GW registrrations  (proposed)
4. (informational)

Not on the charter:
- CPL
- Draft version of TRIP
  -> need much more experience first

TRIP MIB
---------
- proposed completion: Dec 01
- based on current TRIP MIB doc

TRIP ops BCP
------------
- most complexities are in usage and policies
- proposed completion: Feb 02

GW Registration
---------------
- draft-rs-trip-gw-01
- proposed completion: Sep 01

VoIP Routing Framework
----------------------
- inter-domain
- intra-domain
- gw registers
- servcie routing

good to document these problems and their requirements
- draft future work on service routing and intra-domain route exchange

starting points: service codes and gw registration as strating points
- completion Sep 01

Other proposals:

tel: URL
--------
- bring to draft standards
- freeephone and LNP extensions
- trunk group ids
- basically -- SS7 extensions

TRIP authentication attribute document
---------------------------------------

- huge problem here; is this needed at all?
- look for a real need first!

Discussion points:
- are these real problems to solve?
- are there people willing to work on?
  - commitment to write text!
- shutting down is a *very* acceptable result!

Hennings point was that the TRIP MIB is harmless. The tel URL work
needs to be done, since its broken. However, he felt that the other
work was not yet working group material, since it was a little
premature. Jonathan agreed that there are implementations of TRIP; but
there is not yet real deployment.

Dave Oran felt that we need to do the MIB, and we want the gateway
registration thing. The service routing work and operational
guidelines are to premature. No opinion on the tel URL.

Jon Peterson argued that we should do gateway registration and the tel
URL.

Scott Bradner said that there shouldn't be operational guidelines at
this point. Gateway registration work is OK, but he is was not clear
on why the tel URL work should be here. Service routing was too
premature. MIB should get done. 

There was some discussion on the tel URL. Scott suggested that a
design team, outside of any working group, work on fixing up
rfc2806. Henning expressed interest in leading that activity.

Given this input, Jonathan made the following proposal for
rechartering: 

- GW registration
- TRIP MIB

Now the call for volunteers. We need enough to be able to work on
these. We had sufficient people to work on both items.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel