Subject: [Speermint] [drinks] RE: LRF vs. LUF terminology

From: "Daryl Malas" <[email-masked]>
Date: Thu, 20 Nov 2008 10:20:50 -0700

Hadriel,

These should be copied or sent/discussed on the Speermint mailing list;
however, let's discuss these proposals during the Speermint meeting
today.

Regards,

Daryl

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: Thursday, November 20, 2008 10:14 AM
> To: [email-masked]
> Subject: [drinks] LRF vs. LUF terminology
> 
> At the end of the discussion of LRF vs. LUF, I was asked to 
> post suggested terminology wording changes on the list.
> I propose the following:
> - Change terminology to define LUF as:
> "The Look-Up Function (LUF) provides a mechanism for 
> determining for a given request the *terminating* domain to 
> which the request should be routed."
> - Change terminology to define LRF as:
> "The Location Routing Function (LRF) determines for the 
> *terminating* domain of a given request the location of the 
> SF in that domain and optionally develops other SED required 
> to route the request to that domain, *possibly through transit SSPs*."
> 
> Note the asterisks are to show the changes from current 
> wording - they are not going to be included in the proposal 
> to Speermint for actual use in the terminology doc.
> 
> Any objections/comments/suggestions?
> 
> -hadriel
> _______________________________________________
> drinks mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/drinks
> 
_______________________________________________
Speermint mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/speermint

---

From: "Daryl Malas" <[email-masked]>
Date: Thu, 20 Nov 2008 10:24:53 -0700

FYI...assuming these terminology changes are agreeable among the working
group, I have a nit with the second definition.

- Change terminology to define LRF as:
"The Location Routing Function (LRF) determines for the *terminating*
domain of a given request the location of the SF in that domain and
optionally develops other SED required to route the request to that
domain, *possibly through **indirect** SSPs*."

** Indicates nit change.

--Daryl

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Daryl Malas
> Sent: Thursday, November 20, 2008 10:21 AM
> To: Hadriel Kaplan; [email-masked]
> Cc: [email-masked]
> Subject: [Speermint] [drinks] RE: LRF vs. LUF terminology
> 
> 
> Hadriel,
> 
> These should be copied or sent/discussed on the Speermint 
> mailing list; however, let's discuss these proposals during 
> the Speermint meeting today.
> 
> Regards,
> 
> Daryl
> 
> ----------------
> Daryl Malas
> CableLabs
> (o) +1 303 661 3302
> (f) +1 303 661 9199
> > At the end of the discussion of LRF vs. LUF, I was asked to post 
> > suggested terminology wording changes on the list.
> > I propose the following:
> determining for a 
> > given request the *terminating* domain to which the request 
> should be 
> > routed."
> SF in that 
> > domain and optionally develops other SED required to route 
> the request 
> > to that domain, *possibly through transit SSPs*."
> > 
> wording - they 
> > are not going to be included in the proposal to Speermint 
> for actual 
> > use in the terminology doc.
> >

---

From: "David Schwartz" <[email-masked]>
Date: Thu, 20 Nov 2008 17:55:13 -0000

Here are my definitions...

"The Look-Up Function (LUF) provides a mechanism for determining for a given request the *identity of the requested resource on the terminating* domain."

Note I added "identity" as the LUF may modify the username portion, and I removed any mention of routing in the defintion of LUF (although I left the term "domain")

"The Location Routing Function (LRF) determines for the terminating domain of a given request *either* the location of the SF in that domain *or the location/s of SF/s leading to that domain* and optionally develops other SED required *for the purposes of this* routing.

Note the addition of both indirect routing as well as multiple paths to terminating domain.

Let the fireworks begin...

D.

-----Original Message-----
From: [email-masked] on behalf of Daryl Malas
Sent: Thu 11/20/2008 5:24 PM
To: Hadriel Kaplan; [email-masked]
Cc: [email-masked]
Subject: [Speermint]   [drinks] RE: LRF vs. LUF terminology

** Indicates nit change.

--Daryl

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Daryl Malas" <[email-masked]>
Date: Thu, 20 Nov 2008 11:13:29 -0700

David,
 
First, let me say this is not directed at you, but to this discussion.
I am merely using your email to reply to everyone on this discussion.
 
