IPTEL WG - Notes - IETF 55

iptel meeting minutes from the 55th IETF
Tuesday, November 19, 2002
1700-1800 Salon I

Chairs:
J. Rosenberg <jdrosen@dynamicsoft.com>
C. Jennings <fluffy@cisco.com>

Agenda 

-status
-tgrep issues
-2806 bis issues
-tg issues
-cpc / oli issues

no amendments/comments ; agenda approved 

Status:

-management changes
cullen jennings new co chair
rosenberg doing lousy job :)
more work (uri) coming
iesg has asked us to take on tel uri, and in doing so complete three drafts
there is a new mailing list - subscriptions to the old list have not been automatically migrated

existing work items:

-trip mib
expert review conducted
revised version of draft produced addressing comments
more comments since revision from list
one more rev of this draft expected to address these
official iesg last call after all of this
wglc already completed

-tgrep
new version of the draft has been submitted
sorely needs expert review
lack of participation in wg to look over provide detailed comments
solves an important problem: preregister for a block of dn's
jonathan-i'm always having to tell people on the mailing list why you can't just (ab)use register

new work items:

all tel url items, and:
tel url: draft-yu-tel-url-06
2806 bis: draft-antti-rfc2806bis-06
h323 url scheme: draft-levin-iptel-h323-url-scheme-04
when there is consensus on which items will be delivered, cullen and jonathan (chairs) will update the charter

-tgrep issues presentation-
dhaval n shah-

-updates
tgrep is an auxiliary protocol, no longer a subset of trip - this has changed
support for carrier and trunkgroup attributes, address families added
multiple address family handling support is included, but currently only one at a time is required
updated route consolidation section
country codes have been added to the cic 

-open issues
thresholding scheme- leave in, or put in more details?

*cullen-this might be an implementation issue
jonathan-proposed a bcp item in the past, but scott pointed out that we don't have enough field experience

trunk group length-set at 128 bytes, derived from itu 

*jonathan-is this big enough?
jon peterson-30 bytes should be enough

should carrier code be binary or ascii? (currently favoring binary)

*somebody-ascii will do
jon peterson-agree
*jonathan-please provide comments. otherwise we will have to assign reviewers
jon-i can publish the notes I have been giving to dhaval privately, but I am otherwise out of issues

-2806bis: tel uri presentation-
henning schulzrinne-

this has undergone a significant number of changes

-status
changes:
narrow the scope of the uri significantly
uri comparisons should be case insensitive, but use lower case parameters
bnf cleanup remove order dependence
specify preferred ordering

may need ed cleanup
otherwise ready for wglc

-open issue:context
two approaches: dns and tel no prefix space
1.dns tel:7042;phone=context=context=cs.clumbia.edu
2.prefix: choose lowest number in range, or smallest prefix
3. should a prefix list be supported, of the form: phone=context=+31,+49
this is sometimes needed because there are cases where freephone can span country codes now 

*jon-there are 800's domestically that are scoped to bell operating companies / latas, etc.
henning-don't think it is realistic to generalize uri to accommodate this
jon-been uncomfortable with the idea of context, but pstn doesn't have this. e.g. phone number on found piece of paper has no context, and may not work if you were to arbitrarily use it at a terminal, etc.
*henning-number ranges can't be easily conveyed / correctly implied by prefixes;i.e. range of DN's
*jon-there should be a way to describe the private dialing plan
*lawrence conroy-understand jon's concern. went through this in pint. dns is the 'least bad' choice. there is the potential for confusion with private number plans. ibm internal vs ibm external, etc. 
*jonathan-I ask myself: does this problem exist elsewhere? yes, i.e. 1918 address used in an http url, that are is in an email to another domain. the practical solution for this case has been that you only find / use a url in the context it is valid. Otherwise, as an endpoint, I have to be configured with what my scope is, and that is a fair configuration burden.
*henning-could we take a more radical step that says we can't use local scopes?
jonathan-no. just don't send urls out of scope.
dave oran-agree with everything that jonathan said, except about the complexity of configuration. e.g. everybody has speed dials that have context. punt on this problem. 
*henning-context would prevent much of the silliness that happens today. there used to be a tv: url, channel scopes were the issue there. my take is first do no harm, but more info is better than no info
*lawrence conroy-there is a change here. in the original 2806, it says if you don't know if you are in this context, then don't use the url. 
henning-this is simply an issue of the default behavior
lawrence conroy-if you actually ring the wrong number, this is a problem in some locales. also, i see value in the prefix context, but not others, in general.
*jonathan-this is not a tel url-specific problem. this feels to me like a bigger url issue for somebody else to solve. this draft is devoid of semantics on uri processing. 
dave oran-semantics are: you cant put an @ in it
jonathan-need more discussion
henning-tel url is more like a urn, should be treated as such
somebody-seems like a fairly useful feature. 

