Subject: [dns-dir] help with NAPTR & S-NAPTR issues

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Apr 2009 14:46:47 +0300

(Sorry for duplicates; this e-mail got lost when I sent it to
the wrong dns-dir address.)

Directorate,

I have a document in AD review (draft-ietf-mipshop-mos-dns-discovery)
where I had a number of question marks relating to the use and
registration of NATPTRs. I also asked Leslie Daigle for some help and
she suggested S-NAPTR might have been a more appropriate tool for this
task. The problem is, she is busy and I'm clueless about NAPTR. I'd like
to find one volunteer with such clue from the directorate, and put the
volunteer, me, and the author and chair (Cced) to the same conference
call sometime this or next week. The volunteer should help us understand
whether something needs to change in the document, and if so, what.

Jari

Some links:

http://tools.ietf.org/html/draft-ietf-mipshop-mos-dns-discovery-04
http://www.ietf.org/mail-archive/web/mipshop/current/msg04183.html

---

From: Peter Koch <[email-masked]>
Date: Mon, 20 Apr 2009 14:08:00 +0200

Jari,

> whether something needs to change in the document, and if so, what.

I vaguely remembered I had reviewed this draft in an earlier version.
NAPTR RRs are defined in the DDDS context only and for less structured
or specialized name spaces ther are S-NAPTR and U-NAPTR.  I am not a particular
fan of either one because I don't believe in DNS as a service discovery
(rather than a service location) mechanism.

The crucial point in the draft is:

   The procedures defined here assume that the MN knows the domain name 
   of the network where it wants to locate a Mobility Server. The 
   domain name of the network can either be pre-configured, discovered 

This assumes that "a network" has "a domain name", which I disagree with.
Apart from that IO'd be willing to help, of course.  If any of you is
going to be at the RIPE meeting early May, that would even allow a
face 2 face discussion.

-Peter

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 20 Apr 2009 14:31:46 +0200

> going to be at the RIPE meeting early May, that would even allow a

This is the key thing. And also something Stuart Cheshire has asked  
about. For example why not what today is "search domain" (in for  
example DHCP, and resolver configuration) is this "home domain".

Regarding the proposal, well, it could be ok but sounds a bit too  
complicated I think. I have two questions:

- I am nervous the terms IS, ES and CS, are too short. I do see future  
collisions regarding naming (in the prefix in the DNS).

- Is it really the case that you want to look for what services exists  
for a certain domain? If you follow the bonjour way of doing things  
you should instead look up:

_mobility_services._tcp.home.domain. IN PTR _es._tcp.home.domain.
_mobility_services._tcp.home.domain. IN PTR _cs._tcp.home.domain.

Etc...and then the SRV etc.

So, there is an architectural choice whether you want to go the  
(S-)NAPTR path, or bonjour/zeroconf path.

    Patrik

- Why do they not "just" do the bonjour version of the lookup, i.e.  
look up

---

From: <[email-masked]>
Date: Wed, 22 Apr 2009 00:57:21 +0200

Hi Peter, Patrik

  >This assumes that "a network" has "a domain name", which I 

Would the below re-write of the paragraph you cite above solve the problem?

The procedures defined in this document assume that the MN knows the search domain (DNS suffix) where it wants to locate a Mobility Server. 
When the MN wants to find Mobility Servers in its current visited network, it can use DHCP option 15 to request the domain name it should use when resolving hostnames via DNS. The domain name suffix returned in the option can be used as the search domain.
When the MN wants to find Mobility Servers in the home network, it can use the home domain of its subscription as the search domain.
If the MN wants to find Mobility Servers in a 3rd party operated network (which is not its current visited, or its home network) it needs to have the search domains of those 3rd party operated networks preconfigured, or use IEEE 802.21 Information Service query [IEEE802.21] to find the home domains of the networks operating in the location of interest.

The naming issues mentioned by Patrik in the other mail can easily be addressed.

Using the Bonjour way in my opinion wouldn't solve the issue as it has the same problem, ie how to find the suffix of the search domain.

Thanks,
- gabor

  >-----Original Message-----
  >From: Peter Koch [mailto:[email-masked]] On Behalf Of ext Peter Koch
  >Sent: Monday, April 20, 2009 5:08 AM
  >To: Jari Arkko
  >Cc: dns directorate; Bajko Gabor (Nokia); 
  >Devarapalli, Vijay
  >Subject: Re: [dns-dir] help with NAPTR & S-NAPTR issues
  >
  >Jari,
  >
  >> task. The problem is, she is busy and I'm clueless about 
  >NAPTR. I'd 
  >> like to find one volunteer with such clue from the 
  >directorate, and 
  >> put the volunteer, me, and the author and chair (Cced) to the same 
  >> conference call sometime this or next week. The volunteer 
  >should help 
  >> us understand whether something needs to change in the 
  >document, and if so, what.
  >
  >NAPTR RRs are defined in the DDDS context only and for less 
  >structured or specialized name spaces ther are S-NAPTR and 
  >U-NAPTR.  I am not a particular fan of either one because I 
  >don't believe in DNS as a service discovery (rather than a 
  >service location) mechanism.
  >
  >Apart from that IO'd be willing to help, of course.  If any 
  >of you is going to be at the RIPE meeting early May, that 
  >would even allow a face 2 face discussion.
  >
  >-Peter
  >

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 23 Apr 2009 09:09:31 +0200

On 22 apr 2009, at 00.57, <[email-masked]> wrote:

> The procedures defined in this document assume that the MN knows the  
> search domain (DNS suffix) where it wants to locate a Mobility Server.

I think we have two problems here.

a) Is it correct to use the search domain for usage like this (in a  
DDDS context) and Bonjour

b) Do you want to use DDDS or Bonjour algorithm

