[Sipping] Minutes from sipping session#2

["Stephen Hayes (TX/EUS)" <[e-mail]>]

Minutes from SIPPING session#2  August 4, 2005, 10:30-12:30

--------------------------------------

ToIP - draft-ietf-sipping-toip-01.txt

Presentation: <http://www.softarmor.com/sipping/meets/ietf63/slides/toip-arnoud-sipping-ietf63.ppt>

Presenter: Arnoud van Wijk

Gonzalo: No disagreement that v02 (next version) should be ready for WGLC.

--------------------------------------

Config - draft-petrie-sipping-profile-datasets-01.txt, draft-petrie-sipping-sip-dataset-00.txt

Presentation: <http://www.softarmor.com/sipping/meets/ietf63/slides/pres-petrie-datasets-sipping-ietf63.ppt>

Presenter: Dan Petrie

Jonathan: Worried about complexity of due to dealing with merging of policy model data.  Data merging not a real problem.  Worry first about data representation and semantics, worry later about merging data.

Henning: Been thrashing for 2 years.  Should defer solving merging problem.

Dan: The original requirement was to have multiple policies and if so they must be merged.

Francois: Source of the info may not be centralized.

Rohan: Merging model is inherent and existing implementations do merging.  Problem simpler than presence since it does not need to deal with ambiguity.  Should not split the documents.

Mary: Merging is needed from day 1.

Cullen: The problem is different from presence and the data schema can be used to simplify the merging problem.

Dan: Need to discuss the merging behaviour when you discuss the schema.  Otherwise there will be problems down the road.

Rohan: Is it always possible to structure the data to avoid merging?

Cullen: In most cases it should be possible.

Dan: If you don't merge, then how do you resolve the session independent policy?

Cullen: Merging is about merging data.  There needs to be a meta policy to determine which policy info to use at a given time.

Jonathan: Not proposing to eliminate merging.  But emphasis should be on the data, not on the merging.  Merging out of scope of the data format document.

Rohan: Interested parties should come up with use cases of including or not including merging.

Jason: Request specifics on why merging should be eliminated.

Jonathan: Merging not important for use case when a service provider wants to initially configure a device.  Want to be able to progress the documents independently.

Rohan: Device upload can be done currently config framework.  Data format work still needs to complete.

Dave:  Separate data merging and meta policy for how to resolve policy conflicts.  The latter problem is usually intractable.  You need to allow for multiple sources of data but should try and avoid the meta policy issue.

Martin: This is important to service providers and work needs to progress.  Clear direction needed to authors so the work can proceed.

Dean: Need to resolve with Allison if this work is in the scope of SIPPING.

Dean: Poll for Interest (If the scope issues can be resolved, should this be added to the charter and made a WG item):  Yes

--------------------------------------


Proposed Fix to HERFP (Heterogeneous Error Response Forking Problem) - draft-mahy-sipping-herfp-fix-00.txt

Presentation: <http://www.softarmor.com/sipping/meets/ietf63/slides/pres-mahy-herfp-sipping-ietf63.ppt>

Presenter: Rohan Mahy

Robert: If WG interested in addressing HERFP, then work needs to proceed.

Jonathan: What are the alternatives?  Better to not rely on the UAS.  We should proceed with this.  Perhaps we should do experimental draft.

Francois: Need to solve this.  Devil is in the details.  We should not waste effort trying to trim the list of repairable errors.

Cullen: Would prefer it not to require PRACK.

Gonzalo: Discuss the actual mechanisms later.

Robert: There are other alternative solutions.

Jon: Need to look at all solutions before making a decision.

Jason: Concerned about the increase in complexity of the proxies.  We should look at all alternatives.

Gonzalo:  Poll for interest (analyzing the tradeoffs).  General consensus that we should be working on this problem.

Robert: Please send a note to the e-mail indicating that this is a real world problem that needs to be solved.

--------------------------------------

TISPAN simulation (continued).  draft-jesske-sipping-tispan-requirements-01.txt, draft-jesske-sipping-tispan-analysis-00.txt, 
draft-jesske-sipping-etsi-ngn-reason-00.txt

Presentation: <http://www.softarmor.com/sipping/meets/ietf63/slides/tispan-ad-hoc.ppt>

Presenter: Roland Jesske

Cullen: What are we going to do in general with these requirements w.r.t. similar requirements coming from other organizations.

Gonzalo: Plan is to have a WG item (publishable or not) to document the incoming requirements.  Does not mean we are accepting the requirements.  Would like to have feedback on each item

Cullen: Pointless to discuss each item individually

Paul: Each item could take a lot of time to discuss.

Rohan: Our charter is to analyze the requirements.

