SIPPING - IETF 68

Chairs: Gonzalo Camarillo, and Mary Barnes

Secretary: Oscar Novo

MONDAY, March 19, 2007, 0900-1130, Congress II

Time	Length	Discussion Leader	Topic	Relevant Documents
0900 - 0915	15 minutes	Chairs	Status and Agenda Bash	Henning - could we have a template timeline for WGLC, forward for publication, etc? Jonathan - GRUU will have changes for REG-EVENT Jonathan - are we waiting for more comments? Mary - expectation is that reviewers need to confirm that revisions address review comments. Francois - when do you want review comments back? Mary - last week, of course. (document title for SBC doe is wrong on slides) Looking for volunteer reviewers for v6 tortute tests, CC framework - don't have any, so can't go anywhere. Henry on lightweight SIP - assumes that all applications reside in endpoints - both CS and P2P environments, so no network services. Looking for a home for this work - please review and discuss in SIPPING.
0915 - 1000	45 minutes	Sumanth Channabasappa	Configuration Framework	draft-ietf-sipping-config-framework-11.txt Result of IETF 67 breakout and design team. Did two revisions since IETF 67. Specifies a new event package and profile life cycle, plus three profiles. Does not specify any data models. Goal was to simplify structure and technical changes from 09 draft. Draft 10 focused on restructuring. About 30 people read draft 11. Draft 11 simplified lifecycle, included AOR in "From" firled, added device -id and revised security and terminology, plus editorial changes. Questions for the working group... Does layout expect expectations? Henning - would like executive summary/example. Draft is 60 pages long, indication that we can remove stuff. Will send suggestions. Even though document reuses context, it creates new terminology (enrollment is just subscription, isn't it?). Scanning for this would reduce complexity - refer to things that we already understand. Rohan - enrollment isn't quite the same as subscription. Can someone explain this more concisely? please send text! Henning - then please highlight important differences. Dan Petrie - Not modifying 3265 - need to be clear about this. Then there should be a subscription, followed by something else. Francois - can make this clearer. to use underscores or not? Henning - overloading DNS conventions is not a good idea. We had a long-ago discussion about specific hostname conventions for specific services and didn't go there. Concerned that this is the bigger discussion - what mechanisms should we be using? Could be using NAPTR or SRV - this really is a service, not just a UA. Cullen - I brought this up, we just need to ask DNS people, we don't have the expertise to decide here. Device-ID Can we rely on the contact header alone? Henning - seems to be overlap with user agent parameter - why not reuse that? Rohan - was proposed around version 06 or 07, we thought this was about debugging using free-form text. Cullen - why do you need to put the same number in two places in the same message? Of course we need a device ID, but do we need it twice? It's in the contact and in the event header. >From header has user AOR. Cullen - should be instance ID in contact header for device ID - we have a lot of text that already describes confidentiality, "what happens if they're different", etc. Dan - for device profile has to be request URI. Cullen - not sure I care about request URI. Rohan - in device profile or user profile (garbled here) OK with removing device ID for local network profile? Rohan - seems safe but should check this out more carefully. But could be fetching from several hops away, could be lost. Cullen as individual - don't agree with Rohan at all. this is rediculous. What happens with instance ID when it goes through B2BUA? Rohan - trying to fetch specific resource, identified by URI, name should be in that resource. Saying we should fetch a resource by some other name relying on a header that might not be present is silly. Fallback to HTTP? This has been questioned on reflector. Do we need this? Cullen - is it OK that you no longer have a subscription model, so you never get a notification again? Draft doesn't have a poll mechanism. Henning - HTTP expiration would give you a poll mechanism. Concerned that 60 page spec won't be completely implemented, and people will just use HTTP (what they do in proprietary ways today). Jonathan - agree with Henning, 99 percent won't implement. Most stuff today doesn't even update configurations, most of the rest polls periodically. Call out expiration/poll. Francois - this isn't fallback, it's what people do today. Recognise this, and the problems, and describe this as common practice, but explain why more capability is good. Don't remove this, otherwise just use HTTP with no thought. Rohan - complexity of this draft is in specification. Implementation is much more straightforward. This shows this is a problem. We've been yanking chains back and forth and never deciding what to do. We switch back and forth, that's why the document is big and complicated. We incorporated more and more stuff. Rohan - yes, most people are using HTTP. This unifies the way people use HTTP and gives people notifications. Dan - are we talking about the wrong term? This is bootstrapping in HTTP, not fallback. Henning - but this means that people can only implement HTTP and not feel too bad about it. Should recognize that this is a first-class citizen, if this is what people are going to do anyway. Dan - there's no reason to implement this draft if you're going to just do HTTP. If you're not going to do a subscription, there's no reason to do this draft. Francois - draft does explain how to divide configuration into categories, etc. Notification isn't that complicated, although we don't explain it well. We need to publish this, people are giving up and keeping HTTP forever. Stop farting around and issue this draft soon. Jason Fisher - people are moving forward because we haven't issued this document. If you want people to implement it, send it out quickly. Keith Drage. - some of this is not a problem. Do we need the local network profile? Rohan - if you want to implement local policy you need this profile. Cullen - will be finished sooner if we leave this in. Henning - don't have a ready data framework model, so we all have different notions of what goes where, makes it hard to know all the possibilities, overlap, combinatorial failure... Volker - three models merge.
1000 - 1015	15 minutes	Volker Hilt	A User Agent Profile Data Set for Media Policy	draft-ietf-sipping-media-policy-dataset-03.txt Also update on policy framework and event package (no changes). Policy framework - if you accept policies, you must enforce them. Dataset - needed clear separation of session info and session policy. Added rules for mapping between SDP and session info documents. Some changes to XML elements and attributes, simplfied XML format. Session info and session policy have same format but are used with different semantics - use same document elements with different document root elements.Do people agree? We still need more feedback. Henning have own subscription policy and local policy - are these the same? Local policy is essentially session policy. Inheriting from UA dataset, but it's not a WG item. Henning - really worred about complexity - don't think this will be implemented, much less correctly. Merging and failures really are complex, we're over-engineering. These drafts have been reviewed but not through WGLC yet. Gonzalo - what is best way to finish both drafts? Don't want to have the problem Henning identified. Dan - requirement for merging has impact on what you want to be able to describe. Don't think this makes the data schema more complicated. Requirements with very little impact. Gonzalo - have merging discussions explicitly on the list. Need to resolve dependency, clean up schema definition.
1015 - 1030	15 minutes	Jonathan Rosenberg	Overload Design Team Status Update	draft-ietf-sipping-overload-reqs-00.txt Had requirements and some proposed mechanisms - need a coordinated design team to make progress. Complicated thinking needed to focus on simulation work. Design team formed in Jan 2007, many participants aren't IETF people, but have telecom congestion background. Have agreed on simplified simulation model and are currently running simulations to demonstrate the problem with this model. Starting the bulk of the work. Want to narrow down to key proposals and run over more complex networks - want to make design team recommendation to WG by July IETF (Chicago). Mary - requirements document is already WG document, please look at it. Ideal that there is progress between IETFs. Robert - can you release intermediate results? Should be OK.
1030 - 1115	45 minutes	Jonathan Rosenberg	Service Identification	draft-rosenberg-sipping-service-identification-01.txt Thread that has been going, and going ... Don't have many slides, have lots of time for discussion. Want to get out of this rathole. Need to do something. Not about adressing the problem - 3GPP is going to do something in this space, do we have any guidance for them? Need to understand what we're talking about. Andrew Allen's examples were most helpful. Chess was silly. Push-to-talk has come up before. Multiplayer game with voice and MSRP - both use same media but may be prioritized differently, include different features, different billing... IM versus software updates - both use MESSAGE, but are "different" - different dispatch in the phone, different billing. Rohan - don't think we should be glorifying IM/software updates with discussion here - this is not good. IPTV versus videoconferencing - both audio and video, both same codecs, maybe even both unidirectional. But might want different dispatch on the phone, different billing, different QoS. Don't care what a service definition IS, care how it's USED - key observation. Might invoke application servers in the network, based on information I'm not seeing in the SIP today. PoC supplementary services may be different. Need to know what software to dispatch. Include in accounting records for billing. Determine network QoS. Identify additional context at the application layer. Explicitly ASK the network to invoke application servers (recording server). Set of supported services that a caller could use. Who determines service ID? Client, network based on inspection of request, network based on ??? Why are people bothered so much by this? What happens when a regular SIP phone calls a SIP phone when a provider requires a tag? When two providers have different tags for the same service? when two providers have different services but overlap in some way? Even if the call still works, the user experience stinks. We don't do that at the IETF. Sometimes information is usually present, but not in corner cases (offerless INVITEs). Could fix the problem instead of inventing a new mechanism. Do what I mean, not do what I say. Proposal is to identify specific use cases where SIP message lacks information to provide service identifier (missing Require tag for PoC, etc) and invent a P-asserted-service-ID that is only defined within a trust domain, can always be determined in SIP mechanisms - still getting global interoperability. Eric Berger - can you tell me what target of PoC rquest URI is? Target is PoC application server. We're going against the SIP principle - not talking between peers, mangling in the network and "adding value". Jonathan - don't get wrapping around services in the network. People do that. Eric - thinking of transcoding - "pull in this server, and by the way, I'm calling Jonathan". Adam - suspect that proposal isn't going far enough. Problem coming from the terminal is that UA is sending something that's opaque, network may not do the right thing. You're going halfway down the path. No one is going to use this but you're still compromising your principles. Mary - is this in 3GPP 07 release? Andrew - it's frozen, but this is still open. We don't have something to work on by the end of this meeting, we'll have nothing to offer. Need to understand technical solution. Missing authorization based on subscription in your cases. Not sure if 3GPP needs both P-A-Service-ID and other stuff. Jonathan - we won't have a draft next week. Need to show progress. P-header isn't a ticket to randomness - needs expert review. Andrew - not clear whether compromise applies to everything I talked about. 3GPP had requirements, previous draft met them, not clear that this one does. Jonathan - if you want to say something, you need it signaled unambiguously. Andrew - in IMS, edge proxy is often in a different network. Jonathan - that's already totally broken. IMS didn't have to have agreement on services, now we're back where we started. The requirement isn't "we need a header that is called 'foo'". Andrew - have to work with what's in the 3GPP spec now. People who don't want the IETF solution will use this to oppose the work. Jonathan - 3GPP relationship has been one-way. It's gotten better, appropriate to escalate and say approach is broken and they need to rethink. In favor of appropriately worded liaison statement and escalation. Rohan - really like the rant. We can find ways to describe all these things. XCON has participation versus streaming concept. Uncomfortable with P-header. Still feel bad about RFC 3475 - gave 3GPP implicit permission to put the wrong URI in the customer URI. If I have two versions of me, I want the URI that addresses them are different. Jonathan - presence solves this, but I don't think relying on worldwide deployment is right. Rohan - think we can do this without presence. Need to at least try to work this out, this week. Jon - would like discussion to remain focused on whether we should take on the work in this group. If there is, we go forward. EKR (as individual) - agree with Adam. If we shouldn't do anything, pressure shouldn't change that. Don't offer compromise unless you're sure they'll accept it. Henry - how does this map to IAB document on Internet transparency? This is a DOS attack. Need to be very clear on the mapping. Jonathan - agree that we want to maintain interoperability. ??? - is there any way to make this more general? Jonathan - no. Need trust. Eric - like the proposal with a caveat. Beauty of SIP is feature interactions are bundled and work in mysterious ways when you start combining them. SIP bundles are small and easier to figure out. If there are 3 billion handsets that do sort-of SIP, we'll be irrelevent if we don't bring 3GPP into the fold. Henning - they want "features by reference" model. Can't do parameterized features with 3GPP approach - won't work with interactions. Is service URN out now? Jonathan - POC may not be a service URN, but this may still make sense for other services. Andrew - not a choice between doing this or not doing it, it's whether we have input or not. Agree with concerns from the list about people who can't communicate with mobile users. INVITEs being rejected unless they have the right tags will reduce interoperability. Roni - see value, not just for 3GPP. Not just a duck thing - different people made the duck. Jonathan - be clear - need to identify the gaps so that signalling is sufficient. We have interop problems even within my product teams. People use User-Agents, etc. We need to go through the semantics so we know what's required. Miguel - fine with P-A-service ID. This is what people are doing today. Three groups of people using feature tags to hold service identification. Jonathan - deep injustice to say this is just an informational tag. Look at everything people are going to do with it. Adam - what I'm hearing is that what 3GPP has asked for is wrong. If we think we can change that, take on the work. If they want an RFC number for their spec that we don't agree with, that's misguided. Fork has already happened - my phone asks me if I'm using IETF SIP or 3GPP SIP. Keith - that's an OMA thing, not an IETF thing. We need to be capturing some of these "don't do it this way with SIP" guidance. AC?? - how to handle support of IPTV versus non-support? Jonathan - signal what we do, not what it's called. Signalling umbrellas isn't the way to solve this problem.. We have a rich framework that allows you to say what you need to do in order to dispatch. Tags with hidden behaviors is not the way to do this. Dean - missing word is "capabilities". Need a better way to describe this. Mary - there is a problem to be solved here. Is there support for solving it? Rohan - if we can't get consensus on an approach, it doesn't matter whether we want to or not. Mary - defer the humm until Friday? No... Work on a solution to this problem in the working group? Almost exactly divided in the room when we hummed. Mary - 3GPP has a solution and they're on the road with it. We may be able to change their minds. Andrew - we're talking about handsets that can't communicate. Jonathan - not ready to give up on this yet. Escalate first. Rohan - three things we're trying to agree on. Standards-based way of expressing capabilities. P-header like the current draft. Prioritizing one or both of these. Mary - will defer the humm until Friday.
1115 - 1130	15 minutes	Chairs	SIPPING WG: How do we achieve WG deliverables? (if time allows)	We're 50-percent accurate on predicting milestones. Some are dependencies, lack of cycles from editors, newness of tracking in spreadsheets. Move late drafts to end of the queue? Mailing list has been supportive. May also ping editors more often, update spreadsheet bi-weekly, use tools to generate e-mails. Jonathan - pings help. Squeakiest wheel gets the oil. Andrew - generally a good idea, but use discretion. There are life events. Jonathan - if you're unavailable in your day job, you have backup. Maybe we should do this at the IETF. Mary - good idea. We've done this with config framework. We'll probably be grabbing people who want to bring new drafts in - they need to contribute to clearing the queue.

FRIDAY, March 23, 2007, 0900-1030, Congress II (the 1030-1130 slot will be used by the ECRIT WG)

Time	Length	Discussion Leader	Topic	Relevant Documents
0900 - 0905	5 minutes	Chairs	Status and Agenda Bash
		Cullen	Service Identifier	Want WG to take on some work here and help the situation. Key deliverables - informative document explaining what w'ere concerned about, P-header for storing analysis, and media feature take for subtypes. Jonathan has agreed to write the problem statement draft (quickly). Are we willing to work on this? P-header draft is almost finished. Spencer- right thing to do, right steps. humm - working group add a milestone for the problem statement document? ??? - problem is from generic perspective, or 3GPP? Cullen - general problem. Jonathan - why people try to do it, what they have tried, what are the problems that arise, this is generic when you split out the p-header. Not asking about second and third deliverables at this time. humm - informational document? strong consensus for, no humms against.
		Jonathan	ICE vs ANAT in MMUSIC	Has been a low-volume discussion in MMUSIC for two months, and then people woke up. Three options - ICE deprecates ANAT, ANAT is transition mechanism and you can do ICE, SDPCap deprecates ANAT and you can do ICE Third choice hasn't gotten a lot of traction on the list. Pros and cons (please see slides). ICE is good at selection, don't choose paths based on static prioritization. RFC 3484 - IPv6 has a LOT of addresses, so you really need to figure out priorities dynamically and ANAT doesn't. Could add this, but it's not in ANAT today. Cullen - would be surprised if IESG didn't require support for RFC 3484. Hadrian - can comply without doing it at all - it's optional. ICE doesn't use selection algorithm, either. Jonathan - but ICE probing and selection are separate. Could do 3484 if application wants to, or not. Hadrian - delection between link-local and global addresses Cullen - imagine you had two IPv4 interfaces on different networks - if you pick the wrong address, it won't work. ICE won't conflict with RFC 3484. Jonathan - ICE would figure this out without using ANAT. Gonzalo - MMUSIC thinks ANAT doesn't work in all cases, but works for active use cases. Francois - we don't have the expertise to figure this out, we're not IPv6 guys. Gonzalo - we've been talking to V6OPS. Jonathan - SIP transition document doesn't even mention media. This is a problem. Jean-Paul - Alain Durant has been focused on this. It's important to support 3484. I said this in my review of ICE-11. Need to send e-mail to get v6ops feedback, but this is absolutely required, can't ignore this. ICE provides you the information to do this calculation. Jonathan - ANAT doesn't say a word about 3484, need something added. Hadrian - people are focused on 3484, I don't understand how ICE works with it, either. Jonathan - added late, in ICE-12, was introspective selection, now "regular selection", added role to flag candidates to other side, etc. (seriously ratholing here - MMUSIC chairs finally ended the suffering. "You don't have a global view from any node on the Internet, and that changes everything" May not want to stick ICE into this forever, if NATs go away (dream on) Francois - what's the process here? Gonzalo - wasn't rushed in, has been discussed for a while on MMUSIC but none of us cared. Francois - don't want to screw this up worse... main issue is whether we need connectivity check always and whether we need it forever. Think we should do ICE now and optimize it out later (ICE-Lite, or something even lighter). Jonathan - ICE is entirely silent on this. Could delegate. Francois - don't go deep into this, you'll get in a huge argument. Be neutral in ICE document. Don't think we want to debate technical stuff today. Proposal is to deprecate ANAT, use ICE with mechanism that lets us remove ICE later if it's not needed. Jonathan - can spec this later, tight? MMUSIC will do transition mechanism in 20 years, when everyone has moved to IPv6 :-) ??? - if you deprecate ANAT, people may use proprietary mechanisms. Won't work if FW passes RTP but drops STUN - that's one scenarios, there are others. Jonathan - we haven't worried about application gateways, why start now? Jean-Francois - guidance on how ANAT and ICE interact is needed. In favor of deprecating ANAT and picking one mechanism. Hadrian - why does deprecating ANAT hold up ICE? If ICE doesn't get deployed, we won't have an alternative. Jonathan - then we'll make an alternative then. We do this all the time. MMUSIC chairs humm - ICE (transition mechanism) deprecates ANAT, or ICE is used with ANAT (transition mechanism) - sense of the room is rough consensus to deprecate ANAT. Gonzalo - MMUSIC affects us. If you care, subscribe to their list. SIPPING people need to be on MMUSIC.
0905 - 0920	15 minutes	Miguel A. Garcia-Martin	SIP File Directory	draft-garcia-sipping-resource-sharing-framework-01.txt draft-garcia-sipping-resource-event-package-01.txt draft-garcia-sipping-resource-desc-pidf-00.txt These drafts are about resource sharing - requirements for file transfer are done, mechanism draft is underway. Problem is that receiver doesn't know the description of a file on another device. Resource package would be end-to-end. Why not do this with presence? Could be added to pidf... Why are we using SIP at all? Because we bypass 95 percent of the pain Resource XML document describes resources Three documents - use cases, resource event package (with Nokia IPR), and PIDF. Henning - advertise mailing list for event notification, went to SIMPLE last night. Cullen - APPS is also interested, probably about five mailing lists in the last week.Will try to coordinate with APPS ADs. Henning - concerned about kind of things you can propogate - extending metadata doesn't make sense because things (printers) are different. Only pushes the problem up one level. Don't go there. Miguel - thinking about making this generic. Jason - MSRP instead of SIP? Running through proxies is a lot of overhead. Jonathan - this isn't evil, but it's close. File transfer is OK, but don't turn SIP into NFSv5 or something. Henning - problem is that we built a similar non-SIP system - NFS doesn't work when files change, have to poll if this isn't in presence. Paul - not sure if this is suitable for event notification at all. Who wants to report on changes to every file? Restricted set of stuff would make more sense. This is near a fine line. ??? - interested in these kinds of ideas. Dean - possible we might be talking about something similar to RSS, event package that sends you presence about RSS feeds? Cullen - discussing a bunch of APPS issues. Discuss how appropriate this is in SIP, and who we need to be talking to.
0920 - 0935	15 minutes	Daryl Malas	SIP End-to-End Performance Metrics	draft-malas-performance-metrics-06.txt About nine months on this draft so far. Industry need continues. Want to align with ITU-T (E.411 and E.721, and other standards that have been around for a while. People want to measure at UAC and UAS. Henning - does IANA want to be a dictionary? Daryl - haven't asked ::-) Haven't gotten a lot of feedback on some proposed metrics. Henning - inclination is that this is naturally extensible - start as small as possible? ?14 is borderline to too many. Having mechanisms that are roughly comparable to non-SIP is good. Alan - quickly agree. Who's the "we" that establishes the minimum set? You changed the averages, which shouldn't include failures, right? Keith - made a bunch of comments on BMWG documents that are also applicable here - look at two documents together with my comments. Length of message has a serious impact on performance. ??? - 14 metrics may be too many or two few. Can you move beyond Voice (presence, etc.). ??? - interaction between signaling and media is missing - "cutthrough delay". Did you consider? Daryl - yes, but don't have media with all SIP signaling. ??? - please add examples that show this interaction, this is where lots of complaints will happen. Lars - couple of TSV groups that are thinking about application-level metrics. Cullen - have given this draft the runaround, work is progressing anyway. Need to run a BOF or form some kind of group that can work on this and review it. Daryl - kind of frustrated, getting close to deep-sixing the draft at all. Cullen - want to gauge interest on this and capture interested parties.
0935 - 0950	15 minutes	Denis Alexeitsev	Extensions to SIP for the support of the Call Completion Services for ETSI	draft-poetzl-sipping-call-completion-02.txt Two solutions proposed - SIP event framework and BFCP protocol. Hoping to pick one today. New event package, for queue management, P-header, and ??? Jonathan - gotta write the draft on service identification issues. TISPAN thinks BFCP is too complex for the benefits. Coordination between SIP and BFCP media paths is most of the problem. Proposal - agree on SIP event package as preferred solution. John Elwell - Focus on the one big solition. Paul - the way the event package works is still on the table, right? Jonathan - adopt as WG item? no, premature. Humm - between SIP event package and BFCP was not loud, but was in favor of SIP.event package Jonathan - troubled by TISPAN participation - people view us as syntax makers, and we don't need to see architecture discussions, but some of this is protocol design. John Elwell - believe TISPAN made their decision a couple of months ago, looking at SIPPING mail list. Adam - concerns about BFCP are new, hadn't been raised before, think most concerns are based on misconceptions. Jonathan - visualize TISPAN definng the protocol. This is a hard problem. We may need a design team to make progress. Keith - don't go through other paths (Informational, etc.) Need more discussions in SIPPING working group
	15 minutes	Richard Barnes	Early Media in SIP: Problem Statement, Requirements, and Analysis of Solutions	draft-barnes-sip-em-ps-req-sol-00.txt REALLY early media - before you get an answer to your offer. Need normative update to 3261/3264 to MUST this. Need a reliable transport for SDP, forbid sending media until receipt of answer is acknowledged. Cullen - problem with the slide (acknowledgement missing) RFC 3960 - too vague, reliable 183 - requires PRACK, ICE - uses non-SIP messages. None of these are mandatory, so can't rely on any of them. Requirements: ensure answer before media, minimized messaging, SIP-compatible, well-defined PSTN interactions, no new DoS, free from IPT constraints. Francois - what is the scope of what you're trying to fix? Disagree with terminology - not what early media is, not the way we use the term. If you're trying to fix early media, document isn't sufficient. Either expand the document or explain what you're trying to do. Need to look at all of this in the group, but maybe not all at the same time, in one document. Dave Otan - said two meetings ago that we don't have an early media problem, we have a late billing problem. Christer - "backward-compatible with SIP" - we've been trying to do this for many years. Rohan - finish ICE, see if this problem goes away by itself. Discussions will continue on the list.
1005 - 1020	15 minutes	Francois Audet	Early Media Indirection	draft-stucker-sipping-early-media-indirection-00.txt This is a completely different problem from the previous document. All the ways we've seen in the wild about media arriving before a party answers. Solution - treat early media as completely separate dialog. Details on Francois' slide deck (please see proceedings) Are there any implementations of RFC 3959? RFC explains why we DIDN'T use separate dialog then. 3959 does work fairly well if the called device is the one providing early media. Henning - why not an RTP mechanism? Francois - we have lots of them, but none of them work. SSRCs change all the time. Christer - should be a way to identify media with a dialog, genertc thing that we should work on at some point. Don't see why we should use a second dialog to the same location, if the media is coming from the same location. GRUU is optional for both approaches. Not humming on anything, conclusion is that it would be good to be able to deliver announcements and still have everything work without B2BUAs in the middle. Gonzalo - don't just do technical comparison, ask why existing mechanism wasn't deployed. Christer - TISPAN did a study (I wrote it myself) comparing 3959 to TISPAN idea of changing to-tags. Maybe this can also be provided to SIPPING? Gonzalo - we should have an opinion on this, please send a pointer to the list (if you can). Robert - this looks complex, science experiment in strange hard problem mode. Will be market pressures to provide a solution. SIPits are spending time trying to make stuff work. Gonzalo - please continue discussions on list.