Subject: Re: [Sipping] I-D Action:draft-vanelburg-sipping-served-user-07.txt

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Sep 2008 18:36:59 -0400

I haven't looked at this since version -00. Compared to that, this is 
much improved.

This is clearly very focused for IMS usage, and not meaningful in 
anything much different from that. But it is a P- header, and so that 
scoping is ok.

Just a couple of comments:

Section 7.1 says:

>  o The next hop proxy is part of the same Trust Domain
>    for P-Served-User.	

Its not good to talk about the "next hop proxy". While you can tell the 
address of the next hop, whether it is a proxy or not is not 
determinable by examining the address. So I think it is better to simply 
say: "the next hop is part of the same Trust Domain", etc.	

>  o The next hop proxy supports the P-Served-User header.	
>  o The next hop proxy requires the served user information
>    for its proper operation.	

I don't know how you can know these things. Are these really important 
to know? Does it hurt anything to insert the header without knowing this?

Section 7.2 says:

> A proxy that supports the header, MUST remove the 
> header from requests or responses before further 
> forwarding the message.	
> 				
> When the next hop might requires served user information, 
> then the procedure as in Section 7.1 MUST apply before 
> forwarding the message.	

Combined with 7.1, this means that the strategy for keeping this header 
from leaking out into the wild is to insert if for exactly one hop, and 
depend on the recipient to remove it. This puts a dependency on a lot of 
nodes.

Wouldn't it be more consistent to treat this more like 
P-Asserted-Identity? Namely, remove the header when leaving the trust 
domain. This only requires the last element in the trust domain to 
remove it.

For this header there is the added complication that the role can change 
from originating to terminating without leaving the trust domain. So it 
would also be necessary to remove/replace the (old) header when changing 
roles. But it still need only be done by select elements.

This would mean that one could always insert the header when sending to 
an AS, without regard for whether the AS supports it or not.	

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

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 18 Sep 2008 19:51:05 +0200

Paul wrote:

> I don't know how you can know these things. Are these really 
> important to know? Does it hurt anything to insert the header 
> without knowing this?
>

The normal way of dealing with this is that if the next hop does not
support the header, it is configured to not form part of the same trust
domain, and therefore it would be removed by those rules.

That I believe is consistent with your final comment, and indeed has the
same effect.

It is also the way we've defined it is defined in IMS (I think)!

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Monday, September 08, 2008 11:37 PM
> To: sipping
> Subject: Re: [Sipping] I-D 
> Action:draft-vanelburg-sipping-served-user-07.txt
> 
> I haven't looked at this since version -00. Compared to that, 
> this is much improved.
> 
> This is clearly very focused for IMS usage, and not 
> meaningful in anything much different from that. But it is a 
> P- header, and so that scoping is ok.
> 
> Its not good to talk about the "next hop proxy". While you 
> can tell the address of the next hop, whether it is a proxy 
> or not is not determinable by examining the address. So I 
> think it is better to simply 
> I don't know how you can know these things. Are these really 
> important to know? Does it hurt anything to insert the header 
> without knowing this?
> 
> Section 7.2 says:
> 
> > A proxy that supports the header, MUST remove the header 
> from requests 
> > or responses before further
> > forwarding the message.	
> > 				
> > When the next hop might requires served user information, then the 
> > procedure as in Section 7.1 MUST apply before
> > forwarding the message.	
> 
> Combined with 7.1, this means that the strategy for keeping 
> this header from leaking out into the wild is to insert if 
> for exactly one hop, and depend on the recipient to remove 
> it. This puts a dependency on a lot of nodes.
> 
> P-Asserted-Identity? Namely, remove the header when leaving 
> the trust domain. This only requires the last element in the 
> trust domain to remove it.
> 
> For this header there is the added complication that the role 
> can change from originating to terminating without leaving 
> the trust domain. So it would also be necessary to 
> remove/replace the (old) header when changing roles. But it 
> still need only be done by select elements.
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>