--------------
 
Before we decide to lift the proverbial hood on the car and start taking
a look at the terms once again, I decided to take a look at the semantic
disagreement between the use of "target" and "terminating" in the
Webster dictionary and the thesaurus.  Just for consideration, here is
what it says (skimming away the non-relevant definitions):
 
Target - "a goal to be achieved"; thesaurus (MS Outlook) - "aim, goal,
objective, object, end, intention"
Terminate (Terminating) - "to come to an end"; thesaurus (Microsoft
Outlook) - "end, finish, come to an end, conclude, etc."
 
With these two definitions in mind, please explain to me why the
separation of these two is not simply personal preference versus
complete incorrect use of an English word to define the term as you are
describing?
 
I am not opposed to clarifying the terminology draft, but I am not fully
convinced the two terms are different.
 
Regards,
 
Daryl

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199

________________________________

	From: David Schwartz [mailto:[email-masked]] 
	Sent: Thursday, November 20, 2008 10:55 AM
	To: Daryl Malas; Hadriel Kaplan; [email-masked]
	Cc: [email-masked]
	Subject: RE: [Speermint] [drinks] RE: LRF vs. LUF terminology

	"The Look-Up Function (LUF) provides a mechanism for determining
for a given request the *identity of the requested resource on the
terminating* domain."
	
	Note I added "identity" as the LUF may modify the username
portion, and I removed any mention of routing in the defintion of LUF
(although I left the term "domain")
	
	"The Location Routing Function (LRF) determines for the
terminating domain of a given request *either* the location of the SF in
that domain *or the location/s of SF/s leading to that domain* and
optionally develops other SED required *for the purposes of this*
routing.
	
	Note the addition of both indirect routing as well as multiple
paths to terminating domain.

	D.

	-----Original Message-----
	From: [email-masked] on behalf of Daryl Malas
	Sent: Thu 11/20/2008 5:24 PM
	To: Hadriel Kaplan; [email-masked]
	Cc: [email-masked]
	Subject: [Speermint]   [drinks] RE: LRF vs. LUF terminology
	
	FYI...assuming these terminology changes are agreeable among the
working
	group, I have a nit with the second definition.
	
	- Change terminology to define LRF as:
	"The Location Routing Function (LRF) determines for the
*terminating*
	domain of a given request the location of the SF in that domain
and
	optionally develops other SED required to route the request to
that
	domain, *possibly through **indirect** SSPs*."
	
	** Indicates nit change.
	
	--Daryl
	
	----------------
	Daryl Malas
	CableLabs
	(o) +1 303 661 3302
	(f) +1 303 661 9199

	> the Speermint meeting today.
post

______________________________________________________________________
	This email has been scanned by the MessageLabs Email Security
System.
	For more information please visit
http://www.messagelabs.com/email

---

From: "David Schwartz" <[email-masked]>
Date: Thu, 20 Nov 2008 18:40:15 -0000

No offense taken :)

My comments are not related to the difference between target and termination (those were introduced by others ;). My focus was identity/domain and the complete removal of "routing" information from LUF definition and the addition of path information and possibly multiple responses to the LRF.

If I do have to comment on the target/termination issue I would just say that due to historic preferences people seem more comfortable with the word termination.

D.

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]]
Sent: Thu 11/20/2008 6:13 PM
To: David Schwartz; Hadriel Kaplan; [email-masked]
Cc: [email-masked]
Subject: [Speermint]   [drinks] RE: RE: LRF vs. LUF terminology
 
David,

--------------

 

Regards,
 
Daryl

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199

	

	

	D.

	-----Original Message-----
	From: [email-masked] on behalf of Daryl Malas
	Sent: Thu 11/20/2008 5:24 PM
	To: Hadriel Kaplan; [email-masked]
	Cc: [email-masked]
	Subject: [Speermint]   [drinks] RE: LRF vs. LUF terminology

	
	** Indicates nit change.
	
	--Daryl
	
	----------------
	Daryl Malas
	CableLabs
	(o) +1 303 661 3302
	(f) +1 303 661 9199

post

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Nov 2008 14:03:51 -0500

