Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff

From: "Andrew Allen" <[email-masked]>
Date: Thu, 16 Apr 2009 20:27:22 -0400

My understanding of the outcome in San Francisco was that target-uri would update 4244 and 4244bis would be worked on in parallel and potentially obsolete both 4244 and target-uri. 

Whatever is developed for target-uri ought to be able to be incorporated in 4244bis. If 4244 progresses well then target-uri may not need ultimately to be published separately. 

I am afraid that the security question to be addressed by 4244bis is a big can of worms that is likely to be a long discussion. Is there a reason why target-uri can't progress under the current History-Info security framework? Is the security solution for 4244 actually technically broken or is it just that people don't implement it?

There is not a draft dependecy on target-uri for GRUU but it was clearly identified during GRUU development that a lot of use cases for GRUU really need to know that the Request was addressed to a particular GRUU and without target-uri that functionality cannot be achieved. 

________________________________

From: Mary Barnes <[email-masked]> 
To: Andrew Allen; [email-masked] <[email-masked]> 
Cc: [email-masked] <[email-masked]> 
Sent: Thu Apr 16 18:03:42 2009
Subject: RE: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff 

A few comments below [MB]. 

________________________________

From: Andrew Allen [mailto:[email-masked]] 
Sent: Thursday, April 16, 2009 4:50 PM
To: Barnes, Mary (RICH2:AR00); [email-masked]
Cc: [email-masked]
Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff

My understanding was that we would move forward with both drafts as WG items.

My understanding was that in Dublin Target-uri was adopted as a SIP WG item. I don't want to see 4244bis become a dependency for the target-uri work which is urgently needed to solve some GRUU related issues. 

[MB] Per my original comments below, the changes for a target-uri solution based on 4244 is actually more work than putting the normative functionality in 4244bis - that's because you still need to address security, privacy, how it is processed by a UAC, Proxy and UAS. You would then need duplicate text to set the context, etc. and that text would be identical to what's in 4244 OR you'd be breaking existing implementations and there are some of those. Now, we did have one reasonable suggestion as to adding a recommendation that the Privacy not be applied to the entire message as that limits proxy functionality - that's important for target-uri, but it's also likely an oversight in the original 4244. [/MB]  

If 4244bis is ready when target-uri is then we can talk about rolling the two into one but I have concerns that 4244bis will take considerably longer than target-uri based on the discussion in San Fran.  

[MB] Nope - as I noted earlier, I think the discussion was confounded because people were talking about changes to 4244bis (History-Info) that were well beyond what is required for target-uri - i.e., paring down the functionality to only collect the desired entries, which doesn't save a bit of work because you still have to recognize the conditions under which you drop the entries.  Please listen to Francois' response to Hadriel's suggestion in the audio - it's towards the end. Also, the same security issues apply - when we completed 4244, the security section was carefully crafted based on security thoughts at the time. Those have changed (obviously) and if they are problematic in 4244bis, they would be a problem for the target-uri usage of 4244, which has the same security requirements as core 4244.  [/MB]

Target-uri has been needed really for GRUU for more then 2 years and is fairly straightforward. I don't think we should risk delaying that work waiting for 4244bis which seems to contain a number of issues we don't have consensus on yet. 

[MB] The other changes to 4244bis are minor as compared to the normative functionality that needs to be added to the document to support target-uri. Please look at the diff.  I also don't see the GRUU dependency - can you please clarify?  I know GRUU is waiting for Outbound (I promise I will give up if 4244bis reaches a point where it is taking longer to finish than Outbound) and that the gruu-reg-event pkg is waiting for GRUU.  [/MB] 

That was my understanding of the approach we determined in San Francisco.

________________________________

From: [email-masked] <[email-masked]> 
To: Hans Erik van Elburg <[email-masked]> 
Cc: [email-masked] <[email-masked]> 
Sent: Thu Apr 16 17:34:57 2009
Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff 

