Subject: [PEPPERMINT] Comparison of Requirements Documents
From: Edward Lewis <[email-masked]>
To: [email-masked], [email-masked]
Date: Mon, 30 Jun 2008 15:08:15 -0400
List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection <peppermint.ietf.org>

I've been taking a look at two requirements documents, the ESPP 
Requirements and the Consolidated Provisioning Statement.  I realize 
(or have been told) that a new set of ESPP documents is coming out, 
so I'll avoid getting into specifics.  The goal is to have a 
"Unified" (we've already used "Consolidated") requirements document 
for the WG.

BTW, the documents I'm comparing are these:
http://tools.ietf.org/html/draft-mule-peppermint-espp-requirements-00
http://tools.ietf.org/html/draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00

This comparison list is not very detailed, I wanted to identify the 
topics that included in both and where the two requirements had 
different emphasis.  I don't think there is any outright 
contradiction between the two.

Both documents describe a protocol running over SOAP/XML, WDSL, TLS 
and HTTP and being easily integrated into the current provisioning 
systems.

Both recognize that there a telephone number (E164) to URI mapping 
happening, with NAPTR as a major vehicle (but not sole vehicle).

Both mention a need to make the transactions auditable, including logs.

Consolidated mentions multiple kinds of sources of data, ESPP refers 
to multiple clients.  This could be interpreted as an equivalent 
statement.

ESPP explicitly states that operation is based on files (as opposed 
to records).  (I'd question the file name requirements based on this, 
as well as a hard coded limit on the size limit.)

ESPP describes designing an efficient protocol, i.e., being able to 
apply one set of data to many numbers.  (But when I boiled the 
requirements down, I didn't see this idea - maybe it was in the 
protocol.)

ESPP has a specific data model in mind (which is being discussed in 
recent mail), and a capacity of the order of the size of the PSTN 
number range(s).

ESPP includes some protocol maintenance stuff (versioning numbers).

Consolidated has requirements on the database being addressable (any element).

Consolidated explicitly includes prefixs (for ranges) and min/max lengths.

Consolidated explicitly mentions numbers being reassigned and the 
impact of that on database entries and responses.

Consolidated requires dip indications, temporal validity, number 
"ownership" and other ancillary data.

Consolidated requires a catchall record, a \1 shorthand.

Consolidated has requirements on the transport as being end-to-end 
only (no caching) and having flow control.

It's obvious that the two teams that developed the documents had 
different emphasis on what to include in a list or requirements. 
Even with the ESPP requirements document being rather mature (as well 
as being accompanied by a protocol specification), there is a need to 
combine the two documents.  I don't believe that the result will be 
radically different from either, just more complete.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Mon, 30 Jun 2008 09:50:41 +0200
From: "Alexander Mayrhofer" <[email-masked]>
To: <[email-masked]>
Subject: [PEPPERMINT] test - please ignore...
Sender: [email-masked]

another test after the list migration.

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

To: "Jean-Francois Mule" <[email-masked]>
From: [email-masked]
Date: Thu, 26 Jun 2008 15:48:55 +0100
Cc: [email-masked]
Subject: Re: [PEPPERMINT] Data model for "reachability data" and	naming/terminology for group of addresses
Sender: [email-masked]

> We're updating the draft to integrate comments received from the list
> and fix a few issues we found.
> 1) We're changing LRNs (US, PSTN centric to Penn and Otmar's point) to
> use prefix.
> David et al. have chosen prefix in their problem statement draft and
> this describes something that's close to LRNs, yet more generally
> applicable.
> 2) We're also renaming "Service Areas" to "AddressGroup" for a lack of a
> better term

Jean-Francois,

Can you elaborate on what a "Service Area" / "Address Group" actually is?

In the UK for our Central Numbering Database we've developed a concept of 
a "Destination Group" - that being all those numbers (or destinations) 
which are supposed to be routed identically.  Is that the same thing?

Note however that this does not mean that every originating carrier has to 
route them to the same place as every other carrier.

For example if Carrier A (a terminating carrier) has:

  DG1 = (a, b)
  DG2 = (c, d)

then originating Carrier B routes destinations in DG1 to a particular 
interconnect, and routes DG2 to some other interconnect.  However Carrier 
C might have completely different interconnects with Carrier A.

In the UK model the actual interconnect addresses are private information 
bilaterally agreed between carriers.

kind regards,

Ray

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

Content-class: urn:content-classes:message
Date: Thu, 26 Jun 2008 08:35:00 -0600
From: "Jean-Francois Mule" <[email-masked]>
To: <[email-masked]>
Subject: [PEPPERMINT] Data model for "reachability data" and naming/terminology for group of addresses
Sender: [email-masked]

   In draft-mule-peppermint-espp-protocol-01.txt, a data model is
