RE: [Dime] Limited flexibility with NAPTR queries
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Dime] Limited flexibility with NAPTR queries
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
>-----Original Message-----
>From: ext Victor Fajardo [mailto:vfajardo at tari.toshiba.com]
>Sent: 18 April, 2007 06:36
>To: Asveren, Tolga
>Cc: dime at ietf.org
>Subject: Re: [Dime] Limited flexibility with NAPTR queries
>
>Hi Tolga,
>
>> 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?
>>
>
>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
>>
>>> -----Original Message-----
>>> From: Victor Fajardo [mailto:vfajardo at tari.toshiba.com]
>>> Sent: Monday, April 16, 2007 11:33 AM
>>> To: Asveren, Tolga
>>> Cc: dime at ietf.org
>>> 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.
>>>
>>>> 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.
>>>
>>> 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
>>>
>>>
>>>
>>>> Or am I missing something?
>>>>
>>>> Thanks,
>>>> Tolga
>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME at ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/dime
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>> _______________________________________________
>> DiME mailing list
>> DiME at ietf.org
>> https://www1.ietf.org/mailman/listinfo/dime
>>
>>
>>
>>
>
>
>_______________________________________________
>DiME mailing list
>DiME at ietf.org
>https://www1.ietf.org/mailman/listinfo/dime
>
_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.