No - the discussion for 4244(bis) (extracted below) was entirely in the context of the discussion for the target-uri document. You can go back and listen to the audio to verify that.  And, I've stated long before IETF-73 that it would be fairly straightforward to update 4244 to accomodate the target-uri requirements and while we were doing that, there were a few other fixes we could do. 
 
Mary. 

________________________________

From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Thursday, April 16, 2009 4:22 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Dean Willis; [email-masked]
Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE: [Sip] SIPCORE -- If you're not subscribed, you're missing stuff

Hi Mary,

I believe that in the absence of consensus as the minutes correctly state, the the target-uri document should remain the WG document for the target-uri deliverable.

4424bis has another purpose, namely to fix the 4424. If at a certain moment in time it turns out that 4424bis is the appropriate document to contain normative text for target uri delivery then we can always decide to do so. At this stage it is to early to take that decision, given the confused state of the target-uri discussion.

/Hans Erik van Elburg

On Thu, Apr 16, 2009 at 10:02 PM, Mary Barnes <[email-masked]> wrote:

	I'm suggesting to change the decision from IETF-73 and accept the more
	recent realization that including normative text in another document
	rather than 4244bis will be fraught with error and I can't see how that
	is a good idea from a development perspective - you can't just implement
	the target-uri document.
	
	Now, I don't have a problem if folks can accept that the target-uri
	document might change such that the normative functionality is in
	4244bis.   And, this was consensus from IETF-73 per those minutes:
	"Issue: Normative behavior update for RFC 4244
	
	Consensus noted to revise RFC 4244, and fix some other known problems
	with it at teh same time. MAry Barnes volunteered to edit the
	document."
	
	So, there is a conflict in terms of accepting target-uri document as the
	only deliverable for that milestone in the IETF-73 meeting.
	
	Mary.

	-----Original Message-----
	From: Dean Willis [mailto:[email-masked]]
	Sent: Thursday, April 16, 2009 2:36 PM
	To: Barnes, Mary (RICH2:AR00)
	Cc: [email-masked]
	Subject: Re: [sipcore] [Sip] SIPCORE -- If you're not subscribed, you're
	missing stuff

	On Apr 16, 2009, at 2:27 PM, Mary Barnes wrote:
	
	> I have an issue with the target-uri document being proposed as the WG
	> document for the target-uri deliverable. This was not the consensus in
	
	> SF per my recollection (which may be biased) nor per the SIP WG
	> minutes:
	> http://www.ietf.org/proceedings/09mar/minutes/sip.html
	>
	> Which state:
	> "Issue: Progress 4244bis, target-uri draft, or both?
	> In the absence of a clear consensus, the chairs proposed that both
	> documents proceed and we'll hope that further discussion gives us a
	> consensus."
	>
	> Now, I realize that there are now new chairs, but I don't think that
	> should change the WG consensus from the SIP WG session.
	
	However, the minutes from IETF 73 read:
	
	Topic: URI and Parameter Delivery
	Led by Jonaathan Rosenberg
	Slides presented
	http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-delivery-00.txt
	
	...
	
	Poll: Shall WG adopt this draft towards our charter deliverable on the
	topic? Chairs reported a strong consensus to do so.
	So which WG consensus of which SIP WG session do you not want to change?

	>
	> It was my understanding from the minutes that the discussion was to
	> continue as to whether we would merge the two documents or agree one
	> or the other as a WG deliverable.
	>

	That's also consistent with my notes from SIP at 74.
	
	My best guess is that RFC 4244bis goes forward, and that target-uri-
	delivery turns into a "How to use H-I to meet the URI delivery use
	cases" document.
	
	--
	Dean

	
	_______________________________________________
	sipcore mailing list
	[email-masked]
	https://www.ietf.org/mailman/listinfo/sipcore

--------------------------------------------------------------------- 
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 16 Apr 2009 20:29:45 -0500

Hi Andrew,
 
