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.
<>Problematic referring back to SIPPING framework when we're
trying to do something broader in XCON. Mechanisms section is where the
meat is .Mary is willing to make an editing pass. - 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