[Sipping] Please review for minutes

These are my notes from today's session...

Thanks!

Spencer

 SIPPING - IETF 65 Agenda
Chairs: Mary Barnes and Gonzalo Camarillo
Scribes: Spencer Dawkins <spencer@mcsr-labs.org>

WEDENSDAY, March 22, 2006, 1300-1500, Chantilly W
1300 - 1315 15 minutes Chairs Status and Agenda Bash 

  a.. Softarmor.com supplementary web page will be discontinued, will be using official IETF tools instead
  b.. May use this for designated reviewers, but official tools need this for Gen-ART anyway
  c.. Effort is huge for individual submissions
  d.. Allison - want to use this group as guinea pigs for new states (like, who is reviewing) between now and Montreal
  e.. Security directorate also needs a Gen-ARTish tool, for the same reason
  f.. Friday agenda has lots of very short slots
  g.. Have published ten more drafts in RFC editor's queue, plus five more publication requested
  h.. SIPPING will be able to think of tackling new work (after Consent is finished)

  i.. Doing one-slide summaries of some new drafts - isomaki-sipping-file-transfer
  j.. Do we do requirements in this working group, or just solutions?
  k.. MMUSIC slides also presented here for information (accepting file transfer using offer/accept)

  l.. Cullen - "do you reject at INVITE time, or at MSRP time?" Don't actually care, that's what other people were asking
  m.. Dean - SDP variations - are you doing this so IMS can bill you separately for media types? Gonzalo - completely orthogonal
  n.. Jabber - ICE interactions? There are none, this is inline signalling

  o.. Hasabe-race-condition-examples - some organizational changes, would like to get WG opinions on this draft
  p.. Paul - supports this - there's a lot of confusion out there in the world, need to write down the folklore. This needs feedback more than anything else ("clear enough to help?")
  q.. Dean - RFC, either WG or AD-sponsored. May get better review as WG item. Hum is to adopt as WG item.

  r.. Multi-transcoding Use Case - author sent home to explain scenarios where this is possible, has updated the draft, please comment on list about this draft
  s.. SIP LDAP User Schema - please  read and comment

1315 - 1335 20 minutes Dan Petrie
 Config Framework Split
 draft-ietf-sipping-config-framework-08.txt
draft-ietf-sipping-xcap-config-00.txt
draft-ietf-simple-xcap-diff-03.txt  

  a.. Have dependency issue, divided into two parts to bypass XCAP normative dependencies on document and auid even header parameters
  b.. Also fixed nits, clarifications, device certificate usage

  c.. Issue is "how does device know the profile server supports XCAP?"
  d.. Options are (1) Profile delivery server rejects if not supported, (2) XCAP mandatory, (3) Profile delivery server give the smallest profile subset that includes document path or auid
  e.. Jonathan - we have all these event parameters that we are extending and realizing that we don't have extension mechanisms for this. (3) is wrong, you want something like (1) or (2).
  f.. Rohan - in this case, what would the client asking for this do, besides going back and retrieving entire document? Rohan likes (3), but it's that the server returns the entire document.
  g.. Jonathan - don't like client requests A and server returns B.
  h.. Aki - saying that server doesn't know anything about XCAP? HTTP servers understand URIs, they understand the path partially. Sounds like we want to do (1).
  i.. Jonathan - variations here - no XCAP, no support for document parameter, document does not exist...
  j.. Do we ignore parameters we don't understand in 3265? Parameters getting pretty important to understand, the direction we're going.
  k.. Not sure document will actually get done quicker after the split anyway (XCAP has just concluded WGLC).
  l.. Rohan - Allison asked me to do this document's PROTO statement, I looked at dependencies and don't think we can ship the document in this form anyway (is just informative).
  m.. Jonathan - don't think XCAP is too bad a dependency. Perhaps paranoid that people are trying to get XCAP out of the way (can do configuration without this XCAP stuff) - maybe reasonable, but then we need to discover support for XCAP, etc. 

  n.. Dan - has always been a requirement for configuration to work, independently of XCAP.
  o.. Paul - "doesn't work, try a different way" - we've been here before with REGISTER instance IDs - bounced this because people wouldn't tolerate the traffic (would be bad to try everything twice). Prefer (3).
  p.. Aki - This is a 420 going back
  q.. Jonathan - the problem isn't that XCAP is broken, it's that we've got an optional capability with no way to signal support. Let's be crisp.
  r.. Rohan - reasonable to have option tag, but would Jonathan be OK with base profile delivery mechanism that has RFC 3265 behavior (ignore unknown headers)?
  s.. Gonzalo - don't have time for detailed discussion here. Who has opinion on making XCAP mandatory? Not many. Who thinks it should be mandatory? No one in the room - need to take this to the mailing list.
Discussion resumed at end of the session

  a.. Rohan - Real issue is, what do you do if you don't support XCAP at all? Different from what you do if you support XCAP but there's an error. For any event package in general, we haven't needed a mechanism to negotiate whether you support a new header, and don't think we will. No need for mechanism if nothing bad happens if you DON'T support the new header.
  b.. Jonathan - different problem (someone wants to find out that someone else added a third person to the buddy list. We're pushing this back to a separate event notification. My understanding is that IMS doesn't use this.
  c.. Andrew Allen - IMS requires a registration first.
  d.. Jonathan - aren't they using non-SIP mechanisms?
  e.. Rohan - no suprise that IMS doesn't work the way we think. IE-HTTP works fine today. Would I be using a mobile client that doesn't support XCAP? You only get profiles with application types.
  f.. Jonathan - what does application mean if you remove document and auid? Get a 404 - what's the problem?
  g.. Dan - not sure negotiation mechanism is necessary - doesn't make sense.
  h.. Jonathan - what can you do if server doesn't support something you want?
  i.. Rohan - disagree that can't do anything useful.
  j.. Gonzalo - please take this to the list.
  k.. Jonathan - question is whether new stuff is extensible or not.

1325 - 1330 5 minutes Sumanth Channabasappa
Jean-Francois Mule 
Use Case and Considerations for SIPPING  config 
draft-channabasappa-sipua-config-mgmt-00.txt 

  a.. UA configuration and managment are different
  b.. Has three different use cases, focused on third use case here.
  c.. SIPPING framework can be used for both configuration and management
  d.. Must traverse NATs and firewalls in today's networks
  e.. Use SIP-based mechanisms to establish management sessions?
  f.. Rohan - negotiate something? Correct, management isn't done through SIP, only required parameters
  g.. Cullen - management for what? SIP calls aren't working? so can't use it to manage SIP devices, right?
  h.. Assuming that UA needs to be managed, working on how to do this.
  i.. Jonathan - network wants to read statistics off the device - assumed this use case for the draft. Could be "phone home" poke.
  j.. Dan - could be reading firmware versions, etc.
  k.. Heshim - commands are different from queries
  l.. Dan R (AD) - could you coordinate with management framework being worked in management area?

1340 - 1425 45 minutes Gonzalo Camarillo Consent Framework
draft-ietf-sipping-consent-framework-04.txt 
draft-camarillo-sip-consent-method-00.txt
draft-camarillo-sipping-consent-reg-event-00.txt
draft-camarillo-sipping-consent-format-00.txt
draft-camarillo-sipping-grant-permission-00.txt
draft-camarillo-sipping-list-state-00.txt 

  a.. Requirements are in RFC Editor's queue
  b.. WG consensus on framework direction, needed normative behavior documents that implemented the framework
  c.. Based permission document on common policy format (new conditions - sender, target - and new action - trans-handling)
  d.. Could use XCAP to manipulate URI list
  e.. Use XCAP-diff to inform about changes in state of the list - could we use XCAP-patch as well?
  f.. Rohan - what's the problem with XCAP? Does not provide "this change". Need URI for Refers-to.
  g.. Jonathan - has many problems - mixing state machine and static data together - may want to know about events, not just state changes. Mix them, you need both. This is all XCAP-specific. Could have separate event class.
  h.. Henning - general problem is that XCAP becomes a more procedure-oriented protocol - no good way to tell you what actually happened. Even for simple notifications this is a kludge - need warnings around this. We've already done the damage for "simple event notification" - 

  i.. Andrew Allen - seeing proposals like this all the time.
  j.. Jonathan - don't think we should press reset button on all simple notifications, but tunneling a protocol though a document is a mistake. We have a better solution.
  k.. Alternative - list format remains unmodified (extension to XCAP), separate event package with pending permissions.
  l.. Jonathan - don't agree an extension is required at all.
  m.. Gonzalo - translation could be XCAP, registration, or other mechanisms
  n.. Permission-Upload header field used by client to upload permission document. Ipen issue - header field or part of permission document? Choosing header field in draft for now.
  o.. Grant-Permission Event Package - uses XCAP-diff - should it use XCAP-patch as well? Client needs to delete permission documents.
  p.. Could use permission server to generate URI that routes instead.
  q.. Consent in Registration - not applicable when SIP-Outbound is being used. (have already consented to rceive traffic).
  r.. Extension to reg-event (new <consent-status> element), with separate event package with pending permissions.
  s.. Request-contained URI lists generate errors when they have one or more invalid URIs
  t.. Open issues - does a URO get added to the list just by arriving in a request? or do clients need to use XCAP? Clients have no incentive to remove documents from servers (or servers can garbage-collect)
  u.. Andrew Allen - could we have expires? We decided not to.
  v.. Jonathan - two sides - bottom pieces are me and other guy, top pieces are consent server and relay. Consent server issues are different from relay issues - we're conflating them.
  w.. Would like to finish ASAP, but this isn't trivial. We will request reviewers for next version.
  x.. How many people read the documents? Not a lot, but more than Gonzalo expected. 

  y.. Rohan - how many understood? :-)
  z.. How many planning to implement?
  aa.. Henning - this is a blind alley, too complex to implement, giving SIP a bad name, five specs with event packages to do one operation. People will ignore consent if we do it this way. No one will understand it, no one will use it, and it doesn't add a single dollar to revenue - good luck getting implementations.
  ab.. Robert - this is like two orders of magnitude too complex. Do we really want a single mechanism to solve the problem that got us here in the first place?
  ac.. Jonathan - complexity is because of the requirements. If you accept them, you're here. Not because of the generality.
  ad.. Dean - all OMA services are normatively dependent on this, we've got to solve this anyway.
  ae.. Jonathan - core interim requirement was that we can't have a single amplification in the network. If you relax that, you have explosions.
  af.. Cullen - we all agreed to go here. If we remove requirements we can't solve the problem. Do we can all the stuff associated with this?
  ag.. Rohan - disagree - I did not agree to do this, it was a requirement from the IESG to specify something to address explosions. SIPPING was asked to solve this problem, it's IRTF material.
  ah.. Cullen - we can solve the problem but the solution is too complicated and no one will implement it. That's not an IRTF thing.
  ai.. Aki - we're making things very hard for the good guys.
  aj.. Gonzalo - if you're OK with being an amplifier, don't implement this.
  ak.. Robert - if requirement list can't be reduced and still solve the problem, could we reduce requirement list and solve OTHER problems (contact lists, explicitly)? Take a smaller hammer to smaller problems?
  al.. Gonzalo - complexity of solution would be exactly the same.
  am.. Henning - argue that if you can solve the first one, the other stuff is easy - if no one implements the first one, you'll get kludges for the second ones, and they'll be silly one-off implementation efforts. I admire your persistence, but no one will even be able to provide feedback and they'll hum just to be finished. And then it will be mandated into other things. This is a valuable exercise, but we need to honestly say that the cost benefit analysis failed. Don't do this just because you're chartered to do it.
  an.. Dean - came up with SIP way to do this that was a kludge, and it's better than this.
  ao.. Jonathan - I look forward to reading your drafts. You'll either drop requirements or end up in the same thing.
  ap.. Rohan - sending e-mail gives you the same problem, the explosion happens in e-mail instead.
  aq.. Cullen - it's still a milestone, as long as it's a milestone, we need to do this.
