Subject: [drinks] request for input

From: "Guyton, Deborah A" <[email-masked]>
Date: Sun, 14 Jun 2009 22:37:06 -0400

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.

---

From: "Douglas Ranalli" <[email-masked]>
Date: Mon, 15 Jun 2009 09:02:37 -0400

Deborah,

I support the approach of using a Route Object.  DNS is not the only
protocol that is used today to access interconnect routing information and
DNS/ENUM may not survive as the long term query-response protocol for
accessing interconnect routing data.  The one thing we can be sure of is
that new protocols will be developed by the IETF as we move forward as an
industry.   

Doug

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Guyton, Deborah A
Sent: Sunday, June 14, 2009 10:37 PM
To: [email-masked]
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.

---

From: David Schwartz <[email-masked]>
Date: Mon, 15 Jun 2009 16:21:53 +0300

Hi Deborah

In general I would caution against following the DNS model blindly, so to answer your question I would say yes.

On a more general note, is there a preliminary model I can view? Are you referring to the ESPP one? If so, I have some comments relating to the data model.

Is this the forum for that or is it premature to raise my issues?

David
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Guyton, Deborah A
Sent: Monday, June 15, 2009 5:37 AM
To: [email-masked]
Subject: [drinks] request for input

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 15 Jun 2009 09:54:30 -0400

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: David Schwartz <[email-masked]>
Date: Mon, 15 Jun 2009 17:01:22 +0300

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: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Monday, June 15, 2009 4:55 PM
To: 'Guyton, Deborah A'; [email-masked]
Subject: Re: [drinks] request for input

Brian

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 15 Jun 2009 08:02:53 -0600

I'd like to echo Brian's comment, it is what some in the design team
think.  The NAPTR gives us quite a bit of flexibility to express what a
response to a LUF or LUF+LRF resolution query could be.

When trying to build something more generic than a DNS RR like NAPTR,
you basically end up doing the following:

-          Take NAPTR fields out of that structure and put them as
attributes of a new object

-          Define ways to properly return URIs

-          Try and re-create the meaning of svces in NAPTR

-          Add something close to order and preference fields in NAPTR

Bottom line, given the implementations of NAPTRs in the space we're
targeting, is there really something you can't do with a NAPTR?

Jean-Francois

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Monday, June 15, 2009 7:55 AM
To: 'Guyton, Deborah A'; [email-masked]
Subject: Re: [drinks] request for input

Brian

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Guyton, Deborah A
Sent: Sunday, June 14, 2009 10:37 PM
To: [email-masked]
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.

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Mon, 15 Jun 2009 10:20:09 -0400

Debbie:
While flexibility is a good thing and I think that the model should
incorporate at least a variety of RR types, I'm not in favor of defining
some new object with a bunch of attributes in the absence of seeing how
that would actually work. I'm concerned that it will lead to more work
on the backend.
Are there specific proposals for how the generic route object would be
set up? 
 
Penn Pfautz
AT&T Access Management
+1-732-420-4962

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 15 Jun 2009 10:25:38 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: Monday, June 15, 2009 9:55 AM
To: 'Guyton, Deborah A'; [email-masked]
Subject: Re: [drinks] request for input

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 15 Jun 2009 10:46:25 -0400

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:[email-masked]] 
Sent: Monday, June 15, 2009 10:26 AM
To: 'Brian Rosen'; 'Guyton, Deborah A'; [email-masked]
Subject: RE: [drinks] request for input

A sore point for me BTW.  

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

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.

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 17 Jun 2009 10:14:35 -0600

Hi David,

 You asked:
> On a more general note, is there a preliminary model I can view?
> Are you referring to the ESPP one? If so, I have some comments
> relating to the data model.

Just sent you what the design team has come up with.  If you can post it onto a wiki somewhere and give a link for all folks here, even better.

Jean-François

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of David Schwartz
> Sent: Monday, June 15, 2009 7:22 AM
> To: Guyton, Deborah A; [email-masked]
> In general I would caution against following the DNS model blindly,
> so to answer your question I would say yes.
> 
> On a more general note, is there a preliminary model I can view?
> Are you referring to the ESPP one? If so, I have some comments
> relating to the data model.
> 
> ________________________________________
> 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.
>