Subject: [Geopriv] draft-polk-geopriv-sip-lo-retrans-rec-concerns

From: "James M. Polk" <[email-masked]>
Date: Mon, 27 Oct 2008 18:15:24 -0500

Geopriv

Here's a new ID that's intended to be a discussion point, in reaction 
to what I still disagree with regarding Jon and Ted's retransmission 
ID (as a set of recommendations into SIP Location Conveyance).

I highlight several passages of text within the retransmission ID, 
giving counterproposals (counter-recommendations?) that I feel will 
have less impact and increase communication of SIP requests that include LbyV.

Comments are welcome

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>         Title           : Geopriv Concerns about SIP Location 
> Conveyance Retransmission Recommendations Document
>         Author(s)       : J. Polk
>         Filename        : 
> draft-polk-geopriv-sip-lo-retrans-rec-concerns-00.txt
>         Pages           : 10
>         Date            : 2008-10-27
>
>This document expresses grave concerns about the recommendations
>made in the 'Implications of <retransmission-allowed>' document,
>which in turn states several recommendations towards the
>modification of SIP Location Conveyance.  This document makes
>several counterproposals to what is currently in the 'Implications
>of <retransmission-allowed>' document.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-polk-geopriv-sip-lo-retrans-rec-concerns-00.txt
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-polk-geopriv-sip-lo-retrans-rec-concerns-00.txt>
>_______________________________________________
>I-D-Announce mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

---

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

The WGLC of draft-ietf-geopriv-sip-lo-retransmission-00 showed strong  
working group support for that document (extremely strong for this  
working group).

The feedback from that last call led to agreement to change the text  
to acknowledge that the SIP working group was best suited and  
responsible for arguing the details of SIP syntax. The language in the  
draft around recommending behavior for B2BUAs was also changed based  
on later comments.

The draft James has submitted presents  three objections to the  
content of the current draft
draft-ietf-geopriv-sip-lo-retransmission-01.

1) An objection to the way the draft uses authorized recipient while  
describing retransmission recommendations.

2) An objection to the recommendation of a new header preferring a  
different syntactic representation.

3) An objection to what James feels will be interpreted as  
requirements placed on B2BUAs around forwarding location information.

As chair, I have the following observations and requests:

Objection 1 appears to be a restatement of a position in the  
discussions leading to the draft - I'm not clearly seeing a new point  
to consider here. There may be a point of clarification, or at least  
complete documentation of what's been considered,  to be captured -  
James points to a "point that is not made" in the draft. James (or  
anyone else) - if that's what is motivating the objection, please  
suggest a clarification. If, on the other hand, you simply disagree  
with the position the draft takes, the group has fairly strongly  
indicated it agrees with what's in the draft and we need to move on -  
I'll note your objection in the publication request write-up.

Objection 2 is a restatement of a position that James has previously  
argued. On this point, a) the group has strongly expressed  
satisfaction with the recommendations in the draft and b) the document  
explicitly calls out that the recommendation is "an exemplary concrete  
proposal".  With this, it explicitly leaves it to the SIP working  
group to work out the syntax. This syntax is what the contributors in  
GEOPRIV have expressed strong support for, but there will be an  
opportunity to argue the point again in SIP.

Objection 3 deserves careful thought from each of us to see if it  
provides new data affecting the recommendations the draft makes.  
Everyone - please give section 3.6 another read in light of the  
comments James has made. If you think the recommendations need to  
change, please say so on list ASAP.

If anyone thinks I've misread consensus or misunderstood James'  
objections, please let me know.

RjS

On Oct 27, 2008, at 6:15 PM, James M. Polk wrote:

> Geopriv
>
> Here's a new ID that's intended to be a discussion point, in  
> reaction to what I still disagree with regarding Jon and Ted's  
> retransmission ID (as a set of recommendations into SIP Location  
> Conveyance).
>
>>        Filename        : draft-polk-geopriv-sip-lo-retrans-rec- 
>> concerns-00.txt
>>        Pages           : 10
>>        Date            : 2008-10-27
>>
>> <ftp://ftp.ietf.org/internet-drafts/draft-polk-geopriv-sip-lo-retrans-rec-concerns-00.txt 
>> >

---

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

Robert

Thanks for the extensive review

comments are in-line

