Subject: [Ecrit] Re: draft-polk-dhc-uri-00: mixed goals

From: "James M. Polk" <[email-masked]>
Date: Wed, 14 Sep 2005 20:07:55 -0500

At 07:31 PM 9/14/2005 -0500, Thomson, Martin wrote:
>To put this into perspective, I like the idea of this draft - I can see 
>how this would be beneficial,

Thank you

>but I have a few questions.

don't you always?

;-)

> From a high level, when you look at the abstract, the draft talks about 
> URIs - no specific topic.

yep

>  So this draft has the potential to cover a wide array of URI-type 
> configuration information.

yep

>All present URIs are mapping or emergency based, obviously driven by need.

yep

>Is this draft intended to be a container for future URI-type configuration 
>information?

yep

>If this is going to be a container, why then use up numbers so rapidly 
>with primary and secondary options?

How many URIs do you feel qualify as configuration information?

I hope not 255, but I could be wrong - as I've already received a comment I 
should make the purpose byte 2 bytes long.

I know there will be resistance in the DHC community to overloading their 
servers with that many URIs, so I thought I'd leave it at 1 byte in length 
(255 possible URI types) until someone from that WG told me to up it).

>Why not provide a list in each option, similar to the way that RFC 3361 
>and RFC 3397 provide a list of domain names?  That would enable the 
>provision of more than two fallback values if necessary - keeping in mind 
>Michael's point that we already have means of fallback at other layers.

yeah - this is why I don't know if we need to address more than two URIs 
for PSAPs, as the network, if designed right, ought to route around 
problems.  I mean, it's not like a URI is the same as an IP address.

www.google.com has many ways to it through many IP addresses.

>The rest of my comments are more specific to the contents of the document...
>
>The "provided-by" URI is probably better than the structure in PIDF-LO, 
>but how do you envisage this working?

I see, for example, both Option 123 and this doc's Option in the 
Request/Response from the server to bind the two, with the purpose=6 (Org 
owning the Location) being exactly what is put into the <provided-by> 
element within the PIDF-LO. This solves that nasty little discussion we all 
had for about a year in "how do we learn this URL for 3825 and the civic 
Option?" If they are in the same DHCP message, that ought to be a good 
enough bind to Mr White-hat to allow troubleshooting of bad location 
information after-the-fact.

>The <provided-by> element is currently underspecified, so an example might 
>be useful here.

I am cautious of putting that in the DHC doc, and want that in another Arch 
doc where the scemantics can be layed out within the context we 
want.  Maybe I'm being overly sensitive to the DHC WG not caring about 
these specific URIs and getting hammered with all our messages back and 
forth clarifying this or that.

But I can be talked into adding this type of example for each purpose value 
into this doc if folks want that.

>Is this URI something that is included in the PIDF-LO directly?

yep - and that ought to go into one of ECRIT's docs

>If so, do you want to register a URN and schema for the <provided-by> 
>contents?

Not sure on this - but I really had something like www.cisco.com/richardson 
in mind for this, denoting Cisco was the company that gave out the location 
info, and it was out of their Richardson (in this case Texas) office. I 
thought this should give enough info to whomever to do the troubleshooting.

I really hadn't thought it needed to be much more complicated than 
that.  Maybe I'm being naive.

>OR is the intent of this URI that the endpoint dereferences the URI and 
>retrieves an XML fragment containing the <provided-by> contents?  In which 
>case do you expect that application/xml is sufficient as a MIME-type?
>
>I think that from a user perspective the ESRP and PSAP should appear to be 
>the same entity.

This could be a policy area in which only one is returned to the client. We 
can make that semantic clear in an ECRIT Arch/BCP type doc. Something like:

"If the client asks for a PSAP URI, and gets back a ESRP URI, it MUST be 
satisfied with that URI and treat it the same."

>This is really a question of degree: do I want the SIP URI for an 
>individual PSAP operator?

Again - this is a policy decision I didn't want this doc to deal with, so I 
put in both (and one backup)

>For instance, [email-masked] should be enough - I don't care what 
>is done beyond this point.  I assume that contacting 
>[email-masked] will get me help.

I agree

>Distinguishing between an ESGW and ESRP is even less useful - I would hope 
>that they all appear the same to the end user.

This is something that might be important to the end user, but might be 
important to the operator - in that

>I think that we should also mandate that a mapping service use a PIDF-LO 
>as input, therefore distinguishing between a civic and geo mapping service 
>does not add any value.

Andy Newton asked for these, and he can give more justification for them 
(I've slept since he talked me into adding them).

>The capabilities of the mapping service (the ability to accept civic or 
>geo input) are metadata.
>
>Cheers,
>Martin
>
>------------------------------------------------------------------------------------------------
>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]

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 14 Sep 2005 20:45:55 -0500

Thanks for the quick response, but I think you have me mistaken for someone else ;)

I am of the mind that 255 purpose codes should be enough; lists of URIs could help in that.  One thing that might be worth considering is that different URIs may represent services with different capabilities - having multiple options might help there.  That might not apply for emergency, but if you are talking a general solution, why not include the option?  Maybe others can add weight to one argument or the other.

With regards to the <provided-by>, the PIDF-LO soon-RFC says that content needs to be registered with IANA.  Currently URI-style content is not an option; there is only the NENA definition (incidentally, this is broken, because a tel: URI of only 10 characters isn't much use).  This would suggest that to include a URI you need to define a registered format, probably with schema.  Also, the format that you describe is something like a URN, but did you intend to formalize this definition?  Or, merely have it as an informal indicator (which I think is your intention).  Any complexity might depend on what people want to use this information for; I wouldn't want to suggest that you are naïve, but maybe there are more uses than that.

By the way, this starts to blur the line between ECRIT and GEOPRIV.

When I talk about PSAP vs. ESRP vs. ESGW URIs I am actually talking about the same sort of policy that you are talking about.  That is, the decision of the emergency operator to provide a useful URI, regardless of the type of entity that actually gets routed to.  I just don't see where knowing the difference is of benefit to anyone.  Why can't we just have one emergency URI?

I believe that an emergency operator uses an ESRP and ESGW in the same way that they use [email-masked] rather than [email-masked]; I don't think that this is oversimplification, but I would be willing to consider reasons why someone (anyone) would want to know the difference.

> important to the operator - in that

Ta,
Martin

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Thursday, 15 September 2005 11:08 AM
To: Thomson, Martin; [email-masked]
Subject: Re: draft-polk-dhc-uri-00: mixed goals

Thank you

don't you always?

;-)

yep

yep

yep

yep

I agree