1425 - 1445 20 minutes Volker Hilt Session Policies
 draft-hilt-sipping-session-policy-framework-01.txt
draft-hilt-sipping-policy-package-01.txt
draft-ietf-sipping-media-policy-dataset-00.txt 

  a.. Should have been submitted as WG item (sorry!)
  b.. Added confidentiality of SDP concern in Security Considerations section.
  c.. Changed content disposition type for policies
  d.. Clarified SDP extension use
  e.. Depends on policy framework draft
  f.. Major open issue - how to submit session information to the policy server? (Sending a session description to policy server, getting a possibly-modified description back).
  g.. Option 1 - PUBLISH/SUBSCRIBE (but we could run into deadlocks)
  h.. Option 2 - SUBSCRIBE bodies
  i.. Proposed to stay with current mechanism based on SUBSCRIBE only
  j.. Andrew Allen - what was objection to second option? just remember there was a problem, don't remember details
  k.. Discussions to continue on mailing list
Rohan - if you have comments on the config framework, please look at the current version - would like to get something done this week. Too late for an ad hoc, but need to continue discussions.

1445 - 1500 15 minutes Arnoud van Wijk ToIP draft-ietf-sipping-toip-04.txt 

  a.. Who has read the draft? Almost no one
  b.. Draft is WG item, WGLC finished Nov 2005, this version addresses comments received.
  c.. Have gotten new discussion recently
  d.. Main discussion seems to be around purpose of the draft (title is about requirements, document is about framework).
  e.. Some changes to confusing 03 structure.
  f.. List comments said "contradictory and incomplete" - no evidence of contradictory, missing items promised but seem to include peer-to-peer and QoS. Think missing items are OOS for current draft.
  g.. Seek WG agreement on Scope of Draft, WGLC changes, additional ToIP related work is likely?
  h.. We have a reviewer (and chairs will be reviewing update, too).
  i.. Rohan - does anyone think Peer-to-peer is in scope?