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

From: "Richard Shockey" <[email-masked]>
Date: Wed, 16 Apr 2008 13:19:50 -0400

I think I have incorporated most of the comments received to date based on
Darlys first draft.

More are certainly needed.

Specifically thanks to Ken Cartwright who made excellent grammatical
suggestions.

************************

DRINKS Proposed Charter 

Data for Reachability of Inter/tra-NetworK SIP

Current Status: Proposed Working Group

Mailing Lists: 

[email-masked]

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 [email-masked]
Cullen Jennings [email-masked]

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. 

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

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.

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.
Sept 08 

Provisioning of Session Establishment Data (SED) registries.
Nov 08

Provisioning of Localized Session Establishment Data (SED) caches.

Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
PSTN Office +1 571.434.5651 
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>

_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 16 Apr 2008 14:06:47 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> ************************
> DRINKS Proposed Charter

We'll need a new mailing list name (or alias) for [email-masked]. :)

> administrative domains among SIP Service Providers (SSPs. SSP's are

Typo: "(SSPs" should be "(SSPs)".

> entities

Remove last period, or last colon.

> need for the exchange of such data between the Registry and various types

Is there only one Registry? ;)  Change "the Registry" to "a Registry".

> Provisioning of Session Establishment Data (SED) registries.

I think you mean "Data model of SED Registries"? (I'm not really quite sure what this milestone is?)

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

I think you mean "Exchanging Session Establishment Data (SED) between Lookup Function or Location Routing Function Databases."

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 16 Apr 2008 15:36:14 -0400

TKS ... in line ...

>  I think you mean "Exchanging Session Establishment Data (SED) between
>  Lookup Function or Location Routing Function Databases."

Is this better.

Exchanging of Session Establishment Data (SED) from data providers to data
registries.
Nov 08

Exchanging of Localized Session Establishment Data (SED) from data
registries to Lookup Function or Location Routing Function databases.
Feb 09

---

From: Dan York <[email-masked]>
Date: Wed, 16 Apr 2008 19:29:55 -0400

Richard,

I do have one VERY serious problem with this revised charter.  If the  
group name is changed to DRINKS, then I will have lost my opportunity  
to submit an Internet-Draft titled "draft-york-peppermint-pattie"[1].   
Although I suppose the new name does allow everyone to join in the  
creative naming fun... I can just see... "draft-shockey-drinks-too- 
many-sips"... "draft-bond-drinks-sip-shaken-not-stirred"... "draft- 
kaplan-drinks-sips-with-no-identity-challenge"...

Seriously, it looks good overall and does make sense to change the  
name.   I do like how the charter makes it clear how DRINKS relates to  
ENUM and SPEERMINT.

Outside of the nits Hadriel already pointed out, I'll only add a few  
> SPEERMINT and ENUM.  The protocol work OF DRINKS will be designed to  

DY> "OF" should be lowercase.

> need for the exchange of such data between the Registry and various  

DY> Will you be changing this per Hadriel's comment to "a Registry"?

DY> Do you see the data to be exchanged to also include information  
using in billing?

DY> I see nothing in the charter about ensuring that the data is  
exchanged securely between the various administrative domains but I  
would assume this is a necessary requirement.  Is that just an  
implicit assumption that security will be covered in the Requirements  
document? (i.e. no explicit statement is necessary in the charter?)

Regards,
Dan

[1] For those outside North America who have perhaps never sampled the  
candy, see: http://en.wikipedia.org/wiki/York_Peppermint_Pattie
-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 16 Apr 2008 21:15:01 -0400

>  kaplan-drinks-sips-with-no-identity-challenge"...

Alas this is true .. I will no longer be known a Peppermint Patty but only
as the Bartender, something I can professionally live with since in a
earlier life I was a professional in the field.

Again we must consider our overall obligations to the IETF for cute WG
naming which we both agree will inspire much inspired document naming and
hopefully some April 1 RFC's. Whatever it takes ...

>  name.   I do like how the charter makes it clear how DRINKS relates to

Thanks are due not to me but to Daryl and Ken that did most of the heavy
lifting. I was only the charter editor, if a somewhat bad typist.

>  DY> "OF" should be lowercase.

TKS ..will do ..

>  DY> Will you be changing this per Hadriel's comment to "a Registry"?

Again yes you are correct the proper term is to "a" registry.

>  DY> Do you see the data to be exchanged to also include information

IMHO no .. that would be a charter stretch I personally believe the
AD's/IESG would not accept, at this time. Remember this is a new WG. The
first order of business is to produce results based on a limited set of
initial tasks. On the basis of initial WG success it is always possible to
build on success to take on other tasks the WG deems useful.

>  document? (i.e. no explicit statement is necessary in the charter?)

A excellent point but all IETF WG documents have a explicit requirement to
define any security issues associated with the protocol being defined.
Therefore, as you point out, there is no explicit requirement to define
security requirements in the charter.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 17 Apr 2008 10:21:29 -0400

> Behalf Of Richard Shockey
>
> Is this better.
>

Yup, that's a good one.

> Exchanging of Session Establishment Data (SED) from data providers to data

I think I can read that a couple different ways, but I'm ok with it.

> registries to Lookup Function or Location Routing Function databases.

I think the term "data registries" is quite ambiguous, but I actually like that property of it, so I'm good with this too. :)

-hadriel

---

From: Otmar Lendl <[email-masked]>
Date: Sat, 19 Apr 2008 23:06:54 +0200

Some more feedback:

> addition, the IETF has done significant work on data exchanges among various

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? 

> SPEERMINT and ENUM.  The protocol work OF DRINKS will be designed to build

lowercase "OF".

> 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

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.

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

> Provisioning of Session Establishment Data (SED) registries.

See comment re: registries above.

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

/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
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 20 Apr 2008 00:42:05 -0400

> Behalf Of Otmar Lendl

My interpretation of an "administrative domain" is just a set of SIP resources under control of a single administrator entity.  So for example, a set of proxies in an Enterprise acme.com may be one administrative domain; or it may be that ny.acme.com is a distinct administrative domain from dc.acme.com or wien.acme.com.  In other words, yes I think an SSP is an administrative domain, and is a similar concept as BGP AS's (but obviously orthogonal to actual BGP AS's).  It is likely we will have to define how to identify an administrative domain for the purposes of a protocol, but we can do that in the docs if we need to.

> bite us when doing the protocol design.

I don't think that sentence restricts it, since it says "could be" and we can later decide to restrict it further, but yeah it's weird to think of a Federation as being an SSP.

> > need for the exchange of such data between the Registry and various

That should be "a registry".

> replicator, similar to the role of "route reflectors" in BGP.

I had the same worry as you, but I think we'd just say "a registry" is simply consumed inside one or both of the SSP's.  I've always assumed a registry is simply a data store for LUF data - there could be many such data stores, and their data is either internal or external to an SSP or both.  For a bilateral peering model, SSP1 needs to learn the LUF data from SSP2's internal registry, and SSP2 needs to learn the LUF data from SSP1's internal registry.

> That is sorely missing in speermint.

Isn't that Speermint's role to do?  (I'm not clear on that either)

-hadriel

---

From: Otmar Lendl <[email-masked]>
Date: Sun, 20 Apr 2008 23:11:01 +0200

On 2008/04/20 06:04, Hadriel Kaplan <[email-masked]> wrote:
> My interpretation of an "administrative domain" is just a set of
> SIP resources under control of a single administrator entity. So
> for example, a set of proxies in an Enterprise acme.com may be one
> administrative domain; or it may be that ny.acme.com is a distinct
> administrative domain from dc.acme.com or wien.acme.com. In other
> words, yes I think an SSP is an administrative domain, and is a
> similar concept as BGP AS's (but obviously orthogonal to actual
> BGP AS's). It is likely we will have to define how to identify an
> administrative domain for the purposes of a protocol, but we can do
> that in the docs if we need to.

This makes sense.  

> I don't think that sentence restricts it, since it says "could be" and
> we can later decide to restrict it further, but yeah it's weird to
> think of a Federation as being an SSP.

Then let's take "federations" out of this definition NOW.

> I had the same worry as you, but I think we'd just say "a registry" is
> simply consumed inside one or both of the SSP's. I've always assumed
> a registry is simply a data store for LUF data - there could be many
> such data stores, and their data is either internal or external to an
> SSP or both. For a bilateral peering model, SSP1 needs to learn the
> LUF data from SSP2's internal registry, and SSP2 needs to learn the
> LUF data from SSP1's internal registry.

A "registry" within a SSP is simply a "database". The word "registry"
implies some kind of centralized database (with a provisioning and an
access protocol). If that is not what we have in mind here, then we
need to avoid the word "registry".

> Isn't that Speermint's role to do?  (I'm not clear on that either)

Do you see such an item in the speermint milestones? I don't.

IMHO we need something like RFC 1034 for the whole speermint /
peppermint setup.

/ol

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 21 Apr 2008 14:26:58 -0400

>  
>  This makes sense.
>  
>  > > > These administrative domains may be of any practical size and
>  could be any type of SSP, such as recognized telephony carriers,
enterprises,
>  end-
>  > > user
>  > > (carriers, enterprises) with groups of SSPs (federations). This
>  will bite us when doing the protocol design.

Why will this bit us? 

>  Then let's take "federations" out of this definition NOW.

I'm not convinced this is a problem.  Frankly its splitting hairs on
terminology. I don't understand why a federations could not be considered a
SSP? But if there is consensus on taking it out .. OK.

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

Right ..

>  >
>  > I had the same worry as you, but I think we'd just say "a registry"
>  is> simply consumed inside one or both of the SSP's. I've always assumed
>  > such data stores, and their data is either internal or external to
>  an SSP or both. For a bilateral peering model, SSP1 needs to learn the

NO.

The notion of 'a registry' is well understood in this context.  Namely a
"trusted source of data" which multiple SSP internally or externally may
draw data from. Instead of SSP bi-laterally exchanging data, which is OK,
SSP could use a registry to aggregate their data for re-distribution. No
different from Domain Name operations or Centralized Numbering Databases
like the NPAC or the UK NICC.

A registry may be the 'trusted source of data' internal to the network as
well that redistributes data to local databases or caches. This is the way
the world works today in phone networks. A SSP may need to aggregate
multiple data sources' in to a internal registry for distribution to
localized databases, typically known as Service Control Points in PSTN
speak..

Which is different than a database is a structured format for organizing and
maintaining information that can be easily retrieved.

There is a very logical difference between the notion of a registry and a
database. 

>  IMHO we need something like RFC 1034 for the whole speermint /

Well Hadriel is right ... that is a Speermint issue. 

And I've sent the last revision to the AD's for comments. We'll see what
they have to say.

---

From: David Schwartz <[email-masked]>
Date: Mon, 21 Apr 2008 21:49:03 +0300

This is getting silly. If you take out federations you may as well  
take out enterprises as well. It never ceases to amaze me how one  
little word keeps making so many people feel uneasy.

I am against removing it.

D.

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 22 Apr 2008 16:44:52 +0200

On 2008/04/21 20:04, Richard Shockey <[email-masked]> wrote:
> >  end- user

> >  will bite us when doing the protocol design.

Because a SSP can be a member of multiple federations. Now, if you plan
to build a registry similar to a LERG/NPAC database, then you'll have to
deal with multiple federations inserting data about the same numbers.

That's the point where the registry moves from a store of authoritative
information of "who owns a number" and perhaps "what is the URI for the
number" to a distribution mechanism of routing announcements, where
there can be multiple possible records (=routes) per destination.

This has a profound impact on the overall design. Imagine that a domain
registry allows the provisioning of records concerning a domain by
multiple registrars at the same time. Yes, it's possible to build
a system based on this premise, but we need to make this explicit.

> >  > I don't think that sentence restricts it, since it says "could
> >  > be" and we can later decide to restrict it further, but yeah it's
> >  > weird to think of a Federation as being an SSP.
> >
> I'm not convinced this is a problem. Frankly its splitting hairs
> on terminology. I don't understand why a federations could not be
> considered a SSP? But if there is consensus on taking it out .. OK.

A federation is defined as a set of SSPs. 

Any terminology where "X" and "set of X" is of the same type is
likely to be flawed. (e.g. a "a flock of birds" cannot be a "bird")

> like the NPAC or the UK NICC.

Fine. Then what about describing this in the charter properly. e.g. by

 Administrative domains may exchange data directly between each other
 or might use an external registry (perhaps operated by a federation)
 to aggregate data from multiple administrative domains into
 a single view.

> the world works today in phone networks. 

<tongue in cheek>
So the aim of peppermint^Wdrinks is to move the PSTN thinking and
databases into an IP based setting? Will this be anything more than just
porting the concepts behind LERG/NPAC/NICC/... to SIP? 

Will there be any innovation in call routing, or are we just replacing
aging provisioning protocols with new ones, while retaining the
dependency on unloved fat registries?

As we're saying good-bye to the end2end principle for VoIP routing,
is falling back to the PSTN way of routing calls really the path
the IETF should be choosing?
</t-i-c>

Other open questions: 

* Will DRINKS just consider "push" style provisioning protocols,
  or will DRINKS also look at on-demand lookup protocols towards
  these registries?

* Speermint has separated out the LUF (who owns the destination?)
  from the LRF (What's my SED towards the destination network?).

  Given the fact that DRINKS is supposed to build upon speermint,
  can you make clear whether DRINKS is about the LUF or the LRF?

  Or are we mixing up these things *again*?

> Well Hadriel is right ... that is a Speermint issue. 

So you want to define a set protocols without having a reference
scenario against which to test whether the protocols do what we want?

Good plan.

As it has worked so brilliantly for speermint, we have to replicate
it in DRINKs as well, don't we?

/ol

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 22 Apr 2008 11:18:36 -0400

Hi Otmar,
I don't disagree with some or many of our points, but I don't think we need to hash them out for the charter.  I think we can discuss these in the actual WG, after the charter is approved.  Nothing in the charter limits our ability to do that as far as I can tell. (right?)

-hadriel

> Sent: Tuesday, April 22, 2008 10:45 AM
> To: [email-masked]
> Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
>

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 22 Apr 2008 12:25:18 -0400

Thank you Hadriel. 

Now after some conversations with our AD, I think we are in good shape with
the charter as its currently written including the rename. 

There is some clarification in the text I'll fix however there is a strong
suggestion that that we specify a more detailed list of SED data to be
addressed. That means expanding out this sentence below somewhat. We don't
need a exhaustive list only a list that sufficiently bounds the work to be
undertaken. In other words, the AD don't want us wandering off the
reservation.

"Typical SED 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."  

Anyone want to suggest some text?

>  From: [email-masked] [mailto:[email-masked]]
>  On Behalf Of Hadriel Kaplan
>  Sent: Tuesday, April 22, 2008 11:19 AM
>  To: Otmar Lendl; [email-masked]
>  I don't disagree with some or many of our points, but I don't think we
>  need to hash them out for the charter.  I think we can discuss these
>  in the actual WG, after the charter is approved.  Nothing in the
>  charter limits our ability to do that as far as I can tell. (right?)
>  
>  -hadriel
>  
>  
>  > > draw data from. Instead of SSP bi-laterally exchanging data, which
>  is
>  > OK,
>  > > A registry may be the 'trusted source of data' internal to the
>  network
>  > as
>  > > well that redistributes data to local databases or caches. This is
>  the
>  > way

---

From: "Daryl Malas" <[email-masked]>
Date: Tue, 22 Apr 2008 10:36:08 -0600

Richard,

I would assume the description in Section 3.3 of the Speermint
terminology draft is not substantial enough in provide a scope of SED
relative to DRINKS?  I would assume the described aspects of SED would
need to be provisioned and shared as necessary between peers.  We can
definitely get more granular, but I didn't know if this would work at a
high level.

--Daryl 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Richard Shockey
Sent: Tuesday, April 22, 2008 10:25 AM
To: 'Hadriel Kaplan'; 'Otmar Lendl'; [email-masked]
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.

Thank you Hadriel. 

Now after some conversations with our AD, I think we are in good shape
with the charter as its currently written including the rename. 

There is some clarification in the text I'll fix however there is a
strong suggestion that that we specify a more detailed list of SED data
to be addressed. That means expanding out this sentence below somewhat.
We don't need a exhaustive list only a list that sufficiently bounds the
work to be undertaken. In other words, the AD don't want us wandering
off the reservation.

"Typical SED 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."  

>  I don't disagree with some or many of our points, but I don't think 
> we  need to hash them out for the charter.  I think we can discuss 
> these  in the actual WG, after the charter is approved.  Nothing in 
> the  charter limits our ability to do that as far as I can tell. 
> (right?)
>  
>  -hadriel
>  
>  
>  > From: [email-masked] [mailto:peppermint-  
> [email-masked]] On  > Behalf Of Otmar Lendl  > Sent: Tuesday, April 
> 22, 2008 10:45 AM  > To: [email-masked]  > Subject: Re: 
> [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
>  >
>  > > >  > > 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.
>  > >
>  > > Why will this bit us?
>  >
>  > Because a SSP can be a member of multiple federations. Now, if you

> plan  > to build a registry similar to a LERG/NPAC database, then 
> you'll  have to  > deal with multiple federations inserting data about

> the same  numbers.
>  >
>  > That's the point where the registry moves from a store of  
> authoritative  > information of "who owns a number" and perhaps "what 
> is the URI for  the  > number" to a distribution mechanism of routing 
> announcements, where  > there can be multiple possible records 
> (=routes) per destination.
>  >
>  > This has a profound impact on the overall design. Imagine that a  
> domain  > registry allows the provisioning of records concerning a 
> domain by  > multiple registrars at the same time. Yes, it's possible 
> to build  > a system based on this premise, but we need to make this 
> explicit.
>  >
>  > > >  > I don't think that sentence restricts it, since it says  
> "could  > > >  > be" and we can later decide to restrict it further, 
> but yeah  it's  > > >  > weird to think of a Federation as being an 
> SSP.
>  > > >

>  > Any terminology where "X" and "set of X" is of the same type is  > 
> likely to be flawed. (e.g. a "a flock of birds" cannot be a "bird")  >

>  > > "trusted source of data" which multiple SSP internally or  
> externally may  > > draw data from. Instead of SSP bi-laterally 
> exchanging data, which  is  > OK,  > > SSP could use a registry to 
> aggregate their data for re-  distribution. No  > > different from 
> Domain Name operations or Centralized Numbering  Databases  > > like 
> the NPAC or the UK NICC.
>  >
>  >  Administrative domains may exchange data directly between each  
> other  >  or might use an external registry (perhaps operated by a
>  federation)
>  >  to aggregate data from multiple administrative domains into  >  a 
> single view.
>  >
> network  > as  > > well that redistributes data to local databases or 
> caches. This is  the  > way  > > the world works today in phone 
> networks.
>  >
>  > <tongue in cheek>
> > databases into an IP based setting? Will this be anything more than

> just  > porting the concepts behind LERG/NPAC/NICC/... to SIP?
>  >
>  > Will there be any innovation in call routing, or are we just  
> replacing  > aging provisioning protocols with new ones, while 
> retaining the  > dependency on unloved fat registries?
>  >

> > is falling back to the PSTN way of routing calls really the path  > 

>  > So you want to define a set protocols without having a reference  >

>  > // 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  >

---

From: "Daryl Malas" <[email-masked]>
Date: Tue, 22 Apr 2008 10:45:57 -0600

Otmar,

Keep in mind, there is no limitation for federations to peer, much like
SSPs.  Therefore, to use your bird analogy, two flocks can peer and two
birds could peer.  You are right, a flock is not a bird; however, the
provisioning and exchanging of the data should be very similar if not
identical in methodology between the two distinct entities.

--Daryl 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Otmar Lendl
Sent: Tuesday, April 22, 2008 8:45 AM
To: [email-masked]
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.

This has a profound impact on the overall design. Imagine that a domain
registry allows the provisioning of records concerning a domain by
multiple registrars at the same time. Yes, it's possible to build a
system based on this premise, but we need to make this explicit.

> >  > I don't think that sentence restricts it, since it says "could  >

> > be" and we can later decide to restrict it further, but yeah it's  >

> terminology. I don't understand why a federations could not be 

Any terminology where "X" and "set of X" is of the same type is likely
to be flawed. (e.g. a "a flock of birds" cannot be a "bird")

> The notion of 'a registry' is well understood in this context.  Namely

> a "trusted source of data" which multiple SSP internally or externally

> may draw data from. Instead of SSP bi-laterally exchanging data, which

> is OK, SSP could use a registry to aggregate their data for 
> re-distribution. No different from Domain Name operations or 
> Centralized Numbering Databases like the NPAC or the UK NICC.

 Administrative domains may exchange data directly between each other
or might use an external registry (perhaps operated by a federation)  to
aggregate data from multiple administrative domains into  a single view.

> A registry may be the 'trusted source of data' internal to the network

> as well that redistributes data to local databases or caches. This is 
> the way the world works today in phone networks.

<tongue in cheek>

As we're saying good-bye to the end2end principle for VoIP routing, is
falling back to the PSTN way of routing calls really the path the IETF
should be choosing?
</t-i-c>

Other open questions: 

Good plan.

As it has worked so brilliantly for speermint, we have to replicate it
in DRINKs as well, don't we?

/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
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

---

From: "Daryl Malas" <[email-masked]>
Date: Tue, 22 Apr 2008 11:03:18 -0600

Otmar,

First, let me say I do have a lot of respect for your perspective on
this work as it relates to both DRINKS and SPEERMINT; however, I have
heard the discussion relating to "are we simply setting up peering to
look, taste, and feel just like the PSTN" many, many times.  I would
like to assert two comments regarding this endless discussion.  First,
let's take a look at the PSTN...while the PSTN is not the most perfect
approach to voice communications, it has been refined and improved over
the past 100 years.  I am not quite convinced in the past 10 - 15 years,
we can adequately say all aspects of the PSTN are junk and we should
come up with a new method to solve the world's communication problems.
Instead, I recommend we (and, I think we are) take a look at the
problems that have been solved by many intelligent people over a 100
years and continue to ask ourselves (as they likely did) how can we make
this better.  Making an approach more efficient and optimal does not
necessarily mean throwing it out completely.  Second, within yours (and
others) arguments, I have only heard of 3 total approaches to this
"problem": email model, IP routing model, and PSTN model.  All of these
models are still based on known approaches to resolving the "peering"
(or effective exchanging of data) issue as a whole.  Is our goal to try
and make peering look like any one of these, should it take the best
approaches from each of them, or should we throw all 3 of them out and
try something new?  I do not have the answer to that question, but I
think we need to be careful to not regularly take the liberty of
shooting down very well defined, thought out models.  Change is NOT
always good, unless the outcome has been proven (either via solid theory
or proof) to be positive in consideration of the scale of the situation.

I apologize if this has come across as a rant, but every time I see this
discussion thread; I've thought about writing some of my opinions down.
I finally just took the opportunity to do so.  I hope this makes sense.

Thanks,

Daryl

-----Original Message-----

<tongue in cheek>

Other open questions: 

Good plan.

/ol

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 22 Apr 2008 13:05:57 -0400

>  relative to DRINKS?  

This is my working assumption from the AD's.. some general concepts as you
point out, but also scoping out what is NOT to be included. This is classic
WG bounding. No wondering off the reservation. First crawl then walk.

I would assume the described aspects of SED would
>  definitely get more granular, but I didn't know if this would work at
>  a high level.

Basically the subject headers are sufficient for what we should be looking
at. But with specific exclusions... rating information, for instance, should
explicitly be excluded from a first pass at a WG charter.

*****************

3.3. Session Establishment Data 

   Session Establishment Data, or SED, is the data used to route a call 
   to the next hop associated with the called domain's ingress point. A 
   domain's ingress point can be thought of as the location derived from 
   the NAPTR/SRV/A record [1] that resulted from the resolution of the 
   SIP URI. 

   More specifically, the SED is the set of parameters that the outgoing 
   SBEs need to complete the call, and may include: 

     . A destination SIP URI 

     . A SIP proxy or ingress SBE to send the INVITE to, including 

          o  Fully Qualified Domain Name (FQDN) 

          o  Port 

          o  Transport Protocol (UDP/TCP/TLS [9/10/11]) 

     . Security Parameters, including 

          o  TLS certificate to use 

          o  TLS certificate to expect 

          o  TLS certificate verification setting 

     . Optional resource control parameters such as 

          o  Limits on the total number of call initiations to a peer 

          o  Limits on SIP transactions/second

>  >  > Fine. Then what about describing this in the charter properly.
>  e.g.
>  >  by
>  >  >

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 23 Apr 2008 01:20:25 -0400

Huh.  So we need to bound the data being exchanged - got that.  But the tricky part about this is picking what data now, without yet getting into the arguments of how this will work.  For example, the type of "SED" data described in section 3.3 of terminology draft is not that high on the list of things I would expect to be exchanged or resolved by a LUF or LRF query.

Well... that's not totally true, but it's not sufficient data to make peering work at the SBE-SBE connection level, and some of those particular connection-specific details frankly aren't dynamic that way (ie, per route) and probably shouldn't/couldn't be.

What about something more like:

   Session Establishment Data, or SED, is the data used to route a call
   to the next hop domain's ingress point, on its way to the called
   terminating domain. A domain's ingress point can be thought of as the
   location derived from the NAPTR/SRV/A record [1] that resulted from
   the resolution of the SIP URI.

   More specifically, the SED is the set of parameters that the local
   SSP needs to complete the call, through its egress SBE's, and may
   include:

     . A destination SIP/SIPS/TEL URI

     . A SIP next-hop/next-hop-group to send the request to, possibly
       including one or more of the following:

          o  Trunk Group and Context (IPTEL WG)

          o  Learned/static SIP Route headers for the peer SSP

     . A resolved terminating domain identifier, which may include:

          o  The terminating domain identified as a Domain Name

          o  The terminating domain identified as an SSP-ID

          o  One or more parameters indicating ported number resolution

          o  Resource priority value(s) for the call

          o  Geographic or topological identifiers

-hadriel

> From: Richard Shockey [mailto:[email-masked]]
>

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 23 Apr 2008 10:56:56 -0400

>  
>  Huh.  So we need to bound the data being exchanged - got that.  But
>  the tricky part about this is picking what data now, without yet
>  getting into the arguments of how this will work.  

Well at this stage of WG formation the issue for the AD's is that we not
attempt to boil the ocean only select a range of SED Data types necessary to
establish a session aka the baby steps.  Of course as we get into the weeds
here we may find other things that are important. What I suspect is equally
important for the charter is to list what is to be specifically excluded,
such as rating information. What else PKI? 

For example, the
>  type of "SED" data described in section 3.3 of terminology draft is
>  not that high on the list of things I would expect to be exchanged or
>  resolved by a LUF or LRF query.
>  
>  Well... that's not totally true, but it's not sufficient data to make
>  peering work at the SBE-SBE connection level, and some of those
>  particular connection-specific details frankly aren't dynamic that way
>  (ie, per route) and probably shouldn't/couldn't be.
>  

This is a excellent list BTW.

>     SSP needs to complete the call, through its egress SBE's, and may

Number ranges?

>  > at. But with specific exclusions... rating information, for
>  instance,
>  > should
>  [email-masked]]
>  > >  strong suggestion that that we specify a more detailed list of
>  SED
>  > >  data
>  > >  We don't need a exhaustive list only a list that sufficiently
>  bounds
>  > >  the
>  > >  >  > > >  > > These administrative domains may be of any
>  practical
>  > >  size
>  > >
>  > >  > carriers,  > > enterprises,  > > >  end- user  > > >  > > >
>  groups,
>  > >  or
>  > >
>  > >  > Federations.
>  > >  >  > > >  > >
>  > >  >  >
>  > >  >  > Because a SSP can be a member of multiple federations. Now,
>  if
>  > >  you
>  > >
>  > >  > you'll  have to  > deal with multiple federations inserting
>  data
>  > >  about
>  > >
>  > >  > the same  numbers.
>  > >  >  >
>  > >  > > > on terminology. I don't understand why a federations could
>  not
>  > >  be
>  > >
>  > >  > > > considered a SSP? But if there is consensus on taking it
>  out ..
>  > >  >  OK.
>  > >  >  >
>  > >  > > > The notion of 'a registry' is well understood in this
>  context.
>  > >  >  Namely a
>  > >  a
>  > >  > network  > as  > > well that redistributes data to local
>  databases
>  > >  or
>  > >  > > databases into an IP based setting? Will this be anything
>  more
>  > >  than
>  > >
>  > >  >  > > >  > Isn't that Speermint's role to do?  (I'm not clear on
>  that
>  > >  >  either)
>  > >  >  > > >
>  > >  >  > > >  IMHO we need something like RFC 1034 for the whole
>  speermint
>  > >  /
>  > >
>  > >  > > > >  peppermint setup.
>  > >  >  >
>  > //

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 23 Apr 2008 17:40:56 +0200

> >     SSP needs to complete the call, through its egress SBE's, and may

As it is defined, SED is what you get from the mapping step, not the
mapping itself.

Number ranges (or individual numbers) are the key under which SED is stored.

(In the case where ENUM is the access protocol, SED would be whatever is
contained in the NAPTR. The number ranges don't appear there, they are
only relevant for selecting the right NAPTR records from the DNS tree.)

/ol

---

From: "Daryl Malas" <[email-masked]>
Date: Wed, 23 Apr 2008 10:21:56 -0600

I recommend we further simplify:

The scope will be limited to defining the following criteria necessary
for a SSP to respond with the necessary Session Establishment Data (SED)
for both internal and external purposes:

	+ Routes
		- Destination SIP/SIPS/TEL URI Egress and Ingress Routes
		- Relevant route names, identifiers, and services
		- NAPTR context and associations
	+ Service Areas
		- Individual, ranges, or groups of ENUMservice
identifiers
		- Route associations
	+ Treatment Profiles
		- Priority
		- Location

--Daryl

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, April 22, 2008 11:20 PM
To: Richard Shockey; Daryl Malas; 'Otmar Lendl'; [email-masked]
Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.

Huh.  So we need to bound the data being exchanged - got that.  But the
tricky part about this is picking what data now, without yet getting
into the arguments of how this will work.  For example, the type of
"SED" data described in section 3.3 of terminology draft is not that
high on the list of things I would expect to be exchanged or resolved by
a LUF or LRF query.

-hadriel

> Basically the subject headers are sufficient for what we should be 
> looking at. But with specific exclusions... rating information, for 
> instance, should explicitly be excluded from a first pass at a WG 
> charter.
>
> *****************
>
> >  Now after some conversations with our AD, I think we are in good 
> > shape  with the charter as its currently written including the
rename.

> > strong suggestion that that we specify a more detailed list of SED  
> > data  to be addressed. That means expanding out this sentence below

> > somewhat.
> > bounds  the  work to be undertaken. In other words, the AD don't 
> > want us wandering  off the reservation.
> >
> >  >  From: [email-masked]  > 
> > [mailto:[email-masked]]
> >  >  Sent: Tuesday, April 22, 2008 11:19 AM  >  To: Otmar Lendl; 
> > [email-masked]  >  Subject: Re: [PEPPERMINT] DRINKS PROPOSED 
> > Charter ..comments  please.
> >  >
> >  >  Hi Otmar,
> >  >  I don't disagree with some or many of our points, but I don't 
> > think  > we  need to hash them out for the charter.  I think we can 
> > discuss  > these  in the actual WG, after the charter is approved.  
> > Nothing in  > the  charter limits our ability to do that as far as I
can tell.
> >  >  > From: [email-masked] [mailto:peppermint-  > 
> > [email-masked]] On  > Behalf Of Otmar Lendl  > Sent: Tuesday,  
> > April  > 22, 2008 10:45 AM  > To: [email-masked]  > Subject: 
> > Re:
> >  >  > > >  > > 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
> >  > SSPs  > > >  (carriers, enterprises) with groups of SSPs  > 
> > (federations). This  > > >  will bite us when doing the protocol  > 
> > design.
> >  >  > >
> >  >  > > Why will this bit us?
> >  >  >
> >  >  > Because a SSP can be a member of multiple federations. Now, if

> >  >  > That's the point where the registry moves from a store of  > 
> > authoritative  > information of "who owns a number" and perhaps  
> > "what  > is the URI for  the  > number" to a distribution mechanism 
> > of  routing  > announcements, where  > there can be multiple 
> > possible records  > (=routes) per destination.
> >  >  >
> >  >  > This has a profound impact on the overall design. Imagine that

> > a  > domain  > registry allows the provisioning of records 
> > concerning a  > domain by  > multiple registrars at the same time. 
> > Yes, it's  possible  > to build  > a system based on this premise, 
> > but we need to make this  > explicit.
> >  >  >

> > > "could  > > >  > be" and we can later decide to restrict it 
> > further,  > but yeah  it's  > > >  > weird to think of a Federation 
> > as being an  > SSP.
> >  >  > > >
> > not  be
> >  > > > considered a SSP? But if there is consensus on taking it out
..
> >  >  > Any terminology where "X" and "set of X" is of the same type 
> > is  >  > likely to be flawed. (e.g. a "a flock of birds" cannot be a

> > "bird")  >
context.
> >  >  Namely a
> >  >  > > "trusted source of data" which multiple SSP internally or  >

> > externally may  > > draw data from. Instead of SSP bi-laterally  > 

> > > Domain Name operations or Centralized Numbering  Databases  > > 
> > like  > the NPAC or the UK NICC.
> >  >  >
> >  >  >  Administrative domains may exchange data directly between 
> > each  > other  >  or might use an external registry (perhaps 
> > operated by a  >  federation)  >  >  to aggregate data from multiple

> > administrative domains into  >  a  > single view.
> >  >  >
> >  >  > > A registry may be the 'trusted source of data' internal to 
> > the  > network  > as  > > well that redistributes data to local 
> > databases  or  > caches. This is  the  > way  > > the world works 
> > today in phone  > networks.
> >  >  >
> >  >  > <tongue in cheek>
> >  >  > So the aim of peppermint^Wdrinks is to move the PSTN thinking 
> > and  > > databases into an IP based setting? Will this be anything 
> > more  than
> >
> > > replacing  > aging provisioning protocols with new ones, while  > 
> >  > > is falling back to the PSTN way of routing calls really the 
> > path  >  > the IETF should be choosing?
> >  >  > </t-i-c>
> >  >  >
> >  >  > Other open questions:
> >  >  >
> > that  >  either)  >  > > >  >  > > >  Do you see such an item in the

> > speermint milestones? I  don't.
> >  >  > > >
> > speermint  /

> > > //  > http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 23 Apr 2008 12:22:00 -0400

> From: Otmar Lendl [mailto:[email-masked]] On Behalf Of Otmar Lendl
> Sent: Wednesday, April 23, 2008 11:41 AM
>

Yes exactly - afaik, the SED is the result of the lookup, vs. the keys for the lookup; but a couple people actually sent me email asking why number ranges weren't in the list, so maybe that's not a common definition. (and the keys do overlap with the results)  In reading the terminology draft it sure sounds like SED is returned by the LRF, not used for LUF/LRF lookups.

I think though what you're looking for is a minimal list of the data which needs to be exchanged between providers or between provider-regstry? (ie, the both lookup keys and results)
Then I think a starting list would be like:

     . Destination matching criteria, possibly of one or more of the
       following:

          o  An E.164 number, number range, or prefix

          o  A domain name or FQDN

     . One or more originating qualifiers, possibly including one or more
       of the following

          o  A source SIP/SIPS/TEL URI match filter

          o  A source domain identified as an SSP-ID

          o  Source geographic or topological identifiers

Note there are plenty of other matching criteria used today, such as time of day, originating and destination trunk groups, method type, session type, media type, codec types, etc.  But I'm hoping we can avoid those for now.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 23 Apr 2008 12:34:00 -0400

> From: Daryl Malas [mailto:[email-masked]]
>

OK, so here you're defining the minimal data needed to be exchanged by DRINKS, in order for an SSP to provide SED - right?

>                 - NAPTR context and associations

When you exchange data, it may be in the form of a NAPTR in syntax and maybe even semantics, but it's not really a "NAPTR" DNS entry - it just happens to be that you chose to format the resultant route information in the form of a NAPTR.  So I think the word "NAPTR" shouldn't be in the charter's list of data to be exchanged.  We may just happen to use that format in the end for the data, but there's nothing about the data that demands it. (and in fact I personally think it's confusing and misleading to be using that specific format in the data exchange directly, but we can argue about that later :)

>                 - Individual, ranges, or groups of ENUMservice

I don't know what a "Route association" is?

>                 - Location

I note this doesn't directly include originating or source information, which is fairly essential to SIP routing, afaict.  Is that something you'd classify under "route associations" or "treatment profiles", or do you specifically not want that in the charter?

-hadriel

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Wed, 23 Apr 2008 16:42:36 +0000

Do we have to determine the data model now?  This seems premature when
we've not yet considered use cases. 

Tim

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: Wednesday, April 23, 2008 11:34 AM
> To: Daryl Malas; Richard Shockey; Otmar Lendl; [email-masked]
> OK, so here you're defining the minimal data needed to be 
> exchanged by DRINKS, in order for an SSP to provide SED - right?
> 
> 
> >         + Routes
> When you exchange data, it may be in the form of a NAPTR in 
> syntax and maybe even semantics, but it's not really a 
> "NAPTR" DNS entry - it just happens to be that you chose to 
> format the resultant route information in the form of a 
> NAPTR.  So I think the word "NAPTR" shouldn't be in the 
> charter's list of data to be exchanged.  We may just happen 
> to use that format in the end for the data, but there's 
> nothing about the data that demands it. (and in fact I 
> personally think it's confusing and misleading to be using 
> that specific format in the data exchange directly, but we 
> can argue about that later :)
> 
> 
> >         + Service Areas
> I note this doesn't directly include originating or source 
> information, which is fairly essential to SIP routing, 
> afaict.  Is that something you'd classify under "route 
> associations" or "treatment profiles", or do you specifically 
> not want that in the charter?
> 
> -hadriel

---

From: "Daryl Malas" <[email-masked]>
Date: Wed, 23 Apr 2008 10:45:06 -0600

Comments in-line... 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Wednesday, April 23, 2008 10:34 AM
To: Daryl Malas; Richard Shockey; Otmar Lendl; [email-masked]
Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.

> for a SSP to respond with the necessary Session Establishment Data 
> (SED) for both internal and external purposes:

OK, so here you're defining the minimal data needed to be exchanged by
DRINKS, in order for an SSP to provide SED - right? [DM] Yes.

>                 - NAPTR context and associations

When you exchange data, it may be in the form of a NAPTR in syntax and
maybe even semantics, but it's not really a "NAPTR" DNS entry - it just
happens to be that you chose to format the resultant route information
in the form of a NAPTR.  So I think the word "NAPTR" shouldn't be in the
charter's list of data to be exchanged.  We may just happen to use that
format in the end for the data, but there's nothing about the data that
demands it. (and in fact I personally think it's confusing and
misleading to be using that specific format in the data exchange
directly, but we can argue about that later :)
[DM] Ok...do not use NAPTR.

>                 - Individual, ranges, or groups of ENUMservice 

I don't know what a "Route association" is? [DM] This is associating a
"Service Area" to an Ingress or Egress Route as will be defined in the
previous point "Routes".

>                 - Location

I note this doesn't directly include originating or source information,
which is fairly essential to SIP routing, afaict.  Is that something
you'd classify under "route associations" or "treatment profiles", or do
you specifically not want that in the charter?
[DM] The purpose is source or destination information is defined under
"Routes".  Treatment is then applied under Treatment Profiles.

-hadriel

---

From: "Daryl Malas" <[email-masked]>
Date: Wed, 23 Apr 2008 10:48:29 -0600

I think the purpose here is to contain the scope of the charter.  The
subsequent use cases will then be limited to the scope of the charter.
If you do not clearly define the scope, then the use cases can run all
over the place.  If this occurs, it just creates many years of debate, a
very frustrated set of co-chairs and working group.

I think this is the right approach, but we need to be careful to balance
putting enough detail in to clearly contain the scope without too much
detail as to make the charter a working group draft.

--Daryl

-----Original Message-----
From: Dwight, Timothy M (Tim)
[mailto:[email-masked]] 
Sent: Wednesday, April 23, 2008 10:43 AM
To: Hadriel Kaplan; Daryl Malas; Richard Shockey; Otmar Lendl;
[email-masked]
Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.

Tim

> DRINKS, in order for an SSP to provide SED - right?
> 
> 
> >         + Routes

> maybe even semantics, but it's not really a "NAPTR" DNS entry - it 
> just happens to be that you chose to format the resultant route 
> information in the form of a NAPTR.  So I think the word "NAPTR" 
> shouldn't be in the charter's list of data to be exchanged.  We may 
> just happen to use that format in the end for the data, but there's 
> nothing about the data that demands it. (and in fact I personally 
> think it's confusing and misleading to be using that specific format 
> in the data exchange directly, but we can argue about that later :)
> 
> 
> >         + Service Areas
> information, which is fairly essential to SIP routing, afaict.  Is 
> that something you'd classify under "route associations" or "treatment

> profiles", or do you specifically not want that in the charter?
> 
> -hadriel

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Wed, 23 Apr 2008 16:59:54 +0000

Well, limiting the scope sounds good.  But on what basis do we limit it?
How do we know that a proposed data model supports anything useful?  

I assume that proponents of a particular model will have some use
case(s) in mind.  So why not state them explicitly?  Then we can discuss
whether the resulting set of problems to be solved, is sufficient (and
sufficiently bounded).

To me this is simply an issue of determining requirements before we
settle on an implementation.  Settling on an implementation (data model)
first, will have the effect of bounding the set of requirements we might
satisfy.  But doesn't that seem backward?

Tim

> Sent: Wednesday, April 23, 2008 11:48 AM
> To: Dwight, Timothy M (Tim); Hadriel Kaplan; Richard Shockey; 
> Otmar Lendl; [email-masked]
> exchanged by
> syntax and

---

From: "Daryl Malas" <[email-masked]>
Date: Wed, 23 Apr 2008 11:13:39 -0600

Comments in-line... 

-----Original Message-----
From: Dwight, Timothy M (Tim)
[mailto:[email-masked]] 
Sent: Wednesday, April 23, 2008 11:00 AM
To: Daryl Malas; Hadriel Kaplan; Richard Shockey; Otmar Lendl;
[email-masked]
Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.

Well, limiting the scope sounds good.  But on what basis do we limit it?
[DM] For starters, we limited it as the charter already spells out...

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

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.

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

I assume that proponents of a particular model will have some use
case(s) in mind.  So why not state them explicitly?

[DM] Instead of explicitly defining the model at this point, I believe
we are trying to describe well-understood characteristics of the model.

  Then we can discuss whether the resulting set of problems to be
solved, is sufficient (and sufficiently bounded).

[DM] IMHO, this BoF would not have had 2 successful sessions, and have
multiple drafts already proposed if the problem statement was not pretty
well understood.

[DM] If you say you need to build a car...then you say we are going to
limit the scope to a seat, an engine, and some wheels; is that
describing the implementation model?  All we said is...we need to build
a protocol (as described)...let's limit the scope to some SIP, some way
to identify user agents, and some way to know how to get between
them...have we described the implementation model already?

Tim

> To: Dwight, Timothy M (Tim); Hadriel Kaplan; Richard Shockey; Otmar 
> Lendl; [email-masked]

> over the place.  If this occurs, it just creates many years of debate,

> a very frustrated set of co-chairs and working group.
> 
> I think this is the right approach, but we need to be careful to 
> balance putting enough detail in to clearly contain the scope without 
> too much detail as to make the charter a working group draft.
> 
> --Daryl
>

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 23 Apr 2008 13:27:56 -0400

>  Sent: Wednesday, April 23, 2008 1:00 PM

As a practical matter we limit WG scope to what the AD's are prepared
accept. 

In reality we are not limiting ourselves at all ..only limiting what we
attempt to do first.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 23 Apr 2008 13:27:24 -0400

Yeah I'm with Tim on this - this does seem like putting the cart before the horse.  I have no doubt we will get use-cases and data-types that will cause debate in the WG, but that's partly what a WG is there to decide, no?

I don't think it will take too long to reject ones there isn't interest in, and we haven't needed to be able to point to a charter to say "out of scope" to do that usually in other WG's.  If there are ones brought forth there *is* interest in, then we can either spend time in a WG arguing over them, or spend the same amount of time arguing about it before a WG is formed.  At least with doing it in the WG, we can make progress on the ones that are less contentious.

Also, I don't think the type of data we've been talking about is going to constrain much anyway.  Items named "Routes", "relevant route names, identifiers, and services", and "route associations" are broad/generic enough to cover a whole lotta stuff.  We'll read into them what we want to read into them.

-hadriel

> From: Dwight, Timothy M (Tim) [mailto:[email-masked]]

---

From: "Daryl Malas" <[email-masked]>
Date: Wed, 23 Apr 2008 13:05:05 -0600

Guys,

I apologize if my previous comments came across as a little frustrated
with the discussion.  I am just concerned we will continue to go around
and around on nuances without moving forward.  We should/must take the
time we need to make sure everyone is "generally" moving in the same
direction.  We do not want a situation where some do not understand the
purpose of the working group; however, I think sometimes we can nit pick
things too much.  I just don't want to be discussing the charter for
another 6 months, and if you think that is exaggerated; there are plenty
of examples in the IETF to point at...you can start with the speermint
terminology draft. ;-)  I just want to avoid arguing the differences
between a sofa and a couch. :-)

--Daryl 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Wednesday, April 23, 2008 11:27 AM
To: Dwight, Timothy M (Tim); Daryl Malas; [email-masked]
Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.

Yeah I'm with Tim on this - this does seem like putting the cart before
the horse.  I have no doubt we will get use-cases and data-types that
will cause debate in the WG, but that's partly what a WG is there to
decide, no?

I don't think it will take too long to reject ones there isn't interest
in, and we haven't needed to be able to point to a charter to say "out
of scope" to do that usually in other WG's.  If there are ones brought
forth there *is* interest in, then we can either spend time in a WG
arguing over them, or spend the same amount of time arguing about it
before a WG is formed.  At least with doing it in the WG, we can make
progress on the ones that are less contentious.

Also, I don't think the type of data we've been talking about is going
to constrain much anyway.  Items named "Routes", "relevant route names,
identifiers, and services", and "route associations" are broad/generic
enough to cover a whole lotta stuff.  We'll read into them what we want
to read into them.

-hadriel

> case(s) in mind.  So why not state them explicitly?  Then we can 
> discuss whether the resulting set of problems to be solved, is 
> sufficient (and sufficiently bounded).
>
> settle on an implementation.  Settling on an implementation (data 
> model) first, will have the effect of bounding the set of requirements

> we might satisfy.  But doesn't that seem backward?
>
> Tim
>
>
> > I think the purpose here is to contain the scope of the charter.  
> > The subsequent use cases will then be limited to the scope of the
charter.
> > If you do not clearly define the scope, then the use cases can run 
> > all over the place.  If this occurs, it just creates many years of 
> > debate, a very frustrated set of co-chairs and working group.
> >
> > balance putting enough detail in to clearly contain the scope 
> > without too much detail as to make the charter a working group 
> > draft.
> >
> > --Daryl
> >
> > Do we have to determine the data model now?  This seems premature 
> > when we've not yet considered use cases.
> >
> > Tim
> >
> >

> > > shouldn't be in the charter's list of data to be exchanged.  We 
> > > may just happen to use that format in the end for the data, but 
> > > there's nothing about the data that demands it. (and in fact I 
> > > personally think it's confusing and misleading to be using that
> > specific format

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Wed, 23 Apr 2008 19:24:54 +0000

Daryl, 

> we are trying to describe well-understood characteristics of 

That sounds fine.  But maybe we're talking past each other.  I'm
responding to what appears to me to be a much more specific proposal,
that the supported data look something like this:

         + Routes

        + Service Areas

        + Treatment Profiles
                - Priority
                - Location

That looks like a data model to me.

> multiple drafts already proposed if the problem statement was 
> not pretty well understood.

Is it written down anywhere?

> settle on an implementation.  Settling on an implementation (data
model)
> them...have we described the implementation model already?

In saying you need to build a car, you are defining the solution not the
problem.  What are the requirements?  It may turn out that you need a
pickup truck or (gasp) a minivan, not a car.

I think the limitations in scope you state here, are better than those
implied by what I construe as a data model, above.  They're at least
directionally correct, meaning we are moving away from a proposed
solution and toward an understanding of the requirements.  

I also agree that we need both requirements and bounds on the solution
space (which is what I think you mean by scope).  I think the two have
to mature at the same time though.  What I'm sensing here is that one
(bounds on solution space) is out in front of the other (explicit
definition of requirements).  That's what makes me uneasy.  For example
right now I'd agree that we will only use IETF protocols.  Until I
understand the requirements better I don't know that I'd accept a
restriction that SIP be the only protocol.

tim

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 23 Apr 2008 17:49:20 -0400

>  > case(s) in mind.  So why not state them explicitly?

But not in a WG charter ... eyes on the prize here folks. We can get a
charter approved pretty quickly and form the WG if the scope of what we
propose to do _first_ is sufficiently bounded. 

>  that the supported data look something like this:

I think the operative term is "supported data MAY include" .

>  That looks like a data model to me.

Now I'm getting confused. 

So BTW will have to be included. " Data types not in scope will be session
rating or other billing information between SSP's" 

Are we getting close here?

>  solution and toward an understanding of the requirements.

No one is proposing a solution. We are describing  that we do not propose
exchanging data on Collateralized Debt Instruments and Mortgage Interest
Swaps among SSP's

>  restriction that SIP be the only protocol.

SIP is certainly not the only protocol nor is ENUM the only query mechanism.
If someone wants to use DRINKS for the exchange of H.323 gateway information
they certainly can.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 23 Apr 2008 23:45:09 -0400

> exchanging data on Collateralized Debt Instruments and Mortgage Interest

Sure, I'm all in favor of getting a charter approved post-haste.  Even if it means my ideas for "Mortgage Interest eXchanges" (MIX) will have to wait for a charter update.  (too bad too, 'cause a draft-drinks-mix would have been a recipe for success in my opinion)

But seriously, how "detailed" do we need to be in the charter regarding this data?  I think Daryl's proposed data with some minor nits is broad enough not to cause heartburn later, while not letting us get drunk in the possibilities. :)

How about this:

[begin]
The scope will be limited to defining the following criteria necessary for a SSP to respond with the necessary Session Establishment Data (SED) for both internal and external purposes:

        + Routes
                - Destination SIP/SIPS/TEL URI Egress and Ingress Routes
                - Relevant route names, identifiers, and services
                - Attributes affecting route selection
        + Service Areas
                - Individual, ranges, or groups of user-agent identifiers
                - Route-to-service-area associations
        + Treatment Profiles
                - Priority
                - Location

The mechanism(s) chosen should be extensible, in case additional criteria are deemed necessary to achieve the goals of the WG in the future.
[end]

-hadriel

---

From: David Schwartz <[email-masked]>
Date: Thu, 24 Apr 2008 07:16:47 +0300

Since I have been on vacation I have yet to read this entire thread so  
I may have missed something. Isn't defining the actual data something  
that should be done in a requirements doc?

I think that your first paragraph (up to the ':') is all we need right  
now. "routes", "service areas" ( which BTW have never been defined in  
a terminology draft) and "treatment profiles" should be dealt with  
later.

Just keep it short and sweet.

My 1.5 cents

D.

On Apr 24, 2008, at 6:45 AM, Hadriel Kaplan <[email-masked]>  
wrote:

> Sure, I'm all in favor of getting a charter approved post-haste.   
> Even if it means my ideas for "Mortgage Interest eXchanges" (MIX)  
> will have to wait for a charter update.  (too bad too, 'cause a  
> draft-drinks-mix would have been a recipe for success in my opinion)
>
> But seriously, how "detailed" do we need to be in the charter  
> regarding this data?  I think Daryl's proposed data with some minor  
> nits is broad enough not to cause heartburn later, while not letting  
> us get drunk in the possibilities. :)
>
> How about this:
>
> [begin]
> The scope will be limited to defining the following criteria  
> necessary for a SSP to respond with the necessary Session  
> Establishment Data (SED) for both internal and external purposes:
>
>        + Routes
> The mechanism(s) chosen should be extensible, in case additional  
> criteria are deemed necessary to achieve the goals of the WG in the  
> future.
> [end]
>
> -hadriel

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Thu, 24 Apr 2008 08:02:29 -0400

Putting the Service Area concept in the charter still gives me
heartburn. If Drinks is about more than ESPP that doesn't make sense. If
you want to introduce the concept of some aggregate later, after robust
discussion, fine. Not all of us are ready to drink the kool-aid.

Penn Pfautz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hadriel Kaplan
Sent: Wednesday, April 23, 2008 11:45 PM
To: Richard Shockey; 'Dwight, Timothy M (Tim)'; 'Daryl Malas'; 'Otmar
Lendl'; [email-masked]
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.

> exchanging data on Collateralized Debt Instruments and Mortgage
Interest

Sure, I'm all in favor of getting a charter approved post-haste.  Even
if it means my ideas for "Mortgage Interest eXchanges" (MIX) will have
to wait for a charter update.  (too bad too, 'cause a draft-drinks-mix
would have been a recipe for success in my opinion)

But seriously, how "detailed" do we need to be in the charter regarding
this data?  I think Daryl's proposed data with some minor nits is broad
enough not to cause heartburn later, while not letting us get drunk in
the possibilities. :)

How about this:

[begin]

        + Routes
                - Individual, ranges, or groups of user-agent

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 24 Apr 2008 09:34:55 -0400

>  would have been a recipe for success in my opinion)

Good very good ... cant wait to see the draft ..

>  criteria are deemed necessary to achieve the goals of the WG in the

And I'll add the sentence on or rating and billing data.

Works for me ...

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 24 Apr 2008 10:30:31 -0400

I think we are all talking past each other here .. this is a charter.  This
is about what we might do not what we will do.. This is a bounding
excersise.

What I have now is 

**************

More 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), and
the secure manners in which SED and the SIP session data is exchanged
between the peering functions.

Typical SED data types might include:

+ Routes
     - Destination SIP/SIPS/TEL URI Egress and Ingress Routes
     - Relevant route names, identifiers, and services
     - NAPTR context and associations
     - PSTN database information

+ Service Areas
     - Individual, ranges, or groups of ENUMservice identifiers
     - Route 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

**************

>  From: PFAUTZ, PENN L, ATTCORP [mailto:[email-masked]]
>  Sent: Thursday, April 24, 2008 8:02 AM
>  To: Hadriel Kaplan; Richard Shockey; Dwight, Timothy M (Tim); Daryl
>  Malas; Otmar Lendl; [email-masked]
>  regarding

---

From: "Daryl Malas" <[email-masked]>
Date: Thu, 24 Apr 2008 08:44:17 -0600

If there is a problem with the term "Service Areas", then change it to
something else.  I am not hung up on that term.  It just seems to make
logical sense in my mind.  Call it "Non-descript pools of logical
identifiers that may provide value to a relative locale". :-)

IMO, I think the addition below is clear and provides relevant bounds
with which to work in.

--Daryl 

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Thursday, April 24, 2008 8:31 AM
To: 'PFAUTZ, PENN L, ATTCORP'; 'Hadriel Kaplan'; 'Dwight, Timothy M
(Tim)'; Daryl Malas; 'Otmar Lendl'; [email-masked]
Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.

I think we are all talking past each other here .. this is a charter.
This is about what we might do not what we will do.. This is a bounding
excersise.

What I have now is 

**************

More 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), and the secure manners in which SED and the SIP session
data is exchanged between the peering functions.

+ Routes

+ Service Areas

+ Treatment Profiles
     - Priority
     - Location

**************

>  you want to introduce the concept of some aggregate later, after  
> robust  discussion, fine. Not all of us are ready to drink the 
> kool-aid.
>  
>  
>  Penn Pfautz
>  

>  > From: Richard Shockey [mailto:[email-masked]]  >  > No one is 
> proposing a solution. We are describing  that we do not  propose  > 
> exchanging data on Collateralized Debt Instruments and Mortgage  
> Interest  > Swaps among SSP's
>  

> Establishment Data

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 24 Apr 2008 14:51:47 +0000

Richard,

It is precisely because this is a bounding exercise, and specifically a
bound placed on potential solutions, that this is a concern.  We are
trying to define the solution before defining the problem.  

Basically I find this debate contradictory.  If the text starting
"Typical SED data types might include..." below is truly meant only as
examples that might or might not be part of the eventual solution
developed by the WG, then it doesn't bound squat.  So since its
inclusion is controversial, and it doesn't accomplish anything, let's
delete it and declare victory.  If on the other hand its intent is to
function on a bound on potential solutions, then it's disingenuous to
refer to it as "Typical" and say it "might" include... more honest words
would be something like "the WG will be strongly incented to use the
following data model...".  To which I would object.

Tim

> Sent: Thursday, April 24, 2008 9:31 AM
> To: 'PFAUTZ, PENN L, ATTCORP'; 'Hadriel Kaplan'; Dwight, 
> Timothy M (Tim); 'Daryl Malas'; 'Otmar Lendl'; [email-masked]
> Establishment
> >  heartburn. If Drinks is about more than ESPP that doesn't 
> make sense.
> >  If
> >  robust

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 24 Apr 2008 11:22:19 -0400

>  trying to define the solution before defining the problem.

No there is no definition of the solution here.  Remember that is the IETF.
It is a requirement of  new WG's that the scope of the proposed work be
properly bounded so that WG do not go "wandering off the reservation". It
not about defining the solution as much as defining what the WG will NOT do.

>  developed by the WG, then it doesn't bound squat. 

I beg to differ. In the context of IETF WG charters this is perfectly
acceptable problem scoping. It does not propose a data model.

 So since its
>  inclusion is controversial, 

Remember we only deal with "rough consensus" here.

and it doesn't accomplish anything, let's
>  following data model...".  To which I would object.

Well what is your proposed WG scope text? 

Again (with some frustration) ... if anyone has a problem with the current
text then they had better come up with what they propose at the alternative.
I'm simply going to ignore any more objections that do not propose real
alternatives to the text.

>  > >  > No one is proposing a solution. We are describing  that we do
>  not
>  > >  propose

---

From: "Guyton, Deborah A" <[email-masked]>
Date: Thu, 24 Apr 2008 11:41:45 -0400

I believe this provides a description of data or data concepts at a
reasonable level to bound the charter.

Debbie Guyton

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Richard Shockey
Sent: Thursday, April 24, 2008 10:31 AM
To: 'PFAUTZ, PENN L, ATTCORP'; 'Hadriel Kaplan'; 'Dwight, Timothy M
(Tim)'; 'Daryl Malas'; 'Otmar Lendl'; [email-masked]
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.

This

What I have now is 

**************

properly identify an optimal path to a destination SIP user agent (UA),
and

+ Routes

+ Service Areas

+ Treatment Profiles
     - Priority
     - Location

**************

>  Sure, I'm all in favor of getting a charter approved post-haste.
Even
>  The scope will be limited to defining the following criteria
necessary

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Thu, 24 Apr 2008 11:55:16 -0400

How about...

       + Routes
                - Destination SIP/SIPS/TEL URI Egress and Ingress Routes
                - Relevant route names, identifiers, and services
                - Attributes affecting route selection
        + 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

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 24 Apr 2008 11:56:03 -0400

> From: Richard Shockey [mailto:[email-masked]]

I think we agreed to remove the "NAPTR" line from this.  No?

>      - Individual, ranges, or groups of ENUMservice identifiers

I'm not quite sure what you mean by "ENUMservice identifiers" with regards to individual, ranges, or groups.  I mean I know what an "ENUMservice" is per RFC 3761, I just have no idea what it has to do with a "service area", or what "ranges or groups" of them would mean.
Also, "Route associations" is not a well-known term as far as I know.

I *think* what you guys mean here is:
        + Service Areas
                - Individual, ranges, or groups of user-agent identifiers
                - Route-to-service-area associations

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 24 Apr 2008 16:05:21 +0000

Richard, 

> not about defining the solution as much as defining what the 

To define what the solution will not be, is to constrain the solution.
That's my point.  Is it not sufficient, to keep the WG "on the
reservation", to constrain the problem space (rather than the solution
space)?  Obviously you have more IETF experience than me, but in my
experience when working groups struggle it's more often because they
lack clarity with respect to the problem they're trying to solve.

> acceptable problem scoping. It does not propose a data model.

We are in violent agreemnt that the *problem* needs to be scoped.  But
the text in question says nothing about the *problem*.  It only proposes
"typical SED data types".  Whether you consider that a data model or not
(sure looks like one to me) I don't see how it constrains the problem.

> > delete it and declare victory.  

To your question at the end, this is my proposal.

> > If on the other hand its intent is to
> >  refer to it as "Typical" and say it "might" include... more honest
> >  words would be something like "the WG will be strongly incented to
use the
> Well what is your proposed WG scope text? 

See above.

> alternatives to the text.

I'm sure we can all agree to ignore each other.  I'm not sure what that
accomplishes.  

> >  > Data (SED) is collected, what comprises SED, how SED 
> should be used
> >  to
> >  > >  this data?  I think Daryl's proposed data with some 
> minor nits is
> >  > >  broad
> >  > >                  - Destination SIP/SIPS/TEL URI Egress 
> and Ingress
> >  > >  Routes
> >  > >  criteria are deemed necessary to achieve the goals of 
> the WG in
> >  the
> >  > >  future.
> >  > >  [end]
> >  > >
> >  > >  -hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 24 Apr 2008 12:32:07 -0400

I like Penn's calling for Targets ... so this is what I've got now.

Flame away ..

*****

Proposed Charter 

DRINKS Data for Reachability of Inter/tra-NetworK SIP

Mailing Lists: 

[email-masked]

RAI Director(s):

Chairs: TBD

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

Administrative domains may exchange data through the use of an external
registry to aggregate data from multiple administrative domains or multiple
data providers into a single view.

The DRINKS WG 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. In addition DRINKS will insure that the
SED and the SIP session data is securely exchanged between the peering
functions.

Typical SED data might include:

+ Routes

 + Targets

+ Treatment Profiles
     - Priority
     - Location

Requirements for Session Establishment Data (SED) data exchanges. -- Sept 08

Exchanging of Session Establishment Data (SED) from data providers to
registries or between bi/multi-lateral partners. -- Nov 08

Exchange of Session Establishment Data (SED) from registries to Location
Routing Function databases. --- Feb 09

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 24 Apr 2008 12:31:02 -0400

I agree that it is constraining the solution to some degree, but I think what Richard has said is we're going to need to do that a bit to get this past the IESG.  My guess is they're just worried we might try to take on too much or overstep the IETF's comfort zone.

The terms described so far though are fairly generic, and I think one can claim a lot of things would fall under those terms.

So to use the earlier analogy they do say "we're building a car", but that car could be a minivan or pickup - but it's not going to be a plane or boat.  If a mechanism we choose happens to be Chitty-Chitty Bang-Bang, that's ok and I'm not even sure we'd have to revisit the charter to accept that type of solution; but the current charter's just saying it's not in our scope to try to build that type of vehicle at the outset.

If we find that this scope is too constrictive, then we can always revisit and change the charter.  I don't think there will be too much disagreement to changing that if the SSP community needs something more.  And if there is disagreement to that, well... it's fairly pointless to create a mechanism that won't be used. (not that the IETF hasn't done that a hundred times :)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 24 Apr 2008 12:36:07 -0400

Looks good to me, fwiw.

-hadriel

> Sent: Thursday, April 24, 2008 12:32 PM
> To: Hadriel Kaplan; 'PFAUTZ, PENN L, ATTCORP'; 'Dwight, Timothy M (Tim)';
> 'Daryl Malas'; 'Otmar Lendl'; [email-masked]
> Subject: DRINKS PROPOSED Charter Version 02
>
>
> based

---

From: David Schwartz <[email-masked]>
Date: Thu, 24 Apr 2008 21:01:45 +0300

There has been much talk here about "going off the reservation" and  
what the IESG will or won't approve.

I think it would be helpful if one (or both) of the ADs would please  
chime in here as to why there is a need to bound the solution space  
when there are some valid arguments being presented on this list as to  
why this is not a good idea.

While no one wants to boil the ocean it may be a waste of time if all  
we want to do is catch a small tuna.

I think the discussion on this topic proves 2 things:

1 the great interest in the topic
2 the different outlooks on the problem

While I have nothing intrinsic against the proposed text one cannot  
deny its limiting and in light of some of the resistance on the list -  
maybe counterproductive at this point.

ADs?

On Apr 24, 2008, at 7:31 PM, Hadriel Kaplan <[email-masked]>  
wrote:

>
> I agree that it is constraining the solution to some degree, but I  
> think what Richard has said is we're going to need to do that a bit  
> to get this past the IESG.  My guess is they're just worried we  
> might try to take on too much or overstep the IETF's comfort zone.
>
> The terms described so far though are fairly generic, and I think  
> one can claim a lot of things would fall under those terms.
>
> So to use the earlier analogy they do say "we're building a car",  
> but that car could be a minivan or pickup - but it's not going to be  
> a plane or boat.  If a mechanism we choose happens to be Chitty- 
> Chitty Bang-Bang, that's ok and I'm not even sure we'd have to  
> revisit the charter to accept that type of solution; but the current  
> charter's just saying it's not in our scope to try to build that  
> type of vehicle at the outset.
>
> If we find that this scope is too constrictive, then we can always  
> revisit and change the charter.  I don't think there will be too  
> much disagreement to changing that if the SSP community needs  
> something more.  And if there is disagreement to that, well... it's  
> fairly pointless to create a mechanism that won't be used. (not that  
> the IETF hasn't done that a hundred times :)
>
> -hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 24 Apr 2008 14:36:09 -0400

>  why this is not a good idea.

The AD's don't need to explain themselves. 

You don't seem to be listening here. All proposed WG charters must, within
reason, clearly bound the scope of the problem they want to solve and what
aspect of the problem they want to tackle first. At least in the beginning.
The scope of work in the initial charter will be bounded, period. End of
story. That is the IETF process. What don't you understand? This is what you
do to get a charter approved in the IESG.  

The IETF has way too many examples of WG that go "wandering off the
reservation" and try and tackle problems either tangential or impossible to
solve or create work that goes on endlessly.
 
What Daryl and I, as existing WG chairs, among others are reflecting is very
practical experience how this process works. Find a problem, narrowly define
the scope of the solution, fix the problem (incrementally, if possible),
declare victory, go home. Ask any IETF WG chair about this.

>  we want to do is catch a small tuna.

First you have to buy a hook than put the hook in the water .... we ran two
successful BOF's pretty everyone including the AD's "get it".  

>  maybe counterproductive at this point.

We have come this far. We are very close to a implementable first charter
and this discussion on whether there _should_ be limits on what the proposed
WG should or should not do is definitely becoming counterproductive. The
only useful discussion is what those limits actually are.

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 24 Apr 2008 23:03:55 +0200

On 2008/04/24 18:04, Hadriel Kaplan <[email-masked]> wrote:
> 
> So to use the earlier analogy they do say "we're building a car", but
> that car could be a minivan or pickup - but it's not going to be a
> plane or boat. 

We're not building a car. We're building a gearbox.

Some scoping regarding whether this gearbox is for a race-car
or for a truck might be helpful, though.

/ol

---

From: [email-masked]
Date: Mon, 28 Apr 2008 12:27:35 +0100

Richard,

Could we consider at least allowing for some sort of opaque identifier to 
represent billing information, with the mapping between that identifier 
and "real" billing information "to be defined later, possibly elsewhere" ?

kind regards,

Ray

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 28 Apr 2008 12:20:26 -0400

I think that is a perfectly reasonable idea, but the task at hand is to get
a charter approved.

I don't think there would be a problem with a place holder.

>  On Behalf Of [email-masked]
>  Sent: Monday, April 28, 2008 7:28 AM
>  To: [email-masked]
>  > initial tasks. On the basis of initial WG success it is always
>  possible
>  to