AW: [Sipping] Minutes from sipping session#2

["Tschofenig, Hannes" <[e-mail]>]

hi stephen, 

thanks for taking meeting minutes. 

i would like to point out that i said that the 'draft-jesske-sipping-tispan-requirements-01.txt' is hard to read. considering the time we spend to make other document easy to read/understand i think more cycles have to be spend on this one as well. 

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

this is not quite what i said, i believe. my statement regarding the solution specific parts referred to the presentation. 

i, however, questioned the text in the security consideration section. 

ciao
hannes

ps: btw, using rfc 2119 in a requirements document also makes sense. 

> -----Ursprüngliche Nachricht-----
> Von: [e-mail] 
> [mailto:[e-mail]] Im Auftrag von Stephen 
> Hayes (TX/EUS)
> Gesendet: Donnerstag, 4. August 2005 15:18
> An: Sipping (E-mail)
> Betreff: [Sipping] Minutes from sipping session#2
> 
> 
> 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-arn
> oud-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-pet
> rie-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-mah
> y-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-a
> d-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-j
> onathan-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-henn
ing-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

_______________________________________________
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