Subject: [Geopriv] James' objection 3 to -retransmission-

From: Robert Sparks <[email-masked]>
Date: Tue, 28 Oct 2008 15:26:57 -0500

As an individual contributor:

I think draft-ietf-geopriv-sip-lo-retransmission-01.txt says the right  
things about what implementers of B2BUAs (or other gateway-like  
endpoints) should think about when making decisions for their code. I  
don't interpret it as something that places normative restrictions on  
what B2BUAs can (or can't) do. The draft explicitly notes that  
behavior of such beasts is outside the scope of standardization.

I'm sympathetic to James' concern that things like the SBCs we know  
today will chose to not follow the recommendations this group is  
making. That doesn't mean we shouldn't make the recommendation - the  
implementers of such things need to know the implications of the  
choices they're making.

I'll note further that the implications of this section go well beyond  
the things we currently think of as B2BUAs/SBCs.
PSTN gateways need to think about these things if they end up  
tunneling a call across a PSTN link (and choose to
carry/preserve any location information that arrives as part of the  
SIP signaling). The advice in this sections is good
advice for those implementations.

One point in James objection that I would like (as an individual, and  
probably in SIP, not here) to explore further is whether we need to  
add mechanics that enable a "please send me an indication if you  
forwarded this request without forwarding its location information"  
semantic.

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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 28 Oct 2008 18:26:43 -0500

At 03:26 PM 10/28/2008, Robert Sparks wrote:
>what B2BUAs can (or can't) do.

I didn't read the ID saying "this is optional" or "this is merely 
informative".  That would make what you say above pretty clear.

Instead I read the ID saying "B2BUAs/SBCs are out of specification 
scope, but we'll discuss them here anyway" - which definitely is 
implying guidance.  Guidance is something that is taken or 
ignored.  The retransmission ID is asking that it not be ignored.

If some implementer is really into searching if these authors know 
what they are talking about, they'll see that one is a current AD (or 
RAI even, where Geopriv belongs) and one is a past AD, and one is a 
lawyer for civil and privacy rights.

If this becomes known to an implementer, how can that not be 
interpreted as "implying strong guidance"?

>The draft explicitly notes that

yeah - but reality has these implementers searching for any docs that 
can help give them guidance, of which this will become another one.

>implementers of such things need to know the implications of the

OK, this is part of the point I'm making within my discussion ID, 
however I believe that the RECOMMENDATIONs within the retransmission 
ID still make a total policy choice for the implementer 
*in*the*protocol* instead of a warning about how local policy might 
need to be considered.

If the retransmission ID were to be such a warning ID, or even a 
protocol ID, I'd not have said anything about it. But this is not the 
case, this retransmission ID specifically RECOMMENDs how another WG's 
protocol ID needs to be changed, without being written from a "this 
are this (Geopriv's) requirements about privacy" point of view.

>advice for those implementations.

Is Geopriv the right WG to be making these recommendations?

I'm thinking SIP is the right WG to make these policy decisions... 
and I'm not seeing a lot (i.e., zero) list activity in the SIP WG 
list about this topic, which is where it should be found.

>forwarded this request without forwarding its location information"

(sarcasm alert!)

Congratulations!!

this should be on the SIP list, and not here

This specific point will be challenging at best, because many will 
jump on this bandwagon and want their favorite indication that's 
dropped also notify the original UAC, which will be confused with 
indications that were introduced by some intermediary server... but 
this is something that SIP hasn't really looked at (other than an old 
ID I wrote confirming that SIPS was really sent per hop, by each hop 
- all the way to the destination UAS). B2BUAs and SBCs also blow that 
expectation up rather quickly IMO...