The changes were posted to the Drinks mailing list because I asked in the Drinks WG meeting if I could propose them as coming from Drinks when presenting it to Speermint, rather than as individual.  The response was people wanted to see it on the mailing list first.

-hadriel

> Sent: Thursday, November 20, 2008 12:25 PM

---

From: Hendrik Scholz <[email-masked]>
Date: Thu, 20 Nov 2008 20:25:33 +0100

David Schwartz wrote:
> My focus was identity/domain and [...]

I second the identity vs domain point.
I'd like to throw in local number portability (LNP, WLNP, MNP) to help
explaining this.

For a given request (i.e. phone #) the LUF would return an LNP 
'identifier' or identity (i.e. D001).
The LRF would take this id and make a routing decision based on it.
It may be that in the last step the LRF figures that is has to set
a specific DNS domain name in the SIP request.

Cheers,
  Hendrik

-- 
Hendrik Scholz <[email-masked]>
_______________________________________________
Speermint mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/speermint

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Thu, 20 Nov 2008 14:31:42 -0500

I'd agree the LUF result should be "portability corrected" but the
actual response would not be a number portability data element (i.e.,
NOT an LRN or a SPID in the North American context). I DO  expect to see
a domain of some sort. 

Penn Pfautz
AT&T National Access Management
+1-732-420-4962

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hendrik Scholz
Sent: Thursday, November 20, 2008 2:26 PM
To: David Schwartz
Cc: [email-masked]; [email-masked]; Daryl Malas
Subject: Re: [Speermint] [drinks] RE: RE: LRF vs. LUF terminology

Cheers,
  Hendrik

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Nov 2008 14:32:35 -0500

If you believe the words "target" and "terminating" are equivalent, then it should be no difference if we simply swap the words in the terminology doc.
However the English definition is actually different.  When I go home from here, my "end" is my home in Nashua, NH.
To get to that "end", I have several "goals" to achieve: get to airport, fly to ORD, switch planes and fly to MHT, drive car to end. I could break those down further, of course.  But I cannot break down the "end" any further.
"Terminating" implies an end goal.  "Target" does not, it's just a goal, one of possibly many to get to the end goal.

-hadriel

Sent: Thursday, November 20, 2008 1:13 PM

David,

First, let me say this is not directed at you, but to this discussion.  I am merely using your email to reply to everyone on this discussion.

--------------

Before we decide to lift the proverbial hood on the car and start taking a look at the terms once again, I decided to take a look at the semantic disagreement between the use of "target" and "terminating" in the Webster dictionary and the thesaurus.  Just for consideration, here is what it says (skimming away the non-relevant definitions):

Target - "a goal to be achieved"; thesaurus (MS Outlook) - "aim, goal, objective, object, end, intention"
Terminate (Terminating) - "to come to an end"; thesaurus (Microsoft Outlook) - "end, finish, come to an end, conclude, etc."

With these two definitions in mind, please explain to me why the separation of these two is not simply personal preference versus complete incorrect use of an English word to define the term as you are describing?

I am not opposed to clarifying the terminology draft, but I am not fully convinced the two terms are different.

Regards,

Daryl

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199

D.

-----Original Message-----
From: [email-masked] on behalf of Daryl Malas
Sent: Thu 11/20/2008 5:24 PM
To: Hadriel Kaplan; [email-masked]
Cc: [email-masked]
Subject: [Speermint]   [drinks] RE: LRF vs. LUF terminology

** Indicates nit change.

--Daryl

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199

---

From: Hendrik Scholz <[email-masked]>
Date: Thu, 20 Nov 2008 20:41:38 +0100

> NOT an LRN or a SPID in the North American context). I DO  expect to see

Thanks for correcting this. I did not mean to tie this to the LNP/LRN
id but wanted to bring up a case where somebody would like to see 
something different than a DNS domain.

It should be a freely definable identifier. If the identifier is used
in a federation or obtained from a third party the format could be
part of the contract.

Cheers,
  Hendrik

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 20 Nov 2008 21:56:40 +0100

my 2 eurocent:

David Schwartz wrote:
> "The Look-Up Function (LUF) provides a mechanism for determining for a
> given request the *identity of the requested resource on the
> terminating* domain."

