Subject: Re: [PEPPERMINT] Proposed Updated Charter
From: Hadriel Kaplan <[email-masked]>
To: Daryl Malas <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 31 Mar 2008 23:01:11 -0400
List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection <peppermint.ietf.org>

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

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.

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

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

> 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: "Richard Shockey" <[email-masked]>
To: "'DOLLY, MARTIN C, ATTLABS'" <[email-masked]>, <[email-masked]>
Date: Mon, 31 Mar 2008 22:25:47 -0400
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

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

From: Hadriel Kaplan <[email-masked]>
To: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>, Daryl Malas <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 31 Mar 2008 22:17:55 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

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: Mon, 31 Mar 2008 20:31:16 -0500
From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
To: "Daryl Malas" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

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

From: "Richard Shockey" <[email-masked]>
To: "'Daryl Malas'" <[email-masked]>
Date: Mon, 31 Mar 2008 16:33:40 -0400
Cc: [email-masked]
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

What do you think about goals and milestones?

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

Something like this?

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

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

From: "Richard Shockey" <[email-masked]>
To: "'Daryl Malas'" <[email-masked]>, <[email-masked]>
Date: Mon, 31 Mar 2008 16:28:08 -0400
Subject: Re: [PEPPERMINT] Proposed Updated Charter
Sender: [email-masked]

Excellent ...

I don't think we need to specifically call out LNP and CNAM, "Network
databases" is sufficient.

>  
>  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: Mon, 31 Mar 2008 14:10:20 -0600
From: "Daryl Malas" <[email-masked]>
To: <[email-masked]>
Subject: [PEPPERMINT]  Proposed Updated Charter
Sender: [email-masked]

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Mon, 17 Mar 2008 14:34:10 -0400
Subject: [PEPPERMINT] Preliminary notes from the BOF
Sender: [email-masked]

Many thanks to Jason Livingood for taking notes ..

If you have additional recollection of issues etc let me know as I'll draft
the minutes up.

PEPPERMINT BoF IETF 71

Agenda
======

accepted

Charter review
==============

David: "may" use 4114 ... we "may" use a lot of things.

Ken ??: agree we "may" use a lot of things - slippery slope.

shockey proposes to remove reference to 4114

David Schwartz's concerns about "within" / "among" domains... currently says
"across".

David suggests to use "within" AND "among".

Hadriel suggest "within" and "between".

??: Maybe have presentations first, and then look into the charter?

Shockey: 2nd BoF already - identified that there is a problem here.

Jon: concerned about the "among / between" and the paragraph below that as
well.. "various" is not very precise.. doubt this is the right place to do
this charter texting. don't think we can get that agreed here.

David Schwartz speaking
==============

motivation: many peering registries formed, etc..

3 relationships.

between registries, pushing up and pushing down.

registry data 

prefix sub/super 
compatibility with ENUM
resolution data - ownership information
carrier of record, etc.
bulk considerations

logical operations on registry data

other attributes: validity
fee category...

lots of data associated with a number - not neccessarily everthing in a
registry.

Adam Uzelac: Are there "views", depending on "who is asking"?
Shockey: Would be attributes reflecting policy..

Hadriel: covers LUF _and_ LRF?

David: _very_ good question - definitely a different problem set.

Jon: Break all this into achievable chunks.

Jean-Francois - ESPP
====================

effort on ENUM-SIP server provisioning specification - intended as input
into the BoF only.

Problem: how can back office services provision data out to addressing
servers.

used the netconf structure to identify high level requirements

martin dolly: please expand beyond north america.

Sean Kent
=========

talking about design principles of ESPP. 

real time vs. bulk (file) based approach for larger changes.

most people in the room understand the problem

most of them thinks the IETF should work on this problem.

Cullen: Try to get this down to as small as possible. Any ideas on how that
could be defined?

David: Maybe start with "northbound" provisioning first, and leave out
registry-registry-Peering..

Jean-Francois: High level of charter is good - hope to not go into the same
discussions as in SPEERMINT

Daryl: agree with Jon - use the terminology from SPEERMINT - please!

CHAIR additional notes:
=======================

A. Confine first pass at Goals and Milestones to  Domain to Registry and
Registry to Local Cache

B. Eliminate references to PBX interface ..at this time. Could be scoped in
the future.

C. Registry to Registry interface also in the future.

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: "Robert H. Walter" <[email-masked]>
To: <[email-masked]>
Date: Thu, 13 Mar 2008 14:55:45 -0400
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 9, Issue 17
Sender: [email-masked]

Hi Ken,

Good to hear from you and thanks for the prompt response! I see the
distinction... Might a real world example be?

Enterprise ID = Comcast;
Enterprise ID encoded in Client ID encoded Object ID = VeriSign

Thanks,

-RHW

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Cartwright, Kenneth
Sent: Thursday, March 13, 2008 2:33 PM
To: [email-masked]
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 9, Issue 17

Hi Bob,

Thanks for the feedback.  After re-reading the sections of the document
that your points relate to, I think your question is a good one and the
language in the document on this subject could stand some improvement in
clarity.  But the document and the example that you refer to are
actually correct, although not quite clear.  The lack of clarity can
create confusion between the ClientID portion of the ObjectId property
and the EnterpriseID property.

The ClientID portion of the ObjectID is an identifier that represents
the "operational entity/source" responsible of the object in question
(iow, the specific ESPP client) with the goal of creating uniqueness of
the ObjectID property.  This ClientID leverages the IANA Enterprise ID
as the source of unique client IDs (which is then suffixed with a 2
digit identifier to allow for the occasion where there may be multiple
ESPP clients operated by a single organization).

The EnterpriseID property, on the other hand, is an identifier that
represents the "business entity/source" that is responsible for the
object in question.  The Enterprise ID also leverages the IANA
Enterprise ID as the source of unique identifiers.

So, based on the above, it may hopefully be clear now why these two
values are different in the example you refer to.  ....taken an action
to improve the language in the document.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Thursday, March 13, 2008 12:50 PM
To: [email-masked]
Subject: PEPPERMINT Digest, Vol 9, Issue 17

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.  ESPP Enterprise and Object IDs (Robert H. Walter)

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

Message: 1
Date: Thu, 13 Mar 2008 12:47:15 -0400
From: "Robert H. Walter" <[email-masked]>
Subject: [PEPPERMINT] ESPP Enterprise and Object IDs
To: "Peppermint" <[email-masked]>
Message-ID: <00b901c88529$e4b1ccb0$ae156610$@com>
Content-Type: text/plain; charset="us-ascii"

Hello,

This email discusses the topic of ESPP Enterprise and Object
Identifiers.
The I-D draft-mule-peppermint-espp-protocol-01.txt states in section 4.1
the
following:

   The globally unique name space for the assignment of an Enterprise ID
is
the

   open IANA Private Enterprise Number registry,
<http://www.iana.org/assignments/enterprise-numbers>.

This is great!  The next section of the draft indicates that the IANA
Private Enterprise Number registry is a only a candidate space. My
assumption is that the draft needs to be scrubbed and the "candidate"
remark
removed.

If I interpret the section on ID [Page 13] correctly, an ID is a
globally
unique 64-bit unsigned integer identifier that is encoded with an 8
digit
ESPP client identifier and a 12 digit object identifier that is unique
to
that ESPP client.  Additionally, the ESPP client identifier is further
broken down into a  1-6 digit Enterprise ID (EID) followed by a 2 digit
client suffix.   In earlier PacketCable revisions of the document, the
ID
was simply a sequence number that was relative to the Enterprise ID.
This
changed along the way to be globally unique identifier that includes the
EID, however, the EID was not removed from the protocol.  What is the
intent
of EID now that the ID encodes the EID, isn't it simply redundant?
Finally,
the I couldn't find an example in the draft where the <oId> and <eId>
exhibited the documented behavior.  For example in figure 12 [Page 25]
the
<oId> and <eId> are:

        <oId>7845601000012345631</oId>
        <eId>76544</eId>

I would expect them to be:

        <oId>7654401000012345631</oId>
        <eId>76544</eId>

Are the examples incorrect and need to be scrubbed, or is my
understanding
broken?

Best Regards,

Bob

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.ietf.org/pipermail/peppermint/attachments/20080313/bda5c91b/a
ttachment.htm 

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

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

End of PEPPERMINT Digest, Vol 9, Issue 17
*****************************************
_______________________________________________
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, 13 Mar 2008 14:33:02 -0400
From: "Cartwright, Kenneth" <[email-masked]>
To: <[email-masked]>
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 9, Issue 17
Sender: [email-masked]

Hi Bob,

Thanks for the feedback.  After re-reading the sections of the document
that your points relate to, I think your question is a good one and the
language in the document on this subject could stand some improvement in
clarity.  But the document and the example that you refer to are
actually correct, although not quite clear.  The lack of clarity can
create confusion between the ClientID portion of the ObjectId property
and the EnterpriseID property.

The ClientID portion of the ObjectID is an identifier that represents
the "operational entity/source" responsible of the object in question
(iow, the specific ESPP client) with the goal of creating uniqueness of
the ObjectID property.  This ClientID leverages the IANA Enterprise ID
as the source of unique client IDs (which is then suffixed with a 2
digit identifier to allow for the occasion where there may be multiple
ESPP clients operated by a single organization).

The EnterpriseID property, on the other hand, is an identifier that
represents the "business entity/source" that is responsible for the
object in question.  The Enterprise ID also leverages the IANA
Enterprise ID as the source of unique identifiers.

So, based on the above, it may hopefully be clear now why these two
values are different in the example you refer to.  ....taken an action
to improve the language in the document.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Thursday, March 13, 2008 12:50 PM
To: [email-masked]
Subject: PEPPERMINT Digest, Vol 9, Issue 17

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.  ESPP Enterprise and Object IDs (Robert H. Walter)

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

Message: 1
Date: Thu, 13 Mar 2008 12:47:15 -0400
From: "Robert H. Walter" <[email-masked]>
Subject: [PEPPERMINT] ESPP Enterprise and Object IDs
To: "Peppermint" <[email-masked]>
Message-ID: <00b901c88529$e4b1ccb0$ae156610$@com>
Content-Type: text/plain; charset="us-ascii"

Hello,

This email discusses the topic of ESPP Enterprise and Object
Identifiers.
The I-D draft-mule-peppermint-espp-protocol-01.txt states in section 4.1
the
following:

   The globally unique name space for the assignment of an Enterprise ID
is
the

   open IANA Private Enterprise Number registry,
<http://www.iana.org/assignments/enterprise-numbers>.

This is great!  The next section of the draft indicates that the IANA
Private Enterprise Number registry is a only a candidate space. My
assumption is that the draft needs to be scrubbed and the "candidate"
remark
removed.

If I interpret the section on ID [Page 13] correctly, an ID is a
globally
unique 64-bit unsigned integer identifier that is encoded with an 8
digit
ESPP client identifier and a 12 digit object identifier that is unique
to
that ESPP client.  Additionally, the ESPP client identifier is further
broken down into a  1-6 digit Enterprise ID (EID) followed by a 2 digit
client suffix.   In earlier PacketCable revisions of the document, the
ID
was simply a sequence number that was relative to the Enterprise ID.
This
changed along the way to be globally unique identifier that includes the
EID, however, the EID was not removed from the protocol.  What is the
intent
of EID now that the ID encodes the EID, isn't it simply redundant?
Finally,
the I couldn't find an example in the draft where the <oId> and <eId>
exhibited the documented behavior.  For example in figure 12 [Page 25]
the
<oId> and <eId> are:

        <oId>7845601000012345631</oId>
        <eId>76544</eId>

I would expect them to be:

        <oId>7654401000012345631</oId>
        <eId>76544</eId>

Are the examples incorrect and need to be scrubbed, or is my
understanding
broken?

Best Regards,

Bob

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.ietf.org/pipermail/peppermint/attachments/20080313/bda5c91b/a
ttachment.htm 

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

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

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

From: "Robert H. Walter" <[email-masked]>
To: "Peppermint" <[email-masked]>
Date: Thu, 13 Mar 2008 12:47:15 -0400
Subject: [PEPPERMINT] ESPP Enterprise and Object IDs
Sender: [email-masked]

This is a multipart message in MIME format.

--===============0457511316==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00BA_01C88508.5DA02CB0"
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_00BA_01C88508.5DA02CB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello,

This email discusses the topic of ESPP Enterprise and Object Identifiers.
The I-D draft-mule-peppermint-espp-protocol-01.txt states in section 4.1 the
following:

   The globally unique name space for the assignment of an Enterprise ID is
the

   open IANA Private Enterprise Number registry,
<http://www.iana.org/assignments/enterprise-numbers>.

This is great!  The next section of the draft indicates that the IANA
Private Enterprise Number registry is a only a candidate space. My
assumption is that the draft needs to be scrubbed and the "candidate" remark
removed.

If I interpret the section on ID [Page 13] correctly, an ID is a globally
unique 64-bit unsigned integer identifier that is encoded with an 8 digit
ESPP client identifier and a 12 digit object identifier that is unique to
that ESPP client.  Additionally, the ESPP client identifier is further
broken down into a  1-6 digit Enterprise ID (EID) followed by a 2 digit
client suffix.   In earlier PacketCable revisions of the document, the ID
was simply a sequence number that was relative to the Enterprise ID.  This
changed along the way to be globally unique identifier that includes the
EID, however, the EID was not removed from the protocol.  What is the intent
of EID now that the ID encodes the EID, isn't it simply redundant?  Finally,
the I couldn't find an example in the draft where the <oId> and <eId>
exhibited the documented behavior.  For example in figure 12 [Page 25] the
<oId> and <eId> are:

        <oId>7845601000012345631</oId>
        <eId>76544</eId>

I would expect them to be:

        <oId>7654401000012345631</oId>
        <eId>76544</eId>

Are the examples incorrect and need to be scrubbed, or is my understanding
broken?

Best Regards,

Bob

------=_NextPart_000_00BA_01C88508.5DA02CB0
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=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<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;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-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;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;}
@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>Hello,<o:p></o:p></p>

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

<p class=3DMsoNormal>This email discusses the topic of ESPP Enterprise =
and Object
Identifiers.&nbsp; The I-D draft-mule-peppermint-espp-protocol-01.txt =
states in
section 4.1 the following:<o:p></o:p></p>

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

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
The globally unique name space for the assignment of an Enterprise ID is =
the<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;
&nbsp;open IANA Private Enterprise Number registry, =
&lt;http://www.iana.org/assignments/enterprise-numbers&gt;.<o:p></o:p></s=
pan></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Times =
New Roman","serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal>This is great!&nbsp; The next section of the draft =
indicates
that the IANA Private Enterprise Number registry is a only a candidate =
space.
My assumption is that the draft needs to be scrubbed and the =
&#8220;candidate&#8221;
remark removed.<o:p></o:p></p>

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

<p class=3DMsoNormal>If I interpret the section on ID [Page 13] =
correctly, an ID
is a globally unique 64-bit unsigned integer identifier that is encoded =
with an
8 digit ESPP client identifier and a 12 digit object identifier that is =
unique
to that ESPP client.&nbsp; Additionally, the ESPP client identifier is =
further
broken down into a &nbsp;1-6 digit Enterprise ID (EID) followed by a 2 =
digit client
suffix. &nbsp;&nbsp;In earlier PacketCable revisions of the document, =
the ID
was simply a sequence number that was relative to the Enterprise =
ID.&nbsp; This
changed along the way to be globally unique identifier that includes the =
EID,
however, the EID was not removed from the protocol.&nbsp; What is the =
intent of
EID now that the ID encodes the EID, isn&#8217;t it simply =
redundant?&nbsp;
Finally, the I couldn&#8217;t find an example in the draft where the =
&lt;oId&gt;
and &lt;eId&gt; exhibited the documented behavior.&nbsp; For example in =
figure
12 [Page 25] the &lt;oId&gt; and &lt;eId&gt; are:<o:p></o:p></p>

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

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;oId&gt;7845601000012345631&lt;/oId&gt;<o:p></o:p></pre><pre>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;eId&gt;76544&lt;/eId&gt;<o:p></o:p></pre>

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

<p class=3DMsoNormal>I would expect them to be:<o:p></o:p></p>

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

<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;oId&gt;7654401000012345631&lt;/oId&gt;<o:p></o:p></pre><pre>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;eId&gt;76544&lt;/eId&gt;<o:p></o:p></pre>

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

<p class=3DMsoNormal>Are the examples incorrect and need to be scrubbed, =
or is my
understanding broken?<o:p></o:p></p>

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

<p class=3DMsoNormal>Best Regards,<o:p></o:p></p>

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

<p class=3DMsoNormal>Bob<o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_00BA_01C88508.5DA02CB0--

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

--===============0457511316==--

Date: Wed, 12 Mar 2008 20:14:21 +0100
From: Otmar Lendl <[email-masked]>
To: Richard Shockey <[email-masked]>
Cc: [email-masked]
Subject: Re: [PEPPERMINT] FINAL AGENDA
Sender: [email-masked]

Richard Shockey wrote:
> Presentation of the proposed charter.  <Shockey> 10 min ( see below ) 

Isn't that the main focus of the BoF?

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

Are we going to do provisioning and/or routing?

Is there even a sharp line between these two terms?

> Data exchanges to facilitate session-based Multimedia Interconnection are
> typically between various Client User Agents and Registries or bilateral or
> multilateral Registry to Registry.  

IMHO we should never ever consider data from user agents in peppermint.

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

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

From: "Robert H. Walter" <[email-masked]>
To: "Peppermint" <[email-masked]>
Date: Wed, 12 Mar 2008 15:02:08 -0400
Subject: [PEPPERMINT] Public Identity, TNRange and LRN Objects Amoungts other things...
Sender: [email-masked]

I have many questions/comments regarding the ESPP draft documents,
consequently, I will start with just a few of the simple ones and spread
them topically over a series of threads.  The first line of
questions/comments will deal with Public Identity, TNRange and LRN Objects

