Edited by Dean Willis
Agenda Bash:
* No Issues
Accounting/AAA Systems, Bernard Aboba:
Slides describe requirements of real-world accounting requirements, including reliability, security, current issues with RADIUS.
Current issues with RADIUS include:
- backoff unspecified - failover unspecified - application layer acknowledgement missing - undefined proxy behavior - no error messages prevent intelligent failure response - transport security has no confidentiality, known attacks - replay protection only in post-processing - no object security, MITM open
Alternatives discussed including SNMP, DIAMETER
Question: Why couldn't we use Web Services model and XML over secure transport? Answer: accounting semantics are undefined. It could be done, but hasn't yet.
Chair: We had this conversation in order to help us understand AAA requirements.
Question: There are existing systems usually in place (RADIUS). Why are we being blocked from working with them?
Proposal from chairs: Should we be able to do capacity planning and non-usage senstive billing? Consensus yes. Is time sensitive billing in scope? Chair's
Question: We have real requirements -- why are we arguing about which grid-box from RFC 2975 we're going to try and fill?
Question: Time-sensitive billing is a requirement from 3G. Whether it is interdomain is option. Are we talking about the other two A's?
Comment: We should at least consider what has been accomplished with a non-IETF protocol in real-world billing systems.
Question: DIAMETER seems to be the implicit assumption. RADIUS may be obsolete, but should we, instead of arguing requirements, just do a standards-track spec for using DIAMETER and an informational track for using one or more of the existing protocols like RADIUS? Allison: There will be resistance to any RADIUS solution on an RFC track. Why not just use SNMPv3? Chair comment that that doesn't appear to be a good fit for people are doing.
Question: When will DIAMETER exist? Spec editor reports that major issues are done, a few editorial and security considerations remain for documentation, otherwise ready to go.
Observation: RADIUS is widely deployed in accounting for dialup internet access. Many providers combine dial=up with VoIP and have incentive to use same accounting infrastructure. It would be useful for us to document any vulnerabilities of RADIUS that apply to SIP that did not apply to dialup. Response: If you're doing dialup, you're probably not in usage sensitive billing or at least don't have the same requirements as VoIP.
Comment: It is clear that we are driving while looking in rear-view mirror, trying to retrofit VoIP billing on RADIUS. It is clear that we have to look at record format (XML), secure transport (TLS), and look forward instead of backward.
Comment: We should keep in mind that we have a lot of work to do with things like record transfer and post-processing stuff indepedendent of record formats and the like.
Other DCS Drafts:
draft-scsgroup-sip-proxy-proxy-06.txt:
Slides report status and background. Need to update for sipchange process as ind. informational (P-header, no options tag)
DCS architecture draft:
Slides report status. Similar sipchange issues.
Chairs poll for reading of drafts, and for concerns on informational publishing. Comment that we need to know if there are any intellectual property claims, answer "probably".
Question? Will we apply sipchange? yes.
Poll for consensus to proceed -- no objections raised.
Report on 3GPP Ad-Hoc from 20Mar02 (Miguel Garcia):
Path header: current two drafts seem reasonable.
Privacy: Several problems, no clear resolution yet.
Dialed URL: (Target Address-of-Record): P-header approach seems feasible in the short term, may be able to use history or other mechanism in the future. EdNote: This could also be considered as something like a "display name" for the request-URI.
3GPP XML Body: Moving most content to P-headers.
Security items as resolved in SIP.
Event Packages Procedure (Rohan Mahy):
Chairs: Do we need a seperate guidelones document for the authors of SIP Events?
Question: Do we have a template that somebody to use to pre-screen their work for completeness? ENUM put together a template for service field definition. Is the stuff in the sip-events RFC adequate? Chairs poll for sufficiency: strong consensus, current guidance is adequate.
Call and Conference Package (Jonathan Rosenberg):
Slides review proposal from drafts and changes including examples, bis-alignment, addition of direction attribute, removal of To- headers in favor of explicit coding, removal of floor control.
Next steps: at least one implementation known. Need to make sure scope is right and data formats have all information we need. Will split document into two packages (dialog and conference). Propose adding this effort as SIPPING WG item.
Comment: AS we start dfining XML event packages, it looks like the world has moved on beyond DTD definitions into schema-based definitions. We should make a similar evolution in schema definition. Chairs: This is reasonable.
Comment: This framework is needed for distributed call control and the work is supported by the speaker. Several confirmiong comments made.
Comment from chair (Rosen): Do we want to do this definition in SIPPING or is this something that should be done in SIP? This is a "piece" of the problem. It would be really nice to have a bigger view. Have we finished the requirements? Response: It's nice to understand big picture, but also nice to make incremental progress. Chair (Mahy) we need to follow procedure, but we have some requirements, can we proceed? Author: It would be nice to have some discussion of requirements on data format. This should be reflected oe-to-one in the result document, so can be done in conjunction instead of as a seperate effort. This is really a "piece of framework". General discussion follows. Poll for call-info package, none opposed. Poll for conference info package: none opposed.
Future Work (chairs):
Proposals in slides.
3PCC BCP: Never an extension because it was doable in straight SIP, mostly. This has been greatly improved in bis with o/a and update. So the proposed work is to discuss aquestionable lternatives and recommend best practices from the known alternatives. This is not intended to say that 3PCC itself is a better practice than distributed. Poll for adoption: no objections.
Message waiting: Poll for adoption as WG item: no objections. Question: package seems to want to do more than voice message waiting. Author response: will adjust to workgroup conesnsus. Question: Where do we document interworking this with ISDN?
Content indirection and reason codes: Will continue requirements development.
Opaque URI usage: Proposal to do informational draft on guidelines for use of opaque URIs.
MSURI draft: Propose to either roll into Opaque URI or publish as individual informational or do as WG effort. Comment: We haven't really as a group figured out how to do this osrt of thing. Would like to see something that steps back, looks at broad requirements, before delving into solutions. The usage of URIs as service indicators is one of the biggest archittectural problems we face. Counter: This is too large an approach, and we need a solution today. Comment: It is important to define a framework for discovery. Comment: Unless there is someone pushing to do this analysis, the result is likely useless. It is better to proceed by just applowing people to document different approaches and label them with applicability statements. We don't know how big the problem space is, and it is likely to be very large. Comment: we need to define a schema. Comment: we need to do requirements, not jump into solutions. Comment: we need services, concern that if we stall on URI conventions that we'll have problems. Eric Burger volunteers to do framework. Comment: Suggest researching requirements and publishing msuri as an individual in the meantime. Chair comment: would like to see framework or requirements first. Poll: SIPPING WG to develop guideline document on use of URIs. Result - one opposed.
SIP VXML:
NAT Scenarios Draft: Should we do it as WG efforts? Comment: Dealing with NATS is an enormous tarpit. There are many options that apply to different scenarios. Discussion on scope follows. Comments: it would be good to bidirectionally align this with the "unsafe" framework document. Poll: Adopt this as wg item leading to informational rfc: None opposed.
Emergency Services Discussion (Mike Pierce):
Slides review status of emergency services draft and relation to IEPREP work. Proposal from chair: Can authors work with authors of resource priority header on SIP requirements and move other work to ieprep? Answer: That is how the authors are currently proceeding.
Open Mic:
How do we deal with the approval policy for 3PCC stuff like accepting REFERs, etc. Ans: should be in usage drafts, in ot send text.
Device Requirements: We didn't get to this the other day. Where do we stand on it? Comment: There has been some discussion that there may be other venues for operational discussions, such as SIP forums. Comment: Ideal world would be: IETF realized long ago that device configuration is a problem that will be universally faced and have developed a "plug-in" framework (like MIBs) for doing so. This didn't happen. Comment: discussed taking current config document and adding discussion and applicability of things like SNMP, ACAP, etc. Comment: The OAM area has committed to reading the document and working with the author and other interested parties. Comment: This is "right now" problem. We have all the tools we need. We need to write down an interop doc. Comment: We have a split between framework and content. Can we go forward with the definition of the data indpendent of the delivery mechanism? Request from chair: Can we continue this as individual work, dicsussed on SIPPING list, until more clarity?. No opposition. Comment: SIP end devices aree a whole industry, managed by housewives to sysadmins with massive systems. Please think about it.
Settlement: Idea to generate discussion. There might be an opportunity to define a generic challenge-response settlement architecture framework. Comment: How about a response code that says "Payment required -- here's an invoice" something like a 401/407 challenge, with the re-INVITE to contain payment information. Comment: This screams for requirements development in the SIPPING process, need to scope the problem, describe some scenarios, and send text.
AAA: Earlier presentation did not explore large solution space now available. What we can we do if we bring in web services and similar technologies? Consider reviving interdomain settlement/osp drafts earlier "out of scoped" in SIP. Chair request: List discussion on proposal and approach -- "how can we get something done within IETF?" Question: Do you see this work diverging into user-service/provider and provider/provider channels? Response: Mostly between providers. The important thing is the trust function or clearinghouse that enables any-any business relationships.
updated 03/21/2002 20:56 -0600