That's fine with me. I agree with some people here that "terminating" is
a lot clearer than "target" as the latter may be read as "target where the
source SSP sends the call to".

> 
> "The Location Routing Function (LRF) determines for the terminating
> domain of a given request *either* the location of the SF in that domain
> *or the location/s of SF/s leading to that domain* and optionally
> develops other SED required *for the purposes of this* routing.

This is a good idea. Maybe sneak in a "directly reachable" before the SFs.

When I just looked at the slides from Hadriel, I noticed that

"The Location Routing Function (LRF) determines for the target terminating
domain of a given request the location of the SF in that domain and
optionally develops other SED required to route the request to that domain,
possibly through transit SSPs."

doesn't make sense in the transit case. (as "he location of the SF in that
domain" doesn't apply.)

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //
_______________________________________________
Speermint mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/speermint

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 20 Nov 2008 22:02:30 +0100

> in a federation or obtained from a third party the format could be

IMHO the important part here is that this is an identifier is not just
valid inside a national context, but is a worldwide unique identifier.

I don't really care if it is

urn:ietf:speermint:nanp:att:nyc

or

nyc.destination-groups.att.com

or just

nyc.att.com

----

Pro domain:

* looking up further information regarding this identifier is trivial
  using the DNS and records stored at that domain name

Contra domain:

* this might make some people think that RFC 3263 does work for this domain

/ol

---

From: [email-masked]
Date: Thu, 20 Nov 2008 21:26:15 +0000

> nyc.destination-groups.att.com

The attached (incomplete) draft is one that I was working on prior to the 
creation of the DRINKS WG.

The Destination Groups described therein look much like your second 
example, and it was intended that these would be the output of the LUF.

Ray

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 20 Nov 2008 16:26:13 -0500

Well remember these are all abstractions in DRINKS terms.  We're only
talking about provisioning "something". We don't define what the LUF
protocol actually is.  A protocol response to a query may or may not include
both LUF and LRF data depending on what protocol the LUF actually is. 

>  From: [email-masked] [mailto:[email-masked]] On
>  Behalf Of PFAUTZ, PENN L, ATTCORP
>  Sent: Thursday, November 20, 2008 2:32 PM
>  To: Hendrik Scholz; David Schwartz
>  Subject: Re: [drinks] [Speermint] RE: RE: LRF vs. LUF terminology
>

---

From: "Terry Martin" <[email-masked]>
Date: Thu, 20 Nov 2008 16:31:19 -0500

I have been following this list off and on for a year and you are making
a lot of progress on how to deal with VoIP calling over a variety of
networks.  In this recent Email thread you have talked about identifying
the originating carrier or the router where the call originated.  Is
this correct? Will the protocol be able to identify the originating
carrier?

If so do you have a way of identifying the transiting network to allow
the terminating carrier the ability to collect reciprocal compensation?
Or is this part of the Speerment charter.

 I need to get on the IETF web site and review the most recent RFC

Thanks

Terry Martin

TimeData Corporation

VP of Network Operation

East Coast Number:     212-644-1600 X3

West Coast Number     503-678-2224

Cell:                            503-318-8909

From: [email-masked] [mailto:[email-masked]] On
Behalf Of David Schwartz
Sent: Thursday, November 20, 2008 9:55 AM
To: Daryl Malas; Hadriel Kaplan; [email-masked]
Cc: [email-masked]
Subject: Re: [Speermint] [drinks] RE: LRF vs. LUF terminology

Note I added "identity" as the LUF may modify the username portion, and
I removed any mention of routing in the defintion of LUF (although I
left the term "domain")

Note the addition of both indirect routing as well as multiple paths to
terminating domain.

D.

-----Original Message-----
From: [email-masked] on behalf of Daryl Malas
Sent: Thu 11/20/2008 5:24 PM
To: Hadriel Kaplan; [email-masked]
Cc: [email-masked]
Subject: [Speermint]   [drinks] RE: LRF vs. LUF terminology

** Indicates nit change.

--Daryl

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Fri, 21 Nov 2008 11:47:50 -0500

I am not sure I would agree.  Termination can also mean to release.
Because of its ambiguity, it can only be used where the context is
crystal clear as to the intent.  "Terminating the call" is the
poster-child.  Does that mean complete the call or release it?
 
