Subject:
SIPPING - IETF 68 Agenda |
From:
<Saved by Windows Internet Explorer 7> |
Date:
Mon, 19 Mar 2007 09:06:03 +0100 |
Chairs: Gonzalo Camarillo, and Mary Barnes
Secretary: Oscar Novo
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 |
Configuration Framework |
draft-ietf-sipping-config-framework-11.txt
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...
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.
Cullen - I brought this up, we just need to ask DNS people, we don't have the expertise to decide here.
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.
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.
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 |
A User Agent Profile Data Set for Media Policy |
draft-ietf-sipping-media-policy-dataset-03.txt 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 |
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 |
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. |
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 |
SIP File Directory |
draft-garcia-sipping-resource-sharing-framework-01.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 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 |
SIP End-to-End Performance Metrics |
draft-malas-performance-metrics-06.txt 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 |
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.) |
|
|
15 minutes |
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. |