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 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
> -----Original Message-----
> From: Victor Fajardo [mailto:vfajardo at tari.toshiba.com]
> Sent: Wednesday, April 18, 2007 9:36 AM
> 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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.