Subject: [Geopriv] draft-peterson-geopriv-retransmission-00

From: "James M. Polk" <[email-masked]>
Date: Mon, 18 Feb 2008 02:24:42 -0600

Unfortunately, the 2nd to last paragraph on page 7 ends with a comma, 
and not the conclusion part of that paragraph as it hints at.

What was supposed to be there?

The 2nd to last paragraph on page 9 is the very first mention of the 
'routing-permitted' indication (which ends up being "the 
recommendation" of this ID), as if it already existed - which it did 
not.  Is there some missing text from this -00 version of this document?

This  'routing-permitted'  header parameter, how different is it from 
a killed version of it that was in -06 of Conveyance with the 
following table associated:

"
    Proxies receiving location where the proxy performs location-based
    routing may need to consult external databases or systems to
    determine the route.  Transmission of the location information
    (which SHOULD NOT reveal identity, even if the proxy knows the
    identity) is governed by the 'retransmission-allowed' and
    'routing-query-allowed':

    Retransmission-allowed Routing-query-allowed Transmission for Query
    ---------------------- --------------------- ----------------------
    "no" or not present    "no" or not present   Not Allowed
    "no" or not present    "yes"                 Allowed
    "yes"                  not present           Allowed
    "yes"                  "no"                  Not Allowed
    "yes"                  "yes"                 Allowed
"
I realize the Routing-query-allowed element here was proposed to 
become part of the PIDF-LO, and what this new ID suggests is to 
basically more this out and into the Geolocation header, I just don't 
remember anyone suggesting that before.

This part I'm not much more than curious about. Rewriting 3 sections 
of Conveyance to emulate this ID's core meaning is asking a lot -- 
especially given I have a week to get the next version in -- which 
was going to be the basis for the next WGLC...

I've becoming perplexed about whether Conveyance will ever be allowed 
to be completed... given that I'm being regularly hit with massive 
changes that weren't considered before.  The last one being the 
complete rewrite of the errors section...

I can't wait to hear what's next (probably on or around next July 7th)

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 18 Feb 2008 10:27:56 +0200

I can already see the long queues in front of the microphone during the 
GEOPRIV WG session in Philadelphia.

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 19 Feb 2008 20:06:29 -0500

> What was supposed to be there?

Oops! Sorry about that. -00itis. I don't think this omission is a critical issue for understanding the draft, but the sentence should end with something like:

   However, if the Rule
   Maker influences the results of the dereferencing process, including
   determining who can receive LI at what degree of granularity and what
   policies are bound with the LI, then effectively providing a URI can
   selective withhold location information from undesired parties.

> not.  Is there some missing text from this -00 version of 

This is meant to be pointing back to the third paragraph of 3.1, although that paragraph uses "routing" rather than "routing-permitted" as a name for the indicator. This is the text in question:

   That much said, a binary indicator used to authorize
   location-based routing (something like "routing=yes") would at least
   serve to allow location-based routing to occur when <retransmission-
   allowed> is set to "no".

That entire section describes various possible indicators, and the possible semantics that could be associated with them.

> following table associated:
[snip]

It is a simple yes/no indicator that states simply whether or not routing is the intended use of the location information. I was particularly concerned that the current version relied on the UAC knowing whether an endpoint or intermediary needed to use the LI to route a call; that didn't seem like a very plausible thing for a UAC to be able to anticipate given the diverse way that location-based services might be implemented. I'm not claiming that this indicator is somehow original; merely that our analysis suggested it was the best choice.

> remember anyone suggesting that before.

There's some argument in the text about whether the indicator should appear in the header or the LO itself, which eventually concludes that the header seems to be best.

> complete rewrite of the errors section...

I am sympathetic to your procedural concerns. I'm simply trying to follow up on the action item I took from the last IETF meeting to explain the problem space. I thought it'd be useful to make a specific recommendation for what the location-conveyance draft should do to be in alignment with the analysis of the draft. Of course, whether or not the WG agrees with that analysis remains to be seen.

Jon Peterson
NeuStar, Inc.