proposed Figure 3.  Otmar and a number of folks have commented on the
list that the 'bottom' part of data model (the grouping of user
addresses, PSTN prefixes, or anything that be logically attached to a
SIP route/domain) seems to make some sense for some use cases.  The
upper part is where folks see different solutions.

We're updating the draft to integrate comments received from the list
and fix a few issues we found.
1) We're changing LRNs (US, PSTN centric to Penn and Otmar's point) to
use prefix.
David et al. have chosen prefix in their problem statement draft and
this describes something that's close to LRNs, yet more generally
applicable.
2) We're also renaming "Service Areas" to "AddressGroup" for a lack of a
better term

Comments welcome.  You should also see some responses in the coming
weeks on the other threads re: espp comments.

Jean-Francois.

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

Content-class: urn:content-classes:message
Date: Thu, 19 Jun 2008 17:44:28 +0200
From: "Alexander Mayrhofer" <[email-masked]>
To: "Dana Jaff" <[email-masked]>, <[email-masked]>
Subject: Re: [PEPPERMINT] Subscribe
Sender: [email-masked]

> I am interested in being added to your mailing list and 
> discussions.  Please let me know if you need further information. 

Dana,

please see https://www1.ietf.org/mailman/listinfo/peppermint for
information how to subscribe to the list. There is also a list archive.

thanks,

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

To: [email-masked]
From: Dana Jaff <[email-masked]>
Date: Wed, 18 Jun 2008 13:09:06 -0400
Subject: [PEPPERMINT] Subscribe
Sender: [email-masked]

This is a multipart message in MIME format.
--===============1078213233==
Content-Type: multipart/alternative; boundary="=_alternative 005D6D868525746C_="

This is a multipart message in MIME format.
--=_alternative 005D6D868525746C_=
Content-Type: text/plain; charset="US-ASCII"

Hi,

I am interested in being added to your mailing list and discussions. 
Please let me know if you need further information.

Thanks

Dana Jaff
GETS/WPS IC Program
Computer Sciences Corporation (CSC)
Office: 703-818- 4135

Computer Sciences Corporation 
Registered Office: 3170 Fairview Park Drive, Falls Church, Virginia 22042, 
USA
Registered in Nevada, USA No: C-489-59

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

--=_alternative 005D6D868525746C_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">Hi,</font>
<br>
<br><font size=2 face="sans-serif">I am interested in being added to your
mailing list and discussions. &nbsp;Please let me know if you need further
information.</font>
<br>
<br><font size=2 face="sans-serif">Thanks</font>
<br>
<br><font size=2 face="sans-serif">Dana Jaff<br>
GETS/WPS IC Program<br>
Computer Sciences Corporation (CSC)<br>
Office: 703-818- 4135<br>
<br>
Computer Sciences Corporation <br>
Registered Office: 3170 Fairview Park Drive, Falls Church, Virginia 22042,
USA<br>
Registered in Nevada, USA No: C-489-59<br>
<br>
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. <br>
NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.<br>
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>
</font>
--=_alternative 005D6D868525746C_=--

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

--===============1078213233==--

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Mon, 16 Jun 2008 10:44:58 -0400
Subject: Re: [PEPPERMINT] WG Action: Data for Reachability of Inter/tra-NetworK SIP (drinks)
Sender: [email-masked]

You have all seen this by now .. we have a one hour slot ready so that should show up on the draft agenda shortly.

I will arrange this week for the change of mail address from [email-masked] to [email-masked] The Secretariat should be able to enroll the current list pretty automatically.

Needless to say we need to begin Agenda discussions, I have one request so far.

