Subject: [Dime] Limited flexibility with NAPTR queries

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 15 Apr 2007 13:28:21 -0400

Something, which is bothering me recently is the limited flexibility when using NAPTR service fields to locate Diameter servers. The current values placed in the registry allow to find *a* Diameter server in a given domain. It doesn't help much if one is looking for a server for a specific application in a given domain. This could work in environments where each domain (or better said each domain which envisions use of DNS to locate its servers) has a relay/redirect as the main contact point.

My initial thoughts are:
a) We can have registry entries for each Diameter application (could be hard to manage ?)
b) We can explain in the bis document that NAPTR query should resolve to a relay/redirect for the domain, if the domain supports more than one Diameter application.

Or am I missing something?

   Thanks,
   Tolga

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

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 16 Apr 2007 11:33:08 -0400

Hi Tolga,

> b) We can explain in the bis document that NAPTR query should resolve to a relay/redirect for the domain, if the domain supports more than one Diameter application.

I would prefer option (b) for simplicity though I'm concerned about 
explain deployment considerations such as these in the base spec. It may 
open up the door for adding many more possible deployment scenarios 
within the base spec. It maybe possible to add this in the guidelines 
doc but I'm sure.

regards,
victor

regards,
victor

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 16 Apr 2007 11:56:26 -0400

Hi Victor,

If we settle for b), I also do not think that it is mandatory to provide
an extra explanation in the bis document. 

    Thanks,
    Tolga
-----Original Message-----
From: Victor Fajardo [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 11:33 AM
To: Asveren, Tolga
Cc: [email-masked]
Subject: Re: [Dime] Limited flexibility with NAPTR queries

Hi Tolga,

> Something, which is bothering me recently is the limited flexibility
when using NAPTR service fields to locate Diameter servers. The current
values placed in the registry allow to find *a* Diameter server in a
given domain. It doesn't help much if one is looking for a server for a
specific application in a given domain. This could work in environments
where each domain (or better said each domain which envisions use of DNS
to locate its servers) has a relay/redirect as the main contact point.
> b) We can explain in the bis document that NAPTR query should resolve
to a relay/redirect for the domain, if the domain supports more than one
Diameter application.

regards,
victor

regards,
victor

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 18 Apr 2007 09:13:15 -0400

After having a quick look to the meeting minutes I saw that this issue
was touched as well. So, does anybody have some proposal or are we going
to rely on SLP?

    Thanks,
    Tolga
> values placed in the registry allow to find *a* Diameter server in a
given
> domain. It doesn't help much if one is looking for a server for a
specific
> application in a given domain. This could work in environments where
each
> domain (or better said each domain which envisions use of DNS to
locate
> its servers) has a relay/redirect as the main contact point.
> >
> >
> > My initial thoughts are:
> > a) We can have registry entries for each Diameter application (could
be
> hard to manage ?)
> > b) We can explain in the bis document that NAPTR query should
resolve to
> a relay/redirect for the domain, if the domain supports more than one
> Diameter application.
> >
>

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 18 Apr 2007 09:36:07 -0400

Hi Tolga,

> was touched as well. So, does anybody have some proposal or are we going

The current idea is to remove SLP and NAPTR from the base document to 
simplify the bis; the base doc will rely on basic DNS and redirects. If 
other SDOs may see some usefulness in SLP and others, one idea is that 
it maybe up to them to define/redefine its use. Any thoughts on this 
approach ?

regards,
victor

>> when using NAPTR service fields to locate Diameter servers. The
>>     
> current
>   
>> explain deployment considerations such as these in the base spec. It
>>     
> may
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 18 Apr 2007 18:08:26 -0400

Hi Victor,

My impression from the interop and from the deployments I saw till now
is that dropping SLP/NAPTR from bis shouldn't be a big issue.

   Thanks,
   Tolga

> Sent: Wednesday, April 18, 2007 9:36 AM
> To: Asveren, Tolga
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Thu, 19 Apr 2007 18:26:15 -0500

Hi all,

One of the reasons suggested to use NAPTR was to avoid using specific
TLS
ports, but to have a way to query which ports were secure, when
trying to find a Diameter agent.  This was based upon some IESG
guidence.
I don't believe that is needed any more, so I think it is fine to remove
NAPTR from the base spec. Has anyone implemented it?

John 

>From: ext Victor Fajardo [mailto:[email-masked]] 
>Sent: 18 April, 2007 06:36
>To: Asveren, Tolga
>Cc: [email-masked]
>> was touched as well. So, does anybody have some proposal or are we 
>> going to rely on SLP?
>>   
>
>The current idea is to remove SLP and NAPTR from the base 
>document to simplify the bis; the base doc will rely on basic 
>DNS and redirects. If other SDOs may see some usefulness in 
>SLP and others, one idea is that it maybe up to them to 
>define/redefine its use. Any thoughts on this approach ?
>
>regards,
>victor
>
>
>>     Thanks,
>>     Tolga
>>