Subject: [Ecrit] Forward of Off-List Service URN Draft Discussions (6)

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 16 Aug 2006 14:26:42 +0200

-----Ursprüngliche Nachricht-----
Von: Henning Schulzrinne [mailto:[email-masked]] 
Gesendet: Dienstag, 25. Juli 2006 01:00
An: Leslie Daigle
Cc: Marc Linsner; Tschofenig, Hannes; 'James M. Polk'; [email-masked]
Betreff: Re: Moving forward with the Service URN Draft

Please note important discussion on scoping below.

> Comments on LoST, S-NAPTR, and the service URN:
>
> To use S-NAPTR, there are some basic registration and structural
> requirements (as defined, probably not as coherently as one might
> wish, in RFC3958 -- see the IANA Considerations of that document).
>
>
> So -- what is the application service that is to be registered?
> I infer it's meant to be SURN.<service>, but that needs to be
> spelled out -- and perhaps changed to LOST.<service> if you like
> as this is more about LoST than SURN in general.

That's part of the basic problem about where to locate this material.  
SURN itself does NOT require the use of LoST, although this is  
currently the only mechanism defined. Thus, if this section moves to  
the LoST document, we have a problem. Some other mechanism would then  
have to refer back to LoST.

Thus, it seems that the best place to define the NAPTR remains the  
URN document, as that's referenced by all hypothetical resolution  
systems.

The alternative is that service URNs can *only* be resolved using  
LoST, in which case it doesn't much matter which document this  
appears in since the service URN document depends on LoST and vice  
versa.

>
> And then, the $64k question -- *what* is the FQDN that is to
> be queried for the NAPTR records?
>
> I couldn't quite figure that out between the service URN and
> LoST documents.  Is it "hostname"?  Or...?  It seems like
> the basic purpose is to say "given I'm *here*, for some
> value of *here*, where is my LoST service in protocol
> A, B or C".  So, what is *here* expressed in a relevant FQDN?
> That really needs to be made clear in defining the use of S-NAPTR.
>

This is described in "Finding the Mapping Server", albeit less  
precisely than I'd like. Currently, it says that the domain is  
"typically the home or service provider domain". I don't know if it  
would be helpful to give an example for the SIP case, where this  
would be the AOR domain. The cut-and-paste fragmented text in -03  
starting with 'until a working server' gives three options: DHCP  
domain, DNS PTR lookup for all ICE derived addressed and the  
application service provider, tried in order.

I wish I had a better answer; designating a particular domain  
immediately means that we have to pick somebody to run it and I'd  
rather not repeat the e164.arpa experience. (Unlike in ENUM, this is  
altogether unnecessary here since any number of entities can operate  
localized translation servers.)

Henning

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Aug 2006 08:51:04 -0400

I agree with Henning on where the service is registered, I think it's in the
Service URN document.

On finding the LoST server, I have a few thoughts, somewhat contradictory.

Fundamentally, I think the issue is "who runs the LoST server?", and I think
the answer is "the local emergency authorities".  That implies you really
want a LOCAL server, and not necessarily anything the SIP infrastructure
knows about.  On the other hand, I do NOT want to further burden the access
network beyond the basic requirement to supply location.

So, I see three potential suppliers of the URL to the LoST server:
1. Something literally local
2. Something associated with the access network
3. Something associated with the SIP network

Perhaps we try them, possibly in order.
If you had a civic address, it's conceivable we could provide a service by
compiling a URL from it.  For example: Allegheny.pa.us could possible have
an SRV record containing a LoST service (as could pa.us).  Geo's couldn't
use that idea without a reverse geocode engine.

Whatever we decide is the discovery mechanism for the L7 protocol in geopriv
could also supply a LoST server.

Finally, we have something as Henning suggests, off of the AoR or outgoing
proxy server domain.

Brian

> -----Original Message-----
> From: Tschofenig, Hannes [mailto:[email-masked]]
> Sent: Wednesday, August 16, 2006 8:27 AM
> To: [email-masked]
> Subject: [Ecrit] Forward of Off-List Service URN Draft Discussions (6)
> 
> 
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 17 Aug 2006 08:52:19 -0500

We definitely need to specify what gets tried in order, and I can't think of 
a reason not to specify the order.

I think I'm agreeing with Brian, and especially with his reasoning about 
requiring LoST support in all access networks, etc. It would be great if 
LoST was supported close to the host, but "and then we'll upgrade all the 
access networks" seems ambitious.

Thanks,

Spencer

From: "Brian Rosen" <[email-masked]>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Aug 2006 23:09:28 -0400

Just to add some slight twist to this: Based on the architecture  
document, the answer to the "who runs LoST servers" is probably  
slightly more complicated. Clearly, the authoritative server should  
be run by authorities, but lots of other entities can and should run  
local caching servers, which are the ones that users would most  
likely contact. Running such a server should be fairly  
straightforward, of the "install some standard software and enter one  
or two pieces of information" kind, encouraging lots of ISP and VSPs  
to run these. The ISP server is always going to be closer to the end  
user, so it probably should be queried first, if available. If the  
ISP-operated LoST server is provided by DHCP, the end system will  
know very quickly whether there is such a server, even in the "power- 
up-and-dial-911" case.

Thus, we have:

- DHCP for discovering ISP-operated servers
- SIP config and DNS-via-AOR for VSP-operated servers

This seems fairly straightforward.

Henning