>  -----Original Message-----
>  From: The IESG [mailto:[email-masked]]
>  Sent: Friday, June 13, 2008 5:00 PM
>  To: [email-masked]
>  Cc: [email-masked]; [email-masked];
>  [email-masked]
>  Subject: WG Action: Data for Reachability of Inter/tra-NetworK SIP
>  (drinks)
>  
>  A new IETF working group has been formed in the Real-Time Applications
>  and
>  Infrastructure Area.  For additional information, please contact the
>  Area
>  Directors or the WG Chairs.
>  
>  Data for Reachability of Inter/tra-NetworK SIP (drinks)
>  ---------------------------------------------
>  Last Modified: 13 June 2008
>  
>  Current Status: Active Working Group
>  
>  Chairs:
>  
>  Richard Shockey ([email-masked])
>  Alexander Mayrhofer ([email-masked])
>  
>  Area Directorate: Real Time Applications (RAI)
>  
>  RAI Director(s):
>  
>  Jon Peterson ([email-masked])
>  Cullen Jennings ([email-masked])
>  
>  RAI Area Advisor:
>  
>  Jon Peterson ([email-masked])
>  
>  Mailing Lists: [email-masked]
>  General information about the mailing list is at:
>  https://www1.ietf.org/mailman/listinfo/peppermint
>  
>  Working Group Description:
>  
>  The IETF has been working on various aspects of SIP-enabled Multimedia
>  administrative domains among SIP Service Providers (SSP's). SSP's are
>  entities that provide session services utilizing SIP signaling to
>  their
>  customers. In addition, the IETF has done significant work on data
>  exchanges among various network elements.
>  
>  The DRINKS working group is chartered with a scope that is orthogonal
>  to
>  SPEERMINT and ENUM. The protocol work of DRINKS will be designed to
>  build from the work of SPEERMINT and ENUM to identify and define the
>  data structures and data exchange protocol(s) among SIP based
>  Multimedia
>  administrative domains.
>  
>  The ENUM working group is specifically chartered to develop protocols
>  that involve the translation of E.164 numbers to URIs. While the
>  SPEERMINT working group has been chartered to develop requirements and
>  best current practices among real-time application SSPs and to
>  describe
>  how such services may best interconnect across administrative
>  boundaries.
>  
>  These administrative domains may be of any practical size and could be
>  any type of SSP, such as recognized telephony carriers, enterprises,
>  end-user groups, or Federations. Data exchanges among these
>  administrative domains may be bi-lateral or multi-lateral in nature,
>  and
>  could include bulk updates and/or more granular real-time updates.
>  
>  Administrative domains may exchange data through the use of an
>  external
>  registry to aggregate data from multiple administrative domains or
>  multiple data providers into a single view.
>  
>  The DRINKS WG will provide details of how Session Establishment Data
>  (SED) is collected, what comprises SED, how SED should be used to
>  properly identify an optimal path to a destination SIP user agent
>  (UA),either internally or externally to the SSP. In addition DRINKS
>  will
>  insure that the SED and the SIP session data is securely exchanged
>  between the peering functions.
>  
>  Typical SED data might include:
>  
>  + Routes
>  - Destination SIP/SIPS/TEL URI Egress and Ingress Routes
>  - Relevant route names, identifiers, and services
>  - Attributes affecting route selection
>  - PSTN database information
>  
>  + Targets
>  - Individual, ranges, or groups of user-agent identifiers
>  - Target aggregation entities (e.g. service areas) and
>  target-to-aggregate associations
>  
>  + Treatment Profiles
>  - Priority
>  - Location
>  
>  Potential SED Data types not in scope will be session rating or other
>  billing or pricing information between SSP's
>  
>  The working group will draw upon expert advice and on-going
>  consultation
>  from the ENUM and SPEERMINT working groups, and also the XML
>  Directorate.
>  The working group will consider the reuse of elements of RFC 4114.
>  
>  The final work product(s) from this working group will utilize and be
>  based on XML documents and XML document exchanges.
>  
>  
>  GOALS AND MILESTONES
>  
>  Requirements for Session Establishment Data (SED) data exchanges. --
>  Sept 08
>  
>  Exchanging of Session Establishment Data (SED) from data providers to
>  registries or between bi/multi-lateral partners. -- Nov 08
>  
>  Exchange of Session Establishment Data (SED) from registries to
>  Location
>  Routing Function databases. --- Feb 09

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

From: The IESG <[email-masked]>
To: [email-masked]
Date: Fri, 13 Jun 2008 14:00:02 -0700 (PDT)
Cc: [email-masked], [email-masked]
Subject: [PEPPERMINT] WG Action: Data for Reachability of Inter/tra-NetworK SIP (drinks)
Sender: [email-masked]

A new IETF working group has been formed in the Real-Time Applications and
Infrastructure Area.  For additional information, please contact the Area
Directors or the WG Chairs.

Data for Reachability of Inter/tra-NetworK SIP (drinks)
---------------------------------------------
Last Modified: 13 June 2008

Current Status: Active Working Group

Chairs:

Richard Shockey ([email-masked])
Alexander Mayrhofer ([email-masked])

Area Directorate: Real Time Applications (RAI)

RAI Director(s):

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

RAI Area Advisor:

Jon Peterson ([email-masked])

Mailing Lists: [email-masked]
General information about the mailing list is at:
https://www1.ietf.org/mailman/listinfo/peppermint

Working Group Description:

The IETF has been working on various aspects of SIP-enabled Multimedia
administrative domains among SIP Service Providers (SSP's). SSP's are
entities that provide session services utilizing SIP signaling to their
customers. In addition, the IETF has done significant work on data
exchanges among various network elements.

The DRINKS working group is chartered with a scope that is orthogonal to
SPEERMINT and ENUM. The protocol work of DRINKS will be designed to
build from the work of SPEERMINT and ENUM to identify and define the
data structures and data exchange protocol(s) among SIP based Multimedia
administrative domains.

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

These administrative domains may be of any practical size and could be
any type of SSP, such as recognized telephony carriers, enterprises,
end-user groups, or Federations. Data exchanges among these
administrative domains may be bi-lateral or multi-lateral in nature, and
could include bulk updates and/or more granular real-time updates.

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

The DRINKS WG will provide details of how Session Establishment Data
(SED) is collected, what comprises SED, how SED should be used to
properly identify an optimal path to a destination SIP user agent
(UA),either internally or externally to the SSP. In addition DRINKS will
insure that the SED and the SIP session data is securely exchanged
between the peering functions.

Typical SED data might include:

+ Routes
- Destination SIP/SIPS/TEL URI Egress and Ingress Routes
- Relevant route names, identifiers, and services
- Attributes affecting route selection
- PSTN database information

+ Targets
- Individual, ranges, or groups of user-agent identifiers
- Target aggregation entities (e.g. service areas) and
target-to-aggregate associations

+ Treatment Profiles
- Priority
- Location

Potential SED Data types not in scope will be session rating or other
billing or pricing information between SSP's

The working group will draw upon expert advice and on-going consultation
from the ENUM and SPEERMINT working groups, and also the XML
Directorate.
The working group will consider the reuse of elements of RFC 4114.

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

GOALS AND MILESTONES

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

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

Exchange of Session Establishment Data (SED) from registries to Location
Routing Function databases. --- Feb 09
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

From: "Richard Shockey" <[email-masked]>
To: "'Guyton, Deborah A'" <[email-masked]>, <[email-masked]>
Date: Thu, 5 Jun 2008 12:01:18 -0400
Subject: Re: [PEPPERMINT] agenda item
Sender: [email-masked]

This is a multipart message in MIME format.

--===============0401959439==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_1436_01C8C703.DE779F70"
Content-Language: en-us

This is a multipart message in MIME format.

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

Will do .thanks.

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Guyton, Deborah A
Sent: Thursday, June 05, 2008 9:47 AM
To: [email-masked]
Subject: [PEPPERMINT] agenda item

Richard,

I'm planning to send in a contribution for a provisioning interface for a
Registry database and request a presentation slot to present a summary
overview.

Debbie Guyton 

------=_NextPart_000_1436_01C8C703.DE779F70
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)">
<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;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:windowtext;}
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.25in 1.0in 1.25in;}
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'>Will do &#8230;thanks.<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"'>
[email-masked] [mailto:[email-masked]] <b>On =
Behalf
Of </b>Guyton, Deborah A<br>
<b>Sent:</b> Thursday, June 05, 2008 9:47 AM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> [PEPPERMINT] agenda item<o:p></o:p></span></p>