One thing we do need to keep terms distinct is to be sure we don't lose
the distinction between the targetted user and the intermediate hops on
the way there, e.g. difference between target URI and the routes to get
there.
 
Mike

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of David Schwartz
	Sent: Thursday, November 20, 2008 1:40 PM
	To: Daryl Malas; Hadriel Kaplan; [email-masked]
	Cc: [email-masked]
	Subject: Re: [Speermint] [drinks] RE: RE: LRF vs. LUF
terminology

	No offense taken :)
	
	My comments are not related to the difference between target and
termination (those were introduced by others ;). My focus was
identity/domain and the complete removal of "routing" information from
LUF definition and the addition of path information and possibly
multiple responses to the LRF.
	
	If I do have to comment on the target/termination issue I would
just say that due to historic preferences people seem more comfortable
with the word termination.
	
	D.

	-----Original Message-----
	From: Daryl Malas [mailto:[email-masked]]
	Sent: Thu 11/20/2008 6:13 PM
	To: David Schwartz; Hadriel Kaplan; [email-masked]
	Cc: [email-masked]
	Subject: [Speermint]   [drinks] RE: RE: LRF vs. LUF terminology
	
	David,
	
	First, let me say this is not directed at you, but to this
discussion.
	I am merely using your email to reply to everyone on this
discussion.
	
	--------------
	
	Before we decide to lift the proverbial hood on the car and
start taking
	a look at the terms once again, I decided to take a look at the
semantic
	disagreement between the use of "target" and "terminating" in
the
	Webster dictionary and the thesaurus.  Just for consideration,
here is
	what it says (skimming away the non-relevant definitions):
	
	Target - "a goal to be achieved"; thesaurus (MS Outlook) - "aim,
goal,
	objective, object, end, intention"
	Terminate (Terminating) - "to come to an end"; thesaurus
(Microsoft
	Outlook) - "end, finish, come to an end, conclude, etc."
	
	With these two definitions in mind, please explain to me why the
	separation of these two is not simply personal preference versus
	complete incorrect use of an English word to define the term as
you are
	describing?
	
	I am not opposed to clarifying the terminology draft, but I am
not fully
	convinced the two terms are different.
	
	Regards,
	
	Daryl

	----------------
	Daryl Malas
	CableLabs
	(o) +1 303 661 3302
	(f) +1 303 661 9199

	
	        From: David Schwartz [mailto:[email-masked]]
	        Sent: Thursday, November 20, 2008 10:55 AM
	        To: Daryl Malas; Hadriel Kaplan; [email-masked]
	        Cc: [email-masked]
	        Subject: RE: [Speermint] [drinks] RE: LRF vs. LUF
terminology

	
	       
	        "The Look-Up Function (LUF) provides a mechanism for
determining
	for a given request the *identity of the requested resource on
the
	terminating* domain."
	       
	        Note I added "identity" as the LUF may modify the
username
	portion, and I removed any mention of routing in the defintion
of LUF
	(although I left the term "domain")
	       
	        "The Location Routing Function (LRF) determines for the
	terminating domain of a given request *either* the location of
the SF in
	that domain *or the location/s of SF/s leading to that domain*
and
	optionally develops other SED required *for the purposes of
this*
	routing.
	       
	        Note the addition of both indirect routing as well as
multiple
	paths to terminating domain.

	        D.

	        -----Original Message-----
	        From: [email-masked] on behalf of Daryl
Malas
	        Sent: Thu 11/20/2008 5:24 PM
	        To: Hadriel Kaplan; [email-masked]
	        Cc: [email-masked]
	        Subject: [Speermint]   [drinks] RE: LRF vs. LUF
terminology
	       
	        FYI...assuming these terminology changes are agreeable
among the
	working
	        group, I have a nit with the second definition.
	       
	        - Change terminology to define LRF as:
	        "The Location Routing Function (LRF) determines for the
	*terminating*
	        domain of a given request the location of the SF in that
domain
	and
	        optionally develops other SED required to route the
request to
	that
	        domain, *possibly through **indirect** SSPs*."
	       
	        ** Indicates nit change.
	       
	        --Daryl
	       
	        ----------------
	        Daryl Malas
	        CableLabs
	        (o) +1 303 661 3302
	        (f) +1 303 661 9199

	post