I think personally the answers are:

a: Yes - but we need a generic document that updates the DNS spec that  
talk about this change

b: You want bonjour, as what you do is a more zeroconf algorithm

Other people cc:ed might have different opinion.

    Patrik

> When the MN wants to find Mobility Servers in its current visited  
> network, it can use DHCP option 15 to request the domain name it  
> should use when resolving hostnames via DNS. The domain name suffix  
> returned in the option can be used as the search domain.
> When the MN wants to find Mobility Servers in the home network, it  
> can use the home domain of its subscription as the search domain.
> If the MN wants to find Mobility Servers in a 3rd party operated  
> network (which is not its current visited, or its home network) it  
> needs to have the search domains of those 3rd party operated  
> networks preconfigured, or use IEEE 802.21 Information Service query  
> [IEEE802.21] to find the home domains of the networks operating in  
> the location of interest.
>
> Using the Bonjour way in my opinion wouldn't solve the issue as it  
> has the same problem, ie how to find the suffix of the search domain.
>
> Thanks,
> - gabor
>
>
> _______________________________________________
> dns-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-dir

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 24 Apr 2009 07:25:45 +0200

On 24 apr 2009, at 01.25, <[email-masked]> wrote:

> My limited understanding of the Bonjour algorithm tells me that it  
> only works in the local network. Since the Mobility Servers would  
> need to be discovered also in remote networks, I'd prefer a more  
> general solution.

Absolutely not. There is one algorithm for local network (you send DNS  
queries over IP multicast), and one for wide area bonjour.

>> a) Is it correct to use the search domain for usage like
>> this (in a DDDS context) and Bonjour
>> a: Yes - but we need a generic document that updates the DNS
>> spec that talk about this change
>
> I assume you mean the usage of search_domain/home_domain as the  
> first valid key to the DDDS application.

Yes, or as seed for the wide area bonjour algorithm.

> I'd be willing to go down this path if the community finds it  
> acceptable.

    Patrik

> - Gabor
>> From: ext Patrik Fältström [mailto:[email-masked]]
>> Sent: Thursday, April 23, 2009 12:10 AM
>> To: Bajko Gabor (Nokia-CIC/MtView)
>> Cc: [email-masked]; [email-masked]; [email-masked];
>> [email-masked]
>>>> This assumes that "a network" has "a domain name", which
>> I disagree
>>>> with.
>>>
>> a) Is it correct to use the search domain for usage like
>> this (in a DDDS context) and Bonjour
>>
>> a: Yes - but we need a generic document that updates the DNS
>> spec that talk about this change
>>
>>> When the MN wants to find Mobility Servers in the home
>> network, it can
>>> use the home domain of its subscription as the search domain.
>>> needs to have the search domains of those 3rd party
>> operated networks
>>> preconfigured, or use IEEE 802.21 Information Service query
>>> [IEEE802.21] to find the home domains of the networks
>> operating in the
>>> location of interest.
>>>
>>> The naming issues mentioned by Patrik in the other mail
>> can easily be
>>> addressed.
>>>
>>> Using the Bonjour way in my opinion wouldn't solve the
>> issue as it has
>>> the same problem, ie how to find the suffix of the search domain.
>>>
>>> Thanks,
>>> - gabor
>>>
>>>
>>>> Cc: dns directorate; Bajko Gabor (Nokia); Devarapalli, Vijay
>>>> structured or specialized name spaces ther are S-NAPTR
>> and U-NAPTR.
>>>> I am not a particular fan of either one because I don't
>> believe in
>>>> DNS as a service discovery (rather than a service location)
>>>> mechanism.
>>>>
>>>> This assumes that "a network" has "a domain name", which
>> I disagree
>>>> with.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 24 Apr 2009 15:04:58 +0300

How about a phone call to talk about this? Please fill in the poll here:

http://www.doodle.com/pg5nxaxi27s9bmky

Jari

---

From: <[email-masked]>
Date: Fri, 24 Apr 2009 01:25:24 +0200

Hi Patrik,

  >b: You want bonjour, as what you do is a more zeroconf algorithm

My limited understanding of the Bonjour algorithm tells me that it only works in the local network. Since the Mobility Servers would need to be discovered also in remote networks, I'd prefer a more general solution.

  >spec that talk about this change

I assume you mean the usage of search_domain/home_domain as the first valid key to the DDDS application.
I'd be willing to go down this path if the community finds it acceptable.

Thanks,
- Gabor

---

From: Jari Arkko <[email-masked]>
Date: Mon, 27 Apr 2009 11:42:23 +0300

Lets pick Wednesday 3 PM CET:

Conference Title:    mipshop naptr    Additional Information:     Web 
booked conference
     Number of Participants:     10    Conference Duration:     90
     Date of Conference:     29-Apr-09    Recurring Conference:     No
     Start Time:     15:00    Timezone:     Stockholm, Sweden
     Recording:    No       
     Participant Code:     78959  
     Conference Phone Numbers:     +1 972 583 9950 , 866-523-2663, 
     ECN: 800 39950 , *Toll Free: 866-52 ECONF* .,  Conference Helpline: 
+1 972 583 4444

Jari

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 27 Apr 2009 11:38:27 +0200

Ok!

   paf

On 27 apr 2009, at 10.42, Jari Arkko wrote:

> Conference Title:    mipshop naptr    Additional Information:      
> Web booked conference
>    Recording:    No           Participant Code:     78959

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 28 Apr 2009 19:33:37 +0200

Hmm...I just got a very urgent call with ISOC re. ICANN at this time  
slot that seems to be very hard to move. Can we move this 30 min  
earlier? As I do not think we need more time than 30 min for me to  
clarify what I think the issue is?

    Patrik