Notes, SIPPING Session 1, IETF 61

Reported by Spencer Dawkins

AGENDA:

Tuesday, November 9 at 0900-1130
--------------------------------
0900 Agenda Bash - Chairs

0905 Status of Work - Chairs

Have published SIP with ENUM as RFC
Release 5 3GPP with area director
Lots of documents in working group last call
E2M Security requirements aggressively scheduled for December, Conferencing bundle for January, URI-List in February/March
Number of parallel working group last calls is a chair concern - don't want to add another seven documents now, for instance
Location Requirements is morphing into "requirements and solutions" - is this a concern for the working group? Will be discussed during meeting
Conferencing can't be as late as the proposed milestones because of 3GPP dependencies - are the documents close? they've received considerable WGLC comments, expect changes. Some confusion about what 3GPP wants on their deadline - more than terminology in December? Allison thinks "yes". Most IMS work is conferencing, preferences, messaging - may not need all the documents at once (Keith Drage), but need these in December/January. Just need to address the comments, not just move the milestones, though.

0925 Configuration - Dan Petrie - draft-ietf-sipping-config-framework-04.txt and draft-petrie-sipping-profile-datasets-00.txt

Lots of changes to 04 draft (05 is out now).
Looks like we're keying on model numbers (under vendor control) as an extension mechanism? Erk!
Can we do the config framework on low-end devices? Yes (but maybe not the datasets mechanism)
Haven't revved the datasets draft since last IETF, but want to discuss one issue - where are we on complexibility versus parsability?
We have like four different profiles that can overlap - how do we express constraints?
We just need to work through some use cases - don't start out this abstract, we'll get into trouble.
Is this a constraint problem or a syntax problems? If requiring a full XML parser is problematic for low-end devices, should we be using XML?
Let's figure out what we need to do, and be realistic about what people will do on low-end devices - will these devices be capable of merging at all?
We don't have any standard device configuration mechanism now. Don't boil the ocean here. Any improvement will be a huge improvement.
Very worried about complexity, interoperability, and determinism - how many parameters will profiles really be arguing over? If it hurts, stop - don't put parameters in two or more places, leave the effect of conflicts undefined - just do something.
We're going to look at use cases, think about requirements, and keep things simple.

0935 Session-Independent Policies - Volker Hilt - draft-ietf-sipping-session-indep-policy-01.txt

Major revision, now based on config framework
UAs subscribe to policy servers, rules about when to subscribe are defined.
Adding XML schemas for specific policies - do these belong in this draft?
Need to add a new attribute - "default".
Directly session based - OK semantics? Reasonable?
Working on specific conflict resolution behaviors - lowest bandwidth wins, for example.
Treatment of emergency calls?

0945 Session-Specific Policies - Volker Hilt - draft-hilt-sipping-session-spec-policy-01.txt

When does a UA contact a policy server? What information does it provide?
We're not talking about "tell a policy server a call has ended", are we? Actually, people ARE using policy servers as bandwidth controllers for admission control, even though we think this is wrong.
Record-route should provide the needed capabilities without overloading subscriptions - we get wrapped around axles in transfer, etc.
Valuable for policy servers to provide information about policies to UAs but not the other way around.
How does this work in a federation of domains? Where is assertion?
Are policy servers providing guidance or policy enforcement? Probably need to punt this to tonight's discussion about SBCs

0955 SIP-URI Services - Gonzalo Camarillo - draft-ietf-sipping-uri-services-01.txt, draft-ietf-sipping-uri-list-conferencing-01.txt, draft-ietf-sipping-uri-list-message-01.txt, draft-ietf-sipping-uri-list-subscribe-01.txt, and draft-ietf-sipping-multiple-refer-01.txt

