Subject: [drinks] <targetdomain> and the query resolution server...

From: "Ali, Syed Wasim" <[email-masked]>
Date: Fri, 2 Apr 2010 15:29:26 -0400

Hi,

The <targetDomain> in the route group add request-group below supports the
RFC3263 mechanics. If a TN is activated and associated with this
route-group, what is not immediately clear is how this information will be
returned in a ENUM response or a SIP redirect.

<?xml version="1.0" encoding="UTF-8"?>
<addRteGrpsRqst xmlns="urn:ietf:params:xml:ns:sppp:base:1"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1
file:/Users/sali/syed/projects/DRINKS/proto-02f/proto-02f.xsd">
    <basicRqst>
        <clientTransId>id-8173467292</clientTransId>
        <minorVer>50</minorVer>
    </basicRqst>
    <rteGrp>
        <base>
            <rantId>registrantId0</rantId>
            <rarId>registrarId0</rarId>
            <effDate>2006-05-04T18:13:51.0Z</effDate>
        </base>
        <rteGrpName>route_grp_1</rteGrpName>
        <targetDomain>ssp1.example.com</targetDomain>
        <rteRec xsi:type="NAPTRType" ttl="1000">
                <order>10</order>
                <pref>100</pref>
                <svcs>E2U+sip</svcs>
                <regx>
                    <ere>^(.*)$</ere>
                    <repl>sip:\1;[email-masked]</repl>
                </regx>
        </rteRec>
        <isInSvc>true</isInSvc>
    </rteGrp>
</addRteGrpsRqst>

During the WG meeting in Anaheim, Jon and others noted that one choice would
be to express it as a route.

.....
        <rteRec xsi:type="URIType">
            <value>sip:ssp1.example.com</value>
        </rteRec>
        <rteRec xsi:type="NAPTRType" ttl="1000">
                <order>10</order>
                <pref>100</pref>
                <svcs>E2U+sip</svcs>
                <regx>
                    <ere>^(.*)$</ere>
                    <repl>sip:\1;[email-masked]</repl>
                </regx>
        </rteRec>
.....

OR

.....
        <rteRec xsi:type="NAPTRType" ttl="1000">
                <order>10</order>
                <pref>100</pref>
                <svcs>E2U+sip</svcs>
                <regx>
                    <ere>^(.*)$</ere>
                    <repl>sip:ssp1.example.com</repl>
                </regx>
        </rteRec>
        <rteRec xsi:type="NAPTRType" ttl="1000">
                <order>10</order>
                <pref>100</pref>
                <svcs>E2U+sip</svcs>
                <regx>
                    <ere>^(.*)$</ere>
                    <repl>sip:\1;[email-masked]</repl>
                </regx>
        </rteRec>
.....

I think we can do away with the <targetdomain> node element completely in
favor of using existing means available. If the intent is highlight the fact
that a given URI has a domain that will yield a SIP location based on
RFC3263 mechanics, then perhaps we can consider introducing an attribute
called targetdomain as in,

.....
        <rteRec xsi:type="URIType" targetdomain="true">
            <value>sip:ssp1.example.com</value>
        </rteRec>
        <rteRec xsi:type="NAPTRType" ttl="1000">
                <order>10</order>
                <pref>100</pref>
                <svcs>E2U+sip</svcs>
                <regx>
                    <ere>^(.*)$</ere>
                    <repl>sip:\1;[email-masked]</repl>
                </regx>
        </rteRec>
.....

thoughts?

-Syed

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Wed, 7 Apr 2010 15:38:49 -0400

Hi Syed,

Thanks for putting together this proposal.  A few comments...

Target Domain
----------------

For some reason, modeling the targetDomain as a URIType object with a flag indicating that that URIType object instance is the target domain does not sit well with me.  It seems that we are muddying up the URIType object for this one special case.  Should we not add in another RteRecType object type whose type is Target Domain, and whose value must be a well formed URI.

NPDI Indicator
--------------------

You show an SPPP client provisioning in the "npdi" indicator as a string embedded in the NAPTR replacement string.  Doing so makes this piece of information somewhat opaque/hidden from the business logic of the SPPP implementing application.  Furthermore, it may be the SPPP server's job to do the number portability lookup.  So allowing the client to provision it in could be in appropriate at best, and dangerous at worst.