Allison: Like with 3GPP, you start with a meta-analysis.  Separate those that are easy/hard, non-architectural impact/architectural impacts.  There may be some where no IETF work is required. 

Jonathan: Not much of this is P-Headers.  Many of the requested P-Headers represent solutions to generic problems.

Rohan: May decide in some cases that a generic solution is needed.

Miguel: Most are not architectural but are service specific issues many may be of general interest.  May need an interim meeting for dealing with the TISPAN issues.

Mary: Many of these are generic solutions.  Can we handle this in a generic manner?

Hannes: Objects to the solution specific orientation of the document making it hard to understand.

Dean: Input is written in telecom speak.  Propose a design team to do telephony->internet translation, first pass on how to tackle problem, make proposal to WG on how to address each issue.

Miguel: Solutions to be put in the other document

Cullen: Support Dean's suggestion except don't do solutions in the design group.

Rohan: Several people willing to work in design group.

Roland: What is the feedback to TISPAN?

Allison: Agreement to start design work with these documents as input.

Adam: How can this work if input not understood?

Dean: Support from AD to produce a requirements document based on input from TISPAN.

Dean: Poll for interest (Adding a milestone for requirements document for telephony features with TISPAN as input) - Supported.

--------------------------------------

P-Answer State - draft-allen-sipping-poc-p-answer-state-header-00.txt

Presentation: <http://www.softarmor.com/sipping/meets/ietf63/slides/p-answer-state-allen-sipping-ietf63.ppt>

Presenter: Andrew Allen

Gonzalo: Any comments on proposal for Notify to indicate that P-answer-state is confirmed

Paul: Seems confusing (didn't catch the comment)

Rohan: Include a refer so richer info could be included.

Robert: Redraw the picture.  Have the PTT server behave as an end point to simplify things.

Dean: Provide comments back to Andrew.

Gonzalo: Expert review afterwards since a P-Header

--------------------------------------

Implicit Subscriptions - draft-rosenberg-sipping-reg-sub-00.txt

Presentation: <http://www.softarmor.com/sipping/meets/ietf63/slides/regsub-jonathan-sipping-ietf63.ppt>

Presenter: Jonathan Rosenberg

Rohan: Perceived high cost of maintaining subscriptions is just perceived is just a perceived state.  Will make it impossible to send partial state or handle subscribers no longer on the network.  Believes it happened due to propagation to legacy solutions.  Should not pander to poor implementations.

Jason: People doing this don't understand why they need subscriptions.

Dean: Consensus that there is a problem.  Move on to discussing solutions.

Rosenberg: Believes there is truly an engineering problem.

Orit: Now is a good time to discuss the issue

Markkus: It is a problem, but solution needs to work with partial updates.

Aki: It is a problem, but solution should address the high cost of subscriptions due to the overhead of maintaining the subscription.

Andrew: Have to subscribe to lots of things and keep waking up to refresh the subscription state.

Adam: Subscriptions are perceived to be heavy, but are not actually so heavy.

Cullen: In next version be more specific about what resource is critical in the avalanche problem.

Orit: There are several problems in this set and they should be looked at together.

Jonathan: Problem is growing

Aki: If we can save on refresh then this will simply problem

Dean: Poll for Interest (Is there a real problem here that needs to be solved) - Yes

Adam: Agree with problem, disagree with mechanism

--------------------------------------

Media Privacy - draft-shacham-sip-media-privacy-00.txt

Presentation: <http://www.softarmor.com/sipping/meets/ietf63/slides/privacy-henning-sipping-ietf63.ppt>

Presenter: Henning Schulzrinne

Jonathan: (Using cellphone over PA) - Hard to determine in an automated way if a conversation is private.

Rohan: It may hard to assure privacy at the terminating side, but it may be useful to indicate the desire for it.

Jonathan: Easier to just use conversation to establish need for privacy

James: What about legal intercept?

Justin: Important to know if the far end is giving legal consent to be recorded.

Dave: Hopeless to determine if a conversation is private

Jason: This is for indication vs request.  Speakerphone different issue than recorder

Gonzalo: Take it to the mailing list.

--------------------------------------

SIP User Identifiers - draft-schulzrinne-sipping-id-relationships-00.txt

Presentation: <http://www.softarmor.com/sipping/meets/ietf63/slides/ids-henning-sipping-ietf63.ppt>

Presenter: Henning Schulzrinne

Jonathan: Presence is a better solution to find contact info.  Problems with people assuming this mapping is true when it may not always be true.

Rohan: No value added by having this draft.

Cullen: Doesn't like propagating tel-URIs

Dean: Thinks there might be some merit in the enterprise environment.

Rohan: Not in the scope of SIPPING

Gonzallo: Continue discussing in the mailing list.












_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP