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

From: Brian Rosen ^lt;br@brianrosen.net>
Date: Wed Nov 19 2008 - 22:30:15 EST

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:jmpolk@cisco.com]
Sent: Wednesday, November 19, 2008 7:58 PM
To: Brian Rosen; 'Rosen, Brian'; 'GEOPRIV'
Subject: RE: [Geopriv] Suggested text for Section 3.6 of
draft-ietf-geopriv-lo-retransmission

At 06:07 PM 11/19/2008, Brian Rosen wrote:
>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.

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
>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 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.

>Brian
>
>-----Original Message-----
>From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] 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
>
>At 01:54 PM 11/18/2008, Rosen, Brian wrote:
> ><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".
>
>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
> >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
> >Geopriv@ietf.org
> >https://www.ietf.org/mailman/listinfo/geopriv
>
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Wed, 19 Nov 2008 22:30:15 -0500

This archive was generated by hypermail 2.1.8 : Wed Nov 19 2008 - 22:30:28 EST