Thanks for the clarification. On the security point,  if the WG would
agree that the same security considerations as in 4244 apply to
target-uri - i.e., no more/no less, then yes, there's not an issue. As I
understand it, the issue is that the bar is quite high in 4244 (e.g.,
TLS mandated), so the answer is that no one that has implemented it
likely meets that security requirement.  And, yes it is a big can of
worms, just like any other security discussion is for SIP.  But, what
I'm trying to say is that if folks do believe the current security in
4244 is not adequate or implementable, then target-uri would have the
same issue and thus need to address any concerns with 4244 security to
be complete. Based on my experience with more recent RFCs, the bar for
the security requirements and considerations for documents is
significantly higher than it was when 4244 was published. 
 
Thus,  there is no difference at all between progressing 4244bis versus
target-uri, except that I think it is actually more difficult to
properly define the normative processing for target-uri in a separate
document than rely on the existing structure and text in 4244.  
 
Mary.

From: Andrew Allen [mailto:[email-masked]] 
Sent: Thursday, April 16, 2009 7:27 PM
To: Barnes, Mary (RICH2:AR00); [email-masked]
Cc: [email-masked]
Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was
RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff

My understanding of the outcome in San Francisco was that target-uri
would update 4244 and 4244bis would be worked on in parallel and
potentially obsolete both 4244 and target-uri. 

Whatever is developed for target-uri ought to be able to be incorporated
in 4244bis. If 4244 progresses well then target-uri may not need
ultimately to be published separately. 

I am afraid that the security question to be addressed by 4244bis is a
big can of worms that is likely to be a long discussion. Is there a
reason why target-uri can't progress under the current History-Info
security framework? Is the security solution for 4244 actually
technically broken or is it just that people don't implement it?

There is not a draft dependecy on target-uri for GRUU but it was clearly
identified during GRUU development that a lot of use cases for GRUU
really need to know that the Request was addressed to a particular GRUU
and without target-uri that functionality cannot be achieved. 