>working group support for that document (extremely strong for this

I agree that there was demonstrated strong consensus in the Geopriv 
WG in Dublin for what was in this ID (by 12 to 1, if I remember right 
- with me being the ONE).

That said, I haven't received one comment towards the objective of 
this ID on the SIP WG mailing list -- i.e., specific changes 
suggested to the SIP Location Conveyance ID, not one - and that 
troubles me.  This massive consensus is being made and no one wants 
to even comment about how it affects Conveyance?

Perhaps folks in Geopriv are ok with a mindless recommendation 
without understanding its affects on SIP signaling, but as one of the 
few bridges between the two WGs, I have to continue to object to one 
WG's RECOMMENDATIONs on another's documents, specifically one that I'm editing.

This might read like a slam on Geopriv, it is not.

But it is an educated, experienced concern that this ID be adopted by 
SIP without folks in Geopriv understanding how its RECOMMENDATIONs 
are to be taken by those in SIP.

Here's a question for the WG, can each of the 12 that expressed 
strong consensus in Dublin accurately describe the function of a 
B2BUA or SBC (in general), and can they accurately describe how 
taking the retransmission ID's RECOMMENDATIONs will positively or 
adversely affect SIP signaling?

>responsible for arguing the details of SIP syntax.

So... why is this ID still RECOMMENDing a brand new SIP header?

Why not just some indication that's consistent with the idea of this 
RECOMMENDATION?

My ID makes this alternate proposal, which this message doesn't even 
acknowledge

>The language in the

While I do see different text, I see it still contains the same 
limitations on <retransmission-allowed>=no for a received LbyV 
prohibiting re-originating the message along the SIP signaling path 
with that LbyV.

>describing retransmission recommendations.

The above objection is to the point that any entity that receives 
LbyV is an "authorized recipient", which I flatly disagree with 
(mostly cuz that would mean routers and firewalls - especially those 
that are L7 aware - are affected by this, yet this is inconsistent 
with how folks think about this topic).

The point made in the retransmission ID also misses the mark by not 
differentiating a location recipient from a consumer of 
location.  Case in point, if a proxy processes a SIP request whether 
it is location aware or location unaware, is it an authorized user, 
or a location consumer, neither or both?

>different syntactic representation.

My issue with the above is that a Geopriv ID is telling a SIP ID what 
exactly needs to be created (i.e., a new header), instead of what the 
requirement is (i.e., it is making a conclusion vs. making a 
recommendation).  This retransmission ID should not be making 
solutions unless each only affect Geopriv WG items.

>I'll note your objection in the publication request write-up.

see above

>proposal".

yeah - it offers a specific, concrete solution. I do not believe this 
WG has a procedural right to demand a specific solution request to 
another WG.  I believe it can, however, create a single or set of 
requirements to another WG that then can chose which they agree with 
(thus incorporating into any relevant documents (or create a new one)).

>With this, it explicitly leaves it to the SIP working
>group to work out the syntax.

no it doesn't. I don't know how you can say "create this new header 
that says X (and only X)" is open to interpretation by that second WG.

>This syntax is what the contributors in

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 28 Oct 2008 23:30:38 -0500

I'll add my name to the list of those in support of the approach in retransmission.  It's clear enough to me that this is guidance.  I'm also of the opinion that it's sound guidance.  I disagree with James: the _example_ of a new header does not impose any constraints on the realization of any solution in SIP.

For case 3) I can appreciate the pragmatists view that states that the strict interpretation leads to potential failure cases.  However, I can't see how a less limiting viewpoint would do anything other than offer carte blanche for a range of ab-use cases.  Robert is right: the guidance is useful.  To water it down only reduces its value.
	
I could be reading James' document wrong.  James, I found your document quite hard work to read.  I still don't really know what Section 3 is trying to say.

Cheers,
Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Robert Sparks
> Sent: Wednesday, 29 October 2008 7:14 AM
> To: James M. Polk; GEOPRIV
> Subject: [Geopriv] Next steps on -retransmission- (was Re:draft-polk-
> geopriv-sip-lo-retrans-rec-concerns)
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 29 Oct 2008 01:51:19 -0500

At 11:30 PM 10/28/2008, Thomson, Martin wrote:
>I'll add my name to the list of those in support of the approach in 
>retransmission.

I think you were one of the previously counted 12  -- so no double 
votes like ACORN wants counted here...

;-)

