Subject: [Geopriv] Suggested text for Section 3.6 of draft-ietf-geopriv-lo-retransmission

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 18 Nov 2008 14:54:13 -0500

<note that in the following I use lower case "must".  It's advice, we
cannot use MUST.  I think it's acceptable to be strong and use "must",
rather than weasel-wording "any SIP document should consider
compelling...">

Back-to-back user agent behavior is often difficult to proscribe.  There
are many uses of B2BUAs and the rules that apply would depend on the
actual use case.  This section suggests what any SIP mechanism arising
from this document might wish to consider with regard to B2BUA behavior.

In most uses of B2BUAs, it is a simple intermediary between the nominal
originating and nominal terminating UAs, that is, a proxy that does
something proxies aren't allowed to do.  In such cases, the B2BUA must
conform to any new routing-allowed mechanism if it chooses an outgoing
route.  As this document advises proxies, <retransmission-allowed> does
not apply and the B2BUA must copy the LI, the new routing-allowed and
existing <retransmission-allowed> values. 

Where the B2BUA in fact does terminate the session, and originate
another session, <retransmission-allowed> applies to it, and it must not
copy location if <retransmission-allowed> is "no". If it chooses a route
for the outgoing leg, any new routing-allowed mechanism applies to it.
   
Encryption provides additional control to the originator on who is
allowed to see location including B2BUAs.  On the other hand, using
encryption with LI which is needed for routing is problematic in that it
is often difficult to know in advance which elements do location based
routing. Similarly, using location-by-reference instead of
location-by-value provides additional control to the originator over
B2BUA behavior by controlling who can dereference.  The same limitation
for routing applies.

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

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 18 Nov 2008 21:14:03 +0100

The usage of RFC 2119 language is a question of scope. If the action is
in scope, then we can use RFC2119 language to specify its conformance.

So what is the scope of this document. The target of what is written in
this document is primarily the SIP WG to indicate what they should
support in their location conveyance document to provide the required
privacy of location information. Now I indicated this morning that SIP
would be able to normatively define about 30% of this (don't ask me to
justify how I came up with this figure but I was trying to covey that
there will be a significant hole if you want this normatively
specified).

So for that other 70%, we need to target what is essentially a BCP
requirement to the SBC vendors. Does this document do this, or does
GEOPRIV produce another document that does this? If SBC vendors need to
read this document, then we should indicate that in the abstract.

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rosen, Brian
> Sent: Tuesday, November 18, 2008 7:54 PM
> To: GEOPRIV
> Subject: [Geopriv] Suggested text for Section 3.6 
> ofdraft-ietf-geopriv-lo-retransmission
> 
> <note that in the following I use lower case "must".  It's 
> advice, we cannot use MUST.  I think it's acceptable to be 
> strong and use "must", rather than weasel-wording "any SIP 
> document should consider compelling...">
> 
> Back-to-back user agent behavior is often difficult to 
> proscribe.  There are many uses of B2BUAs and the rules that 
> apply would depend on the actual use case.  This section 
> suggests what any SIP mechanism arising from this document 
> might wish to consider with regard to B2BUA behavior.
> 
> In most uses of B2BUAs, it is a simple intermediary between 
> the nominal originating and nominal terminating UAs, that is, 
> a proxy that does something proxies aren't allowed to do.  In 
> such cases, the B2BUA must conform to any new routing-allowed 
> mechanism if it chooses an outgoing route.  As this document 
> advises proxies, <retransmission-allowed> does not apply and 
> the B2BUA must copy the LI, the new routing-allowed and 
> Where the B2BUA in fact does terminate the session, and 
> originate another session, <retransmission-allowed> applies 
> to it, and it must not copy location if 
> <retransmission-allowed> is "no". If it chooses a route for 
> the outgoing leg, any new routing-allowed mechanism applies to it.
>    
> Encryption provides additional control to the originator on 
> who is allowed to see location including B2BUAs.  On the 
> other hand, using encryption with LI which is needed for 
> routing is problematic in that it is often difficult to know 
> in advance which elements do location based routing. 
> Similarly, using location-by-reference instead of 
> location-by-value provides additional control to the 
> originator over B2BUA behavior by controlling who can 
> dereference.  The same limitation for routing applies.
> 
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 18 Nov 2008 15:52:17 -0600

I have no problem with this text.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Rosen, Brian
> Sent: Tuesday, 18 November 2008 1:54 PM
> To: GEOPRIV
> Subject: [Geopriv] Suggested text for Section 3.6 ofdraft-ietf-geopriv-
> lo-retransmission
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 19 Nov 2008 15:48:36 -0600

At 01:54 PM 11/18/2008, Rosen, Brian wrote:
>copy location if <retransmission-allowed> is "no".

I firmly/strongly/(whatever) do not agree with this use of MUST NOT 
(capitalized or not).  B2BUAs by definition terminate sessions - so 
there is no wiggle room here.  But this is *not* the behavior we want 
B2BUAs to adhere to here. We want B2BUAs to act like proxies as much 
as is possible when copying ruleholder policies downstream (only!), 
and yet follow what these policies mean regarding transmitting the 
received location to any other parties/entities.

>  If it chooses a route

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 19 Nov 2008 19:07:45 -0500

I tried to differentiate two classes of B2BUAs.  As per Jonathan's outspoken
complaint that we don't have names for the various classes of B2BUAs, I
tried to distinguish those that really are proxies that break proxy rules,
and those which really, really terminate a session and re-originate another
session.  Technically, of course, all B2BUAs terminate sessions and
originate sessions.  Most B2BUAs that are in the wild are proxies that break
the rules.  However, there are B2BUAs that are more the second sort.  I
think in those cases, the UAS side (terminating side) IS the UAS to which
"retransmission-allowed" refers to, and thus it should not reveal location
to it's UAC side.

I don't agree that all B2BUAs send location downstream.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of James M. Polk
Sent: Wednesday, November 19, 2008 4:49 PM
To: Rosen, Brian; GEOPRIV
Subject: Re: [Geopriv] Suggested text for Section 3.6 of
draft-ietf-geopriv-lo-retransmission

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 19 Nov 2008 18:57:43 -0600

At 06:07 PM 11/19/2008, Brian Rosen wrote:
>session.

ah hah, I don't care which name is used or whether one (verses 
another) teminates a call-ID and generates another one - I don't want 
to make this distinction here.

>Technically, of course, all B2BUAs terminate sessions and
>originate sessions.

exactly

>Most B2BUAs that are in the wild are proxies that break
>the rules.

sure

>However, there are B2BUAs that are more the second sort.  I

I absolutely disagree with this. That isn't the intent of from the 
originating UAC, to have location stopped because there was a 
particular type of B2BUA.  All B2BUAs and SBCs SHOULD or MUST 
regenerate location towards the SIP signaling destination UAS (this 
doesn't apply if the B2BUA actually is the ultimate destination).

I believe (obviously very strongly) that all the policy flags 
(routing-allowed, <retransmission-allowed> and <retention-expiry> 
need to stay the same on the UAC side of the B2BUA (that received 
location on its UAS side).

The existing text in -01 at least provided a loophole that I could 
work with ("If the B2BUA is acting as an endpoint..."). You've 
removed that one, which is why I'm raising a stink here.

>I don't agree that all B2BUAs send location downstream.

I don't either - I just want them to act like proxies when they 
aren't the ultimate destination of the location.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 19 Nov 2008 22:30:15 -0500

So what I get out of this is that you agree that there are two
classifications of B2BUAs that matter here, and you agree that the text
correctly describes what the B2BUA should do for each of those classes, but
you don't agree on my choice of wording to differentiate the classes.  Have
I got that correct?

You like "if the B2BUA is acting like an endpoint".  You don't like "Where
the B2BUA in fact does terminate the session, and originate another
session".

I'm not wild about either wording, but I'm unable to come up with a better
way to describe the kind of B2BUA where you don't copy LI unless
<retransmission-allowed> is "yes".

Can anyone suggest a better way to describe this kind of B2BUA?

Brian

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Wednesday, November 19, 2008 7:58 PM
To: Brian Rosen; 'Rosen, Brian'; 'GEOPRIV'
Subject: RE: [Geopriv] Suggested text for Section 3.6 of

exactly

sure

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 19 Nov 2008 22:30:17 -0600

Is the one case this is causing friction on, the one where the one side is SIP (w/ conveyance) and the other some other protocol?

Maybe the rule should be:

   If the thing (B2BUA/proxy, whatever JDR comes up with) does not, or cannot ensure that the rules will be conveyed onwards with the signalling, then it MUST NOT forward LI with that signalling.

Take the second and third paragraphs from Brian's proposal and include a statement to that effect.

Martin

> Behalf Of Brian Rosen
> Sent: Wednesday, 19 November 2008 9:30 PM
> To: 'James M. Polk'; 'GEOPRIV'
> Subject: Re: [Geopriv] Suggested text for Section 3.6 ofdraft-ietf-
> geopriv-lo-retransmission
> 
> Behalf

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Nov 2008 08:50:40 -0500

Nah, a B2BUA, by definition, has SIP on both sides.

Also, I'm differentiating the case where the B2BUA IS subject to the retransmission allowed (that is, we don't see it as an intermediary like a proxy). It's not that the B2BUA doesn't know what could happen downstream; it's that the B2BUA is, in fact the location recipient, and what is downstream is a 3rd party.

Brian 

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Wednesday, November 19, 2008 11:30 PM
To: Brian Rosen; James M. Polk; GEOPRIV
Subject: RE: [Geopriv] Suggested text for Section 3.6 ofdraft-ietf-geopriv-lo-retransmission

Martin

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 20 Nov 2008 17:58:58 +0100

But in the sense of the GEOPRIV document, the device we are talking
about could have SIP on both sides, and have an entire global
telecommunications network in the middle, with those sides located in
entirely disparate physical locations.

Keith 

> [mailto:[email-masked]] On Behalf Of Brian Rosen
> Sent: Thursday, November 20, 2008 1:51 PM
> To: 'Thomson, Martin'; 'James M. Polk'; 'GEOPRIV'
> Subject: Re: [Geopriv] Suggested text for Section 
> 3.6ofdraft-ietf-geopriv-lo-retransmission
> 
> Also, I'm differentiating the case where the B2BUA IS subject 
> to the retransmission allowed (that is, we don't see it as an 
> intermediary like a proxy). It's not that the B2BUA doesn't 
> know what could happen downstream; it's that the B2BUA is, in 
> fact the location recipient, and what is downstream is a 3rd party.
> 
> Brian 
> 
> Is the one case this is causing friction on, the one where 
> the one side is SIP (w/ conveyance) and the other some other protocol?
> 
>    If the thing (B2BUA/proxy, whatever JDR comes up with) 
> does not, or cannot ensure that the rules will be conveyed 
> onwards with the signalling, then it MUST NOT forward LI with 
> that signalling.
> 
> > classifications of B2BUAs that matter here, and you agree that the 
> > text correctly describes what the B2BUA should do for each of those 
> > classes, but you don't agree on my choice of wording to 
> differentiate 
> > the classes.
> > Have
> > I got that correct?
> > 
> > You like "if the B2BUA is acting like an endpoint".  You don't like 
> > "Where the B2BUA in fact does terminate the session, and originate 
> > another session".
> > 
> > I'm not wild about either wording, but I'm unable to come up with a 
> > better way to describe the kind of B2BUA where you don't copy LI 
> > unless <retransmission-allowed> is "yes".
> > 
> > >complaint that we don't have names for the various classes 
> of B2BUAs,
> > I
> originate 
> > >sessions.
> > >Most B2BUAs that are in the wild are proxies that break the rules.
> > 
> > sure
> > 
> > >However, there are B2BUAs that are more the second sort.  
> I think in 
> > >those cases, the UAS side (terminating side) IS the UAS to
> > which
> > (routing-allowed, <retransmission-allowed> and 
> <retention-expiry> need 
> > to stay the same on the UAC side of the B2BUA (that 
> received location 
> > on its UAS side).
> > 
> > work with ("If the B2BUA is acting as an endpoint..."). 
> You've removed 
> > that one, which is why I'm raising a stink here.
> > 
> > 
> > I don't either - I just want them to act like proxies when 
> they aren't 
> > the ultimate destination of the location.
> > 
> > 
> > >Brian
> > >
> > > ><note that in the following I use lower case "must".  
> It's advice,
> > we
> > > >are many uses of B2BUAs and the rules that apply would depend on 
> > > >the actual use case.  This section suggests what any SIP 
> mechanism
> > arising
> > > >route.  As this document advises proxies, 
> <retransmission-allowed>
> > does
> originate 
> > > >another session, <retransmission-allowed> applies to it, and it 
> > > >must
> > not
> > > >for the outgoing leg, any new routing-allowed mechanism 
> applies to
> > it.
> > > >
> > > >location-by-value provides additional control to the originator 
> > > >over B2BUA behavior by controlling who can dereference.  The same
> > limitation
> > > >for routing applies.
> > > >
> > > >

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 20 Nov 2008 12:06:25 -0500

Sure, but what is that B2BUA doing?  If it mostly looks like a wire, or a
proxy, then it's not the watcher, and retransmission-allowed doesn't apply
to it, routing-allowed DOES apply to it, and it copies LI, rt-allowed and
routing-allowed across.

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Thursday, November 20, 2008 11:59 AM
To: Brian Rosen; Thomson, Martin; James M. Polk; GEOPRIV
Subject: RE: [Geopriv] Suggested text for Section

Keith