</div>

</div>

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

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Richard,<o:p>=
</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I&#8217;m
planning to send in a contribution for a provisioning interface for a =
Registry
database and request a presentation slot to present a summary =
overview.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Debbie
Guyton <o:p></o:p></span></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_1436_01C8C703.DE779F70--

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

--===============0401959439==--

From: "Guyton, Deborah A" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 5 Jun 2008 09:46:32 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [PEPPERMINT] agenda item
Sender: [email-masked]

--===============1741077881==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_AE85DAD2723E724EAB2A704148DE15AC278DF32FE3rrcdteexmb2dt_"

--_000_AE85DAD2723E724EAB2A704148DE15AC278DF32FE3rrcdteexmb2dt_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Richard,
I'm planning to send in a contribution for a provisioning interface for a R=
egistry database and request a presentation slot to present a summary overv=
iew.
Debbie Guyton

--_000_AE85DAD2723E724EAB2A704148DE15AC278DF32FE3rrcdteexmb2dt_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" 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 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Richard,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>I&#8217;m planning to send in a contribution for a
provisioning interface for a Registry database and request a presentation s=
lot
to present a summary overview.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Debbie Guyton <o:p></o:p></span></font></p>

</div>

</body>

</html>

--_000_AE85DAD2723E724EAB2A704148DE15AC278DF32FE3rrcdteexmb2dt_--

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

--===============1741077881==--