|
If the question is “Can I put whatever
information I want in a regex?” than the answer is yes – a NAPTR can suffice. If
the question is “Is a regex the most elegant way to store routing information
other than target FQDN (e.g. trunk group info, LRN info, etc.)” than the answer
is no. There are other issues as well (am heading
into a meeting so I will elaborate later)… D. From: drinks-bounces at ietf.org
[mailto:drinks-bounces at ietf.org] On Behalf Of
Brian Rosen We haven’t found anything we can’t do
with a NAPTR, with parameters. Could someone cite an example of what
you can’t do with a NAPTR? Brian From:
drinks-bounces at ietf.org [mailto:drinks-bounces at ietf.org] On Behalf Of Guyton, Deborah A The
protocol design team has been working on a data model and protocol for the
registry provisioning interface. We
have associated with each public identifier routing information in the form of
resolution answers on the name server. Initially we looked at specific
types of routing info – such as NS and NAPTR Resource Records. We have heard
feedback that this is too DNS-centric. We are discussing collapsing these into
a “generic” Route Object. This may lead to a long set of attributes, one would
be route type, but many others would be optional and may only apply to a given
route type. We
would appreciate some feedback –does it make sense to collapse into a generic
Route Object? Other suggestions are welcome. Thank
you. Please reply to the list. |
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.