>The capabilities of the mapping service (the ability to accept civic or 
<snip ugly disclaimer>

cheers,
James

                                 *******************

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 15 Sep 2005 01:05:07 -0500

Hi James,

Sorry, brain seems to be behaving oddly today - I have more (yes, there is always more).

Just another thought - it isn't clear in the document how a client requests URIs for a single purpose, or if they can at all.  Option 55 allows the requesting of this option (or not), but how does a client avoid getting all URIs when all they want is the URI of the emergency service?

I don't think that you should avoid this particular function, particularly if you intend this to be a container for many different URIs.

This is a bit of a stretch, but it might trigger some thoughts...  More services are moving to a web services infrastructure; and, web services can usually be described by a URI (which probably points to a WSDL file ...?).  Is this option applicable to web services types of applications, or is UDDI more appropriate?  Could this service be characterized as a very specific, limited subset of that sort of service?

Ta,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomson, Martin
Sent: Thursday, 15 September 2005 11:46 AM
To: James M. Polk; [email-masked]
Subject: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals

<snip>

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 15 Sep 2005 10:34:15 +0200

Sorry for jumping in into this discussion a bit late
but I had no time up to now to read the draft completely

I also apologize if I re-query some issues already discussed

In principle I consider it as a good idea to have a vehicle
to provide such information to a client.

Having said this, I would like to discuss the purpose list
in detail.

Purpose = 1  (Primary PSAP URI)
   Purpose = 2  (Secondary PSAP URI)
   Purpose = 3  (Location By-Reference of Client)
   Purpose = 4  (ESGW URI of Client)
   Purpose = 5  (ESRP URI of Client)
   Purpose = 6  (Location Providing Location for Client)
   Purpose = 7  (URI of Geocoding/Reverse Geocoding)
   Purpose = 8  (Primary URI of Geo Mapping Service)
   Purpose = 9  (Secondary URI of Geo Mapping Service)
   Purpose = 10 (Primary URI of Civic Mapping Service)
   Purpose = 11 (Secondary URI of Civic Mapping Service)

General remark 1 (this was already discussed):
There needs to be a requirement in ecrit req I-D defining
the TTL of such information and therefore the minimum lease time

Also the concern of Brian regarding short time changes has to by taken
into 
account, which may render the transmissinon of the URI of the Mapping
service and the PSAP useless, because then they always need to be
queried at
emergency call setup.

General remark 2:
Is it necessary to provide secondaries in general? Especially
for SIP URIs (PSAP) this can be done with other means (e.g. SRV RR)

Remark ESRP

If you query the mapping service, you get back a SIP URI. You do
not care if this is a PSAP direct or a ESRP. As far as I know there
is no distinction within the proposed protocols. So why put
this distinction here. If you have a distinction, you need first
to get the date. Since the provider of this date may (Must?) derive
this data from the mapping service anyway, how can he make the
distinction?

So IMHO this purpose is not needed.

Remark ESGW:

Now here I have a serious problem

It is stated in the draft
   "This purpose=4 URI is for the Emergency Services Gateway that an IP 
   client would contact when setting up an emergency call with a PSAP 
   that is not IP enabled.  Having this information locally in the
   client will allow it to contact the ESGW directly and not have to 
   rely on an intermediary to determine which ESGW is the right one for
   this client, and possibly fail the call set-up during that 
   determination."

We are planning to use ESGW, but these may accessed only via
the ESRPs. The ESGW are basically PoIs to the PSTN. If you access
the ESGW with a SIP URI, you are basically accessing a SIP proxy
and then it is a ESRP.

We are planning to access the ESGW with tel URIs via the ESRP.
It is the task of the ESRP to map the location (via the mapping service
or via a local DB to the NATIONAL routing numbers required to access
the national emergency service network. This mapping is very national
specific (it may not use E.164 numbers).

Since the client is not able in most case to access the ESGW directly
this purpose should not be there.

Side remark: there are discussions here in Europe to provide
international
access to PSAPs (at least to a national default PSAP), as an
intermediary
solution for VSPs having no national gateway and if, they may need to
know 
the national practice, but I do not consider this as a good idea. In
this
case you may provide this TEL URI in the purpose.
First, this is not generally available (some countries do not provide
access to PSAPs via international calls) and second, it is only a
deviating from
the more straightforward solution using a national ESRP with access to
a national ESGW.

One possible solution here is to store in the mapping service in
addition
to the SIP URI to the ESRP (which is used by the clients) also a TEL URI
with local context (which is then used only by the ESRP). The local
context
indicated that the TEL URI can only be interpreted by the specific
national
ESRP to provide the ESGW with the necessary routing information.

Now one may consider to store this tel URI in the ESGW purpose, but
since this information is useless to the client, I need not be there

What I am missing in the I-D is a way to provide the client eventually
with the local emergency identifiers

Cheers
Richard

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 15 Sep 2005 16:11:35 -0500

Andy,

This kind of problem can be completely avoided by providing a
LocationURI and allowing the proposed recipient to decide what kind of
location ot request.

Cheers
James 

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Andrew Newton
> Sent: Thursday, 15 September 2005 10:51 PM
> To: Thomson, Martin
> Cc: [email-masked]
> Subject: Re: [Ecrit] draft-polk-dhc-uri-00: mixed goals
> 
> 
> On Sep 14, 2005, at 8:31 PM, Thomson, Martin wrote:
> 
> > I think that we should also mandate that a mapping service use a
> > PIDF-LO as input, therefore distinguishing between a civic and geo
> > mapping service does not add any value.  The capabilities of the
> > mapping service (the ability to accept civic or geo input) are
> > metadata.
> 
> Martin,
> 
> I'm not sure all of PIDF-LO should be a requirement, but certainly
> the location elements seem appropriate.  As of my last reading of the
> requirements document, neither were required.
> 
> The intent of separating out the two types of URIs was not to suggest
> that they have different inputs, but only to tell the client when
> LCMS is needed and when the direct PSAP URIs can be used.  For
> instance, if the client is provided PSAP URIs and geo-LCMS URIs (and
> not civic-LCMS URIs), it can know not to invoke LCMS for civic cases
> and instead use the PSAP URIs.
> 
> -andy
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 16 Sep 2005 17:44:36 -0500

comments in line

>the TTL of such information and therefore the minimum lease time

ok

>service and the PSAP useless, because then they always need to be

Why "at" call set-up? Why not "before" call set-up?

>for SIP URIs (PSAP) this can be done with other means (e.g. SRV RR)

I thought I'd include them now and see what the WGs said about the reliance 
on one or two

>not care if this is a PSAP direct or a ESRP.

The client might not, but it might be stored in a server differently. 
Further, the client could get 3 URIs, Pri and Sec PSAP URIs and the ESRP as 
another fallback.

>As far as I know there
>this distinction here.

Because we don't know every possible instance of how URIs will be used, and 
there may be a difference somewhere.

>If you have a distinction, you need first
>to get the date.

the date? I don't understand this.

>Since the provider of this date may (Must?) derive

again - I don't understand this "date"

>the ESRPs.

Is that true for every enterprise network?

>The ESGW are basically PoIs to the PSTN. If you access

You may be telling a call server which GW to direct the call set-up 
towards. I believe this applies more to the smaller networks than the open 
Internet

>We are planning to access the ESGW with tel URIs via the ESRP.

I believe a tel:uri will be converted to a SIP uri that is then sent to the 
ESGW, but I could be wrong

>specific (it may not use E.164 numbers).

yes - but an ESRP is not always necessary.

If the UA has the IP destination URI (be it PSAP or ESGW), there doesn't 
need to be an ESRP to do the mapping that has already been done.

>this purpose should not be there.

"in most cases" means not all the time, so there are instances in which 
this can be used, maybe not many

>with the local emergency identifiers

remember, this is **NOT** an ECRIT Architecture ID, it is a DHC ID that 
doesn't need to get into all the architecture stuff of emergency 
communications. Another ECRIT (or two) ID could/should explain how these 
purposes are used, including message flows.

cheers,
James

                                 *******************

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 17 Sep 2005 01:13:42 +0200

Hi James

Sorry for the "date" problem, I meant data, but the explanation
was not very well formulated anyway. It was a bit late

Ok, it is late now again, but lets try

>purposes are used, including message flows.

Ok, but we are discussing this on the ecrit list.
 
So in ecrit we must define how the data are distributed
to the DHCP servers. One method could be that the
DHCP servers are querying periodically the mapping
database, because this is IMHO the ONLY authoritative
source for the location to PSAP URI mapping

Any other means would end up in a complete mess (one
cannot expect thousands of DHCP servers updated
properly if a PSAP URI changes)
 
So the PSAP URI may be retrieved in that way, but
I did not see in any of the proposals of the mapping
database a datafield indicating a destinction between
a PSAP URI or a ESRP URI, and I also did not
see an ESGW URI
 
So where are these DATA coming from?

The only data in the mapping database up
to now is a SIP URI. We would propose
to provide IN ADDITION to the PSAP
URI (which may also be an ESRP URI -who cares)
a TEL URI. This TEL URI may either be used
by the ESRP to access an ESGW or maybe
by any network knowing or owning a gateway
and also knowing the (national) context.
 
cheers
 
Richard

________________________________

Von: James M. Polk [mailto:[email-masked]]
Gesendet: Sa 17.09.2005 00:44
An: Stastny Richard; Thomson, Martin; [email-masked]
Betreff: RE: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals

comments in line

ok

cheers,
James

                                 *******************

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 16 Sep 2005 20:10:05 -0500

>was not very well formulated anyway. It was a bit late

fair

it's past Miller Time here too...

>Ok, but we are discussing this on the ecrit list.

yes, and we need to take the context of each topic and determine where it 
needs to be discussed. In other words, just because no official 
architecture doc exists doesn't mean we don't talk about architectures. 
Conversly, just because a single mechanism document is offered doesn't mean 
it has to cover every bit of the overlaying architecture that can take 

>source for the location to PSAP URI mapping

The DHCP servers will interact with the wire map database server to get 
location for endpoints based on a circuit ID (for RFC 3825). I expect the 
DHCP servers will interact periodically with your authoritative source for 
PSAP URI mapping to location jurisdications.

The timing of the interaction should be configurable, and a local policy 
decision. I guess I can add some text to address this to the ID.

>Any other means would end up in a complete mess

I do not know another one that would work

>(one

I think this will happen, but it is a question of how long this will take 
to fully populate to the servers, and then get to the clients

>So where are these DATA coming from?

PSAP URIs are not in existence yet, and we need to create them.  Just as is 
true for the ESRP and ESGW URIs. A URI is a unique identifier, that's all 
(conceptually).  An ESRP just has to be uniquely identifable and accept 
messages to that URI

How those URIs get distributed is another exercise.

>to now is a SIP URI.

Figuratively speaking, because not one database has been created yet.

The ESRP might not come from the PSAP community anyway, but could come from 
another source, like the LLP. If I want service from a particular LLP, they 
ask what state/province I'm in, I tell them, they configure my location to 
that URI, that propagates to their DHCP servers waiting for my device(s) at 
my address to boot up to request the URIs.

>We would propose
>a TEL URI.

Are tel:uris routable?

If not, they need to be converted to SIP URIs, which are routable, and that 
URI could be to a ESRP, ESGW or PSAP...

>This TEL URI may either be used

cheers,
James

                                 *******************

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 17 Sep 2005 10:12:55 +0200

>Are tel:uris routable?

Not on IP, but on the PSTN

>URI could be to a ESRP, ESGW or PSAP...

The problem here is that the ESGW is not precicely defined
I think you are talking about a corporate or campus environment
using a UNI. I am talking about a Point-of-Interconnect (PoI) using
a NNI. NNIs can never be accessed by the end-user directly.

That was the reason that although we have an ESGW in the architecture;
we considered it as a part of or behind an ESRP. The access from
ESRP to ESGW is already a national matter. This may be 1:1 or 1:n

The routing between ESRP and ESGW is of course done via SIP,
eventally with an embedded Tel URI. The ESGW itself understands
only Tel URIs. Which ESGW to use depends eventually on the
information contained in the Tel-URI and also on fail-over, etc.

Having said that, if the ESGW is used in your case for UNI-GWs,
I have no problem with it, we would just not use it.

BTW, I have another serious proble with your proposal I have not
brought forward yet:

You assume only ONE PSAP, but there are countries out there
with more then one emergency numbers. We have 9 (no comments
on this, please ;-)

This implies, that we would need 2x3x9 = 54 URI purposes
for ES alone ;-)

cheers
Richard

Von: James M. Polk [mailto:[email-masked]]
Gesendet: Sa 17.09.2005 03:10
An: Stastny Richard; Thomson, Martin; [email-masked]
Betreff: RE: [Ecrit] RE: draft-polk-dhc-uri-00: mixed goals

fair

Are tel:uris routable?

cheers,
James

                                 *******************

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 20 Sep 2005 13:56:54 -0500

>a NNI. NNIs can never be accessed by the end-user directly.

I am talking about both, but your PoI will not necessarily be universally 
accessable by the UA directly. This doesn't invalidate the "purpose", as it 
does have a use in campuses/enterprises/small businesses. I think this will 
be possible in some situations within an IP provider if that provider is 
directly connecting the UA to the GW within its own network.

>we considered it as a part of or behind an ESRP.

The above is where some confusion has been caused, because a GW is a GW to 
some folks, regardless of whether it is directly accessable or not. If it 
is hidden behind the ESRP *always*, I didn't read that text in the i2 spec. 
Obviously this cannot be the case, because enterprise GWs have direct 
access to SRs today, so this diagram would fit medium to large enterprises too.

>The access from
>ESRP to ESGW is already a national matter.

a national matter some of the time, not always. diagrams have a tendency of 
being the norm, and should avoid such when it is known not to apply.

>This may be 1:1 or 1:n
>only Tel URIs.

no it doesn't. The IP side needs to have access to a tel:uri in order to 
properly convey that on the TDM side, but it is not void in URI 
understanding in the SIP message.

>Which ESGW to use depends eventually on the

again, this is not true. I can have a fully formed INVITE from the ESRP 
using URIs. So long as that INVITE *also* has the tel:uri (the ANI) in it 
somewhere the ESGW can find it, everything is fine. That ANI field could be 
in the From header, or Contact header or it could be in a message body - it 
doesn't matter, as long as it is there for the ESGW to find.

>I have no problem with it, we would just not use it.

who's "we" here?

>with more then one emergency numbers.

I don't assume ONE PSAP. I have 2 PSAP URIs now. I was waiting for someone 
to say they needed another one for Fire, another one for Police, another 
one for Marine, another one for Mountain, another one for At Sea, etc....

I wasn't going to add these until asked to.

Are you asking me to?

>We have 9 (no comments

What's the 2 and the 3 in the above equation represent?

cheers,
James

                                 *******************