Last Modified: 2004-11-02
| Done | Submit gateway location framework document to IESG for consideration as an RFC. | |
| Done | Submit call processing syntax framework document to IESG for consideration as an RFC. | |
| Done | Submit call processing syntax document to IESG for consideration as a Proposed Standard. | |
| Done | Submit gateway location protocol document to IESG for consideration as an RFC. | |
| Done | TRIP MIB Document submitted to IESG for consideration as proposed standard | |
| Jun 03 | Gateway to Server Route Exchange document submitted to IESG for consideration as proposed standard. | |
| Jul 03 | Tel URI revisions submitted to IESG | |
| Sep 03 | Number portability extensions submitted to IESG for consideration as proposed standard | |
| Nov 03 | Consider closing |
| RFC | Status | Title |
|---|---|---|
| RFC2824 | I | Call Processing Language Framework and Requirements |
| RFC2871 | I | A Framework for a Gateway Location Protocol |
| RFC3219 | PS | Telephony Routing over IP (TRIP) |
| RFC3872 | Standard | Management Information Base for Telephony Routing over IP (TRIP) |
| RFC3880 | Standard | CPL: A Language for User Control of Internet Telephony Services |
|
IPTEL
IETF-61 TUESDAY, November 9, 2004, 1300-1400 ==================================== CHAIRS: Jonathan Rosenberg <jdrosen@cisco.com> Cullen Jennings <fluffy@cisco.com> Note-taker - Spencer Dawkins <spencer@mcsr-labs.org> Status Update: Since last meeting we have published TRIP MIB and CPL. 2806bis was published shortly after the meeting. Enum dip indicator: Richard Stastny presented draft-stastny-iptel-tel-enumdi. This would add a flag that indicated that the ENUM dip had been done and did not need to be repeated. General consensus in room was to accept this work. Some discussion about if there should be a way to indicate that dips had been done to different roots. Eventually decided that there are no current documents specifying ENUM for multiple roots and we would not do this. draft-ietf-iptel-tel-np-02.txt Revision is coming and it will be WGLC and hopefully finished. Volunteers agreed to review. Some interested in implementing this. draft-ietf-iptel-trunk-group-02.txt Volunteers agreed to review. Need to WGLC. Some interested in implementing this. Dial string draft: will go forward as individual submission Calling party category draft: This has expired with very little response to comments. There is substantial work left to finish this. One or two people in room thought they might implement it. Not clear what the key uses of it are. Will discuss on list if we want to move forward with this (as a WG item) or not. It could always be done as individual. More detailed notes follow: * TRIP MIB, CPL published as RFCs since last meeting of IPTel * rfc2096bis in RFC editor queue 20 min Enum Indicator Richard Stastny - draft-stastny-iptel-tel-enumdi-00.txt * Also heads-uped in ENUM * Add "enumdi" to E.164 tel URI saying "we've already done an ENUM lookup, so you don't have to try again when you're resolving the URI" * "MUST NOT attempt e164.arpa resolution" requirement also discussed in ENUM * Who can add "enumdi?" - if you would do ENUM, you can add it, and an endpoint can add it to the original URI before anyone tries to resolve it * Cullen points out that this is not a mandatory parameter, so network elements that don't understand it will still attempt the lookup * <>This is good. Why limit it to e164.arpa? There will be other lightweight mechanisms, too. * <><>2806bis should probably also be a SHOULD - how consistent do we need to be?Makes sense, but do we need to say this in the current draft? * <><>If we allow this for multiple routes, we need to say what routes have been queried. Should we add a translation counter to help people realize a URI has been changed? How does transitive trust work? And please don't change semantics in a future rev - do it now, or don't do it. * Allow other roots in the first version, too - won't this slow the document down on the approval process? * If you know who did the lookup, you can decide whether to trust them based on that knowledge. * Leave it like is, or extend it (loop counter or something else)? Not a significant difference in sense of the room. We're trying to shut the working group down, so the authors will be guided by whatever the chairs ask for. * We don't actually have a spec that says you can legitimately query against another domain. Jonathan doesn't get it... no harm in redoing the lookup ("dip"). * Punt this question to the ENUM working group chair :-) - service providers would like to do something like this. Would like to continue as a working group document, would like to rev quickly and WGLC quickly. * Ignoring this is like ignoring NATs - don't put our heads in the sand. We'll block for six months to a year if we add alternative roots. * Accept as WG item with no changes - humm? Sense of room is "yes". [still needs to be confirmed on the list, right?] 30 min Plan for concluding work - Chairs Et.Al. draft-ietf-iptel-tel-np-02.txt draft-ietf-iptel-trunk-group-02.txt draft-ietf-iptel-tgrep-04.txt * Number portability draft revision is coming and addresses comments to date. * Volunteer reviewers were selected for NP and trunk group drafts. * Lite interest in implementing NP extensions and trunk group drafts. Will be immediately WGLCed. Reviewers, please report back during that timeframe. Dial string draft * will go forward as individual submission Calling party category draft * has expired, no responses to comments received * some concerns raised (trust boundaries, asserted identity) - not near done with this one. * We discussed making this a WG item many moons ago, and decided not to do it for pretty much the same reasons being raised now. * This work will take some time to get right. If the working group takes it on, we have to expect to come to consensus before we can close. * This work is useful, but maybe doesn't matter whether it's a WG item or not. * Who would implement? maybe one or two in the room * Not sure who needs this - what problem is being solved? duplicate parameters, endpoint identification - what? Maybe emergency services and coin phones, or something like that. Check with development groups and discuss this on the list in a couple of weeks after end of IETF. ENUM Dip? * We think we decided to do this at the beginning of the meeting. |