Daryl Malas | 4 Jan 00:56 2008
Picon

Change of email address

As of January 4, 2008, this email address (daryl@...) and
daryl.malas@... will no longer be a valid address to reach me
regarding comments or questions for the following two drafts:

draft-ietf-speermint-terminology-14
draft-ietf-speermint-architecture-04

Please use the interim email address of dmalas@... until further
notice.

Thank you,

Daryl Malas
Uzelac, Adam | 14 Jan 17:50 2008

Categorization of Federations

In the next release of the VoIP use-case ID for SPEERMINT, there is
going to be an effort to consolidate the Federation section of the
document into the agreed upon categorizations of Static/On-Demand, and
the subsequent subdivision of direct and indirect.  I am of the camp
that Federations should fall into the Static/Direct categorization,
while an argument can also be made to have Federations in the
On-Demand/Direct scenario. 

I would like to get a feel from the list on this topic.  Please comment.

Adam Uzelac
Director, Converged Network Arch and Planning
Global Crossing
585-563-4359
The IESG | 15 Jan 22:57 2008
Picon

Last Call: draft-ietf-speermint-consolidated-presence-im-usecases (Presence & Instant Messaging Peering Use Cases) to Informational RFC

The IESG has received a request from the Session PEERing for Multimedia 
INTerconnect WG (speermint) to consider the following document:

- 'Presence & Instant Messaging Peering Use Cases '
   <draft-ietf-speermint-consolidated-presence-im-usecases-03.txt> as an
Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@... mailing lists by 2008-01-29. Exceptionally, 
comments may be sent to iesg@... instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-speermint-consolidated-presence-im-usecases-03.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15839&rfc_flag=0
Daryl Malas | 17 Jan 22:38 2008
Picon

re:LUF vs. LF

I apologize for not responding to this discussion for awhile.  I would
like to propose the following updates:

>From this....

4.3.1. Look-Up Function
The Look-Up Function (LUF) provides a mechanism for querying an
internal and/or external database, which maintains a list of peered
host domains.

4.3.2. Location Function
The Location Function (LF) develops SED by discovering the Signaling
Function (SF), and SF's reachable host (IP Address and port).

In some cases, some entity (usually a 3rd party or federation)
provides peering assistance to either the originating SSP by providing
this function.  The assisting entity may provide information relating
to direct (Section 4.2.1) or indirect (Section 4.2.2) peering as
necessary.

To this....