The introduction of draft-mule-peppermint-espp-protocol-01.txt states that: 

   An ENUM-SIP addressing server is a session routing server which
   resolves telephone numbers or any type of public user addresses into
   routable Uniform Resource Identifiers (URIs) based on various rules
   and routing logic. [Page 2]

The phrase "any type of public user addresses" feels ambiguous.  I see the
correlation to Public Identity in that its description states:

   A Public Identity may be a telephone number, an email address, or
   other identity as deemed appropriate.

There is no correlation for TNRange or LRN.  It's not clear how an ENUM-SIP
addressing server will resolve an email address or other arbitrary identity
that is not a telephone number to a set of URI's.  What is the intent here?
Is it acceptable for the ESPP server to simply refuse to process a public
identity if it contains an identity that is not deemed appropriate by the
ENUM-SIP addressing server?  If so, what is the appropriate protocol
response?

Interestingly enough, the logical structure diagram appears to have been
updated from an earlier PacketCable version to constrain the public identity
to an LRN, though the XML object structure defines a "PubId" attribute as an
arbitrary string of unspecified length.  Am I interpreting this correctly?
In the context of ESPP, I recommend that a public identity be constrained to
a telephone number, not over-constrained to a 10-digit LRN or
under-constrained to an ambiguous public user address of unspecified length.
For example:

   A Public Identity is uniquely identified by a telephone number
   consisting of 1-31 hexadecimal (0-9, A-F) digits.

What happens when two public identities have different eid/oid, but the same
pubId value?  Doesn't the  pubId (i.e. telephone number) attribute need to
be unique?

Is the intent of the TNRange object to allow for arbitrary number ranges?
For example 9788482830 - 9788482832 represent a range of three national
telephone numbers.  I ask this question because it places a potentially
significant burden on the ESPP server implementation to expand the number
ranges into individual telephone numbers.  I recommend ESPP define number
blocks instead of arbitrary ranges.  Use of wildcard (best match) algorithms
within the ENUM-SIP Addressing server eliminate the requirement to expand
the blocks.

Finally, the draft defines an LRN as the following:

   A 10-digit number that identifies the switching port for a local
   telephone exchange.  LRN is used to support Local Number
   Portability in North America.  An LRN is associated with a Service
   Area.  [Page 12]

This object is specifically associated with the US and Canadian national
number portability implementation.  I believe ESPP would be better served by
defining a Routing Number (prefix)?  In North America, the routing number
would represent an NPA-NXX office code.  There is little or no need to bring
North American implementation semantics into the specification.

If ESPP uses conventional number blocks verses arbitrary number ranges, I
would argue, that the TNRange and LRN objects may be subsumed into a single
RN object.

This brings up the issue of national verses international numbering plans.
The specification appears to intermix national verses international
numbering without providing any context of when a public identity or TNRange
is national or international.  It feels like the specification is missing an
important contextual element with regards to national verses international
numbering.  Please advise on how I should be thinking about this issue.

Regards,

Bob Walter
NetNumber, Inc.
+1-978-848-2831

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

From: David Schwartz <[email-masked]>
To: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Wed, 12 Mar 2008 14:11:41 -0400
Cc: [email-masked]
Subject: Re: [PEPPERMINT] re draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00
Sender: [email-masked]

--===============1965052701==
Content-Type: multipart/alternative; boundary=Apple-Mail-1--594964955

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

Hi Penn

I do not want to get bogged down just yet with the "ownership" issue  
(a.k.a the e164 issue being debated elsewhere). I think its fair to  
assume that the outcome of that discussion will have consequences here.

As for the fee structure, even in the bilateral scenario you describe  
(which I agree with by the way) you may still want to differentiate  
"free" from "transit".

Thanks for the comments,

D.

On Mar 11, 2008, at 9:46 PM, PFAUTZ, PENN L, ATTCORP wrote:

> I have a little trouble parsing the following in Section 3.2:
>
> In complex cases, several VSPs may claim some form of responsibility
>    for the same prefix.  We can use the term "last hop" VSP to  
> describe
>    the VSP closest to the end-user of a phone number.  The provider  
> who
>    was assigned a prefix by the national numbering authority is the
>    "first hop" VSP.  The first hop VSP may have no way of knowing if  
> the
>    last hop VSP will include itself in the registry.
>
> This wouldn't seem to make sense in a number portability environment  
> that uses all call query (e.g., the US) where the prefix may be
> routed (I won't say owned) by one VSP but ported out numbers route  
> directly to the serving VSP.
>
> Probably some formal indication of carrier-or-record status for a  
> number is needed if the registry is going to allow others entities  
> beyond the COR to provision records.
>
> Likewise, I have concerns about the fee category construct. While  
> this might be uniformly defined in the PSTN space I believe this may  
> move toward bilateral agreements in the NGN space.
>
> Penn Pfautz
>
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/peppermint

--Apple-Mail-1--594964955
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =
style=3D"font-size: 13px; ">Hi Penn</span><div><font =
class=3D"Apple-style-span" size=3D"3"><span class=3D"Apple-style-span" =
style=3D"font-size: 13px;"><br =
class=3D"webkit-block-placeholder"></span></font></div><div><font =
class=3D"Apple-style-span" size=3D"3"><span class=3D"Apple-style-span" =
style=3D"font-size: 13px;">I do not want to get bogged down just yet =
with the "ownership" issue (a.k.a the e164 issue being debated =
elsewhere). I think its fair to assume that the outcome of that =
discussion will have consequences here.</span></font></div><div><font =
class=3D"Apple-style-span" size=3D"3"><span class=3D"Apple-style-span" =
style=3D"font-size: 13px;"><br =
class=3D"webkit-block-placeholder"></span></font></div><div><font =
class=3D"Apple-style-span" size=3D"3"><span class=3D"Apple-style-span" =
style=3D"font-size: 13px;">As for the fee structure, even in the =
bilateral scenario you describe (which I agree with by the way) you may =
still want to differentiate "free" from =
"transit".</span></font></div><div><font class=3D"Apple-style-span" =
size=3D"3"><span class=3D"Apple-style-span" style=3D"font-size: =
13px;"><br =
class=3D"webkit-block-placeholder"></span></font></div><div><font =
class=3D"Apple-style-span" size=3D"3"><span class=3D"Apple-style-span" =
style=3D"font-size: 13px;">Thanks for the =
comments,</span></font></div><div><font class=3D"Apple-style-span" =
size=3D"3"><span class=3D"Apple-style-span" style=3D"font-size: =
13px;"><br =
class=3D"webkit-block-placeholder"></span></font></div><div><font =
class=3D"Apple-style-span" size=3D"3"><span class=3D"Apple-style-span" =
style=3D"font-size: 13px;">D.</span></font></div><div><font =
class=3D"Apple-style-span" size=3D"3"><span class=3D"Apple-style-span" =
style=3D"font-size: 13px;"><br =
class=3D"webkit-block-placeholder"></span></font></div><div><div><div>On =
Mar 11, 2008, at 9:46 PM, PFAUTZ, PENN L, ATTCORP wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"> <div> =
<div><font face=3D"Arial" size=3D"2"><span class=3D"624252901-12032008">I =
have a little trouble parsing the following in Section =
3.2:</span></font></div> <div>&nbsp;</div> <div><font face=3D"Arial" =
size=3D"2">In complex cases, several VSPs may claim some form of =
responsibility<br>&nbsp;&nbsp; for the same prefix.&nbsp; We can use the =
term "last hop" VSP to describe<br>&nbsp;&nbsp; the VSP closest to the =
end-user of a phone number.&nbsp; The provider who<br>&nbsp;&nbsp; was =
assigned a prefix by the national numbering authority is =
the<br>&nbsp;&nbsp; "first hop" VSP.&nbsp; The first hop VSP may have no =
way of knowing if the<br>&nbsp;&nbsp; last hop VSP will include itself =
in the registry.</font></div> <div><font face=3D"Arial" =
size=3D"2"></font>&nbsp;</div> <div><font face=3D"Arial" size=3D"2"><span =
class=3D"624252901-12032008">This wouldn't seem to make sense in a =
number portability environment that uses all call query (e.g., the US) =
where the prefix may be</span></font></div> <div><font face=3D"Arial" =
size=3D"2"><span class=3D"624252901-12032008">routed (I won't say =
owned)&nbsp;by one VSP but ported out numbers route directly to the =
serving VSP.</span></font></div> <div><font face=3D"Arial" =
size=3D"2"><span class=3D"624252901-12032008"></span></font>&nbsp;</div> =
<div><font face=3D"Arial" size=3D"2"><span =
class=3D"624252901-12032008">Probably some formal indication of =
carrier-or-record status for a number is needed if the registry is going =
to allow others entities beyond the COR to provision =
records.</span></font></div> <div><font face=3D"Arial" size=3D"2"><span =
class=3D"624252901-12032008"></span></font>&nbsp;</div> <div><font =
face=3D"Arial" size=3D"2"><span =
class=3D"624252901-12032008">Likewise,&nbsp;I have concerns about the =
fee category construct. While this might be uniformly defined in the =
PSTN space&nbsp;I believe this may move toward bilateral agreements in =
the NGN space. </span></font></div> <div><font face=3D"Arial" =
size=3D"2"><span class=3D"624252901-12032008"></span></font>&nbsp;</div> =
<div align=3D"left"><font face=3D"Arial" size=3D"2">Penn =
Pfautz</font></div> <div><font face=3D"Arial" =
size=3D"2"></font>&nbsp;</div></div> =
_______________________________________________<br>PEPPERMINT mailing =
list<br><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>https://www=
.ietf.org/mailman/listinfo/peppermint<br></blockquote></div><br></div></bo=
dy></html>=

--Apple-Mail-1--594964955--

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

--===============1965052701==--

From: "Richard Shockey" <[email-masked]>
To: "'David Schwartz'" <[email-masked]>
Date: Wed, 12 Mar 2008 12:22:31 -0400
Cc: [email-masked]
Subject: Re: [PEPPERMINT] Proposed Charter Wording
Sender: [email-masked]

This is a multipart message in MIME format.

--===============0528807917==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0C4C_01C8843B.BF88F560"
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_0C4C_01C8843B.BF88F560
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Well that is certainly something to review this afternoon. Scope will be the
key issue the IESG looks at when evaluating whether or not to grant a
charter.

But we should all remember what the task this afternoon really is ..to
demonstrate that 

A. There is a problem that needs to be fixed 

B. The problem is within the scope of the IETF and CAN be fixed.

C. There is a sufficient number of people ready willing and able to fix the
problem ( within a reasonable time frame)

From: David Schwartz [mailto:[email-masked]] 
Sent: Wednesday, March 12, 2008 7:22 AM
To: [email-masked]
Cc: [email-masked]
Subject: Proposed Charter Wording

 

I know that we are trying to form consensus but as I was putting together my
slides I kept on crashing into the words "among administrative domains" and
recalling Hadriels comments in Vancouver regarding the difference between
"within" and "among".

I think it is important that this issue be debated today and put to rest
once and for all or it will come back to bite us in the future.

I am proposing to mention them both as follows (even if we first tackle the
"within") ...

"The PEPPERMINT working group is charted to define what data needs to be
exchanged within and among Multimedia administrative domains (outside the
normal scope of establishing various forms of a SIP session) and how that
data should be structured provisioned and propagated."

Any thoughts?

D. 

------=_NextPart_000_0C4C_01C8843B.BF88F560
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>Proposed Charter Wording</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'>Well that is certainly something to review this =
afternoon. Scope
will be the key issue the IESG looks at when evaluating whether or not =
to grant
a charter.<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'>But we should all remember what the task this afternoon =
really
is ..to demonstrate that <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'>A. There is a problem that needs to be fixed =
<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'>B. The problem is within the scope of the IETF and CAN be =
fixed.<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'>C. There is a sufficient number of people ready willing =
and able
to fix the problem ( within a reasonable time =
frame)<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>

<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"'> David =
Schwartz
[mailto:[email-masked]] <br>
<b>Sent:</b> Wednesday, March 12, 2008 7:22 AM<br>
<b>To:</b> [email-masked]<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> Proposed Charter Wording<o:p></o:p></span></p>

</div>

</div>

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

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

<p><span style=3D'font-size:10.0pt'>I know that we are trying to form =
consensus
but as I was putting together my slides I kept on crashing into the =
words
&quot;among administrative domains&quot; and recalling Hadriels comments =
in
Vancouver regarding the difference between &quot;within&quot; and
&quot;among&quot;.<br>
<br>
I think it is important that this issue be debated today and put to rest =
once
and for all or it will come back to bite us in the future.<br>
<br>
I am proposing to mention them both as follows (even if we first tackle =
the
&quot;within&quot;) ...<br>
<br>
&quot;The PEPPERMINT working group is charted to define what data needs =
to be
exchanged within and among Multimedia administrative domains (outside =
the
normal scope of establishing various forms of a SIP session) and how =
that data
should be structured provisioned and propagated.&quot;<br>
<br>
Any thoughts?<br>
<br>
D.</span> <o:p></o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_0C4C_01C8843B.BF88F560--

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

--===============0528807917==--

Content-class: urn:content-classes:message
Date: Tue, 11 Mar 2008 21:46:36 -0400
From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
To: <[email-masked]>
Subject: [PEPPERMINT] re draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00
Sender: [email-masked]

This is a multi-part message in MIME format.

--===============0566699030==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C883E2.E91E4209"

This is a multi-part message in MIME format.

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

I have a little trouble parsing the following in Section 3.2:
=20
In complex cases, several VSPs may claim some form of responsibility
   for the same prefix.  We can use the term "last hop" VSP to describe
   the VSP closest to the end-user of a phone number.  The provider who
   was assigned a prefix by the national numbering authority is the
   "first hop" VSP.  The first hop VSP may have no way of knowing if the
   last hop VSP will include itself in the registry.
=20
This wouldn't seem to make sense in a number portability environment
that uses all call query (e.g., the US) where the prefix may be
routed (I won't say owned) by one VSP but ported out numbers route
directly to the serving VSP.
=20
Probably some formal indication of carrier-or-record status for a number
is needed if the registry is going to allow others entities beyond the
COR to provision records.
=20
Likewise, I have concerns about the fee category construct. While this
might be uniformly defined in the PSTN space I believe this may move
toward bilateral agreements in the NGN space.=20
=20
Penn Pfautz
=20

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3268" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D624252901-12032008>I have =
a little=20
trouble parsing the following in Section 3.2:</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In complex cases, several VSPs may =
claim some form=20
of responsibility<BR>&nbsp;&nbsp; for the same prefix.&nbsp; We can use =
the term=20
"last hop" VSP to describe<BR>&nbsp;&nbsp; the VSP closest to the =
end-user of a=20
phone number.&nbsp; The provider who<BR>&nbsp;&nbsp; was assigned a =
prefix by=20
the national numbering authority is the<BR>&nbsp;&nbsp; "first hop" =
VSP.&nbsp;=20
The first hop VSP may have no way of knowing if the<BR>&nbsp;&nbsp; last =
hop VSP=20
will include itself in the registry.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D624252901-12032008>This =
wouldn't seem=20
to make sense in a number portability environment that uses all call =
query=20
(e.g., the US) where the prefix may be</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D624252901-12032008>routed =
(I won't say=20
owned)&nbsp;by one VSP but ported out numbers route directly to the =
serving=20
VSP.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D624252901-12032008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D624252901-12032008>Probably some formal=20
indication of carrier-or-record status for a number is needed if the =
registry is=20
going to allow others entities beyond the COR to provision=20
records.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D624252901-12032008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D624252901-12032008>Likewise,&nbsp;I=20
have concerns about the fee category construct. While this might be =
uniformly=20
defined in the PSTN space&nbsp;I believe this may move toward bilateral=20
agreements in the NGN space. </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D624252901-12032008></SPAN></FONT>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Penn Pfautz</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C883E2.E91E4209--

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

--===============0566699030==--

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Wed, 12 Mar 2008 11:33:45 -0400
Subject: [PEPPERMINT] Meeting Materials
Sender: [email-masked]

https://datatracker.ietf.org/meeting/71/materials.html

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: Wed, 12 Mar 2008 07:52:24 -0600
From: "Jean-Francois Mule" <[email-masked]>
To: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] ESPP drafts
Sender: [email-masked]

Penn,

   Thank you for your comments.

   First let me say that these drafts are provided as an input to a BOF to =
show a real need and an example of how a few folks viewed the provisioning =
data problem for a particular entity (addressing/routing server).  It is pr=
ovided to help clarify the scope/charter items.
  =

   Some of your concerns are shared and this is why the data model allows f=
or number ranges, individual TNs and any type of URI really (under "public =
identity").  That said, to get this data model to meet the requirements tha=
t some telephony groups have within SIP service providers in North America =
(inside and outside cable really), LRNs were added into the mix during the =
intermediary phase of moving away from PSTN-like management.

   More inline.

Jean-Francois.

> -----Original Message-----
> From: [email-masked] [mailto:peppermint-
> [email-masked]] On Behalf Of PFAUTZ, PENN L, ATTCORP
> Sent: Wednesday, March 12, 2008 7:29 AM
> To: [email-masked]
> Subject: [PEPPERMINT] ESPP drafts
> =

> Some high level comments on the ESPP drafts ( draft-mule-
> peppermint-espp-requirements-00.txt and draft-mule-peppermint-espp-
> protocol-01.txt)
> =

> I was a little surprised to see the focus on=A0 central office code-
> based routing. While I understand this is the current basis of PSTN
> number allocation and routing, I'm concerned about an approach that
> perpetuates the code nexus. (E.164 I like, but the exchange code
> arrangement creates a host of problems we should be trying to move
> away from.) One of the good things about ENUM is the potential to
> free us from these limitations while allowing us to make use of the
> good parts of E.164 numbering.
Point taken.
I would note that the other draft presented today from David, Rohan, Alan a=
nd Ed also very e.164 centric.  The data model added LRNs because we had a =
requirement from folks handling sip call routing to the PSTN that we should=
 accommodate the way they do things with LRNs today.  Not visionary but jus=
t reality. =

 =

> A=A0couple of=A0nits re the use of LRNs as long as you're going down
> the code routing path: first,=A0LRN is North American specific;
> second you could just refer to the code prefix which would be more
> general since=A0an LRN by definition uses an NPA-NXX code for which
> the LRN assignee is the code holder in the LERG. In LRN-based
> routing only the terminating switch cases about the XXXX portion of
> the LRN.
Yes

 =

> I appreciate the attempt to deal with the data volume issues
> represented by NAPTRs for each TN, but I have reservations about
> the particular solution path. Perhaps a non-NAPTR URI record as
> proposed by Patrik Faltstrom might be=A0 worth some consideration.
Yes.  We just tried to deal with what was available today.

> There are at least two flies in the ointment of number aggregation:
> number portability and the possibility that different numbers in a
> range served by the same service provider might have different
> characteristics that require different treatment.
> In the US, for example, some carriers have more than one type of
> network/service offer, e.g. wireless, TDM wireline, VoIP. These may
> be served out of the same pool of numbers given numbering
> resource=A0optimization regulations and cross-modal portability.
> =

> 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: Wed, 12 Mar 2008 09:28:56 -0400
From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
To: <[email-masked]>
Subject: [PEPPERMINT] ESPP drafts
Sender: [email-masked]

This is a multi-part message in MIME format.

--===============0563844982==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C88445.063ED7FC"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C88445.063ED7FC
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Some high level comments on the ESPP drafts (
draft-mule-peppermint-espp-requirements-00.txt and
draft-mule-peppermint-espp-protocol-01.txt)

=20
I was a little surprised to see the focus on  central office code-based
routing. While I understand this is the current basis of PSTN number
allocation and routing, I'm concerned about an approach that perpetuates
the code nexus. (E.164 I like, but the exchange code arrangement creates
a host of problems we should be trying to move away from.) One of the
good things about ENUM is the potential to free us from these
limitations while allowing us to make use of the good parts of E.164
numbering.
=20
A couple of nits re the use of LRNs as long as you're going down the
code routing path: first, LRN is North American specific; second you
could just refer to the code prefix which would be more general since an
LRN by definition uses an NPA-NXX code for which the LRN assignee is the
code holder in the LERG. In LRN-based routing only the terminating
switch cases about the XXXX portion of the LRN.
=20
I appreciate the attempt to deal with the data volume issues represented
by NAPTRs for each TN, but I have reservations about the particular
solution path. Perhaps a non-NAPTR URI record as proposed by Patrik
Faltstrom might be  worth some consideration. There are at least two
flies in the ointment of number aggregation: number portability and the
possibility that different numbers in a range served by the same service
provider might have different characteristics that require different
treatment.
In the US, for example, some carriers have more than one type of
network/service offer, e.g. wireless, TDM wireline, VoIP. These may be
served out of the same pool of numbers given numbering resource
optimization regulations and cross-modal portability.=20

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

------_=_NextPart_001_01C88445.063ED7FC
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3268" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D049080513-12032008>Some =
high level=20
comments on the ESPP drafts (=20
</SPAN></FONT>draft-mule-peppermint-espp-requirements-00.txt<SPAN=20
class=3D049080513-12032008> and=20
draft-mule-peppermint-espp-protocol-01.txt)<BR></SPAN></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D049080513-12032008></SPAN></FONT></FONT><FONT face=3DArial=20
size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D049080513-12032008><FONT face=3DArial size=3D2>I was =
a little=20
surprised to see the focus on&nbsp; central office code-based routing. =
While I=20
understand this is the current basis of PSTN number allocation and =
routing, I'm=20
concerned about an approach that perpetuates the code nexus. (E.164 I =
like, but=20
the exchange code arrangement creates a host of problems we should be =
trying to=20
move away from.) One of the good things about ENUM is the potential to =
free us=20
from these limitations while allowing us to make use of the good parts =
of E.164=20
numbering.</FONT></SPAN></DIV>
<DIV><SPAN class=3D049080513-12032008><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D049080513-12032008><FONT face=3DArial =
size=3D2>A&nbsp;couple=20
of&nbsp;nits re the use of LRNs as long as you're going down the code =
routing=20
path: first,&nbsp;LRN is North American specific; second you could just =
refer to=20
the code prefix which would be more general since&nbsp;an LRN by =
definition uses=20
an NPA-NXX code for which the LRN assignee is the code holder in the =
LERG. In=20
LRN-based routing only the terminating switch cases about the XXXX =
portion of=20
the LRN.</FONT></SPAN></DIV>
<DIV><SPAN class=3D049080513-12032008><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D049080513-12032008><FONT face=3DArial size=3D2>I =
appreciate the=20
attempt to deal with the data volume issues represented by NAPTRs for =
each TN,=20
but I have reservations about the particular solution path. Perhaps a =
non-NAPTR=20
URI record as proposed by Patrik Faltstrom might be&nbsp; worth some=20
consideration. There are at least two flies in the ointment of number=20
aggregation: number portability and the possibility that different =
numbers in a=20
range served by the same service provider might have different =
characteristics=20
that require different treatment.</FONT></SPAN></DIV>
<DIV><SPAN class=3D049080513-12032008><FONT face=3DArial size=3D2>In the =
US, for=20
example, some carriers have more than one type of network/service offer, =
e.g.=20
wireless, TDM wireline, VoIP. These may be served out of the same pool =
of=20
numbers given numbering resource&nbsp;optimization regulations and =
cross-modal=20
portability. </FONT></SPAN></DIV>
<DIV><BR></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Penn Pfautz</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>AT&amp;T National Access=20
Management</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial =
size=3D2>+1-732-420-4962</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C88445.063ED7FC--

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

--===============0563844982==--

Content-class: urn:content-classes:message
Date: Wed, 12 Mar 2008 11:22:28 -0000
From: "David Schwartz" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: [PEPPERMINT] Proposed Charter Wording
Sender: [email-masked]

This is a multi-part message in MIME format.

--===============1269390349==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C88433.5B279AA9"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C88433.5B279AA9
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I know that we are trying to form consensus but as I was putting =
together my slides I kept on crashing into the words "among =
administrative domains" and recalling Hadriels comments in Vancouver =
regarding the difference between "within" and "among".

I think it is important that this issue be debated today and put to rest =
once and for all or it will come back to bite us in the future.

I am proposing to mention them both as follows (even if we first tackle =
the "within") ...

"The PEPPERMINT working group is charted to define what data needs to be =
exchanged within and among Multimedia administrative domains (outside =
the normal scope of establishing various forms of a SIP session) and how =
that data should be structured provisioned and propagated."

Any thoughts?

D.

------_=_NextPart_001_01C88433.5B279AA9
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7638.1">
<TITLE>Proposed Charter Wording</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>I know that we are trying to form consensus but as I =
was putting together my slides I kept on crashing into the words =
&quot;among administrative domains&quot; and recalling Hadriels comments =
in Vancouver regarding the difference between &quot;within&quot; and =
&quot;among&quot;.<BR>
<BR>
I think it is important that this issue be debated today and put to rest =
once and for all or it will come back to bite us in the future.<BR>
<BR>
I am proposing to mention them both as follows (even if we first tackle =
the &quot;within&quot;) ...<BR>
<BR>
&quot;The PEPPERMINT working group is charted to define what data needs =
to be exchanged within and among Multimedia administrative domains =
(outside the normal scope of establishing various forms of a SIP =
session) and how that data should be structured provisioned and =
propagated.&quot;<BR>
<BR>
Any thoughts?<BR>
<BR>
D.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C88433.5B279AA9--

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

--===============1269390349==--

Content-class: urn:content-classes:message
Date: Wed, 12 Mar 2008 09:28:44 -0000
From: "David Schwartz" <[email-masked]>
To: <[email-masked]>
Subject: [PEPPERMINT] draft-schwartz-peppermint-problem-statement-01
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C88423.899EA377
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C88423.899EA377"

------_=_NextPart_002_01C88423.899EA377
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

I wanted to incorporate some of the comments that I received on this =
prior to discussions today so I generated an 01 version and am sending =
via email (I will publish on publicly reachable web site later on today =
as well).

Since it is so close to the meeting I figured I would highlight =
changes...

Section 3.1 added a 3rd paragraph
Section 3.2 changes to 1st and 5th paragraphs
Section 4 changes to paragraph 2
Section 5 changes to "port-out" and "renumber" definitions
Section 10 changes to paragraph 3

D.

------_=_NextPart_002_01C88423.899EA377
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7638.1">
<TITLE>draft-schwartz-peppermint-problem-statement-01</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>Hi<BR>
<BR>
I wanted to incorporate some of the comments that I received on this =
prior to discussions today so I generated an 01 version and am sending =
via email (I will publish on publicly reachable web site later on today =
as well).<BR>
<BR>
Since it is so close to the meeting I figured I would highlight =
changes...<BR>
<BR>
Section 3.1 added a 3rd paragraph<BR>
Section 3.2 changes to 1st and 5th paragraphs<BR>
Section 4 changes to paragraph 2<BR>
Section 5 changes to &quot;port-out&quot; and &quot;renumber&quot; =
definitions<BR>
Section 10 changes to paragraph 3<BR>
<BR>
D.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_002_01C88423.899EA377--

------_=_NextPart_001_01C88423.899EA377
Content-Type: text/plain;
	name="consolidated-provisioning-v1.txt"
Content-Transfer-Encoding: base64
Content-Description: consolidated-provisioning-v1.txt
Content-Disposition: attachment;
	filename="consolidated-provisioning-v1.txt"

------_=_NextPart_001_01C88423.899EA377
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

------_=_NextPart_001_01C88423.899EA377--

Content-class: urn:content-classes:message
Date: Wed, 12 Mar 2008 07:26:32 -0000
From: "David Schwartz" <[email-masked]>
To: "Otmar Lendl" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] some comments onconsolidated-provisioning-problem-statement-00
Sender: [email-masked]

This is a multi-part message in MIME format.

--===============0785606631==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C88412.8F67892E"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C88412.8F67892E
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Otmar.

Thanks for the input and nice catch with the 3XX redirect responses.

D.

-----Original Message-----
From: [email-masked] on behalf of Otmar Lendl
Sent: Tue 3/11/2008 10:06 PM
To: [email-masked]
Subject: [PEPPERMINT] some comments =
onconsolidated-provisioning-problem-statement-00
=20

Some quick words on David's draft:

Overall: very good draft. It captures the core concepts we need.

>3.1.  Index/Key Data
>
>   The organization of registry data is based on specific phone numbers
>   or phone number prefixes (which could represent blocks of phone
>   numbers, regions, or theoretically whole countries).  For =
generality,
>   we will use the term prefix to include complete phone numbers as
>   well.=20

Good catch. That makes the data modelling easier and covers both
open and closed numbering plans.

>                             These globally normalized prefixes always
>   begin with a plus (+) and a telephone country code. =20

That's a good idea to make it clear that prefixes are fully qualified.
Maybe tweak the language a bit: "..prefixes are always written with a
leading + to avoid confusions").

>
>3.2.  Resolution Data
>
>   For each prefix, there is a variety of data that can be exchanged.
>   The most important set of data identifies that a specific VSP is
>   responsible for the prefix and in most cases the VSP provides a SIP
>   URI through which this prefix can be reached.

"reached" is maybe too strong. "addressed" might be better.

Perhaps add here a sentence stating that it is _not_ assumed that this
SIP URI is reachable via the public Internet using the RFC3263 process.
Instead, a further routing algorithm might be needed to find a suitable
next hop towards the destination network.

>
>   Like stated in the introduction it is imperative that the minimal =
set
>   of resolution data contain all the information required for a DNS
>   NAPTR RR.
>

I don't quite understand this sentence. Without specifying for which
enum-service you want to construct a NAPTR, it's hard to describe
the minimal set of data needed.

>   Additionally, as a future proofing mechanism it is recommended that
>   resolution data include a catchall (similar to a DNS TXT RR) for =
data
>   that is not currently present in any ENUM service definitions.

I don't quite get it. We have x- enumservices and quite generic
uri-schemes like data:, so we can put anything into NAPTRs.=20
(which prejudices ENUM, which IMHO we shouldn't do at this step)

As we're talking about the provisioning protocol, we just need to make
sure we either can transmit arbitrary attribute/value pairs during the
provisioning step.

>   One final note.  One of the common "rewrite" rules for the URI in
>   NAPTR RRs for example is of the form "\[email-masked]"
>   where the "\1" refers to the telephone number being processed.  This
>   kind of shorthand should be available when processing prefixes in
>   bulk.

"..regardless of whether ENUM will be the query protocol".

>4.  Reachability vs. Routing
>
>   The goal of the registry is to provide sufficient information to
>   identify a responsible VSP for a prefix.  The responsible VSP can
>   provide a SIP URI that can be proxied or redirected as desired by =
the
>   VSP.  It is important to note that the registry is expected to =
return
>   the same responsibility data for all parties that query it.

Nicely put. Good.

>   Routing information is also out of scope of the registry =
provisioning
>   problem.  Once a responsible VSP is contacted, that VSP can use a
>   variety of techniques to route that request. =20

hm. Shouldn't that be "Once the call originating VSP has learned the
identity of the responsible VSP, the O-VSP can use a variety of
techniques to route that request." ?

>
>5.  Operations on the Registry Data
>
>   Delete:  Remove a prefix from the registry.  Semantically it means
>   that the prefix no longer exists anywhere.
>
>   Port-out:  A port-out is similar to a delete, but could be logged
>   differently.  The semantics are that the prefix still exists, but
>   that the previous VSP is no longer responsible for it.

Perhaps note here that one difference between Delete and Port-out is
that in the case of Delete, further request can get matched by
super-prefixes existing in the registry, whereas in the Port-out case
the registry will return "not-found" even if a containing prefix exists.

>9.  Data Propegation

Propagation

>10.  Querying The Registry
>
>
>   When SIP is used for the query mechanism, the numbering registry
>   functions as a SIP redirect proxy [RFC3261] .  The input to this
>   mechanism is a URI or more importantly the UserInfo part of the URI
>   containing the number to be queried.  The response returned by the
>   proxy is either an error code indicating the absence of information
>   about the number queried or a redirect response (3XX) containing 1
>   (or more) Contact Headers representing available routing options.

Whoa, stop here.=20

In 4. you wrote that the registry contains ownership information, not
routing information.

/ol
--=20
// 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

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email=20
______________________________________________________________________

------_=_NextPart_001_01C88412.8F67892E
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7638.1">
<TITLE>RE: [PEPPERMINT] some comments =
onconsolidated-provisioning-problem-statement-00</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi Otmar.<BR>
<BR>
Thanks for the input and nice catch with the 3XX redirect responses.<BR>
<BR>
D.<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of Otmar Lendl<BR>
Sent: Tue 3/11/2008 10:06 PM<BR>
To: [email-masked]<BR>
Subject: [PEPPERMINT] some comments =
onconsolidated-provisioning-problem-statement-00<BR>
<BR>
<BR>
Some quick words on David's draft:<BR>
<BR>
Overall: very good draft. It captures the core concepts we need.<BR>
<BR>
<BR>
&gt;3.1.&nbsp; Index/Key Data<BR>
&gt;<BR>
&gt;&nbsp;&nbsp; The organization of registry data is based on specific =
phone numbers<BR>
&gt;&nbsp;&nbsp; or phone number prefixes (which could represent blocks =
of phone<BR>
&gt;&nbsp;&nbsp; numbers, regions, or theoretically whole =
countries).&nbsp; For generality,<BR>
&gt;&nbsp;&nbsp; we will use the term prefix to include complete phone =
numbers as<BR>
&gt;&nbsp;&nbsp; well.<BR>
<BR>
Good catch. That makes the data modelling easier and covers both<BR>
open and closed numbering plans.<BR>
<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; These globally normalized prefixes always<BR>
&gt;&nbsp;&nbsp; begin with a plus (+) and a telephone country =
code.&nbsp;<BR>
<BR>
That's a good idea to make it clear that prefixes are fully =
qualified.<BR>
Maybe tweak the language a bit: &quot;..prefixes are always written with =
a<BR>
leading + to avoid confusions&quot;).<BR>
<BR>
&gt;<BR>
&gt;3.2.&nbsp; Resolution Data<BR>
&gt;<BR>
&gt;&nbsp;&nbsp; For each prefix, there is a variety of data that can be =
exchanged.<BR>
&gt;&nbsp;&nbsp; The most important set of data identifies that a =
specific VSP is<BR>
&gt;&nbsp;&nbsp; responsible for the prefix and in most cases the VSP =
provides a SIP<BR>
&gt;&nbsp;&nbsp; URI through which this prefix can be reached.<BR>
<BR>
&quot;reached&quot; is maybe too strong. &quot;addressed&quot; might be =
better.<BR>
<BR>
Perhaps add here a sentence stating that it is _not_ assumed that =
this<BR>
SIP URI is reachable via the public Internet using the RFC3263 =
process.<BR>
Instead, a further routing algorithm might be needed to find a =
suitable<BR>
next hop towards the destination network.<BR>
<BR>
&gt;<BR>
&gt;&nbsp;&nbsp; Like stated in the introduction it is imperative that =
the minimal set<BR>
&gt;&nbsp;&nbsp; of resolution data contain all the information required =
for a DNS<BR>
&gt;&nbsp;&nbsp; NAPTR RR.<BR>
&gt;<BR>
<BR>
I don't quite understand this sentence. Without specifying for which<BR>
enum-service you want to construct a NAPTR, it's hard to describe<BR>
the minimal set of data needed.<BR>
<BR>
&gt;&nbsp;&nbsp; Additionally, as a future proofing mechanism it is =
recommended that<BR>
&gt;&nbsp;&nbsp; resolution data include a catchall (similar to a DNS =
TXT RR) for data<BR>
&gt;&nbsp;&nbsp; that is not currently present in any ENUM service =
definitions.<BR>
<BR>
<BR>
I don't quite get it. We have x- enumservices and quite generic<BR>
uri-schemes like data:, so we can put anything into NAPTRs.<BR>
(which prejudices ENUM, which IMHO we shouldn't do at this step)<BR>
<BR>
As we're talking about the provisioning protocol, we just need to =
make<BR>
sure we either can transmit arbitrary attribute/value pairs during =
the<BR>
provisioning step.<BR>
<BR>
&gt;&nbsp;&nbsp; One final note.&nbsp; One of the common =
&quot;rewrite&quot; rules for the URI in<BR>
&gt;&nbsp;&nbsp; NAPTR RRs for example is of the form =
&quot;\[email-masked]&quot;<BR>
&gt;&nbsp;&nbsp; where the &quot;\1&quot; refers to the telephone number =
being processed.&nbsp; This<BR>
&gt;&nbsp;&nbsp; kind of shorthand should be available when processing =
prefixes in<BR>
&gt;&nbsp;&nbsp; bulk.<BR>
<BR>
&quot;..regardless of whether ENUM will be the query protocol&quot;.<BR>
<BR>
&gt;4.&nbsp; Reachability vs. Routing<BR>
&gt;<BR>
&gt;&nbsp;&nbsp; The goal of the registry is to provide sufficient =
information to<BR>
&gt;&nbsp;&nbsp; identify a responsible VSP for a prefix.&nbsp; The =
responsible VSP can<BR>
&gt;&nbsp;&nbsp; provide a SIP URI that can be proxied or redirected as =
desired by the<BR>
&gt;&nbsp;&nbsp; VSP.&nbsp; It is important to note that the registry is =
expected to return<BR>
&gt;&nbsp;&nbsp; the same responsibility data for all parties that query =
it.<BR>
<BR>
Nicely put. Good.<BR>
<BR>
&gt;&nbsp;&nbsp; Routing information is also out of scope of the =
registry provisioning<BR>
&gt;&nbsp;&nbsp; problem.&nbsp; Once a responsible VSP is contacted, =
that VSP can use a<BR>
&gt;&nbsp;&nbsp; variety of techniques to route that request.&nbsp;<BR>
<BR>
hm. Shouldn't that be &quot;Once the call originating VSP has learned =
the<BR>
identity of the responsible VSP, the O-VSP can use a variety of<BR>
techniques to route that request.&quot; ?<BR>
<BR>
&gt;<BR>
&gt;5.&nbsp; Operations on the Registry Data<BR>
&gt;<BR>
&gt;&nbsp;&nbsp; Delete:&nbsp; Remove a prefix from the registry.&nbsp; =
Semantically it means<BR>
&gt;&nbsp;&nbsp; that the prefix no longer exists anywhere.<BR>
&gt;<BR>
&gt;&nbsp;&nbsp; Port-out:&nbsp; A port-out is similar to a delete, but =
could be logged<BR>
&gt;&nbsp;&nbsp; differently.&nbsp; The semantics are that the prefix =
still exists, but<BR>
&gt;&nbsp;&nbsp; that the previous VSP is no longer responsible for =
it.<BR>
<BR>
Perhaps note here that one difference between Delete and Port-out is<BR>
that in the case of Delete, further request can get matched by<BR>
super-prefixes existing in the registry, whereas in the Port-out =
case<BR>
the registry will return &quot;not-found&quot; even if a containing =
prefix exists.<BR>
<BR>
&gt;9.&nbsp; Data Propegation<BR>
<BR>
Propagation<BR>
<BR>
&gt;10.&nbsp; Querying The Registry<BR>
&gt;<BR>
&gt;<BR>
&gt;&nbsp;&nbsp; When SIP is used for the query mechanism, the numbering =
registry<BR>
&gt;&nbsp;&nbsp; functions as a SIP redirect proxy [RFC3261] .&nbsp; The =
input to this<BR>
&gt;&nbsp;&nbsp; mechanism is a URI or more importantly the UserInfo =
part of the URI<BR>
&gt;&nbsp;&nbsp; containing the number to be queried.&nbsp; The response =
returned by the<BR>
&gt;&nbsp;&nbsp; proxy is either an error code indicating the absence of =
information<BR>
&gt;&nbsp;&nbsp; about the number queried or a redirect response (3XX) =
containing 1<BR>
&gt;&nbsp;&nbsp; (or more) Contact Headers representing available =
routing options.<BR>
<BR>
Whoa, stop here.<BR>
<BR>
In 4. you wrote that the registry contains ownership information, =
not<BR>
routing information.<BR>
<BR>
/ol<BR>
--<BR>
// Otmar Lendl &lt;[email-masked]&gt;, T: +43 1 5056416 - 33, F: - 933<BR>
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H<BR>
// <A HREF=3D"http://www.nic.at/">http://www.nic.at/</A>&nbsp; LG =
Salzburg, FN 172568b, Sitz: Salzburg<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>
______________________________________________________________________<BR=
>
This email has been scanned by the MessageLabs Email Security =
System.<BR>
For more information please visit <A =
HREF=3D"http://www.messagelabs.com/email">http://www.messagelabs.com/emai=
l</A><BR>
______________________________________________________________________<BR=
>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C88412.8F67892E--

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

--===============0785606631==--

Date: Tue, 11 Mar 2008 23:06:02 +0100
From: Otmar Lendl <[email-masked]>
To: [email-masked]
Mail-Followup-To: Otmar Lendl <[email-masked]>, [email-masked]
Subject: [PEPPERMINT] some comments on consolidated-provisioning-problem-statement-00
Sender: [email-masked]

Some quick words on David's draft:

Overall: very good draft. It captures the core concepts we need.

>3.1.  Index/Key Data
>
>   The organization of registry data is based on specific phone numbers
>   or phone number prefixes (which could represent blocks of phone
>   numbers, regions, or theoretically whole countries).  For generality,
>   we will use the term prefix to include complete phone numbers as
>   well. 

Good catch. That makes the data modelling easier and covers both
open and closed numbering plans.

>                             These globally normalized prefixes always
>   begin with a plus (+) and a telephone country code.  

That's a good idea to make it clear that prefixes are fully qualified.
Maybe tweak the language a bit: "..prefixes are always written with a
leading + to avoid confusions").

>
>3.2.  Resolution Data
>
>   For each prefix, there is a variety of data that can be exchanged.
>   The most important set of data identifies that a specific VSP is
>   responsible for the prefix and in most cases the VSP provides a SIP
>   URI through which this prefix can be reached.

"reached" is maybe too strong. "addressed" might be better.

Perhaps add here a sentence stating that it is _not_ assumed that this
SIP URI is reachable via the public Internet using the RFC3263 process.
Instead, a further routing algorithm might be needed to find a suitable
next hop towards the destination network.

>
>   Like stated in the introduction it is imperative that the minimal set
>   of resolution data contain all the information required for a DNS
>   NAPTR RR.
>

I don't quite understand this sentence. Without specifying for which
enum-service you want to construct a NAPTR, it's hard to describe
the minimal set of data needed.

>   Additionally, as a future proofing mechanism it is recommended that
>   resolution data include a catchall (similar to a DNS TXT RR) for data
>   that is not currently present in any ENUM service definitions.

I don't quite get it. We have x- enumservices and quite generic
uri-schemes like data:, so we can put anything into NAPTRs. 
(which prejudices ENUM, which IMHO we shouldn't do at this step)

As we're talking about the provisioning protocol, we just need to make
sure we either can transmit arbitrary attribute/value pairs during the
provisioning step.

>   One final note.  One of the common "rewrite" rules for the URI in
>   NAPTR RRs for example is of the form "\[email-masked]"
>   where the "\1" refers to the telephone number being processed.  This
>   kind of shorthand should be available when processing prefixes in
>   bulk.

"..regardless of whether ENUM will be the query protocol".

>4.  Reachability vs. Routing
>
>   The goal of the registry is to provide sufficient information to
>   identify a responsible VSP for a prefix.  The responsible VSP can
>   provide a SIP URI that can be proxied or redirected as desired by the
>   VSP.  It is important to note that the registry is expected to return
>   the same responsibility data for all parties that query it.

Nicely put. Good.

>   Routing information is also out of scope of the registry provisioning
>   problem.  Once a responsible VSP is contacted, that VSP can use a
>   variety of techniques to route that request.  

hm. Shouldn't that be "Once the call originating VSP has learned the
identity of the responsible VSP, the O-VSP can use a variety of
techniques to route that request." ?

>
>5.  Operations on the Registry Data
>
>   Delete:  Remove a prefix from the registry.  Semantically it means
>   that the prefix no longer exists anywhere.
>
>   Port-out:  A port-out is similar to a delete, but could be logged
>   differently.  The semantics are that the prefix still exists, but
>   that the previous VSP is no longer responsible for it.

Perhaps note here that one difference between Delete and Port-out is
that in the case of Delete, further request can get matched by
super-prefixes existing in the registry, whereas in the Port-out case
the registry will return "not-found" even if a containing prefix exists.

>9.  Data Propegation

Propagation

>10.  Querying The Registry
>
>
>   When SIP is used for the query mechanism, the numbering registry
>   functions as a SIP redirect proxy [RFC3261] .  The input to this
>   mechanism is a URI or more importantly the UserInfo part of the URI
>   containing the number to be queried.  The response returned by the
>   proxy is either an error code indicating the absence of information
>   about the number queried or a redirect response (3XX) containing 1
>   (or more) Contact Headers representing available routing options.

Whoa, stop here. 

In 4. you wrote that the registry contains ownership information, not
routing information.

/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: Tue, 11 Mar 2008 22:55:54 +0100
From: Otmar Lendl <[email-masked]>
To: [email-masked]
Mail-Followup-To: Otmar Lendl <[email-masked]>, [email-masked]
Subject: [PEPPERMINT] Some comments on the ESPP reqs draft
Sender: [email-masked]

I haven't managed to fully read both drafts yet, so these are
just first comments.

>1.  Introduction
>
>   This document presents a set of use cases and protocol requirements
>   for an ENUM-SIP addressing Server Provisioning Protocol (ESPP).  An
>   ENUM-SIP addressing server is a session routing server which resolves
>   telephone numbers or any type of public user addresses into routable
>   Uniform Resource Identifiers (URIs) based on various rules and
>   routing logic.  

Could you elaborate what you mean by "routable"? Suitable for RFC3263
processing? In which networks?

>   A provisioning protocol has been defined based on the requirements
>   summarized in this document ([CableLabs-ESPP]) and it is presented in
>   [I-D.espp-protocol].  A number of vendors have client and server
>   implementations of this protocol and two interoperability testing
>   events have been conducted to date.

What is the aim of this draft (and the spec one)? Just document what
cablelabs did? Ideas for peppermint? A solution of the general 
peppermint problem statement?

>   For example, two SIP service providers that respectively service the
>   New York-Manhattan and New-York Queens metropolitan areas agree to
>   peer.

Can a service area just be served by a single SSP? Can they overlap?

>   Some of the session establishment data (SBEs, Service Areas, Routes)
>   is usually provisioned once for each cable operator with occasional
>   subsequent updates as interconnect points are added or changed.  It
>   is provisioned independently from the provisioning of the elements
>   contained in Service Areas (TNs, TN Ranges, LRNs, or public
>   identities such as IM identifiers).  This allows the rare process of
>   provisioning SBEs, service areas, etc. to be distinctly separate from
>   the continuous process of adding subscribers.

It's a good idea to separate these two different types of information.

(For my part, I think that should be two different protocols, but I'm
glad that there is at least some sort of two-stage mapping in the
design.)

>   Figure 1 illustrates how telephone numbers may be grouped logically
>   into service areas (which may not necessarily be based on
>   geographical boundaries).  It also shows how each service area may be
>   reachable via signaling path border elements.

I have a hard time understanding the data design (and the naming) behind
ESPP. I'll try to go through the protocol specs later.

>3.3.  Backward Compatibility to Legacy Switch Translations
>
>   The underlying data schema used to provision ENUM-SIP addressing
>   servers should be backward compatible with today's VoIP server
>   translations and legacy PSTN.  This requirement arises from the fact
>   that some SIP service providers may wish to utilize the same number
>   translation data employed by their SIP servers or Call Management
>   Servers (CMS).
>
>   For example, a SIP service provider's switch translation personnel,
>   who are responsible for managing CMS translations, are given
>   responsibility for managing the operator's ENUM data.  Rather than
>   provisioning complete 10-digit numbers to a peer's ENUM server some
>   may choose to provision Location Routing Numbers (LRNs).  This
>   decision is, in large part, due to the fact that, in some networks,
>   the trunk selection algorithm of the operator's CMS are based on LRNs
>   (NPA-NXX).  The switch translation personnel choose to reuse LRNs
>   rather than taking responsibility for keeping a complete set of the
>   operator's numbers up to date.

Phew, this is awefully NANP-specific.

/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: <[email-masked]>
Date: Mon, 10 Mar 2008 18:21:33 -0400
Subject: [PEPPERMINT] PLEASE GET YOUR SLIDES TO ME
Sender: [email-masked]

ASAP ..

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: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Tue, 4 Mar 2008 14:51:10 -0500
Subject: [PEPPERMINT] FINAL AGENDA
Sender: [email-masked]

The only change from the previous draft agenda is that we will deal with the
Problem Statement documents one after another.

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

IETF 71 PEPPERMINT BOF Agenda

Provisioning Extensions in Peering Registries for Multimedia INTerconnection

1510-1610 Afternoon Session II
Franklin 11/12	INT	dna	Detecting Network Attachment WG
Franklin 5	OPS	grow	Global Routing Operations WG
Franklin 3/4	RAI	peppermint	Provisioning Extensions in Peering
Registries for Multimedia INTerconnection BOF
Franklin 13	RTG	isis	IS-IS for IP Internets WG
Salon I	SEC	ltans	Long-Term Archive and Notary Services WG
Franklin 5	SEC	msec	Multicast Security WG

Chair(s):

Richard Shockey <[email-masked]>
Tom Creighton  <[email-masked]>

RAI Director(s):

Jon Peterson [email-masked]
Cullen Jennings [email-masked]

Agenda Bashing. 

Presentation of the proposed charter.  <Shockey> 10 min ( see below ) 

1. 
	Title		: Consolidated Provisioning Problem Statement
	Author(s)	: D. Schwartz, R. Mahy, A. Duric, E. Lewis
	Filename	:
draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00.txt
	Pages		: 12
	Date		: 2008-2-11
	
This document describes the type of data provisioned among Voice   Service
Providers and underscores the need for clearly defined   structures and
interfaces to facilitate this provisioning. This work is in support of the
service provider peering as defined by the  SPEERMINT WG.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-schwartz-peppermint-consolidated-p
rovisioning-problem-statement-00.txt

2. A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Provisioning Protocol Requirements for ENUM-SIP
Addressing Servers
	Author(s)       : T. Creighton, J. Mule
	Filename        : draft-mule-peppermint-espp-requirements-00.txt
	Pages           : 16
	Date            : 2008-02-18

This document presents use cases and protocol requirements for provisioning
ENUM-SIP addressing servers.  The provisioned data is used by an addressing
server to return part of the session establishment data to SIP entities so
that they can route SIP sessions to the target destinations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mule-peppermint-espp-requirements-
00.txt

3. 	
	Title           : A Provisioning Protocol for ENUM-SIP Addressing
Servers
	Author(s)       : K. Cartwright, et al.
	Filename        : draft-mule-peppermint-espp-protocol-01.txt
	Pages           : 117
	Date            : 2008-02-25

This document defines a provisioning protocol for ENUM-SIP addressing
servers.  This protocol has been recently published as part of
CableLabs(r) PacketCable(tm) specifications.  It allows SIP service
providers to provision and manage session establishment data used by SIP
network elements to route SIP sessions to the target destinations which may
be served by the SIP service provider's own internal network or by a session
peering partner.  The data provisioned into an ENUM-SIP addressing server is
queried by SIP entities using ENUM or SIP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mule-peppermint-espp-protocol-01.t
xt

General Discussion

The Usual Questions.

A. Is this a problem that the IETF needs to work on?

B. Who wants to work on this problem?

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

Peppermint Proposed Charter 

Provisioning Extensions in Peering Registries for Multimedia
Interconnection.

Mailing Lists: 

[email-masked]

General information about the mailing list is at:

 https://www1.ietf.org/mailman/listinfo/peppermint

Temporary Area Directorate: Real Time Applications (RAI)

Ultimate Area Directorate: TBD

Chairs: TBD

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.

PROPOSED GOALS AND MILESTONES

Requirements for Interconnection data exchanges.         Sept 08 

Provisioning of Interconnection data registries.         Nov 08

Provisioning of Interconnection data caches.             Feb 09 

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: Cullen Jennings <[email-masked]>
To: [email-masked]
Impp: xmpp:[email-masked]
Date: Sat, 1 Mar 2008 10:51:15 -0800
Subject: [PEPPERMINT] Minor comments on draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00
Sender: [email-masked]

My biggest complaint is your draft name is too long :-) Seriously I  
found this draft easy to understand and get what the problem was you  
were trying to solve - I like it. Few little things.

Section 3.1, do you want to say anything about what happens when you  
have overlapping ranges with the same length. For example one prefix  
has 1000-3000 and the other other has 2900 to 3100. I have used stuff  
that selected the smallest range in that case - I don't know that is  
what you want but seems like a case that might motivate some  
requirements one way or the other.

Section 3.2 para 5 - I would rephrase to say that the protocol should  
be easily extensible in ways that anticipate ways that ENUM will be  
extended or something like that. Comparing this to the DNS TXT RR  
record may cause some people allergic reaction that are not really  
what you want.

Section 5 - the para on "Renumber". I'm not 100% clear what the  
requirements are here - can you say a bit more. What information at  
the semantic level would a renumber operation contain.

Section 6

The Fee Category attributes got me a little worried. What would they  
mean and how would they be used. I imagine I would have no problems  
with these but I would want to be very careful. The idea of landline  
or mobile is starting to get pretty vague when we are talking about a  
SIP call to [email-masked].

I have serious worries about the Media types. I worry that this needs  
to be negotiated at the time of the call and that having it in a  
registry will hinder deployments of devices that support a wide  
variety of media types. Let's talk about this in Philadelphia some  
time and see if you can educate me on the requirements here.

Cullen <with my individual contributor hat on>

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