Subject: [Sip] Draft agenda, SIP at IETF 72

From: Dean Willis <[email-masked]>
Date: Wed, 16 Jul 2008 10:45:01 -0500

This is the draft agenda for the SIP meeting at IETF 72 in Dublin.

• Note that this agenda is subject to change based on list conversations

• Note that we're still trying to work out how to have the "Identity"  
discussion

Pretty HTML is at:
http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_72

Text follows

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

Agenda for SIP at IETF 72, Primary Session, Tuesday July 29, 2008,  
1300-1500, Convention 3

Agenda Bash
Chairs
10

Using SAML for SIP
Chairs
draft-ietf-sip-saml-04
10

Identify requirements for test matrix to move SIP to Draft Standard
Robert Sparks
draft-sparks-sip-steps-to-draft-00
20

Essential corrections to RFC 3261 (1st batch)
Robert Sparks
draft-sparks-sip-invfix-02
15

Delivery of Request URI and Parameters to UAS Through Proxy
Speaker TBD
draft-rosenberg-sip-ua-loose-route-02
draft-holmberg-sip-target-uri-delivery-01
25

Mechanisms for UA Initiated Privacy
Mayumi Munakata
draft-ietf-sip-ua-privacy-02
15

MIME body handling in SIP
Gonzalo Camarillo
draft-ietf-sip-body-handling-02
15

Guidelines for double route recording
Thomas Froment
draft-ietf-sip-record-route-fix-03
Time TBD

Keepalive Without Outbound
Christer Holmberg
draft-holmberg-sip-keep-01
10

Agenda for SIP at IETF 72, Primary Session, Thursday July 31, 2008,  
1510-1610, Convention 3

Agenda Bash
Chairs
5

Termination of early dialog prior to final response
Christer Holmberg
draft-ietf-sip-199-00
20

INFO
Speaker TBD
draft-burger-sip-info-02
draft-kaplan-sip-info-events-01
draft-rosenberg-sip-info-litmus-01
draft-kaplan-sipping-dtmf-package-00
draft-willis-sip-infopackage-00
35

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Robert Sparks <[email-masked]>
Date: Wed, 16 Jul 2008 16:20:56 -0500

This is a really good place to start bashing from. Thanks for going  
through the pain it takes to put this together.

Everyone should take note that the second session has a RAI conflict
(with DRINKS) and think through where to put conversations so that
we minimize the pain caused by the necessary split of people.

I think I'd rather see the large, architectural questions,
INFO and Identity, moved into the conflict free spot and
put topics with a smaller constituency into the second session.

I also think people across the working group should chime in with what  
they think
the three most important _DRAFTS_ to talk about, in person, at this  
meeting are.
I strongly suspect there's a surprise or two that will come out of that.

I'll throw my own list in later (because I want to think awhile about  
what's _not_
in the proposed agenda), but to help tune things early:

I do want to talk about 199.

I don't see why we should spend face time on sip-keep at this point.

I think we can get away without face time on record-route fix.
(its unlikely at this late stage that we'll find a crisis to work  
through there).

I have received very little feedback on invfix, and I don't think
     we need to spend any in-meeting time on the essential
     corrections process itself. So, I propose we take that entire
     topic to the list and/or hallways. I'll take on pushing a few
     key folks to review the big recent changes to invfix and
     speak up that they've done so before we get to the meetings.

Everybody else: If you hold the token on any of the other drafts and  
feel you can
  resolve any issues you currently have the same way, I strongly urge
  you to propose something similar for your time.

RjS

On Jul 16, 2008, at 10:45 AM, Dean Willis wrote:

> • Note that we're still trying to work out how to have the  
> "Identity" discussion
>
> Pretty HTML is at:

---

From: "Hisham Khartabil" <[email-masked]>
Date: Thu, 17 Jul 2008 09:26:32 +1000

Having looked at the agenda, I think we can do without the 2nd session. What
I mean is that we can remove presentations from the 1st session that we
don't think need face time (Robert pointed at a couple) and move the ones
requiring face time from the 2nd session to the 1st.

I don't think we need 10 mins to bash the agenda. I also don't think we need
10mins for draft-ietf-sip-saml-04. We can limit face time to drafts that
have open issues to discuss that were not resolveable on the list.

Thanks,
Hisham

On 17/07/2008, Robert Sparks <[email-masked]> wrote:
>
> This is a really good place to start bashing from. Thanks for going through
> the pain it takes to put this together.
>
> I also think people across the working group should chime in with what they
> think
> the three most important _DRAFTS_ to talk about, in person, at this meeting
> are.
> (its unlikely at this late stage that we'll find a crisis to work through
> there).
>
> Everybody else: If you hold the token on any of the other drafts and feel
> you can

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Jul 2008 00:05:31 -0500

On Jul 16, 2008, at 6:26 PM, Hisham Khartabil wrote:

> Having looked at the agenda, I think we can do without the 2nd  
> session. What I mean is that we can remove presentations from the  
> 1st session that we don't think need face time (Robert pointed at a  
> couple) and move the ones requiring face time from the 2nd session  
> to the 1st.
>

Well, I have to say I based the invfix and steps-to-draft times on  
Robert's request from last week, so I'm surprised but not unhappy  
about the suggestion to nuke them.
>
> I don't think we need 10 mins to bash the agenda.

Keith and I discussed that. I suggested 5. He pointed out that for the  
last 10 meetings or so, every time we've said 5 we've used 15.

> I also don't think we need 10mins for draft-ietf-sip-saml-04. We can  
> limit face time to drafts that have open issues to discuss that were  
> not resolveable on the list.
>

Here's the open issue with SAML. Are we actually going to do anything  
with it? The two people who seem to care about the draft have worked  
at it steadily. Does it have any meaning to the rest of us? Should we  
publish it? Maybe as experimental?

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 17 Jul 2008 07:20:45 +0200

Hi,
 
As I said earlier, I see no major issue with 199 at this point which would require face-to-face discussions. I could give a status update, but that would only take about 5 minutes.
 
I think we DO need to decided, based on Keith's requirement questions etc, how to move forward with keep.
 
I also think two slots now give us a good opportunity to discuss (and decide) what to do with INFO, so I really think we should use the two slots that have been given to us. 
 
Regards,
 
Christer

________________________________

