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.