Regardless of how one might feel about the merits of this "npdi provisioned in by the client question", if we want that to be allowed then I think we need to have a use case that explains when it is necessary and when it is not.  Perhaps elements like this, if there have use cases that justify them, should be broken out into a separate field.

TTL Value
--------------------

It seems that adding this into the model has added a notable amount of complexity (i.e. the need for the RDType structure.  I think the TTL value should not be in there.  Is there a use case that necessitates allowing the clients to provision this into the system?  I cannot think of one.  If there is one, we need to add it into the use cases.

Thanks for considering these points.
Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali, Syed Wasim
Sent: Friday, April 02, 2010 3:29 PM
To: [email-masked]
Subject: [drinks] <targetdomain> and the query resolution server...

Hi,

.....

OR

.....

.....

thoughts?

-Syed

_______________________________________________
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.

---

From: "Ali, Syed Wasim" <[email-masked]>
Date: Thu, 8 Apr 2010 08:27:41 -0400

Ken, 

Thanks for the feedback. Please, see below:

On 4/7/10 3:38 PM, "Cartwright, Kenneth" <[email-masked]> wrote:

> For some reason, modeling the targetDomain as a URIType object with a flag
> indicating that that URIType object instance is the target domain does not sit
> well with me.  It seems that we are muddying up the URIType object for this
> one special case.  Should we not add in another RteRecType object type whose
> type is Target Domain, and whose value must be a well formed URI.
Thinking modeling, I am not sure if capturing a route record called
targetDomainType and requiring a URI, and not a fqdn, is a better choice.
;-)  Any how, while I understand that a route record called targetDomainType
creates added emphasis, for ENUM and SIP query resolution servers today,
there is no tangible indicator to highlight this. For the query resolver,
what they receive is a URI, be it in a Contact header or a NAPTR. In the
proposed method, there is also flexibility for existing ENUM centric
solutions that are using a NAPTR record to populate this information today,
such as,  

         <rteRec xsi:type="NAPTRType" targetdomain="true">
                 <order>10</order>
                 <pref>100</pref>
                 <svcs>E2U+sip</svcs>
                 <regx>
                     <ere>^(.*)$</ere>
                     <repl>sip:ssp1.example.com</repl>
                 </regx>
         </rteRec>

> 
> 
> NPDI Indicator
> --------------------
> 
> You show an SPPP client provisioning in the "npdi" indicator as a string
> embedded in the NAPTR replacement string.  Doing so makes this piece of
> information somewhat opaque/hidden from the business logic of the SPPP
> implementing application.  Furthermore, it may be the SPPP server's job to do
> the number portability lookup.  So allowing the client to provision it in
> could be in appropriate at best, and dangerous at worst.
> 
> Regardless of how one might feel about the merits of this "npdi provisioned in
> by the client question", if we want that to be allowed then I think we need to
> have a use case that explains when it is necessary and when it is not.
> Perhaps elements like this, if there have use cases that justify them, should
> be broken out into a separate field.
I completely agree with your assessment. The example was pulled from the
protocol slides used in the WG meeting in Anaheim and any mention of 'npdi'
in the XML instance was purely accidental.

> 
> TTL Value
> --------------------
> 
> It seems that adding this into the model has added a notable amount of
> complexity (i.e. the need for the RDType structure.  I think the TTL value
> should not be in there.  Is there a use case that necessitates allowing the
> clients to provision this into the system?  I cannot think of one.  If there
> is one, we need to add it into the use cases.
You are right, the use case should be added. We have situations where the
querying entity uses caching DNS server to query records to maximize
localized lookups and only reach out to the authoritative server when either
the TTL expires or another trigger that enables the querier to create an
authoritative only query.

> are not the intended recipient, please contact the sender by reply e-mail and
> destroy all copies of the original message.
>

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 8 Apr 2010 10:02:34 -0400

Ok.  Maybe I didn't understand your proposal fully.  You had suggested this. Which I think makes sense, aside from a minor personal nit about muddying up the definition of the URIType with the targetDomain attribute...

>                     <repl>sip:\1;[email-masked]</repl>

But in this recent response you show this below.  Putting these two together seems to suggest that you are proposing putting the targetDomain as an attribute on the base RteRecType.  Maybe we can discuss this on the call.

Ken

-----Original Message-----
From: Ali, Syed Wasim [mailto:[email-masked]]
Sent: Thursday, April 08, 2010 8:28 AM
To: Cartwright, Kenneth; [email-masked]
Subject: Re: <targetdomain> and the query resolution server...

Ken,