Lähettäjä: [email-masked] puolesta: Robert Sparks
Lähetetty: ke 16.7.2008 23:20
Vastaanottaja: Dean Willis
Kopio: SIP IETF; Cullen Jennings
Aihe: Re: [Sip] Draft agenda, SIP at IETF 72

RjS

On Jul 16, 2008, at 10:45 AM, Dean Willis wrote:

> * Note that this agenda is subject to change based on list 
> conversations
>
> * Note that we're still trying to work out how to have the 
> "Identity" discussion
>
> Pretty HTML is at:

---

From: "Hisham Khartabil" <[email-masked]>
Date: Thu, 17 Jul 2008 15:38:48 +1000

Christer,

The 2nd session conflits with DRINKS, therefore you will find that it may
well end up having all the unimportant topics discussed in it. I therefore
suggested cancelling that session compeletly. I really believe important
topics can be queezed into the one session.

Regards,
Hisham

On 17/07/2008, Christer Holmberg <[email-masked]> wrote:
>
> Hi,
>
> As I said earlier, I see no major issue with 199 at this point which would
> require face-to-face discussions. I could give a status update, but that
> would only take about 5 minutes.
>
> I also think two slots now give us a good opportunity to discuss (and
> decide) what to do with INFO, so I really think we should use the two slots
> that have been given to us.
>
> Regards,
>
> Christer
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Jul 2008 08:11:24 +0100

My 3 (well, 4) most important topics:
- RFC 4474 issues
- INFO
- Next steps towards Draft
- UA loose route

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Robert Sparks
> Sent: 16 July 2008 22:21
> To: Dean Willis
> Cc: SIP IETF; Cullen Jennings
> Subject: Re: [Sip] Draft agenda, SIP at IETF 72
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 17 Jul 2008 03:31:57 -0400

My list is the same as John's, fwiw.
I'm also very surprised SIP can be scheduled in conflict with any other RAI WG, especially a brand new one. :(

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Elwell, John
> Sent: Thursday, July 17, 2008 3:11 AM
> To: Robert Sparks; Dean Willis

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 17 Jul 2008 14:11:20 +0200

THERE ARE NOT INTENDED TO BE ANY PRESENTATIONS IN THE SIP AGENDA.
 
These are the slots we think we need to address the issues that have surfaced on the list, and where we believed face to face time would be beneficial, or where we as chairs need guidance on how to progress an item. In that respect the inclusion or exclusion of items is certainly discussable.
 
For all you agenda replanners out there, here are some issues to take into account.
 
1)    We have already missed one significant issue off the agenda which was the identity issue. Large number of drafts, large number of posts to the mailing list - that outqualifies most of the other items on the SIP WG list and in every other RAI WG without exception. If we gain an hour on agenda planning, then that item goes back in, or we fall back on our current plan of trying to have some discussion outside the main meeting.
 
2)    The agenda bashing time is also for 1 slide questions on WG drafts outside the main agenda. For example, I believe we have to point out the current status change of domain certs and make sure everyone is OK with that. Also pointing out that 10 minutes is excessive hurts - there are other RAI groups that take longer than this on this item.
 
3)    3 of the items are documents that have recently, or are currently, in WGLC. We want to get these out of the door with completion of open issues raised. If there are WGLC comments that would benefit from face to face time in addition to list discussion to complete those documents, then those documents will get agenda time. invfix already has one issue to raise. Am still waiting for editor feedback on body-handling. record-route-fix is still in WGLC with only one set of comments made so far - where are your comments?
 
4)    SIP is one of the larger groups and therefore the mic queues are longer. If we have scheduled the right question it takes at least 10 minutes for all the people at the mic queue to have one go at making their point, and some of you want more than one go. Attempts at asking people to be more concise don't improve the situation. Therefore one appropriate question at the face-to-face meeting takes 10 minutes to discuss.
 
5)    We didn't schedule the clash with DRINKS. We suffer from the problem that there are too many RAI groups, and some of them ask for more time than they need (and some of them get their requests in late!). People propose sets of groups that can meet in parallel, but seem unable to agree on the split. And then you want core meeting time for BOFs as well. SIP hasn't had time for a navel gazing agenda item for a long long time. It distresses me when SIP has thing it needs to discuss but cannot, and we see other groups scheduling an hour for an agenda item entitled "way forward" or 20 minutes for "remaining direction" without any list discussion or incoming drafts to back it up. I have no intention of asking to cancel the second SIP session. We'll move stuff from one session to the other if it is possible and the move helps people, but that is it.
 
regards
 
