Subject: Re: [PEPPERMINT] Proposed Updated Charter
From: "Daryl Malas" <[email-masked]>
To: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>, <[email-masked]>
Date: Tue, 1 Apr 2008 10:12:45 -0600
List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection <peppermint.ietf.org>

Martin,

I do not disagree with your perspective; however, my point is the
defined processes should not be different.  If the processes are not
different (or perhaps have 1 additional "dip switch"), then I still
think it can be encompassed within an SSP.

--Daryl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of DOLLY, MARTIN C, ATTLABS
Sent: Tuesday, April 01, 2008 9:13 AM
To: Daryl Malas; [email-masked]
Subject: Re: [PEPPERMINT] Proposed Updated Charter

Daryl,

I view AT&T differently depending on whether I am accessing them
intranet versus as an AT&T customer, so I do not see them as being the
same. In the intranet case, it is the AT&T IT department that controls
everything, which is different than when I am a customer of AT&T.

Martin 

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]]
Sent: Tuesday, April 01, 2008 11:01 AM
To: DOLLY, MARTIN C, ATTLABS; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

Hello Martin,

I feel it is appropriate to include enterprises within the context of an
SSP.  Per the definition of an SSP, an enterprise provides SIP services
to its customers (employees), in much the same an operator would.  This
is the intention within the charter update below.

--Daryl 

-----Original Message-----
From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]]
Sent: Monday, March 31, 2008 7:31 PM
To: Daryl Malas; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

Hello,

As I stated in the meeting, reference to enterprise/PBXs should be
removed. If you think it should remain please give examples of the
provisioned information?

Thanks,

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Daryl Malas
Sent: Monday, March 31, 2008 4:10 PM
To: [email-masked]
Subject: [PEPPERMINT] Proposed Updated Charter

All,

I was asked to re-write the charter using agreed upon SPEERMINT WG
defined terms.  I also added/changed a few minor suggested details.  The
update is below:

------------------------------------------
Existing charter:

PROPOSED CHARTER FOR PEPPERMINT

The IETF has been working on various aspects of session-based Multimedia
Interconnection among administrative domains. In addition, the IETF has
done significant work on data exchanges among various network elements.

ENUM is specifically chartered to develop protocols that involve the
translation of E.164 numbers to URI's.
 
SPEERMINT has been chartered to develop best current practices among
real-time application service providers and how such services
interconnect across administrative boundaries.

The PEPPERMINT work group is chartered to define what data needs to be
exchanged among Multimedia administrative domains, and how that data
should be structured provisioned and propagated. These protocols would
be outside the normal scope of establishing various forms of a SIP
session. These administrative domains are of any practical size and
could be service providers or enterprise SIP proxy's, such as PBX's.

Data exchanges to facilitate session-based Multimedia Interconnection
are typically between various Client User Agents and Registries or
bilateral or multilateral Registry to Registry.  Data exchanges could
include bulk data as well as real time updates. Typical data include
mappings of phone numbers to URIs, policies surrounding admission to
various points of network interconnection and various types of trunk
data.  In addition, there is a specific need for redistribution of such
Registry data to various types of network databases.  

The working group will draw upon expert advice and ongoing consultation
from the ENUM, SPEERMINT and PROVREG working groups. The working group
may also reuse elements of RFC 4114, if possible.

The final work product(s) from this working group will utilize and be
based on XML documents and XML document exchanges.
-------------------------------------
New revision:

PROPOSED CHARTER FOR PEPPERMINT

The IETF has been working on various aspects of session-based Multimedia
peering among SIP Service Providers (SSPs), 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 following working groups' work provides
the underlying context for much of the intended work within this
charter:

ENUM, which is specifically chartered to develop protocols that involve
the translation of E.164 numbers to URIs.
 
SPEERMINT, which has been chartered to develop requirements and best
current practices among real-time application SSPs and how such services
may interconnect across administrative boundaries.  This work will
provide details of how Session Establishment Data (SED) is collected and
what this data is comprised of, the use of this data to properly
identify an optimal path to the destination user agent (UA), and the
secure manners in which this and the SIP session data is exchanged
between all of the peering functions.  It is also recognizes peering
relationships become more complex as multiple peers are added to a
common relationship, these complex aspects and requirements of multiple,
yet common peering relationships are defined with the contexts of a
peering Federation.

The PEPPERMINT working group is chartered to define what data needs to
be exchanged among Multimedia administrative domains, and how that data
should be structured, provisioned, and propagated. These protocols would
be outside the normal scope of establishing various forms of a SIP
session. These administrative domains are of any practical size and
could be any type of SSP, such as recognized telephony carriers,
enterprises, end-user groups, and Federations.

Data exchanges to facilitate session-based Multimedia Interconnection
are typically between various bilateral or multilateral client User
Agents and related Registries.  Data exchanges could include bulk data
and/or real time updates. Typical data includes mappings of phone
numbers to URIs, policies surrounding admission to various points of
network interconnection, and various types of interconnect data.  In
addition, there is a specific need for the exchange of such data between
the Registry and various types of network databases (e.g. Local Number
Portability (LNP), Calling Name (CNAM), etc.).  

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, if possible.

The final work product(s) from this working group will utilize and be
based on XML documents and XML document exchanges.

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

Thanks...--Daryl

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

Content-class: urn:content-classes:message
Date: Tue, 1 Apr 2008 18:02:28 +0200
From: "DRAGE, Keith \(Keith\)" <[email-masked]>
To: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>, "Hadriel Kaplan" <[email-masked]>, "Daryl Malas" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

Just to note that the reason that this text appeared in the first place
was in response to a question I asked about the size of systems to be
addressed. 

The smaller the systems that this becomes appropriate for, the more we
move into enterprise land, and out of that of the big public network
operators (although this is a generalisation as there are many
enterprise networks bigger that some public networks).

So it is range of system size I want to see represented in the text if
we are really stuck on terminology. 

Regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of DOLLY, 
> MARTIN C, ATTLABS
> Sent: Tuesday, April 01, 2008 12:08 PM
> To: Hadriel Kaplan; Daryl Malas; [email-masked]
> Subject: Re: [PEPPERMINT] Proposed Updated Charter
> 
> Hadriel,
> 
> I do not agree with your example, yet. Can you be a little 
> more specific, as to what information  peppermint would provide here?
> 
> Thanks,
> 
> Martin 
> 
> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Monday, March 31, 2008 10:18 PM
> To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; [email-masked]
> Subject: RE: [PEPPERMINT] Proposed Updated Charter
> 
> His proposed replacement text is only the second half of his 
> email, which doesn't use the term "PBX" (thankfully).  It 
> does use the term "enterprises", but does not define the 
> scope of that, nor does it imply any and all enterprises 
> would be involved or how (which I think it's good to keep undefined).
> 
> Examples would be an Enterprise using something out of 
> PEPPERMINT itself to provision its own proxies/databases, for 
> example with what service provider to use for what routes, or 
> what SBE's to use to reach that service provider.  Or a 
> service provider might exchange some information with the 
> Enterprise, or vice-versa, for similar information.  The 
> "enterprises" could be large corporations; or perhaps a 
> service provider's own internal employee system, or their 
> consumer voip service might be considered a separate, 
> enterprise-type, from their other voip services/networks.
> 
> -hadriel
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]
> On
> > Behalf Of DOLLY, MARTIN C, ATTLABS
> > Sent: Monday, March 31, 2008 9:31 PM
> > To: Daryl Malas; [email-masked]
> > Subject: Re: [PEPPERMINT] Proposed Updated Charter
> >
> > Hello,
> >
> > As I stated in the meeting, reference to enterprise/PBXs should be 
> > removed. If you think it should remain please give examples of the 
> > provisioned information?
> >
> > Thanks,
> >
> > Martin
> >
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]
> > On Behalf Of Daryl Malas
> > Sent: Monday, March 31, 2008 4:10 PM
> > To: [email-masked]
> > Subject: [PEPPERMINT] Proposed Updated Charter
> >
> > All,
> >
> > I was asked to re-write the charter using agreed upon SPEERMINT WG 
> > defined terms.  I also added/changed a few minor suggested details.
> The
> > update is below:
> >
> > ------------------------------------------
> > Existing charter:
> >
> > PROPOSED CHARTER FOR PEPPERMINT
> >
> > The IETF has been working on various aspects of session-based
> Multimedia
> > Interconnection among administrative domains. In addition, the IETF
> has
> > done significant work on data exchanges among various network
> elements.
> >
> > ENUM is specifically chartered to develop protocols that 
> involve the 
> > translation of E.164 numbers to URI's.
> >
> > SPEERMINT has been chartered to develop best current 
> practices among 
> > real-time application service providers and how such services 
> > interconnect across administrative boundaries.
> >
> > The PEPPERMINT work group is chartered to define what data 
> needs to be 
> > exchanged among Multimedia administrative domains, and how 
> that data 
> > should be structured provisioned and propagated. These 
> protocols would 
> > be outside the normal scope of establishing various forms of a SIP 
> > session. These administrative domains are of any practical size and 
> > could be service providers or enterprise SIP proxy's, such as PBX's.
> >
> > Data exchanges to facilitate session-based Multimedia 
> Interconnection 
> > are typically between various Client User Agents and Registries or 
> > bilateral or multilateral Registry to Registry.  Data 
> exchanges could 
> > include bulk data as well as real time updates. Typical 
> data include 
> > mappings of phone numbers to URIs, policies surrounding 
> admission to 
> > various points of network interconnection and various types 
> of trunk 
> > data.  In addition, there is a specific need for redistribution of
> such
> > Registry data to various types of network databases.
> >
> > The working group will draw upon expert advice and ongoing
> consultation
> > from the ENUM, SPEERMINT and PROVREG working groups. The 
> working group 
> > may also reuse elements of RFC 4114, if possible.
> >
> > The final work product(s) from this working group will 
> utilize and be 
> > based on XML documents and XML document exchanges.
> > -------------------------------------
> > New revision:
> >
> > PROPOSED CHARTER FOR PEPPERMINT
> >
> > The IETF has been working on various aspects of session-based
> Multimedia
> > peering among SIP Service Providers (SSPs), 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 following working groups' 
> work provides 
> > the underlying context for much of the intended work within this
> > charter:
> >
> > ENUM, which is specifically chartered to develop protocols that
> involve
> > the translation of E.164 numbers to URIs.
> >
> > SPEERMINT, which has been chartered to develop requirements 
> and best 
> > current practices among real-time application SSPs and how such
> services
> > may interconnect across administrative boundaries.  This work will 
> > provide details of how Session Establishment Data (SED) is collected
> and
> > what this data is comprised of, the use of this data to properly 
> > identify an optimal path to the destination user agent 
> (UA), and the 
> > secure manners in which this and the SIP session data is exchanged 
> > between all of the peering functions.  It is also 
> recognizes peering 
> > relationships become more complex as multiple peers are added to a 
> > common relationship, these complex aspects and requirements of
> multiple,
> > yet common peering relationships are defined with the contexts of a 
> > peering Federation.
> >
> > The PEPPERMINT working group is chartered to define what 
> data needs to 
> > be exchanged among Multimedia administrative domains, and how that
> data
> > should be structured, provisioned, and propagated. These protocols
> would
> > be outside the normal scope of establishing various forms of a SIP 
> > session. These administrative domains are of any practical size and 
> > could be any type of SSP, such as recognized telephony carriers, 
> > enterprises, end-user groups, and Federations.
> >
> > Data exchanges to facilitate session-based Multimedia 
> Interconnection 
> > are typically between various bilateral or multilateral client User 
> > Agents and related Registries.  Data exchanges could 
> include bulk data 
> > and/or real time updates. Typical data includes mappings of phone 
> > numbers to URIs, policies surrounding admission to various 
> points of 
> > network interconnection, and various types of interconnect 
> data.  In 
> > addition, there is a specific need for the exchange of such data
> between
> > the Registry and various types of network databases (e.g. 
> Local Number 
> > Portability (LNP), Calling Name (CNAM), etc.).
> >
> > 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, if possible.
> >
> > The final work product(s) from this working group will 
> utilize and be 
> > based on XML documents and XML document exchanges.
> >
> > ---------------------------------------
> >
> > Thanks...--Daryl
> >
> >
> > _______________________________________________
> > PEPPERMINT mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/peppermint
> > _______________________________________________
> > PEPPERMINT mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/peppermint
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/peppermint
> 
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Tue, 1 Apr 2008 11:36:02 -0400
From: "Cartwright, Kenneth" <[email-masked]>
To: <[email-masked]>
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 9, Issue 21
Sender: [email-masked]

Hi Daryl,

Looks good.  I've offered some possible modifications for consideration.
They are in-line and delimited by ">>>>KJCStart" and ">>>>KJCEnd".

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, March 31, 2008 4:10 PM
To: [email-masked]
Subject: PEPPERMINT Digest, Vol 9, Issue 21

Send PEPPERMINT mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/peppermint
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of PEPPERMINT digest..."

Today's Topics:

   1.   Proposed Updated Charter (Daryl Malas)

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

Message: 1
Date: Mon, 31 Mar 2008 14:10:20 -0600
From: "Daryl Malas" <[email-masked]>
Subject: [PEPPERMINT]  Proposed Updated Charter
To: <[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

All,

I was asked to re-write the charter using agreed upon SPEERMINT WG
defined terms.  I also added/changed a few minor suggested details.  The
update is below:

------------------------------------------
Existing charter:

PROPOSED CHARTER FOR PEPPERMINT

The IETF has been working on various aspects of session-based Multimedia
Interconnection among administrative domains. In addition, the IETF has
done significant work on data exchanges among various network elements.

ENUM is specifically chartered to develop protocols that involve the
translation of E.164 numbers to URI's.
 
SPEERMINT has been chartered to develop best current practices among
real-time application service providers and how such services
interconnect across administrative boundaries.

The PEPPERMINT work group is chartered to define what data needs to be
exchanged among Multimedia administrative domains, and how that data
should be structured provisioned and propagated. These protocols would
be outside the normal scope of establishing various forms of a SIP
session. These administrative domains are of any practical size and
could be service providers or enterprise SIP proxy's, such as PBX's.

Data exchanges to facilitate session-based Multimedia Interconnection
are typically between various Client User Agents and Registries or
bilateral or multilateral Registry to Registry.  Data exchanges could
include bulk data as well as real time updates. Typical data include
mappings of phone numbers to URIs, policies surrounding admission to
various points of network interconnection and various types of trunk
data.  In addition, there is a specific need for redistribution of such
Registry data to various types of network databases.  

The working group will draw upon expert advice and ongoing consultation
from the ENUM, SPEERMINT and PROVREG working groups. The working group
may also reuse elements of RFC 4114, if possible.

The final work product(s) from this working group will utilize and be
based on XML documents and XML document exchanges.
-------------------------------------
New revision:

PROPOSED CHARTER FOR PEPPERMINT

The IETF has been working on various aspects of session-based Multimedia
peering among SIP Service Providers (SSPs), 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 following working groups' work provides
the underlying context for much of the intended work within this
charter:

>>>>KJCStart
You may consider altering the wording of the above sentence to read as
follows:  The ENUM and SPEERMINT working groups provide the underlying
context for much of the intended work that the SPEERMINT working group
will undertake.
>>>>KJCEnd

ENUM, which is specifically chartered to develop protocols that involve
the translation of E.164 numbers to URIs.
 
SPEERMINT, which has been chartered to develop requirements and best
current practices among real-time application SSPs and how such services
may interconnect across administrative boundaries.

>>>>KJCStart
You may consider altering the wording of the above two sentences to read
as follows:  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.  
>>>>KJCEnd

This work will provide details of how Session Establishment Data (SED)
is collected and what this data is comprised of, the use of this data to
properly identify an optimal path to the destination user agent (UA),
and the secure manners in which this and the SIP session data is
exchanged between all of the peering functions.  

>>>>KJCStart
In the above sentences when you say "this work" I believe you are
referring to the work of SPEERMINT, as apposed to the work of SPEERMINT.
So you may consider this tweaked version of the two sentences above:
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
user agent (UA), and the secure manners in which SED and the SIP session
data is exchanged between the peering functions.
>>>>KJCEnd

It is also recognizes peering relationships become more complex as
multiple peers are added to a common relationship, these complex aspects
and requirements of multiple, yet common peering relationships are
defined with the contexts of a peering Federation.

>>>>KJCStart
While I understand what you are saying in the above sentence, I'm not
certain of your intent in adding it here, as a sentence that rides on
the end of your synopsis of the role of the SPEERMINT working group.
Imho, this sentence may be un-necessary in this document.  You may
consider removing it, recognizing that this idea is/willBe addressed and
fleshed out in a requirements document or some other document that can
do it justice.
>>>>KJCEnd

The PEPPERMINT working group is chartered to define what data needs to
be exchanged among Multimedia administrative domains, and how that data
should be structured, provisioned, and propagated. These protocols would
be outside the normal scope of establishing various forms of a SIP
session. These administrative domains are of any practical size and
could be any type of SSP, such as recognized telephony carriers,
enterprises, end-user groups, and Federations.  Data exchanges to
facilitate session-based Multimedia Interconnection are typically
between various bilateral or multilateral client User Agents and related
Registries.  Data exchanges could include bulk data and/or real time
updates. Typical data includes mappings of phone numbers to URIs,
policies surrounding admission to various points of network
interconnection, and various types of interconnect data.  In addition,
there is a specific need for the exchange of such data between the
Registry and various types of network databases (e.g. Local Number
Portability (LNP), Calling Name (CNAM), etc.).

>>>>KJCStart
You may consider rewording the above as follows:  The PEPPERMINT working
group is chartered with a scope that is orthogonal to SPEERMINT and
ENUM.  The work tasks within the scope of PEPPERMINT will be designed to
build from the work of SPEERMINT and ENUM to identify and define the
data structures and provisioning protocol(s) that facilitate the
provisioning data exchanges among 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 network databases (e.g. Local Number Portability (LNP),
Calling Name (CNAM), etc.).
>>>>KJCEnd

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, if possible.

The final work product(s) from this working group will utilize and be
based on XML documents and XML document exchanges.

>>>KJCStart
During the previous IETF in Vancouver, on the mailing list, and at the
most recent IETF in Phily there were opinions expressed that attempting
to pre-determine the list of candidate data structures and protocols was
probably un-necessary for the purposes of the charter and an open ended
activity.  I also feel that just listing the possible candidates in the
charter does not best capture the intended goal, which is to facilitate
the requirements and progress of the working group.  While I don't feel
that this is a major issue, I am of this opinion.  So you may consider
that the above few sentences could be re-worded as follows, which I
think better states the goal while not attempting to pre-determine the
best list of candidates that may meet the goal:  The working group will
draw upon expert advice and on-going consultation from the ENUM and
SPEERMINT working groups.  The working group will also consider reusing
appropriate pre-existing data structures, protocols, and technologies
that are determined to meet the requirements of and facilitate the
progress of the working group.
>>>>KJCEnd

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

Thanks...--Daryl

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

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

End of PEPPERMINT Digest, Vol 9, Issue 21
*****************************************
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Tue, 1 Apr 2008 09:28:11 -0600
From: "Daryl Malas" <[email-masked]>
To: "Hadriel Kaplan" <[email-masked]>, "DOLLY, MARTIN C, ATTLABS" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

Hadriel,

I agree it should be within the scope to consider an enterprise's use of
the outcome of PEPPERMINT, but it is not PEPPERMINT's job to determine
the formation of enterprises within varying peering architectures.  At
best, this would be done within SPEERMINT, and some architectures and
peering considerations for enterprises are already documented within
SPEERMINT artifacts.

--Daryl

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, April 01, 2008 9:20 AM
To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

Imagine a big enterprise, having multiple branch offices, lots of user
agents and proxies/servers/whatever.  They may want calls within a
branch to stay in the branch, calls between certain branches to go over
the public Internet, calls between other branches to use leased lines or
VPNs, calls between other branches to use the PSTN or ESN-type TDM
network, etc.  So they could potentially use an outcome of PEPPERMINT to
dynamically provision their servers/proxies in the various branches with
such routing data, and make changes as employees or groups are added or
move branches.

OR another example is suppose this big enterprise connects to multiple
service providers or federations, perhaps different ones for different
branches - the providers or federations can dynamically inform the
enterprise or its branches of which ingress points can be used for what
routes, with potentially some other attributes yet to be defined.  That
way as the provider/federation adds or removes ingress points or routes,
it can do so in a more automated fashion.

I think, but I'm not sure, that including enterprises in the charter
does not mean to say any of those things would happen, or that
PEPPERMINT would actually define such uses explicitly/separately, or
that they have to give special consideration to such - just that it's
within the scope of the WG's purview to do so.  Is that correct?

-hadriel

> -----Original Message-----
> From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]]
>
> I do not agree with your example, yet. Can you be a little more 
> specific, as to what information  peppermint would provide here?
>
> Thanks,
>
> Martin
>
> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Monday, March 31, 2008 10:18 PM
> To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; [email-masked]
> Subject: RE: [PEPPERMINT] Proposed Updated Charter
>
> His proposed replacement text is only the second half of his email, 
> which doesn't use the term "PBX" (thankfully).  It does use the term 
> "enterprises", but does not define the scope of that, nor does it 
> imply any and all enterprises would be involved or how (which I think 
> it's good to keep undefined).
>
> Examples would be an Enterprise using something out of PEPPERMINT 
> itself to provision its own proxies/databases, for example with what 
> service provider to use for what routes, or what SBE's to use to reach

> that service provider.  Or a service provider might exchange some 
> information with the Enterprise, or vice-versa, for similar 
> information.  The "enterprises" could be large corporations; or 
> perhaps a service provider's own internal employee system, or their 
> consumer voip service might be considered a separate, enterprise-type,

> from their other voip services/networks.
>
> -hadriel
>
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Tue, 1 Apr 2008 09:24:03 -0600
From: "Daryl Malas" <[email-masked]>
To: "Hadriel Kaplan" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

Comments in-line... 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Monday, March 31, 2008 9:01 PM
To: Daryl Malas; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

Hey Daryl,
Looks pretty good!
Minor comments inline...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]

> On Behalf Of Daryl Malas
> -------------------------------------
> New revision:
>
> PROPOSED CHARTER FOR PEPPERMINT
>
> The IETF has been working on various aspects of session-based 
> Multimedia peering among SIP Service Providers (SSPs), 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 following working groups' work 
> provides the underlying context for much of the intended work within 
> this
> charter:
>
> ENUM, which is specifically chartered to develop protocols that 
> involve the translation of E.164 numbers to URIs.
>
> SPEERMINT, which has been chartered to develop requirements and best 
> current practices among real-time application SSPs and how such 
> services may interconnect across administrative boundaries.  This work

> will provide details of how Session Establishment Data (SED) is 
> collected and what this data is comprised of, the use of this data to 
> properly identify an optimal path to the destination user agent (UA), 
> and the secure manners in which this and the SIP session data is 
> exchanged between all of the peering functions.  It is also recognizes

> peering relationships become more complex as multiple peers are added 
> to a common relationship, these complex aspects and requirements of 
> multiple, yet common peering relationships are defined with the 
> contexts of a peering Federation.

There are some grammatical errors in the last sentence above.  I think
you want to say: "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."

[DM] Agreed...I will fix this.

