Re: [PEPPERMINT] DRINKS Charter v 02

["Jean-Francois Mule" <[e-mail]>]

Rich,

   The draft charter looks ok but this attempt to limit the scope to one
of the protocols that can access or make use of this data is too
restrictive.  Said differently, the drops (data elements in DRINKS)
should be independent from the query protocol used to access it.  

   Find some comments inline to assist in the scope definition.

Jean-Francois.


> -----Original Message-----
> From: [e-mail] [mailto:peppermint-
> [e-mail]] On Behalf Of Richard Shockey
> Sent: Sunday, May 11, 2008 4:02 PM
> To: [e-mail]
> Subject: [PEPPERMINT] DRINKS Charter v 02
> 
> Well ..moving along here .. the IESG has made initial pass on
> DRINKS charter
> review and there are a few minor editorial changes that were
> suggested.
> First issues surrounding milestones which are minor and second
> further
> discussion of tightening and defining initial scope.
> 
> I want to make it clear again that any discussion of the need to
> limit scope
> is fruitless. The only relevant question is how.
> 
> I've suggested an additional sentence that defines initial scope of
> SED data
> shall be typically that involved in ENUM databases with limited
> exceptions
> and if there is WG desire to look at data types outside the scope
> of ENUM
> databases and registries that will trigger a recharter.
> 
> ******************
> 
> 
> Proposed Charter
> 
> 
> DRINKS Data for Reachability of Inter/tra-NetworK SIP
> 
> 
> Current Status: Proposed Working Group
> 
> 
> Mailing Lists:
> 
> [e-mail]
> 
> 
> General information about the mailing list is at:
> 
> https://www1.ietf.org/mailman/listinfo/peppermint
> 
> 
> Area Directorate: Real Time Applications (RAI)
> 
> 
> RAI Director(s):
> 
> Jon Peterson [e-mail]
> Cullen Jennings [e-mail]
> 
> Chairs: TBD
> 
> 
> PROPOSED CHARTER FOR PEPPERMINT
> 
> The IETF has been working on various aspects of SIP-enabled
> Multimedia
> administrative domains among SIP Service Providers (SSP's). 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.
> 
> 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.
> 
> Specifically, DRINKS 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),either
> internally or externally to the SSP. 


> RS: For the initial iteration of this
> charter, the SED data is assumed to be fields that might be
> provisioned for
> ENUM, with limited exceptions. 

On the one hand, this sentence does not say much given you have "with
limited exceptions". 
On the other hand, it means limiting the SED data subset to what can be
expressed or meaningful for ENUM.  Fundamentally, this seems wrong to
assume given deliverables (data exchanges between data registries, SSPs,
location functions -- not all will rely on ENUM).
I would be ok with including fields that might be provisioned for the
session establishment using ENUM and/or SIP.


> If the working group would like to
> work on
> data types unrelated to ENUM registries and databases, the WG will
> recharter. 


> RS:  In addition DRINKS will ensure that the SED and the
> SIP
> session data securely exchanged between the peering functions.
I don't understand what is meant here.  
Is it for DRINKS to ensure that the SED data can be securely exchanged
by protocol entities?



> Typical SED data might include:
> 
> + Routes
>      - Destination SIP/SIPS/TEL URI Egress and Ingress Routes
>      - Relevant route names, identifiers, and services
>      - Attributes affecting route selection
>      - PSTN database information
> 
>  + Targets
>      - Individual, ranges, or groups of user-agent identifiers
>      - Target aggregation entities (e.g. service areas) and
> target-to-aggregate associations
> 
> + Treatment Profiles
>      - Priority
>      - Location
> 
> Potential SED Data types not in scope will be session rating or
> other
> billing or pricing information between SSP's.
I would remove "potential" otherwise this is still left for further
discussion.

> 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
> 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.  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.
> 
> Administrative domains may exchange data directly between each
> other or
> might use an external registry to aggregate data from multiple
> administrative domains or multiple data providers into a single
> view.
> 
> 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
> 
> 
> Requirements for Session Establishment Data (SED) data exchanges.
> Status
> Proposed Standard.
> WGLC - Nov 08
> 
> Exchanging of Session Establishment Data (SED) from data providers
> to
> registries or between bi/multi-lateral partners. Intended Status -
> Proposed
> standard.
> WGLC - Jan 09
> 
> Exchange of Session Establishment Data (SED) from registries to
> Location
> Routing Function databases. Intended Status-Proposed Status.
> WGLC - Mar 09
To limit the scope, should one of the two last deliverables be declared
out-of-scope for now?  I guess the question is: do people on the list
feel that both the data-to-registry and registry-to-location function
problems need to be solved?  This seems 2 related but distinct problems
in scope.

As I commented at the mike in IETF#71, I personally think both are
valuable to solve in parallel but may be that is too much.  There was a
draft submitted to show an example of something that could feed into the
last deliverable.  
One thought would be to start from the bottom and move up the data
chain: what is used by quering entities that use SIP/ENUM from a
location routing function? then get that data model about right, before
you look at how data providers want to structure the multiple views
based on the roles played by data owners/users/intermediates.  Can you
declare one of the 2 out-of-scope and then recharter to add the second
deliverable once we get somewhere?


> 
> 
> 
> Richard Shockey
> Director, Member of the Technical Staff
> NeuStar
> 46000 Center Oak Plaza - Sterling, VA 20166
> PSTN Office +1 571.434.5651
> PSTN Mobile: [phone]
> <mailto:richard(at)shockey.us>
> <mailto:richard.shockey(at)neustar.biz>
> 
> 
> 
> _______________________________________________
> PEPPERMINT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/peppermint
_______________________________________________
PEPPERMINT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/peppermint