Keith

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Hisham Khartabil
	Sent: Thursday, July 17, 2008 12:27 AM
	To: Robert Sparks
	Cc: SIP IETF; Cullen Jennings; Dean Willis
	Subject: Re: [Sip] Draft agenda, SIP at IETF 72

	Having looked at the agenda, I think we can do without the 2nd session. What I mean is that we can remove presentations from the 1st session that we don't think need face time (Robert pointed at a couple) and move the ones requiring face time from the 2nd session to the 1st.
	 
	I don't think we need 10 mins to bash the agenda. I also don't think we need 10mins for draft-ietf-sip-saml-04. We can limit face time to drafts that have open issues to discuss that were not resolveable on the list.
	 
	Thanks,
	Hisham

		This is a really good place to start bashing from. Thanks for going through the pain it takes to put this together.

		
		I also think people across the working group should chime in with what they think
		the three most important _DRAFTS_ to talk about, in person, at this meeting are.
		I strongly suspect there's a surprise or two that will come out of that.
		
		I'll throw my own list in later (because I want to think awhile about what's _not_
		in the proposed agenda), but to help tune things early:

		
		I think we can get away without face time on record-route fix.
		(its unlikely at this late stage that we'll find a crisis to work through there).

		Everybody else: If you hold the token on any of the other drafts and feel you can
		 resolve any issues you currently have the same way, I strongly urge
		 you to propose something similar for your time.

		RjS 

		

			
			• Note that we're still trying to work out how to have the "Identity" discussion
			
			Pretty HTML is at:
			
			Text follows
			
			-----------------
			
			Agenda for SIP at IETF 72, Primary Session, Tuesday July 29, 2008, 1300-1500, Convention 3
			
			Agenda Bash
			Chairs
			10
			
			Using SAML for SIP
			Chairs
			draft-ietf-sip-saml-04
			10

			

			

			Agenda for SIP at IETF 72, Primary Session, Thursday July 31, 2008, 1510-1610, Convention 3
			
			Agenda Bash
			Chairs
			5

			INFO
			Speaker TBD
			draft-burger-sip-info-02

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Jul 2008 13:28:44 +0100

> Behalf Of DRAGE, Keith (Keith)
> Sent: 17 July 2008 13:11
> To: Hisham Khartabil
> These are the slots we think we need to address the issues 
> that have surfaced on the list, and where we believed face to 
> face time would be beneficial, or where we as chairs need 
> guidance on how to progress an item. In that respect the 
> inclusion or exclusion of items is certainly discussable.
>  
> 1)    We have already missed one significant issue off the 
> agenda which was the identity issue. Large number of drafts, 
> large number of posts to the mailing list - that outqualifies 
> most of the other items on the SIP WG list and in every other 
> RAI WG without exception. If we gain an hour on agenda 
> planning, then that item goes back in, or we fall back on our 
> current plan of trying to have some discussion outside the 
> main meeting.
>  
> 2)    The agenda bashing time is also for 1 slide questions 
> on WG drafts outside the main agenda. For example, I believe 
> we have to point out the current status change of domain 
> certs and make sure everyone is OK with that. Also pointing 
> out that 10 minutes is excessive hurts - there are other RAI 
> groups that take longer than this on this item.
>  
> 3)    3 of the items are documents that have recently, or are 
> currently, in WGLC. We want to get these out of the door with 
> completion of open issues raised. If there are WGLC comments 
> that would benefit from face to face time in addition to list 
> discussion to complete those documents, then those documents 
> will get agenda time. invfix already has one issue to raise. 
> Am still waiting for editor feedback on body-handling. 
> record-route-fix is still in WGLC with only one set of 
> comments made so far - where are your comments?
>  
> 4)    SIP is one of the larger groups and therefore the mic 
> queues are longer. If we have scheduled the right question it 
> takes at least 10 minutes for all the people at the mic queue 
> to have one go at making their point, and some of you want 
> more than one go. Attempts at asking people to be more 
> concise don't improve the situation. Therefore one 
> appropriate question at the face-to-face meeting takes 10 
> minutes to discuss.
>  
> 5)    We didn't schedule the clash with DRINKS. We suffer 
> from the problem that there are too many RAI groups, and some 
> of them ask for more time than they need (and some of them 
> get their requests in late!). People propose sets of groups 
> that can meet in parallel, but seem unable to agree on the 
> split. And then you want core meeting time for BOFs as well. 
> SIP hasn't had time for a navel gazing agenda item for a long 
> long time. It distresses me when SIP has thing it needs to 
> discuss but cannot, and we see other groups scheduling an 
> hour for an agenda item entitled "way forward" or 20 minutes 
> for "remaining direction" without any list discussion or 
> incoming drafts to back it up. I have no intention of asking 
> to cancel the second SIP session. We'll move stuff from one 
> session to the other if it is possible and the move helps 
> people, but that is it.

[JRE] I would like to support what Keith says, in particular this last
point (5). Over recent years I have been in sessions of some RAI groups
that have finished early or had relatively large amounts of time for a
small number of topics, yet this never seems to be the case in SIP or
SIPPING, which seem to be time-constrained on a regular basis. Maybe
mailing list activity between meetings should be one of the criteria on
which WGs session durations are determined.

John

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 17 Jul 2008 09:13:04 -0400

> > split.

Nope, not your fault, nor anyone's - and I don't think anyone thinks or claimed it was.  But I think actually that the parallel groups suggested on the RAI mailing list had no dissenters; and regardless, it's really just unfair to make SIP conflict with anything in RAI.  But I'll take this topic to the RAI list.

-hadriel

---

From: Robert Sparks <[email-masked]>
Date: Thu, 17 Jul 2008 09:59:56 -0500

> about the suggestion to nuke them.

I did not offer to remove steps-to-draft - we do need face time on that.

And I mentioned when I scheduled invfix that we could pull it if there  
were no comments before the meeting.

> Keith and I discussed that. I suggested 5. He pointed out that for  
> the last 10 meetings or so, every time we've said 5 we've used 15.
>
>> I also don't think we need 10mins for draft-ietf-sip-saml-04. We  
>> can limit face time to drafts that have open issues to discuss that  
>> were not resolveable on the list.
>>
>
> Here's the open issue with SAML. Are we actually going to do  
> anything with it? The two people who seem to care about the draft  
> have worked at it steadily. Does it have any meaning to the rest of  
> us? Should we publish it? Maybe as experimental?
>
>
> --
> Dean
>
>
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Jul 2008 18:24:50 +0300

>>> not resolveable on the list.

I also do not think we need to discuss the document during the meeting.
There are open issues but they are mostly technical in nature and I
don't expect a lot of feedback on these issues during a face-to-face
discussion with a 10 min slot. 

My impression at previous SIP meetings was that there is not enough time
for some discussions related to the overall direction of the work. Many
of the detailed discussions on drafts, where often only 5 folks know the
subject well enough or care about it enough to join the discussion, are
not really well-spent time given the larger number of folks in the
meeting room. 

Ciao
Hannes

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 17 Jul 2008 18:03:33 +0200

See the response Dean made, but we will come up with a more general post
from the chairs to the SIP list on what we expect to ask here.

Keith 

> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Thursday, July 17, 2008 4:25 PM
> To: ext Robert Sparks; Dean Willis

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Jul 2008 11:39:01 -0500

> which WGs session durations are determined.

Thanks, John.

This is, in large part, why I'd like to see SIP and SIPPING split up  
into more modular working groups. They're ALWAYS time constrained, and  
can never seem to focus on the right subset of their myriad tasks to  
make people happy,

But your post points out one important issue: a large, complex working  
group can pack a meeting agenda more completely with topics than can a  
narrowly-focused WG.

Is this a good thing or a bad thing?

If our goal is to build the most efficiently packed agendae, it's a  
good thing. If, however, our goal is to get issues thoroughly  
discussed and build solid consensus, I suggest it is not.

I'm reminded of the old management saw: "Be careful what you measure,  
because whatever is measured, improves according to the definition of  
that measurement."

SIP and SIPPING have been very effective at efficiently packing agenda  
time. We've even been pretty good at turning out pages of RFC.

Have we been effective at producing clear, simple, well-thought-out  
specifications that are easy to implement? I fear we don't score as  
well on that axis of measurement.

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Jul 2008 11:41:33 -0500

On Jul 17, 2008, at 9:59 AM, Robert Sparks wrote:

>>> 1st session that we don't think need face time (Robert pointed at  
>>> a couple) and move the ones requiring face time from the 2nd  
>>> session to the 1st.
>>>
>>
> And I mentioned when I scheduled invfix that we could pull it if  
> there were no comments before the meeting.
>
>

Okay, that makes sense. The only invfix comments I've seen so far have  
been typographical.

Does anybody have issues of substance to discuss face to face?

---
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Jul 2008 11:45:28 -0500

> not really well-spent time given the larger number of folks in the

So here are the questions:

1) Are we getting anywhere, as a WG, with SAML?

2) Is there some other process we should be using that would be more  
effective, such as a) a design team leading to AD-sponsored individual  
or experimental draft, b) a dedicated working group on identity issues  
such as I have proposed?

3) Does the work NEED to be done at all in the IETF? Is there a  
constituency of implementation, or are we engaging in a purely  
academic exercise? Perhaps academic publication would be a more  
appropriate direction if we lack a constituency.

--
Dean

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 17 Jul 2008 12:53:10 -0400

I have a specific suggestion on this topic.

I would like to see a late night education session:

Explain SAML

Explain how we use SAML with SIP

Show how the whole thing is used to solve a problem.

We might ask on the list who would attend such a session, but I suspect it
may be well attended, and after it, you may get some more feedback.

Brian

> Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Thursday, July 17, 2008 11:25 AM

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Jul 2008 20:05:41 +0300

Hi Dean, 

>> My impression at previous SIP meetings was that there is not enough 
>> time for some discussions related to the overall direction of the 
>> work.
>> Many
>> of the detailed discussions on drafts, where often only 5 folks know 
>> the subject well enough or care about it enough to join the 
>> discussion, are not really well-spent time given the larger 
>number of 
>> folks in the meeting room.
>
>

I am not sure I fully understand the question. 

>
>2) Is there some other process we should be using that would 
>be more effective, such as a) a design team leading to 
>AD-sponsored individual or experimental draft, b) a dedicated 
>working group on identity issues such as I have proposed?

One of the reasons for us being slow with the document was the
dependency on SIP Identity and all the discussions around it during the
past year or so. SIP SAML is dependent on SIP identity, at least it was
up to the current version of the specification. 

Initially, I was hoping that these discussions would come to a
conclusion rather soon. As it turns out this wasn't the case. 

I am currently leaning towards avoiding the dependency with SIP Identity
(by using an independent header) and to ignore the discussions that
happen in SIP identity (SBC issues, E.164 numbers, etc.). 

>3) Does the work NEED to be done at all in the IETF?

Is the question focusing on "should this be done at all" or is the
question "is the IETF the right place for it"? 

> Is there 
>a constituency of implementation, or are we engaging in a 
>purely academic exercise?

There are implementations. Unfortunately from different versions of the
draft -- and the draft has changed over time.

Academic exercise: With the current state of deployment almost all SIP
security mechanisms are to some degree academic rather than enjoying
widespread deployment. 

When starting the work I obviously had a different picture of the next
steps of the SIP deployment in mind. I was hoping for a more end-to-end
usage of SIP for things other than voice. The document builds, with
regard to the functionality, on SIP Identity. If nobody wants SIP
Identity then I doubt that they are extremly interested in the advanced
version of SIP Identity. 

>Perhaps academic publication would 
>be a more appropriate direction if we lack a constituency.

This document is not more or less academic than the rest of the
documents in the SIP working group. I could list many things -- but I
better try to avoid that. Have already upset the GEOPRIV working group
today. 

If you are, however, asking whether the status of the document is
correct (currently PS) and whether it should probably experimental then
I am not so sure. 

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Jul 2008 20:25:38 +0300

In fact I have proposed various tutorial topics to the EDU team, after I
organized a Diameter tutorial. I was turned down. I believe the argument
was something lke "folks participating in the IETF should obtain their
technical knowledge themself"

Ideally, I would like to have one of the SAML authors todo the SAML
tutorial part to have the best possible expertise in the room. I,
however, don't know whether Jeff is attending this IETF meeting.

Alternatively, I could also imagine that a podcast would help to get
things explained quite well. 

>From: ext Brian Rosen [mailto:[email-masked]] 
>Sent: 17 July, 2008 19:53
>To: Tschofenig, Hannes (NSN - FI/Espoo); 'ext Robert Sparks'; 
>'Dean Willis'
>Cc: 'SIP IETF'; 'Cullen Jennings'
>Subject: RE: [Sip] Draft agenda, SIP at IETF 72
>
>We might ask on the list who would attend such a session, but 
>I suspect it may be well attended, and after it, you may get 
>some more feedback.
>
>Brian
>
>> work. Many of the detailed discussions on drafts, where often only 5 
>> folks know the subject well enough or care about it enough 
>to join the 
>> This list is for NEW development of the core SIP Protocol Use 
>> [email-masked] for questions on current sip Use 
>> [email-masked] for new developments on the application of sip
>
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 17 Jul 2008 12:39:27 -0500

>may be well attended, and after it, you may get some more feedback.

I think we did something like this a while ago - and it was attended 
well (maybe 20 or 30), so this idea has merit *BUT* needs to be 
before the SIP preso of SAML (making it Monday evening) to 
effectively tune the SIP preso with what was learned from the 
unofficial bof of SAML...

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Jul 2008 13:25:37 -0500

> I am not sure I fully understand the question.

Is the SIP WG successfully moving the document along, or is it stuck  
in perpetual hold zone? Note that we've slipped the charter milestone  
for this draft several times. This is not the hallmark of good  
management.

> happen in SIP identity (SBC issues, E.164 numbers, etc.).

Please tell me this doesn't mean you're inventing yet another identity  
mechanism for SAML . . .

> question "is the IETF the right place for it"?

The latter. Is the IETF the right place for this work?

> draft -- and the draft has changed over time.

Commercial or widely-deployed free implementations? Or lab  
implementations?
> security mechanisms are to some degree academic rather than enjoying

True. There is some pressure to stop putting effort into security  
mechanisms that are not being deployed.

> Identity then I doubt that they are extremly interested in the  

That's a fair statement.

> correct (currently PS) and whether it should probably experimental  

Well, the bar to publication as experimental is somewhat lower than  
PS. And if we don't expect near-term large-scale deployment,  
experimental may be exactly the right track to be on, as it's also a  
lot easier to change later once the implementation experience teaches  
us what we did wrong.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Jul 2008 21:50:47 +0300

Hi Dean,
 
>Is the SIP WG successfully moving the document along, or is it 
>stuck in perpetual hold zone? Note that we've slipped the 
>charter milestone for this draft several times. This is not 
>the hallmark of good management.

That's indeed true. 

If I ignore the ongoing SIP Identity discussions then I could finish the
document next week. 

>>> effective, such as a) a design team leading to AD-sponsored 
>>> individual or experimental draft, b) a dedicated working group on 
>>> identity issues such as I have proposed?
>>
>> dependency on SIP Identity and all the discussions around it during 
>> the past year or so. SIP SAML is dependent on SIP identity, at least 
>> it was up to the current version of the specification.
>>
>> I am currently leaning towards avoiding the dependency with SIP 
>> Identity (by using an independent header) and to ignore the 
>> discussions that happen in SIP identity (SBC issues, E.164 numbers, 
>> etc.).
>>
>
>Please tell me this doesn't mean you're inventing yet another 
>identity mechanism for SAML . . .

We are re-using the same way how SIP Identity signs the header fields. 
As such, if the raised issues with SBCs & co are real then the problems
would be the same. 

>The latter. Is the IETF the right place for this work?

What other organization would you propose? 

>
>>> Is there
>>> a constituency of implementation, or are we engaging in a purely 
>>> academic exercise?
>>
>> There are implementations. Unfortunately from different versions of 
>> the draft -- and the draft has changed over time.
>

Lab implementations

>True. There is some pressure to stop putting effort into 
>security mechanisms that are not being deployed.

I can understand that. 

>> steps of the SIP deployment in mind. I was hoping for a more end-to- 
>> end usage of SIP for things other than voice. The document builds, 
>> with regard to the functionality, on SIP Identity. If nobody 
>wants SIP 
>> Identity then I doubt that they are extremly interested in the 
>> advanced version of SIP Identity.
>
>That's a fair statement.
>
>
>> correct (currently PS) and whether it should probably experimental 
>> then I am not so sure.
>
>Well, the bar to publication as experimental is somewhat lower 
>than PS. And if we don't expect near-term large-scale 
>deployment, experimental may be exactly the right track to be 
>on, as it's also a lot easier to change later once the 
>implementation experience teaches us what we did wrong.
>
Maybe that's not a bad idea. 

Ciao
Hannes

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Jul 2008 14:03:00 -0500

> If I ignore the ongoing SIP Identity discussions then I could finish  

Would it be reasonable to write the SAML doc against RFC 4474,  
documenting  the issues with RFC 4474 that you've raised, and then  
publish as experimental? Then if we ever get Identity revised, we can  
come back to the SAML document. And it gets one more thing off our  
plate for now.

And I'd still like to have a SAML tutorial.  We've had lunchtime  
tutorials on things like XCAP in the past that were well attended. All  
we need is a sponsor (asking people to pay for buffet lunch doesn't  
work) or a facility that is amenable to "brown bag" lunches in a  
conference room. And of course, we need somebody to organize and  
present said material . . .

--
Dean

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Jul 2008 22:14:12 +0300

Hi Dean, 

>> If I ignore the ongoing SIP Identity discussions then I could finish 
>> the document next week.
>>
>
>
>documenting  the issues with RFC 4474 that you've raised, and 
>then publish as experimental? Then if we ever get Identity 
>revised, we can come back to the SAML document. And it gets 
>one more thing off our plate for now.

Sure. That's essentially what we currently have in the document. 
Still, there is one unresolved issue we never really figured out how to
fix: "wrt RFC4474 'absoluteURI' in Identity-Info header field and
SIP-SAML implications"
http://www.tschofenig.priv.at:8080/saml-sip/issue12

This let us wonder whether we should maybe go for a separate header. 

>
>And I'd still like to have a SAML tutorial.  We've had 
>lunchtime tutorials on things like XCAP in the past that were 
>well attended. All we need is a sponsor (asking people to pay 
>for buffet lunch doesn't
>work) or a facility that is amenable to "brown bag" lunches in 
>a conference room. And of course, we need somebody to organize 
>and present said material . . .

I just dropped a mail to Jeff to see whether he is in Dublin. He
informed me that he hasn't received an OK from his boss yet. Let's see.
I can also give a tutorial myself but there is certainly a difference
between the person who wrote the SAML spec and the person who read it. 

Ciao
Hannes

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Jul 2008 20:24:32 +0100

> Behalf Of Dean Willis
> Sent: 17 July 2008 20:03
> To: Tschofenig, Hannes (NSN - FI/Espoo)
> Subject: [Sip] saml proposal
> 
> 
> > the
[JRE] Sounds reasonable. I know SAML is becoming important in the
applications world and it seems very likely that integration with SIP
will become important sometime in the future. However, I don't see the
drivers at present.

> present said material . . .
[JRE] I would try to attend such a session. One thing I am missing from
the draft is a set of real life use cases - I guess these were in RFC
4484, but something to link the two together would be good, i.e., how
exactly SIP/SAML would operate to solve each of these. Maybe it is just
me, but if you were to explain that in a tutorial it would be helpful.

John

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Jul 2008 22:28:08 +0300

>[JRE] I would try to attend such a session. One thing I am 
>missing from the draft is a set of real life use cases - I 
>guess these were in RFC 4484, but something to link the two 
>together would be good, i.e., how exactly SIP/SAML would 
>operate to solve each of these. Maybe it is just me, but if 
>you were to explain that in a tutorial it would be helpful.

In previous versions of the draft we had short descriptions of these
scenarios. 

We later removed them and put them in more detail in separate drafts
that also define the attributes. We did not update these drafts; they
all expired since we wanted to get the main spec done first before we
define attributes for the different scenarios. 

Ciao
Hannes

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jul 2008 16:08:09 -0400

I would also suggest the same list. And in particular, if we don't make 
a lot of progress on INFO and rfc4474, we have wasted our time. Those 
two IMHO should cover 75% of our meeting time. Having a bunch of 10 
minute presentations, each of which is on a topic that only three people 
care about, is not a good use of everyones time. Those two topics 
clearly have big impact on SIP as a whole and are of broad interest.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Jul 2008 19:33:58 -0500

> This let us wonder whether we should maybe go for a separate header.

Ah. I understand, I think. Check me:  SIP-SAML  doesn't work with RFC  
4474 because the Identity-Info header field of RFC 4474 has as its  
value a URI that points to a cert, and SIP-SMAL needs it to point to a  
SAML assertion.

So you're proposing a new header like "SAML-Info" that would have as  
its value a URI that points to a SAML assertion?

This could be done easily enough in an Experimental (although current  
3427 rules mean it would be P-SAML-Info, note that Keith has a draft  
out on revising 3427). It would certainly be easier than revising RFC  
4474.

If you went that route, you might note that the requirement for a  
separate header to reference the SAML assertion is an artifact of RFC  
4474, and that it could be done away with if a revision of RFC 4474  
allowed the Identity-Info header field to reference a SAML assertion.

Are we done with this now?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Jul 2008 19:39:41 -0500

On Jul 17, 2008, at 3:08 PM, Jonathan Rosenberg wrote:

> I would also suggest the same list. And in particular, if we don't  
> make a lot of progress on INFO and rfc4474, we have wasted our time.  
> Those two IMHO should cover 75% of our meeting time. Having a bunch  
> of 10 minute presentations, each of which is on a topic that only  
> three people care about, is not a good use of everyones time. Those  
> two topics clearly have big impact on SIP as a whole and are of  
> broad interest.

I don't disagree. In fact, I think you are absolutely right.

But while they are within the scope of our charter, neither INFO nor  
revision of RFC 4474 is a milestone on our charter. The other things  
we currently have on the agenda (except "keep") ARE milestone items.  
And we're LATE on most of them!

So either our charter is wrong, or we're out-of-scope in our interests.

I've previously tried to charter deliverables on both items and been  
shot down.

So what do you think we should do?

---

From: Dean Willis <[email-masked]>
Date: Fri, 18 Jul 2008 01:03:15 -0500

But the author Christer said:

> As I said earlier, I see no major issue with 199 at this point which  
> would require face-to-face discussions. I could give a status  
> update, but that would only take about 5 minutes.

So, which is it? Robert, are you aware of any specific issues? Or do  
you just have general concerns that we aren't getting closure on the  
list?

--
Dean, the agenda mangling cochair

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Jul 2008 10:03:18 +0100

Dean,

So these milestone items we are late on, how many of them are late
because they are held up waiting for face-to-face discussion?

John 

> Sent: 18 July 2008 01:40
> To: Jonathan Rosenberg

---

From: "Andreas Pashalidis" <[email-masked]>
Date: Fri, 18 Jul 2008 12:42:54 +0200

Dear James, all,

We apologise for not clearly stating the purpose of draft-pashalidis-sip-saml-00 and its key differences with draft-ietf-sip-saml-04.txt - we should have done that.

> [...] making me question why the new ID was written [...] [...] asking 
> if you can explain the need for this second SAML in SIP ID [...]

We wrote this ID having in mind the following main use case (among others).

The user wants to register with his SIP proxy, and is then put in contact with his IdP to perform authentication. 
The IdP provides authentication (as a service) but is not itself a SIP proxy. In general, the IdP provides authentication and user attributes to a multitude of service providers (including SIP proxies, webservers, and other types of service).

In other words, we would like to have a solution where the authentication is offloaded to an IdP, and where the relevant messages are SAML messages. We do not think that this competes or interferes with other user authentication mechanisms for SIP in any way. The reason why would like to have the messages encoded in SAML is because this is likely to maximise overall interoperability (and hence, positively affect overall user experience) since one can make the system work with any SAML-based IdP with limited effort. Having a SIP proxy accept a SAML authentication assertion means that we can have Single Sign-On *across* application domains (e.g. across HTTP and SIP) - this is what we would like to have. 

The main differences of draft-pashalidis-sip-saml-00 and draft-ietf-sip-saml-04.txt are as follows (according to our current, perhaps limited, understanding).

1. the former addresses the main use case above; the latter doesn't because it only allows the exchange of attributes (and "trait-based authorization" 
somehow conveys the message that the user's authentication status is NOT regarded as an attribute, i.e. explicitly excluded) 2. the former focuses on the SIP REGISTER method; the latter focuses on the SIP INVITE method 3. (as a side-effect of 2:) the former focuses of the provision of user authentication and attributes  to the SIP proxy of the *caller*; the latter focuses on the provision of attributes to the *callee* (or its SIP proxy) 4. the former specifies how to carry SAML over SIP, in a fashion that is similar to the way that HTTP has been specified to carry SAML. The advantage of SIP carrying SAML messages is that SIP UAs or SIP proxies do not need to implement two different transport protocols (SIP and HTTP), as is currently required by draft-ietf-sip-saml-04.txt. However, this could be easily added to the existing WG doc as well (at least we think so).

As to the why we submitted this draft, we wanted to support these activities which we think are important and fit to our current use of SIP and SAML. The current WG doc has a scope founded by rfc4474 and rfc4484 which does not cover all the use cases we'd like. Perhaps those are outside the scope of the WG, we think that's the discussion we'd like to have. 
The draft should be seen as input on this topic rather than competing or a statement of disagreement.

The other reason to submit this draft was to try and rekindle the discussion on the use of SAML in the context of SIP (it's recently been rekindled enough :)). We believe it is very important to have a consistent view on SSO and attribute exchange - a view that is consistent across platforms and, as much as possible, application domains.

Best Regards,
Andreas & Joao

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Robert Sparks <[email-masked]>
Date: Fri, 18 Jul 2008 09:40:33 -0500

I have specific issues which I will bring to the list before the  
meeting.
If I am the only person with issues to discuss, then any face time  
needed to close this can be with Christer in the hall.

This is part of why I want people to send in what the three _drafts_  
they think are the most important to talk about
(I re-emphasize draft here - its different from topics - we know we  
have some large issues to discuss, but we need
to give the editors, and frankly the reviewers, more insight into how  
much constituency each topic really has at
the moment).

On Jul 18, 2008, at 1:03 AM, Dean Willis wrote:

>> As I said earlier, I see no major issue with 199 at this point  
>> which would require face-to-face discussions. I could give a status

---

From: Robert Sparks <[email-masked]>
Date: Fri, 18 Jul 2008 09:56:06 -0500

On Jul 17, 2008, at 7:39 PM, Dean Willis wrote:

>> make a lot of progress on INFO and rfc4474, we have wasted our  
>> time. Those two IMHO should cover 75% of our meeting time. Having a  
>> bunch of 10 minute presentations, each of which is on a topic that  
>> only three people care about, is not a good use of everyones time.  
>> Those two topics clearly have big impact on SIP as a whole and are  
>> of broad interest.
>

You seem to be assuming that spending meeting time on them will make  
them less late. For the most part, that's only going to be true when  
there's some blocking discontent that an in-face meeting can resolve.  
Most of the stuff that you are expressing frustration over isn't in  
that state.

> So either our charter is wrong, or we're out-of-scope in our  

This is a false dichotomy, even if both statements turn out to be true.

I think, rather, that we have a lot of chartered items that just need  
to finish. They may need management to make sure review happens. They  
may need editors to punt them to somebody with more time. But the  
majority _aren't_ cross-community controversial. The in-the-room in- 
face meeting time needs to focus on things that are.

And quite often, the discussions requiring face time to resolve are  
exactly the kinds of things that result in new milestones and  
occasionally revised charters.

> I've previously tried to charter deliverables on both items and been  

And yet, you're one of the first to complain that the WG/ IETF won't  
say NO. :)

(Lest someone read more into that than I intend, I am not trying to  
say no to the info or identity discussions.)

---

From: Dean Willis <[email-masked]>
Date: Fri, 18 Jul 2008 12:37:42 -0500

> because they are held up waiting for face-to-face discussion?

That's a good question. I'm having a hard time telling, since some  
(like SAML) don't seem to get a lot of list discussion either.

Let's take a look:

Jun 2007 Mechanism and guidelines for outbound connections to IESG
	-- Waiting on me

Jul 2007 Example security flows to WGLC
	-- Waiting on author, I think

Jul 2007 Location Conveyance with SIP to IESG
	-- Waiting on face-to-face, but in GEOPRIV

Aug 2007 Connection reuse mechanism to IESG
	-- Waiting on Keith

Sep 2007 Session Policies to IESG
	-- Waiting on Keith

Sep 2007 Example security flows to IESG
	-- Waiting on WGLC

Sep 2007 Using SAML for SIP to WGLC
	-- Not sure, maybe F2F?

Nov 2007 Requirements for media keying to IESG
	-- Waiting on me

Dec 2007 Extensions to SIP UA Profile Delivery Change Notification to  
IESG
	-- Hey, this one is done! I've just notified the secretariat. Yay!

Dec 2007 Using SAML for SIP to IESG
	-- Waiting on the WGLC, which may be waiting on F2F

Dec 2007 Extension for use in etags in conditional notification to IESG
	-- Waiting on the author. Somebody buy Aki a beer!

Dec 2007 Delivering request-URI and parameters to UAS via proxy to WGLC
	-- DEFINITELY waiting on F2F
	
Dec 2007 Establishment of secure media sessions using DTLS-SRTP to WGLC
	-- Waiting on author. Somebody buy EKR a babysitter!

Feb 2008 Identify requirements for test matrix to move SIP to Draft Std
	-- Waiting on F2F. On current agenda.

Feb 2008 Delivering request-URI and parameters to UAS via proxy to IESG
	-- Waiting on WGLC, which is waiting on F2F

Feb 2008 Revise charter
	-- Waiting on some decisions WRT Identity, which is probably F2F

Feb 2008 Establishment of secure media sessions using DTLS-SRTP to IESG
	-- Waiting on WGLC, which is waiting on author

Apr 2008 MIME body handling in SIP to IESG
	--  I'm not exactly sure.

Apr 2008 Essential corrections to RFC 3261 (1st batch) to IESG
	-- May or may not need F2F for invix

May 2008 Mechanisms for UA initiated privacy to WGLC
	-- Waiting for F2F

Jul 2008 Mechanisms for UA initiated privacy to IESG
	-- waiting for WGLC, which is waiting F2F

Aug 2008 Guidelines for double route recording to IESG
	-- In WGLC from July 16, may or may not need F2F

Sep 2008 X.509 Certificates for TLS use in SIP to IESG
	-- Waiting on Keith

Sep 2008 X.509 extended key usage for SIP to IESG
	-- Waiting on Keith

Sep 2008 Termination of early dialog prior to final response to WGLC
	-- Waiting on F2F

Nov 2008 Termination of early dialog prior to final response to IESG
	-- Waiting on WGLC, hence on F2F

So, it looks like we MAY require F2F time to advance the following:

SAML
Record-Route Fix?
invfix (Essential Corrections #1)?
Delivery of URI and Parameters to UAS Through Proxy
Requirements for Test matrix to Move to Draft
Revise Charter
Body Handling?
UA Initiated Privacy
Termination of Early Dialog (which isn't "late" yet)

The three "?" items (Record-Route, invfix, and Body Handling) are all  
in a WGLC cycle, so we don't know yet whether we he have critical F2F  
issues.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 18 Jul 2008 11:51:17 -0700

On Jul 17, 2008, at 24:31 , Hadriel Kaplan wrote:

> I'm also very surprised SIP can be scheduled in conflict with any  
> other RAI WG, especially a brand new one. :(

All the RAI groups that requested more than one session had their  
second session scheduled in conflict with another meeting. If anyone  
wants to tell me what groups should be closed to make more time for  
SIP, or what WG needs less time than they are currently getting, well  
that would be very useful input to me. Wishing there was more time is  
something the IESG is working on for IETF 73. We are trying to  
consider how to run meetings on Friday afternoon to provide more time.  
No final decisions have been made on this but you can expect to hear  
more about this in Dublin before any decisions get made.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 18 Jul 2008 22:59:21 +0300

>	-- Waiting on face-to-face, but in GEOPRIV

This one is interesting: I believe that it was not a good idea to have
the document in SIP when most of the controversial discussions happen in
GEOPRIV, i.e. the encoding wasn't been the problem --  the semantic was.

Spreading topics over different groups always makes the process more
complicated. 

Ciao
Hannes

PS: I also have to add that GEOPRIV clearly isn't the easiest group I
have dealt with. Hence, the delay is probably not so surprising. 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Robert Sparks <[email-masked]>
Date: Fri, 18 Jul 2008 15:09:42 -0500

> Spreading topics over different groups always makes the process more

Interesting coincidence with my insanely-cross-posted message of just  
now.

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 18 Jul 2008 17:01:32 -0500

At 01:51 PM 7/18/2008, Cullen Jennings wrote:
>  Wishing there was more time is

this is already being discussed on the ietf.ietf.org list -- btw, 
most like the idea, some want a specific measurement of success 
(silly them) - but are also in favor of the experiment.

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 18 Jul 2008 17:04:45 -0500

>GEOPRIV, i.e. the encoding wasn't been the problem --  the semantic was.

yeah *but* there is thing about the ID that creates new SIP headers, 
and header parameters and a new response code... that makes it be in 
SIP, according to an existing RFC (4485 I think)

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 18 Jul 2008 17:05:44 -0500

>have dealt with. Hence, the delay is probably not so surprising.

amen to that one, brother

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sat, 19 Jul 2008 02:29:25 +0200

RFC 3427 placed location conveyance correctly in SIP.

There was a requirements exercise outside SIP, which preceded it, which
apparently some key players did not buy into. But not buying into the
requirements documents at the time they were written is apparently a
general GEOPRIV problem.

The semantic of the current GEOPRIV draft should have been written into
the location conveyance requirements draft before it was endorsed by the
working group that produced it. Then we would not have had this
continual reversal of opinion.

We seem to have too many people who think protocol design consists of
listing all the codepoint values they can think of, and then getting
IETF to endorse it. Use cases and requirements are a key part and the
charters of various RAI groups make clear provision for those drafts to
be written, and the work then passed over.

Keith 

> Behalf Of James M. Polk
> Sent: Friday, July 18, 2008 11:05 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo); ext Dean Willis; Elwell, John
> Cc: SIP IETF
> Subject: Re: [Sip] Late Milestones (was Re: Draft agenda, SIP 
> at IETF 72)
> 
> >the document in SIP when most of the controversial 
> discussions happen 
> >in GEOPRIV, i.e. the encoding wasn't been the problem --  
> the semantic was.
> 
> yeah *but* there is thing about the ID that creates new SIP 
> headers, and header parameters and a new response code... 
> that makes it be in SIP, according to an existing RFC (4485 I think)
> 
> [email-masked] for questions on current sip

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 18 Jul 2008 23:47:13 -0400

> From: Cullen Jennings [mailto:[email-masked]]
>
> second session scheduled in conflict with another meeting.

Having the second slot of a multi-slot WG meeting conflict with another WG is missing the point if the other WG it conflicts with is not a multi-slot one.  What it's doing then is penalizing the other WG.  For example, it is unfair to DRINKS that SIP conflicts with it - *DRINKS* didn't ask for two slots.

To reiterate what I've posted on the RAI mailing list, I grok the overlap problem, I think.  What I suggest, though, is that the overlap decision be implemented differently.  Instead of just forcing any RAI WG that needs 2 slots to have its second slot conflict, choose the conflicts based on topic relativity.  One proposal I posted was to break the groups into topic threads, such that different threads could conflict but not with the globally relevant groups (like SIP).

Let me put it a different way - what if the second slot for SIP conflicted with P2PSIP?

-hadriel

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sun, 20 Jul 2008 18:34:07 +0200

For the following two:

There has been a major change in domain-certs since WGLC which I am
waiting for enough people in the WG to read (and if necessary to object
to).

There is a potential further change coming in based on comments from
PKIX - see Vijay's message of a few days back.

And having worked my way through both of them, I will be trying to take
some time in Dublin with the editor's to clean a few things up!

Regards

Keith 

> Sent: Friday, July 18, 2008 6:38 PM
> To: Elwell, John
> Cc: SIP IETF
> Subject: [Sip] Late Milestones (was Re: Draft agenda, SIP at IETF 72)
> 
> 
> That's a good question. I'm having a hard time telling, since 
> some (like SAML) don't seem to get a lot of list discussion either.
> 
> 
> Let's take a look:
> 
> Dec 2007 Extensions to SIP UA Profile Delivery Change 
> Notification to IESG
> Requirements for Test matrix to Move to Draft Revise Charter 
> Body Handling?
> UA Initiated Privacy
> The three "?" items (Record-Route, invfix, and Body Handling) 
> are all in a WGLC cycle, so we don't know yet whether we he 
> have critical F2F issues.
> 
> --
> Dean
>

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 20 Jul 2008 09:37:46 -0700

On Jul 18, 2008, at 8:47 PM, Hadriel Kaplan wrote:

> Having the second slot of a multi-slot WG meeting conflict with  
> another WG is missing the point if the other WG it conflicts with is  
> not a multi-slot one.  What it's doing then is penalizing the other  
> WG.  For example, it is unfair to DRINKS that SIP conflicts with it  
> - *DRINKS* didn't ask for two slots.
>

Agree - this was considered. If this had seemed unworkable for the  
DRINKS folks, we would not have done this.

>
> To reiterate what I've posted on the RAI mailing list, I grok the  
> overlap problem, I think.  What I suggest, though, is that the  
> overlap decision be implemented differently.  Instead of just  
> forcing any RAI WG that needs 2 slots to have its second slot  
> conflict, choose the conflicts based on topic relativity.  One  
> proposal I posted was to break the groups into topic threads, such  
> that different threads could conflict but not with the globally  
> relevant groups (like SIP).
>

Of course the overlap is considered - but looking at it as the overlap  
of everything SIP does and everything  DRINKS does it leads one to the  
wrong conclusion. A better way to look at it is, can the SIP chairs  
arrange the material they have for this specific meeting for three  
hours such that the stuff they put in the 1/3 of time that overlaps  
with DRINKS does not have large overlap with DRINKS.  When you look at  
who is participating in the discussion around the items in SIP right  
now and the work in DRINKS, I think this is possible. It is certainly  
not ideal - a lot of permutations and combinations were looked at -  
none were good.

The basic problem is that to create a bunch of time for new work in  
RAI, we need to get some of the things currently using time to use  
less time - that can be done by finishing work or deciding that work  
is not longer a priority and removing it.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 21 Jul 2008 14:51:56 -0500

> PKIX - see Vijay's message of a few days back.

Keith: Regarding draft-ietf-sip-eku, we have received word from
PKIX that the text in the current version of the draft (-02)
can proceed as is.  So technically, there will not be any
changes in what is described in -02.

> some time in Dublin with the editor's to clean a few things up!

Scott and I can meet up with you in Dublin to get your comments on
cleaning it up, but I suspect that any cleanup now will be more
editorial in nature.

Thank you.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip