See responses inline. -----Original Message----- From: drinks-bounces at ietf.org [mailto:drinks-bounces at ietf.org] On Behalf Of Otmar Lendl Sent: Monday, July 27, 2009 11:13 AM To: drinks at ietf.org Subject: [drinks] Comment on the NAPTR question This is too long to be asked on the Jabber channel, but let me bring it up here: The question was whether we can capture all information needed in NAPTR records. I think that is definitetly the case for the Number->DestinationGroup mapping. KJC> Agree, I think. NAPTRs are well suited to give LUF responses, depending on how one described the role of the LUF. Given that the LUF will return "ownership/responsibleParty" data for a given lookup key (e.g. a TN), NAPTRs can hold that in the form of a URI whose domain name portion dictates the current "owner/responsibleParty". However, the phrasing in speermint arch draft does not quite read this way. It describes the LUF as returning a domain name, while others in the WG meetings have described it as returning a URI. The latter seems to be more accurate and more amenable to NAPTRs. And this seems to just be a wording problem with the architecture draft rather than a structural problem. Stupid Question: Would it be possible to have the Registry push the relevant DestinationGroup/RouteGroup/NAPTR data to its customer's SIP devices independently of any actual call? This is basically a routing table dump. This is the merged with local internal routing data to build the local data structures needed to generate full SED (internal routing to get to the egress element, next external hop, SIP parameters, security parameters, ...) based on a DestGroup as input. KJC> The key part of this question is of course "independently of any actual call". On the surface at least the answer seems to be "Yes". However, at least two caveats are necessary. (1) The "NAPTR" data referred to above that holds some portion of the SED data necessary to complete the call may need to be supplemented with additional SED data derived locally by other means. So if the receptacle for sending SED data is NAPTRs then those NAPTRs *may* have to be locally "massaged" to complete that specific call. (2) The case of source based routing needs to be recognized here. If the source of each individual call can impact the routing decision, wich it certainly can, then the "source identifiers" associated with any given RouteGroup must also be sent down. And the granularity to which source based routing must be supported (caller's domain name, callers TN Prefix, queriers IP address, etc) will impact the amount of data sent down. Only the TN/PI -> DestGroup mapping is done by a live, on-demand query to the Registry (or a locally cached copy). This is the only time when we actually need to transmit NAPTRs on the wire between the registry and the querying party. KJC> Good Point. Your "background" draft from last October also described this. However, this assumes that SSPs are willing to make routing queries to services residing *outside* their local network, incurring the resulting propagation delay. This is not always acceptable. ------------- What I'm fearing is that we try to use ENUM/NAPTRs as a SIP-Proxy control protocol. It was never designed for that. It can be coaxed to support simple scenarions. More complexity can be supported in the answers (the ugly: URI mentioned today), but it ENUM just can't support complextity in the quesion. See http://tools.ietf.org/html/draft-lendl-speermint-background-02#section-6.2 for a more verbose explanation. All the latest perversions suggested as feature for ENUM (source-dependent lookups, Trunk-groups) stem from this mistake. KJC> Agree that a better data structure could be devised to hold and to communicate SED than NAPTRs. /ol -- // Otmar Lendl <lendl at nic.at>, T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg _______________________________________________ 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.