Having said that, I'm not actually sure I agree with it.  Just because I
peer with Foo, and Foo peers with Bar, does not mean I and Bar are in a
common Federation nor have a common relationship, except for that we're
both peers of Foo.  In other words I'm not convinced all relationships
are transitive.  Take, for example, an SSP X in Israel peering with SSP
Y in Egypt, who peers with SSP Z in Iran.

[DM] Okay, I am not sure how you read "indirect" peering into that
sentence.  Also, just because you are a member of a federation does not
suddenly give you a "golden key" to peer with everyone within it.  The
point of the sentence is to indicate there are potential complexities to
be considered within PEPPERMINT when peers are in multilateral
relationships.  It should not be PEPPERMINT to determine what those
architectural complexities are.  These are discussed, documented, and
determined within SPEERMINT; however, based on these complexities,
PEPPERMINT will need to take into consideration the provisioning of data
within a Federation.  It will be, potentially, different than a single
bi-lateral peering arrangement.

> The PEPPERMINT working group is chartered to define what data needs to

> be exchanged among Multimedia administrative domains, and how that 
> data

Maybe change it to "SIP Multimedia administrative domains..."?

[DM] I would rather suggest "SIP-enabled Multimedia administrative
domains..."

> should be structured, provisioned, and propagated. These protocols 
> would be outside the normal scope of establishing various forms of a 
> SIP session. These administrative domains are of any practical size 
> and could be any type of SSP, such as recognized telephony carriers, 
> enterprises, end-user groups, and Federations.
>
> Data exchanges to facilitate session-based Multimedia Interconnection 
> are typically between various bilateral or multilateral client User 
> Agents and related Registries.

I'm not sure I understand why the term "client User Agents" is used?  A
Proxy is not a User Agent, and neither is an ENUM server, for example.
Or do you just mean it's a User Agent with respect to being the Agent of
the data exchange?

[DM] I would suggest "client User Agents" is changed to "SIP User
Agents", but a proxy would not be provisioned within an ENUM server as
an end-point.   A B2BUA, otherwise known as a UA to SIP, would be.

> Data exchanges could include bulk data and/or real time updates. 
> Typical data includes mappings of phone numbers to URIs, policies 
> surrounding admission to various points of network interconnection, 
> and various types of interconnect data.  In addition, there is a 
> specific need for the exchange of such data between the Registry and 
> various types of network databases (e.g. Local Number Portability 
> (LNP), Calling Name (CNAM), etc.).
>
> 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, if possible.
>
> The final work product(s) from this working group will utilize and be 
> based on XML documents and XML document exchanges.
>
> ---------------------------------------
>
> Thanks...--Daryl
>
>
> _______________________________________________
> 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: Hadriel Kaplan <[email-masked]>
To: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>, Daryl Malas <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 1 Apr 2008 11:20:14 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

Imagine a big enterprise, having multiple branch offices, lots of user agents and proxies/servers/whatever.  They may want calls within a branch to stay in the branch, calls between certain branches to go over the public Internet, calls between other branches to use leased lines or VPNs, calls between other branches to use the PSTN or ESN-type TDM network, etc.  So they could potentially use an outcome of PEPPERMINT to dynamically provision their servers/proxies in the various branches with such routing data, and make changes as employees or groups are added or move branches.

OR another example is suppose this big enterprise connects to multiple service providers or federations, perhaps different ones for different branches - the providers or federations can dynamically inform the enterprise or its branches of which ingress points can be used for what routes, with potentially some other attributes yet to be defined.  That way as the provider/federation adds or removes ingress points or routes, it can do so in a more automated fashion.

I think, but I'm not sure, that including enterprises in the charter does not mean to say any of those things would happen, or that PEPPERMINT would actually define such uses explicitly/separately, or that they have to give special consideration to such - just that it's within the scope of the WG's purview to do so.  Is that correct?

-hadriel

> -----Original Message-----
> From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]]
>
> I do not agree with your example, yet. Can you be a little more
> specific, as to what information  peppermint would provide here?
>
> Thanks,
>
> Martin
>
> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Monday, March 31, 2008 10:18 PM
> To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; [email-masked]
> Subject: RE: [PEPPERMINT] Proposed Updated Charter
>
> His proposed replacement text is only the second half of his email,
> which doesn't use the term "PBX" (thankfully).  It does use the term
> "enterprises", but does not define the scope of that, nor does it imply
> any and all enterprises would be involved or how (which I think it's
> good to keep undefined).
>
> Examples would be an Enterprise using something out of PEPPERMINT itself
> to provision its own proxies/databases, for example with what service
> provider to use for what routes, or what SBE's to use to reach that
> service provider.  Or a service provider might exchange some information
> with the Enterprise, or vice-versa, for similar information.  The
> "enterprises" could be large corporations; or perhaps a service
> provider's own internal employee system, or their consumer voip service
> might be considered a separate, enterprise-type, from their other voip
> services/networks.
>
> -hadriel
>
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Tue, 1 Apr 2008 11:14:19 -0400
From: "Uzelac, Adam" <[email-masked]>
To: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>, "Hadriel Kaplan" <[email-masked]>, "Daryl Malas" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

I completely agree with Hadriel and believe that an enterprise most
certainly is one example of a SSP.  An enterprise would logically like
to dictate to the world how others should send multimedia sessions to
it.  For instance, they may want to dictate that all SIP communications
for its SIP administrative domain traverse another SSP (like L3, Global
Crossing, Comcast, etc) - maybe to perform some form of Signaling or
Media message handling like handling security certificates - and in
doing so would provision the SBEs of the L3, GC, Comcast as the
"Next-hop" the world should use to communicate with them.  This seems
very logical and empowering to the enterprise.

It should also be noted that enterprises are specifically called out and
included in SPEERMINT work.

Adam

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of DOLLY, 
> MARTIN C, ATTLABS
> Sent: Tuesday, April 01, 2008 7:08 AM
> To: Hadriel Kaplan; Daryl Malas; [email-masked]
> Subject: Re: [PEPPERMINT] Proposed Updated Charter
> 
> Hadriel,
> 
> I do not agree with your example, yet. Can you be a little 
> more specific, as to what information  peppermint would provide here?
> 
> Thanks,
> 
> Martin 
> 
> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Monday, March 31, 2008 10:18 PM
> To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; [email-masked]
> Subject: RE: [PEPPERMINT] Proposed Updated Charter
> 
> His proposed replacement text is only the second half of his 
> email, which doesn't use the term "PBX" (thankfully).  It 
> does use the term "enterprises", but does not define the 
> scope of that, nor does it imply any and all enterprises 
> would be involved or how (which I think it's good to keep undefined).
> 
> Examples would be an Enterprise using something out of 
> PEPPERMINT itself to provision its own proxies/databases, for 
> example with what service provider to use for what routes, or 
> what SBE's to use to reach that service provider.  Or a 
> service provider might exchange some information with the 
> Enterprise, or vice-versa, for similar information.  The 
> "enterprises" could be large corporations; or perhaps a 
> service provider's own internal employee system, or their 
> consumer voip service might be considered a separate, 
> enterprise-type, from their other voip services/networks.
> 
> -hadriel
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]
> On
> > Behalf Of DOLLY, MARTIN C, ATTLABS
> > Sent: Monday, March 31, 2008 9:31 PM
> > To: Daryl Malas; [email-masked]
> > Subject: Re: [PEPPERMINT] Proposed Updated Charter
> >
> > Hello,
> >
> > As I stated in the meeting, reference to enterprise/PBXs should be 
> > removed. If you think it should remain please give examples of the 
> > provisioned information?
> >
> > Thanks,
> >
> > Martin
> >
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]
> > On Behalf Of Daryl Malas
> > Sent: Monday, March 31, 2008 4:10 PM
> > To: [email-masked]
> > Subject: [PEPPERMINT] Proposed Updated Charter
> >
> > All,
> >
> > I was asked to re-write the charter using agreed upon SPEERMINT WG 
> > defined terms.  I also added/changed a few minor suggested details.
> The
> > update is below:
> >
> > ------------------------------------------
> > Existing charter:
> >
> > PROPOSED CHARTER FOR PEPPERMINT
> >
> > The IETF has been working on various aspects of session-based
> Multimedia
> > Interconnection among administrative domains. In addition, the IETF
> has
> > done significant work on data exchanges among various network
> elements.
> >
> > ENUM is specifically chartered to develop protocols that 
> involve the 
> > translation of E.164 numbers to URI's.
> >
> > SPEERMINT has been chartered to develop best current 
> practices among 
> > real-time application service providers and how such services 
> > interconnect across administrative boundaries.
> >
> > The PEPPERMINT work group is chartered to define what data 
> needs to be 
> > exchanged among Multimedia administrative domains, and how 
> that data 
> > should be structured provisioned and propagated. These 
> protocols would 
> > be outside the normal scope of establishing various forms of a SIP 
> > session. These administrative domains are of any practical size and 
> > could be service providers or enterprise SIP proxy's, such as PBX's.
> >
> > Data exchanges to facilitate session-based Multimedia 
> Interconnection 
> > are typically between various Client User Agents and Registries or 
> > bilateral or multilateral Registry to Registry.  Data 
> exchanges could 
> > include bulk data as well as real time updates. Typical 
> data include 
> > mappings of phone numbers to URIs, policies surrounding 
> admission to 
> > various points of network interconnection and various types 
> of trunk 
> > data.  In addition, there is a specific need for redistribution of
> such
> > Registry data to various types of network databases.
> >
> > The working group will draw upon expert advice and ongoing
> consultation
> > from the ENUM, SPEERMINT and PROVREG working groups. The 
> working group 
> > may also reuse elements of RFC 4114, if possible.
> >
> > The final work product(s) from this working group will 
> utilize and be 
> > based on XML documents and XML document exchanges.
> > -------------------------------------
> > New revision:
> >
> > PROPOSED CHARTER FOR PEPPERMINT
> >
> > The IETF has been working on various aspects of session-based
> Multimedia
> > peering among SIP Service Providers (SSPs), 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 following working groups' 
> work provides 
> > the underlying context for much of the intended work within this
> > charter:
> >
> > ENUM, which is specifically chartered to develop protocols that
> involve
> > the translation of E.164 numbers to URIs.
> >
> > SPEERMINT, which has been chartered to develop requirements 
> and best 
> > current practices among real-time application SSPs and how such
> services
> > may interconnect across administrative boundaries.  This work will 
> > provide details of how Session Establishment Data (SED) is collected
> and
> > what this data is comprised of, the use of this data to properly 
> > identify an optimal path to the destination user agent 
> (UA), and the 
> > secure manners in which this and the SIP session data is exchanged 
> > between all of the peering functions.  It is also 
> recognizes peering 
> > relationships become more complex as multiple peers are added to a 
> > common relationship, these complex aspects and requirements of
> multiple,
> > yet common peering relationships are defined with the contexts of a 
> > peering Federation.
> >
> > The PEPPERMINT working group is chartered to define what 
> data needs to 
> > be exchanged among Multimedia administrative domains, and how that
> data
> > should be structured, provisioned, and propagated. These protocols
> would
> > be outside the normal scope of establishing various forms of a SIP 
> > session. These administrative domains are of any practical size and 
> > could be any type of SSP, such as recognized telephony carriers, 
> > enterprises, end-user groups, and Federations.
> >
> > Data exchanges to facilitate session-based Multimedia 
> Interconnection 
> > are typically between various bilateral or multilateral client User 
> > Agents and related Registries.  Data exchanges could 
> include bulk data 
> > and/or real time updates. Typical data includes mappings of phone 
> > numbers to URIs, policies surrounding admission to various 
> points of 
> > network interconnection, and various types of interconnect 
> data.  In 
> > addition, there is a specific need for the exchange of such data
> between
> > the Registry and various types of network databases (e.g. 
> Local Number 
> > Portability (LNP), Calling Name (CNAM), etc.).
> >
> > 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, if possible.
> >
> > The final work product(s) from this working group will 
> utilize and be 
> > based on XML documents and XML document exchanges.
> >
> > ---------------------------------------
> >
> > Thanks...--Daryl
> >
> >
> > _______________________________________________
> > PEPPERMINT mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/peppermint
> > _______________________________________________
> > PEPPERMINT mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/peppermint
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/peppermint
> 
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Tue, 1 Apr 2008 09:14:11 -0600
From: "Daryl Malas" <[email-masked]>
To: "Richard Shockey" <[email-masked]>, "DOLLY, MARTIN C, ATTLABS" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

Richard,

Enterprise peering is within the scope of SPEERMINT, and I think they
should be considered within the general term of SIP Service Provider.

"A SIP Service Provider (or SSP) is an entity that provides session
   services utilizing SIP signaling to its customers."

IMHO, based on the above excerpt from the Terminology draft definition
of an SSP, I do not see why an enterprise cannot be considered within
this definition.  Their customers are their employees, whom they are
providing session services to.

--Daryl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Richard Shockey
Sent: Monday, March 31, 2008 8:26 PM
To: 'DOLLY, MARTIN C, ATTLABS'; [email-masked]
Subject: Re: [PEPPERMINT] Proposed Updated Charter

You are correct we did agree that for the time being this potential
application was out of scope for the charter, or is it?

I believe there was consensus that the first order charter would deal
principally with SSP to Registry and Registry to localized cached
servers.
Is that your understanding as well?

So If I understand this correctly your problem is with ..

In line ..

Please indicate what part of the text is objectionable etc or propose
alternative text. 

In other words is a enterprise a SSP? Inquiring minds want to know. :-) 

>  New revision:
>  
>  PROPOSED CHARTER FOR PEPPERMINT
>  
>  The IETF has been working on various aspects of session-based  
> Multimedia  peering among SIP Service Providers (SSPs), 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 following working groups' work 
> provides  the underlying context for much of the intended work within 
> this
>  charter:
>  
>  ENUM, which is specifically chartered to develop protocols that  
> involve  the translation of E.164 numbers to URIs.
>  
>  SPEERMINT, which has been chartered to develop requirements and best

> current practices among real-time application SSPs and how such  
> services  may interconnect across administrative boundaries.  This 
> work will  provide details of how Session Establishment Data (SED) is 
> collected  and  what this data is comprised of, the use of this data 
> to properly  identify an optimal path to the destination user agent 
> (UA), and the  secure manners in which this and the SIP session data 
> is exchanged  between all of the peering functions.  It is also 
> recognizes peering  relationships become more complex as multiple 
> peers are added to a  common relationship, these complex aspects and 
> requirements of  multiple,  yet common peering relationships are 
> defined with the contexts of a  peering Federation.
>  
>  The PEPPERMINT working group is chartered to define what data needs 
> to  be exchanged among Multimedia administrative domains, and how that

> data  should be structured, provisioned, and propagated. These 
> protocols  would  be outside the normal scope of establishing various 
> forms of a SIP  session. These administrative domains are of any 
> practical size and  could be any type of SSP, such as recognized 
> telephony carriers,  enterprises, end-user groups, and Federations.
^^^^^^^^^^^^^^^^^^^^^

Here..????

>  
>  Data exchanges to facilitate session-based Multimedia Interconnection

> are typically between various bilateral or multilateral client User  
> Agents and related Registries.  Data exchanges could include bulk data

> and/or real time updates. Typical data includes mappings of phone  
> numbers to URIs, policies surrounding admission to various points of  
> network interconnection, and various types of interconnect data.  In  
> addition, there is a specific need for the exchange of such data  
> between  the Registry and various types of network databases (e.g. 
> Local Number  Portability (LNP), Calling Name (CNAM), etc.).
>  
>  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, if possible.
>  
>  The final work product(s) from this working group will utilize and be

> based on XML documents and XML document exchanges.
>  
>  ---------------------------------------
>  
>  Thanks...--Daryl
>  
>  
>  _______________________________________________
>  PEPPERMINT mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/peppermint
>  _______________________________________________
>  PEPPERMINT mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/peppermint

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

Content-class: urn:content-classes:message
Date: Tue, 1 Apr 2008 10:13:10 -0500
From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
To: "Daryl Malas" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

Daryl,

I view AT&T differently depending on whether I am accessing them
intranet versus as an AT&T customer, so I do not see them as being the
same. In the intranet case, it is the AT&T IT department that controls
everything, which is different than when I am a customer of AT&T.

Martin 

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]] 
Sent: Tuesday, April 01, 2008 11:01 AM
To: DOLLY, MARTIN C, ATTLABS; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

Hello Martin,

I feel it is appropriate to include enterprises within the context of an
SSP.  Per the definition of an SSP, an enterprise provides SIP services
to its customers (employees), in much the same an operator would.  This
is the intention within the charter update below.

--Daryl 

-----Original Message-----
From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]] 
Sent: Monday, March 31, 2008 7:31 PM
To: Daryl Malas; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

Hello,

As I stated in the meeting, reference to enterprise/PBXs should be
removed. If you think it should remain please give examples of the
provisioned information?

Thanks,

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Daryl Malas
Sent: Monday, March 31, 2008 4:10 PM
To: [email-masked]
Subject: [PEPPERMINT] Proposed Updated Charter

All,

I was asked to re-write the charter using agreed upon SPEERMINT WG
defined terms.  I also added/changed a few minor suggested details.  The
update is below:

------------------------------------------
Existing charter:

PROPOSED CHARTER FOR PEPPERMINT

The IETF has been working on various aspects of session-based Multimedia
Interconnection among administrative domains. In addition, the IETF has
done significant work on data exchanges among various network elements.

ENUM is specifically chartered to develop protocols that involve the
translation of E.164 numbers to URI's.
 
SPEERMINT has been chartered to develop best current practices among
real-time application service providers and how such services
interconnect across administrative boundaries.

The PEPPERMINT work group is chartered to define what data needs to be
exchanged among Multimedia administrative domains, and how that data
should be structured provisioned and propagated. These protocols would
be outside the normal scope of establishing various forms of a SIP
session. These administrative domains are of any practical size and
could be service providers or enterprise SIP proxy's, such as PBX's.

Data exchanges to facilitate session-based Multimedia Interconnection
are typically between various Client User Agents and Registries or
bilateral or multilateral Registry to Registry.  Data exchanges could
include bulk data as well as real time updates. Typical data include
mappings of phone numbers to URIs, policies surrounding admission to
various points of network interconnection and various types of trunk
data.  In addition, there is a specific need for redistribution of such
Registry data to various types of network databases.  

The working group will draw upon expert advice and ongoing consultation
from the ENUM, SPEERMINT and PROVREG working groups. The working group
may also reuse elements of RFC 4114, if possible.

The final work product(s) from this working group will utilize and be
based on XML documents and XML document exchanges.
-------------------------------------
New revision:

PROPOSED CHARTER FOR PEPPERMINT

The IETF has been working on various aspects of session-based Multimedia
peering among SIP Service Providers (SSPs), 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 following working groups' work provides
the underlying context for much of the intended work within this
charter:

ENUM, which is specifically chartered to develop protocols that involve
the translation of E.164 numbers to URIs.
 
SPEERMINT, which has been chartered to develop requirements and best
current practices among real-time application SSPs and how such services
may interconnect across administrative boundaries.  This work will
provide details of how Session Establishment Data (SED) is collected and
what this data is comprised of, the use of this data to properly
identify an optimal path to the destination user agent (UA), and the
secure manners in which this and the SIP session data is exchanged
between all of the peering functions.  It is also recognizes peering
relationships become more complex as multiple peers are added to a
common relationship, these complex aspects and requirements of multiple,
yet common peering relationships are defined with the contexts of a
peering Federation.

The PEPPERMINT working group is chartered to define what data needs to
be exchanged among Multimedia administrative domains, and how that data
should be structured, provisioned, and propagated. These protocols would
be outside the normal scope of establishing various forms of a SIP
session. These administrative domains are of any practical size and
could be any type of SSP, such as recognized telephony carriers,
enterprises, end-user groups, and Federations.

Data exchanges to facilitate session-based Multimedia Interconnection
are typically between various bilateral or multilateral client User
Agents and related Registries.  Data exchanges could include bulk data
and/or real time updates. Typical data includes mappings of phone
numbers to URIs, policies surrounding admission to various points of
network interconnection, and various types of interconnect data.  In
addition, there is a specific need for the exchange of such data between
the Registry and various types of network databases (e.g. Local Number
Portability (LNP), Calling Name (CNAM), etc.).  

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, if possible.

The final work product(s) from this working group will utilize and be
based on XML documents and XML document exchanges.

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

Thanks...--Daryl

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

Content-class: urn:content-classes:message
Date: Tue, 1 Apr 2008 09:08:54 -0600
From: "Daryl Malas" <[email-masked]>
To: "Hadriel Kaplan" <[email-masked]>, "DOLLY, MARTIN C, ATTLABS" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

Hadriel,

This was the intention.

Thanks,

Daryl

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Monday, March 31, 2008 8:18 PM
To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

His proposed replacement text is only the second half of his email,
which doesn't use the term "PBX" (thankfully).  It does use the term
"enterprises", but does not define the scope of that, nor does it imply
any and all enterprises would be involved or how (which I think it's
good to keep undefined).

Examples would be an Enterprise using something out of PEPPERMINT itself
to provision its own proxies/databases, for example with what service
provider to use for what routes, or what SBE's to use to reach that
service provider.  Or a service provider might exchange some information
with the Enterprise, or vice-versa, for similar information.  The
"enterprises" could be large corporations; or perhaps a service
provider's own internal employee system, or their consumer voip service
might be considered a separate, enterprise-type, from their other voip
services/networks.

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]

> On Behalf Of DOLLY, MARTIN C, ATTLABS
> Sent: Monday, March 31, 2008 9:31 PM
> To: Daryl Malas; [email-masked]
> Subject: Re: [PEPPERMINT] Proposed Updated Charter
>
> Hello,
>
> As I stated in the meeting, reference to enterprise/PBXs should be 
> removed. If you think it should remain please give examples of the 
> provisioned information?
>
> Thanks,
>
> Martin
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Daryl Malas
> Sent: Monday, March 31, 2008 4:10 PM
> To: [email-masked]
> Subject: [PEPPERMINT] Proposed Updated Charter
>
> All,
>
> I was asked to re-write the charter using agreed upon SPEERMINT WG 
> defined terms.  I also added/changed a few minor suggested details.  
> The update is below:
>
> ------------------------------------------
> Existing charter:
>
> PROPOSED CHARTER FOR PEPPERMINT
>
> The IETF has been working on various aspects of session-based 
> Multimedia Interconnection among administrative domains. In addition, 
> the IETF has done significant work on data exchanges among various
network elements.
>
> ENUM is specifically chartered to develop protocols that involve the 
> translation of E.164 numbers to URI's.
>
> SPEERMINT has been chartered to develop best current practices among 
> real-time application service providers and how such services 
> interconnect across administrative boundaries.
>
> The PEPPERMINT work group is chartered to define what data needs to be

> exchanged among Multimedia administrative domains, and how that data 
> should be structured provisioned and propagated. These protocols would

> be outside the normal scope of establishing various forms of a SIP 
> session. These administrative domains are of any practical size and 
> could be service providers or enterprise SIP proxy's, such as PBX's.
>
> Data exchanges to facilitate session-based Multimedia Interconnection 
> are typically between various Client User Agents and Registries or 
> bilateral or multilateral Registry to Registry.  Data exchanges could 
> include bulk data as well as real time updates. Typical data include 
> mappings of phone numbers to URIs, policies surrounding admission to 
> various points of network interconnection and various types of trunk 
> data.  In addition, there is a specific need for redistribution of 
> such Registry data to various types of network databases.
>
> The working group will draw upon expert advice and ongoing 
> consultation from the ENUM, SPEERMINT and PROVREG working groups. The 
> working group may also reuse elements of RFC 4114, if possible.
>
> The final work product(s) from this working group will utilize and be 
> based on XML documents and XML document exchanges.
> -------------------------------------
> New revision:
>
> PROPOSED CHARTER FOR PEPPERMINT
>
> The IETF has been working on various aspects of session-based 
> Multimedia peering among SIP Service Providers (SSPs), 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 following working groups' work 
> provides the underlying context for much of the intended work within 
> this
> charter:
>
> ENUM, which is specifically chartered to develop protocols that 
> involve the translation of E.164 numbers to URIs.
>
> SPEERMINT, which has been chartered to develop requirements and best 
> current practices among real-time application SSPs and how such 
> services may interconnect across administrative boundaries.  This work

> will provide details of how Session Establishment Data (SED) is 
> collected and what this data is comprised of, the use of this data to 
> properly identify an optimal path to the destination user agent (UA), 
> and the secure manners in which this and the SIP session data is 
> exchanged between all of the peering functions.  It is also recognizes

> peering relationships become more complex as multiple peers are added 
> to a common relationship, these complex aspects and requirements of 
> multiple, yet common peering relationships are defined with the 
> contexts of a peering Federation.
>
> The PEPPERMINT working group is chartered to define what data needs to

> be exchanged among Multimedia administrative domains, and how that 
> data should be structured, provisioned, and propagated. These 
> protocols would be outside the normal scope of establishing various 
> forms of a SIP session. These administrative domains are of any 
> practical size and could be any type of SSP, such as recognized 
> telephony carriers, enterprises, end-user groups, and Federations.
>
> Data exchanges to facilitate session-based Multimedia Interconnection 
> are typically between various bilateral or multilateral client User 
> Agents and related Registries.  Data exchanges could include bulk data

> and/or real time updates. Typical data includes mappings of phone 
> numbers to URIs, policies surrounding admission to various points of 
> network interconnection, and various types of interconnect data.  In 
> addition, there is a specific need for the exchange of such data 
> between the Registry and various types of network databases (e.g. 
> Local Number Portability (LNP), Calling Name (CNAM), etc.).
>
> 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, if possible.
>
> The final work product(s) from this working group will utilize and be 
> based on XML documents and XML document exchanges.
>
> ---------------------------------------
>
> Thanks...--Daryl
>
>
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/peppermint
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/peppermint
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Tue, 1 Apr 2008 09:01:11 -0600
From: "Daryl Malas" <[email-masked]>
To: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

Hello Martin,

I feel it is appropriate to include enterprises within the context of an
SSP.  Per the definition of an SSP, an enterprise provides SIP services
to its customers (employees), in much the same an operator would.  This
is the intention within the charter update below.

--Daryl 

-----Original Message-----
From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]] 
Sent: Monday, March 31, 2008 7:31 PM
To: Daryl Malas; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

Hello,

As I stated in the meeting, reference to enterprise/PBXs should be
removed. If you think it should remain please give examples of the
provisioned information?

Thanks,

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Daryl Malas
Sent: Monday, March 31, 2008 4:10 PM
To: [email-masked]
Subject: [PEPPERMINT] Proposed Updated Charter

All,

I was asked to re-write the charter using agreed upon SPEERMINT WG
defined terms.  I also added/changed a few minor suggested details.  The
update is below:

------------------------------------------
Existing charter:

PROPOSED CHARTER FOR PEPPERMINT

The IETF has been working on various aspects of session-based Multimedia
Interconnection among administrative domains. In addition, the IETF has
done significant work on data exchanges among various network elements.

ENUM is specifically chartered to develop protocols that involve the
translation of E.164 numbers to URI's.
 
SPEERMINT has been chartered to develop best current practices among
real-time application service providers and how such services
interconnect across administrative boundaries.

The PEPPERMINT work group is chartered to define what data needs to be
exchanged among Multimedia administrative domains, and how that data
should be structured provisioned and propagated. These protocols would
be outside the normal scope of establishing various forms of a SIP
session. These administrative domains are of any practical size and
could be service providers or enterprise SIP proxy's, such as PBX's.

Data exchanges to facilitate session-based Multimedia Interconnection
are typically between various Client User Agents and Registries or
bilateral or multilateral Registry to Registry.  Data exchanges could
include bulk data as well as real time updates. Typical data include
mappings of phone numbers to URIs, policies surrounding admission to
various points of network interconnection and various types of trunk
data.  In addition, there is a specific need for redistribution of such
Registry data to various types of network databases.  

The working group will draw upon expert advice and ongoing consultation
from the ENUM, SPEERMINT and PROVREG working groups. The working group
may also reuse elements of RFC 4114, if possible.

The final work product(s) from this working group will utilize and be
based on XML documents and XML document exchanges.
-------------------------------------
New revision:

PROPOSED CHARTER FOR PEPPERMINT

The IETF has been working on various aspects of session-based Multimedia
peering among SIP Service Providers (SSPs), 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 following working groups' work provides
the underlying context for much of the intended work within this
charter:

ENUM, which is specifically chartered to develop protocols that involve
the translation of E.164 numbers to URIs.
 
SPEERMINT, which has been chartered to develop requirements and best
current practices among real-time application SSPs and how such services
may interconnect across administrative boundaries.  This work will
provide details of how Session Establishment Data (SED) is collected and
what this data is comprised of, the use of this data to properly
identify an optimal path to the destination user agent (UA), and the
secure manners in which this and the SIP session data is exchanged
between all of the peering functions.  It is also recognizes peering
relationships become more complex as multiple peers are added to a
common relationship, these complex aspects and requirements of multiple,
yet common peering relationships are defined with the contexts of a
peering Federation.

The PEPPERMINT working group is chartered to define what data needs to
be exchanged among Multimedia administrative domains, and how that data
should be structured, provisioned, and propagated. These protocols would
be outside the normal scope of establishing various forms of a SIP
session. These administrative domains are of any practical size and
could be any type of SSP, such as recognized telephony carriers,
enterprises, end-user groups, and Federations.

Data exchanges to facilitate session-based Multimedia Interconnection
are typically between various bilateral or multilateral client User
Agents and related Registries.  Data exchanges could include bulk data
and/or real time updates. Typical data includes mappings of phone
numbers to URIs, policies surrounding admission to various points of
network interconnection, and various types of interconnect data.  In
addition, there is a specific need for the exchange of such data between
the Registry and various types of network databases (e.g. Local Number
Portability (LNP), Calling Name (CNAM), etc.).  

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, if possible.

The final work product(s) from this working group will utilize and be
based on XML documents and XML document exchanges.

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

Thanks...--Daryl

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

Content-class: urn:content-classes:message
Date: Tue, 1 Apr 2008 06:08:19 -0500
From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
To: "Hadriel Kaplan" <[email-masked]>, "Daryl Malas" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

Hadriel,

I do not agree with your example, yet. Can you be a little more
specific, as to what information  peppermint would provide here?

Thanks,

Martin 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Monday, March 31, 2008 10:18 PM
To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; [email-masked]
Subject: RE: [PEPPERMINT] Proposed Updated Charter

His proposed replacement text is only the second half of his email,
which doesn't use the term "PBX" (thankfully).  It does use the term
"enterprises", but does not define the scope of that, nor does it imply
any and all enterprises would be involved or how (which I think it's
good to keep undefined).

Examples would be an Enterprise using something out of PEPPERMINT itself
to provision its own proxies/databases, for example with what service
provider to use for what routes, or what SBE's to use to reach that
service provider.  Or a service provider might exchange some information
with the Enterprise, or vice-versa, for similar information.  The
"enterprises" could be large corporations; or perhaps a service
provider's own internal employee system, or their consumer voip service
might be considered a separate, enterprise-type, from their other voip
services/networks.

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of DOLLY, MARTIN C, ATTLABS
> Sent: Monday, March 31, 2008 9:31 PM
> To: Daryl Malas; [email-masked]
> Subject: Re: [PEPPERMINT] Proposed Updated Charter
>
> Hello,
>
> As I stated in the meeting, reference to enterprise/PBXs should be
> removed. If you think it should remain please give examples of the
> provisioned information?
>
> Thanks,
>
> Martin
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Daryl Malas
> Sent: Monday, March 31, 2008 4:10 PM
> To: [email-masked]
> Subject: [PEPPERMINT] Proposed Updated Charter
>
> All,
>
> I was asked to re-write the charter using agreed upon SPEERMINT WG
> defined terms.  I also added/changed a few minor suggested details.
The
> update is below:
>
> ------------------------------------------
> Existing charter:
>
> PROPOSED CHARTER FOR PEPPERMINT
>
> The IETF has been working on various aspects of session-based
Multimedia
> Interconnection among administrative domains. In addition, the IETF
has
> done significant work on data exchanges among various network
elements.
>
> ENUM is specifically chartered to develop protocols that involve the
> translation of E.164 numbers to URI's.
>
> SPEERMINT has been chartered to develop best current practices among
> real-time application service providers and how such services
> interconnect across administrative boundaries.
>
> The PEPPERMINT work group is chartered to define what data needs to be
> exchanged among Multimedia administrative domains, and how that data
> should be structured provisioned and propagated. These protocols would
> be outside the normal scope of establishing various forms of a SIP
> session. These administrative domains are of any practical size and
> could be service providers or enterprise SIP proxy's, such as PBX's.
>
> Data exchanges to facilitate session-based Multimedia Interconnection
> are typically between various Client User Agents and Registries or
> bilateral or multilateral Registry to Registry.  Data exchanges could
> include bulk data as well as real time updates. Typical data include
> mappings of phone numbers to URIs, policies surrounding admission to
> various points of network interconnection and various types of trunk
> data.  In addition, there is a specific need for redistribution of
such
> Registry data to various types of network databases.
>
> The working group will draw upon expert advice and ongoing
consultation
> from the ENUM, SPEERMINT and PROVREG working groups. The working group
> may also reuse elements of RFC 4114, if possible.
>
> The final work product(s) from this working group will utilize and be
> based on XML documents and XML document exchanges.
> -------------------------------------
> New revision:
>
> PROPOSED CHARTER FOR PEPPERMINT
>
> The IETF has been working on various aspects of session-based
Multimedia
> peering among SIP Service Providers (SSPs), 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 following working groups' work provides
> the underlying context for much of the intended work within this
> charter:
>
> ENUM, which is specifically chartered to develop protocols that
involve
> the translation of E.164 numbers to URIs.
>
> SPEERMINT, which has been chartered to develop requirements and best
> current practices among real-time application SSPs and how such
services
> may interconnect across administrative boundaries.  This work will
> provide details of how Session Establishment Data (SED) is collected
and
> what this data is comprised of, the use of this data to properly
> identify an optimal path to the destination user agent (UA), and the
> secure manners in which this and the SIP session data is exchanged
> between all of the peering functions.  It is also recognizes peering
> relationships become more complex as multiple peers are added to a
> common relationship, these complex aspects and requirements of
multiple,
> yet common peering relationships are defined with the contexts of a
> peering Federation.
>
> The PEPPERMINT working group is chartered to define what data needs to
> be exchanged among Multimedia administrative domains, and how that
data
> should be structured, provisioned, and propagated. These protocols
would
> be outside the normal scope of establishing various forms of a SIP
> session. These administrative domains are of any practical size and
> could be any type of SSP, such as recognized telephony carriers,
> enterprises, end-user groups, and Federations.
>
> Data exchanges to facilitate session-based Multimedia Interconnection
> are typically between various bilateral or multilateral client User
> Agents and related Registries.  Data exchanges could include bulk data
> and/or real time updates. Typical data includes mappings of phone
> numbers to URIs, policies surrounding admission to various points of
> network interconnection, and various types of interconnect data.  In
> addition, there is a specific need for the exchange of such data
between
> the Registry and various types of network databases (e.g. Local Number
> Portability (LNP), Calling Name (CNAM), etc.).
>
> 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, if possible.
>
> The final work product(s) from this working group will utilize and be
> based on XML documents and XML document exchanges.
>
> ---------------------------------------
>
> Thanks...--Daryl
>
>
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/peppermint
> _______________________________________________
> 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: "Richard Shockey" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Mon, 28 Apr 2008 12:20:26 -0400
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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.

>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]]
>  On Behalf Of [email-masked]
>  Sent: Monday, April 28, 2008 7:28 AM
>  To: [email-masked]
>  Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
>  
>  > >  DY> Do you see the data to be exchanged to also include
>  information
>  > >  using in billing?
>  >
>  > 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.
>  
>  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

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

To: [email-masked]
From: [email-masked]
Date: Mon, 28 Apr 2008 12:27:35 +0100
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

> >  DY> Do you see the data to be exchanged to also include information
> >  using in billing?
> 
> 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.

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

Date: Thu, 24 Apr 2008 23:03:55 +0200
From: Otmar Lendl <[email-masked]>
To: "[email-masked]" <[email-masked]>
Mail-Followup-To: Otmar Lendl <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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
-- 
// 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: "Richard Shockey" <[email-masked]>
To: "'David Schwartz'" <[email-masked]>, "'Hadriel Kaplan'" <[email-masked]>
Date: Thu, 24 Apr 2008 14:36:09 -0400
Cc: 'Daryl Malas' <[email-masked]>, [email-masked]
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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

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.

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

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

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

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. 

>  

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

From: David Schwartz <[email-masked]>
To: Hadriel Kaplan <[email-masked]>
Date: Thu, 24 Apr 2008 21:01:45 +0300
Cc: "[email-masked]" <[email-masked]>, Daryl Malas <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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
> _______________________________________________
> 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: Hadriel Kaplan <[email-masked]>
To: Richard Shockey <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 24 Apr 2008 12:36:07 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter  Version 02
Sender: [email-masked]

Looks good to me, fwiw.

-hadriel

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]]
> 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
>
>
> 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
>
>
> 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 (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.
>
> 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.
>
> 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 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
>      - 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
>
> 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
>
>
> 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

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

From: Hadriel Kaplan <[email-masked]>
To: "Dwight, Timothy M (Tim)" <[email-masked]>, Richard Shockey <[email-masked]>, "PFAUTZ, PENN L, ATTCORP" <[email-masked]>,  Daryl Malas <[email-masked]>, Otmar Lendl <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 24 Apr 2008 12:31:02 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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

From: "Richard Shockey" <[email-masked]>
To: "'Hadriel Kaplan'" <[email-masked]>, "'PFAUTZ, PENN L, ATTCORP'" <[email-masked]>, "'Dwight, Timothy M \(Tim\)'" <[email-masked]>, "'Daryl Malas'" <[email-masked]>, "'Otmar Lendl'" <[email-masked]>, <[email-masked]>
Date: Thu, 24 Apr 2008 12:32:07 -0400
Subject: [PEPPERMINT] DRINKS PROPOSED Charter  Version 02
Sender: [email-masked]

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

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

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.  

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

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

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

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

Date: Thu, 24 Apr 2008 16:05:21 +0000
From: "Dwight, Timothy M (Tim)" <[email-masked]>
To: Richard Shockey <[email-masked]>, "PFAUTZ, PENN L, ATTCORP" <[email-masked]>, Hadriel Kaplan <[email-masked]>, Daryl Malas <[email-masked]>,  Otmar Lendl <[email-masked]>, [email-masked]
Content-class: urn:content-classes:message
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

Richard, 

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

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.

> >  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. 
> 
> I beg to differ. In the context of IETF WG charters this is perfectly
> 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.

> > and it doesn't accomplish anything, let's
> > delete it and declare victory.  

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

> > 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.
> 
> 
> Well what is your proposed WG scope text? 

See above.

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

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

> 
> 
> >  
> >  Tim
> >  
> >  
> >  > -----Original Message-----
> >  > From: Richard Shockey [mailto:[email-masked]]
> >  > 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]
> >  > 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.
> >  >
> >  >
> >  > 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
> >  >
> >  > **************
> >  >
> >  >
> >  >
> >  >
> >  >
> >  > >  -----Original Message-----
> >  > >  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]
> >  > >  Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter
> >  > ..comments please.
> >  > >
> >  > >  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.
> >  > >
> >  > >
> >  > >  > -----Original Message-----
> >  > >  > 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
> >  > >
> >  > >  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
> >  > >  _______________________________________________
> >  > >  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: Hadriel Kaplan <[email-masked]>
To: Richard Shockey <[email-masked]>, "'PFAUTZ, PENN L, ATTCORP'" <[email-masked]>, "'Dwight, Timothy M (Tim)'" <[email-masked]>, 'Daryl Malas' <[email-masked]>, 'Otmar Lendl' <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 24 Apr 2008 11:56:03 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]]
>
> **************
>
> 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

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

> + Service Areas
>      - Individual, ranges, or groups of ENUMservice identifiers
>      - Route associations

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

> + Treatment Profiles
>      - Priority
>      - Location
>
> Potential SED Data types not in scope will be session rating or other
> billing or pricing information between SSP's
>
> **************
>
>
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Thu, 24 Apr 2008 11:55:16 -0400
From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
To: "Guyton, Deborah A" <[email-masked]>, "Richard Shockey" <[email-masked]>, "Hadriel Kaplan" <[email-masked]>, "Dwight, Timothy M (Tim)" <[email-masked]>, "Daryl Malas" <[email-masked]>, "Otmar Lendl" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

How about...

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

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

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

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

Content-class: urn:content-classes:message
Date: Thu, 24 Apr 2008 11:41:45 -0400
From: "Guyton, Deborah A" <[email-masked]>
To: "Richard Shockey" <[email-masked]>, "PFAUTZ, PENN L, ATTCORP" <[email-masked]>, "Hadriel Kaplan" <[email-masked]>, "Dwight, Timothy M \(Tim\)" <[email-masked]>, "Daryl Malas" <[email-masked]>, "Otmar Lendl" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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.

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

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

>  -----Original Message-----
>  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]
>  Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
>  
>  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.
>  
>  
>  > -----Original Message-----
>  > 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
>  
>  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
>  _______________________________________________
>  PEPPERMINT mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/peppermint

_______________________________________________
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: "Richard Shockey" <[email-masked]>
To: "'Dwight, Timothy M \(Tim\)'" <[email-masked]>, "'PFAUTZ, PENN L, ATTCORP'" <[email-masked]>, "'Hadriel Kaplan'" <[email-masked]>, "'Daryl Malas'" <[email-masked]>, "'Otmar Lendl'" <[email-masked]>, <[email-masked]>
Date: Thu, 24 Apr 2008 11:22:19 -0400
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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

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.

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

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

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.

>  
>  Tim
>  
>  
>  > -----Original Message-----
>  > From: Richard Shockey [mailto:[email-masked]]
>  > 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]
>  > 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.
>  >
>  >
>  > 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
>  >
>  > **************
>  >
>  >
>  >
>  >
>  >
>  > >  -----Original Message-----
>  > >  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]
>  > >  Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter
>  > ..comments please.
>  > >
>  > >  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.
>  > >
>  > >
>  > >  > -----Original Message-----
>  > >  > 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
>  > >
>  > >  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
>  > >  _______________________________________________
>  > >  PEPPERMINT mailing list
>  > >  [email-masked]
>  > >  https://www.ietf.org/mailman/listinfo/peppermint
>  >
>  >

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

Date: Thu, 24 Apr 2008 14:51:47 +0000
From: "Dwight, Timothy M (Tim)" <[email-masked]>
To: Richard Shockey <[email-masked]>, "PFAUTZ, PENN L, ATTCORP" <[email-masked]>, Hadriel Kaplan <[email-masked]>, Daryl Malas <[email-masked]>,  Otmar Lendl <[email-masked]>, [email-masked]
Content-class: urn:content-classes:message
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]] 
> 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]
> 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.
> 
> 
> 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
> 
> **************
> 
> 
> 
> 
> 
> >  -----Original Message-----
> >  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]
> >  Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter 
> ..comments please.
> >  
> >  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.
> >  
> >  
> >  > -----Original Message-----
> >  > 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
> >  
> >  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
> >  _______________________________________________
> >  PEPPERMINT mailing list
> >  [email-masked]
> >  https://www.ietf.org/mailman/listinfo/peppermint
> 
> 
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Thu, 24 Apr 2008 08:44:17 -0600
From: "Daryl Malas" <[email-masked]>
To: "Richard Shockey" <[email-masked]>, "PFAUTZ, PENN L, ATTCORP" <[email-masked]>, "Hadriel Kaplan" <[email-masked]>, "Dwight, Timothy M (Tim)" <[email-masked]>, "Otmar Lendl" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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.

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

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

>  -----Original Message-----
>  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]
>  Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
>  
>  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.
>  
>  
>  > -----Original Message-----
>  > 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
>  
>  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
>  _______________________________________________
>  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: "Richard Shockey" <[email-masked]>
To: "'PFAUTZ, PENN L, ATTCORP'" <[email-masked]>, "'Hadriel Kaplan'" <[email-masked]>, "'Dwight, Timothy M \(Tim\)'" <[email-masked]>, "'Daryl Malas'" <[email-masked]>, "'Otmar Lendl'" <[email-masked]>, <[email-masked]>
Date: Thu, 24 Apr 2008 10:30:31 -0400
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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

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

>  -----Original Message-----
>  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]
>  Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
>  
>  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.
>  
>  
>  > -----Original Message-----
>  > 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
>  
>  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
>  _______________________________________________
>  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: "Richard Shockey" <[email-masked]>
To: "'Hadriel Kaplan'" <[email-masked]>, "'Dwight, Timothy M \(Tim\)'" <[email-masked]>, "'Daryl Malas'" <[email-masked]>, "'Otmar Lendl'" <[email-masked]>, <[email-masked]>
Date: Thu, 24 Apr 2008 09:34:55 -0400
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

>  
>  > -----Original Message-----
>  > 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
>  
>  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)

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

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

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

Works for me ...

>  
>  -hadriel

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

Content-class: urn:content-classes:message
Date: Thu, 24 Apr 2008 08:02:29 -0400
From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
To: "Hadriel Kaplan" <[email-masked]>, "Richard Shockey" <[email-masked]>, "Dwight, Timothy M (Tim)" <[email-masked]>, "Daryl Malas" <[email-masked]>, "Otmar Lendl" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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.

> -----Original Message-----
> 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

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
_______________________________________________
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: David Schwartz <[email-masked]>
To: Hadriel Kaplan <[email-masked]>
Date: Thu, 24 Apr 2008 07:16:47 +0300
Cc: "[email-masked]" <[email-masked]>, Daryl Malas <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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:

>
>> -----Original Message-----
>> 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
>
> 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
> _______________________________________________
> 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: Hadriel Kaplan <[email-masked]>
To: Richard Shockey <[email-masked]>, "'Dwight, Timothy M (Tim)'" <[email-masked]>, 'Daryl Malas' <[email-masked]>, 'Otmar Lendl' <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 23 Apr 2008 23:45:09 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

> -----Original Message-----
> 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

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

From: "Richard Shockey" <[email-masked]>
To: "'Dwight, Timothy M \(Tim\)'" <[email-masked]>, "'Daryl Malas'" <[email-masked]>, "'Hadriel Kaplan'" <[email-masked]>, "'Otmar Lendl'" <[email-masked]>, <[email-masked]>
Date: Wed, 23 Apr 2008 17:49:20 -0400
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

>  
>  Daryl,
>  
>  > 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?

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. 

>  >
>  > [DM] Instead of explicitly defining the model at this point, I
>  believe
>  > we are trying to describe well-understood characteristics of
>  > the model.
>  
>  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:

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

>  
>           + 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
>  
>  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?

>  
>  
>  > 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.
>  
>  Is it written down anywhere?
>  
>  
>  > 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?
>  >
>  > [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?
>  
>  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.

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

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

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

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

Date: Wed, 23 Apr 2008 19:24:54 +0000
From: "Dwight, Timothy M (Tim)" <[email-masked]>
To: Daryl Malas <[email-masked]>, Hadriel Kaplan <[email-masked]>, Richard Shockey <[email-masked]>,  Otmar Lendl <[email-masked]>, [email-masked]
Content-class: urn:content-classes:message
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

Daryl, 

> 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?
> 
> [DM] Instead of explicitly defining the model at this point, I believe
> we are trying to describe well-understood characteristics of 
> the model.

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

That looks like a data model to me.

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

Is it written down anywhere?

> 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?
> 
> [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?

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

Content-class: urn:content-classes:message
Date: Wed, 23 Apr 2008 13:05:05 -0600
From: "Daryl Malas" <[email-masked]>
To: "Hadriel Kaplan" <[email-masked]>, "Dwight, Timothy M (Tim)" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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

> -----Original Message-----
> From: Dwight, Timothy M (Tim) 
> [mailto:[email-masked]]
> Sent: Wednesday, April 23, 2008 1:00 PM
> 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?
> 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
>
>
> > -----Original Message-----
> > From: Daryl Malas [mailto:[email-masked]]
> > Sent: Wednesday, April 23, 2008 11:48 AM
> > To: Dwight, Timothy M (Tim); Hadriel Kaplan; Richard Shockey; Otmar 
> > Lendl; [email-masked]
> > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
> >
> > 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.
> >
> > Do we have to determine the data model now?  This seems premature 
> > when we've not yet considered use cases.
> >
> > Tim
> >
> >
> > > -----Original Message-----
> > > 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]
> > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments
please.
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Daryl Malas [mailto:[email-masked]]
> > > >
> > > > 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:
> > >
> > > 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
> > > >                 - Destination SIP/SIPS/TEL URI Egress and
> > > Ingress Routes
> > > >                 - Relevant route names, identifiers, and
services
> > > >                 - 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 
> > > :)
> > >
> > >
> > > >         + Service Areas
> > > >                 - Individual, ranges, or groups of ENUMservice 
> > > > identifiers
> > > >                 - Route associations
> > >
> > > I don't know what a "Route association" is?
> > >
> > >
> > > >         + Treatment Profiles
> > > >                 - Priority
> > > >                 - 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
> > > _______________________________________________
> > > 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: Hadriel Kaplan <[email-masked]>
To: "Dwight, Timothy M (Tim)" <[email-masked]>, Daryl Malas <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 23 Apr 2008 13:27:24 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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

> -----Original Message-----
> From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
> Sent: Wednesday, April 23, 2008 1:00 PM
> 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?
> 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
>
>
> > -----Original Message-----
> > From: Daryl Malas [mailto:[email-masked]]
> > Sent: Wednesday, April 23, 2008 11:48 AM
> > To: Dwight, Timothy M (Tim); Hadriel Kaplan; Richard Shockey;
> > Otmar Lendl; [email-masked]
> > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
> >
> > 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.
> >
> > Do we have to determine the data model now?  This seems premature when
> > we've not yet considered use cases.
> >
> > Tim
> >
> >
> > > -----Original Message-----
> > > 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]
> > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Daryl Malas [mailto:[email-masked]]
> > > >
> > > > 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:
> > >
> > > 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
> > > >                 - Destination SIP/SIPS/TEL URI Egress and
> > > Ingress Routes
> > > >                 - Relevant route names, identifiers, and services
> > > >                 - 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 :)
> > >
> > >
> > > >         + Service Areas
> > > >                 - Individual, ranges, or groups of ENUMservice
> > > > identifiers
> > > >                 - Route associations
> > >
> > > I don't know what a "Route association" is?
> > >
> > >
> > > >         + Treatment Profiles
> > > >                 - Priority
> > > >                 - 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
> > > _______________________________________________
> > > 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: "Richard Shockey" <[email-masked]>
To: "'Dwight, Timothy M \(Tim\)'" <[email-masked]>, "'Daryl Malas'" <[email-masked]>, "'Hadriel Kaplan'" <[email-masked]>, "'Otmar Lendl'" <[email-masked]>, <[email-masked]>
Date: Wed, 23 Apr 2008 13:27:56 -0400
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

>  -----Original Message-----
>  From: Dwight, Timothy M (Tim)
>  [mailto:[email-masked]]
>  Sent: Wednesday, April 23, 2008 1:00 PM
>  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?

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. 

>  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
>  
>  
>  > -----Original Message-----
>  > From: Daryl Malas [mailto:[email-masked]]
>  > Sent: Wednesday, April 23, 2008 11:48 AM
>  > To: Dwight, Timothy M (Tim); Hadriel Kaplan; Richard Shockey;
>  > Otmar Lendl; [email-masked]
>  > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
>  >
>  > 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.
>  >
>  > Do we have to determine the data model now?  This seems premature
>  when
>  > we've not yet considered use cases.
>  >
>  > Tim
>  >
>  >
>  > > -----Original Message-----
>  > > 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]
>  > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments
>  please.
>  > >
>  > >
>  > >
>  > > > -----Original Message-----
>  > > > From: Daryl Malas [mailto:[email-masked]]
>  > > >
>  > > > 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:
>  > >
>  > > 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
>  > > >                 - Destination SIP/SIPS/TEL URI Egress and
>  > > Ingress Routes
>  > > >                 - Relevant route names, identifiers, and
>  services
>  > > >                 - 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
>  :)
>  > >
>  > >
>  > > >         + Service Areas
>  > > >                 - Individual, ranges, or groups of ENUMservice
>  > > > identifiers
>  > > >                 - Route associations
>  > >
>  > > I don't know what a "Route association" is?
>  > >
>  > >
>  > > >         + Treatment Profiles
>  > > >                 - Priority
>  > > >                 - 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
>  > > _______________________________________________
>  > > PEPPERMINT mailing list
>  > > [email-masked]
>  > > https://www.ietf.org/mailman/listinfo/peppermint
>  > >
>  >

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

Content-class: urn:content-classes:message
Date: Wed, 23 Apr 2008 11:13:39 -0600
From: "Daryl Malas" <[email-masked]>
To: "Dwight, Timothy M (Tim)" <[email-masked]>, "Hadriel Kaplan" <[email-masked]>, "Richard Shockey" <[email-masked]>, "Otmar Lendl" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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

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?

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

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?

[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

> -----Original Message-----
> From: Daryl Malas [mailto:[email-masked]]
> Sent: Wednesday, April 23, 2008 11:48 AM
> To: Dwight, Timothy M (Tim); Hadriel Kaplan; Richard Shockey; Otmar 
> Lendl; [email-masked]
> Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
> 
> 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.
> 
> Do we have to determine the data model now?  This seems premature when

> we've not yet considered use cases.
> 
> Tim
> 
> 
> > -----Original Message-----
> > 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]
> > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Daryl Malas [mailto:[email-masked]]
> > >
> > > 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:
> > 
> > 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
> > >                 - Destination SIP/SIPS/TEL URI Egress and
> > Ingress Routes
> > >                 - Relevant route names, identifiers, and services
> > >                 - 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 :)
> > 
> > 
> > >         + Service Areas
> > >                 - Individual, ranges, or groups of ENUMservice 
> > > identifiers
> > >                 - Route associations
> > 
> > I don't know what a "Route association" is?
> > 
> > 
> > >         + Treatment Profiles
> > >                 - Priority
> > >                 - 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
> > _______________________________________________
> > PEPPERMINT mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/peppermint
> > 
> 
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Date: Wed, 23 Apr 2008 16:59:54 +0000
From: "Dwight, Timothy M (Tim)" <[email-masked]>
To: Daryl Malas <[email-masked]>, Hadriel Kaplan <[email-masked]>, Richard Shockey <[email-masked]>,  Otmar Lendl <[email-masked]>, [email-masked]
Content-class: urn:content-classes:message
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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

> -----Original Message-----
> From: Daryl Malas [mailto:[email-masked]] 
> Sent: Wednesday, April 23, 2008 11:48 AM
> To: Dwight, Timothy M (Tim); Hadriel Kaplan; Richard Shockey; 
> Otmar Lendl; [email-masked]
> Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
> 
> 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.
> 
> Do we have to determine the data model now?  This seems premature when
> we've not yet considered use cases. 
> 
> Tim
> 
> 
> > -----Original Message-----
> > 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]
> > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Daryl Malas [mailto:[email-masked]]
> > >
> > > 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:
> > 
> > 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
> > >                 - Destination SIP/SIPS/TEL URI Egress and
> > Ingress Routes
> > >                 - Relevant route names, identifiers, and services
> > >                 - 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 :)
> > 
> > 
> > >         + Service Areas
> > >                 - Individual, ranges, or groups of ENUMservice 
> > > identifiers
> > >                 - Route associations
> > 
> > I don't know what a "Route association" is?
> > 
> > 
> > >         + Treatment Profiles
> > >                 - Priority
> > >                 - 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
> > _______________________________________________
> > PEPPERMINT mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/peppermint
> > 
> 
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Wed, 23 Apr 2008 10:48:29 -0600
From: "Daryl Malas" <[email-masked]>
To: "Dwight, Timothy M (Tim)" <[email-masked]>, "Hadriel Kaplan" <[email-masked]>, "Richard Shockey" <[email-masked]>, "Otmar Lendl" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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.

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

Tim

> -----Original Message-----
> 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]
> Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
> 
> 
> 
> > -----Original Message-----
> > From: Daryl Malas [mailto:[email-masked]]
> >
> > 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:
> 
> 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
> >                 - Destination SIP/SIPS/TEL URI Egress and
> Ingress Routes
> >                 - Relevant route names, identifiers, and services
> >                 - 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 :)
> 
> 
> >         + Service Areas
> >                 - Individual, ranges, or groups of ENUMservice 
> > identifiers
> >                 - Route associations
> 
> I don't know what a "Route association" is?
> 
> 
> >         + Treatment Profiles
> >                 - Priority
> >                 - 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
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/peppermint
> 
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Wed, 23 Apr 2008 10:45:06 -0600
From: "Daryl Malas" <[email-masked]>
To: "Hadriel Kaplan" <[email-masked]>, "Richard Shockey" <[email-masked]>, "Otmar Lendl" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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.

> -----Original Message-----
> From: Daryl Malas [mailto:[email-masked]]
>
> 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:

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.

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

>         + Service Areas
>                 - Individual, ranges, or groups of ENUMservice 
> identifiers
>                 - Route associations

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

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

Date: Wed, 23 Apr 2008 16:42:36 +0000
From: "Dwight, Timothy M (Tim)" <[email-masked]>
To: Hadriel Kaplan <[email-masked]>, Daryl Malas <[email-masked]>, Richard Shockey <[email-masked]>,  Otmar Lendl <[email-masked]>, [email-masked]
Content-class: urn:content-classes:message
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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

Tim

> -----Original Message-----
> 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]
> Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
> 
> 
> 
> > -----Original Message-----
> > From: Daryl Malas [mailto:[email-masked]]
> >
> > 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:
> 
> 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
> >                 - Destination SIP/SIPS/TEL URI Egress and 
> Ingress Routes
> >                 - Relevant route names, identifiers, and services
> >                 - 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 :)
> 
> 
> >         + Service Areas
> >                 - Individual, ranges, or groups of ENUMservice
> > identifiers
> >                 - Route associations
> 
> I don't know what a "Route association" is?
> 
> 
> >         + Treatment Profiles
> >                 - Priority
> >                 - 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
> _______________________________________________
> 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: Hadriel Kaplan <[email-masked]>
To: Daryl Malas <[email-masked]>, Richard Shockey <[email-masked]>,  Otmar Lendl <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 23 Apr 2008 12:34:00 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

> -----Original Message-----
> From: Daryl Malas [mailto:[email-masked]]
>
> 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:

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

>         + Service Areas
>                 - Individual, ranges, or groups of ENUMservice
> identifiers
>                 - Route associations

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

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

From: Hadriel Kaplan <[email-masked]>
To: Otmar Lendl <[email-masked]>, Richard Shockey <[email-masked]>
Date: Wed, 23 Apr 2008 12:22:00 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: 'Daryl Malas' <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

> -----Original Message-----
> From: Otmar Lendl [mailto:[email-masked]] On Behalf Of Otmar Lendl
> Sent: Wednesday, April 23, 2008 11:41 AM
>
> On 2008/04/23 16:04, Richard Shockey <[email-masked]> wrote:
> > >
> > >     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:
> >
> > Number ranges?
>
> 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.)

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

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

          o  Fully Qualified Domain Name (FQDN)

          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

     . Optional resource control parameters such as

          o  Resource priority value(s) for the call

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

Content-class: urn:content-classes:message
Date: Wed, 23 Apr 2008 10:21:56 -0600
From: "Daryl Malas" <[email-masked]>
To: "Hadriel Kaplan" <[email-masked]>, "Richard Shockey" <[email-masked]>, "Otmar Lendl" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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.

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  Fully Qualified Domain Name (FQDN)

          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

     . Optional resource control parameters such as

          o  Resource priority value(s) for the call

          o  Geographic or topological identifiers

-hadriel

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]]
>
> 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
>
>
>
> >
> >  --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."
> >
> >  Anyone want to suggest some text?
> >
> >  >  -----Original Message-----
> >  >  From: [email-masked]  > 
> > [mailto:[email-masked]]
> >  >  On Behalf Of Hadriel Kaplan
> >  >  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.
> >  > (right?)
> >  >
> >  >  -hadriel
> >  >
> >  >
> >  >  > -----Original Message-----
> >  >  > 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.
> >  >  >
> >  >  > On 2008/04/21 20:04, Richard Shockey <[email-masked]>
wrote:
> >  >  > > >
> >  >  > > >  > > 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.
> >  >  > > >
> >  >  > > >  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.
> >  >  >
> >  >  > 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")  >
> >
> >  > > > 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.
> >  >  >
> >  >  > 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.
> >  >  >
> >  >  > > 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
> >
> >  > 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*?
> >  >  >
> >  >  > > >  > > That is sorely missing in speermint.
> >  >  > > >  >
> >  >  > > >  > 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.
> >  >  >
> >  >  > > 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
> >  >  > --
> >  >  > // 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
> >
> >  _______________________________________________
> >  PEPPERMINT mailing list
> >  [email-masked]
> >  https://www.ietf.org/mailman/listinfo/peppermint

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

Date: Wed, 23 Apr 2008 17:40:56 +0200
From: Otmar Lendl <[email-masked]>
To: Richard Shockey <[email-masked]>
Mail-Followup-To: Otmar Lendl <[email-masked]>, Richard Shockey <[email-masked]>, 'Hadriel Kaplan' <[email-masked]>, 'Daryl Malas' <[email-masked]>, [email-masked]
Cc: 'Daryl Malas' <[email-masked]>, 'Hadriel Kaplan' <[email-masked]>, [email-masked]
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

On 2008/04/23 16:04, Richard Shockey <[email-masked]> wrote:
> >  
> >     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:
> 
> Number ranges?

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
-- 
// 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: "Richard Shockey" <[email-masked]>
To: "'Hadriel Kaplan'" <[email-masked]>, "'Daryl Malas'" <[email-masked]>, "'Otmar Lendl'" <[email-masked]>, <[email-masked]>
Date: Wed, 23 Apr 2008 10:56:56 -0400
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

>  
>  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.
>  
>  What about something more like:

This is a excellent list BTW.

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

Number ranges?

>  
>       . 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  Fully Qualified Domain Name (FQDN)
>  
>            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
>  
>       . Optional resource control parameters such as
>  
>            o  Resource priority value(s) for the call
>  
>            o  Geographic or topological identifiers
>  
>  
>  -hadriel
>  
>  
>  > -----Original Message-----
>  > From: Richard Shockey [mailto:[email-masked]]
>  >
>  > 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
>  >
>  >
>  >
>  > >
>  > >  --Daryl
>  > >
>  > >  -----Original Message-----
>  > >  From: [email-masked] [mailto:peppermint-
>  [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."
>  > >
>  > >  Anyone want to suggest some text?
>  > >
>  > >  >  -----Original Message-----
>  > >  >  From: [email-masked]
>  > >  > [mailto:[email-masked]]
>  > >  >  On Behalf Of Hadriel Kaplan
>  > >  >  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.
>  > >  > (right?)
>  > >  >
>  > >  >  -hadriel
>  > >  >
>  > >  >
>  > >  >  > -----Original Message-----
>  > >  >  > 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.
>  > >  >  >
>  > >  >  > On 2008/04/21 20:04, Richard Shockey <[email-masked]>
>  wrote:
>  > >  >  > > >
>  > >  >  > > >  > > 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.
>  > >  >  > > >
>  > >  >  > > >  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.
>  > >  >  >
>  > >  >  > 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")
>  > >  >
>  > >
>  > >  > > > 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.
>  > >  >  >
>  > >  >  > 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.
>  > >  >  >
>  > >  >  > > 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
>  > >
>  > >  > 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*?
>  > >  >  >
>  > >  >  > > >  > > That is sorely missing in speermint.
>  > >  >  > > >  >
>  > >  >  > > >  > 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.
>  > >  >  >
>  > >  >  > > 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
>  > >  >  > --
>  > >  >  > // 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
>  > >
>  > >  _______________________________________________
>  > >  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: Hadriel Kaplan <[email-masked]>
To: Richard Shockey <[email-masked]>, 'Daryl Malas' <[email-masked]>, 'Otmar Lendl' <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 23 Apr 2008 01:20:25 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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  Fully Qualified Domain Name (FQDN)

          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

     . Optional resource control parameters such as

          o  Resource priority value(s) for the call

          o  Geographic or topological identifiers

-hadriel

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]]
>
> 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
>
>
>
> >
> >  --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."
> >
> >  Anyone want to suggest some text?
> >
> >  >  -----Original Message-----
> >  >  From: [email-masked]
> >  > [mailto:[email-masked]]
> >  >  On Behalf Of Hadriel Kaplan
> >  >  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.
> >  > (right?)
> >  >
> >  >  -hadriel
> >  >
> >  >
> >  >  > -----Original Message-----
> >  >  > 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.
> >  >  >
> >  >  > On 2008/04/21 20:04, Richard Shockey <[email-masked]> wrote:
> >  >  > > >
> >  >  > > >  > > 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.
> >  >  > > >
> >  >  > > >  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.
> >  >  >
> >  >  > 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")
> >  >
> >
> >  > > > 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.
> >  >  >
> >  >  > 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.
> >  >  >
> >  >  > > 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
> >
> >  > 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*?
> >  >  >
> >  >  > > >  > > That is sorely missing in speermint.
> >  >  > > >  >
> >  >  > > >  > 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.
> >  >  >
> >  >  > > 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
> >  >  > --
> >  >  > // 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
> >
> >  _______________________________________________
> >  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: "Richard Shockey" <[email-masked]>
To: "'Daryl Malas'" <[email-masked]>, "'Hadriel Kaplan'" <[email-masked]>, "'Otmar Lendl'" <[email-masked]>, <[email-masked]>
Date: Tue, 22 Apr 2008 13:05:57 -0400
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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

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

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

>  
>  --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."
>  
>  Anyone want to suggest some text?
>  
>  >  -----Original Message-----
>  >  From: [email-masked]
>  > [mailto:[email-masked]]
>  >  On Behalf Of Hadriel Kaplan
>  >  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.
>  > (right?)
>  >
>  >  -hadriel
>  >
>  >
>  >  > -----Original Message-----
>  >  > 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.
>  >  >
>  >  > On 2008/04/21 20:04, Richard Shockey <[email-masked]> wrote:
>  >  > > >
>  >  > > >  > > 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.
>  >  > > >
>  >  > > >  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.
>  >  >
>  >  > 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")
>  >
>  
>  > > > 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.
>  >  >
>  >  > 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.
>  >  >
>  >  > > 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
>  
>  > 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*?
>  >  >
>  >  > > >  > > That is sorely missing in speermint.
>  >  > > >  >
>  >  > > >  > 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.
>  >  >
>  >  > > 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
>  >  > --
>  >  > // 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
>  
>  _______________________________________________
>  PEPPERMINT mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/peppermint

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

Content-class: urn:content-classes:message
Date: Tue, 22 Apr 2008 11:03:18 -0600
From: "Daryl Malas" <[email-masked]>
To: "Otmar Lendl" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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

On 2008/04/21 20:04, Richard Shockey <[email-masked]> wrote:
> >  
> >  > > 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.
> >
> >  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.

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

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

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.

> 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 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*?

> >  > > That is sorely missing in speermint.
> >  >
> >  > 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.

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

Content-class: urn:content-classes:message
Date: Tue, 22 Apr 2008 10:45:57 -0600
From: "Daryl Malas" <[email-masked]>
To: "Otmar Lendl" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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.

On 2008/04/21 20:04, Richard Shockey <[email-masked]> wrote:
> >  
> >  > > 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.
> >
> >  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.

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

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

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.

> 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 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*?

> >  > > That is sorely missing in speermint.
> >  >
> >  > 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.

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

Content-class: urn:content-classes:message
Date: Tue, 22 Apr 2008 10:36:08 -0600
From: "Daryl Malas" <[email-masked]>
To: "Richard Shockey" <[email-masked]>, "Hadriel Kaplan" <[email-masked]>, "Otmar Lendl" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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

Anyone want to suggest some text?

>  -----Original Message-----
>  From: [email-masked] 
> [mailto:[email-masked]]
>  On Behalf Of Hadriel Kaplan
>  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. 
> (right?)
>  
>  -hadriel
>  
>  
>  > -----Original Message-----
>  > 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.
>  >
>  > On 2008/04/21 20:04, Richard Shockey <[email-masked]> wrote:
>  > > >
>  > > >  > > 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.
>  > > >
>  > > >  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.
>  >
>  > 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")  >

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

> 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*?
>  >
>  > > >  > > That is sorely missing in speermint.
>  > > >  >
>  > > >  > 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.
>  >
>  > > 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
>  > --
>  > // 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

_______________________________________________
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: "Richard Shockey" <[email-masked]>
To: "'Hadriel Kaplan'" <[email-masked]>, "'Otmar Lendl'" <[email-masked]>, <[email-masked]>
Date: Tue, 22 Apr 2008 12:25:18 -0400
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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?

>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]]
>  On Behalf Of Hadriel Kaplan
>  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. (right?)
>  
>  -hadriel
>  
>  
>  > -----Original Message-----
>  > 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.
>  >
>  > On 2008/04/21 20:04, Richard Shockey <[email-masked]> wrote:
>  > > >
>  > > >  > > 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.
>  > > >
>  > > >  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.
>  >
>  > 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")
>  >
>  > > 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.
>  >
>  > 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.
>  >
>  > > 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
>  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*?
>  >
>  > > >  > > That is sorely missing in speermint.
>  > > >  >
>  > > >  > 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.
>  >
>  > > 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
>  > --
>  > // 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

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

From: Hadriel Kaplan <[email-masked]>
To: Otmar Lendl <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 22 Apr 2008 11:18:36 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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

> -----Original Message-----
> From: [email-masked] [mailto:[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.
>
> On 2008/04/21 20:04, Richard Shockey <[email-masked]> wrote:
> > >
> > >  > > 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.
> > >
> > >  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.
>
> 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")
>
> > 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.
>
> 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.
>
> > 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 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*?
>
> > >  > > That is sorely missing in speermint.
> > >  >
> > >  > 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.
>
> > 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
> --
> // 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

Date: Tue, 22 Apr 2008 16:44:52 +0200
From: Otmar Lendl <[email-masked]>
To: [email-masked]
Mail-Followup-To: Otmar Lendl <[email-masked]>, [email-masked]
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

On 2008/04/21 20:04, Richard Shockey <[email-masked]> wrote:
> >  
> >  > > 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.
> >
> >  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.

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

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

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.

> 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 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*?

> >  > > That is sorely missing in speermint.
> >  >
> >  > 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.

> 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
-- 
// 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: David Schwartz <[email-masked]>
To: Richard Shockey <[email-masked]>
Date: Mon, 21 Apr 2008 21:49:03 +0300
Cc: "[email-masked]" <[email-masked]>, Hadriel Kaplan <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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.

On Apr 21, 2008, at 9:26 PM, "Richard Shockey" <[email-masked]>  
wrote:

>
>>
>> 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
>>>>> 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?
>
>
>>>
>>> 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'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.
>
>
>>
>>>> Whoa, hold your horses.
>>>> "the Registry?"
>>>
>>> That should be "a 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.
>
> 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
>>> 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".
>
> 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.
>
>>
>>>>> 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.
>>>
>>> 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.
>
>
> 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.
>
>
>>
>> /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
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

From: "Richard Shockey" <[email-masked]>
To: "'Otmar Lendl'" <[email-masked]>, "'Hadriel Kaplan'" <[email-masked]>
Date: Mon, 21 Apr 2008 14:26:58 -0400
Cc: [email-masked]
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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

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

>  
>  > > Whoa, hold your horses.
>  > > "the Registry?"
>  >
>  > That should be "a 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.

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

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. 

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

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.

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

Content-class: urn:content-classes:message
Date: Mon, 21 Apr 2008 09:54:26 -0400
From: "James McEachern" <[email-masked]>
To: <[email-masked]>
Subject: Re: [PEPPERMINT] New name for the WG... consensus desired
Sender: [email-masked]

  > -----Original Message-----
  > From: [email-masked]
[mailto:[email-masked]]
  > On Behalf Of Otmar Lendl
  > Sent: Sunday, April 20, 2008 5:13 PM
  > To: [email-masked]
  > Subject: Re: [PEPPERMINT] New name for the WG... consensus desired

  > "drinks" is fine except that it is quite unsuitable for targetted
  > googling.
  > 
  > I'd prefer some word which is not as common.

Interestingly, if you Google "drinks IETF" the top item already points
to this charter discussion.  

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

Date: Sun, 20 Apr 2008 23:13:12 +0200
From: Otmar Lendl <[email-masked]>
To: [email-masked]
Mail-Followup-To: Otmar Lendl <[email-masked]>, [email-masked]
Subject: Re: [PEPPERMINT] New name for the WG... consensus desired
Sender: [email-masked]

On 2008/04/10 03:04, Richard Shockey <[email-masked]> wrote:
> In some serious off line discussions, there was a suggestion that PEPPERMINT
> might not be the most appropriate WG name since the concept of provisioning
> has very specific context in teleco world.
> 
> What we are dealing with is data exchanges.
> 
> Hense the suggestion of a new WG name 
> 
> DRINKS 
> 
> Data for Reachability of Inter/tra-NetworK SIP
> 
> Personally I think this is a perfect IETF WG name and meets all the
> criterion of cuteness, banality, etc. and extremely appropriate given the
> venue of a probably first meeting ..Dublin .

"drinks" is fine except that it is quite unsuitable for targetted googling.

I'd prefer some word which is not as common.

/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

Date: Sun, 20 Apr 2008 23:11:01 +0200
From: Otmar Lendl <[email-masked]>
To: Hadriel Kaplan <[email-masked]>
Mail-Followup-To: Otmar Lendl <[email-masked]>, Hadriel Kaplan <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

On 2008/04/20 06:04, Hadriel Kaplan <[email-masked]> wrote:
> > Is an "administrative domain" usually the same as a SSP?
> 
> 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.  

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

> > Whoa, hold your horses.
> > "the Registry?"
> 
> That should be "a 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.
>
> 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".

> > > 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.
> 
> 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
-- 
// 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]>
To: Otmar Lendl <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sun, 20 Apr 2008 00:42:05 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Otmar Lendl
> >
> > PROPOSED CHARTER FOR PEPPERMINT
> >
> > The IETF has been working on various aspects of SIP-enabled Multimedia
> > administrative domains among SIP Service Providers (SSPs. SSP's are
> entities
> > that provide session services utilizing SIP signaling to their
> customers. In
> > addition, the IETF has done significant work on data exchanges among
> various
> > network elements.
>
> As these term are central to this charter, can you clarify:
> Are "administrative domains" meant as equivalents to "autonomous
> systems" in the BGP context?
> Is an "administrative domain" usually the same as a SSP?

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.

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

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.

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

That should be "a 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.

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.

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

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

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

Date: Sat, 19 Apr 2008 23:06:54 +0200
From: Otmar Lendl <[email-masked]>
To: [email-masked]
Mail-Followup-To: Otmar Lendl <[email-masked]>, [email-masked]
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

Some more feedback:

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

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

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

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

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

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

lowercase "OF".

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

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

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

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

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

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

Whoa, hold your horses.

"the Registry?"

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

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

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

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

What about writing a 

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

first? 

That is sorely missing in speermint.

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

See comment re: registries above.

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

/ol
-- 
// Otmar Lendl <[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]>
To: Richard Shockey <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 17 Apr 2008 10:21:29 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Shockey
>
> Is this better.
>
> Requirements for Session Establishment Data (SED) data exchanges.
> Sept 08

Yup, that's a good one.

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

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

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

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

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

From: "Richard Shockey" <[email-masked]>
To: "'Dan York'" <[email-masked]>
Date: Wed, 16 Apr 2008 21:15:01 -0400
Cc: [email-masked]
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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

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

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

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.

>  
>  Outside of the nits Hadriel already pointed out, I'll only add a few
>  points embedded with "DY>":
>  >
>  > 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
>  
>  DY> "OF" should be lowercase.

TKS ..will do ..

>  
>  > 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.
>  
>  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
>  using in billing?

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.

>  
>  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?)

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.

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

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

From: Dan York <[email-masked]>
To: Richard Shockey <[email-masked]>
Date: Wed, 16 Apr 2008 19:29:55 -0400
Cc: [email-masked]
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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  
points embedded with "DY>":
>
> 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

DY> "OF" should be lowercase.

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

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

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

From: "Richard Shockey" <[email-masked]>
To: "'Hadriel Kaplan'" <[email-masked]>, <[email-masked]>
Date: Wed, 16 Apr 2008 15:36:14 -0400
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

TKS ... in line ...

>  >
>  > PROPOSED GOALS AND MILESTONES
>  >
>  >
>  > Requirements for Session Establishment Data (SED) data exchanges.
>  > Sept 08
>  >
>  > Provisioning of Session Establishment Data (SED) registries.
>  > Nov 08
>  
>  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."

Is this better.

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

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 

>  
>  -hadriel

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

From: Hadriel Kaplan <[email-masked]>
To: Richard Shockey <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 16 Apr 2008 14:06:47 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> ************************
> DRINKS Proposed Charter
> Data for Reachability of Inter/tra-NetworK SIP
> Current Status: Proposed Working Group
>
> Mailing Lists:
> [email-masked]

We'll need a new mailing list name (or alias) for [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

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

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

Remove last period, or last colon.

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

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

> 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

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Wed, 16 Apr 2008 13:19:50 -0400
Subject: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Date: Mon, 14 Apr 2008 09:46:53 -0600
From: "Jean-Francois Mule" <[email-masked]>
To: "Otmar Lendl" <[email-masked]>
Cc: [email-masked]
Subject: Re: [PEPPERMINT] Some comments on ESPP
Sender: [email-masked]

Otmar, Bob, Paul, and all of your who sent comments/issues re: ESPP
Internet-Drafts:

   Thank you for the detailed comments.  This is exactly the type of
review comments we were hoping to get.

   Along with the other co-authors, we're taking notes of these comments
and we plan to review them and send an aggregated response.  Some
comments may lead to bug fixes in the I-Ds, new email threads, etc.  In
the meantime, just wanted to ack the receipt of these and say thanks for
taking the time to read this.

More later.
Jean-Francois.

> -----Original Message-----
> From: [email-masked] [mailto:peppermint-
> [email-masked]] On Behalf Of Otmar Lendl
> Sent: Monday, April 14, 2008 8:46 AM
> To: [email-masked]
> Subject: [PEPPERMINT] Some comments on ESPP
> 
> 
> I've meant to send a detailed review of ESPP for a while now, some
> fragements of which have be languishing in my draft-mail folder.
> 
> To get things moving, here are my (incomplete) notes on ESPP:
> 
> ---------------------
> 
> I've now read the ESPP drafts; these are valuable contributions
> both
> to the peppermint bof, als well as to the speermint WG.
> 
> There are some good ideas in ESPP, as well as (IMHO) problems.
> 
> First of all, let's take a look at the data model which underpin
> ESPP:
> 
> -----
> 
>                                                       +------------
> ----+
>                            A Route is associated with |NAPTR:
> |
>         +----------------+ zero or more SBE NAPTRs.
> |id,enterpriseId,|
>         |                |--------------------------->|order,pref,
> |
>         |Route:          | NAPTRs associated with
> |flags,svcs,regx,|
>         |id,enterpriseId,| Routes are not User or TN
> |repl,extension  |
>         |routeName,      | specific. The user portion +------------
> ----+
>         |isLnService,    | of the regex will be "\\1".
>         |sbeNAPTRs,      |                            +------------
> ----+
>         |extension       |                            |Egress
> Route:   |
>         |                |<---------------------------
> |id,enterpriseId,|
>         +----------------+ An EgressRoute is
> |routeIds,pref,  |
>                         ^  associated with zero or    |svcs,
> |
>          A Service Area |  more Routes.
> |regxRewriteRule,|
>          is associated  |                             |extension
> |
>          with 1 or more |                             +------------
> ----+
>          Routes         |
>                     +----------------+
>                     |Service Area:   |
>                     |id,enterpriseId,|
>                +--->|ServiceAreaName,|<---+
>                |    |routeIds,       |    |
>                |    |extension       |    |
>                |    +----------------+    |
>                |An LRN is   |A TNRange is |A Public
>                |associated  |associated   |Identify is
>                |with only 1 |with only 1  |associated
>                |Service     |Service      |with zero or
>                |Area.       |Area.        |1 Service Area.
>                |            |             |
>    +--------------++--------------++--------------+   +------------
> --+
>    |LRN:          ||TNRange:      ||Public        |   |NAPTR:
> |
>    |id,           ||id,           ||Identity:     |   |id,
> |
>    |enterpriseId, ||enterpriseId, ||id,           |
> |enterpriseId, |
>    |lrn,          ||tnRangeStart, ||enterpriseId, |-->|order,pref,
> |
>    |serviceAreaId,||tnRangeEnd,   ||lrn,          |   |flags,svcs,
> |
>    |extension     ||serviceAreaId,||serviceAreaId,|   |regx,repl,
> |
>    |              ||extension     ||extension     |   |extension
> |
>    +--------------++--------------++--------------+   +------------
> --+
>                                               |
>                            A Public Identity  | Multiple Public
>                            is associated with | Identities can
>                            zero or 1 Private  | be associated
>                            Identity           | with 1 Private
>                                               | Identity
>                                               |
>                                               |
>                                               |
>                                               |
>                                               |
>                                               V
>                                       +----------------+
>                                       |Private         |
>                                       |Identity:       |
>                                       |id,             |
>                                       |enterpriseId,   |
>                                       |privateIdentity,|
>                                       |extension       |
>                                       +----------------+
> -----
> 
> As I view this design, it has two parts:
> 
> (1) Mapping endpoint addresses to ServiceAreas
> (2) Routing information for ServiceAreas
> 
> This separation is a good idea. You should never attach routing
> information directly to phone numbers. You first apply some mapping
> step
> to an aggregation object, to which the routing information is
> attached.
> 
> As the draft notes, the potential update-patterns are different in
> these two areas.
> 
> The information in (1) is potentially *huge*; changes are caused by
> the normal churn of customers between providers. This will be a
> steady
> stream of updates (without hard realtime requirements), punctured
> by
> occasional bulk updates (network grooming, mergers, ...) plus large
> initial data loads.
> 
> This is basically a classic example of a directory: the information
> is
> independent on who is asking, data-set is huge, update frequency
> harmless.
> 
> Comparing (1) to
> draft-schwartz-peppermint-consolidated-provisioning-problem-
> statement-00
> I find a very good match: This is exactly what David & co describe
> in
> their draft.
> 
> The upper part in the diagram, i.e. (2), is different. This is
> routing data,
> pure and simple.
> 
> Here is the point, where I can't follow the authors of ESPP: You
> don't
> "provision" inter-provider routing table entries. That's telco-
> thinking.
> That is maybe IP routing of the 80's. Having a human enter a such a
> route into the ESPP system sounds to me like adding a static route
> to an
> IP router.
> 
> Yes, you do that on the customer facing interface, but you cetainly
> don't do that on a peering router. On a peering router, you
> configure
> the basic parameters of a routing protocol: where are the peers,
> which
> routes to announce, and which conditions learned routes must
> fulfill.
> Manual traffic engineering is done by tweaking the routing
> protocol,
> weighing routes differently based on various criteria, but *never*
> by
> hardcoding routes into the system.
> 
> I may be oversensitive to the difference between "provisioning" and
> "routing", but this is crucial towards the direction of speermint
> and
> peppermint.
> 
> ----
> 
> Other comments:
> 
> * ServiceArea
> 
> As I wrote above, the concept is sound. We need such an aggregation
> scheme. I'm a bit worried, though, that the "ServiceArea" term is
> quite
> specific to the US cable landscape with operators serving
> geographically
> disjunct regions.
> 
> What about a scenario where multiple operators serve the same area,
> with number porting between them. ServiceArea "Brooklyn" thus isn't
> specific to a single carrier. I'm not quite sure how that fits into
> this scheme.
> 
> * NAPTR
> 
> A provisioning protocol should not be overly tied to the specifics
> of
> the query protocol. I'd feel more comfortable with a provision
> system
> which deals with generic routing information. Whether that
> information
> is then passed to the switches by means of an ENUM response, or via
> dumping some sort of proprietary database into the switches should
> be of
> no concern to the provisioning.
> 
> NAPTRs are a quirk of the ENUM protocol. They are not the most
> natural
> data format for routing information.
> 
> * Transit
> 
> I won't make myself popular by bringing this up, but we need to
> keep the
> requirements of provisioning transit in the back of our head.
> 
> Like it or not, but we will have to be prepared for it.
> 
> What would that mean for ESPP?
> 
> I see two basic approaches to implement transit with ESPP:
> 
> a) The transit operator announces mappings and routes towards the
> destination network as they were part of his own network. Perhaps
> with a
> special ServiceArea designation, but otherwise no changes.
> 
> b) The transit operator re-injects number->ServiceArea mappings
> unchanged into the other ESPP domain, and only creates new Route
> objects
> announcing the path via this transit operator.
> 
> In both cases, it will happen that potential source networks see
> competing announcements towards a destination. As I have read ESPP,
> this
> has not been considered.
> 
> /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

Date: Mon, 14 Apr 2008 16:45:39 +0200
From: Otmar Lendl <[email-masked]>
To: [email-masked]
Mail-Followup-To: Otmar Lendl <[email-masked]>, [email-masked]
Subject: [PEPPERMINT] Some comments on ESPP
Sender: [email-masked]

I've meant to send a detailed review of ESPP for a while now, some
fragements of which have be languishing in my draft-mail folder.

To get things moving, here are my (incomplete) notes on ESPP:

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

I've now read the ESPP drafts; these are valuable contributions both
to the peppermint bof, als well as to the speermint WG.

There are some good ideas in ESPP, as well as (IMHO) problems.

First of all, let's take a look at the data model which underpin ESPP:

-----

                                                      +----------------+
                           A Route is associated with |NAPTR:          |
        +----------------+ zero or more SBE NAPTRs.   |id,enterpriseId,|
        |                |--------------------------->|order,pref,     |
        |Route:          | NAPTRs associated with     |flags,svcs,regx,|
        |id,enterpriseId,| Routes are not User or TN  |repl,extension  |
        |routeName,      | specific. The user portion +----------------+
        |isLnService,    | of the regex will be "\\1".
        |sbeNAPTRs,      |                            +----------------+
        |extension       |                            |Egress Route:   |
        |                |<---------------------------|id,enterpriseId,|
        +----------------+ An EgressRoute is          |routeIds,pref,  |
                        ^  associated with zero or    |svcs,           |
         A Service Area |  more Routes.               |regxRewriteRule,|
         is associated  |                             |extension       |
         with 1 or more |                             +----------------+
         Routes         |
                    +----------------+
                    |Service Area:   |
                    |id,enterpriseId,|
               +--->|ServiceAreaName,|<---+
               |    |routeIds,       |    |
               |    |extension       |    |
               |    +----------------+    |
               |An LRN is   |A TNRange is |A Public
               |associated  |associated   |Identify is
               |with only 1 |with only 1  |associated
               |Service     |Service      |with zero or
               |Area.       |Area.        |1 Service Area.
               |            |             |
   +--------------++--------------++--------------+   +--------------+
   |LRN:          ||TNRange:      ||Public        |   |NAPTR:        |
   |id,           ||id,           ||Identity:     |   |id,           |
   |enterpriseId, ||enterpriseId, ||id,           |   |enterpriseId, |
   |lrn,          ||tnRangeStart, ||enterpriseId, |-->|order,pref,   |
   |serviceAreaId,||tnRangeEnd,   ||lrn,          |   |flags,svcs,   |
   |extension     ||serviceAreaId,||serviceAreaId,|   |regx,repl,    |
   |              ||extension     ||extension     |   |extension     |
   +--------------++--------------++--------------+   +--------------+
                                              |
                           A Public Identity  | Multiple Public
                           is associated with | Identities can
                           zero or 1 Private  | be associated
                           Identity           | with 1 Private
                                              | Identity
                                              |
                                              |
                                              |
                                              |
                                              |
                                              V
                                      +----------------+
                                      |Private         |
                                      |Identity:       |
                                      |id,             |
                                      |enterpriseId,   |
                                      |privateIdentity,|
                                      |extension       |
                                      +----------------+
-----

As I view this design, it has two parts:

(1) Mapping endpoint addresses to ServiceAreas
(2) Routing information for ServiceAreas

This separation is a good idea. You should never attach routing
information directly to phone numbers. You first apply some mapping step
to an aggregation object, to which the routing information is attached.

As the draft notes, the potential update-patterns are different in 
these two areas. 

The information in (1) is potentially *huge*; changes are caused by
the normal churn of customers between providers. This will be a steady
stream of updates (without hard realtime requirements), punctured by
occasional bulk updates (network grooming, mergers, ...) plus large
initial data loads.

This is basically a classic example of a directory: the information is
independent on who is asking, data-set is huge, update frequency harmless. 

Comparing (1) to
draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00
I find a very good match: This is exactly what David & co describe in
their draft.

The upper part in the diagram, i.e. (2), is different. This is routing data,
pure and simple.

Here is the point, where I can't follow the authors of ESPP: You don't
"provision" inter-provider routing table entries. That's telco-thinking.
That is maybe IP routing of the 80's. Having a human enter a such a
route into the ESPP system sounds to me like adding a static route to an
IP router.

Yes, you do that on the customer facing interface, but you cetainly
don't do that on a peering router. On a peering router, you configure
the basic parameters of a routing protocol: where are the peers, which
routes to announce, and which conditions learned routes must fulfill.
Manual traffic engineering is done by tweaking the routing protocol,
weighing routes differently based on various criteria, but *never* by
hardcoding routes into the system.

I may be oversensitive to the difference between "provisioning" and
"routing", but this is crucial towards the direction of speermint and
peppermint.

----

Other comments:

* ServiceArea

As I wrote above, the concept is sound. We need such an aggregation
scheme. I'm a bit worried, though, that the "ServiceArea" term is quite
specific to the US cable landscape with operators serving geographically
disjunct regions.

What about a scenario where multiple operators serve the same area,
with number porting between them. ServiceArea "Brooklyn" thus isn't
specific to a single carrier. I'm not quite sure how that fits into
this scheme.

* NAPTR

A provisioning protocol should not be overly tied to the specifics of
the query protocol. I'd feel more comfortable with a provision system
which deals with generic routing information. Whether that information
is then passed to the switches by means of an ENUM response, or via
dumping some sort of proprietary database into the switches should be of
no concern to the provisioning.

NAPTRs are a quirk of the ENUM protocol. They are not the most natural
data format for routing information.

* Transit

I won't make myself popular by bringing this up, but we need to keep the
requirements of provisioning transit in the back of our head.

Like it or not, but we will have to be prepared for it.

What would that mean for ESPP?

I see two basic approaches to implement transit with ESPP:

a) The transit operator announces mappings and routes towards the
destination network as they were part of his own network. Perhaps with a
special ServiceArea designation, but otherwise no changes.

b) The transit operator re-injects number->ServiceArea mappings
unchanged into the other ESPP domain, and only creates new Route objects
announcing the path via this transit operator.

In both cases, it will happen that potential source networks see
competing announcements towards a destination. As I have read ESPP, this
has not been considered.

/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

Content-class: urn:content-classes:message
Date: Fri, 11 Apr 2008 16:43:41 -0400
From: "Cartwright, Kenneth" <[email-masked]>
To: <[email-masked]>
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18
Sender: [email-masked]

"I'm not implying provisioning isn't in scope - I'm implying
provisioning isn't constraining the scope"

Ahhh, perfect.  Got it.

Ken.

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, April 11, 2008 4:37 PM
To: Cartwright, Kenneth; [email-masked]
Subject: RE: PEPPERMINT Digest, Vol 10, Issue 18

Right, but I'm not implying provisioning isn't in scope - I'm implying
provisioning isn't constraining the scope.  In other words, provisioning
is a specific subset form of "data exchange", and "data exchange" does
not have to be provisioning.

To make this more concrete, I'll use an example: ESPP.  Not that we are
or are not going to use any form of ESPP, but it was presented as one
possible example to show that the chartered work is technically do-able.
ESPP, as defined, certainly could be used for true "provisioning" as
most people mean that term.  But the minute the information
pushed/pulled by ESPP is not authoritative to the client - i.e., if it
can be modified, post-processed, manipulated, filtered, ignored, etc.,
it ceases to be provisioning in the common sense of the word.  (or at
least causes confusion to people who use "provisioning" in the
authoritative sense, as one would do from an Element Management System,
for example)  And ESPP may well have that lesser-control semantic when
really used.

Thus, I think it's safer if we ignore the loaded term, and just define
the actual requirements we want/need in the WG itself.

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]

> On Behalf Of Cartwright, Kenneth
> Sent: Friday, April 11, 2008 12:16 PM
> To: [email-masked]
> Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18
>
> Thanks for this background.  That helps somewhat.  So once I see the 
> next version of the charter I'll better understand what you mean by 
> the statement "Peppermint is not provisioning, or at least not how 
> they mean that word".  This statement certainly surprises me, which 
> means that there is certainly a disconnect somewhere (and maybe that 
> "somewhere" is
> me) that needs to be addressed.  The presentations and discussions 
> that I've observed at both of the BOFs, and my reading of the charter,

> makes it clear, to me at least, that provisioning (as I use the word) 
> is definitely in the scope of the WG.  If it's not then that is, 
> needless to say, a vital item for the charter to make clear, imho.
>
> Ken
>
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

From: Hadriel Kaplan <[email-masked]>
To: "Cartwright, Kenneth" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 11 Apr 2008 16:36:33 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18
Sender: [email-masked]

Right, but I'm not implying provisioning isn't in scope - I'm implying provisioning isn't constraining the scope.  In other words, provisioning is a specific subset form of "data exchange", and "data exchange" does not have to be provisioning.

To make this more concrete, I'll use an example: ESPP.  Not that we are or are not going to use any form of ESPP, but it was presented as one possible example to show that the chartered work is technically do-able.  ESPP, as defined, certainly could be used for true "provisioning" as most people mean that term.  But the minute the information pushed/pulled by ESPP is not authoritative to the client - i.e., if it can be modified, post-processed, manipulated, filtered, ignored, etc., it ceases to be provisioning in the common sense of the word.  (or at least causes confusion to people who use "provisioning" in the authoritative sense, as one would do from an Element Management System, for example)  And ESPP may well have that lesser-control semantic when really used.

Thus, I think it's safer if we ignore the loaded term, and just define the actual requirements we want/need in the WG itself.

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Cartwright, Kenneth
> Sent: Friday, April 11, 2008 12:16 PM
> To: [email-masked]
> Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18
>
> Thanks for this background.  That helps somewhat.  So once I see the
> next version of the charter I'll better understand what you mean by the
> statement "Peppermint is not provisioning, or at least not how they mean
> that word".  This statement certainly surprises me, which means that
> there is certainly a disconnect somewhere (and maybe that "somewhere" is
> me) that needs to be addressed.  The presentations and discussions that
> I've observed at both of the BOFs, and my reading of the charter, makes
> it clear, to me at least, that provisioning (as I use the word) is
> definitely in the scope of the WG.  If it's not then that is, needless
> to say, a vital item for the charter to make clear, imho.
>
> Ken
>
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Fri, 11 Apr 2008 12:16:01 -0400
From: "Cartwright, Kenneth" <[email-masked]>
To: <[email-masked]>
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18
Sender: [email-masked]

Thanks for this background.  That helps somewhat.  So once I see the
next version of the charter I'll better understand what you mean by the
statement "Peppermint is not provisioning, or at least not how they mean
that word".  This statement certainly surprises me, which means that
there is certainly a disconnect somewhere (and maybe that "somewhere" is
me) that needs to be addressed.  The presentations and discussions that
I've observed at both of the BOFs, and my reading of the charter, makes
it clear, to me at least, that provisioning (as I use the word) is
definitely in the scope of the WG.  If it's not then that is, needless
to say, a vital item for the charter to make clear, imho.

Ken

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Thursday, April 10, 2008 6:05 PM
To: Cartwright, Kenneth; [email-masked]
Subject: RE: PEPPERMINT Digest, Vol 10, Issue 18

Right, so it was entirely off-line, and the reason I started it that way
was because I didn't want to cause any possible disruption to this group
getting its charter approved and WG formed.  So I basically consulted
with the BoF chairs and a few other folks to see if they felt (1) it
wasn't important what the name was, or (2) if it would be better to let
sleeping dogs lie.

Normally I wouldn't care about such things, because like you, I know the
charter is what matters.  I like the current charter just fine.  But in
the last 3 weeks I have had to explain to at least 6 people that
Peppermint is not provisioning, or at least not how they mean that word.
(of the 6 people, 3 attend the IETF and are active in the RAI area)  So
methinks it safer/better if we can avoid that term and its baggage.

We could argue about what the term truly means, and whether the current
charter truly means it, and so on.  But if we just remove the term and
leave the charter as is, we can argue about the specific requirements
and proposals based on the charter in the WG after it's formed, rather
than that particular term's definition now or even then. (because I bet
if you ask two people what it means you'll get three answers :)

As to the DRINK vs. PEPPERMINT - I also came up with alternative
expansions for "Peppermint" that avoided the term provisioning, as well
as a few alternative new names, and DRINKS seemed to wet people's thirst
for a new name.  ;)

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]

> On Behalf Of Cartwright, Kenneth
> Sent: Thursday, April 10, 2008 11:08 AM
> To: [email-masked]
> Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18
>
> First off, it's good to know that the off-line discussions were 
> "serious".  :-)  Secondly, I went back a couple weeks through the 
> PEPPERMINT emails in my inbox but did not find mention of this subject

> of the term "provisioning" being problematic.  SO I guess this subject

> occurred entirely offline.  If not, can you please refer to an 
> approximate date where this was captured in a PEPPERMINT email, 
> perhaps I missed it.  If the discussion was entirely off-line can you 
> please just provide a sentence or two on the reasoning?
>
> I would guess that the reasoning may be something along these lines:
>
> 1) The term provisioning is ill defined.
> 2) The term provisioning may be interpreted by some as too limiting or

> too broad.
> 3) Depending on ones definition of "provisioning", the WG may work on 
> items that have nothing to do with provisioning.
>
> However, while the above points may be accurate, I'm not sure how 
> changing the WG name from "PEPPERMINT" to "DRINKS" helps in a 
> meaningful manner.  It seems that the content of the WG Charter is 
> more important in providing the necessary clarity than the name of the
WG.
>
> In short, my $.02 is that changing the name of the WG from PEPPERMINT 
> to DRINKS is just fine.  But, more importantly, I'd like to see how 
> this name change impacts the content of the Charter.
>
> Ken
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Wednesday, April 09, 2008 9:18 PM
> To: [email-masked]
> Subject: PEPPERMINT Digest, Vol 10, Issue 18
>
> Send PEPPERMINT mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/peppermint
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific 
> than
> "Re: Contents of PEPPERMINT digest..."
>
>
> Today's Topics:
>
>    1.  New name for the WG... consensus desired (Richard Shockey)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 9 Apr 2008 21:18:13 -0400
> From: "Richard Shockey" <[email-masked]>
> Subject: [PEPPERMINT] New name for the WG... consensus desired
> To: <[email-masked]>
> Message-ID: <021601c89aa8$c0a9b5f0$41fd21d0$@us>
> Content-Type: text/plain;       charset="US-ASCII"
>
> In some serious off line discussions, there was a suggestion that 
> PEPPERMINT might not be the most appropriate WG name since the concept

> of provisioning has very specific context in teleco world.
>
> What we are dealing with is data exchanges.
>
> Hense the suggestion of a new WG name
>
> DRINKS
>
> Data for Reachability of Inter/tra-NetworK SIP
>
> Personally I think this is a perfect IETF WG name and meets all the 
> criterion of cuteness, banality, etc. and extremely appropriate given 
> the venue of a probably first meeting ..Dublin .
>
> We'd like to get a consensus if the change of name is appropriate.
>
>
>
> 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
>
>
> End of PEPPERMINT Digest, Vol 10, Issue 18
> ******************************************
> _______________________________________________
> 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: "Richard Shockey" <[email-masked]>
To: "'Hadriel Kaplan'" <[email-masked]>, "'Cartwright, Kenneth'" <[email-masked]>, <[email-masked]>
Date: Thu, 10 Apr 2008 19:45:17 -0400
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18
Sender: [email-masked]

Thanks Hadriel ..for this public explanation. As I pointed out earlier this
distinction of provisioning vs data exchanges seems semantically trivial but
is not. Your experiences in describing the WG clearly indicated a potential
problem.

The whole conversation is important to Daryl who hopefully will have v2 of
the draft charter shortly.

I would very much like to wrap up the charter discussion very shortly so we
can submit something to the RAI AD's in a timely fashion.

In any event we can submit both WG names to the IESG but I have a suspicion
which one the will prefer. :-) 

>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]]
>  On Behalf Of Hadriel Kaplan
>  Sent: Thursday, April 10, 2008 6:05 PM
>  To: Cartwright, Kenneth; [email-masked]
>  Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18
>  
>  
>  Right, so it was entirely off-line, and the reason I started it that
>  way was because I didn't want to cause any possible disruption to this
>  group getting its charter approved and WG formed.  So I basically
>  consulted with the BoF chairs and a few other folks to see if they
>  felt (1) it wasn't important what the name was, or (2) if it would be
>  better to let sleeping dogs lie.
>  
>  Normally I wouldn't care about such things, because like you, I know
>  the charter is what matters.  I like the current charter just fine.
>  But in the last 3 weeks I have had to explain to at least 6 people
>  that Peppermint is not provisioning, or at least not how they mean
>  that word. (of the 6 people, 3 attend the IETF and are active in the
>  RAI area)  So methinks it safer/better if we can avoid that term and
>  its baggage.
>  
>  We could argue about what the term truly means, and whether the
>  current charter truly means it, and so on.  But if we just remove the
>  term and leave the charter as is, we can argue about the specific
>  requirements and proposals based on the charter in the WG after it's
>  formed, rather than that particular term's definition now or even
>  then. (because I bet if you ask two people what it means you'll get
>  three answers :)
>  
>  As to the DRINK vs. PEPPERMINT - I also came up with alternative
>  expansions for "Peppermint" that avoided the term provisioning, as
>  well as a few alternative new names, and DRINKS seemed to wet people's
>  thirst for a new name.  ;)
>  
>  -hadriel
>  
>  
>  > -----Original Message-----
>  > From: [email-masked] [mailto:peppermint-
>  [email-masked]] On
>  > Behalf Of Cartwright, Kenneth
>  > Sent: Thursday, April 10, 2008 11:08 AM
>  > To: [email-masked]
>  > Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18
>  >
>  > First off, it's good to know that the off-line discussions were
>  > "serious".  :-)  Secondly, I went back a couple weeks through the
>  > PEPPERMINT emails in my inbox but did not find mention of this
>  subject
>  > of the term "provisioning" being problematic.  SO I guess this
>  subject
>  > occurred entirely offline.  If not, can you please refer to an
>  > approximate date where this was captured in a PEPPERMINT email,
>  perhaps
>  > I missed it.  If the discussion was entirely off-line can you please
>  > just provide a sentence or two on the reasoning?
>  >
>  > I would guess that the reasoning may be something along these lines:
>  >
>  > 1) The term provisioning is ill defined.
>  > 2) The term provisioning may be interpreted by some as too limiting
>  or
>  > too broad.
>  > 3) Depending on ones definition of "provisioning", the WG may work
>  on
>  > items that have nothing to do with provisioning.
>  >
>  > However, while the above points may be accurate, I'm not sure how
>  > changing the WG name from "PEPPERMINT" to "DRINKS" helps in a
>  meaningful
>  > manner.  It seems that the content of the WG Charter is more
>  important
>  > in providing the necessary clarity than the name of the WG.
>  >
>  > In short, my $.02 is that changing the name of the WG from
>  PEPPERMINT to
>  > DRINKS is just fine.  But, more importantly, I'd like to see how
>  this
>  > name change impacts the content of the Charter.
>  >
>  > Ken
>  >
>  > -----Original Message-----
>  > From: [email-masked] [mailto:peppermint-
>  [email-masked]]
>  > On Behalf Of [email-masked]
>  > Sent: Wednesday, April 09, 2008 9:18 PM
>  > To: [email-masked]
>  > Subject: PEPPERMINT Digest, Vol 10, Issue 18
>  >
>  > Send PEPPERMINT mailing list submissions to
>  >         [email-masked]
>  >
>  > To subscribe or unsubscribe via the World Wide Web, visit
>  >         https://www.ietf.org/mailman/listinfo/peppermint
>  > or, via email, send a message with subject or body 'help' to
>  >         [email-masked]
>  >
>  > You can reach the person managing the list at
>  >         [email-masked]
>  >
>  > When replying, please edit your Subject line so it is more specific
>  than
>  > "Re: Contents of PEPPERMINT digest..."
>  >
>  >
>  > Today's Topics:
>  >
>  >    1.  New name for the WG... consensus desired (Richard Shockey)
>  >
>  >
>  > --------------------------------------------------------------------
>  --
>  >
>  > Message: 1
>  > Date: Wed, 9 Apr 2008 21:18:13 -0400
>  > From: "Richard Shockey" <[email-masked]>
>  > Subject: [PEPPERMINT] New name for the WG... consensus desired
>  > To: <[email-masked]>
>  > Message-ID: <021601c89aa8$c0a9b5f0$41fd21d0$@us>
>  > Content-Type: text/plain;       charset="US-ASCII"
>  >
>  > In some serious off line discussions, there was a suggestion that
>  > PEPPERMINT might not be the most appropriate WG name since the
>  concept
>  > of provisioning has very specific context in teleco world.
>  >
>  > What we are dealing with is data exchanges.
>  >
>  > Hense the suggestion of a new WG name
>  >
>  > DRINKS
>  >
>  > Data for Reachability of Inter/tra-NetworK SIP
>  >
>  > Personally I think this is a perfect IETF WG name and meets all the
>  > criterion of cuteness, banality, etc. and extremely appropriate
>  given
>  > the venue of a probably first meeting ..Dublin .
>  >
>  > We'd like to get a consensus if the change of name is appropriate.
>  >
>  >
>  >
>  > 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
>  >
>  >
>  > End of PEPPERMINT Digest, Vol 10, Issue 18
>  > ******************************************
>  > _______________________________________________
>  > PEPPERMINT mailing list
>  > [email-masked]
>  > https://www.ietf.org/mailman/listinfo/peppermint
>  _______________________________________________
>  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: Hadriel Kaplan <[email-masked]>
To: "Cartwright, Kenneth" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 10 Apr 2008 18:05:10 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18
Sender: [email-masked]

Right, so it was entirely off-line, and the reason I started it that way was because I didn't want to cause any possible disruption to this group getting its charter approved and WG formed.  So I basically consulted with the BoF chairs and a few other folks to see if they felt (1) it wasn't important what the name was, or (2) if it would be better to let sleeping dogs lie.

Normally I wouldn't care about such things, because like you, I know the charter is what matters.  I like the current charter just fine.  But in the last 3 weeks I have had to explain to at least 6 people that Peppermint is not provisioning, or at least not how they mean that word. (of the 6 people, 3 attend the IETF and are active in the RAI area)  So methinks it safer/better if we can avoid that term and its baggage.

We could argue about what the term truly means, and whether the current charter truly means it, and so on.  But if we just remove the term and leave the charter as is, we can argue about the specific requirements and proposals based on the charter in the WG after it's formed, rather than that particular term's definition now or even then. (because I bet if you ask two people what it means you'll get three answers :)

As to the DRINK vs. PEPPERMINT - I also came up with alternative expansions for "Peppermint" that avoided the term provisioning, as well as a few alternative new names, and DRINKS seemed to wet people's thirst for a new name.  ;)

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Cartwright, Kenneth
> Sent: Thursday, April 10, 2008 11:08 AM
> To: [email-masked]
> Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18
>
> First off, it's good to know that the off-line discussions were
> "serious".  :-)  Secondly, I went back a couple weeks through the
> PEPPERMINT emails in my inbox but did not find mention of this subject
> of the term "provisioning" being problematic.  SO I guess this subject
> occurred entirely offline.  If not, can you please refer to an
> approximate date where this was captured in a PEPPERMINT email, perhaps
> I missed it.  If the discussion was entirely off-line can you please
> just provide a sentence or two on the reasoning?
>
> I would guess that the reasoning may be something along these lines:
>
> 1) The term provisioning is ill defined.
> 2) The term provisioning may be interpreted by some as too limiting or
> too broad.
> 3) Depending on ones definition of "provisioning", the WG may work on
> items that have nothing to do with provisioning.
>
> However, while the above points may be accurate, I'm not sure how
> changing the WG name from "PEPPERMINT" to "DRINKS" helps in a meaningful
> manner.  It seems that the content of the WG Charter is more important
> in providing the necessary clarity than the name of the WG.
>
> In short, my $.02 is that changing the name of the WG from PEPPERMINT to
> DRINKS is just fine.  But, more importantly, I'd like to see how this
> name change impacts the content of the Charter.
>
> Ken
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Wednesday, April 09, 2008 9:18 PM
> To: [email-masked]
> Subject: PEPPERMINT Digest, Vol 10, Issue 18
>
> Send PEPPERMINT mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/peppermint
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of PEPPERMINT digest..."
>
>
> Today's Topics:
>
>    1.  New name for the WG... consensus desired (Richard Shockey)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 9 Apr 2008 21:18:13 -0400
> From: "Richard Shockey" <[email-masked]>
> Subject: [PEPPERMINT] New name for the WG... consensus desired
> To: <[email-masked]>
> Message-ID: <021601c89aa8$c0a9b5f0$41fd21d0$@us>
> Content-Type: text/plain;       charset="US-ASCII"
>
> In some serious off line discussions, there was a suggestion that
> PEPPERMINT might not be the most appropriate WG name since the concept
> of provisioning has very specific context in teleco world.
>
> What we are dealing with is data exchanges.
>
> Hense the suggestion of a new WG name
>
> DRINKS
>
> Data for Reachability of Inter/tra-NetworK SIP
>
> Personally I think this is a perfect IETF WG name and meets all the
> criterion of cuteness, banality, etc. and extremely appropriate given
> the venue of a probably first meeting ..Dublin .
>
> We'd like to get a consensus if the change of name is appropriate.
>
>
>
> 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
>
>
> End of PEPPERMINT Digest, Vol 10, Issue 18
> ******************************************
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/peppermint
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Thu, 10 Apr 2008 11:07:34 -0400
From: "Cartwright, Kenneth" <[email-masked]>
To: <[email-masked]>
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 10, Issue 18
Sender: [email-masked]

First off, it's good to know that the off-line discussions were
"serious".  :-)  Secondly, I went back a couple weeks through the
PEPPERMINT emails in my inbox but did not find mention of this subject
of the term "provisioning" being problematic.  SO I guess this subject
occurred entirely offline.  If not, can you please refer to an
approximate date where this was captured in a PEPPERMINT email, perhaps
I missed it.  If the discussion was entirely off-line can you please
just provide a sentence or two on the reasoning?

I would guess that the reasoning may be something along these lines:

1) The term provisioning is ill defined.
2) The term provisioning may be interpreted by some as too limiting or
too broad.
3) Depending on ones definition of "provisioning", the WG may work on
items that have nothing to do with provisioning.

However, while the above points may be accurate, I'm not sure how
changing the WG name from "PEPPERMINT" to "DRINKS" helps in a meaningful
manner.  It seems that the content of the WG Charter is more important
in providing the necessary clarity than the name of the WG.

In short, my $.02 is that changing the name of the WG from PEPPERMINT to
DRINKS is just fine.  But, more importantly, I'd like to see how this
name change impacts the content of the Charter.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Wednesday, April 09, 2008 9:18 PM
To: [email-masked]
Subject: PEPPERMINT Digest, Vol 10, Issue 18

Send PEPPERMINT mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/peppermint
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of PEPPERMINT digest..."

Today's Topics:

   1.  New name for the WG... consensus desired (Richard Shockey)

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

Message: 1
Date: Wed, 9 Apr 2008 21:18:13 -0400
From: "Richard Shockey" <[email-masked]>
Subject: [PEPPERMINT] New name for the WG... consensus desired
To: <[email-masked]>
Message-ID: <021601c89aa8$c0a9b5f0$41fd21d0$@us>
Content-Type: text/plain;	charset="US-ASCII"

In some serious off line discussions, there was a suggestion that
PEPPERMINT might not be the most appropriate WG name since the concept
of provisioning has very specific context in teleco world.

What we are dealing with is data exchanges.

Hense the suggestion of a new WG name 

DRINKS 

Data for Reachability of Inter/tra-NetworK SIP

Personally I think this is a perfect IETF WG name and meets all the
criterion of cuteness, banality, etc. and extremely appropriate given
the venue of a probably first meeting ..Dublin .

We'd like to get a consensus if the change of name is appropriate.

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

End of PEPPERMINT Digest, Vol 10, Issue 18
******************************************
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

From: Dan York <[email-masked]>
Date: Thu, 10 Apr 2008 09:01:41 -0400
To: Richard Shockey <[email-masked]>
Cc: [email-masked], 'Hadriel Kaplan' <[email-masked]>
Subject: Re: [PEPPERMINT] New name for the WG... consensus desired
Sender: [email-masked]

--===============0523461622==
Content-Type: multipart/alternative; boundary=Apple-Mail-5--255448635

--Apple-Mail-5--255448635
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On Apr 10, 2008, at 12:39 AM, Richard Shockey wrote:

>>  Oh sure, blame me!  You were the one who liked DRINKS! :)
>
> Very true I like DRINKS.  I like lots of DRINKS.
>
> Seriously, I was only giving proper credit where credit is due. The  
> point
> you made on "provisioning" terminology is in fact valid in the  
> context of
> what this WG wants to accomplish and your unique and deliciously  
> elegant
> solution for WG naming you propose is equally valid.
>
> Clarity in intent and purpose is vital to a correct charter and WG
> definition. This is exactly what we are supposed to do in the IETF.  
> That the
> WG name you proposed is both comic and sublime is only a bonus.

+1  (now that I understand the suggestion is serious)

The PEPPERMINT name always seemed  a bit of a stretch to me (not that  
DRINKS isn't!).  This *might* also ease some of the confusion with  
SPEERMINT, at least in terms of people *talking* about the two groups.

Dan (who wonders if there is some image out there of Peppermint Patty  
drinking...)

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

--Apple-Mail-5--255448635
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><br><div><div><html>On Apr 10, =
2008, at 12:39 AM, Richard Shockey wrote:</html><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><span =
class=3D"Apple-style-span" style=3D"-webkit-text-stroke-width: -1; ">=A0Oh=
 sure, blame me!=A0 You were the one who liked DRINKS! :)</span></div> =
</blockquote><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Very true I like DRINKS.<span =
class=3D"Apple-converted-space">=A0 </span>I like lots of =
DRINKS.</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Seriously, I was only giving proper credit where =
credit is due. The point</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">you made on =
"provisioning" terminology is in fact valid in the context of</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">what this WG wants to accomplish and your unique and =
deliciously elegant</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">solution for WG naming you =
propose is equally valid.<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Clarity in =
intent and purpose is vital to a correct charter and WG</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">definition. This is exactly what we are supposed to =
do in the IETF. That the</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">WG name you =
proposed is both comic and sublime is only a bonus.</div> =
</blockquote></div><div><br></div>+1 =A0(now that I understand the =
suggestion is serious)</div><div><br></div><div>The PEPPERMINT name =
always seemed =A0a bit of a stretch to me (not that DRINKS isn't!). =
=A0This *might* also ease some of the confusion with SPEERMINT, at least =
in terms of people *talking* about the two =
groups.</div><div><br></div><div>Dan (who wonders if there is some image =
out there of Peppermint Patty drinking...)</div><div><br><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; -webkit-text-decorations-in-effect: none; =
text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">--=A0</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Dan York, =
CISSP, Director of Emerging Communication Technology</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Office of the CTO=A0 =A0<span =
class=3D"Apple-converted-space">=A0</span>Voxeo Corporation<span =
class=3D"Apple-converted-space">=A0</span>=A0 =A0<span =
class=3D"Apple-converted-space">=A0</span><a =
href=3D"mailto:[email-masked]">[email-masked]</a></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Phone: +1-407-455-5859=A0<span =
class=3D"Apple-converted-space">=A0</span>Skype: danyork=A0<span =
class=3D"Apple-converted-space">=A0</span><a =
href=3D"http://www.voxeo.com">http://www.voxeo.com</a></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Blogs: <a =
href=3D"http://blogs.voxeo.com">http://blogs.voxeo.com</a>=A0<span =
class=3D"Apple-converted-space">=A0</span><a =
href=3D"http://www.disruptivetelephony.com">http://www.disruptivetelephony=
.com</a></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; min-height: 14px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Build voice applications based on open =
standards.</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Find out how at <a =
href=3D"http://www.voxeo.com/free">http://www.voxeo.com/free</a></div><div=
 style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
min-height: 14px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; min-height: 14px; "><br =
class=3D"khtml-block-placeholder"></div><br =
class=3D"Apple-interchange-newline"></span></span><br =
class=3D"Apple-interchange-newline"> </div><br></div></body></html>=

--Apple-Mail-5--255448635--

--===============0523461622==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0523461622==--

From: "Brian Rosen" <[email-masked]>
To: "'Richard Shockey'" <[email-masked]>, "'Hadriel Kaplan'" <[email-masked]>, <[email-masked]>
Date: Thu, 10 Apr 2008 08:53:42 -0400
Subject: Re: [PEPPERMINT] New name for the WG... consensus desired
Sender: [email-masked]

This change request wouldn't be related to your recently bestowed nom de
plume would it... Peppermint Patty?

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Richard Shockey
Sent: Thursday, April 10, 2008 12:40 AM
To: 'Hadriel Kaplan'; [email-masked]
Subject: Re: [PEPPERMINT] New name for the WG... consensus desired

>  
>  
>  Oh sure, blame me!  You were the one who liked DRINKS! :)

Very true I like DRINKS.  I like lots of DRINKS.

Seriously, I was only giving proper credit where credit is due. The point
you made on "provisioning" terminology is in fact valid in the context of
what this WG wants to accomplish and your unique and deliciously elegant
solution for WG naming you propose is equally valid. 

Clarity in intent and purpose is vital to a correct charter and WG
definition. This is exactly what we are supposed to do in the IETF. That the
WG name you proposed is both comic and sublime is only a bonus.

>  I wouldn't have raised it if it weren't for all the people I talk to
>  about it getting confused with provisioning, and having to spend time
>  starting off conversations with "well, it says provisioning, but...".

You saw a problem you raised it, you were right to raise it. Many of us
agree. Problem solved. 

>  :-P
>  

_______________________________________________
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: "Richard Shockey" <[email-masked]>
To: "'Hadriel Kaplan'" <[email-masked]>, <[email-masked]>
Date: Thu, 10 Apr 2008 00:39:37 -0400
Subject: Re: [PEPPERMINT] New name for the WG... consensus desired
Sender: [email-masked]

>  
>  
>  Oh sure, blame me!  You were the one who liked DRINKS! :)

Very true I like DRINKS.  I like lots of DRINKS.

Seriously, I was only giving proper credit where credit is due. The point
you made on "provisioning" terminology is in fact valid in the context of
what this WG wants to accomplish and your unique and deliciously elegant
solution for WG naming you propose is equally valid. 

Clarity in intent and purpose is vital to a correct charter and WG
definition. This is exactly what we are supposed to do in the IETF. That the
WG name you proposed is both comic and sublime is only a bonus.

>  I wouldn't have raised it if it weren't for all the people I talk to
>  about it getting confused with provisioning, and having to spend time
>  starting off conversations with "well, it says provisioning, but...".

You saw a problem you raised it, you were right to raise it. Many of us
agree. Problem solved. 

>  :-P
>  

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

From: Hadriel Kaplan <[email-masked]>
To: Richard Shockey <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 9 Apr 2008 23:34:37 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] New name for the WG... consensus desired
Sender: [email-masked]

Oh sure, blame me!  You were the one who liked DRINKS! :)
I wouldn't have raised it if it weren't for all the people I talk to about it getting confused with provisioning, and having to spend time starting off conversations with "well, it says provisioning, but...".
:-P

-hadriel

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]]
>
> I would like to point out, for the record, that Hadriel Kaplan correctly
> pointed out the semantic issue with provisioning terminology in the WG
> title
> and charter and suggested the new WG name.
>
> A most useful contribution.
>
> .
> >
> >  +1
> >  I am all in favor of avoiding the "provisioning" term, even if it
> >  drives us to DRINK(s).
> >
> >  -hadriel

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

From: "Richard Shockey" <[email-masked]>
To: "'Hadriel Kaplan'" <[email-masked]>, <[email-masked]>
Date: Wed, 9 Apr 2008 23:31:05 -0400
Subject: Re: [PEPPERMINT] New name for the WG... consensus desired
Sender: [email-masked]

I would like to point out, for the record, that Hadriel Kaplan correctly
pointed out the semantic issue with provisioning terminology in the WG title
and charter and suggested the new WG name.

A most useful contribution. 

.
>  
>  +1
>  I am all in favor of avoiding the "provisioning" term, even if it
>  drives us to DRINK(s).
>  
>  -hadriel

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

From: "Richard Shockey" <[email-masked]>
To: "'DOLLY, MARTIN C, ATTLABS'" <[email-masked]>, <[email-masked]>
Date: Wed, 9 Apr 2008 23:16:52 -0400
Subject: Re: [PEPPERMINT] New name for the WG... consensus desired
Sender: [email-masked]

Obviously the WG would be BYOB.

>  -----Original Message-----
>  From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]]
>  Sent: Wednesday, April 09, 2008 9:50 PM
>  To: Richard Shockey; [email-masked]
>  Subject: RE: [PEPPERMINT] New name for the WG... consensus desired
>  
>  I do not think I could turn down a DRINK(S)...
>  
>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]]
>  On Behalf Of Richard Shockey
>  Sent: Wednesday, April 09, 2008 9:18 PM
>  To: [email-masked]
>  Subject: [PEPPERMINT] New name for the WG... consensus desired
>  
>  In some serious off line discussions, there was a suggestion that
>  PEPPERMINT
>  might not be the most appropriate WG name since the concept of
>  provisioning
>  has very specific context in teleco world.
>  
>  What we are dealing with is data exchanges.
>  
>  Hense the suggestion of a new WG name
>  
>  DRINKS
>  
>  Data for Reachability of Inter/tra-NetworK SIP
>  
>  Personally I think this is a perfect IETF WG name and meets all the
>  criterion of cuteness, banality, etc. and extremely appropriate given
>  the
>  venue of a probably first meeting ..Dublin .
>  
>  We'd like to get a consensus if the change of name is appropriate.
>  
>  
>  
>  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

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

From: "Richard Shockey" <[email-masked]>
To: "'Maharishi, Manjul'" <[email-masked]>, <[email-masked]>
Date: Wed, 9 Apr 2008 23:16:22 -0400
Subject: Re: [PEPPERMINT] New name for the WG... consensus desired
Sender: [email-masked]

This is a multipart message in MIME format.

--===============0356086227==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_051F_01C89A97.BB312B00"
Content-language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_051F_01C89A97.BB312B00
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Who said this was a joke?

 

From: Maharishi, Manjul [mailto:[email-masked]] 
Sent: Wednesday, April 09, 2008 10:10 PM
To: Richard Shockey; [email-masked]
Subject: Re: [PEPPERMINT] New name for the WG... consensus desired

Rich,

You are seriously late for the April fools day jokes ....when I last checked
my calendar, it was already the 9th :)

Manjul Maharishi
Sr.Mgr. R&D IPE
VeriSign

Sent from Goodlink

 -----Original Message-----
From:   DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]]
Sent:   Wednesday, April 09, 2008 09:49 PM Eastern Standard Time
To:     Richard Shockey; [email-masked]
Subject:        Re: [PEPPERMINT] New name for the WG... consensus desired

I do not think I could turn down a DRINK(S)...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Richard Shockey
Sent: Wednesday, April 09, 2008 9:18 PM
To: [email-masked]
Subject: [PEPPERMINT] New name for the WG... consensus desired

In some serious off line discussions, there was a suggestion that
PEPPERMINT
might not be the most appropriate WG name since the concept of
provisioning
has very specific context in teleco world.

What we are dealing with is data exchanges.

Hense the suggestion of a new WG name

DRINKS

Data for Reachability of Inter/tra-NetworK SIP

Personally I think this is a perfect IETF WG name and meets all the
criterion of cuteness, banality, etc. and extremely appropriate given
the
venue of a probably first meeting ..Dublin .

We'd like to get a consensus if the change of name is appropriate.

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

------=_NextPart_000_051F_01C89A97.BB312B00
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<title>Re: [PEPPERMINT] New name for the WG... consensus desired</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Who said this was a joke?<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Maharishi, =
Manjul
[mailto:[email-masked]] <br>
<b>Sent:</b> Wednesday, April 09, 2008 10:10 PM<br>
<b>To:</b> Richard Shockey; [email-masked]<br>
<b>Subject:</b> Re: [PEPPERMINT] New name for the WG... consensus =
desired<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p><span style=3D'font-size:10.0pt'>Rich,<br>
<br>
You are seriously late for the April fools day jokes ....when I last =
checked my
calendar, it was already the 9th :)<br>
<br>
Manjul Maharishi<br>
Sr.Mgr. R&amp;D IPE<br>
VeriSign<br>
<br>
Sent from Goodlink<br>
<br>
&nbsp;-----Original Message-----<br>
From: &nbsp; DOLLY, MARTIN C, ATTLABS [<a =
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>]<br>
Sent:&nbsp;&nbsp; Wednesday, April 09, 2008 09:49 PM Eastern Standard =
Time<br>
To:&nbsp;&nbsp;&nbsp;&nbsp; Richard Shockey; [email-masked]<br>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: [PEPPERMINT] New =
name
for the WG... consensus desired<br>
<br>
I do not think I could turn down a DRINK(S)...<br>
<br>
-----Original Message-----<br>
From: [email-masked] [<a =
href=3D"mailto:[email-masked]">mailto:peppermint-bounces@iet=
f.org</a>]<br>
On Behalf Of Richard Shockey<br>
Sent: Wednesday, April 09, 2008 9:18 PM<br>
To: [email-masked]<br>
Subject: [PEPPERMINT] New name for the WG... consensus desired<br>
<br>
In some serious off line discussions, there was a suggestion that<br>
PEPPERMINT<br>
might not be the most appropriate WG name since the concept of<br>
provisioning<br>
has very specific context in teleco world.<br>
<br>
What we are dealing with is data exchanges.<br>
<br>
Hense the suggestion of a new WG name<br>
<br>
DRINKS<br>
<br>
Data for Reachability of Inter/tra-NetworK SIP<br>
<br>
Personally I think this is a perfect IETF WG name and meets all the<br>
criterion of cuteness, banality, etc. and extremely appropriate =
given<br>
the<br>
venue of a probably first meeting ..Dublin .<br>
<br>
We'd like to get a consensus if the change of name is appropriate.<br>
<br>
<br>
<br>
Richard Shockey<br>
Director, Member of the Technical Staff<br>
NeuStar<br>
46000 Center Oak Plaza - Sterling, VA 20166<br>
PSTN Office +1 571.434.5651<br>
PSTN Mobile: +1 703.593.2683<br>
&lt;<a =
href=3D"mailto:richard(at)shockey.us">mailto:richard(at)shockey.us</a>&gt=
;<br>
&lt;<a =
href=3D"mailto:richard.shockey(at)neustar.biz">mailto:richard.shockey(at)=
neustar.biz</a>&gt;<br>
<br>
<br>
<br>
_______________________________________________<br>
PEPPERMINT mailing list<br>
[email-masked]<br>
<a =
href=3D"https://www.ietf.org/mailman/listinfo/peppermint">https://www.iet=
f.org/mailman/listinfo/peppermint</a><br>
_______________________________________________<br>
PEPPERMINT mailing list<br>
[email-masked]<br>
<a =
href=3D"https://www.ietf.org/mailman/listinfo/peppermint">https://www.iet=
f.org/mailman/listinfo/peppermint</a></span><o:p></o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_051F_01C89A97.BB312B00--

--===============0356086227==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0356086227==--

From: Hadriel Kaplan <[email-masked]>
To: Richard Shockey <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 9 Apr 2008 23:12:43 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] New name for the WG... consensus desired
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Shockey
> What we are dealing with is data exchanges.
> Hense the suggestion of a new WG name
> DRINKS
> Data for Reachability of Inter/tra-NetworK SIP
> Personally I think this is a perfect IETF WG name and meets all the
> criterion of cuteness, banality, etc. and extremely appropriate given the
> venue of a probably first meeting ..Dublin .
> We'd like to get a consensus if the change of name is appropriate.

+1
I am all in favor of avoiding the "provisioning" term, even if it drives us to DRINK(s).

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

Content-class: urn:content-classes:message
Date: Wed, 9 Apr 2008 22:10:08 -0400
From: "Maharishi, Manjul" <[email-masked]>
To: "Richard Shockey" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] New name for the WG... consensus desired
Sender: [email-masked]

This is a multi-part message in MIME format.

--===============1969759771==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C89AAF.FFC25442"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C89AAF.FFC25442
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Rich,

You are seriously late for the April fools day jokes ....when I last =
checked my calendar, it was already the 9th :)

Manjul Maharishi
Sr.Mgr. R&D IPE
VeriSign

Sent from Goodlink

 -----Original Message-----
From: 	DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]]
Sent:	Wednesday, April 09, 2008 09:49 PM Eastern Standard Time
To:	Richard Shockey; [email-masked]
Subject:	Re: [PEPPERMINT] New name for the WG... consensus desired

I do not think I could turn down a DRINK(S)...=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Richard Shockey
Sent: Wednesday, April 09, 2008 9:18 PM
To: [email-masked]
Subject: [PEPPERMINT] New name for the WG... consensus desired

In some serious off line discussions, there was a suggestion that
PEPPERMINT
might not be the most appropriate WG name since the concept of
provisioning
has very specific context in teleco world.

What we are dealing with is data exchanges.

Hense the suggestion of a new WG name=20

DRINKS=20

Data for Reachability of Inter/tra-NetworK SIP

Personally I think this is a perfect IETF WG name and meets all the
criterion of cuteness, banality, etc. and extremely appropriate given
the
venue of a probably first meeting ..Dublin .

We'd like to get a consensus if the change of name is appropriate.

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

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

------_=_NextPart_001_01C89AAF.FFC25442
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Re: [PEPPERMINT] New name for the WG... consensus desired</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Rich,<BR>
<BR>
You are seriously late for the April fools day jokes ....when I last =
checked my calendar, it was already the 9th :)<BR>
<BR>
Manjul Maharishi<BR>
Sr.Mgr. R&amp;D IPE<BR>
VeriSign<BR>
<BR>
Sent from Goodlink<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; DOLLY, MARTIN C, ATTLABS [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent:&nbsp;&nbsp; Wednesday, April 09, 2008 09:49 PM Eastern Standard =
Time<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; Richard Shockey; [email-masked]<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: [PEPPERMINT] New =
name for the WG... consensus desired<BR>
<BR>
I do not think I could turn down a DRINK(S)...<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:peppermint-bounces@iet=
f.org</A>]<BR>
On Behalf Of Richard Shockey<BR>
Sent: Wednesday, April 09, 2008 9:18 PM<BR>
To: [email-masked]<BR>
Subject: [PEPPERMINT] New name for the WG... consensus desired<BR>
<BR>
In some serious off line discussions, there was a suggestion that<BR>
PEPPERMINT<BR>
might not be the most appropriate WG name since the concept of<BR>
provisioning<BR>
has very specific context in teleco world.<BR>
<BR>
What we are dealing with is data exchanges.<BR>
<BR>
Hense the suggestion of a new WG name<BR>
<BR>
DRINKS<BR>
<BR>
Data for Reachability of Inter/tra-NetworK SIP<BR>
<BR>
Personally I think this is a perfect IETF WG name and meets all the<BR>
criterion of cuteness, banality, etc. and extremely appropriate =
given<BR>
the<BR>
venue of a probably first meeting ..Dublin .<BR>
<BR>
We'd like to get a consensus if the change of name is appropriate.<BR>
<BR>
<BR>
<BR>
Richard Shockey<BR>
Director, Member of the Technical Staff<BR>
NeuStar<BR>
46000 Center Oak Plaza - Sterling, VA 20166<BR>
PSTN Office +1 571.434.5651<BR>
PSTN Mobile: +1 703.593.2683<BR>
&lt;<A =
HREF=3D"mailto:richard(at)shockey.us">mailto:richard(at)shockey.us</A>&gt=
;<BR>
&lt;<A =
HREF=3D"mailto:richard.shockey(at)neustar.biz">mailto:richard.shockey(at)=
neustar.biz</A>&gt;<BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
PEPPERMINT mailing list<BR>
[email-masked]<BR>
<A =
HREF=3D"https://www.ietf.org/mailman/listinfo/peppermint">https://www.iet=
f.org/mailman/listinfo/peppermint</A><BR>
_______________________________________________<BR>
PEPPERMINT mailing list<BR>
[email-masked]<BR>
<A =
HREF=3D"https://www.ietf.org/mailman/listinfo/peppermint">https://www.iet=
f.org/mailman/listinfo/peppermint</A><BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C89AAF.FFC25442--

--===============1969759771==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1969759771==--

Content-class: urn:content-classes:message
Date: Wed, 9 Apr 2008 20:49:46 -0500
From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
To: "Richard Shockey" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] New name for the WG... consensus desired
Sender: [email-masked]

I do not think I could turn down a DRINK(S)... 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Richard Shockey
Sent: Wednesday, April 09, 2008 9:18 PM
To: [email-masked]
Subject: [PEPPERMINT] New name for the WG... consensus desired

In some serious off line discussions, there was a suggestion that
PEPPERMINT
might not be the most appropriate WG name since the concept of
provisioning
has very specific context in teleco world.

What we are dealing with is data exchanges.

Hense the suggestion of a new WG name 

DRINKS 

Data for Reachability of Inter/tra-NetworK SIP

Personally I think this is a perfect IETF WG name and meets all the
criterion of cuteness, banality, etc. and extremely appropriate given
the
venue of a probably first meeting ..Dublin .

We'd like to get a consensus if the change of name is appropriate.

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Wed, 9 Apr 2008 21:18:13 -0400
Subject: [PEPPERMINT] New name for the WG... consensus desired
Sender: [email-masked]

In some serious off line discussions, there was a suggestion that PEPPERMINT
might not be the most appropriate WG name since the concept of provisioning
has very specific context in teleco world.

What we are dealing with is data exchanges.

Hense the suggestion of a new WG name 

DRINKS 

Data for Reachability of Inter/tra-NetworK SIP

Personally I think this is a perfect IETF WG name and meets all the
criterion of cuteness, banality, etc. and extremely appropriate given the
venue of a probably first meeting ..Dublin .

We'd like to get a consensus if the change of name is appropriate.

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]>
To: Daryl Malas <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 1 Apr 2008 17:36:44 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

> -----Original Message-----
> From: Daryl Malas [mailto:[email-masked]]
> >
> > Data exchanges to facilitate session-based Multimedia Interconnection
> > are typically between various bilateral or multilateral client User
> > Agents and related Registries.
>
> [HK] I'm not sure I understand why the term "client User Agents" is used?
> A Proxy is not a User Agent, and neither is an ENUM server, for example.
> Or do you just mean it's a User Agent with respect to being the Agent of
> the data exchange?
>
> [DM] I would suggest "client User Agents" is changed to "SIP User
> Agents", but a proxy would not be provisioned within an ENUM server as
> an end-point.   A B2BUA, otherwise known as a UA to SIP, would be.

I don't know what you mean by "a proxy would not be provisioned within an ENUM server as an end-point".  Clearly there may not be an E.164 phone number/NAPTr entry representing a proxy (although interestingly in some cases there are, but I digress), but the next-hop defined by the regex replacement hostname could well be a proxy.  Or it could be a b2bua, or SBE, or whatever hybrid intermediate hop type exists.  Or it could be a final endpoint UAS.

Regardless, the part I'm concerned with is that the paragraph says the data exchange is typically between various UA's and related registries.  I *think* what you mean by that is that the data is typically exchanged between various LUF and/or LRF functional nodes (e.g., enum DB, proxy, b2bua, sbe, etc.)?

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

From: Hadriel Kaplan <[email-masked]>
To: Daryl Malas <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 1 Apr 2008 17:25:09 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

> -----Original Message-----
> From: Daryl Malas [mailto:[email-masked]]
>
> [DM] Okay, I am not sure how you read "indirect" peering into that
> sentence.  Also, just because you are a member of a federation does not
> suddenly give you a "golden key" to peer with everyone within it.  The
> point of the sentence is to indicate there are potential complexities to
> be considered within PEPPERMINT when peers are in multilateral
> relationships.  It should not be PEPPERMINT to determine what those
> architectural complexities are.  These are discussed, documented, and
> determined within SPEERMINT; however, based on these complexities,
> PEPPERMINT will need to take into consideration the provisioning of data
> within a Federation.  It will be, potentially, different than a single
> bi-lateral peering arrangement.

Totally agree on that - I just read it from your first version, as implying such would be the case.  I'm cool with this.

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

From: Hadriel Kaplan <[email-masked]>
To: Daryl Malas <[email-masked]>, "DOLLY, MARTIN C, ATTLABS" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 1 Apr 2008 17:19:52 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

> -----Original Message-----
> From: Daryl Malas [mailto:[email-masked]]
>
> Hadriel,
>
> I agree it should be within the scope to consider an enterprise's use of
> the outcome of PEPPERMINT, but it is not PEPPERMINT's job to determine
> the formation of enterprises within varying peering architectures.  At
> best, this would be done within SPEERMINT, and some architectures and
> peering considerations for enterprises are already documented within
> SPEERMINT artifacts.

I'm confused - did I imply such would be PEPPERMINT's job?  I certainly didn't mean to if I did.