______________________________________________________________________
	        This email has been scanned by the MessageLabs Email
Security
	System.
	        For more information please visit
	http://www.messagelabs.com/email

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Fri, 21 Nov 2008 13:01:17 -0500

We may be splitting hairs here.  The target is an identity for a user,
but calls get terminated on a device.  So, in effect, you have reached
your target when the call gets terminated on that user's device.
 
Mike

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hadriel Kaplan
	Sent: Thursday, November 20, 2008 2:33 PM
	To: Daryl Malas; David Schwartz; [email-masked]
	Cc: [email-masked]
	Subject: Re: [Speermint] [drinks] RE: RE: LRF vs. LUF
terminology

	If you believe the words "target" and "terminating" are
equivalent, then it should be no difference if we simply swap the words
in the terminology doc.

	However the English definition is actually different.  When I go
home from here, my "end" is my home in Nashua, NH.

	To get to that "end", I have several "goals" to achieve: get to
airport, fly to ORD, switch planes and fly to MHT, drive car to end. I
could break those down further, of course.  But I cannot break down the
"end" any further.

	"Terminating" implies an end goal.  "Target" does not, it's just
a goal, one of possibly many to get to the end goal.

	-hadriel

	David,

	First, let me say this is not directed at you, but to this
discussion.  I am merely using your email to reply to everyone on this
discussion.

	--------------

	Before we decide to lift the proverbial hood on the car and
start taking a look at the terms once again, I decided to take a look at
the semantic disagreement between the use of "target" and "terminating"
in the Webster dictionary and the thesaurus.  Just for consideration,
here is what it says (skimming away the non-relevant definitions):

	Target - "a goal to be achieved"; thesaurus (MS Outlook) - "aim,
goal, objective, object, end, intention"

	Terminate (Terminating) - "to come to an end"; thesaurus
(Microsoft Outlook) - "end, finish, come to an end, conclude, etc."

	I am not opposed to clarifying the terminology draft, but I am
not fully convinced the two terms are different.

	Regards,

	Daryl

	----------------
	Daryl Malas
	CableLabs
	(o) +1 303 661 3302
	(f) +1 303 661 9199

		
		"The Look-Up Function (LUF) provides a mechanism for
determining for a given request the *identity of the requested resource
on the terminating* domain."
		
		Note I added "identity" as the LUF may modify the
username portion, and I removed any mention of routing in the defintion
of LUF (although I left the term "domain")

		Note the addition of both indirect routing as well as
multiple paths to terminating domain.

		D.

		-----Original Message-----
		
among the working
		
domain and
request to that
		
		** Indicates nit change.
		
		--Daryl
		
		----------------
		Daryl Malas
		CableLabs
		(o) +1 303 661 3302
		(f) +1 303 661 9199

terminology

Security System.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Nov 2008 23:46:02 -0500

> From: Mike Hammer (hmmr) [mailto:[email-masked]]
> Sent: Friday, November 21, 2008 11:48 AM
>
> One thing we do need to keep terms distinct is to be sure we don't lose the distinction between the targetted user > and the intermediate hops on the way there, e.g. difference between target URI and the routes to get there.

Yes exactly.  We are splitting hairs as you said in another email, but the reason I'm doing it is to try to make that distinction - the LUF provides the target AoR/URI, whereas the LRF provides the routes to reach it.  In SIP we *would* call it the target URI, so I'm cool with calling it that if we can figure out how to make the distinction clear to people who aren't well versed in IETF SIP WG nomenclature nuance.  And the only reason I think we need to be clearer is because not less than 15 minutes after the DRINKS WG meeting, I was talking with someone in the hallway who knows SIP but doesn't breath it in the IETF, who thought the target was always the next-hop.

-hadriel

---

From: "James McEachern" <[email-masked]>
Date: Mon, 24 Nov 2008 16:44:26 -0500

Ray,
In your document you state that...
   The proposed solution is therefore to register a new Enumservice and
   URI type (in line with [I-D.ietf-enum-enumservices-guide]) which
   returns an opaque reference to the real interconnection data.  The
   interpretation of that opaque reference is then a matter of bi-
   lateral agreement between carriers.

