Re: [drinks] request for input

["Brian Rosen" <br at brianrosen.net>]

I?d rather this work not get ahead of other protocol work.

If there is some protocol effort for routing of ?phone-like? services, and
it doesn?t use NAPTRs, and it has information that NAPTRs don?t handle, then
let?s talk about it.

I?m not aware of such, and consequently, I'd like to keep the scope to what
we have, or can reasonably forecast.

Brian

From: Richard Shockey [mailto:richard at shockey.us] 
Sent: Monday, June 15, 2009 10:26 AM
To: 'Brian Rosen'; 'Guyton, Deborah A'; drinks at ietf.org
Subject: RE: [drinks] request for input

Trunkgroup?  The LRF whatever that really is..

A sore point for me BTW.  

Part of this is an attempt to make sure the data provisioned is agnostic to
the protocol used to retrieve it . Its not supported to be either ENUM or
SIP redirect centric.

From: drinks-bounces at ietf.org [mailto:drinks-bounces at ietf.org] On Behalf Of
Brian Rosen
Sent: Monday, June 15, 2009 9:55 AM
To: 'Guyton, Deborah A'; drinks at ietf.org
Subject: Re: [drinks] request for input

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
Sent: Sunday, June 14, 2009 10:37 PM
To: drinks at ietf.org
Subject: [drinks] request for input

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.