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 17:12:12 -0600

At 03:53 PM 11/19/2008, Richard Barnes wrote:
>Suggested text?

sure, see in-line below (which replaces the whole 3rd paragraph of 
what Brian's text)

>James M. Polk wrote:
>>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.

(this text replaces all of the above paragraph text from Brian and no 
other text)

Where B2BUAs act as an endpoint for a received session, the 
<retransmission-allowed> applies to this request, and MUST NOT 
transmit the LI in this request to any another entity (SIP or 
not-SIP). Where B2BUAs are not the ultimate destination of the 
received SIP request (i.e., with the intent on transmitting the SIP 
request downstream towards the ultimate destination), the B2BUA MUST 
act like a proxy and pass on the unchanged rules for 
<retransmission-allowed>, <retention-expiry> and the newly created 
"routing-allowed" in the spirit of the original ruleholder (which the 
original UAC at least had a say in setting each policy value).

>>>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
>>_______________________________________________
>>Geopriv mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/geopriv

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