Subject: Re: [PEPPERMINT] Proposed Updated Charter

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

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

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 01 Apr 2008 21:57:16 +0100

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

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 1 Apr 2008 17:19:52 -0400

> 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

> Sent: Tuesday, April 01, 2008 9:20 AM
> 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
>
>
> > 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
> >
> > 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
> >

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 1 Apr 2008 17:25:09 -0400

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 1 Apr 2008 17:36:44 -0400

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