>It's clear enough to me that this is guidance.  I'm also of the 
>opinion that it's sound guidance.  I disagree with James: the 
>_example_ of a new header does not impose any constraints on the 
>realization of any solution in SIP.

then why does it suggest a solution (i.e., the new header) instead of 
just an indication or flag that means the same thing?

Everyone seems to be avoiding answering this simple question, which I 
posed well prior to retransmission-01 was submitted (which means it 
could have been incorporated in -01 of that ID).

>For case 3) I can appreciate the pragmatists view that states that 
>the strict interpretation leads to potential failure 
>cases.  However, I can't see how a less limiting viewpoint would do 
>anything other than offer carte blanche for a range of ab-use 
>cases.  Robert is right: the guidance is useful.  To water it down 
>only reduces its value.
>
>I could be reading James' document wrong.  James, I found your 
>document quite hard work to read.  I still don't really know what 
>Section 3 is trying to say.

What is this text from retransmission ID saying exactly that's not 
already agreed to (and has been agreed to without extensive discussion)?

       After extensive discussion in both GEOPRIV and SIP contexts,
       there seems to be consensus that a solution for this problem
       must enable location-based routing to work even when the
       <retransmission-allowed> flag is set to "no".

When wasn't this (idea of location-based routing) a goal within 
Geopriv (once it was first proposed)?

The idea of this (idea of location-based routing) was first 
posted/written about in late 2003.  I'm not really understanding why 
the 2008 retransmission ID brings this topic up as if it either new, 
or weren't being considered appropriately.

In 2003 we knew this had to be accounted for.

That's all section 3 of my ID is questioning. In other words, there's 
more words in my response here then there is in section 3. It's just 
not that long.

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 29 Oct 2008 16:50:15 -0500

I understand now.  Thanks.  I don't see why you needed to include a section to state that, though.

> From: James M. Polk [mailto:[email-masked]]
> Sent: Wednesday, 29 October 2008 5:51 PM
> To: Thomson, Martin; Robert Sparks; GEOPRIV
> Subject: RE: [Geopriv] Next steps on -retransmission- (was Re:draft-
> polk-geopriv-sip-lo-retrans-rec-concerns)
>

---

From: Robert Sparks <[email-masked]>
Date: Thu, 30 Oct 2008 12:29:17 -0500

Some responses inline:

On Oct 28, 2008, at 6:02 PM, James M. Polk wrote:

> WG in Dublin for what was in this ID (by 12 to 1, if I remember  
> right - with me being the ONE).
>

If you recall, the conversation in SIP was formally directed into  
GEOPRIV until this document is finished. It does not surprise me that  
you haven't seen SIP mailing list traffic at all given that we've told  
people to talk about it here until this document gets published.

> Perhaps folks in Geopriv are ok with a mindless recommendation

Tone?

> without understanding its affects on SIP signaling, but as one of  
> the few bridges between the two WGs, I have to continue to object to  
> one WG's RECOMMENDATIONs on another's documents, specifically one  
> that I'm editing.

> But it is an educated, experienced concern that this ID be adopted  
> by SIP without folks in Geopriv understanding how its  
> RECOMMENDATIONs are to be taken by those in SIP.

The number of people that contributed in this conversation that are  
also active in SIP is not trivial.
The set of people who will engage in the next set of discussions in  
SIP after this document is likely to be very similar to this set.

> My ID makes this alternate proposal, which this message doesn't even  

Not intentional - I went back and looked for the proposal you are  
pointing to here, and I still do not see it.
I do see that you argue for a different syntax.

> differentiating a location recipient from a consumer of location.   
> Case in point, if a proxy processes a SIP request whether it is  
> location aware or location unaware, is it an authorized user, or a  
> location consumer, neither or both?
>
>
> My issue with the above is that a Geopriv ID is telling a SIP ID  
> what exactly needs to be created (i.e., a new header), instead of  
> what the requirement is (i.e., it is making a conclusion vs. making  
> a recommendation).  This retransmission ID should not be making  
> yeah - it offers a specific, concrete solution. I do not believe  
> this WG has a procedural right to demand a specific solution request  
> to another WG.  I believe it can, however, create a single or set of  

from these word: "As an exemplary concrete proposal".

For you, that's clearly not enough to convey that GEOPRIV is not  
saying "Hey SIP, you have to create exactly this header". I'd like to  
hear if that's the case from others on this list. I'll ask a more  
pointed question about this in a separate message.