From: Mary Barnes <[email-masked]> 
To: Andrew Allen; [email-masked] <[email-masked]> 
Cc: [email-masked] <[email-masked]> 
Sent: Thu Apr 16 18:03:42 2009
Subject: RE: [sipcore] Target-uri document as SIPCORE WG document? (was
RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff 

From: Andrew Allen [mailto:[email-masked]] 
Sent: Thursday, April 16, 2009 4:50 PM
To: Barnes, Mary (RICH2:AR00); [email-masked]
Cc: [email-masked]
Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was
RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff

My understanding was that we would move forward with both drafts as WG
items.

My understanding was that in Dublin Target-uri was adopted as a SIP WG
item. I don't want to see 4244bis become a dependency for the target-uri
work which is urgently needed to solve some GRUU related issues. 

[MB] Per my original comments below, the changes for a target-uri
solution based on 4244 is actually more work than putting the normative
functionality in 4244bis - that's because you still need to address
security, privacy, how it is processed by a UAC, Proxy and UAS. You
would then need duplicate text to set the context, etc. and that text
would be identical to what's in 4244 OR you'd be breaking existing
implementations and there are some of those. Now, we did have one
reasonable suggestion as to adding a recommendation that the Privacy not
be applied to the entire message as that limits proxy functionality -
that's important for target-uri, but it's also likely an oversight in
the original 4244. [/MB]  

If 4244bis is ready when target-uri is then we can talk about rolling
the two into one but I have concerns that 4244bis will take considerably
longer than target-uri based on the discussion in San Fran.  

[MB] Nope - as I noted earlier, I think the discussion was confounded
because people were talking about changes to 4244bis (History-Info) that
were well beyond what is required for target-uri - i.e., paring down the
functionality to only collect the desired entries, which doesn't save a
bit of work because you still have to recognize the conditions under
which you drop the entries.  Please listen to Francois' response to
Hadriel's suggestion in the audio - it's towards the end. Also, the same
security issues apply - when we completed 4244, the security section was
carefully crafted based on security thoughts at the time. Those have
changed (obviously) and if they are problematic in 4244bis, they would
be a problem for the target-uri usage of 4244, which has the same
security requirements as core 4244.  [/MB]

Target-uri has been needed really for GRUU for more then 2 years and is
fairly straightforward. I don't think we should risk delaying that work
waiting for 4244bis which seems to contain a number of issues we don't
have consensus on yet. 

[MB] The other changes to 4244bis are minor as compared to the normative
functionality that needs to be added to the document to support
target-uri. Please look at the diff.  I also don't see the GRUU
dependency - can you please clarify?  I know GRUU is waiting for
Outbound (I promise I will give up if 4244bis reaches a point where it
is taking longer to finish than Outbound) and that the gruu-reg-event
pkg is waiting for GRUU.  [/MB] 

That was my understanding of the approach we determined in San
Francisco.

From: [email-masked] <[email-masked]> 
To: Hans Erik van Elburg <[email-masked]> 
Cc: [email-masked] <[email-masked]> 
Sent: Thu Apr 16 17:34:57 2009
Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was
RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff 

No - the discussion for 4244(bis) (extracted below) was entirely in the
context of the discussion for the target-uri document. You can go back
and listen to the audio to verify that.  And, I've stated long before
IETF-73 that it would be fairly straightforward to update 4244 to
accomodate the target-uri requirements and while we were doing that,
there were a few other fixes we could do. 
 
Mary. 

From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Thursday, April 16, 2009 4:22 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Dean Willis; [email-masked]
Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was
RE: [Sip] SIPCORE -- If you're not subscribed, you're missing stuff

Hi Mary,

I believe that in the absence of consensus as the minutes correctly
state, the the target-uri document should remain the WG document for the
target-uri deliverable.

4424bis has another purpose, namely to fix the 4424. If at a certain
moment in time it turns out that 4424bis is the appropriate document to
contain normative text for target uri delivery then we can always decide
to do so. At this stage it is to early to take that decision, given the
confused state of the target-uri discussion.

/Hans Erik van Elburg

On Thu, Apr 16, 2009 at 10:02 PM, Mary Barnes <[email-masked]>
wrote:

	I'm suggesting to change the decision from IETF-73 and accept
the more
	recent realization that including normative text in another
document
	rather than 4244bis will be fraught with error and I can't see
how that
	is a good idea from a development perspective - you can't just
implement
	the target-uri document.
	
	Now, I don't have a problem if folks can accept that the
target-uri
	document might change such that the normative functionality is
in
	4244bis.   And, this was consensus from IETF-73 per those
minutes:
	"Issue: Normative behavior update for RFC 4244
	
	Consensus noted to revise RFC 4244, and fix some other known
problems
	with it at teh same time. MAry Barnes volunteered to edit the
	document."
	
	So, there is a conflict in terms of accepting target-uri
document as the
	only deliverable for that milestone in the IETF-73 meeting.
	
	Mary.

	-----Original Message-----
	From: Dean Willis [mailto:[email-masked]]
	Sent: Thursday, April 16, 2009 2:36 PM
	To: Barnes, Mary (RICH2:AR00)
	Cc: [email-masked]
	Subject: Re: [sipcore] [Sip] SIPCORE -- If you're not
subscribed, you're
	missing stuff

	

	
	
	...
	
	Poll: Shall WG adopt this draft towards our charter deliverable
on the
	topic? Chairs reported a strong consensus to do so.
	So which WG consensus of which SIP WG session do you not want to
change?

	
	My best guess is that RFC 4244bis goes forward, and that
target-uri-
	delivery turns into a "How to use H-I to meet the URI delivery
use
	cases" document.
	
	--
	Dean

	

--------------------------------------------------------------------- 
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
--------------------------------------------------------------------- 
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.