Subject: Re: [Geopriv] -retransmission- comments needed ASAP

From: "Brian Rosen" <[email-masked]>
Date: Tue, 4 Nov 2008 11:03:41 -0500

I have read the draft and agree with it.  I don't feel the example is
harmful and would prefer to leave it in.

I wouldn't have any qualms about challenging the syntax or mechanism
provided in this example when we get to mechanism.  It is clearly, in my
mind, just an example.

Mostly, I want this done, so we can finish -conveyance.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of James M. Polk
Sent: Thursday, October 30, 2008 6:30 PM
To: Henning Schulzrinne; Robert Sparks
Cc: GEOPRIV
Subject: Re: [Geopriv] -retransmission- comments needed ASAP

At 04:53 PM 10/30/2008, Henning Schulzrinne wrote:
>I think it's generally a bad idea to mingle requirements and
>background documents with protocol proposals, so I would simply
>replace the example section with something like
>
>"The permission to route on location information can be conveyed with
>a new SIP header field, an extension of PIDF-LO, a flag on the Geo- 
>Location header field and possibly other mechanisms. Details and 
>trade- offs are beyond the scope of this document."

this is something I'd really like; especially if section 3.6 were 
included in what the above paragraph replaces.

In fact, if all of section 3 of the current version (-01) took the 
philosophy of Henning's suggested quoted paragraph above (i.e., what 
he says in the paragraph below were written with this same 
philosophy), I'd probably drop my whole objection (and counterproposal ID).

>If there's specific advice that we really need to capture as to which
>is better, we can do this, but such discussions used to be done in
>mailing list archives, not RFCs, before the IETF succumbed to TPS
>report mentality.
>
>I don't think anybody in the SIP working group is so abstraction- 
>challenged that they need to be given a bogus header name to imagine
>what a header field looks like. Creating bogus header names either
>prejudges the syntax discussion outcome or creates confusion if the
>final outcome looks different.
>
>Henning
>
>On Oct 30, 2008, at 1:38 PM, Robert Sparks wrote:
>
>>Folks -
>>
>>I need feedback from more people to know whether or not to
>>pubrequest this version of the draft or if we need to take it back
>>again. It will also inform how we build Minneapolis' agenda.
>>
>>Specifically:
>>
>>We agreed in Dublin to change the language in this draft such that
>>we leave the engineering of syntax to SIP. The editors have tried to
>>do this by saying the formulation built in this document is an
>>example. My question to the group is does this document, with the
>>concrete syntax proposal _as an example_ have enough data in it for
>>the contributors to the effort in SIP to build whatever syntax they
>>want and get the location privacy considerations we're informing
>>them about right?
>>
>>
>>_______________________________________________
>>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

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

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 05 Nov 2008 17:21:22 -0600

>provided in this example when we get to mechanism.  It is clearly, in my

I (as if I've not been clear to date) read the text in section 3 as a 
mandate, and not an example. Mostly because I don't read any wiggle 
room in the example.  I don't read wiggle words like "could" or "can" 
or "might consider". I read words like "we recommend" (over and over 
again), which I take to mean "this is the way we think it ought to be 
(in Conveyance)".

I also read this ID as if it were written for providers and 
configurers, intead of implementers.  In other words, I can't help 
but point out that this ID is recommending additional policy rules be 
built into the protocol.

         B2BUAs receiving a LbyV only get to transmit the location
         out the other side if the <retransmission-allowed> is set to yes

as the best example. This, IMO, completely disregards the reality 
that most SIP proxy servers are in fact B2BUAs, thus neutering the 
ability to have location conveyed as an LbyV, even when a provider or 
enterprise wants to.

>Mostly, I want this done, so we can finish -conveyance.

no one wants conveyance done more than me.

Of course, it still has to run the IESG gauntlet -- which might not 
be too fun (!)