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

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 9 Apr 2006 22:56:18 -0500

I believe that this is the right approach

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, 10 April 2006 12:04 PM
> To: Thomson, Martin
> Cc: Rosen, Brian; [email-masked]
> Subject: Re: [Ecrit] Re: Review of draft-ietf-ecrit-service-urn-02,
DDDS
> 
> > 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.
> 
> 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.
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit

------------------------------------------------------------------------------------------------
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: "Marc Linsner" <[email-masked]>
Date: Mon, 10 Apr 2006 09:43:45 -0400

1. Given the current state of the in-addr.arpa db (IMO, a mess) and the
current discussions going on within the dns ops community, I would not want
to suggest that implementers rely on this service.  The current draft within
the dnsop wg only suggests the population of in-addr.arpa, it does not
require it.

2. I agree with Henning in that a VoIP SP is the most likely candidate to
operate a LoST server/service and therefore any entry in the in-addr.arpa db
would never compare to the operator of a telephone service.

I certainly wouldn't want the success of an emergency call I make to rely on
reverse DNS.  I suggest we don't mention it.

-Marc-

> From: Winterbottom, James [mailto:[email-masked]] 
> Sent: Sunday, April 09, 2006 11:56 PM
> To: Henning Schulzrinne; Thomson, Martin
> Subject: RE: [Ecrit] Re: Review of 
> draft-ietf-ecrit-service-urn-02, DDDS
> 
> > > 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

---

From: Andrew Newton <[email-masked]>
Date: Mon, 10 Apr 2006 10:31:47 -0400

> reverse DNS.  I suggest we don't mention it.

First, I agree that solely hanging our hats on reverse DNS is a recipe 
for a non-working architecture.  During the MARID working group when 
many people were arguing for MTA Mark and using the reverse DNS for 
anti-spam measures, APNIC sent a formal message that basically said, 
"fat chance of getting that to work in Asia."

However, the suggestion isn't a bad idea in this use case as there are 
likely to be many ISPs that do maintain their reverse space adequately 
and would want to do the right thing (if they can).  Additionally, if 
this lookup is done at boot-time or network attachment-time, then I 
think it would be preferable to use it over that of a VSP-default.

To restate it:
   At boot or network attachment time, do the following:
   1) Use the reverse DNS to find the appropriate LoST resolver.
   2) If not successful, use the VSP default to find the appropriate 
LoST resolver.

BTW, we are talking about VSPs running LoST resolvers, not LoST mapping 
servers, right?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 Apr 2006 13:27:54 -0400

> think it would be preferable to use it over that of a VSP-default.

I'm curious what leads you to this conclusion. (I could come up with 
reasons either way and would consider my reasons largely speculative, in 
the realm of motivation, since there's not much real deployment to go 
by, to put it charitably.)

One clear advantage of the ISP-operated resolver is that it is likely to 
be closer, network-wise, than a VSP-operated one and it satisfies the 
extensively-inconclusively-debated minimum-connectivity requirement.

>   2) If not successful, use the VSP default to find the appropriate LoST 
> resolver.
> 

I would elaborate on this slightly and say that an end system would use 
the ICE mechanism to determine all IP addresses and then perform reverse 
DNS (your step (1)), possibly several times.

One minor wrinkle is that some systems also get their DNS name via DHCP. 
I would suggest that as step (0).

> BTW, we are talking about VSPs running LoST resolvers, not LoST mapping 

At least in my view of the world, yes. (I think there was some 
discussion that they might run actual mapping servers during early 
deployments.)

Henning

---

From: Andrew Newton <[email-masked]>
Date: Mon, 10 Apr 2006 14:27:02 -0400

Comments in-line:

> extensively-inconclusively-debated minimum-connectivity requirement.

I agree.  I think the ISP will have a much better idea about the closest 
resolver than the VSP.

> I would suggest that as step (0).

No disagreement on either point.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 10 Apr 2006 15:17:14 -0400

> 
> First, I agree that solely hanging our hats on reverse DNS is 
> a recipe for a non-working architecture.  During the MARID 
> working group when many people were arguing for MTA Mark and 
> using the reverse DNS for anti-spam measures, APNIC sent a 
> formal message that basically said, "fat chance of getting 
> that to work in Asia."

I think APNIC gives too much credit to non-Asia access providers.

> 
> However, the suggestion isn't a bad idea in this use case as 
> there are likely to be many ISPs that do maintain their 
> reverse space adequately and would want to do the right thing 
> (if they can).  Additionally, if this lookup is done at 
> boot-time or network attachment-time, then I think it would 
> be preferable to use it over that of a VSP-default.
> 
> To restate it:
>    2) If not successful, use the VSP default to find the 
> appropriate LoST resolver.

Why would we rely on a historically failed mechanism as our #1 choice for
discovering a LoST resolver?

I believe we agree that discovering a LoST resolver is essential to the
success of an emergency call.  Precedence dictates that the provider of the
'telephone service' is responsible for ensuring a successful emergency call
setup.  This leads to a conclusion that the application provider *should* be
more interested in operating the LoST resolver used by it's customers than
the access provider who is simply selling pipes and bandwidth.  

We are currently asking the access provider to, in addition to providing
pipes and bandwidth:

1) Implement a location determination mechanism.  We believe this is
straight forward for wireline access providers, we believe they have this
information within their service location db.
2) Provide this location information to their customer via: dhcp and/or a
yet-to-be-determined L7 protocol.

Now we want to add to the list:

3) Operate a LoST resolver
4) Update and maintain the in-addr.arpa database to facilitate the discovery
of said resolver (which seems odd given #3). 

We reconcile #1 & #2 by concluding that there is no other place to get this
information, therefore the access provider *must* provide it.  We have no
valid argument for #3 & #4, we simply can't justify why an access provider
would be in the LoST resolver business.

The discovery of the LoST resolver should be provisioned:

1) Via the application provider's registration mechanism.
2) Hard-coded.  (I'm from the old-school that believes the application
provider will still be involved in the config of the client, e.g. supply the
client hardware and/or software).
3) IF the access provider operates a LoST resolver, via the host
configuration mechanism.

I think we should listen to the dns ops gurus.

> 
> BTW, we are talking about VSPs running LoST resolvers, not 
> LoST mapping servers, right?

Correct!

-Marc-