Subject: [Iptel] FW: IPTEL Minutes - IETF 61

From: Cullen Jennings <[email-masked]>
Date: Thu, 09 Dec 2004 13:38:48 -0800

------ Forwarded Message
From: Cullen Jennings <[email-masked]>
Date: Thu, 09 Dec 2004 12:46:42 -0800
To: <[email-masked]>
Cc: Jonathan Rosenberg <[email-masked]>, Cullen Jennings
<[email-masked]>
Subject: IPTEL Minutes  - IETF 61

 TUESDAY, November 9, 2004, 1300-1400
====================================

CHAIRS: Jonathan Rosenberg <[email-masked]>
Cullen Jennings <[email-masked]>
Note-taker - Spencer Dawkins <[email-masked]>

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.

------ End of Forwarded Message

_______________________________________________
Iptel mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iptel