Subject: [Geopriv] "retransmission" Issue #1 - B2BUA behavior

From: "James M. Polk" <[email-masked]>
Date: Mon, 20 Oct 2008 19:13:44 -0500

Here's the relevant text from the ID:

"3.6   Behavior of Back-to-Back User Agents

    Back-to-Back user agents are always a bit tricky, since they function
    in multiple realms.  One standard way of approaching their behavior
    is to see them as terminating one flow of information and originating
    a new one.  From that perspective, the correct behavior of a B2BUA
    receiving LI on one "back" is to treat that as terminating the
    information flow.  It can originate a new information flow containing
    that LI by value in the other direction only if the PIDF-LO it
    contains permits it by using <retransmission-allowed> set to yes.  If
    the PIDF-LO it contains is encrypted, it can pass it onward with the
    understanding that a recipient capable of decrypting it is
    authorized.

    Note that this case is also easier to handle using the location-by-
    reference model.  Since the passing of location-by-reference does not
    properly include the location itself, it can pass a location-by-
    reference pointer in the new direction with the understanding that
    the dereferencing protocol handles the determination of whether those
    dereferencing the location are authorized recipients or not.

    If both sides of a B2BUA's are SIP, we recommend that it copy any
    "Location-Routing-Allowed" header value found in the input flow when
    it re-originates the flow."

I have a issue with how the Retransmission ID "recommends" that, for 
conveyed LbyV, unless the retransmission flag is set to "yes", the 
location doesn't get transmitted by the B2BUA.  This, IMO, flies in 
the face of how SIP works - because a UAC doesn't know there is a 
B2BUA in the message path, therefore cannot account for one that's 
gonna through away a desired or critical piece of information that is 
sent in the SIP request.

I believe a better alternative is to have language in the 
retransmission ID RECOMMEND (in section 3.6) that for B2BUAs, if one 
were to receive LbyV on the UAS back side, that it forward that LbyV 
out the UAC back side as if the B2BUA is a SIP proxy (which is the 
expected behavior of a stateless or stateful SIP proxy BTW).  That 
said, have text stating the B2BUA (just like any other SIP server) 
MUST NOT forward the LbyV to another other entity other than one in 
the signaling path of the normal SIP message flow (i.e., no 3rd party).

Unless this change occurs, this will completely stifle most 
enterprise SIP implementations that have SIP servers configured as 
B2BUAs, and not just proxies in nature.  That reality alone begs for 
this text to change - because that market has been obviously 
overlooked and will completely ignore this text (if the SIP WG wants 
to add it into the conveyance doc).

 From another point of view, take the second sentence out of the 
first paragraph, and it sez:

    "One standard way of approaching their behavior
    is to see them as terminating one flow of information and originating
    a new one.  "

Is this defining a consistent way that the SIP WG should view B2BUAs?

If so, that ought to be up to SIP, shouldn't it?

Regardless, this second sentence doesn't prevent other standard 
approaches for describing B2BUAs - yet it eludes there are at least 
more than one, which means all the others are not defined (or even 
mentioned) in this ID.  This leaves the possibility for the SIP WG to 
wholly reject this interpretation of how to classify B2BUA behavior, 
thus rejecting this recommendation (the way I see it).

IMO, modifying the text as his message has recommended will gain 
wider support within the SIP WG, mostly because it doesn't pigeonhole 
B2BUAs only one way (or no way).  Preserve the idea of the intended 
signaling path and these entities become no different than a proxy, 
which is all that a user of a UAC can expect or predict (in the 
behavior of the entities handling its SIP request). This would 
preserve the information within the UAC's message as the user 
intended, which should be a goal - right?

James

BTW - other issues with this ID to come in separate messages

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

---

From: "TS Glassey" <[email-masked]>
Date: Tue, 21 Oct 2008 14:55:03 -0700

----- Original Message ----- 
From: "James M. Polk" <[email-masked]>
To: <[email-masked]>
Sent: Monday, October 20, 2008 5:13 PM
Subject: [Geopriv] "retransmission" Issue #1 - B2BUA behavior

>    a new one.

Which assumes they are end-points rather than gateways into other POLICY 
DOMAINS. In fact that is just what they are "POLICY CONTROL POINTS" where 
the POLICY itself can be changed or renegotiated.

>    From that perspective, the correct behavior of a B2BUA
>    contains permits it by using <retransmission-allowed> set to yes.

This is ont of the key problems in the IETF - the lack of understanding of 
the term CHAIN OF CUSTODY and how to make it work properly in a NETWORK 
AGENT'S WORLD.

>    If

THIS AGAIN IS SPECIFIC TO THE GATEWAY POLICY AND NOT NECESSARILY THE 
DOCUMENT POLICY.
>    it re-originates the flow."

IF IT ALTERS THE ORIGINAL MESXSAGE IN ANY FORM EXCEPT TO REINCAPSULATE IT, 
THE FORMAL CHAIN OF CUSTODY WOULD BE BROKEN. THAT MEANS IF IT RETRANSMITS 
THE MESSAGE AS A NEW ONE IT ALSO HAS TO DEAL WITH INSURING THAT THE ORIGINAL 
POLICY IS PRESERVED IN THE NEW HEADERS TOO.

> gonna through away a desired or critical piece of information that is

I HAVE A LARGER ISSUE WITH THE GROSS FAILURE TO OBEY THE LAW IN THE IETF BUT 
THAT IS ANOTHER ISSUE ...

> BTW - other issues with this ID to come in separate messages

--------------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.173 / Virus Database: 270.8.2/1735 - Release Date: 10/20/2008 
2:52 PM