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.