We're going to do comparisons between URIs based on RFC 3261, right? so we would understand aliases, etc.
Can I update the original URI-list using a subsequent SUBSCRIBE? Gonzalo is leaning toward "no". 3PCC may have problems here - Gonzalo will look at this (we've been surprised before).
Is this going to be consistent with consent framework (whatever that turns out to be)? Consent framework will be one way of addressing requirements - should this be a MUST? What happens if someone blows the consent framework off? Cullen will provide text here. But we'll need at least one mandatory-to-implement mechanism here that meets the requirements (others would be OK, too).
We're overloading the list - when it arrives at a list server, it explodes the list, but if it arrives at an end system, it has other effects. This seems problematic - needs to be using a different content type..

1005 Consent - Gonzalo Camarillo - draft-ietf-sipping-consent-reqs-00.txt and draft-ietf-sipping-consent-framework-00.txt

Can I authorize translations beforehand (without waiting for an INVITE, for example).
One way would be XCAP - Cullen thinks we should be open to other options - this is usually going to be binary yes-no, right? We should just think about this. Do we limit the set of user agents that can receive explosions to be limited to the user agents that support XCAP? Maybe just to support automatons - a human could certainly use a web page, or something.
We also need a must-implement mechanism that provides consent, if we're going to get interoperability.
Maybe XCAP could be more trivial than we're making it - HTTP or SIP body and that's it? "Write-only XCAP"? Inserts are more complicated than what we're talking about.
We can have schemas that accommodate simple use for simple purposes but can handle more complex ones, too.
What's mandatory to implement in the server doesn't have to match what's mandatory to implement in the client, right? Accommodate high-end users, too.

1025 Transfer - Alan Johnston -draft-ietf-sipping-cc-transfer-03.txt

REFERs sent out of dialog with GRUUs is still an issue. Correlate to target dialog? Maybe back this text out and think about it? Need to fix this now - this is a real problem affecting real people. Need to generalize beyond REFER (it's already in the interactions-framework draft). Could also express what the relationship is.
Think we're good for WGLC if we can get past this open issue.

1040 End-to-middle Security - Kumiko Ono - draft-ietf-sipping-e2m-reqs-04.txt (currently under WGLC), draft-ono-sipping-end2middle-security-03.txt

Reqs-04 has some changes since reqs-03, not large, feedback is appreciated.
Now working on follow-on draft.
For target body for "middle" - four options, recommend a new SIP header (not a new SIP parameter in existing header or MIME header/parameter).
How do we handle notification about problems with e2m security - with a new error code? Is 403 sufficient? "495 Signature Required"?
Is this mechanism SIP work or SIPPING work? Rohan thinks SIP. Would also match maturity level in SIP (many milestones finishing).
What's the community interest in implementing this work? Significant but not overwhelming. Will be recommended to SIP via Allison. Please provide feedback on the issues we've talked about today.

1055 Caller Preferences User Cases - Paul Kyzivat - draft-ietf-sipping-callerprefs-usecases-03.txt

"Has been crawling through these working groups for years"
Biggest change is implementation guidance on the matching algorithm
Removing "UA Routing" -> GRUU
Fixing errors and oversights, but this is mostly finished - right? Not a lot of comments on the list, not a lot of involvement - is it ready for WGLC? As soon as a slot opens...

1105 GRUU Extensions to the Reg Event Package - Paul Kyzivat - draft-kyzivat-sipping-gruu-reg-event-01.txt

Some registration event package things break with GRUUs because the returned Contact is not accessible. This draft tries to fix/clarify them. Paul thinks the current draft has addressed all the open issues received to date.
Again, not a lot of WG feedback (maybe too small to be done by itself?). Merge this with GRUU draft? In SIP working group? Needs scrutiny anyway.
What about registration cleanup?
Do exactly what we're doing now? Usage of GRUU is intimately tied to data models - how to separate the documents?
Who's implementing the reg package? Looks like they would all implement this draft (based on sense of the room).
Does this even need to be done in the working group? Does it need to be done now?

0920 Conferencing Design Team Status Update - Jonathan Rosenberg - draft-ietf-sipping-conferencing-framework-03.txt (currently under WGLC)

Main remaining issue is making sure this draft fit well with xcon framework. Don't want conflict, don't want overlap.
Seem to have some concept that one document is an overview of the other, and that's not true. There are mechanisms that don't exist in XCON.
Don't need a generalized model for conferencing!
What if we come up with two capabilities that don't mesh? The IETF has done this before, but we're talking about two capabilities for the same community of interest. Jon - "This Seems Wrong", but Allison is the AD for both SIPPING and XCON, and she's out of the room...
Dead set against two conferencing systems that compete. We need a framework. We're stalling. We need to move forward now. Protocol-agnostic issues in XCON - we've already proved we can map H.323 to SIP anyway.
A limited SIP conferencing framework and an XCON that deviates from it is a mistake!
What would we do if XCON was taking place in another standards body? We would clearly still have a SIPPING framework, right? We're having a problem with scope creep and work will never finish - we have four two-hour meetings for the two working groups. XCON doesn't even require SIP as a participant in the conference at all. XCON framework doesn't go into detail about SIP mechanisms.
Don't see overlap, don't see contradiction, don't see overlap (Jonathan disagrees).
If we started with XCON we would need a SIP mapping, anyway. Don't understand why people are concerned about deployment.
Problem isn't that they conflict today, it's keeping them in sync.
Can't just "do" things in XCON that will affect SIPPING without talking to them anyway.
Do people have concrete suggestions for text moves/adds/deletes? Jonathan will provide text on the list.
Need a chairs discussion with ADs to sort this out!
Is SIPPING required to follow the XCON framework? No.
Not a single MUST, SHOULD, or MAY in SIPPING framework that shouldn't be in XCON. XCON shouldn't be solving the total problem (mobility, etc.)

1130 Meeting Ends