-hadriel

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Tuesday, April 01, 2008 9:20 AM
> To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; [email-masked]
> Subject: RE: [PEPPERMINT] Proposed Updated Charter
>
>
> Imagine a big enterprise, having multiple branch offices, lots of user
> agents and proxies/servers/whatever.  They may want calls within a
> branch to stay in the branch, calls between certain branches to go over
> the public Internet, calls between other branches to use leased lines or
> VPNs, calls between other branches to use the PSTN or ESN-type TDM
> network, etc.  So they could potentially use an outcome of PEPPERMINT to
> dynamically provision their servers/proxies in the various branches with
> such routing data, and make changes as employees or groups are added or
> move branches.
>
> OR another example is suppose this big enterprise connects to multiple
> service providers or federations, perhaps different ones for different
> branches - the providers or federations can dynamically inform the
> enterprise or its branches of which ingress points can be used for what
> routes, with potentially some other attributes yet to be defined.  That
> way as the provider/federation adds or removes ingress points or routes,
> it can do so in a more automated fashion.
>
> I think, but I'm not sure, that including enterprises in the charter
> does not mean to say any of those things would happen, or that
> PEPPERMINT would actually define such uses explicitly/separately, or
> that they have to give special consideration to such - just that it's
> within the scope of the WG's purview to do so.  Is that correct?
>
> -hadriel
>
>
> > -----Original Message-----
> > From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]]
> >
> > I do not agree with your example, yet. Can you be a little more
> > specific, as to what information  peppermint would provide here?
> >
> > Thanks,
> >
> > Martin
> >
> > -----Original Message-----
> > From: Hadriel Kaplan [mailto:[email-masked]]
> > Sent: Monday, March 31, 2008 10:18 PM
> > To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; [email-masked]
> > Subject: RE: [PEPPERMINT] Proposed Updated Charter
> >
> > His proposed replacement text is only the second half of his email,
> > which doesn't use the term "PBX" (thankfully).  It does use the term
> > "enterprises", but does not define the scope of that, nor does it
> > imply any and all enterprises would be involved or how (which I think
> > it's good to keep undefined).
> >
> > Examples would be an Enterprise using something out of PEPPERMINT
> > itself to provision its own proxies/databases, for example with what
> > service provider to use for what routes, or what SBE's to use to reach
>
> > that service provider.  Or a service provider might exchange some
> > information with the Enterprise, or vice-versa, for similar
> > information.  The "enterprises" could be large corporations; or
> > perhaps a service provider's own internal employee system, or their
> > consumer voip service might be considered a separate, enterprise-type,
>
> > from their other voip services/networks.
> >
> > -hadriel
> >
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Date: Tue, 01 Apr 2008 21:57:16 +0100
From: "Elwell, John" <[email-masked]>
To: Richard Shockey <[email-masked]>, "DRAGE, Keith (Keith)" <[email-masked]>, "DOLLY, MARTIN C, ATTLABS" <[email-masked]>, Hadriel Kaplan <[email-masked]>, Daryl Malas <[email-masked]>, [email-masked]
Content-class: urn:content-classes:message
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

Replying to all who have commented on the enterprise question, I would
not want the charter or the deliverables to explicitly exclude
enterprises. There will be different sizes of enterprises, and if some
of the work of PEPPERMINT turns out to be suitable for use within and
between larger enterprises and between enterprises and carriers, I would
not want to preclude that.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Richard Shockey
> Sent: 01 April 2008 18:05
> To: 'DRAGE, Keith (Keith)'; 'DOLLY, MARTIN C, ATTLABS'; 
> 'Hadriel Kaplan'; 'Daryl Malas'; [email-masked]
> Subject: Re: [PEPPERMINT] Proposed Updated Charter
> 
> I agree with you Keith.
> 
> There is no reason here to get into a Talmudic discussion of 
> what is and is
> not a SSP.
> 
> But with that said there is probably no reason to actually 
> call out the
> enterprise either in the charter. In this peculiar case "size does not
> matter."
> 
> >  -----Original Message-----
> >  From: [email-masked] 
> [mailto:[email-masked]]
> >  On Behalf Of DRAGE, Keith (Keith)
> >  Sent: Tuesday, April 01, 2008 12:02 PM
> >  To: DOLLY, MARTIN C, ATTLABS; Hadriel Kaplan; Daryl Malas;
> >  [email-masked]
> >  Subject: Re: [PEPPERMINT] Proposed Updated Charter
> >  
> >  Just to note that the reason that this text appeared in the first
> >  place
> >  was in response to a question I asked about the size of 
> systems to be
> >  addressed.
> >  
> >  The smaller the systems that this becomes appropriate for, 
> the more we
> >  move into enterprise land, and out of that of the big 
> public network
> >  operators (although this is a generalisation as there are many
> >  enterprise networks bigger that some public networks).
> >  
> >  So it is range of system size I want to see represented in 
> the text if
> >  we are really stuck on terminology.
> >  
> >  Regards
> >  
> >  Keith
> >  
> >  > -----Original Message-----
> >  > From: [email-masked]
> >  > [mailto:[email-masked]] On Behalf Of DOLLY,
> >  > MARTIN C, ATTLABS
> >  > Sent: Tuesday, April 01, 2008 12:08 PM
> >  > To: Hadriel Kaplan; Daryl Malas; [email-masked]
> >  > Subject: Re: [PEPPERMINT] Proposed Updated Charter
> >  >
> >  > Hadriel,
> >  >
> >  > I do not agree with your example, yet. Can you be a little
> >  > more specific, as to what information  peppermint would provide
> >  here?
> >  >
> >  > Thanks,
> >  >
> >  > Martin
> >  >
> >  > -----Original Message-----
> >  > From: Hadriel Kaplan [mailto:[email-masked]]
> >  > Sent: Monday, March 31, 2008 10:18 PM
> >  > To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; [email-masked]
> >  > Subject: RE: [PEPPERMINT] Proposed Updated Charter
> >  >
> >  > His proposed replacement text is only the second half of his
> >  > email, which doesn't use the term "PBX" (thankfully).  It
> >  > does use the term "enterprises", but does not define the
> >  > scope of that, nor does it imply any and all enterprises
> >  > would be involved or how (which I think it's good to keep
> >  undefined).
> >  >
> >  > Examples would be an Enterprise using something out of
> >  > PEPPERMINT itself to provision its own proxies/databases, for
> >  > example with what service provider to use for what routes, or
> >  > what SBE's to use to reach that service provider.  Or a
> >  > service provider might exchange some information with the
> >  > Enterprise, or vice-versa, for similar information.  The
> >  > "enterprises" could be large corporations; or perhaps a
> >  > service provider's own internal employee system, or their
> >  > consumer voip service might be considered a separate,
> >  > enterprise-type, from their other voip services/networks.
> >  >
> >  > -hadriel
> >  >
> >  > > -----Original Message-----
> >  > > From: [email-masked]
> >  > [mailto:[email-masked]]
> >  > On
> >  > > Behalf Of DOLLY, MARTIN C, ATTLABS
> >  > > Sent: Monday, March 31, 2008 9:31 PM
> >  > > To: Daryl Malas; [email-masked]
> >  > > Subject: Re: [PEPPERMINT] Proposed Updated Charter
> >  > >
> >  > > Hello,
> >  > >
> >  > > As I stated in the meeting, reference to 
> enterprise/PBXs should be
> >  > > removed. If you think it should remain please give 
> examples of the
> >  > > provisioned information?
> >  > >
> >  > > Thanks,
> >  > >
> >  > > Martin
> >  > >
> >  > > -----Original Message-----
> >  > > From: [email-masked]
> >  > [mailto:[email-masked]]
> >  > > On Behalf Of Daryl Malas
> >  > > Sent: Monday, March 31, 2008 4:10 PM
> >  > > To: [email-masked]
> >  > > Subject: [PEPPERMINT] Proposed Updated Charter
> >  > >
> >  > > All,
> >  > >
> >  > > I was asked to re-write the charter using agreed upon 
> SPEERMINT WG
> >  > > defined terms.  I also added/changed a few minor suggested
> >  details.
> >  > The
> >  > > update is below:
> >  > >
> >  > > ------------------------------------------
> >  > > Existing charter:
> >  > >
> >  > > PROPOSED CHARTER FOR PEPPERMINT
> >  > >
> >  > > The IETF has been working on various aspects of session-based
> >  > Multimedia
> >  > > Interconnection among administrative domains. In addition, the
> >  IETF
> >  > has
> >  > > done significant work on data exchanges among various network
> >  > elements.
> >  > >
> >  > > ENUM is specifically chartered to develop protocols that
> >  > involve the
> >  > > translation of E.164 numbers to URI's.
> >  > >
> >  > > SPEERMINT has been chartered to develop best current
> >  > practices among
> >  > > real-time application service providers and how such services
> >  > > interconnect across administrative boundaries.
> >  > >
> >  > > The PEPPERMINT work group is chartered to define what data
> >  > needs to be
> >  > > exchanged among Multimedia administrative domains, and how
> >  > that data
> >  > > should be structured provisioned and propagated. These
> >  > protocols would
> >  > > be outside the normal scope of establishing various 
> forms of a SIP
> >  > > session. These administrative domains are of any practical size
> >  and
> >  > > could be service providers or enterprise SIP proxy's, such as
> >  PBX's.
> >  > >
> >  > > Data exchanges to facilitate session-based Multimedia
> >  > Interconnection
> >  > > are typically between various Client User Agents and 
> Registries or
> >  > > bilateral or multilateral Registry to Registry.  Data
> >  > exchanges could
> >  > > include bulk data as well as real time updates. Typical
> >  > data include
> >  > > mappings of phone numbers to URIs, policies surrounding
> >  > admission to
> >  > > various points of network interconnection and various types
> >  > of trunk
> >  > > data.  In addition, there is a specific need for 
> redistribution of
> >  > such
> >  > > Registry data to various types of network databases.
> >  > >
> >  > > The working group will draw upon expert advice and ongoing
> >  > consultation
> >  > > from the ENUM, SPEERMINT and PROVREG working groups. The
> >  > working group
> >  > > may also reuse elements of RFC 4114, if possible.
> >  > >
> >  > > The final work product(s) from this working group will
> >  > utilize and be
> >  > > based on XML documents and XML document exchanges.
> >  > > -------------------------------------
> >  > > New revision:
> >  > >
> >  > > PROPOSED CHARTER FOR PEPPERMINT
> >  > >
> >  > > The IETF has been working on various aspects of session-based
> >  > Multimedia
> >  > > peering among SIP Service Providers (SSPs), 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 following working groups'
> >  > work provides
> >  > > the underlying context for much of the intended work 
> within this
> >  > > charter:
> >  > >
> >  > > ENUM, which is specifically chartered to develop protocols that
> >  > involve
> >  > > the translation of E.164 numbers to URIs.
> >  > >
> >  > > SPEERMINT, which has been chartered to develop requirements
> >  > and best
> >  > > current practices among real-time application SSPs and how such
> >  > services
> >  > > may interconnect across administrative boundaries.  
> This work will
> >  > > provide details of how Session Establishment Data (SED) is
> >  collected
> >  > and
> >  > > what this data is comprised of, the use of this data 
> to properly
> >  > > identify an optimal path to the destination user agent
> >  > (UA), and the
> >  > > secure manners in which this and the SIP session data 
> is exchanged
> >  > > between all of the peering functions.  It is also
> >  > recognizes peering
> >  > > relationships become more complex as multiple peers 
> are added to a
> >  > > common relationship, these complex aspects and requirements of
> >  > multiple,
> >  > > yet common peering relationships are defined with the 
> contexts of
> >  a
> >  > > peering Federation.
> >  > >
> >  > > The PEPPERMINT working group is chartered to define what
> >  > data needs to
> >  > > be exchanged among Multimedia administrative domains, 
> and how that
> >  > data
> >  > > should be structured, provisioned, and propagated. 
> These protocols
> >  > would
> >  > > be outside the normal scope of establishing various 
> forms of a SIP
> >  > > session. These administrative domains are of any practical size
> >  and
> >  > > could be any type of SSP, such as recognized telephony 
> carriers,
> >  > > enterprises, end-user groups, and Federations.
> >  > >
> >  > > Data exchanges to facilitate session-based Multimedia
> >  > Interconnection
> >  > > are typically between various bilateral or multilateral client
> >  User
> >  > > Agents and related Registries.  Data exchanges could
> >  > include bulk data
> >  > > and/or real time updates. Typical data includes 
> mappings of phone
> >  > > numbers to URIs, policies surrounding admission to various
> >  > points of
> >  > > network interconnection, and various types of interconnect
> >  > data.  In
> >  > > addition, there is a specific need for the exchange of 
> such data
> >  > between
> >  > > the Registry and various types of network databases (e.g.
> >  > Local Number
> >  > > Portability (LNP), Calling Name (CNAM), etc.).
> >  > >
> >  > > 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, if possible.
> >  > >
> >  > > The final work product(s) from this working group will
> >  > utilize and be
> >  > > based on XML documents and XML document exchanges.
> >  > >
> >  > > ---------------------------------------
> >  > >
> >  > > Thanks...--Daryl
> >  > >
> >  > >
> >  > > _______________________________________________
> >  > > PEPPERMINT mailing list
> >  > > [email-masked]
> >  > > https://www.ietf.org/mailman/listinfo/peppermint
> >  > > _______________________________________________
> >  > > PEPPERMINT mailing list
> >  > > [email-masked]
> >  > > https://www.ietf.org/mailman/listinfo/peppermint
> >  > _______________________________________________
> >  > PEPPERMINT mailing list
> >  > [email-masked]
> >  > https://www.ietf.org/mailman/listinfo/peppermint
> >  >
> >  _______________________________________________
> >  PEPPERMINT mailing list
> >  [email-masked]
> >  https://www.ietf.org/mailman/listinfo/peppermint
> 
> _______________________________________________
> 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: "Richard Shockey" <[email-masked]>
To: "'DRAGE, Keith \(Keith\)'" <[email-masked]>, "'DOLLY, MARTIN C, ATTLABS'" <[email-masked]>, "'Hadriel Kaplan'" <[email-masked]>, "'Daryl Malas'" <[email-masked]>, <[email-masked]>
Date: Tue, 1 Apr 2008 13:05:28 -0400
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

I agree with you Keith.

There is no reason here to get into a Talmudic discussion of what is and is
not a SSP.

But with that said there is probably no reason to actually call out the
enterprise either in the charter. In this peculiar case "size does not
matter."

>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]]
>  On Behalf Of DRAGE, Keith (Keith)
>  Sent: Tuesday, April 01, 2008 12:02 PM
>  To: DOLLY, MARTIN C, ATTLABS; Hadriel Kaplan; Daryl Malas;
>  [email-masked]
>  Subject: Re: [PEPPERMINT] Proposed Updated Charter
>  
>  Just to note that the reason that this text appeared in the first
>  place
>  was in response to a question I asked about the size of systems to be
>  addressed.
>  
>  The smaller the systems that this becomes appropriate for, the more we
>  move into enterprise land, and out of that of the big public network
>  operators (although this is a generalisation as there are many
>  enterprise networks bigger that some public networks).
>  
>  So it is range of system size I want to see represented in the text if
>  we are really stuck on terminology.
>  
>  Regards
>  
>  Keith
>  
>  > -----Original Message-----
>  > From: [email-masked]
>  > [mailto:[email-masked]] On Behalf Of DOLLY,
>  > MARTIN C, ATTLABS
>  > Sent: Tuesday, April 01, 2008 12:08 PM
>  > To: Hadriel Kaplan; Daryl Malas; [email-masked]
>  > Subject: Re: [PEPPERMINT] Proposed Updated Charter
>  >
>  > Hadriel,
>  >
>  > I do not agree with your example, yet. Can you be a little
>  > more specific, as to what information  peppermint would provide
>  here?
>  >
>  > Thanks,
>  >
>  > Martin
>  >
>  > -----Original Message-----
>  > From: Hadriel Kaplan [mailto:[email-masked]]
>  > Sent: Monday, March 31, 2008 10:18 PM
>  > To: DOLLY, MARTIN C, ATTLABS; Daryl Malas; [email-masked]
>  > Subject: RE: [PEPPERMINT] Proposed Updated Charter
>  >
>  > His proposed replacement text is only the second half of his
>  > email, which doesn't use the term "PBX" (thankfully).  It
>  > does use the term "enterprises", but does not define the
>  > scope of that, nor does it imply any and all enterprises
>  > would be involved or how (which I think it's good to keep
>  undefined).
>  >
>  > Examples would be an Enterprise using something out of
>  > PEPPERMINT itself to provision its own proxies/databases, for
>  > example with what service provider to use for what routes, or
>  > what SBE's to use to reach that service provider.  Or a
>  > service provider might exchange some information with the
>  > Enterprise, or vice-versa, for similar information.  The
>  > "enterprises" could be large corporations; or perhaps a
>  > service provider's own internal employee system, or their
>  > consumer voip service might be considered a separate,
>  > enterprise-type, from their other voip services/networks.
>  >
>  > -hadriel
>  >
>  > > -----Original Message-----
>  > > From: [email-masked]
>  > [mailto:[email-masked]]
>  > On
>  > > Behalf Of DOLLY, MARTIN C, ATTLABS
>  > > Sent: Monday, March 31, 2008 9:31 PM
>  > > To: Daryl Malas; [email-masked]
>  > > Subject: Re: [PEPPERMINT] Proposed Updated Charter
>  > >
>  > > Hello,
>  > >
>  > > As I stated in the meeting, reference to enterprise/PBXs should be
>  > > removed. If you think it should remain please give examples of the
>  > > provisioned information?
>  > >
>  > > Thanks,
>  > >
>  > > Martin
>  > >
>  > > -----Original Message-----
>  > > From: [email-masked]
>  > [mailto:[email-masked]]
>  > > On Behalf Of Daryl Malas
>  > > Sent: Monday, March 31, 2008 4:10 PM
>  > > To: [email-masked]
>  > > Subject: [PEPPERMINT] Proposed Updated Charter
>  > >
>  > > All,
>  > >
>  > > I was asked to re-write the charter using agreed upon SPEERMINT WG
>  > > defined terms.  I also added/changed a few minor suggested
>  details.
>  > The
>  > > update is below:
>  > >
>  > > ------------------------------------------
>  > > Existing charter:
>  > >
>  > > PROPOSED CHARTER FOR PEPPERMINT
>  > >
>  > > The IETF has been working on various aspects of session-based
>  > Multimedia
>  > > Interconnection among administrative domains. In addition, the
>  IETF
>  > has
>  > > done significant work on data exchanges among various network
>  > elements.
>  > >
>  > > ENUM is specifically chartered to develop protocols that
>  > involve the
>  > > translation of E.164 numbers to URI's.
>  > >
>  > > SPEERMINT has been chartered to develop best current
>  > practices among
>  > > real-time application service providers and how such services
>  > > interconnect across administrative boundaries.
>  > >
>  > > The PEPPERMINT work group is chartered to define what data
>  > needs to be
>  > > exchanged among Multimedia administrative domains, and how
>  > that data
>  > > should be structured provisioned and propagated. These
>  > protocols would
>  > > be outside the normal scope of establishing various forms of a SIP
>  > > session. These administrative domains are of any practical size
>  and
>  > > could be service providers or enterprise SIP proxy's, such as
>  PBX's.
>  > >
>  > > Data exchanges to facilitate session-based Multimedia
>  > Interconnection
>  > > are typically between various Client User Agents and Registries or
>  > > bilateral or multilateral Registry to Registry.  Data
>  > exchanges could
>  > > include bulk data as well as real time updates. Typical
>  > data include
>  > > mappings of phone numbers to URIs, policies surrounding
>  > admission to
>  > > various points of network interconnection and various types
>  > of trunk
>  > > data.  In addition, there is a specific need for redistribution of
>  > such
>  > > Registry data to various types of network databases.
>  > >
>  > > The working group will draw upon expert advice and ongoing
>  > consultation
>  > > from the ENUM, SPEERMINT and PROVREG working groups. The
>  > working group
>  > > may also reuse elements of RFC 4114, if possible.
>  > >
>  > > The final work product(s) from this working group will
>  > utilize and be
>  > > based on XML documents and XML document exchanges.
>  > > -------------------------------------
>  > > New revision:
>  > >
>  > > PROPOSED CHARTER FOR PEPPERMINT
>  > >
>  > > The IETF has been working on various aspects of session-based
>  > Multimedia
>  > > peering among SIP Service Providers (SSPs), 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 following working groups'
>  > work provides
>  > > the underlying context for much of the intended work within this
>  > > charter:
>  > >
>  > > ENUM, which is specifically chartered to develop protocols that
>  > involve
>  > > the translation of E.164 numbers to URIs.
>  > >
>  > > SPEERMINT, which has been chartered to develop requirements
>  > and best
>  > > current practices among real-time application SSPs and how such
>  > services
>  > > may interconnect across administrative boundaries.  This work will
>  > > provide details of how Session Establishment Data (SED) is
>  collected
>  > and
>  > > what this data is comprised of, the use of this data to properly
>  > > identify an optimal path to the destination user agent
>  > (UA), and the
>  > > secure manners in which this and the SIP session data is exchanged
>  > > between all of the peering functions.  It is also
>  > recognizes peering
>  > > relationships become more complex as multiple peers are added to a
>  > > common relationship, these complex aspects and requirements of
>  > multiple,
>  > > yet common peering relationships are defined with the contexts of
>  a
>  > > peering Federation.
>  > >
>  > > The PEPPERMINT working group is chartered to define what
>  > data needs to
>  > > be exchanged among Multimedia administrative domains, and how that
>  > data
>  > > should be structured, provisioned, and propagated. These protocols
>  > would
>  > > be outside the normal scope of establishing various forms of a SIP
>  > > session. These administrative domains are of any practical size
>  and
>  > > could be any type of SSP, such as recognized telephony carriers,
>  > > enterprises, end-user groups, and Federations.
>  > >
>  > > Data exchanges to facilitate session-based Multimedia
>  > Interconnection
>  > > are typically between various bilateral or multilateral client
>  User
>  > > Agents and related Registries.  Data exchanges could
>  > include bulk data
>  > > and/or real time updates. Typical data includes mappings of phone
>  > > numbers to URIs, policies surrounding admission to various
>  > points of
>  > > network interconnection, and various types of interconnect
>  > data.  In
>  > > addition, there is a specific need for the exchange of such data
>  > between
>  > > the Registry and various types of network databases (e.g.
>  > Local Number
>  > > Portability (LNP), Calling Name (CNAM), etc.).
>  > >
>  > > 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, if possible.
>  > >
>  > > The final work product(s) from this working group will
>  > utilize and be
>  > > based on XML documents and XML document exchanges.
>  > >
>  > > ---------------------------------------
>  > >
>  > > Thanks...--Daryl
>  > >
>  > >
>  > > _______________________________________________
>  > > PEPPERMINT mailing list
>  > > [email-masked]
>  > > https://www.ietf.org/mailman/listinfo/peppermint
>  > > _______________________________________________
>  > > PEPPERMINT mailing list
>  > > [email-masked]
>  > > https://www.ietf.org/mailman/listinfo/peppermint
>  > _______________________________________________
>  > PEPPERMINT mailing list
>  > [email-masked]
>  > https://www.ietf.org/mailman/listinfo/peppermint
>  >
>  _______________________________________________
>  PEPPERMINT mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/peppermint

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