4.3.1. Look-Up Function
The Look-Up Function (LUF) provides a mechanism for querying an
external centralized database of records accessible between two peers
or within the federation.  This database assists peers in the
discovery of target user agents by hosting a centralized set of
records between them.  (In some cases, a local replication of this
database may be used to potentially improve query performance;
however, functionally it is still the use of a centralized common
(Continue reading)

Daryl Malas | 17 Jan 23:24 2008
Picon

Re: Categorization of Federations

Adam,

The definition of a Federation is directly polarized to the concept of
On-demand, please see below:

4.2.3. On-demand Peering
SSPs are said to peer on-demand when they are able to exchange traffic
without any pre-association prior to the origination of a real-time
transaction (like a SIP message) between the domains.

[...without any pre-association prior...]

5. Federations
A federation is a group of SSPs which agree to receive calls from each
other via SIP, and who agree on a set of administrative rules for such
calls (settlement, abuse-handling, ...) and the specific rules for the
technical details of the peering.

I can add some verbiage to Section 5 to indicate Federations may only
peer in a static manner if it will clear up confusion.

--Daryl

On Jan 14, 2008 9:50 AM, Uzelac, Adam
<Adam.Uzelac@...> wrote:
> In the next release of the VoIP use-case ID for SPEERMINT, there is
> going to be an effort to consolidate the Federation section of the
> document into the agreed upon categorizations of Static/On-Demand, and
> the subsequent subdivision of direct and indirect.  I am of the camp
> that Federations should fall into the Static/Direct categorization,
(Continue reading)

Elwell, John | 18 Jan 10:20 2008
Picon

RE: re:LUF vs. LF

Daryl,

I think it is wrong to talk about UAs here. The existence of UAs will be
known only within the target domain, i.e., by the that domain's
registrar and domain proxy. A peer domain trying to route to a target
domain just needs to know how to do that - to route to the target
domain. It does not need to know (and indeed should not be able to find
out) anything about UAs in the target domain. The proposed definition of
LuF completely confuses me.

It would also be helpful to say what is the input to the LuF. Is it just
a telephone number (in other words, the LuF is a kind of ENUM look-up,
resulting in a SIP URI for the target user)?

Also, my reading of the definition of LF is that it could simply
comprise the functionality specified in RFC 3263. I other words, it
takes a target SIP/SIPS URI and locates a server. If this is the case,
it might be better to express it in those terms. If there is some
distinguishing feature that makes a LF somehow different from RFC 3263
server location functionality, then the definition must be more precise.

By the way, is the term "location function" liable to be confused with
the well-established RFC 3261 term "location service"? We may need to
find a different term, but until I understand what the two terms are
intended to mean, I cannot propose an alternative.

John

> -----Original Message-----
> From: Daryl Malas [mailto:dmalas@...] 
(Continue reading)

Daryl Malas | 18 Jan 16:15 2008
Picon

Re: re:LUF vs. LF

John,

I can easily remove UA's and simplify it to domains.  Since, you are
still confused by the definition, can you please propose some new
wording for these two terms?

IMO, this draft is being held up by these two terms.

Thanks...

Daryl

On 1/18/08, Elwell, John <john.elwell@...> wrote:
> Daryl,
>
> I think it is wrong to talk about UAs here. The existence of UAs will be
> known only within the target domain, i.e., by the that domain's
> registrar and domain proxy. A peer domain trying to route to a target
> domain just needs to know how to do that - to route to the target
> domain. It does not need to know (and indeed should not be able to find
> out) anything about UAs in the target domain. The proposed definition of
> LuF completely confuses me.
>
> It would also be helpful to say what is the input to the LuF. Is it just
> a telephone number (in other words, the LuF is a kind of ENUM look-up,
> resulting in a SIP URI for the target user)?
>
> Also, my reading of the definition of LF is that it could simply
> comprise the functionality specified in RFC 3263. I other words, it
> takes a target SIP/SIPS URI and locates a server. If this is the case,
(Continue reading)

Elwell, John | 18 Jan 16:39 2008
Picon

RE: re:LUF vs. LF

Daryl,

Trying to keep it simple, how about the following?

LuF: A function that determines for a given request the domain to which
the request should be routed.
LF: A function that determines for a given domain the location of a SIP
server in that domain and optionally other information needed to route a
request to that domain.

I have tried to keep this to a minimum, but if it is heading in the
right direction we can add to it if necessary. However, I am in favour
of concise definitions.

John

> -----Original Message-----
> From: Daryl Malas [mailto:dmalas@...] 
> Sent: 18 January 2008 15:16
> To: Elwell, John
> Cc: speermint@...
> Subject: Re: [Speermint] re:LUF vs. LF
> 
> John,
> 
> I can easily remove UA's and simplify it to domains.  Since, you are
> still confused by the definition, can you please propose some new
> wording for these two terms?
> 
> IMO, this draft is being held up by these two terms.
(Continue reading)

Daryl Malas | 18 Jan 16:55 2008
Picon

Re: re:LUF vs. LF

John,

Thank you for suggesting some new language.  Please review these
updated definitions, and provide feedback.  I also suggested some
possible term changes to make sure there is no confusion with
'Location Service' in 3261.

LUF:

The Look-Up Function (LUF) provides a mechanism for determining for a
given request the target domain to which the request should be routed.

Suggested term change from Location Function to:
Location Determination Function
Location Routing Function (I prefer this one.)

LRF:
The Location Routing Function (LRF) determines for a given domain the
location of the SF in the target domain and optionally develops other
SED required to route the associated request to that domain.

Thanks...--Daryl

On 1/18/08, Elwell, John <john.elwell@...> wrote:
> Daryl,
>
> Trying to keep it simple, how about the following?
>
> LuF: A function that determines for a given request the domain to which
> the request should be routed.
(Continue reading)

Elwell, John | 18 Jan 17:16 2008
Picon

RE: re:LUF vs. LF

Daryl,

See below.

John 

> -----Original Message-----
> From: Daryl Malas [mailto:dmalas@...] 
> Sent: 18 January 2008 15:56
> To: Elwell, John
> Cc: speermint@...
> Subject: Re: [Speermint] re:LUF vs. LF
> 
> John,
> 
> Thank you for suggesting some new language.  Please review these
> updated definitions, and provide feedback.  I also suggested some
> possible term changes to make sure there is no confusion with
> 'Location Service' in 3261.
> 
> LUF:
> 
> The Look-Up Function (LUF) provides a mechanism for determining for a
> given request the target domain to which the request should be routed.
[JRE] OK

> 
> Suggested term change from Location Function to:
> Location Determination Function
> Location Routing Function (I prefer this one.)
(Continue reading)


Gmane