Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.

[Otmar Lendl <[e-mail]>]

Some more feedback:

On 2008/04/16 19:04, Richard Shockey <[e-mail]> wrote:
> 
> Chairs: TBD
> 
> 
> PROPOSED CHARTER FOR PEPPERMINT
> 
> The IETF has been working on various aspects of SIP-enabled Multimedia
> administrative domains among SIP Service Providers (SSPs. SSP's are entities
> that provide session services utilizing SIP signaling to their customers. In
> addition, the IETF has done significant work on data exchanges among various
> network elements. 

As these term are central to this charter, can you clarify:

Are "administrative domains" meant as equivalents to "autonomous
systems" in the BGP context?

Is an "administrative domain" usually the same as a SSP? 

> The ENUM and SPEERMINT working groups provide the underlying context for
> much of the intended work that the DRINKS working group will undertake.:
> 
> The ENUM working group is specifically chartered to develop protocols that
> involve the translation of E.164 numbers to URIs.  While the SPEERMINT
> working group has been chartered to develop requirements and best current
> practices among real-time application SSPs and to describe how such services
> may best interconnect across administrative boundaries.  
> 
> More specifically, SPEERMINT will provide details of how Session
> Establishment Data (SED) is collected, what comprises SED, how SED should be
> used to properly identify an optimal path to a destination SIP user agent
> (UA), and the secure manners in which SED and the SIP session data is
> exchanged between the peering functions.
> 

> It is also recognized that peering relationships become more complex as
> multiple peers are added to a common relationship; these complex aspects and
> requirements are defined within the contexts of a peering Federation.  
> 
> The DRINKS working group is chartered with a scope that is orthogonal to
> SPEERMINT and ENUM.  The protocol work OF DRINKS will be designed to build

lowercase "OF".

> from the work of SPEERMINT and ENUM to identify and define the data
> structures and data exchange protocol(s) among SIP based Multimedia
> administrative domains.
> 
> These administrative domains may be of any practical size and could be any
> type of SSP, such as recognized telephony carriers, enterprises, end-user
> groups, or Federations.  

I think we have a problem here. IMHO we should not mix single SSPs
(carriers, enterprises) with groups of SSPs (federations). This will
bite us when doing the protocol design.

User/numbers are always uniquely tied to a single SSP. This is the
owner of that number. Or, in BGP speak, the origin. 

Federations do not have that property: as a SSP can be a member in
multiple federations, his numbers/users appear in the data-set
of more than one federation. Whenever these federation announce their
routes to a yet another SSPs, it will get conflicting information.

This doesn't jive with the "let's do simple registry provisioning"
tone of this document.

> Data exchanges among these administrative domains
> may be bi-lateral or multi-lateral in nature, and could include bulk updates
> and/or more granular real-time updates.
> 
> Typical data includes the mapping of phone numbers to URIs, policies
> surrounding admission to various points of network interconnection, and
> various other types of interconnect data.  In addition, there is a specific
> need for the exchange of such data between the Registry and various types of
> PSTN network databases.

Whoa, hold your horses.

"the Registry?"

Nothing up to here requires a Registry. From the preceding paragraph:
we're dealing with "bi-lateral or multi-lateral data exchanges". If
two SSPs have a bi-lateral data exchange, they don't need a Registry.
"multi-lateral" exchanges could also be facilitated by a simple data
replicator, similar to the role of "route reflectors" in BGP.

Yes, given your background, I can see why you assume that a "Registry"
needs to be part of the solution, but this not a given at all.

A "Registry" is just one potential solution. We should not prejudice
that in the charter.

> The working group will draw upon expert advice and on-going consultation
> from the ENUM and SPEERMINT working groups, and also the XML Directorate.
> The working group will consider the reuse of elements of RFC 4114.
> 
> The final work product(s) from this working group will utilize and be based
> on XML documents and XML document exchanges.
> 
> PROPOSED GOALS AND MILESTONES
> 

What about writing a 

High-level description of the overall VoIP routing architecture, 
players and data-flows.

first? 

That is sorely missing in speermint.

> 
> Requirements for Session Establishment Data (SED) data exchanges.
> Sept 08 
> 
> Provisioning of Session Establishment Data (SED) registries.
> Nov 08

See comment re: registries above.

> 
> Provisioning of Localized Session Establishment Data (SED) caches.
> 

/ol
-- 
// Otmar Lendl <[e-mail]>, T: [phone] - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg
_______________________________________________
PEPPERMINT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/peppermint