Subject: RE: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02, DDDS

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 9 Apr 2006 20:42:03 -0500

I like the inclusion of SNAPTR, but then, I suggested it.  I like the method of using the top level service tag - it simplifies things to the right level.

> > not all that easy to determine what that is.  Read the HELD and LCP
> > documents, and the discussion about this point.  I think this document
> > needs to handle this.  I think whatever it says is likely to have
> > to be
> >
> 
> I didn't see any description of this in draft-winterbottom-geopriv-
> held-sighting-00. LCP seems to define, besides the usual suspects of
> manual configuration and DHCP, a broadcast request, not specified
> further. (This would be essentially a one-off version of SLP.)

The discussion on HELD was quite heated in previous incarnations.

> I think there are at least two plausible approaches to find an ISP-
> operated domain name, besides DHCP:
> 
> (1) SLP or Bonjour; the practical problem is that SLP is seeing
> limited new deployments and Bonjour seems to be under the cloud of
> being non-IETF-developed (but comparatively widely deployed), with
> the IETF competitor having been sent back to the WG for a do-over
> (somebody might know more about this).
> 
> (2) Inverse DNS: Get public IP address (via STUN, say); obtain domain
> name (via the usual reverse DNS lookup); use SRV or NAPTR record for
> that domain. This relies on the user's public IP address having a DNS
> entry. As far as I can tell, this seems to be almost universally true
> for residential broadband. (For enterprise users, I suspect that the
> DHCP solution is easiest.)
> 
> I had suggested a version of (2).

We are looking at this sort of discovery mechanism for some tests here as well.  I think that it is workable, and you can write a client that orders the different methods appropriately:

 1. Get domain name from DNS
 2. Do NAPTR/SRV lookup for that domain (you can iterate from local domains to TLD-1 if you like).  Success = URL or Host/Port of service.
 3. Use STUN/UPnP/other to determine public IP address.
 4. Use reverse DNS to determine the domain name(s) for the public IP address.
 5. Repeat step 2. for the new domain name(s).
 6. Use static configuration.

This relies on having reverse DNS, which I'm told is not an ironclad guarantee, but highly likely.

This method is good for local services, but for services relating to your calling service, I see no reason not to search based on your VSP domain.  However, I think that VSPs are providing a backup LoST server only - the coverage area of that server is virtually unbounded, which makes it impractical long term.  Maybe the VSP would be happy with its service being the statically configured option.

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]

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 9 Apr 2006 22:03:45 -0400

> We are looking at this sort of discovery mechanism for some tests  
> here as well.  I think that it is workable, and you can write a  
> client that orders the different methods appropriately:
>
>  2. Do NAPTR/SRV lookup for that domain (you can iterate from local  
> domains to TLD-1 if you like).  Success = URL or Host/Port of service.

Since the provider of the lookup service also controls the IP  
addresses in most cases, the ISP can fix the omission if need be.

If there's agreement on this general mechanism, I'll add it to the  
draft.

>
> This method is good for local services, but for services relating  
> to your calling service, I see no reason not to search based on  
> your VSP domain.  However, I think that VSPs are providing a backup  
> LoST server only - the coverage area of that server is virtually  
> unbounded, which makes it impractical long term.  Maybe the VSP  
> would be happy with its service being the statically configured  
> option.

Based on the architectural discussions, the VSP (or ISP) wouldn't  
really need to provide a world-wide database. It would provide an  
entry point only, i.e., a resolver in LoST terminology. This is no  
more onerous than providing a local DNS server.