Subject: Re: [drinks] request for input

From: "Cartwright, Kenneth" <[email-masked]>
Date: Wed, 22 Jul 2009 15:32:05 -0400

Sorry for offering this delayed input on this subject.  But I'm catching up on some IETF related emails and activities today and wanted to offer some input on this subject.

1) I've waffled on this subject myself.
2) This discussion is occurring within the context of a provisioning protocol, not a resolution protocol.
3) This discussion is not about whether NAPTRs should be used in *resolution*.  It is whether NAPTRs should be used in *provisioning* within the context of SPPP.
4) NAPTRs are really best suited as *resolution* data structures, but granted the point of division between "provisioning system" and "resolution system" can be gray.  None the less, NAPTRs are primarily intended to provide standardization of the data structure that is passed between elements of the resolution system, not the provisioning system.
5) NAPTRs are of course ENUM centric, not SIP centric.
6) Both ENUM and SIP can be and are used as "resolution" protocols.  So having the provisioning system be somewhat resolution protocol agnostic could be a good thing, imo.  And could turn out to be absolutely necessary.
7) Some piece of software must collect, determine, and then use data elements to ultimately *build* a NAPTR.  But that does not mean that NAPTRs must be the data structure in which all such information is passed across all layers of a peering eco-system.
8) The piece of software that collects, determines, and then uses data elements to *build* a NAPTR could be the SPPP server, for example.  Or the SPDP server, or a combination of the two.  But the vital point here is that it need not be the SPPP client.
9) There is clear precedence here in separating/abstracting the provisioning protocol data structures from the resolution protocol data structures.  EPP, for example, does not have the EPP client pass in an NS record, or an A record.  Is has you "register a domain name for X years".  It has you "renew a domain name for X years", is has you "associate an NS name with a domain name", etc.  The EPP registry system then collects and adds to these data elements, send that set of information down to a resolution server.  The resolution server then uses these data elements and others to build a DNS response that adheres to the DNS RR resolution protocol standard.
7) Given the points above, I think it is certainly worth considering, and perhaps even preferable, that the data elements and objects that the SPPP provisioning protocol exposes not necessarily include a NAPTR object per se.  Instead SPPP can expose objects and contained date elements that can be used by the SPP server or the SPDP server to build NAPTRs.

Thanks for considering this.
Ken

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

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

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

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: [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.

Thank you. Please reply to the list.

_______________________________________________
drinks mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/drinks

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.