-open issue:global numbers
are of the form: +cc-xxxxx
these require no context
freephone numbers are perceived as global, but are local. however, this may change in the future, may not need to undertake special handling

-draft progression
planned for draft standard
where do we go from here?
one idea: trim down so there is a reasonable chance of getting this implemented
need an interop matrix of some sort
would appreciate it if folks using the url would contact me

l conroy-jonathan pointed out that semantics are needed. can think of three scenarios where this might be used...
should not go to draft standard since it is a radical change in the expected behavior of clients; this breaks private clients; it breaks 2806 compliant implementations
jonathan-can anyone verify that in order to pursue draft standard, all normatives have to be at that level?
somebody-yes
jonathan-well what about RFC2396 (URI generic syntax)? this is not draft standard. I will speak with ad's as to what their position is on moving this work forward 
l conroy-i am aware of at least one existing implementation that would break with the 2806bis mods, although it is an internal subsystem
jonathan- there is no formal requirement that this has to be backwards compatible. that is up to us to decide.
henning-don't want to spend more years iterating this. want to make sure that our gating conditions are met first, as to assure quick passage

-we will have to bump cpc stuff, because we are behind on time. take this to the list. will ask for more time at the next IETF session

-trunk group open issues presentation-
vijay gurbani-

-motivation for this work
if you have proxy and multiple gateways, you need to indicate what trunk group you want the call to go out on
also true in reverse

-issue 1
should trunk group indication be carried in tel uri? (vs sip uri) 
right now it is in tel uri

-issue 2
global or local namespaces?
most trunk groups are locally scoped. 

*somebody-left it as a local issue for coordination in tgrep 
*henning-having double equals is not a good idea
vijay-not the first place this has been done...
rohan-double equal is currently legal, also, in interop, found a number of other thing that although 

-issue 3
originating and terminating trunk group should be able to appear separately but concurrently in sip uri
for the originating case could use contact header (but this is the address of record)
for terminating / destination use request uri

*jonathan-there are no semantics for tel url, but you are specing that for sip
jon-some amount is desirable
jonathan-semantics are clear / implicit. if the semantics are well defined enough, you don't need to do anything special to make it work for sip
dave oran-you are underestimating the perversity of the implementers

-issue4
sip uri should be able to specify outbound trunk groups

Items:

-do we want to have a draft to extend the tel url to include trunk group? need to decide
-richard shockey requested that enum work this be punted to iptel 
-gwloc-slp draft
this was trying to solve a different problem than trip/tgrep so it was allowed to continue
will still proceed as an individual work, if its scope has not changed

Open Mic:

won't try to take hums here.

*jon-i submitted the tel cpc draft for discussion only... don't think it should necessarily be a chartered item 
*l conroy- tel url may have a local number, but enum may not.
*brit-h323 version 05 is a pressing issue
jonathan-this was in rfc editor's queue but pulled back. this should be one of the first things that should be complete
brit-this was submitted to all of the relevant mailing lists 2 weeks ago <frustration>
*dave-one option for this wg is to declare victory and have wg go to sleep... not take action and go to sleep. 
rohan-could take a hum for mib, then send everything to transport area. i don't think that is a good idea
dave-no, some just go to sleep
jonathan-iesg asked us to do three things, we should do those.
*rohan-i'm cool with making h323 an item, but is this entangled with annex o
jonathan-this is only an issue if changes or updates will be disallowed
brit-annex o still waits for tel url
jonathan-is it possible to feedback changes to itu?
brit-only if there are faults in draft
jonathan-we have to discuss this with ad's et al.  
brit-why can't we do a hum? <frustration>
jonathan-iesg told us to take this on, presumably not just hand it back again
*shockey?-why not just go to wglc. lots of these things have been in review for a long time

thank you. sign the blue sheets, send in your ietf membership dues, etc.