Re: [RAI] Minutes of 3GPP - IETF telco on the 19th of October

[Paul Kyzivat <[e-mail]>]

ISTM there is a Catch-22 here.

If an ID is potentially of use for more than one purpose, some middlebox 
wants to mess with it in regard to one of those purposes. (Block it, 
make it work "better", etc.) Hence the only solution is to create a 
separate ID for each and every possible use. :-(

	Thanks,
	Paul

On 10/26/2010 11:39 AM, Hadriel Kaplan wrote:
>
> The problem with using session-id for anything else is: for every other
> use-case discussed so far, I can easily imagine situations where a
> middlebox would need to change the session-id to make things work,
> thereby negating its troubleshooting value.
>
> -hadriel
>
> On Oct 26, 2010, at 10:59 AM, Peter Musgrave wrote:
>
>> Hi Hadriel,
>>
>> I have implemented this as well. It has utility in a non-trouble
>> shooting context in my application.
>>
>> I think the issue in IETF was that we fell into the "solve world
>> hunger" trap. SIPREC through they might find it useful for session
>> correlation but in a pure SIP sense this mechanism does not guarantee
>> dialog correlation...
>>
>> Peter Musgrave
>>
>> On Tue, Oct 26, 2010 at 10:38 AM, Hadriel Kaplan
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>
>>     Hi,
>>     I see the topic of session-id and SIPSCOTCH came up in this
>>     meeting. I've tried getting it chartered, but it appears there
>>     isn't consensus that the narrow topic I want to focus on
>>     (troubleshooting) is what other people care about.
>>     (well... not for people in the IETF anyway - I get constant
>>     queries about this draft mechanism from service providers, but
>>     they don't generally join nor comment in IETF mailing lists)
>>
>>     So I don't really know what to do, other than just implement it
>>     and convince some other vendors to as well, and avoid the IETF.
>>     The IETF just isn't a good place for dealing with operational
>>     issues in SIP, afaict.
>>
>>     -hadriel
>>
>>
>>     On Oct 22, 2010, at 9:32 AM, <[e-mail]
>>     <mailto:[e-mail]>> <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>>     Dear all,
>>>     please find the minutes of the 3GPP - IETF telco earlier this week.
>>>     *Date:*19^th October 2010
>>>     *Time:*15:00 – 17:00 UTC
>>>     *Venue:*Phone conference
>>>     *Participants:*
>>>     Hannu Hietalahti (notetaker), Atle Monrad, Peter Schmitt,
>>>     Christer Holmberg, Peter Dawes, Bengt Sahlin, Keith Drage, Milan
>>>     Patel, Georg Mayer,
>>>     Robert Sparks, Adam Roach, Dale Worley, Spencer Dawkins, Dan
>>>     Romascanu, Jari Arkko, Paul Kyzivat, Ben Campbell
>>>     *Agenda:*
>>>     -------------
>>>     1. Roll call
>>>     2. Review of action points
>>>     3. ATOCA work
>>>     - Presentation of 3GPP PWS in IETF #79
>>>     4. Stalled drafts
>>>     - draft-drage-sipping-rfc3455bis
>>>     - draft-ietf-patel-ecrit-sos-parameter
>>>     - draft-ietf-sipcore-location-conveyance
>>>     - draft-ietf-sipcore-keep
>>>     - draft-ietf-sipcore-199
>>>     - draft-bliss-call-completion
>>>     - draft-ietf-mmusic-ice-tcp
>>>     - draft-patel-dispatch-cpc-oli-parameter
>>>     - draft-bakker-sipping-3gpp-ims-xml-body-handling
>>>     - draft-kaplan-dispatch-session-id
>>>     - draft-dawes-dispatch-mediasec-parameter?
>>>     5. Review of 3GPP IETF dependency document
>>>     - any comments on any other items in the dependency list
>>>     6. Next meeting
>>>     7. AOB
>>>     8. Closing
>>>     *1. **ROLL CALL*
>>>     All participants are listed above.
>>>     *2. **REVIEW OF ACTION POINTS*
>>>     *#*	*Old APs from previous meetings*	*Responsible*	*Status*
>>>     14	Talk with ECRIT chairs and Robert Sparks to make a proposal on
>>>     how and where the sos-parameter -draft should progress
>>>     The current version is being reviewed in DISPATCH and then
>>>     foreseen to proceed as AD sponsored draft
>>>     	Gonzalo 	Closed
>>>     15	Request for volunteers from 3GPP side to co-author
>>>     draft-mmusic-ice-tcp 	Atle	Closed
>>>     16	Check with 3GPP LS officer why the LS C1-101810 was not
>>>     distributed on DISPATCH list
>>>     One way forward would be to provide an informational draft to
>>>     document how things have been done historically. It was agreed
>>>     that re-distribution of the LS is not necessary.
>>>     	Hannu	Closed
>>>     	*New APs assigned in this meeting*		
>>>     17	Agree during IETF #79 how to progress the work on
>>>     draft-drage-sipping-rfc3455bis 	Keith, Christer, Robert	Open
>>>     18	Decide between the editor, DISPATCH co-chairs and AD the best
>>>     approach to progress the work on
>>>     draft-patel-dispatch-cpc-oli-parameter. 	Milan, Mary, Cullen,
>>>     Robert	Open
>>>     			
>>>     			
>>>
>>>     *3. ATOCA**WORK*
>>>     Outside this meeting it has been agreed with ATOCA WG chairs that
>>>     Hannu Hietalahti will make a presentation of 3GPP Public Warning
>>>     System in the ATOCA session in IETF #79. The presentation is
>>>     being prepared in small expert group. The drafting group does not
>>>     follow any 3GPP WG borders but anyone who is willing to work on
>>>     the presentation is invited to contact Hannu.
>>>     *4. STALLED DRAFTS*
>>>     *4.1 draft-drage-sipping-rfc**3455bis*
>>>     This draft has been stalled due to low priority to drive it from
>>>     3GPP side. Christer Holmberg volunteered to help out as co-editor
>>>     to get the work done.
>>>     It still needs to be agreed how to progress this draft. AP 17 was
>>>     assigned to determine whether it can proceed as AD sponsored draft?
>>>     *4.2 draft-ietf-patel-ecrit-sos**-parameter*
>>>     Extensibility mechanism has been removed and now it is reversed
>>>     back to just URI parameter to indicate emergency registration.
>>>     The latest draft does not take any position on how the special
>>>     registration would be treated afterwards. Misuse of URI parameter
>>>     is covered in the latest version, aiming at restricting the use
>>>     of the special registration to emergency case only.
>>>     The 3GPP requirement is to identify special registration for
>>>     emergency purposes.
>>>     Possible re-naming of the draft was discussed to highlight that
>>>     it has been recently treated in DISPATCH but no firm decision was
>>>     made on this yet.
>>>     *4.3 draft-ietf-sipcore-location-conveyance*
>>>     Authors intend to distribute a new version before IETF #79 to
>>>     address the open issues that were identified in IETF #78 in
>>>     Maastricht. The new version will be discussed in Beijing IETF. If
>>>     no new issues are raised, it is expected that the draft could go
>>>     to WG LC in November or December.
>>>     *4.4 draft-ietf-sipcore-keep*
>>>     The draft has just finished WG last call and it has been moved to
>>>     IESG today.
>>>     *4.5 draft-ietf-sipcore-199*
>>>     This draft has been in IESG for a while and it has got stuck in a
>>>     discussion on what are the conditions when this draft is applicable.
>>>     The editor is waiting for the comment from the AD (Robert Sparks).
>>>     *4.6 draft**-ietf-bliss-call-completion*
>>>     The draft is now in WG LC which has already brought up some open
>>>     issues. Dale Worley has got a list of open items and he will
>>>     share them with the editor.
>>>     *4.7 draft-ietf-mmusic-ice-tcp*
>>>     There has been discussion on the 3GPP requirement for this. Now a
>>>     new editor has taken over the editorship of the draft and the
>>>     work is ongoing again.
>>>     Also an email comment on the foreseen way forward was received.
>>>     The document authors have indicated there are currently no known
>>>     issues and they have solicited a few reviewers. The authors
>>>     expect to be ready for WGLC after the Beijing meeting (Nov 2010),
>>>     assuming no new issues come up.
>>>     *4.8 draft-patel-dispatch-cpc-oli-parameter*
>>>     There have been no changes since Maastricht, where the feedback
>>>     was not supportive at all. Informational draft that would
>>>     document historically existing solution was seen as one possible
>>>     way forward. However, Tel-URI parameters would require a
>>>     standards track document, so this point needs to be checked.
>>>     AP 18 was assigned to determine the best way forward.
>>>     *4.9 draft-bakker-sipping-3gpp-ims-xml-body-handling*
>>>     This draft has got a patent issue related with publication number
>>>     US 2009/0119382 A1, Bakker et al. which is dated May 7^th 2009.
>>>     3GPP needs to know whether the draft can proceed to RFC or not
>>>     and take appropriate actions based on that.
>>>     *4.10 draft-kaplan-dispatch-session-id*
>>>     This is the first candidate document for SIPSCOTCH. The charter
>>>     text has been discussed but the group has not been chartered yet.
>>>     This matter has not progressed recently.
>>>     Those interested in the chartering of the WG should contact the
>>>     author of the draft to re-start the charter discussion.
>>>     *4.11 draft-dawes-dispatch-mediasec-parameter*
>>>     On 3GPP side it is seen that DTLS-based solution is not seen to
>>>     work in 3GPP environment, so another solution is needed. The
>>>     editor has not received much feedback on the DISPATCH mailing
>>>     list on his draft. The editor will re-post the draft to the list
>>>     and those driving this work can then give their comments.
>>>     *5. REVIEW OF 3GPP**– IETF DEPENDENCY DOCUMENT*
>>>     *5.1 De**pendency document review during the teleconference*
>>>     New version of draft-liess-dispatch-alert-info-urns has been
>>>     distributed today.
>>>     The author of draft-jesske-dispatch-reason-in-responses would
>>>     need AD feedback from Gonzalo on how to proceed with the work.
>>>     draft-ietf-simple-msrp-acm is waiting for AD go-ahead (Gonzalo
>>>     Camarillo). So far this draft has been processed in sync with
>>>     draft-ietf-simple-msrp-sessmatch, but it is being considered
>>>     whether that linkage should be broken.
>>>     The session matching draft (draft-ietf-simple-msrp-sessmatch) has
>>>     proven controversial both in earlier IETF discussions and in the
>>>     IETF last call. It has now been sent back to WG to get consensus
>>>     on how to proceed. This draft may require substantial re-thinking
>>>     before it can proceed.
>>>     The status of draft-yu-tel-dai in the I-D tracker will be checked
>>>     by Robert Sparks together with Gonzalo Camarillo.
>>>     Hannu volunteered to check the latest news on
>>>     draft-das-mipshop-andsf-dhcp-options from Jari Arkko.
>>>     draft-pkix-cmp-transport-protocols is also marked as critical,
>>>     but no comments were made on it.
>>>     Email comments were received on the following drafts.
>>>     draft-mipshop-andsf-dhcp-options is in IESG evaluation with two
>>>     discussions remaining. This is seen to require a straightforward
>>>     update of the draft and the a review by Tim Polk.
>>>     draft-ietf-mext-rfc3775bis is in AD review.
>>>     draft-ietf-mext-nemo-pd is pending for author’s changes since
>>>     September. The discusses seem reasonable.
>>>     *6. NEXT MEETING*
>>>     Hannu will attend IETF #79 which makes a good opportunity for the
>>>     next status check-up.
>>>     *7. ANY OTHER BUSINESS*
>>>     None.
>>>     *8. CLOSING*
>>>     The meeting was closed at 16:20 UTC.
>>>     BR,
>>>     Hannu Hietalahti
>>>     3GPP TSG CT Chairman
>>>     tel: [phone]
>>>     <ATT00001..c>
>>
>>
>>     _______________________________________________
>>     RAI mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/rai
>>
>>
>
>
>
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rai