If the carriers are going to set up a bilateral agreement that specifies
how they will interpret the opaque reference, is there anything to stop
them from setting up a bilateral agreement that would allow them to
resolve a single URI (returned to anyone who queries) into a unique
interconnect point (known only to the parties in the bilateral
agreement)?  

Jim McEachern
T:+1 613 763-3419
M:+1 613 853-0176

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, November 20, 2008 4:26 PM
To: Otmar Lendl
Cc: [email-masked]; [email-masked]
Subject: Re: [Speermint] [drinks] RE: RE: LRF vs. LUF terminology

> nyc.destination-groups.att.com

The attached (incomplete) draft is one that I was working on prior to
the 
creation of the DRINKS WG.

Ray

---

From: [email-masked]
Date: Mon, 24 Nov 2008 22:01:46 +0000

> interconnect point (known only to the parties in the bilateral

If I understand your question correctly, that's exactly the intent.

Terminating Carrier B publishes a DG NAPTR record containing e.g. 
dg:foobar.dg.carrier-b.example.com.

Only Originating Carrier A has the bilaterally agreed lookup table that 
says that this DG corresponds to private-sbc.carrier-b.example.com.

Everyone else is missing the DG lookup for 'foobar' and would have to rely 
on default call routing.

Ray

---

From: "Uzelac, Adam" <[email-masked]>
Date: Tue, 25 Nov 2008 09:22:25 -0500

I think I understand what Jim's getting at here.  I believe he's asking a basic "what's the point?" type of question.  At least that's how I understand it.  The point really is to remove the LUF function requirement, and while it may appear to not add value in a standard bi-lateral requirement, it would add value in federation-like environments.  The LUF would return the same value to all the other members of the federation, but the LRF would return specific data pertaining to the relationship of the originator of the request, and the terminator (or target) of the request.

Adam

> Sent: Monday, November 24, 2008 5:02 PM
> To: James McEachern
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 25 Nov 2008 22:01:14 +0100

On 2008/11/25 15:11, "Uzelac, Adam" <[email-masked]> wrote:
> I think I understand what Jim's getting at here. I believe he's
> asking a basic "what's the point?" type of question. At least that's
> how I understand it. 

No, I think the question makes perfectly sense.

> The point really is to remove the LUF function
> requirement, and while it may appear to not add value in a standard
> bi-lateral requirement, it would add value in federation-like
> environments. The LUF would return the same value to all the other
> members of the federation, but the LRF would return specific data
> pertaining to the relationship of the originator of the request, and
> the terminator (or target) of the request.

I've already meant to write a mail on this, because I already saw the
same gotcha in a different mail in this thread:

If we want to support non-trivial transit routing in the Speermint
/ Drinks scenario (which I think we have to), then this has some
consequences regarding how the LUF is implemented and who operates it:

If the output of the LUF (whether it be just a FQDN, a Destination Group
identifier, or a AoR SIP URI) is meant to be the input to the LRF which
actually implements the multi-hop routing algorithm, this implies that
the LUF needs to be able to return a value for TNs which is not hosted
by one of the SSPs participating in a peering fabric (federation)
shared with the originating SSP.

Example: A small rural SSP in Montana needs to be able to map
+436641234567 to [email-masked] in order to select the best
path towards this Austrian mobile operator (i.e. which of its upstreams
advertises a better route towards mobilkom.at) even though it is
extremely unlikely that these two are members of the same federation /
peering fabric.

This is why I don't think that the LUF can be provided by federations.
It should be done by country-code, preferably within a global
Infrastructure-ENUM tree.

Regarding read permissions to that tree: To use the example from above,
the operator of the Austrian I-ENUM branch had no chance to decide
whether that query from Montana comes from a legitimate SSP, a
multi-homed PBX or just any other IP address.

I thus think (as noted in draft-lendl-speermint-background-02) that the
LUF needs to be implemented in the public DNS.

Which is actually fine and harmless, as there is absolutely no ingress-
point information stored there.

/ol
-- 
// Otmar Lendl <[email-masked]>, 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
_______________________________________________
Speermint mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/speermint