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: drinks-bounces at ietf.org [mailto:drinks-bounces at ietf.org] On Behalf Of Brian Rosen Sent: Monday, June 15, 2009 10:46 AM To: 'Richard Shockey'; 'Guyton, Deborah A'; drinks at ietf.org 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: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. _______________________________________________ drinks mailing list drinks at ietf.org 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.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.