From speermint-bounces@ietf.org Wed Feb 01 08:57:31 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F4IUF-0003v5-4D; Wed, 01 Feb 2006 08:57:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F4IUD-0003sI-Np
	for speermint@megatron.ietf.org; Wed, 01 Feb 2006 08:57:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00744
	for <speermint@ietf.org>; Wed, 1 Feb 2006 08:55:30 -0500 (EST)
Received: from dpc6746187138.direcpc.com ([67.46.187.138] helo=localhost)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F4Iex-0006d7-Fv
	for speermint@ietf.org; Wed, 01 Feb 2006 09:08:41 -0500
Message-ID: <000001c62761$4df74700$0100007f@localhost>
From: "Marshall Bell" <jseiferth@betinternet.com>
To: <speermint@ietf.org>
Date: Wed, 01 Feb 2006 07:56:43 -0600
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 093efd19b5f651b2707595638f6c4003
Subject: [Speermint] Need S0ftware?
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1990484741=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1990484741==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C62761.4DF74700"

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C62761.4DF74700
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se


ListPrice:  $550.00 
OurPrice:  $69.95 
YouSave:  $480.05 ( 87%) 

 

Availability: Available for INSTANT download! 



Sales Rank: #1 
Average Customer Review:  
(based on 36 reviews)

--------------------------------------------------------------------------------
 
Microsoft Windows XP Professional 
   by Microsoft 


ListPrice:  $200.00 
OurPrice:  $49.95 
YouSave:  $150.05 ( 75%) 

 

Availability: Available for INSTANT download! 



Sales Rank: #2 
Average Customer Review:  
(based on 49 reviews)

--------------------------------------------------------------------------------
 
Adobe Photoshop CS2 V 9.0 
   by Adobe 


ListPrice:  $599.00 
OurPrice:  $69.95 
YouSave:  $529.05 ( 88%) 

 

Availability: Available for INSTANT download! 



Sales Rank: #3 
Average Customer Review:  
(based on 46 reviews)

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

------=_NextPart_000_0001_01C62761.4DF74700
Content-Type: text/html;
    charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
  <HEAD>
    <STYLE type=3Dtext/css>
      .eyebrow { FONT-WEIGHT: bold; FONT-SIZE: 10px; TEXT-TRANSFORM: uppercase; COLOR: #ffffff; FONT-FAMILY: verdana,arial,helvetica,sans-serif; TEXT-DECORATION: none } A.eyebrow:link { TEXT-DECORATION: none }
    </STYLE>
    <TITLE>
      Software
    </TITLE>
    <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-1252">
    <META content=3D"MSHTML 6.00.2900.2627" name=3DGENERATOR>
    <STYLE type=3Dtext/css>
      .serif { FONT-SIZE: small; FONT-FAMILY: times,serif } .sans { FONT-SIZE: small; FONT-FAMILY: verdana,arial,helvetica,sans-serif } .small { FONT-SIZE: x-small; FONT-FAMILY: verdana,arial,helvetica,sans-serif } .h1 { FONT-SIZE: small; COLOR: #cc6600; FONT-FAMILY: verdana, arial,helvetica,sans-serif } .h3color { FONT-SIZE: x-small; COLOR: #cc6600; FONT-FAMILY: verdana,
      arial,helvetica,sans-serif } .tiny { FONT-SIZE: xx-small; FONT-FAMILY: verdana,arial,helvetica, sans-serif } .listprice { FONT-SIZE: x-small; FONT-FAMILY: arial,verdana,sans-serif; TEXT-DECORATION: line-through } .price { FONT-SIZE: x-small; COLOR: #990000; FONT-FAMILY: verdana,arial,helvetica,sans-serif } .tinyprice { FONT-SIZE: xx-small; COLOR: #990000; FONT-FAMILY: verdana,arial,helvetica,sans-serif } .attention { BACKGROUND-COLOR: #ffffd5 } .eyebrow { FONT-WEIGHT: bold; FONT-SIZE: 10px; TEXT-TRANSFORM: uppercase; COLOR: #ffffff; FONT-FAMILY: verdana,arial,helvetica,sans-serif; TEXT-DECORATION: none } A.eyebrow:link { TEXT-DECORATION: none }
    </STYLE>
  </HEAD>
<BODY text=3D#000000 vLink=3D#996633 aLink=3D#FF9933 link=3D#003399 bgColor=3D#FFFFFF><TABLE cellSpacing=3D0 cellPadding=3D0 width=3D705 border=3D0><DIV align=3Dleft></TABLE></DIV><TBODY><TR> <TD class=3Dsmall align=3Dmiddle bgColor=3D#ffffdd width=3D707></TD></TR></TBODY></TABLE><TABLE cellSpacing=3D0 cellPadding=3D0 width=3D704 border=3D0><TR> <TD vAlign=3Dtop width=3D166><TABLE cellSpacing=3D0 cellPadding=3D0 width=3D155 bgColor=3D#eeeecc border=3D0><TR vAlign=3Dbottom align=3Dmiddle> <TD><TABLE cellSpacing=3D0 cellPadding=3D0 width=3D155 border=3D0><TR vAlign=3Dtop bgColor=3D#333399> <TD width=3D5 bgcolor=3D#000080> <FONT size=3D1> <IMG src=3Dhttp://g-images.amazon.com/images/G/01/icons/eyebrow-upper-left-corner.gif width=3D5 height=3D5></FONT></TD> <TD bgcolor=3D#000080><TABLE cellSpacing=3D3 cellPadding=3D0 width=3D99% border=3D0><TR> <TD vAlign=3Dbottom><P align=3Dcenter> <B> <FONT face=3Dverdana,arial,helvetica size=3D1 color=3D#FFFFFF> TOP 10 NEW TITLES</FONT></B></!
 P></TD></TR></TABLE></TD> <TD align=3Dright width=3D5 bgcolor=3D#000080> <FONT size=3D1>
<IMG src=3Dhttp://g-images.amazon.com/images/G/01/icons/eyebrow-upper-right-corner.gif width=3D5 height=3D5></FONT></TD></TR></TABLE></TD></TR><TR> <TD><TABLE cellSpacing=3D0 cellPadding=3D1 width=3D100% bgColor=3D#cccc99 border=3D0><TR> <TD width=3D100%><TABLE cellSpacing=3D0 cellPadding=3D0 width=3D100% bgColor=3D#cccc99 border=3D0><TR> <TD vAlign=3Dtop width=3D100% bgColor=3D#eeeecc><TABLE cellSpacing=3D0 cellPadding=3D2 width=3D153 border=3D0><TR> <TD width=3D141 colspan=3D3 bgcolor=3D#FFFFFF><P align=3Dcenter> <B> <FONT face=3Dverdana,arial,helvetica size=3D1 color=3D#CC6600> &nbsp;ON SALE NOW!</FONT></B></P></TD></TR><TR> <TD width=3D4> &nbsp;</TD> <TD width=3D8> <FONT face=3DVerdana size=3D1> 1</FONT></TD> <TD width=3D129> <FONT face=3Dverdana,arial,helvetica size=3D1> <A href=3Dhttp://mid.alkonavt.com/> Office Pro 2003</A></FONT></TD></TR><TR> <TD width=3D4> &nbsp;</TD> <TD width=3D8> <FONT face=3DVerdana size=3D1> 2</FONT></TD> <TD width=3D129> <A href=3Dhttp://mid.!
 alkonavt.com/> <FONT face=3Dverdana,arial,helvetica size=3D1> Adobe Photoshop 9.0</FONT></A></TD></TR><TR> <TD width=3D4> &nbsp;</TD> <TD width=3D8>
<FONT face=3DVerdana size=3D1> 3</FONT></TD> <TD width=3D129> <A href=3Dhttp://mid.alkonavt.com/> <FONT face=3Dverdana,arial,helvetica size=3D1> Windows XP Pro</FONT></A></TD></TR><TR> <TD width=3D4> &nbsp;</TD> <TD width=3D8> <FONT face=3DVerdana size=3D1> 4</FONT></TD> <TD width=3D129> <A href=3Dhttp://mid.alkonavt.com/> <FONT face=3Dverdana,arial,helvetica size=3D1> Adobe Acrobat 7 Pro</FONT></A></TD></TR><TR> <TD width=3D4> &nbsp;</TD> <TD width=3D8> <FONT face=3DVerdana size=3D1> 5</FONT></TD> <TD width=3D129> <FONT face=3Dverdana,arial,helvetica size=3D1> <A href=3Dhttp://mid.alkonavt.com/> Flash MX 2004</A></FONT></TD></TR><TR> <TD width=3D4> &nbsp;</TD> <TD width=3D8> <FONT face=3DVerdana size=3D1> 6</FONT></TD> <TD width=3D129> <FONT face=3Dverdana,arial,helvetica size=3D1> <A href=3Dhttp://mid.alkonavt.com/> Corel Draw 12</A></FONT></TD></TR><TR> <TD width=3D4> &nbsp;</TD> <TD width=3D8> <FONT face=3DVerdana size=3D1> 7</FONT></TD> <TD width=3D129> <A href=3Dhttp:/!
 /mid.alkonavt.com/> <FONT face=3Dverdana,arial,helvetica size=3D1> Norton Antivirus 2005</FONT></A></TD></TR><TR> <TD width=3D4> &nbsp;</TD> <TD width=3D8>
<FONT face=3DVerdana size=3D1> 8</FONT></TD> <TD width=3D129> <FONT face=3Dverdana,arial,helvetica size=3D1> <A href=3Dhttp://mid.alkonavt.com/> Windows 2003 Server</A></FONT></TD></TR><TR> <TD width=3D4> &nbsp;</TD> <TD width=3D8> <FONT face=3DVerdana size=3D1> 9</FONT></TD> <TD width=3D129> <FONT face=3Dverdana,arial,helvetica size=3D1> <A href=3Dhttp://mid.alkonavt.com/> Alias Maya 6 Wavefrt</A></FONT></TD></TR><TR> <TD width=3D4> &nbsp;</TD> <TD width=3D8> <FONT face=3DVerdana size=3D1> 10</FONT></TD> <TD width=3D129> <FONT face=3Dverdana,arial,helvetica size=3D1> <A href=3Dhttp://mid.alkonavt.com/> Adobe </A></FONT> <A href=3Dhttp://mid.alkonavt.com/> <FONT face=3Dverdana,arial,helvetica size=3D1> Illustrator 11</FONT></A></TD></TR><TR> <TD width=3D4> &nbsp;</TD> <TD colSpan=3D2 width=3D141> <SPAN class=3Dsmall> <B> <FONT face=3DVerdana size=3D1> See more by this manufacturer</FONT></B></SPAN></TD></TR><TR> <TD width=3D4> &nbsp;</TD> <TD width=3D8> &nbsp;</TD> <TD width!
 =3D129> <FONT face=3Dverdana,arial,helvetica size=3D1> <A href=3Dhttp://mid.alkonavt.com/> Microsoft</A></FONT></TD></TR><TR> <TD width=3D4> &nbsp;</TD>
<TD width=3D8> &nbsp;</TD> <TD width=3D129> <A href=3Dhttp://mid.alkonavt.com/> <FONT face=3Dverdana,arial,helvetica size=3D1> Symantec</FONT></A></TD></TR><TR> <TD width=3D4> &nbsp;</TD> <TD width=3D8> &nbsp;</TD> <TD width=3D129> <FONT face=3Dverdana,arial,helvetica size=3D1> <A href=3Dhttp://mid.alkonavt.com/> Adobe</A></FONT></TD></TR></TABLE></TD></TR></TABLE></TD></TR></TABLE></TD></TR></TABLE></TD> <TD vAlign=3Dtop align=3Dleft width=3D530><TABLE border=3D0 cellpadding=3D0 cellspacing=3D0 style=3D"border-collapse: collapse" bordercolor=3D#111111 width=3D100% id=3DAutoNumber1 height=3D55><TR> <TD width=3D100% height=3D55><P> <B class=3Dsans> Microsoft Office Professional Edition 2003</B> <BR> <SPAN class=3Dsmall> &nbsp;&nbsp;&nbsp;by Microsoft <IMG border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/promotions/sticker/newest_version.gif width=3D82 height=3D14></SPAN></P><P> <A href=3Dhttp://mid.alkonavt.com/> <IMG height=3D150 src=3Dhttp://images.amazon.com/images/!
 P/B0000AZJVC.01.TZZZZZZZ.jpg width=3D118 align=3Dleft border=3D0 name=3Dprod_image hspace=3D5></A></P> <SPAN class=3Dsmall>
<TABLE cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D21 width=3D189><TR> <TD class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73> <B>ListPrice:</B></TD> <TD height=3D18 width=3D11></TD> <TD class=3Dsmall height=3D18 width=3D105> <SPAN class=3Dlistprice> $550.00</SPAN></TD></TR><TR> <TD class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73> <B>OurPrice:</B></TD> <TD height=3D18 width=3D11></TD> <TD class=3Dsmall height=3D18 width=3D105> <B class=3Dprice> $69.95</B></TD></TR><TR> <TD class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D1 width=3D73> <B>YouSave:</B></TD> <TD height=3D1 width=3D11></TD> <TD class=3Dsmall height=3D1 width=3D105> <SPAN class=3Dprice> $480.05 ( 87%)</SPAN></TD></TR></TABLE><P> <A href=3Dhttp://mid.alkonavt.com/> <IMG border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/buttons/add-to-cart-yellow-short.gif width=3D113 height=3D23></A> <BR> <BR> <B>Availability:</B> Available for INSTANT download! <BR>!
 </P><P></SPAN> <BR> <SPAN class=3Dtiny> <B>Sales Rank:</B> #1 <BR></SPAN> <FONT class=3Dtiny> <B>Average Customer Review:</B>
<IMG height=3D12 alt=3D"5 out of 5 stars" src=3Dhttp://g-images.amazon.com/images/G/01/x-locale/common/customer-reviews/stars-5-0.gif width=3D64 border=3D0> <BR>(based on 42 reviews)</FONT></P></FONT><HR noShade SIZE=3D1></TD></TR><TR> <TD width=3D100% height=3D55><P> <B class=3Dsans> Microsoft Windows XP Professional</B> <BR> <SPAN class=3Dsmall> &nbsp;&nbsp;&nbsp;by Microsoft <IMG border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/promotions/sticker/newest_version.gif width=3D82 height=3D14></SPAN></P><P> <A href=3Dhttp://mid.alkonavt.com/> <IMG height=3D150 src=3Dhttp://images.amazon.com/images/P/B00005MOTG.01._SCMZZZZZZZ_.jpg width=3D118 align=3Dleft border=3D0 name=3Dprod_image hspace=3D5></A></P> <SPAN class=3Dsmall><TABLE cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D21 width=3D189><TR> <TD class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73> <B>ListPrice:</B></TD> <TD height=3D18 width=3D11></TD> <TD class=3Dsmall height=3D18 width=3D105!
 > <SPAN class=3Dlistprice> $200.00</SPAN></TD></TR><TR>
<TD class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73> <B>OurPrice:</B></TD> <TD height=3D18 width=3D11></TD> <TD class=3Dsmall height=3D18 width=3D105> <B class=3Dprice> $49.95</B></TD></TR><TR> <TD class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D1 width=3D73> <B>YouSave:</B></TD> <TD height=3D1 width=3D11></TD> <TD class=3Dsmall height=3D1 width=3D105> <SPAN class=3Dprice> $150.05 ( 75%)</SPAN></TD></TR></TABLE><P> <A href=3Dhttp://mid.alkonavt.com/> <IMG border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/buttons/add-to-cart-yellow-short.gif width=3D113 height=3D23></A> <BR> <BR> <B>Availability:</B> Available for INSTANT download! <BR></P><P></SPAN> <BR> <SPAN class=3Dtiny> <B>Sales Rank:</B> #2 <BR></SPAN> <FONT class=3Dtiny> <B>Average Customer Review:</B> <IMG height=3D12 alt=3D"5 out of 5 stars" src=3Dhttp://g-images.amazon.com/images/G/01/x-locale/common/customer-reviews/stars-5-0.gif width=3D64 border=3D0> <BR>(based on 47 reviews)!
 </FONT></P></FONT><HR noShade SIZE=3D1></TD></TR><TR> <TD width=3D100% height=3D55><P> <B class=3Dsans>
Adobe Photoshop CS2 V 9.0</B> <BR> <SPAN class=3Dsmall> &nbsp;&nbsp;&nbsp;by Adobe <IMG border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/promotions/sticker/newest_version.gif width=3D82 height=3D14></SPAN></P><P> <A href=3Dhttp://mid.alkonavt.com/> <IMG height=3D150 src=3Dhttp://images.amazon.com/images/P/B00081I6JI.01._PE7_SCMZZZZZZZ_.jpg width=3D118 align=3Dleft border=3D0 name=3Dprod_image hspace=3D5></A></P> <SPAN class=3Dsmall><TABLE cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D21 width=3D189><TR> <TD class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73> <B>ListPrice:</B></TD> <TD height=3D18 width=3D11></TD> <TD class=3Dsmall height=3D18 width=3D105> <SPAN class=3Dlistprice> $599.00</SPAN></TD></TR><TR> <TD class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73> <B>OurPrice:</B></TD> <TD height=3D18 width=3D11></TD> <TD class=3Dsmall height=3D18 width=3D105> <B class=3Dprice> $69.95</B></TD></TR><TR> <TD class=3Dsmall vAl!
 ign=3Dtop noWrap align=3Dright height=3D1 width=3D73> <B>YouSave:</B></TD> <TD height=3D1 width=3D11></TD> <TD class=3Dsmall height=3D1 width=3D105>
<SPAN class=3Dprice> $529.05 ( 88%)</SPAN></TD></TR></TABLE><P> <A href=3Dhttp://mid.alkonavt.com/> <IMG border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/buttons/add-to-cart-yellow-short.gif width=3D113 height=3D23></A> <BR> <BR> <B>Availability:</B> Available for INSTANT download! <BR></P><P></SPAN> <BR> <SPAN class=3Dtiny> <B>Sales Rank:</B> #3 <BR></SPAN> <FONT class=3Dtiny> <B>Average Customer Review:</B> <IMG height=3D12 alt=3D"5 out of 5 stars" src=3Dhttp://g-images.amazon.com/images/G/01/x-locale/common/customer-reviews/stars-5-0.gif width=3D64 border=3D0> <BR>(based on 32 reviews)</FONT></P></FONT><HR noShade SIZE=3D1></TD></TR></TABLE></TD></TR></TABLE></FORM></TD></TR></TABLE></BODY>
</HTML>

------=_NextPart_000_0001_01C62761.4DF74700--



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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============1990484741==--





From speermint-bounces@ietf.org Thu Feb 02 22:30:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F4reg-0000az-Ln; Thu, 02 Feb 2006 22:30:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F4rXE-0007qk-0A; Thu, 02 Feb 2006 22:22:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15076;
	Thu, 2 Feb 2006 22:21:08 -0500 (EST)
Received: from [59.52.112.52] (helo=3DF1F138)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1F4riX-0002ad-MJ; Thu, 02 Feb 2006 22:34:40 -0500
Received: from mail.brush.yahoo.fr (bullit-approbativeness.yahoo.fr [yahoo.fr])
	by brainache-anapophysis.arthroncus.tv (5.23.5/5.23.5) with ESMTP id
	e17DtWrNh88497
	for <drNOblueoceankncp@yahoo.co.in>; Fri, 03 Feb 2006 06:18:31 +0300
Date: Thu, 02 Feb 2006 22:20:31 -0500
From: "Ronda Smith" <drNOblueoceankncp@yahoo.co.in>
To: speermint@ietf.org, srg@ietf.org, ssm@ietf.org
Message-ID: <2eEj888.ZF293.dk9.210C4E9N2@localhost>
X-Accept-Language: en,zh,ka,je,lo,ja,ko,tr,ru
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Priority: normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: 
Subject: [Speermint] howz going
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Hi speermint@ietf.org,

Thousands of people are stuck with investments that they don't want.

Get signs, flat-fee MLS listings, contracts and free research.=20


U S  $ 300 ,000       oL0 oANS        are avai lable for only $277 / month=
! WE'RE oPRACT ICALLY oGIVIoNG oAWAY MOoNEY!

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

COPY the Addreoss below and paste in your WEoB BROoWSER:

realquikx.com

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

V a l id for 24 Hrs.

His raincoat is there in the overstuffed chair,.
In which I have during the last eight years studied the methods of my frie=
nd Sherlock Holmes,=20.
It might be a bit of the cloak.
To lisp my very earliest word.
Weep not, my darling,.


Bye,
Carmelo Bartlett

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Fri Feb 03 04:32:54 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F4xJG-0000Ap-Hp; Fri, 03 Feb 2006 04:32:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F4xJD-0008WN-Mr
	for speermint@megatron.ietf.org; Fri, 03 Feb 2006 04:32:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09399
	for <speermint@ietf.org>; Fri, 3 Feb 2006 04:31:12 -0500 (EST)
Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4xUX-0005yb-9L
	for speermint@ietf.org; Fri, 03 Feb 2006 04:44:47 -0500
Received: from [220.91.128.23] (helo=65.246.255.50)
	by mx2.foretec.com with smtp (Exim 4.24) id 1F4xIm-0003z3-GN
	for speermint@ietf.org; Fri, 03 Feb 2006 04:32:25 -0500
Received: from wCQ@localhost by yVl.int (8.11.6/8.11.6);
	Fri, 03 Feb 2006 03:46:23 -0500
Message-ID: <wrMX8wmt7sl3QQazb5zZJTX.21mxwntAdR@monteregie.com>
From: "Tiffanie Renee Darwish" <JuliaBrewster@monteregie.com>
To: kaa11471@ietf.org
Date: Fri, 03 Feb 2006 12:49:23 +0400
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2
X-Sender: JuliaBrewster@monteregie.com
Content-Type: multipart/mixed;  boundary="--SqYAjf3zf517Ftx"
X-Spam-Score: 3.6 (+++)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: speermint@ietf.org, aa01256@ietf.org
Subject: [Speermint] MS 2003 Re: OEM Systemworks, Photoshop,
	& Systemworks on s8le Now
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Tiffanie Renee Darwish <JuliaBrewster@monteregie.com>
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

wxRpPzn7S7WAeeFrUzF 

----SqYAjf3zf517Ftx
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3DContent-Language content=3Den-us><meta name=
=3DGS1aLqWEsaHGZP8 content=3DvoNmsqFVpGcUU1IW><meta name=3DDEESObHEiAG con=
tent=3D49G0f0vRU0IG1b><meta http-equiv=3DContent-Type content=3D"text/html=
; charset=3Dwindows-1252"><title>VuTIKNIcDOkC8IIfOI</title></head><body><t=
able border=3D0 cellspacing=3D1 style=3D"border-collapse: collapse" border=
color=3D#111111 width=3D1 id=3DAutoNumber1 height=3D234><tr><td width=3D10=
 height=3D231><font face=3D"Courier New" size=3D2><br><br><br> D<br><br><b=
r> M<br><br><br><br><br><br> A<br><br><br><br><br><br> M<br><br><br><br> A=
<br> &nbsp;</font></td><td width=3D18 height=3D231><font face=3D"Courier N=
ew" size=3D2><br><br><br> ow<br><br><br> ic<br><br><br><br><br><br> do<br>=
 &nbsp;<br><br><br><br><br> ac<br><br><br><br> ut<br> &nbsp;</font></td><t=
d width=3D25 height=3D231><font face=3D"Courier New" size=3D2>&nbsp;<br>&n=
bsp; V<br><br> nlo<br><br><br> ros<br><br><br><br><br><br> be<br> &nbsp;<b=
r><br><br><br><br> rom<br><br><br><br> ode<br> &nbsp;</font></td><td width=
=3D25 height=3D231><font face=3D"Courier New" size=3D2><br>isi<br> &nbsp;<=
br> ad<br> &nbsp;<br><br> oft<br><br><br><br><br><br> Acr<br> Pho<br> Cre<=
br> Go<br> Ill<br><br> edi<br><br><br><br> sk&nbsp;<br> &nbsp;</font></td>=
<td width=3D33 height=3D231><font face=3D"Courier New" size=3D2>&nbsp;<br>=
t Ou<br><br> Inst<br><br><br> &nbsp;Win<br> &nbsp;Off<br> &nbsp;Off<br> &n=
bsp;Ser<br> &nbsp;Ser<br><br> obat<br> tosh<br> ativ<br> Live<br> ustr<br>=
<br> a&nbsp;St<br> &nbsp; Dr<br> &nbsp; Fl<br><br> Auto<br> &nbsp; </font>=
</td><td width=3D33 height=3D231><font face=3D"Courier New" size=3D2><br>r=
 On<br><br> antl<br> &nbsp;<br><br> dows<br> ice<br> ice<br> ver<br> ver<b=
r><br> &nbsp;v7.<br> op C<br> e&nbsp;Su<br> &nbsp;CS2<br> ator<br><br> udi=
o<br> eamw<br> ash<br><br> CAD<br>&nbsp;</font></td><td width=3D17 height=3D=
231><p><font face=3D"Courier New" size=3D2><br>li<br><br> y!<br><br><br> &=
nbsp;X<br> &nbsp;X<br> 2K<br> 2K<br> &nbsp;2<br><br> 0<br> S2<br> it<br><b=
r> &nbsp;1<br><br> &nbsp;M<br> ea<br> MX<br><br> 20<br> &nbsp;</font></p><=
/td><td width=3D17 height=3D231><p><font face=3D"Courier New" size=3D2><br=
>ne<br><br><br><br><br> P<br> P<br> 3<br> 3<br> K<br><br> Pr<br><br> e<br>=
<br> 1.<br><br> X<br> ve<br> &nbsp;P<br><br> 05<br> &nbsp;</font></p></td>=
<td width=3D33 height=3D231><p><font face=3D"Courier New" size=3D2>&nbsp;<=
br>&nbsp;Sto<br><br> &nbsp;<br><br> &nbsp;<br> Pro<br> Pro<br> Pro<br> Ent=
<br> Pro<br><br> o<br><br> 2<br><br> 0 CS<br><br> 2004<br> r 8<br> ro<br>=
<br><br> &nbsp;</font></p></td><td width=3D17 height=3D231><p><font face=3D=
"Courier New" size=3D2><br>re<br><br> Re<br> ..<br><br><br><br><br><br><br=
><br><br><br><br><br><br><br><br><br><br><br><br> &nbsp;</font></p></td><t=
d width=3D17 height=3D231><p><font face=3D"Courier New" size=3D2><br>&nbsp=
;&amp;<br><br> t.<br> ..<br><br> &nbsp;$<br> &nbsp;$<br> &nbsp;$<br> &nbsp=
;$<br> &nbsp;$<br><br> &nbsp;$<br> &nbsp;$<br> &nbsp;$<br> &nbsp;$<br> &nb=
sp;$<br><br> &nbsp;$<br> &nbsp;$<br> &nbsp;$<br> &nbsp;<br> &nbsp;$<br> &n=
bsp;</font></p></td><td width=3D17 height=3D231><p><font face=3D"Courier N=
ew" size=3D2><br>&nbsp;S<br><br> &nbsp;P<br> ..<br><br> 27<br> 49<br> 59<b=
r> 79<br> 66<br><br> 44<br> 59<br> 11<br> 39<br> 49<br><br> 99<br> 39<br> =
54<br><br> 37<br> &nbsp;</font></p></td><td width=3D17 height=3D231><p><fo=
nt face=3D"Courier New" size=3D2><br>av<br><br> ri<br> ..<br><br> 9.<br> 9=
<br> 9.<br> 9.<br> 9.<br><br> 9.<br> 9.<br> 99<br> 9.<br> 9.<br><br> 9.<b=
r> 9.<br> 9.<br><br> 50<br> &nbsp;</font></p></td><td width=3D17 height=3D=
231><p><font face=3D"Courier New" size=3D2><br>e<br><br> ce<br> ..<br><br>=
 00<br> 00<br> 00<br> 00<br> 00<br><br> 00<br> 00<br> .0<br> 00<br> 00<br>=
<br> 00<br> 00<br> 00<br><br> .0<br> &nbsp;</font></p></td><td width=3D17 =
height=3D231><p><font face=3D"Courier New" size=3D2><br>Up<br><br> &nbsp;<=
br><br><br><br><br><br><br><br><br><br><br> 0<br><br><br><br><br><br><br><=
br> 0<br> &nbsp;</font></p></td><td width=3D18 height=3D231><p><font face=3D=
"Courier New" size=3D2><b><br></b>&nbsp;t<br> <b><br> Ou<br> ..<br><br><br=
><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br> &nbsp;</=
b></font></p></td><td width=3D18 height=3D231><p><font face=3D"Courier New=
" size=3D2><b><br></b>o<b><br><br> r<br> ..<br><br> $4<br> $4<br> $6<br> $=
6<br> $6<br><br> $6<br> $6<br> $9<br> $4<br> $4<br><br> $6<br> $4<br> $3<b=
r><br> $9<br> &nbsp;</b></font></p></td><td width=3D18 height=3D231><p><fo=
nt face=3D"Courier New" size=3D2><b><br></b>90<b><br><br> Pr<br> ..<br><br=
> 9.<br> 9.<br> 9.<br> 9.<br> 9.<br><br> 9.<br> 9.<br> 9.<br> 9.<br> 9.<br=
><br> 9.<br> 9.<br> 9.<br><br> 9.<br> &nbsp;</b></font></p></td><td width=3D=
18 height=3D231><p><font face=3D"Courier New" size=3D2><b><br></b>=
%<b><br><br> ic<br> ..<br><br> 99<br> 99<br> 99<br> 99<br> 99<br><br> 99<b=
r> 99<br> 99<br> 99<br> 99<br><br> 99<br> 99<br> 99<br><br> 95<br> &nbsp;<=
/b></font></p></td><td width=3D18 height=3D231><p><font face=3D"Courier Ne=
w" size=3D2><b><br></b>Of<b><br><br> e<br> .<br><br><br><br><br><br><br><b=
r><br><br><br><br><br><br><br><br><br><br><br> &nbsp;</b></font></p></td><=
td width=3D18 height=3D231><p><font face=3D"Courier New" size=3D2><b><br><=
/b>f!<b><br><br> &nbsp;Y<br> &nbsp;.<br><br> &nbsp;O<br> &nbsp;O<br> &nbsp=
;O<br> &nbsp;O<br> &nbsp;O<br><br> &nbsp;O<br> &nbsp;O<br> &nbsp;O<br> &nb=
sp;O<br> &nbsp;O<br><br> &nbsp;O<br> &nbsp;O<br> &nbsp;O<br><br> Ov<br> &n=
bsp;</b></font></p></td><td width=3D18 height=3D231><p><b><font face=3D"Co=
urier New" size=3D2><br><br><br> ou<br> ..<br><br> ve<br> ve<br> ve<br> ve=
<br> ve<br><br> ve<br> ve<br> vr<br> ve<br> ve<br><br> ve<br> ve<br> ve<br=
><br> er<br> &nbsp;</font></b></p></td><td width=3D18 height=3D231><p><b><=
font face=3D"Courier New" size=3D2><br><br><br> &nbsp;S<br> ..<br><br> r<b=
r> r<br> r<br> r<br> r<br><br> r<br> r<br> &nbsp;$<br> r<br> r<br><br> r<b=
r> r<br> r<br><br> &nbsp;$<br> &nbsp;</font></b></p></td><td width=3D18 he=
ight=3D231><p><b><font face=3D"Courier New" size=3D2><br><br><br> av<br> .=
<br><br> $2<br> $4<br> $5<br> $7<br> $7<br><br> $3<br> $5<br> 10<br> $3<b=
r> $4<br><br> $9<br> $3<br> $5<br><br> 36<br> &nbsp;</font></b></p></td><t=
d width=3D20 height=3D231><p><b><font face=3D"Courier New" size=3D2><br><b=
r><br> e<br> .<br><br> 29<br> 49<br> 29<br> 29<br> 00<br><br> 79<br> 29<br=
> 49<br> 49<br> 49<br><br> 29<br> 49<br> 09<br><br> 50<br> &nbsp;</font></=
b></p></td></tr></table><p><font face=3D"Courier New" size=3D2><a href=3Dh=
ttp://oembariga.com/?VJYlIyVBXaYWexo3zl4T5>http://oembariga.com/?AaR6ijWas=
3nQJUaUJd9z4U</a></a></font></p></body></html>

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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

----SqYAjf3zf517Ftx--




From speermint-bounces@ietf.org Fri Feb 03 09:41:05 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F527V-0003e3-Le; Fri, 03 Feb 2006 09:41:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F527U-0003cw-5C
	for speermint@megatron.ietf.org; Fri, 03 Feb 2006 09:41:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03958
	for <speermint@ietf.org>; Fri, 3 Feb 2006 09:39:18 -0500 (EST)
Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]
	helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F52Ix-0004US-E2
	for speermint@ietf.org; Fri, 03 Feb 2006 09:52:55 -0500
Received: from ([10.20.62.12])
	by paoakoavas09.cable.comcast.com with ESMTP  id KP-TDCH7.16789500;
	Fri, 03 Feb 2006 09:40:21 -0500
Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by
	PACDCEXCRLY02.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 09:40:22 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 3 Feb 2006 09:40:21 -0500
Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A0D5@PACDCEXCMB01.cable.comcast.com>
Thread-Topic: Continued Spam On speermint
Thread-Index: AcYoz8J5XohW+6blR1qRrw0ychSriA==
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: <speermint@ietf.org>
X-OriginalArrivalTime: 03 Feb 2006 14:40:22.0110 (UTC)
	FILETIME=[C2F957E0:01C628CF]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Subject: [Speermint] Continued Spam On speermint
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0439520189=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0439520189==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C628CF.C2B4556D"

This is a multi-part message in MIME format.

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

Apologies that spam is still making it onto the list by people cc'ing
the list (as non-subscribers).  We have escalated the problem to IETF
Secretariat Services and they are investigating.  We hope this will be
worked out very soon.  Thanks for your continued patience.
=20
Regards
Jason Livingood

------_=_NextPart_001_01C628CF.C2B4556D
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.2627" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D745553814-03022006>Apologies that spam=20
is still&nbsp;making it onto the list by people cc'ing the list (as=20
non-subscribers).&nbsp; We have escalated the problem to IETF =
Secretariat=20
Services and they are investigating.&nbsp; We hope this will be worked =
out very=20
soon.&nbsp; Thanks for your continued patience.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D745553814-03022006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D745553814-03022006>Regards</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D745553814-03022006>Jason=20
Livingood</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C628CF.C2B4556D--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============0439520189==--




From speermint-bounces@ietf.org Fri Feb 03 09:46:33 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F52Cm-0006Mr-W9; Fri, 03 Feb 2006 09:46:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F52Cl-0006Ly-En
	for speermint@megatron.ietf.org; Fri, 03 Feb 2006 09:46:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04413
	for <speermint@ietf.org>; Fri, 3 Feb 2006 09:44:53 -0500 (EST)
Received: from m106.maoz.com ([205.167.76.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F52OL-0004gB-Da
	for speermint@ietf.org; Fri, 03 Feb 2006 09:58:31 -0500
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])
	by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k13Ek599019665
	for <speermint@ietf.org>; Fri, 3 Feb 2006 06:46:05 -0800
Received: (from dmm@localhost)
	by m106.maoz.com (8.13.4/8.12.11/Submit) id k13Ek5AL019664
	for speermint@ietf.org; Fri, 3 Feb 2006 06:46:05 -0800
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using
	-f
Date: Fri, 3 Feb 2006 06:46:05 -0800
From: David Meyer <dmm@1-4-5.net>
To: speermint@ietf.org
Message-ID: <20060203144605.GA19652@1-4-5.net>
Mime-Version: 1.0
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader,
	Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Subject: [Speermint] FYI -- [ietf-secretariat@ietf.org: Internet-Drafts
	Submission Cutoff Dates for the 65th IETF Meeting in Dallas,
	TX, USA]
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0927744698=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org


--===============0927744698==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr"
Content-Disposition: inline


--PNTmBPCT7hxwcZjr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

----- Forwarded message from ietf-secretariat@ietf.org -----

> From: ietf-secretariat@ietf.org
> To: ietf-announce@ietf.org
> Subject: Internet-Drafts Submission Cutoff Dates for the 65th IETF Meeting
>  in Dallas, TX, USA=20
> Date: Fri, 03 Feb 2006 00:00:01 -0500
>=20
>=20
> There are two (2) Internet-Draft cutoff dates for the 65th=20
> IETF Meeting in Dallas, TX, USA:
>=20
> February 27th: Cutoff Date for Initial (i.e., version -00)=20
> Internet-Draft Submissions=20
>=20
> All initial Internet-Drafts (version -00) must be submitted by Monday,=20
> February 27th at 9:00 AM ET. As always, all initial submissions with a=20
> filename beginning with "draft-ietf" must be approved by the=20
> appropriate WG Chair before they can be processed or announced.  The=20
> Secretariat would appreciate receiving WG Chair approval by Monday,=20
> February 20th at 9:00 AM ET.
>=20
> March 6th: Cutoff Date for Revised (i.e., version -01 and higher)=20
> Internet-Draft Submissions=20
>=20
> All revised Internet-Drafts (version -01 and higher) must be submitted=20
> by Monday, March 6th at 9:00 AM ET.
>=20
> Initial and revised Internet-Drafts received after their respective=20
> cutoff dates will not be made available in the Internet-Drafts=20
> directory or announced until on or after Monday, March 20th at 9:00=20
> AM ET, when Internet-Draft posting resumes.  Please do not wait until=20
> the last minute to submit.
>=20
> Thank you for your understanding and cooperation. If you have any=20
> questions or concerns, then please send a message to=20
> internet-drafts@ietf.org.
>=20
> The IETF Secretariat
>=20
> FYI: The Internet-Draft cutoff dates as well as other significant dates
> for the 65th IETF Meeting can be found at http://www.ietf.org/meetings/cu=
toff_dates_65.html.
>=20
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce

----- End forwarded message -----

--PNTmBPCT7hxwcZjr
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFD42ytORgD1qCZ2KcRAlOnAJ4vPKgl1ZLZ9ESMg/XNo4IfF5iD9QCfaKNn
xcg1PqjNbJf8Udb/cWs7ZxQ=
=appv
-----END PGP SIGNATURE-----

--PNTmBPCT7hxwcZjr--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============0927744698==--




From speermint-bounces@ietf.org Fri Feb 03 11:38:27 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F53x5-00035N-Ly; Fri, 03 Feb 2006 11:38:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F53x3-00034z-Ql
	for speermint@megatron.ietf.org; Fri, 03 Feb 2006 11:38:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18198
	for <speermint@ietf.org>; Fri, 3 Feb 2006 11:36:47 -0500 (EST)
Received: from m106.maoz.com ([205.167.76.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F548g-000213-0F
	for speermint@ietf.org; Fri, 03 Feb 2006 11:50:26 -0500
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])
	by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k13GcFGe023172;
	Fri, 3 Feb 2006 08:38:15 -0800
Received: (from dmm@localhost)
	by m106.maoz.com (8.13.4/8.12.11/Submit) id k13GcFY8023171;
	Fri, 3 Feb 2006 08:38:15 -0800
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using
	-f
Date: Fri, 3 Feb 2006 08:38:15 -0800
From: David Meyer <dmm@1-4-5.net>
To: speermint@ietf.org
Message-ID: <20060203163815.GA23097@1-4-5.net>
Mime-Version: 1.0
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader,
	Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: Jason_Livingood@cable.comcast.com, jon.peterson@neustar.biz
Subject: [Speermint] speermint now a working group
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1293679193=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org


--===============1293679193==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+"
Content-Disposition: inline


--8t9RHnE3ZwKMSgU+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

	Folks,

	The IESG ok'ed the speermint charter yesterday, with=20
	Jason and me will as the co-chairs. So we're ready to
	go. I'll request a slot for Dallas, and I would like all
	of you to submit proposed agenda items to Jason and me.

	We'd also like to thank Allison Mankin for all of her
	support in shepherding us through the process, and Jon
	Peterson for his support in getting the WG chartered.

	Looking forward to seeing you all in Dallas.

	Dave & Jason




--8t9RHnE3ZwKMSgU+
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFD44b3ORgD1qCZ2KcRAvi4AJ9FnaDLvgw8dvaSoOGtpfwBvG23CgCfdnPV
RKmxrYTtuZqJ0yPn6xomPi8=
=wE17
-----END PGP SIGNATURE-----

--8t9RHnE3ZwKMSgU+--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============1293679193==--




From speermint-bounces@ietf.org Fri Feb 03 12:11:15 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F54Sp-0005ua-3M; Fri, 03 Feb 2006 12:11:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F54S0-0005of-Ti
	for speermint@megatron.ietf.org; Fri, 03 Feb 2006 12:10:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20738
	for <speermint@ietf.org>; Fri, 3 Feb 2006 12:08:38 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F54dU-000322-O1
	for speermint@ietf.org; Fri, 03 Feb 2006 12:22:18 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Speermint] speermint now a working group
Date: Fri, 3 Feb 2006 18:10:07 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C47FD@oefeg-s04.oefeg.loc>
Thread-Topic: [Speermint] speermint now a working group
Thread-Index: AcYo4NZyYnmFojL1RmyWyrGUmZWUBQAA9g+/
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "David Meyer" <dmm@1-4-5.net>, <speermint@ietf.org>
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Content-Transfer-Encoding: quoted-printable
Cc: Jason_Livingood@cable.comcast.com, jon.peterson@neustar.biz
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Great,
=20
I consider this an important achievment for the future of IP Telephony
=20
Congratulations and thanx to all involved, especially to the co-chairs
=20
Richard Stastmy

________________________________

Von: speermint-bounces@ietf.org im Auftrag von David Meyer
Gesendet: Fr 03.02.2006 17:38
An: speermint@ietf.org
Cc: Jason_Livingood@cable.comcast.com; jon.peterson@neustar.biz
Betreff: [Speermint] speermint now a working group



        Folks,

        The IESG ok'ed the speermint charter yesterday, with
        Jason and me will as the co-chairs. So we're ready to
        go. I'll request a slot for Dallas, and I would like all
        of you to submit proposed agenda items to Jason and me.

        We'd also like to thank Allison Mankin for all of her
        support in shepherding us through the process, and Jon
        Peterson for his support in getting the WG chartered.

        Looking forward to seeing you all in Dallas.

        Dave & Jason






_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Fri Feb 03 12:53:14 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F557S-0001Z8-8g; Fri, 03 Feb 2006 12:53:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F557Q-0001YX-2Q
	for speermint@megatron.ietf.org; Fri, 03 Feb 2006 12:53:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24137
	for <speermint@ietf.org>; Fri, 3 Feb 2006 12:51:19 -0500 (EST)
Received: from m106.maoz.com ([205.167.76.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F55In-00051U-MY
	for speermint@ietf.org; Fri, 03 Feb 2006 13:04:59 -0500
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])
	by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k13HqkLw027337;
	Fri, 3 Feb 2006 09:52:46 -0800
Received: (from dmm@localhost)
	by m106.maoz.com (8.13.4/8.12.11/Submit) id k13Hqf42027335;
	Fri, 3 Feb 2006 09:52:41 -0800
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using
	-f
Date: Fri, 3 Feb 2006 09:52:41 -0800
From: David Meyer <dmm@1-4-5.net>
To: Stastny Richard <Richard.Stastny@oefeg.at>
Subject: Re: [Speermint] speermint now a working group
Message-ID: <20060203175241.GA27315@1-4-5.net>
References: <32755D354E6B65498C3BD9FD496C7D462C47FD@oefeg-s04.oefeg.loc>
Mime-Version: 1.0
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C47FD@oefeg-s04.oefeg.loc>
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader,
	Star Wars Episode IV.
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: speermint@ietf.org, Jason_Livingood@cable.comcast.com,
	jon.peterson@neustar.biz
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1253835704=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org


--===============1253835704==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo"
Content-Disposition: inline


--envbJBWh7q8WU6mo
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 03, 2006 at 06:10:07PM +0100, Stastny Richard wrote:
> Great,
> =20
> I consider this an important achievment for the future of IP Telephony
> =20
> Congratulations and thanx to all involved, especially to the co-chairs

	Agreed, and thanks very much. Time to do the work now!=20

	Dave


> =20
> Richard Stastmy
>=20
> ________________________________
>=20
> Von: speermint-bounces@ietf.org im Auftrag von David Meyer
> Gesendet: Fr 03.02.2006 17:38
> An: speermint@ietf.org
> Cc: Jason_Livingood@cable.comcast.com; jon.peterson@neustar.biz
> Betreff: [Speermint] speermint now a working group
>=20
>=20
>=20
>         Folks,
>=20
>         The IESG ok'ed the speermint charter yesterday, with
>         Jason and me will as the co-chairs. So we're ready to
>         go. I'll request a slot for Dallas, and I would like all
>         of you to submit proposed agenda items to Jason and me.
>=20
>         We'd also like to thank Allison Mankin for all of her
>         support in shepherding us through the process, and Jon
>         Peterson for his support in getting the WG chartered.
>=20
>         Looking forward to seeing you all in Dallas.
>=20
>         Dave & Jason
>=20
>=20
>=20
>=20
>=20

--envbJBWh7q8WU6mo
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFD45hpORgD1qCZ2KcRAqrVAJoCDCz7AVNDXV1RFbwpA0jiEHtYHgCfWV4x
6x1mwuEMIPtHT5sh+O7BisI=
=Kxev
-----END PGP SIGNATURE-----

--envbJBWh7q8WU6mo--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============1253835704==--




From speermint-bounces@ietf.org Fri Feb 03 17:22:50 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F59KM-0001lb-Le; Fri, 03 Feb 2006 17:22:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F59KI-0001kz-Ps; Fri, 03 Feb 2006 17:22:48 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20902;
	Fri, 3 Feb 2006 17:20:50 -0500 (EST)
Received: from m106.maoz.com ([205.167.76.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F59Ve-0001Ba-M8; Fri, 03 Feb 2006 17:34:32 -0500
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])
	by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k13MMHXs010488;
	Fri, 3 Feb 2006 14:22:17 -0800
Received: (from dmm@localhost)
	by m106.maoz.com (8.13.4/8.12.11/Submit) id k13MMHQR010487;
	Fri, 3 Feb 2006 14:22:17 -0800
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using
	-f
Date: Fri, 3 Feb 2006 14:22:17 -0800
From: David Meyer <dmm@1-4-5.net>
To: internet-drafts@ietf.org
Message-ID: <20060203222217.GA10462@1-4-5.net>
Mime-Version: 1.0
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader,
	Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d01c7b9466fe967a5df27b46fdb03146
Cc: speermint@ietf.org
Subject: [Speermint] please post draft-speermint-reqs-and-terminology-00.txt
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1672997850=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org


--===============1672997850==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh"
Content-Disposition: inline


--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


	internet-drafts: The speermint working group was ok'ed at
	the last IESG telechat. I'm not sure about the timing
	issues here, but please post this if possible. If not,
	please let me know if I need to resubmit it at a later
	date.

	Thanks,

	Dave
---


Network Working Group                                           D. Meyer
Internet-Draft                                          February 3, 2005
Expires: August 7, 2005


                 SPEERMINT Requirements and Terminology
              draft-speermint-reqs-and-terminology-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 7, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document outlines the solutions space requirements and defines
   the terminology that is to be used by the Session PEERing for
   Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
   primary objective to focus the working group during its discussions,
   and when writing requirements, gap analysis and other solutions
   oriented documents.






Meyer                    Expires August 7, 2005                 [Page 1]

Internet-Draft   SPEERMINT Requirements and Terminology    February 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Context  . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Unified solution for all peering policies  . . . . . . . .  4
     3.2.  Domain Based . . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  No blocked calls . . . . . . . . . . . . . . . . . . . . .  5
     3.4.  Scaling  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.5.  Independence of lower layers . . . . . . . . . . . . . . .  5
     3.6.  Administrative and technical policies  . . . . . . . . . .  5
     3.7.  Minimal additional cost on call initiation . . . . . . . .  6
     3.8.  Look beyond SIP  . . . . . . . . . . . . . . . . . . . . .  6
   4.  General Definitions  . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Call Routing Data  . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Call Routing . . . . . . . . . . . . . . . . . . . . . . .  6
     4.3.  PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.4.  Network  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.5.  VoIP Service Provider  . . . . . . . . . . . . . . . . . .  7
     4.6.  Peering  . . . . . . . . . . . . . . . . . . . . . . . . .  7
       4.6.1.  Layer 3 Peering  . . . . . . . . . . . . . . . . . . .  7
       4.6.2.  Layer 5 Peering  . . . . . . . . . . . . . . . . . . .  7
     4.7.  VoIP Peering . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Carrier of Record  . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Public ENUM  . . . . . . . . . . . . . . . . . . . . . . .  8
     5.3.  Private ENUM . . . . . . . . . . . . . . . . . . . . . . .  8
     5.4.  Carrier ENUM . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     10.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
   Intellectual Property and Copyright Statements . . . . . . . . . . 12














Meyer                    Expires August 7, 2005                 [Page 2]

Internet-Draft   SPEERMINT Requirements and Terminology    February 2005


1.  Introduction

   The term "VoIP Peering" has historically been used to describe a wide
   variety of aspects pertaining to the interconnection of service
   provider networks and to the delivery of SIP call termination over
   those interconnections.  The discussion of these interconnections has
   at times been confused by the fact that the term "peering" is used in
   various contexts to relate to interconnection at different levels in
   a protocol stack.  Session Peering for Multimedia Interconnect
   focuses on how to identify and route real-time sessions (such as VoIP
   calls) at the application layer, and it does not (necessarily)
   involve the exchange of packet routing data or media sessions.  In
   particular, "layer 5 network" is used here to refer to the
   interconnection between SIP servers, as opposed to interconnection at
   the IP layer ("layer 3").  Finally, the terms "peering" and
   "interconnect" are used interchangeably throughout this document.

   This document introduces standard terminology for use in
   characterizing real-time session interconnection.  Note however, that
   while this document is primarily targeted at the VoIP interconnect
   case, the terminology described here is applicable to those cases in
   which service providers interconnect using SIP signaling for real-
   time or quasi-real-time communications.

   The remainder of this document is organized as follows: Section 3
   provides the requirements for SPEERMINT working group solutions.
   Section 2 provides the general context for the VOIPEER Working Group,
   and Section 4 provides the general definitions for real-time SIP
   based communication, with focus on the VoIP interconnect case.
   Section 5 briefly touches on terms from the ENUM Working Group.
   Finally, Section 6 provides comments on usage.


2.  Context

   Figure 1 depicts the general VoIP interconnect context.  In this
   case, the caller uses an E.164 number [ITU.E164.1991] as the "name"
   of the called user.  Note that this E.164 number is not an address,
   since at this point we do not have information about where the named
   endpoint is located.  In the case shown here, an E.164 number is used
   as a key to retrieve a NAPTR recored [RFC3404] from the DNS, which in
   turn resolved into a SIP URI.  Call routing is based on this SIP URI.
   The call routing step does not depend on the presence of an E.164
   number; the SIP URI can be advertised in various other ways, such as
   on a web page.  Finally, note that the subsequent lookup steps,
   namely, lookup of SRV, A, and AAAA records (as well as any routing
   steps below that) are outside the scope of VOIPEER.




Meyer                    Expires August 7, 2005                 [Page 3]

Internet-Draft   SPEERMINT Requirements and Terminology    February 2005


           E.164 number <--- Peer Discovery
                |
                | <--- ENUM lookup of NAPTR in DNS
                |
                |
                | ENUM Working Group Scope
           =====+=======================================
                | VOIPEER Working Group Scope
                |
                |
           SIP URI <--- Call Routing Data (CRD)
                |
                | <--- Service Location (Lookup of SRV in DNS)
                |
                |
           Hostname <--- VoIP addressing and session establishment
                |
                | <---- Lookup of A and AAAA in DNS
                |
           Ip address
                |
                | <---- Routing protocols, ARP etc
                |
           Mac-address

   Figure 1: VoIP Interconnect Context

   The ENUM Working Group is primarily concerned with the acquisition of
   Call Routing Data, or CRD (i.e., above the double line in Figure 1),
   while the VOIPEER Working Group is focused on the use of such CRD.
   Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS
   entry), or via any other mechanism available to the user.


3.  Requirements

   A system for real-time session interconnection must satisfy the
   following requirements:

3.1.  Unified solution for all peering policies

   Policies developed in the context of the SPEERMINT working group must
   be extensible and flexible enough to cover existing and future
   peering policies.  These start by a closed system which accepts only
   incoming calls from selected peers (i.e. a set of bilateral peerings)
   and include the model of membership in a number of peering fabrics or
   carrier clubs.  The case of an open SIP proxy should be covered as a
   special case as well.



Meyer                    Expires August 7, 2005                 [Page 4]

Internet-Draft   SPEERMINT Requirements and Terminology    February 2005


3.2.  Domain Based

   Although the initial call routing may be based on E.164 numbers, a
   generic peering methodology should not rely on such numbers.  Rather,
   call routing should rely on URIs.  We assume that all SIP URIs with
   the same domain-part share the same set of peering policies, thus the
   domain of the SIP URI may be used as the primary key to any
   information regarding the reachability of that SIP URI.

3.3.  No blocked calls

   An originating Voice Service Provider, or VSP, must be able to
   determine whether a SIP URI is open for direct interconnection
   without actually sending a SIP INVITE.  This is important as
   unsuccessful call attempts are highly undesirable since they can
   introduce high delays due to timeouts and can act as an unintended
   denial of service attack. (e.g., by repeated TLS handshakes).

3.4.  Scaling

   The maintenance of the system needs to scale beyond simple lists of
   peering partners.  In particular, it must incorporate aggregation
   mechanisms which avoid O(n2) scaling (where n is the number of
   participating VoIP services).  Per-VSP opt-in without consultation of
   a centralized 'peering registry', but rather by publishing local
   configuration choices only is highly desirable.  The distributed
   management of the DNS is a good example for the scalability of this
   approach.

3.5.  Independence of lower layers

   The system needs to be independent of details on what technologies
   are used route the call and which are used to ensure that only
   approved peering partner actually connect to the destination SIP
   proxy.  It should not matter whether restrictions are implemented by
   private L3 connectivity ("walled gardens"), firewalls, TLS policies
   or SIP proxy configuration.

3.6.  Administrative and technical policies

   The reasons for declining vs. accepting incoming calls from a
   prospective peering partner can be both administrative (contractual,
   legal, commercial, or business decisions) and technical (certain QoS
   parameters, TLS keys, domain keys, ...).  Methodologies developed by
   the SPEERMINT working group should accommodate all policies.






Meyer                    Expires August 7, 2005                 [Page 5]

Internet-Draft   SPEERMINT Requirements and Terminology    February 2005


3.7.  Minimal additional cost on call initiation

   Since each call setup implies execution of any proposed algorithm it
   should incur minimal overhead and delay, and employ caching wherever
   possible to avoid extra protocol round trips.

3.8.  Look beyond SIP

   The problem of selective peering is not limited to SIP-based
   communication.  Other protocols may benefit from a generic framework
   as well, such as SMTP mail.  Any solutions proposed by the SPEERMINT
   working group must be generic enough to encompass other protocols as
   well.


4.  General Definitions

4.1.  Call Routing Data

   Call Routing Data, or CRD, is a SIP URI used to route a call (real-
   time, voice or other type) to the called domain's ingress point.  A
   domain's ingress point can be thought of as the location pointed to
   by the SRV record that resulted from the resolution of the CRD (i.e.,
   a SIP URI).

4.2.  Call Routing

   Call routing is the set of processes, rules, and CRD used to route a
   VoIP call to its proper (SIP) destination.  More generally, call
   routing can be thought of as the set of processes, rules and CRD
   which are used to route a real-time session to its termination
   (ingress) point.

4.3.  PSTN

   The term "PSTN" refers to the Public Switched Telephone Network.  In
   particular, the PSTN refers to the collection of interconnected
   circuit-switched voice-oriented public telephone networks, both
   commercial and government-owned.  In general, PSTN terminals are
   addressed using E.164 numbers, noting that various dial-plans (such
   as emergency services dial-plans) may not directly use E.164 numbers.

4.4.  Network

   For purposes of this document and the VOIPEER and ENUM Working
   Groups, a network is defined to be the set of SIP servers and end-
   users (customers) that are controlled by a single administrative
   domain.  The network may also contain end-users who are located on



Meyer                    Expires August 7, 2005                 [Page 6]

Internet-Draft   SPEERMINT Requirements and Terminology    February 2005


   the PSTN.

4.5.  VoIP Service Provider

   A VoIP service provider is an entity that provides transport of SIP
   signaling (and possibly media streams) to its customers.  Such a
   service provider may additionally be interconnected with other
   service providers; that is, it may "peer" with other service
   providers.  A VoIP service provider may also interconnect with the
   PSTN.

   Note that as soon as a ingress point is advertised via a SRV record,
   anyone can find that ingress point and hence can send calls there.
   This is very similar to sending mail to a SMTP server based on the
   existence of a MX record.

4.6.  Peering

   While the precise definition of the term "peering" is the subject of
   some debate, peering in general refers to the negotiation of
   reciprocal interconnection arrangements, settlement-free or
   otherwise, between operationally independent service providers.

   This document distinguishes two types of peering, Layer 3 Peering and
   Layer 5 peering, which are described below.

4.6.1.  Layer 3 Peering

   Layer 3 peering refers to interconnection of two service providers
   for the purposes of exchanging IP packets which destined for one (or
   both) of the peer's networks.  Layer 3 peering is generally agnostic
   to the IP payload, and is frequently achieved using a routing
   protocol such as BGP [RFC1771] to exchange the required routing
   information.

   An alternate, perhaps more operational definition of layer 3 peering
   is that two peers exchange only customer routes, and hence any
   traffic between peers terminates on one of the peer's network.

4.6.2.  Layer 5 Peering

   Layer 5 peering refers to interconnection of two service providers
   for the purposes of SIP signaling.  Note that in the layer 5 peering
   case, there is no intervening network.  That is, for purposes of this
   discussion, there is no such thing as a "Layer 5 Transit Network".






Meyer                    Expires August 7, 2005                 [Page 7]

Internet-Draft   SPEERMINT Requirements and Terminology    February 2005


4.7.  VoIP Peering

   VoIP peering is defined to be a layer 5 peering between two VoIP
   providers for purposes of routing real-time (or quasi-real time) call
   signaling between their respective customers.  Media streams
   associated with this signaling (if any) are not constrained to follow
   the same set of paths.


5.  ENUM

   ENUM [RFC3761] defines how the Domain Name System (DNS) can be used
   for identifying available services connected to one E.164 number.

5.1.  Carrier of Record

   For purposes of this document, "Carrier of Record", or COR, refers to
   the entity that provides PSTN service for an E.164 number [I-D.lind-
   infrastructure-enum-reqs].  The exact definition of who and what is a
   COR is ultimately the responsibility of the relevant NRA.

5.2.  Public ENUM

   Public ENUM is generally defined as the set administrative policies
   and procedures surrounding the use of the e164.arpa domain for
   Telephone Number to URI resolution [RFC3761].  Policies and
   procedures for the registration of telephone numbers within all
   branches of the e164.arpa tree are Nation State issues by agreement
   with the IAB and ITU.  National Regulatory Authorities have generally
   defined Public ENUM Registrants as the E.164 number holder as opposed
   to the COR that issued the phone number.

5.3.  Private ENUM

   Private ENUM is generally regarded as one or more technologies
   (including DNS and SIP Redirect) that service providers or
   enterprises may use to exchange phone number to URI mappings in a
   private secure manner.  Private ENUM may be used in any mutually
   agreed upon domain.  Records in Private ENUM may be globally visible
   but in most cases are not visible to the global Internet and are
   protected using a variety of security technologies such as split-DNS,
   VPN's or various forms or authentication and authorization.
   Technical comments on issues surrounding split-DNS can be found in
   [RFC2826].

5.4.  Carrier ENUM

   Carrier ENUM is generally regarded as the use of a separate branch



Meyer                    Expires August 7, 2005                 [Page 8]

Internet-Draft   SPEERMINT Requirements and Terminology    February 2005


   the e164.arpa tree, such as 4.4.c.e164.arpa to permit service
   providers to exchange phone number to URI data in order to find
   points of interconnection.  The current theory of Carrier ENUM is
   that only the COR for a particular E.164 number is permitted to
   provision data for that E.164 within that portion of the e164.arpa
   tree.

   In carrier ENUM case, only the COR may enter data in the
   corresponding domain.  The COR may also enter CRD (i.e., a SIP URI)
   to allow other VoIP Service Providers to route calls to its network.

   Finally, note that ENUM is not constrained to carry only data (CDR)
   as defined by VOIPEER.  In particular, an an important class of CRD,
   the tel URIs [RFC3966] may be carried in ENUM.  Such tel URIs are
   most frequently used to interconnect with the PSTN directly, and are
   out of scope for VOIPEER.  On the other hand, PSTN endpoints served
   by a COR and reachable via CDR and networks as defined in Section 4.1
   and Section 4.4 are in scope for VOIPEER.


6.  Conclusions


7.  Acknowledgments

   Many of the definitions were gleaned from detailed discussions on the
   VOIPEER, ENUM, and SIPPING mailing lists.  Scott Brim, Mike Hammer,
   Jean-Francois Mule, Richard Shocky, and Richard Stastny made valuable
   contributions to early revisions of this document.  Patrik Faltstrom
   also made many insightful comments to early versions of this draft,
   and contributed the basis of Figure 1.  Finally, Otmar Lendl
   contributed much of the text found in the Requirements section.


8.  Security Considerations

   This document itself introduces no new security considerations.
   However, it is important to note that VoIP interconnect has a wide
   variety of security issues that should be considered in documents
   addressing both protocol and use case analyzes.


9.  IANA Considerations

   This document creates no new requirements on IANA namespaces
   [RFC2434].





Meyer                    Expires August 7, 2005                 [Page 9]

Internet-Draft   SPEERMINT Requirements and Terminology    February 2005


10.  References

10.1.  Normative References

   [RFC3404]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Four: The Uniform Resource Identifiers (URI)",
              RFC 3404, October 2002.

   [RFC3761]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform
              Resource Identifiers (URI) Dynamic Delegation Discovery
              System (DDDS) Application (ENUM)", RFC 3761, April 2004.

   [ITU.E164.1991]
              International Telecommunications Union, "The International
              Public Telecommunication Numbering Plan", ITU-
              T Recommendation E.164, 1991.

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
              RFC 3966, December 2004.

10.2.  Informative References

   [RFC1771]  Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
              (BGP-4)", RFC 1771, March 1995.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
              Unique DNS Root", RFC 2826, May 2000.

   [I-D.lind-infrastructure-enum-reqs]
              Lind, S., "Infrastructure ENUM Requirements",
              draft-lind-infrastructure-enum-reqs-00 (work in progress),
              July 2005.















Meyer                    Expires August 7, 2005                [Page 10]

Internet-Draft   SPEERMINT Requirements and Terminology    February 2005


Author's Address

   David Meyer

   Email: dmm@1-4-5.net














































Meyer                    Expires August 7, 2005                [Page 11]

Internet-Draft   SPEERMINT Requirements and Terminology    February 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Meyer                    Expires August 7, 2005                [Page 12]


--jI8keyz6grp/JLjh
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFD49eZORgD1qCZ2KcRAuPMAJ932OZ9KPa38CePu8Iem8hvOlRKBACfR/0X
M1uQEhuxXq97wFnRHnYrIGA=
=aBNH
-----END PGP SIGNATURE-----

--jI8keyz6grp/JLjh--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============1672997850==--




From speermint-bounces@ietf.org Sat Feb 04 13:30:27 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F5SB1-0006rf-41; Sat, 04 Feb 2006 13:30:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F5SAz-0006qm-6X
	for speermint@megatron.ietf.org; Sat, 04 Feb 2006 13:30:25 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27302
	for <speermint@ietf.org>; Sat, 4 Feb 2006 13:28:37 -0500 (EST)
Received: from m106.maoz.com ([205.167.76.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5SMf-0007Wg-Tc
	for speermint@ietf.org; Sat, 04 Feb 2006 13:42:31 -0500
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])
	by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k14IU3aE028443;
	Sat, 4 Feb 2006 10:30:03 -0800
Received: (from dmm@localhost)
	by m106.maoz.com (8.13.4/8.12.11/Submit) id k14IU31V028442;
	Sat, 4 Feb 2006 10:30:03 -0800
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using
	-f
Date: Sat, 4 Feb 2006 10:30:03 -0800
From: David Meyer <dmm@1-4-5.net>
To: speermint@ietf.org
Subject: Re: [Speermint] please post
	draft-speermint-reqs-and-terminology-00.txt
Message-ID: <20060204183003.GA28416@1-4-5.net>
References: <20060203222217.GA10462@1-4-5.net>
Mime-Version: 1.0
In-Reply-To: <20060203222217.GA10462@1-4-5.net>
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader,
	Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2096993258=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org


--===============2096993258==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z"
Content-Disposition: inline


--Nq2Wo0NMKNjxTN9z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


	All,

	Allison points out that I jumped the gun a bit by
	assuming the WG would accept what was the
	voipeer-terminology document as WG document (this is what
	I renamed draft-speermint-reqs-and-terminology-00.txt).

	I've renamed it to draft-meyer-speermint-reqs-and-terminology-00.txt.
=09
	Take a look and we can discuss whether we want to take it
	on as a WG document.

	Thanks,

	Dave

--Nq2Wo0NMKNjxTN9z
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFD5PKrORgD1qCZ2KcRArGjAJ9t7egH7xqmfmFQM2X+G1UQ03JQ/gCfbVBI
nAzG/+QbhaIE/G4v1JaoF8c=
=f+Zf
-----END PGP SIGNATURE-----

--Nq2Wo0NMKNjxTN9z--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============2096993258==--




From speermint-bounces@ietf.org Sat Feb 04 18:07:03 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F5WUh-0007bL-Eq; Sat, 04 Feb 2006 18:07:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F5WUe-0007aM-8y; Sat, 04 Feb 2006 18:07:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16389;
	Sat, 4 Feb 2006 18:05:08 -0500 (EST)
Received: from extmail09.cingular.com ([170.35.225.24] helo=cingular.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F5WgJ-00078Q-Ra; Sat, 04 Feb 2006 18:19:04 -0500
Received: from ([10.3.188.52])
	by extmail09.cingular.com with ESMTP  id KP-VYGZ6.56623417;
	Sat, 04 Feb 2006 18:06:19 -0500
Received: by s75202e004001.tdc.cingular.net with Internet Mail Service
	(5.5.2657.72) id <1FCB4FKL>; Sat, 4 Feb 2006 17:09:51 -0600
Message-ID: <DE175C3426C51144B22109E3346CFFA4215FFA03@S75202E004049.sbms.sbc.com>
To: speermint@ietf.org, enum@ietf.org
Date: Sat, 4 Feb 2006 17:07:04 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
From: "Stafford, Matthew" <matthew.stafford@cingular.com>
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c
Cc: 
Subject: [Speermint] a suggestion re: using flags to distinguish post-ENUM
	signaling f lows
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0390481550=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0390481550==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C629DF.B67981A0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C629DF.B67981A0
Content-Type: text/plain

I strongly agree with the following statement from
draft-lendl-sip-peering-policy (lifted verbatim from section 6.2):

 

=>   RFC 3263 builds on that.  Quote:

=>      If a SIP proxy, redirect server, or registrar is to be contacted

=>      through the lookup of NAPTR records, there MUST be at least three

=>      records - one with a "SIP+D2T" service field, one with a "SIP+D2U"

=>      service field, and one with a "SIPS+D2T" service field.

=>

=>   This "MUST" needs to be reconsidered in this context, as it forces

=>   VSP to accept calls over unsecured SIP transports.

 

In fact, I would go further, as explained below.

 

The "u" flag defined in RFC 3761 doesn't say how to interpret the domain
name in the returned URI. In the case of a SIP URI, RFC 3263 signaling (in
particular, an additional layer of dereferencing embodied in a second NAPTR)
makes perfect sense to me in a situation where you know nothing about the
domain.

 

But should RFC 3263 be "universally normative" for SIP URIs? It seems to me
that the entity that provisions an ENUM NAPTR will in many cases already
know something useful about the target domain. As a simple for-instance,
suppose "transport=tcp" is included in the sip URI (as allowed by RFC 3261).
In this case, there would be an efficiency advantage if the ENUM response
could be followed directly by an SRV query.

 

So I have argued that there will be circumstances where the second NAPTR
doesn't buy you much. Of course there will also be circumstances where RFC
3263 signaling is warranted. I'm cross-posting to the ENUM working group for
the following reason: flags could be used to distinguish the two kinds of
signaling flows. Say a "g" flag (mnemonic for Gateway) that tells the
recipient of the ENUM NAPTR that there is an SRV record (w/domain in the
ENUM NAPTR as key) pointing to the gateway.

 

I think the example just described is worthwhile. Moreover, I think the
Lendl draft suggests that there are additional scenarios that might be
facilitated by via new ENUM flags. I'm not clear whether this sort of thing
would end up in "3761bis", so to speak, or in another document. Either way,
I'd like to float the idea and see if there's interest.

 

Best,

Matt Stafford

Vice Chair of Addressing Task Force, GSM North America

 

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

Matthew Stafford 

Principal Member of Technical Staff 

Cingular Wireless, Inc. 

9505 Arboretum Blvd Austin TX 78759 

matthew.stafford@cingular.com

Voice : +1(512)372-5623 

Fax : +1(512)372-5891 

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

This email and any files transmitted with it are property of Cingular
Wireless, are confidential, and are intended solely for the use of the
individual or entity to whom this email is addressed. If you are not one of
the named recipient(s) or otherwise have reason to believe that you have
received this message in error, please notify the sender at 512/372-5623 and
delete this message immediately from your computer. Any other use,
retention, dissemination, forwarding, printing or copying of this email is
strictly prohibited.

 


------_=_NextPart_001_01C629DF.B67981A0
Content-Type: text/html
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:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
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)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"Street" =
downloadurl=3D"http://www.5iantlavalampft-com:office:smarttags"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"address" =
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<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;}
p
	{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";}
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>
<!--[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><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I strongly agree with the following statement from
draft-lendl-sip-peering-policy (lifted verbatim from section =
6.2):<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=3D&gt;&nbsp;&nbsp; RFC 3263 builds on that.&nbsp; =
Quote:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=3D&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If a SIP =
proxy, redirect
server, or registrar is to be contacted<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=3D&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; through the =
lookup of
NAPTR records, there MUST be at least =
three<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=3D&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; records - one =
with a
&quot;SIP+D2T&quot; service field, one with a =
&quot;SIP+D2U&quot;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=3D&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; service field, =
and one
with a &quot;SIPS+D2T&quot; service field.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=3D&gt;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=3D&gt;&nbsp;&nbsp; This &quot;MUST&quot; needs to =
be
reconsidered in this context, as it forces<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>=3D&gt;&nbsp;&nbsp; VSP to accept calls over =
unsecured SIP
transports.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In fact, I would go further, as explained =
below.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The &quot;u&quot; flag defined in RFC 3761 doesn't =
say how
to interpret the domain name in the returned URI. In the case of a SIP =
URI, RFC
3263 signaling (in particular, an additional layer of dereferencing =
embodied in
a second NAPTR) makes perfect sense to me in a situation where you know =
nothing
about the domain.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>But should RFC 3263 be &quot;universally =
normative&quot; for
SIP URIs? It seems to me that the entity that provisions an ENUM NAPTR =
will in
many cases already know something useful about the target domain. As a =
simple
for-instance, suppose &quot;transport=3Dtcp&quot; is included in the =
sip URI (as
allowed by RFC 3261). In this case, there would be an efficiency =
advantage if
the ENUM response could be followed directly by an SRV =
query.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>So I have argued that there will be circumstances =
where the
second NAPTR doesn't buy you much. Of course there will also be =
circumstances
where RFC 3263 signaling is warranted. I'm cross-posting to the ENUM =
working
group for the following reason: flags could be used to distinguish the =
two
kinds of signaling flows. Say a &quot;g&quot; flag (mnemonic for =
Gateway) that
tells the recipient of the ENUM NAPTR that there is an SRV record =
(w/domain in
the ENUM NAPTR as key) pointing to the =
gateway.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I think the example just described is worthwhile. =
Moreover,
I think the Lendl draft suggests that there are additional scenarios =
that might
be facilitated by via new ENUM flags. I'm not clear whether this sort =
of thing
would end up in &quot;3761bis&quot;, so to speak, or in another =
document.
Either way, I'd like to float the idea and see if there's =
interest.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Matt Stafford<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Vice Chair of Addressing Task Force, GSM North =
America<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:2.0pt;
margin-left:0in'><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>-----------------------------------</span></font><o:p=
></o:p></p>

<p =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:2.0pt;
margin-left:0in'><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Matthew Stafford </span></font><o:p></o:p></p>

<p =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:2.0pt;
margin-left:0in'><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Principal Member of Technical Staff =
</span></font><o:p></o:p></p>

<p =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:2.0pt;
margin-left:0in'><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Cingular Wireless, Inc. =
</span></font><o:p></o:p></p>

<p =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:2.0pt;
margin-left:0in'><st1:Street w:st=3D"on"><st1:address w:st=3D"on"><font =
size=3D2
  face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>9505 =
Arboretum
  Blvd</span></font></st1:address></st1:Street><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'> Austin TX 78759 =
</span></font><o:p></o:p></p>

<p =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:2.0pt;
margin-left:0in'><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>matthew.stafford@cingular.com</span></font><o:p></o:p=
></p>

<p =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:2.0pt;
margin-left:0in'><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Voice : +1(512)372-5623 =
</span></font><o:p></o:p></p>

<p =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:2.0pt;
margin-left:0in'><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Fax : +1(512)372-5891 </span></font><o:p></o:p></p>

<p =
style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bottom:2.0pt;
margin-left:0in'><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>-----------------------------------</span></font><o:p=
></o:p></p>

<p><i><font size=3D1 face=3D"Times New Roman"><span =
style=3D'font-size:7.5pt;
font-style:italic'>This email and any files transmitted with it are =
property of
Cingular Wireless, are confidential, and are intended solely for the =
use of the
individual or entity to whom this email is addressed. If you are not =
one of the
named recipient(s) or otherwise have reason to believe that you have =
received
this message in error, please notify the sender at 512/372-5623 and =
delete this
message immediately from your computer. Any other use, retention,
dissemination, forwarding, printing or copying of this email is =
strictly
prohibited.</span></font></i><i><font size=3D1><span =
style=3D'font-size:7.5pt;
font-style:italic'><o:p></o:p></span></font></i></p>

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

</div>

</body>

</html>

------_=_NextPart_001_01C629DF.B67981A0--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============0390481550==--




From speermint-bounces@ietf.org Sun Feb 05 11:19:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F5mbe-0006jS-Ng; Sun, 05 Feb 2006 11:19:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F5j52-0007xT-Ht; Sun, 05 Feb 2006 07:33:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04226;
	Sun, 5 Feb 2006 07:31:34 -0500 (EST)
Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123]
	helo=norman.insensate.co.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F5jGr-0002dY-25; Sun, 05 Feb 2006 07:45:37 -0500
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by norman.insensate.co.uk (Postfix) with ESMTP
	id 1E0777BA20; Sun,  5 Feb 2006 12:32:27 +0000 (GMT)
In-Reply-To: <DE175C3426C51144B22109E3346CFFA4215FFA03@S75202E004049.sbms.sbc.com>
References: <DE175C3426C51144B22109E3346CFFA4215FFA03@S75202E004049.sbms.sbc.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <82A9B943-EEDE-49F4-B2D0-96FF6E162232@insensate.co.uk>
Content-Transfer-Encoding: 7bit
From: lconroy <lconroy@insensate.co.uk>
Date: Sun, 5 Feb 2006 12:32:25 +0000
To: "Stafford, Matthew" <matthew.stafford@cingular.com>,
	Otmar Lendl <lendl@nic.at>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sun, 05 Feb 2006 11:19:17 -0500
Cc: enum@ietf.org, speermint@ietf.org
Subject: [Speermint] Re: [Enum] a suggestion re: using flags to distinguish
	post-ENUM signaling f lows
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Hi Matt, Otmar, folks,
  This is an interesting posting for several reasons.
The first is the process issue - what group (if any) coordinates
between the different DDDS applications and their uses; this topic
covers D2x NAPTRs (natural territory for SIP/SIPPING), E2U NAPTRs
(natural territory for ENUM), and their use for peering (welcome,
SPEERMINT). If it's useful to add clarifications for DDDS itself
then who or what does that?

To the substance of the post:
I'm sure Otmar was not suggesting that D2x NAPTRs MUST be available
for all domains before a SIP exchange can occur. For Service Providers
it's fine, but...
There are a number of individuals who do not need or use an intermediary
provider for their SIP exchanges, so adding D2U NAPTRs is "overkill"
I, for example, do not have D2x NAPTRs in my zone; there's no target
domain redirection, so the NAPTRs would not be useful. I only have one
SIP proxy so one could even argue that SRVs are excessive - it's not
exactly a load balanced system.

However, for Service Providers, we enter new territories. Do you know
that your customers will want *every* insecure SIP invite to fail (i.e.
those customers have said to you explicitly that a _sip transaction is
not acceptable)? Is is a regulatory requirement that you at least tell
the caller that this call has failed though a terminating service like
UCB, rather than not even accept the attempt?

Lastly, adding a new flag for ENUM *in general* is going to cause some
problems for application developers like me - ALL of my ENUM clients
will have to support this, or else these will be non-compliant to any
3761bis. It seems that your proposal is purely for Carrier/ 
Infrastructure/
Private ENUM; in this case, changing 3761 has unintended consequences  
for
Public/User ENUM applications.

It appears that the proposed 'g' flag is appropriate only for SIP use  
within
Carrier ENUM, so one could WELL argue that this is an issue for the  
SIP URI
- I don't see how it can be used for other Enumservices (like  
email:mailto,
for example). Perhaps adding a SIP parameter (akin to ;user=phone)  
would be
more appropriate, or adding a new Enumservice to run alongside the  
existing
SIP one (i.e. to develop a new Enumservice definition RFC to specify  
a SIP
Gateway service)?

all the best,
   Lawrence


On 4 Feb 2006, at 23:07, Stafford, Matthew wrote:
> I strongly agree with the following statement from draft-lendl-sip- 
> peering-policy (lifted verbatim from section 6.2):
>
> =>   RFC 3263 builds on that.  Quote:
>
> =>      If a SIP proxy, redirect server, or registrar is to be  
> contacted
>
> =>      through the lookup of NAPTR records, there MUST be at least  
> three
>
> =>      records - one with a "SIP+D2T" service field, one with a  
> "SIP+D2U"
>
> =>      service field, and one with a "SIPS+D2T" service field.
>
> =>
>
> =>   This "MUST" needs to be reconsidered in this context, as it  
> forces
>
> =>   VSP to accept calls over unsecured SIP transports.
>
>  In fact, I would go further, as explained below.
>
> The "u" flag defined in RFC 3761 doesn't say how to interpret the  
> domain name in the returned URI. In the case of a SIP URI, RFC 3263  
> signaling (in particular, an additional layer of dereferencing  
> embodied in a second NAPTR) makes perfect sense to me in a  
> situation where you know nothing about the domain.
>
> But should RFC 3263 be "universally normative" for SIP URIs? It  
> seems to me that the entity that provisions an ENUM NAPTR will in  
> many cases already know something useful about the target domain.  
> As a simple for-instance, suppose "transport=tcp" is included in  
> the sip URI (as allowed by RFC 3261). In this case, there would be  
> an efficiency advantage if the ENUM response could be followed  
> directly by an SRV query.
>
> So I have argued that there will be circumstances where the second  
> NAPTR doesn't buy you much. Of course there will also be  
> circumstances where RFC 3263 signaling is warranted. I'm cross- 
> posting to the ENUM working group for the following reason: flags  
> could be used to distinguish the two kinds of signaling flows. Say  
> a "g" flag (mnemonic for Gateway) that tells the recipient of the  
> ENUM NAPTR that there is an SRV record (w/domain in the ENUM NAPTR  
> as key) pointing to the gateway.
>
> I think the example just described is worthwhile. Moreover, I think  
> the Lendl draft suggests that there are additional scenarios that  
> might be facilitated by via new ENUM flags. I'm not clear whether  
> this sort of thing would end up in "3761bis", so to speak, or in  
> another document. Either way, I'd like to float the idea and see if  
> there's interest.
>
> Best,
>
> Matt Stafford
>
> Vice Chair of Addressing Task Force, GSM North America

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Sun Feb 05 11:26:23 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F5miV-00011w-BW; Sun, 05 Feb 2006 11:26:23 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F5miT-0000zQ-42; Sun, 05 Feb 2006 11:26:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23192;
	Sun, 5 Feb 2006 11:24:41 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F5muT-00016h-T5; Sun, 05 Feb 2006 11:38:46 -0500
Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net
	[68.165.240.35]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k15GQP2r024116
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 5 Feb 2006 08:26:26 -0800
Message-ID: <43E62708.407@shockey.us>
Date: Sun, 05 Feb 2006 11:25:44 -0500
From: Richard Shockey <richard@shockey.us>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: lconroy <lconroy@insensate.co.uk>
References: <DE175C3426C51144B22109E3346CFFA4215FFA03@S75202E004049.sbms.sbc.com>
	<82A9B943-EEDE-49F4-B2D0-96FF6E162232@insensate.co.uk>
In-Reply-To: <82A9B943-EEDE-49F4-B2D0-96FF6E162232@insensate.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, speermint@ietf.org
Subject: [Speermint] Re: [Enum] a suggestion re: using flags to distinguish
 post-ENUM signaling f lows
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

lconroy wrote:
> Hi Matt, Otmar, folks,
>  This is an interesting posting for several reasons.
> The first is the process issue - what group (if any) coordinates
> between the different DDDS applications and their uses; this topic
> covers D2x NAPTRs (natural territory for SIP/SIPPING), E2U NAPTRs
> (natural territory for ENUM), and their use for peering (welcome,
> SPEERMINT). If it's useful to add clarifications for DDDS itself
> then who or what does that?
> 
> To the substance of the post:
> I'm sure Otmar was not suggesting that D2x NAPTRs MUST be available
> for all domains before a SIP exchange can occur. For Service Providers
> it's fine, but...
> There are a number of individuals who do not need or use an intermediary
> provider for their SIP exchanges, so adding D2U NAPTRs is "overkill"
> I, for example, do not have D2x NAPTRs in my zone; there's no target
> domain redirection, so the NAPTRs would not be useful. I only have one
> SIP proxy so one could even argue that SRVs are excessive - it's not
> exactly a load balanced system.
> 
>
> Lastly, adding a new flag for ENUM *in general* is going to cause some
> problems for application developers like me - ALL of my ENUM clients
> will have to support this, or else these will be non-compliant to any
> 3761bis. It seems that your proposal is purely for Carrier/Infrastructure/
> Private ENUM; in this case, changing 3761 has unintended consequences for
> Public/User ENUM applications.
> 
> It appears that the proposed 'g' flag is appropriate only for SIP use 
> within
> Carrier ENUM, so one could WELL argue that this is an issue for the SIP URI
> - I don't see how it can be used for other Enumservices (like email:mailto,
> for example). Perhaps adding a SIP parameter (akin to ;user=phone) would be
> more appropriate, or adding a new Enumservice to run alongside the existing
> SIP one (i.e. to develop a new Enumservice definition RFC to specify a SIP
> Gateway service)?


Larry I agree with your view.

If there were a general requirement for this form of tag its better done 
as an extension to a Enumservice field.

Those fields are quite extensible you can add as many sub-types as you 
want so long as they are properly defined in a RFC.

E2U+sip:gw

strikes me as the right way to do this.

The purpose of the flag field is not to hint at describe or the nature 
of endpoint after the rewrite but to define how to process the reg exp 
under certain defined conditions. This went to our past issue of how to 
use the replacement field, should someone find a way to use it properly.

BTW we have realized we have a bit of a mess with the Enumservice 
registry in general and we will shortly have a WG draft addressing the 
problem




> 
> all the best,
>   Lawrence
> 
> 
> On 4 Feb 2006, at 23:07, Stafford, Matthew wrote:
>> I strongly agree with the following statement from 
>> draft-lendl-sip-peering-policy (lifted verbatim from section 6.2):
>>
>> =>   RFC 3263 builds on that.  Quote:
>>
>> =>      If a SIP proxy, redirect server, or registrar is to be contacted
>>
>> =>      through the lookup of NAPTR records, there MUST be at least three
>>
>> =>      records - one with a "SIP+D2T" service field, one with a 
>> "SIP+D2U"
>>
>> =>      service field, and one with a "SIPS+D2T" service field.
>>
>> =>
>>
>> =>   This "MUST" needs to be reconsidered in this context, as it forces
>>
>> =>   VSP to accept calls over unsecured SIP transports.
>>
>>  In fact, I would go further, as explained below.
>>
>> The "u" flag defined in RFC 3761 doesn't say how to interpret the 
>> domain name in the returned URI. In the case of a SIP URI, RFC 3263 
>> signaling (in particular, an additional layer of dereferencing 
>> embodied in a second NAPTR) makes perfect sense to me in a situation 
>> where you know nothing about the domain.
>>
>> But should RFC 3263 be "universally normative" for SIP URIs? It seems 
>> to me that the entity that provisions an ENUM NAPTR will in many cases 
>> already know something useful about the target domain. As a simple 
>> for-instance, suppose "transport=tcp" is included in the sip URI (as 
>> allowed by RFC 3261). In this case, there would be an efficiency 
>> advantage if the ENUM response could be followed directly by an SRV 
>> query.
>>
>> So I have argued that there will be circumstances where the second 
>> NAPTR doesn't buy you much. Of course there will also be circumstances 
>> where RFC 3263 signaling is warranted. I'm cross-posting to the ENUM 
>> working group for the following reason: flags could be used to 
>> distinguish the two kinds of signaling flows. Say a "g" flag (mnemonic 
>> for Gateway) that tells the recipient of the ENUM NAPTR that there is 
>> an SRV record (w/domain in the ENUM NAPTR as key) pointing to the 
>> gateway.
>>
>> I think the example just described is worthwhile. Moreover, I think 
>> the Lendl draft suggests that there are additional scenarios that 
>> might be facilitated by via new ENUM flags. I'm not clear whether this 
>> sort of thing would end up in "3761bis", so to speak, or in another 
>> document. Either way, I'd like to float the idea and see if there's 
>> interest.
>>
>> Best,
>>
>> Matt Stafford
>>
>> Vice Chair of Addressing Task Force, GSM North America
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
> 


-- 


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Sun Feb 05 11:32:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F5mo6-0002bw-2I; Sun, 05 Feb 2006 11:32:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F5mo4-0002au-4M
	for speermint@megatron.ietf.org; Sun, 05 Feb 2006 11:32:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23625
	for <speermint@ietf.org>; Sun, 5 Feb 2006 11:30:20 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5mzx-000246-D3
	for speermint@ietf.org; Sun, 05 Feb 2006 11:44:25 -0500
Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net
	[68.165.240.35]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k15GWMDM024720
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 5 Feb 2006 08:32:23 -0800
Message-ID: <43E6286E.7020603@shockey.us>
Date: Sun, 05 Feb 2006 11:31:42 -0500
From: Richard Shockey <richard@shockey.us>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: David Meyer <dmm@1-4-5.net>
Subject: Re: [Speermint] please
	post	draft-speermint-reqs-and-terminology-00.txt
References: <20060203222217.GA10462@1-4-5.net>
	<20060204183003.GA28416@1-4-5.net>
In-Reply-To: <20060204183003.GA28416@1-4-5.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: 7bit
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

David Meyer wrote:
> 	All,
> 
> 	Allison points out that I jumped the gun a bit by
> 	assuming the WG would accept what was the
> 	voipeer-terminology document as WG document (this is what
> 	I renamed draft-speermint-reqs-and-terminology-00.txt).
> 
> 	I've renamed it to draft-meyer-speermint-reqs-and-terminology-00.txt.
> 	
> 	Take a look and we can discuss whether we want to take it
> 	on as a WG document.


I dont think you jumped the gun at all.

This is clearly a requirement for the WG going forward.

I support making it a SPPEERMINT WG document immediately so we can 
discuss it in depth in Dallas vs waste time on whether its appropriate.


Can we have a E-Humm please ?


> 
> 	Thanks,
> 
> 	Dave
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint


-- 


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Sun Feb 05 12:17:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F5nW6-0001Nc-OB; Sun, 05 Feb 2006 12:17:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F5nVl-0000ra-Tl
	for speermint@megatron.ietf.org; Sun, 05 Feb 2006 12:17:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26672
	for <speermint@ietf.org>; Sun, 5 Feb 2006 12:15:23 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F5nhY-0007Sn-O5
	for speermint@ietf.org; Sun, 05 Feb 2006 12:29:29 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Speermint] pleasepost draft-speermint-reqs-and-terminology-00.txt
Date: Sun, 5 Feb 2006 18:19:21 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C480B@oefeg-s04.oefeg.loc>
Thread-Topic: [Speermint] pleasepost
	draft-speermint-reqs-and-terminology-00.txt
Thread-Index: AcYqcoGiBNvwbTwjSMuptu1UWIRImgABcxaU
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Richard Shockey" <richard@shockey.us>, "David Meyer" <dmm@1-4-5.net>
X-Spam-Score: 0.8 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Content-Transfer-Encoding: quoted-printable
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Rich Shockey wrote:
>I support making it a SPPEERMINT WG document immediately so we can
>discuss it in depth in Dallas vs waste time on whether its appropriate.

fully agree
=20
Hummm
=20
Richard

________________________________

Von: speermint-bounces@ietf.org im Auftrag von Richard Shockey
Gesendet: So 05.02.2006 17:31
An: David Meyer
Cc: speermint@ietf.org
Betreff: Re: [Speermint] pleasepost =
draft-speermint-reqs-and-terminology-00.txt



David Meyer wrote:
>       All,
>
>       Allison points out that I jumped the gun a bit by
>       assuming the WG would accept what was the
>       voipeer-terminology document as WG document (this is what
>       I renamed draft-speermint-reqs-and-terminology-00.txt).
>
>       I've renamed it to =
draft-meyer-speermint-reqs-and-terminology-00.txt.
>     =20
>       Take a look and we can discuss whether we want to take it
>       on as a WG document.


I dont think you jumped the gun at all.

This is clearly a requirement for the WG going forward.

I support making it a SPPEERMINT WG document immediately so we can
discuss it in depth in Dallas vs waste time on whether its appropriate.


Can we have a E-Humm please ?


>
>       Thanks,
>
>       Dave
>
>
> =
------------------------------------------------------------------------
>
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint


--


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 06 10:12:48 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F682q-0000hA-8L; Mon, 06 Feb 2006 10:12:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F5myC-0006dA-QW; Sun, 05 Feb 2006 11:42:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24426;
	Sun, 5 Feb 2006 11:40:37 -0500 (EST)
Received: from osprey.verisign.com ([216.168.239.75])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F5n9t-0003Bh-6o; Sun, 05 Feb 2006 11:54:42 -0500
Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com
	[10.170.12.139])
	by osprey.verisign.com (8.13.1/8.13.4) with ESMTP id k15GiVVQ025290;
	Sun, 5 Feb 2006 11:44:31 -0500
Received: from trutkowski-desk.verisign.com ([10.169.64.229]) by
	dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft
	SMTPSVC(6.0.3790.1830); Sun, 5 Feb 2006 11:41:59 -0500
Message-Id: <7.0.1.0.2.20060205110918.035d3d70@verisign.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Sun, 05 Feb 2006 11:41:58 -0500
To: lconroy <lconroy@insensate.co.uk>,
	"Stafford, Matthew" <matthew.stafford@cingular.com>,
	Otmar Lendl <lendl@nic.at>
From: Tony Rutkowski <trutkowski@verisign.com>
In-Reply-To: <82A9B943-EEDE-49F4-B2D0-96FF6E162232@insensate.co.uk>
References: <DE175C3426C51144B22109E3346CFFA4215FFA03@S75202E004049.sbms.sbc.com>
	<82A9B943-EEDE-49F4-B2D0-96FF6E162232@insensate.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 05 Feb 2006 16:41:59.0743 (UTC)
	FILETIME=[158744F0:01C62A73]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
X-Mailman-Approved-At: Mon, 06 Feb 2006 10:12:46 -0500
Cc: enum@ietf.org, speermint@ietf.org
Subject: [Speermint] Re: [Enum] a suggestion re: using flags to distinguish
 post-ENUM signaling f lows
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Hi Lawrence,

>The first is the process issue - what group (if any) coordinates
>between the different DDDS applications and their uses; this topic
...
>3761bis. It seems that your proposal is purely for Carrier/ Infrastructure/
>Private ENUM; in this case, changing 3761 has unintended consequences
>for Public/User ENUM applications.

These are great understatements.  The use of
E.164 identifiers, internationally and
domestically, is subject to more statutory,
regulatory, national security, and industry
practice requirements than any identifier
space in existence - not to mention well
established institutional jurisdiction.

The following list is a current tabulation
of E.164 resolver-directory capability
requirements, parsed into three categories,
currently in play in various industry NGN
forums.  The recently enacted EC Data
Retention Directive, and the U.S. Prevent
Cyberstalking law, add further complexity
to the mix. ;-)

best,
--tony

>basic resolver capability
>
>supplementary capability
>         Number Portability
>         Priority Access
>         Roaming
>         Quality of Service
>         Directory Assistance
>         CallerID
>         Disability Assistance
>         Language preference
>         Personal emergency (E112/911)
>         Public emergency alerts
>         Law enforcement assistance
>         DoNotCall
>         Payment Methods
>         Intercarrier Compensation
>         Profile Management
>         Presence
>         Availability
>         Location
>         Push Management
>         Digital Rights Management
>         Device Management
>         Authentication Credentials
>         Information verification level
>
>protocol feature
>         Authentication
>         Auditing
>         Multiple Syntax Support
>         Mutiple Language Support
>         Extensibility and Localisation Mechanisms


_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 06 10:33:33 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F68Mv-0006es-AX; Mon, 06 Feb 2006 10:33:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F68Mb-0006Sd-RQ
	for speermint@megatron.ietf.org; Mon, 06 Feb 2006 10:33:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27316
	for <speermint@ietf.org>; Mon, 6 Feb 2006 10:31:22 -0500 (EST)
Message-Id: <200602061531.KAA27316@ietf.org>
Received: from mail.pulver.com ([192.246.69.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F68Yd-0003QY-11
	for speermint@ietf.org; Mon, 06 Feb 2006 10:45:41 -0500
Received: (qmail 30782 invoked by uid 510); 6 Feb 2006 10:57:33 -0500
Received: from henry@pulver.com by mail.pulver.com by uid 508 with
	qmail-scanner-1.22-st-qms 
	(clamdscan: 0.72. spamassassin: 2.63.  Clear:RC:1(67.187.111.112):. 
	Processed in 1.832981 secs); 06 Feb 2006 15:57:33 -0000
X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com
X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(67.187.111.112):. Processed in
	1.832981 secs Process 30776)
Received: from c-67-187-111-112.hsd1.tx.comcast.net (HELO 1AB764895C324D3)
	(henry@pulver.com@67.187.111.112)
	by 192.246.69.184 with SMTP; Mon, 06 Feb 2006 15:57:31 +0000
From: "Henry Sinnreich" <henry@pulver.com>
To: "'Tony Rutkowski'" <trutkowski@verisign.com>,
	"'lconroy'" <lconroy@insensate.co.uk>,
	"'Stafford, Matthew'" <matthew.stafford@cingular.com>,
	"'Otmar Lendl'" <lendl@nic.at>
Subject: RE: [Speermint] Re: [Enum] a suggestion re: using flags to
	distinguish post-ENUM signaling f lows
Date: Mon, 6 Feb 2006 09:32:51 -0600
Organization: pulver.com
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <7.0.1.0.2.20060205110918.035d3d70@verisign.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcYrM7NpmUSoI38oSL2GC2uIJC/XEAAAoR5g
X-Antivirus-MYDOMAIN-Message-ID: <113924145183530776@mail.pulver.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: henry@pulver.com
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

The information provided by Tony Rutkowski are a welcome reminder that phone
numbers are not only a crippled addressing system but a huge trap with
legacy telecom regulatory issues and big legal staffing costs.

Let's use the Internet and the DNS for what they were designed: URIs

The other alternative are the name spaces in P2P systems.

Sincere apology to all my friends working on ENUM: 
Keep it within strict bounds, simple and use with caution.

Thanks, Henry

 

-----Original Message-----
From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On
Behalf Of Tony Rutkowski
Sent: Sunday, February 05, 2006 10:42 AM
To: lconroy; Stafford, Matthew; Otmar Lendl
Cc: enum@ietf.org; speermint@ietf.org
Subject: [Speermint] Re: [Enum] a suggestion re: using flags to distinguish
post-ENUM signaling f lows

Hi Lawrence,

>The first is the process issue - what group (if any) coordinates
>between the different DDDS applications and their uses; this topic
...
>3761bis. It seems that your proposal is purely for Carrier/ Infrastructure/
>Private ENUM; in this case, changing 3761 has unintended consequences
>for Public/User ENUM applications.

These are great understatements.  The use of
E.164 identifiers, internationally and
domestically, is subject to more statutory,
regulatory, national security, and industry
practice requirements than any identifier
space in existence - not to mention well
established institutional jurisdiction.

The following list is a current tabulation
of E.164 resolver-directory capability
requirements, parsed into three categories,
currently in play in various industry NGN
forums.  The recently enacted EC Data
Retention Directive, and the U.S. Prevent
Cyberstalking law, add further complexity
to the mix. ;-)

best,
--tony

>basic resolver capability
>
>supplementary capability
>         Number Portability
>         Priority Access
>         Roaming
>         Quality of Service
>         Directory Assistance
>         CallerID
>         Disability Assistance
>         Language preference
>         Personal emergency (E112/911)
>         Public emergency alerts
>         Law enforcement assistance
>         DoNotCall
>         Payment Methods
>         Intercarrier Compensation
>         Profile Management
>         Presence
>         Availability
>         Location
>         Push Management
>         Digital Rights Management
>         Device Management
>         Authentication Credentials
>         Information verification level
>
>protocol feature
>         Authentication
>         Auditing
>         Multiple Syntax Support
>         Mutiple Language Support
>         Extensibility and Localisation Mechanisms


_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint




_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 06 10:50:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F68dj-0003Je-NN; Mon, 06 Feb 2006 10:50:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F68df-0003I1-Sf; Mon, 06 Feb 2006 10:50:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28506;
	Mon, 6 Feb 2006 10:49:01 -0500 (EST)
Received: from mail124.messagelabs.com ([85.158.136.19])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1F68pd-0004OT-ML; Mon, 06 Feb 2006 11:03:19 -0500
X-VirusChecked: Checked
X-Env-Sender: ppfautz@att.com
X-Msg-Ref: server-6.tower-124.messagelabs.com!1139241003!6561632!7
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 10153 invoked from network); 6 Feb 2006 15:50:22 -0000
Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4)
	by server-6.tower-124.messagelabs.com with SMTP;
	6 Feb 2006 15:50:22 -0000
Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by
	attrh2i.attrh.att.com (7.2.052)
	id 43CF0375002B25BB; Mon, 6 Feb 2006 10:50:19 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] Re: [Enum] a suggestion re: using flags todistinguish
	post-ENUM signaling f lows
Date: Mon, 6 Feb 2006 10:50:18 -0500
Message-ID: <34DA635B184A644DA4588E260EC0A25A0C15E4BC@ACCLUST02EVS1.ugd.att.com>
Thread-Topic: [Speermint] Re: [Enum] a suggestion re: using flags
	todistinguish post-ENUM signaling f lows
Thread-Index: AcYrM7NpmUSoI38oSL2GC2uIJC/XEAAAoR5gAAB0RnA=
From: "Pfautz, Penn L, NEO" <ppfautz@att.com>
To: <henry@pulver.com>, "Tony Rutkowski" <trutkowski@verisign.com>,
	"lconroy" <lconroy@insensate.co.uk>,
	"Stafford, Matthew" <matthew.stafford@cingular.com>,
	"Otmar Lendl" <lendl@nic.at>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3
Content-Transfer-Encoding: quoted-printable
Cc: enum@ietf.org, speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Right now, however, phone numbers are a little like democracy - "the
worst system imaginable except for all others"
P2P folks don't seem serious about interoperability  (look at IM) and
only TNs provide reachability from the PSTN.

Penn
(sorry, Henry, couldn't resist)

-----Original Message-----
From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On
Behalf Of Henry Sinnreich
Sent: Monday, February 06, 2006 10:33 AM
To: 'Tony Rutkowski'; 'lconroy'; 'Stafford, Matthew'; 'Otmar Lendl'
Cc: enum@ietf.org; speermint@ietf.org
Subject: RE: [Speermint] Re: [Enum] a suggestion re: using flags
todistinguish post-ENUM signaling f lows

The information provided by Tony Rutkowski are a welcome reminder that
phone
numbers are not only a crippled addressing system but a huge trap with
legacy telecom regulatory issues and big legal staffing costs.

Let's use the Internet and the DNS for what they were designed: URIs

The other alternative are the name spaces in P2P systems.

Sincere apology to all my friends working on ENUM:=20
Keep it within strict bounds, simple and use with caution.

Thanks, Henry

=20

-----Original Message-----
From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On
Behalf Of Tony Rutkowski
Sent: Sunday, February 05, 2006 10:42 AM
To: lconroy; Stafford, Matthew; Otmar Lendl
Cc: enum@ietf.org; speermint@ietf.org
Subject: [Speermint] Re: [Enum] a suggestion re: using flags to
distinguish
post-ENUM signaling f lows

Hi Lawrence,

>The first is the process issue - what group (if any) coordinates
>between the different DDDS applications and their uses; this topic
...
>3761bis. It seems that your proposal is purely for Carrier/
Infrastructure/
>Private ENUM; in this case, changing 3761 has unintended consequences
>for Public/User ENUM applications.

These are great understatements.  The use of
E.164 identifiers, internationally and
domestically, is subject to more statutory,
regulatory, national security, and industry
practice requirements than any identifier
space in existence - not to mention well
established institutional jurisdiction.

The following list is a current tabulation
of E.164 resolver-directory capability
requirements, parsed into three categories,
currently in play in various industry NGN
forums.  The recently enacted EC Data
Retention Directive, and the U.S. Prevent
Cyberstalking law, add further complexity
to the mix. ;-)

best,
--tony

>basic resolver capability
>
>supplementary capability
>         Number Portability
>         Priority Access
>         Roaming
>         Quality of Service
>         Directory Assistance
>         CallerID
>         Disability Assistance
>         Language preference
>         Personal emergency (E112/911)
>         Public emergency alerts
>         Law enforcement assistance
>         DoNotCall
>         Payment Methods
>         Intercarrier Compensation
>         Profile Management
>         Presence
>         Availability
>         Location
>         Push Management
>         Digital Rights Management
>         Device Management
>         Authentication Credentials
>         Information verification level
>
>protocol feature
>         Authentication
>         Auditing
>         Multiple Syntax Support
>         Mutiple Language Support
>         Extensibility and Localisation Mechanisms


_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint




_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 06 11:02:14 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F68og-000673-QA; Mon, 06 Feb 2006 11:02:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F68oa-00066Z-Tv; Mon, 06 Feb 2006 11:02:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29360;
	Mon, 6 Feb 2006 11:00:15 -0500 (EST)
Received: from h139-142-184-176.roothosts.com ([139.142.184.176]
	helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F690X-00055L-2v; Mon, 06 Feb 2006 11:14:30 -0500
Received: from [192.168.1.101] (cpe-24-95-54-117.columbus.res.rr.com
	[24.95.54.117])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified))
	by wodka.aus-biz.com (Postfix) with ESMTP id 5567AE38;
	Mon,  6 Feb 2006 11:01:24 -0500 (EST)
Message-ID: <43E772D3.5010801@e164.org>
Date: Mon, 06 Feb 2006 11:01:23 -0500
From: Duane <duane@e164.org>
User-Agent: Mail/News 1.5 (X11/20060119)
MIME-Version: 1.0
To: "Pfautz, Penn L, NEO" <ppfautz@att.com>
Subject: Re: [Speermint] Re: [Enum] a suggestion re: using flags todistinguish
	post-ENUM signaling f lows
References: <34DA635B184A644DA4588E260EC0A25A0C15E4BC@ACCLUST02EVS1.ugd.att.com>
In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0C15E4BC@ACCLUST02EVS1.ugd.att.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, speermint@ietf.org, Tony Rutkowski <trutkowski@verisign.com>,
	lconroy <lconroy@insensate.co.uk>
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Pfautz, Penn L, NEO wrote:
> Right now, however, phone numbers are a little like democracy - "the
> worst system imaginable except for all others"
> P2P folks don't seem serious about interoperability  (look at IM) and
> only TNs provide reachability from the PSTN.

Not entirely true, the guys from Jabber use enum lookups and resolve 
Jabber IDs from our zone (e164.org).

Also we're currently working on plugins for thunderbird/firefox to do 
phone number to email/website with the idea of unification on business 
cards of 10 different pieces of contact information to just a phone 
number if people want to go that route.

-- 

Best regards,
  Duane

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 06 16:43:34 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6E90-0004u3-M9; Mon, 06 Feb 2006 16:43:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F6E8z-0004tF-8c
	for speermint@megatron.ietf.org; Mon, 06 Feb 2006 16:43:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07283
	for <speermint@ietf.org>; Mon, 6 Feb 2006 16:41:43 -0500 (EST)
Received: from paoakoavas10.cable.comcast.com ([208.17.35.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6EL6-0003Hr-UY
	for speermint@ietf.org; Mon, 06 Feb 2006 16:56:06 -0500
Received: from ([10.20.9.172])
	by paoakoavas10.cable.comcast.com with ESMTP  id KP-TDCH3.16764107;
	Mon, 06 Feb 2006 16:42:51 -0500
Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by
	PACDCEXCSMTP01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 6 Feb 2006 16:42:40 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 6 Feb 2006 16:42:36 -0500
Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A13A@PACDCEXCMB01.cable.comcast.com>
Thread-Topic: Test Message
Thread-Index: AcYrZj6P7XEs51ysTjWtuhuR8q55OA==
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: <speermint@ietf.org>
X-OriginalArrivalTime: 06 Feb 2006 21:42:40.0987 (UTC)
	FILETIME=[415C62B0:01C62B66]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4
Content-Transfer-Encoding: quoted-printable
Subject: [Speermint] Test Message
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

This is a test, please ignore this.  We've reset some of the abuse /
spam filters and just checking to ensure that we're still good.
Thanks
Jason

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 06 18:04:20 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6FPA-0007M0-O3; Mon, 06 Feb 2006 18:04:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F6FP8-0007JN-UW
	for speermint@megatron.ietf.org; Mon, 06 Feb 2006 18:04:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19079
	for <speermint@ietf.org>; Mon, 6 Feb 2006 18:02:33 -0500 (EST)
Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6FbK-00017u-Aq
	for speermint@ietf.org; Mon, 06 Feb 2006 18:16:55 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 6 Feb 2006 18:03:44 -0500
Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A148@PACDCEXCMB01.cable.comcast.com>
Thread-Topic: wg-business: Secretary Interest?
Thread-Index: AcYrcZPoSYkZ4OTARymmR6oIjyOwrA==
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: <speermint@ietf.org>
X-OriginalArrivalTime: 06 Feb 2006 23:03:45.0252 (UTC)
	FILETIME=[94B05240:01C62B71]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: [Speermint] wg-business: Secretary Interest?
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Hello all -

We're gearing up for IETF 65 in Dallas and our first official WG
session.  :-)  David and I should soon have a draft agenda for review
and input from this list.

In the meantime, we'd like to see if anyone out there is interested in
volunteering for the role of Secretary of the WG.  This person should
have a grasp of the technologies being discussed and be able to take
detailed minutes of WG sessions, perform NITS reviews of I-Ds, and
generally assist in the process of managing & organizing the WG.  If you
may be interested in this, please email David (cc'd) and I privately to
express your interest.

Thanks
Jason

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 07 03:29:19 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6ODv-00051d-L7; Tue, 07 Feb 2006 03:29:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6ODs-0004wy-Qz; Tue, 07 Feb 2006 03:29:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02953;
	Tue, 7 Feb 2006 03:27:35 -0500 (EST)
Received: from pb94.dyndns.org ([213.239.207.29])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F6OQE-00067i-0R; Tue, 07 Feb 2006 03:42:03 -0500
Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3])
	by pb94.dyndns.org (Postfix) with ESMTP id 3B97A7211C8;
	Tue,  7 Feb 2006 09:28:56 +0100 (CET)
Message-ID: <43E85A4C.8020207@pernau.at>
Date: Tue, 07 Feb 2006 09:29:00 +0100
From: Klaus Darilion <klaus.mailinglists@pernau.at>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Duane <duane@e164.org>
Subject: Re: [Speermint] Re: [Enum] a suggestion re: using flags todistinguish
	post-ENUM signaling f lows
References: <34DA635B184A644DA4588E260EC0A25A0C15E4BC@ACCLUST02EVS1.ugd.att.com>
	<43E772D3.5010801@e164.org>
In-Reply-To: <43E772D3.5010801@e164.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, speermint@ietf.org, lconroy <lconroy@insensate.co.uk>,
	Tony Rutkowski <trutkowski@verisign.com>
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Duane wrote:
> Pfautz, Penn L, NEO wrote:
> 
>> Right now, however, phone numbers are a little like democracy - "the
>> worst system imaginable except for all others"
>> P2P folks don't seem serious about interoperability  (look at IM) and
>> only TNs provide reachability from the PSTN.
> 
> 
> Not entirely true, the guys from Jabber use enum lookups and resolve 
> Jabber IDs from our zone (e164.org).
> 
> Also we're currently working on plugins for thunderbird/firefox to do 
> phone number to email/website with the idea of unification on business 
> cards of 10 different pieces of contact information to just a phone 
> number if people want to go that route.

FYI: There already exists a firefox plugin (firefox 1.0.x only).
http://falb.at/enum4firefox/enummapper-0.1.0.xpi

regards
klaus


_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 07 08:50:14 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6TET-0000Ak-OL; Tue, 07 Feb 2006 08:50:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6TE2-0008Sw-6i; Tue, 07 Feb 2006 08:50:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26709;
	Tue, 7 Feb 2006 08:47:55 -0500 (EST)
Received: from mail124.messagelabs.com ([85.158.136.19])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1F6TQE-0000WH-LZ; Tue, 07 Feb 2006 09:02:26 -0500
X-VirusChecked: Checked
X-Env-Sender: ppfautz@att.com
X-Msg-Ref: server-5.tower-124.messagelabs.com!1139320103!6908890!21
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 9609 invoked from network); 7 Feb 2006 13:49:22 -0000
Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4)
	by server-5.tower-124.messagelabs.com with SMTP;
	7 Feb 2006 13:49:22 -0000
Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by
	attrh2i.attrh.att.com (7.2.052)
	id 43CF0375002D9372; Tue, 7 Feb 2006 08:49:20 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] and are phone numbers a borken addressing system?
Date: Tue, 7 Feb 2006 08:49:20 -0500
Message-ID: <34DA635B184A644DA4588E260EC0A25A0C197939@ACCLUST02EVS1.ugd.att.com>
Thread-Topic: [Speermint] and are phone numbers a borken addressing system?
Thread-Index: AcYrwI7+uWvK8J5uRVuyJ8CBkI74WgAJ7DSQ
From: "Pfautz, Penn L, NEO" <ppfautz@att.com>
To: "Klaus Darilion" <klaus.mailinglists@pernau.at>, "Duane" <duane@e164.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: quoted-printable
Cc: enum@ietf.org, speermint@ietf.org, lconroy <lconroy@insensate.co.uk>,
	Tony Rutkowski <trutkowski@verisign.com>
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

All neat stuff I'm sure. But it lacks the kind of universality and
authoritativeness that are ultimately required for a system that's going
to be more than an adjunct, however popular.=20
My point about IM was simply that the major offers don't make much of an
attempt to interoperate which puts them where the telephone system was
about a century ago when you could only call me if we had the same phone
company. Likewise the   "non-connected" VoIP systems: how does
Googletalk interwork with Skype?=20
Pity, because IP handles the interconnection problem (at layer 3) so
elegantly compared to the phone network. The object of Speermint is do
bring this elegance to layer 5. I hope we'll do that, but if you want to
make the PSTN go away you'll need an industrial strength addressing
system. ENUM is great because is marries the good properties of E.164 to
the flexibility of the net. I haven't seen anything else that gets the
whole job done.

My personal view...

Penn =20

-----Original Message-----
From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20
Sent: Tuesday, February 07, 2006 3:29 AM
To: Duane
Cc: Pfautz, Penn L, NEO; enum@ietf.org; speermint@ietf.org; Tony
Rutkowski; lconroy
Subject: Re: [Speermint] Re: [Enum] a suggestion re: using flags
todistinguish post-ENUM signaling f lows

Duane wrote:
> Pfautz, Penn L, NEO wrote:
>=20
>> Right now, however, phone numbers are a little like democracy - "the
>> worst system imaginable except for all others"
>> P2P folks don't seem serious about interoperability  (look at IM) and
>> only TNs provide reachability from the PSTN.
>=20
>=20
> Not entirely true, the guys from Jabber use enum lookups and resolve=20
> Jabber IDs from our zone (e164.org).
>=20
> Also we're currently working on plugins for thunderbird/firefox to do=20
> phone number to email/website with the idea of unification on business

> cards of 10 different pieces of contact information to just a phone=20
> number if people want to go that route.

FYI: There already exists a firefox plugin (firefox 1.0.x only).
http://falb.at/enum4firefox/enummapper-0.1.0.xpi

regards
klaus


_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

From enum-bounces@ietf.org Tue Feb 07 08:50:14 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6TES-0000AY-DW; Tue, 07 Feb 2006 08:50:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6TE2-0008Sw-6i; Tue, 07 Feb 2006 08:50:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26709;
	Tue, 7 Feb 2006 08:47:55 -0500 (EST)
Received: from mail124.messagelabs.com ([85.158.136.19])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1F6TQE-0000WH-LZ; Tue, 07 Feb 2006 09:02:26 -0500
X-VirusChecked: Checked
X-Env-Sender: ppfautz@att.com
X-Msg-Ref: server-5.tower-124.messagelabs.com!1139320103!6908890!21
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 9609 invoked from network); 7 Feb 2006 13:49:22 -0000
Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4)
	by server-5.tower-124.messagelabs.com with SMTP;
	7 Feb 2006 13:49:22 -0000
Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by
	attrh2i.attrh.att.com (7.2.052)
	id 43CF0375002D9372; Tue, 7 Feb 2006 08:49:20 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 7 Feb 2006 08:49:20 -0500
Message-ID: <34DA635B184A644DA4588E260EC0A25A0C197939@ACCLUST02EVS1.ugd.att.com>
Thread-Topic: [Speermint] and are phone numbers a borken addressing system?
Thread-Index: AcYrwI7+uWvK8J5uRVuyJ8CBkI74WgAJ7DSQ
From: "Pfautz, Penn L, NEO" <ppfautz@att.com>
To: "Klaus Darilion" <klaus.mailinglists@pernau.at>, "Duane" <duane@e164.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: quoted-printable
Cc: enum@ietf.org, speermint@ietf.org, lconroy <lconroy@insensate.co.uk>,
	Tony Rutkowski <trutkowski@verisign.com>
Subject: [Enum] RE: [Speermint] and are phone numbers a borken addressing
	system?
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>,
	<mailto:enum-request@ietf.org?subject=subscribe>
Sender: enum-bounces@ietf.org
Errors-To: enum-bounces@ietf.org

All neat stuff I'm sure. But it lacks the kind of universality and
authoritativeness that are ultimately required for a system that's going
to be more than an adjunct, however popular.=20
My point about IM was simply that the major offers don't make much of an
attempt to interoperate which puts them where the telephone system was
about a century ago when you could only call me if we had the same phone
company. Likewise the   "non-connected" VoIP systems: how does
Googletalk interwork with Skype?=20
Pity, because IP handles the interconnection problem (at layer 3) so
elegantly compared to the phone network. The object of Speermint is do
bring this elegance to layer 5. I hope we'll do that, but if you want to
make the PSTN go away you'll need an industrial strength addressing
system. ENUM is great because is marries the good properties of E.164 to
the flexibility of the net. I haven't seen anything else that gets the
whole job done.

My personal view...

Penn =20

-----Original Message-----
From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]=20
Sent: Tuesday, February 07, 2006 3:29 AM
To: Duane
Cc: Pfautz, Penn L, NEO; enum@ietf.org; speermint@ietf.org; Tony
Rutkowski; lconroy
Subject: Re: [Speermint] Re: [Enum] a suggestion re: using flags
todistinguish post-ENUM signaling f lows

Duane wrote:
> Pfautz, Penn L, NEO wrote:
>=20
>> Right now, however, phone numbers are a little like democracy - "the
>> worst system imaginable except for all others"
>> P2P folks don't seem serious about interoperability  (look at IM) and
>> only TNs provide reachability from the PSTN.
>=20
>=20
> Not entirely true, the guys from Jabber use enum lookups and resolve=20
> Jabber IDs from our zone (e164.org).
>=20
> Also we're currently working on plugins for thunderbird/firefox to do=20
> phone number to email/website with the idea of unification on business

> cards of 10 different pieces of contact information to just a phone=20
> number if people want to go that route.

FYI: There already exists a firefox plugin (firefox 1.0.x only).
http://falb.at/enum4firefox/enummapper-0.1.0.xpi

regards
klaus


_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum





From speermint-bounces@ietf.org Tue Feb 07 09:08:33 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6TWD-0007eJ-JZ; Tue, 07 Feb 2006 09:08:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6TW9-0007Pi-Q3; Tue, 07 Feb 2006 09:08:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28170;
	Tue, 7 Feb 2006 09:06:33 -0500 (EST)
Received: from h139-142-184-176.roothosts.com ([139.142.184.176]
	helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F6TiI-00019Y-CB; Tue, 07 Feb 2006 09:21:04 -0500
Received: from [192.168.1.101] (cpe-24-95-54-117.columbus.res.rr.com
	[24.95.54.117])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified))
	by wodka.aus-biz.com (Postfix) with ESMTP id 69A1449AF;
	Tue,  7 Feb 2006 09:07:54 -0500 (EST)
Message-ID: <43E8A9B9.7080901@e164.org>
Date: Tue, 07 Feb 2006 09:07:53 -0500
From: Duane <duane@e164.org>
User-Agent: Mail/News 1.5 (X11/20060119)
MIME-Version: 1.0
To: Klaus Darilion <klaus.mailinglists@pernau.at>
Subject: Re: [Speermint] Re: [Enum] a suggestion re: using flags todistinguish
	post-ENUM signaling f lows
References: <34DA635B184A644DA4588E260EC0A25A0C15E4BC@ACCLUST02EVS1.ugd.att.com>
	<43E772D3.5010801@e164.org> <43E85A4C.8020207@pernau.at>
In-Reply-To: <43E85A4C.8020207@pernau.at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, speermint@ietf.org, lconroy <lconroy@insensate.co.uk>,
	Tony Rutkowski <trutkowski@verisign.com>
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Klaus Darilion wrote:
>> Also we're currently working on plugins for thunderbird/firefox to do 
>> phone number to email/website with the idea of unification on business 
>> cards of 10 different pieces of contact information to just a phone 
>> number if people want to go that route.
> 
> FYI: There already exists a firefox plugin (firefox 1.0.x only).
> http://falb.at/enum4firefox/enummapper-0.1.0.xpi

I'm aware of that plugin but that only works on windows, and the 
binaries including in the plugin only link to their service.

-- 

Best regards,
  Duane

http://www.cacert.org - Free Security Certificates
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://e164.org - Using Enum.164 to interconnect asterisk servers

"In the long run the pessimist may be proved right,
     but the optimist has a better time on the trip."

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 07 09:48:09 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6U8X-0004n1-44; Tue, 07 Feb 2006 09:48:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F6U8M-0004lV-Of
	for speermint@megatron.ietf.org; Tue, 07 Feb 2006 09:48:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00896
	for <speermint@ietf.org>; Tue, 7 Feb 2006 09:46:07 -0500 (EST)
Message-Id: <200602071446.JAA00896@ietf.org>
Received: from mail.pulver.com ([192.246.69.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6UKc-0002Ql-6N
	for speermint@ietf.org; Tue, 07 Feb 2006 10:00:38 -0500
Received: (qmail 29648 invoked by uid 510); 7 Feb 2006 10:12:42 -0500
Received: from henry@pulver.com by mail.pulver.com by uid 508 with
	qmail-scanner-1.22-st-qms 
	(clamdscan: 0.72. spamassassin: 2.63.  Clear:RC:1(67.187.111.112):. 
	Processed in 1.82195 secs); 07 Feb 2006 15:12:42 -0000
X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com
X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(67.187.111.112):. Processed in
	1.82195 secs Process 29643)
Received: from c-67-187-111-112.hsd1.tx.comcast.net (HELO 1AB764895C324D3)
	(henry@pulver.com@67.187.111.112)
	by 192.246.69.184 with SMTP; Tue, 07 Feb 2006 15:12:39 +0000
From: "Henry Sinnreich" <henry@pulver.com>
To: "'Pfautz, Penn L, NEO'" <ppfautz@att.com>,
	"'Klaus Darilion'" <klaus.mailinglists@pernau.at>,
	"'Duane'" <duane@e164.org>
Subject: RE: [Speermint] and are phone numbers a borken addressing system?
Date: Tue, 7 Feb 2006 08:47:35 -0600
Organization: pulver.com
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
thread-index: AcYrwI7+uWvK8J5uRVuyJ8CBkI74WgAJ7DSQAAKZZWA=
In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0C197939@ACCLUST02EVS1.ugd.att.com>
X-Antivirus-MYDOMAIN-Message-ID: <113932516083529643@mail.pulver.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, speermint@ietf.org, 'lconroy' <lconroy@insensate.co.uk>,
	'Tony Rutkowski' <trutkowski@verisign.com>
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: henry@pulver.com
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Penn,

I have to agree with you:

>My point about IM was simply that the major offers don't make much of an
>attempt to interoperate which puts them where the telephone system was
>about a century ago when you could only call me if we had the same phone.

Maybe the time is right for another Theodore Vail.

Also, the IM companies carry most of the VoIP traffic and have by far the
largest number of users. Only the new Microsoft IM and Yahoo IM are SIP. AOL
and Google have the "intention" to support SIP and Skype uses SIP to
interconnect to PSTN gateway providers. My Skype reads 5,259,584 users
online...

Maybe folks on the list have more accurate information.

Coming to the point: 
What about peering for presence and IM? 
Or should we wait for another Theodore Vail?

Thanks, Henry


 

-----Original Message-----
From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On
Behalf Of Pfautz, Penn L, NEO
Sent: Tuesday, February 07, 2006 7:49 AM
To: Klaus Darilion; Duane
Cc: enum@ietf.org; speermint@ietf.org; lconroy; Tony Rutkowski
Subject: RE: [Speermint] and are phone numbers a borken addressing system?

All neat stuff I'm sure. But it lacks the kind of universality and
authoritativeness that are ultimately required for a system that's going
to be more than an adjunct, however popular. 
My point about IM was simply that the major offers don't make much of an
attempt to interoperate which puts them where the telephone system was
about a century ago when you could only call me if we had the same phone
company. Likewise the   "non-connected" VoIP systems: how does
Googletalk interwork with Skype? 
Pity, because IP handles the interconnection problem (at layer 3) so
elegantly compared to the phone network. The object of Speermint is do
bring this elegance to layer 5. I hope we'll do that, but if you want to
make the PSTN go away you'll need an industrial strength addressing
system. ENUM is great because is marries the good properties of E.164 to
the flexibility of the net. I haven't seen anything else that gets the
whole job done.

My personal view...

Penn  

-----Original Message-----
From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] 
Sent: Tuesday, February 07, 2006 3:29 AM
To: Duane
Cc: Pfautz, Penn L, NEO; enum@ietf.org; speermint@ietf.org; Tony
Rutkowski; lconroy
Subject: Re: [Speermint] Re: [Enum] a suggestion re: using flags
todistinguish post-ENUM signaling f lows

Duane wrote:
> Pfautz, Penn L, NEO wrote:
> 
>> Right now, however, phone numbers are a little like democracy - "the
>> worst system imaginable except for all others"
>> P2P folks don't seem serious about interoperability  (look at IM) and
>> only TNs provide reachability from the PSTN.
> 
> 
> Not entirely true, the guys from Jabber use enum lookups and resolve 
> Jabber IDs from our zone (e164.org).
> 
> Also we're currently working on plugins for thunderbird/firefox to do 
> phone number to email/website with the idea of unification on business

> cards of 10 different pieces of contact information to just a phone 
> number if people want to go that route.

FYI: There already exists a firefox plugin (firefox 1.0.x only).
http://falb.at/enum4firefox/enummapper-0.1.0.xpi

regards
klaus


_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 07 13:08:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6XG4-0007i6-4y; Tue, 07 Feb 2006 13:08:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6XG2-0007f9-By; Tue, 07 Feb 2006 13:08:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17018;
	Tue, 7 Feb 2006 13:06:25 -0500 (EST)
Received: from extmail09.cingular.com ([170.35.225.24] helo=cingular.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F6XSS-0001Bt-UT; Tue, 07 Feb 2006 13:20:57 -0500
Received: from ([10.3.188.52])
	by extmail09.cingular.com with ESMTP  id KP-VYGZ6.56945499;
	Tue, 07 Feb 2006 13:07:28 -0500
Received: by s75202e004001.tdc.cingular.net with Internet Mail Service
	(5.5.2657.72) id <1FCBYR00>; Tue, 7 Feb 2006 12:11:03 -0600
Message-ID: <DE175C3426C51144B22109E3346CFFA421774074@S75202E004049.sbms.sbc.com>
To: lconroy <lconroy@insensate.co.uk>
Date: Tue, 7 Feb 2006 12:08:09 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
From: "Stafford, Matthew" <matthew.stafford@cingular.com>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83
Cc: enum@ietf.org, speermint@ietf.org
Subject: [Speermint] RE: [Enum] a suggestion re: using flags to distinguish
	post-ENUM signaling f lows
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0453763937=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0453763937==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C62C11.73FE4E30"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C62C11.73FE4E30
Content-Type: text/plain

Lawrence- Thanks for your comments... good discussion points here! Inline.

Best,
Matt

-----Original Message-----
From: lconroy [mailto:lconroy@insensate.co.uk] 
Sent: Sunday, February 05, 2006 6:32 AM
To: Stafford, Matthew; Otmar Lendl
Cc: speermint@ietf.org; enum@ietf.org
Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM
signaling f lows

Hi Matt, Otmar, folks,
  This is an interesting posting for several reasons.
The first is the process issue - what group (if any) coordinates
between the different DDDS applications and their uses; this topic
covers D2x NAPTRs (natural territory for SIP/SIPPING), E2U NAPTRs
(natural territory for ENUM), and their use for peering (welcome,
SPEERMINT). If it's useful to add clarifications for DDDS itself
then who or what does that?

==> Agree that this is not a trivial question.

To the substance of the post:
I'm sure Otmar was not suggesting that D2x NAPTRs MUST be available
for all domains before a SIP exchange can occur. For Service Providers
it's fine, but...
There are a number of individuals who do not need or use an intermediary
provider for their SIP exchanges, so adding D2U NAPTRs is "overkill"
I, for example, do not have D2x NAPTRs in my zone; there's no target
domain redirection, so the NAPTRs would not be useful. I only have one
SIP proxy so one could even argue that SRVs are excessive - it's not
exactly a load balanced system.

==> The way I read (this portion of) the Lendl draft is as follows (correct
==> me if I misinterpret):
==> *If* you want to dereference SIP URIs using D2x NAPTRs *but* you will
==> not accept SIP signaling over UDP, then RFC 3263 is telling you to do
==> something that doesn't make much sense (namely, post a D2U NAPTR
==> anyway).

==> My reading of RFC 3263 doesn't seem to say you MUST dereference SIP URIs
==> via D2x NAPTRs. But AFAICT, nothing systematic is specified re: other
==> signaling flows for resolving SIP URIs. BTW, strongly agree with your
==> suggestion that other signaling flows make sense in many cases.

However, for Service Providers, we enter new territories. Do you know
that your customers will want *every* insecure SIP invite to fail (i.e.
those customers have said to you explicitly that a _sip transaction is
not acceptable)? Is is a regulatory requirement that you at least tell
the caller that this call has failed though a terminating service like
UCB, rather than not even accept the attempt?

==> Another interesting point.

Lastly, adding a new flag for ENUM *in general* is going to cause some
problems for application developers like me - ALL of my ENUM clients
will have to support this, or else these will be non-compliant to any
3761bis. It seems that your proposal is purely for Carrier/ 
Infrastructure/
Private ENUM; in this case, changing 3761 has unintended consequences  
for
Public/User ENUM applications.

==> I take your point regarding the headaches w/changes to clients.
==> However, I'm not sure I agree that this is limited to carrier/infra-
==> ENUM, at least if we think of that in terms of traditional telcos/
==> cellcos. For example, does this discussion really bear no relevance
==> to enterprise applications (e.g., I want to call into my company's
==> IP PBX while I'm on the road?) 

It appears that the proposed 'g' flag is appropriate only for SIP use  
within
Carrier ENUM, so one could WELL argue that this is an issue for the  
SIP URI
- I don't see how it can be used for other Enumservices (like  
email:mailto,
for example). Perhaps adding a SIP parameter (akin to ;user=phone)  
would be
more appropriate, or adding a new Enumservice to run alongside the  
existing
SIP one (i.e. to develop a new Enumservice definition RFC to specify  
a SIP
Gateway service)?

==> That would have a similar effect to the flag proposal, in the sense
==> that the contents of the ENUM NAPTR offer guidance on what to do next
==> (which is really what I'm after)

==> For the sake of discussion, here's a similar example using the
recently-==> standardized Enumservice mms:mailto... an 'm' flag indicating
that the ==> NAPTR recipient should now look for an MX Resource Record.

all the best,
   Lawrence


On 4 Feb 2006, at 23:07, Stafford, Matthew wrote:
> I strongly agree with the following statement from draft-lendl-sip- 
> peering-policy (lifted verbatim from section 6.2):
>
> =>   RFC 3263 builds on that.  Quote:
>
> =>      If a SIP proxy, redirect server, or registrar is to be  
> contacted
>
> =>      through the lookup of NAPTR records, there MUST be at least  
> three
>
> =>      records - one with a "SIP+D2T" service field, one with a  
> "SIP+D2U"
>
> =>      service field, and one with a "SIPS+D2T" service field.
>
> =>
>
> =>   This "MUST" needs to be reconsidered in this context, as it  
> forces
>
> =>   VSP to accept calls over unsecured SIP transports.
>
>  In fact, I would go further, as explained below.
>
> The "u" flag defined in RFC 3761 doesn't say how to interpret the  
> domain name in the returned URI. In the case of a SIP URI, RFC 3263  
> signaling (in particular, an additional layer of dereferencing  
> embodied in a second NAPTR) makes perfect sense to me in a  
> situation where you know nothing about the domain.
>
> But should RFC 3263 be "universally normative" for SIP URIs? It  
> seems to me that the entity that provisions an ENUM NAPTR will in  
> many cases already know something useful about the target domain.  
> As a simple for-instance, suppose "transport=tcp" is included in  
> the sip URI (as allowed by RFC 3261). In this case, there would be  
> an efficiency advantage if the ENUM response could be followed  
> directly by an SRV query.
>
> So I have argued that there will be circumstances where the second  
> NAPTR doesn't buy you much. Of course there will also be  
> circumstances where RFC 3263 signaling is warranted. I'm cross- 
> posting to the ENUM working group for the following reason: flags  
> could be used to distinguish the two kinds of signaling flows. Say  
> a "g" flag (mnemonic for Gateway) that tells the recipient of the  
> ENUM NAPTR that there is an SRV record (w/domain in the ENUM NAPTR  
> as key) pointing to the gateway.
>
> I think the example just described is worthwhile. Moreover, I think  
> the Lendl draft suggests that there are additional scenarios that  
> might be facilitated by via new ENUM flags. I'm not clear whether  
> this sort of thing would end up in "3761bis", so to speak, or in  
> another document. Either way, I'd like to float the idea and see if  
> there's interest.
>
> Best,
>
> Matt Stafford
>
> Vice Chair of Addressing Task Force, GSM North America

------_=_NextPart_001_01C62C11.73FE4E30
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.34">
<TITLE>RE: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Lawrence- Thanks for your comments... good discussion points here! Inline.</FONT>
</P>

<P><FONT SIZE=2>Best,</FONT>
<BR><FONT SIZE=2>Matt</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: lconroy [<A HREF="mailto:lconroy@insensate.co.uk">mailto:lconroy@insensate.co.uk</A>] </FONT>
<BR><FONT SIZE=2>Sent: Sunday, February 05, 2006 6:32 AM</FONT>
<BR><FONT SIZE=2>To: Stafford, Matthew; Otmar Lendl</FONT>
<BR><FONT SIZE=2>Cc: speermint@ietf.org; enum@ietf.org</FONT>
<BR><FONT SIZE=2>Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows</FONT>
</P>

<P><FONT SIZE=2>Hi Matt, Otmar, folks,</FONT>
<BR><FONT SIZE=2>&nbsp; This is an interesting posting for several reasons.</FONT>
<BR><FONT SIZE=2>The first is the process issue - what group (if any) coordinates</FONT>
<BR><FONT SIZE=2>between the different DDDS applications and their uses; this topic</FONT>
<BR><FONT SIZE=2>covers D2x NAPTRs (natural territory for SIP/SIPPING), E2U NAPTRs</FONT>
<BR><FONT SIZE=2>(natural territory for ENUM), and their use for peering (welcome,</FONT>
<BR><FONT SIZE=2>SPEERMINT). If it's useful to add clarifications for DDDS itself</FONT>
<BR><FONT SIZE=2>then who or what does that?</FONT>
</P>

<P><FONT SIZE=2>==&gt; Agree that this is not a trivial question.</FONT>
</P>

<P><FONT SIZE=2>To the substance of the post:</FONT>
<BR><FONT SIZE=2>I'm sure Otmar was not suggesting that D2x NAPTRs MUST be available</FONT>
<BR><FONT SIZE=2>for all domains before a SIP exchange can occur. For Service Providers</FONT>
<BR><FONT SIZE=2>it's fine, but...</FONT>
<BR><FONT SIZE=2>There are a number of individuals who do not need or use an intermediary</FONT>
<BR><FONT SIZE=2>provider for their SIP exchanges, so adding D2U NAPTRs is &quot;overkill&quot;</FONT>
<BR><FONT SIZE=2>I, for example, do not have D2x NAPTRs in my zone; there's no target</FONT>
<BR><FONT SIZE=2>domain redirection, so the NAPTRs would not be useful. I only have one</FONT>
<BR><FONT SIZE=2>SIP proxy so one could even argue that SRVs are excessive - it's not</FONT>
<BR><FONT SIZE=2>exactly a load balanced system.</FONT>
</P>

<P><FONT SIZE=2>==&gt; The way I read (this portion of) the Lendl draft is as follows (correct</FONT>
<BR><FONT SIZE=2>==&gt; me if I misinterpret):</FONT>
<BR><FONT SIZE=2>==&gt; *If* you want to dereference SIP URIs using D2x NAPTRs *but* you will</FONT>
<BR><FONT SIZE=2>==&gt; not accept SIP signaling over UDP, then RFC 3263 is telling you to do</FONT>
<BR><FONT SIZE=2>==&gt; something that doesn't make much sense (namely, post a D2U NAPTR</FONT>
<BR><FONT SIZE=2>==&gt; anyway).</FONT>
</P>

<P><FONT SIZE=2>==&gt; My reading of RFC 3263 doesn't seem to say you MUST dereference SIP URIs</FONT>
<BR><FONT SIZE=2>==&gt; via D2x NAPTRs. But AFAICT, nothing systematic is specified re: other</FONT>
<BR><FONT SIZE=2>==&gt; signaling flows for resolving SIP URIs. BTW, strongly agree with your</FONT>
<BR><FONT SIZE=2>==&gt; suggestion that other signaling flows make sense in many cases.</FONT>
</P>

<P><FONT SIZE=2>However, for Service Providers, we enter new territories. Do you know</FONT>
<BR><FONT SIZE=2>that your customers will want *every* insecure SIP invite to fail (i.e.</FONT>
<BR><FONT SIZE=2>those customers have said to you explicitly that a _sip transaction is</FONT>
<BR><FONT SIZE=2>not acceptable)? Is is a regulatory requirement that you at least tell</FONT>
<BR><FONT SIZE=2>the caller that this call has failed though a terminating service like</FONT>
<BR><FONT SIZE=2>UCB, rather than not even accept the attempt?</FONT>
</P>

<P><FONT SIZE=2>==&gt; Another interesting point.</FONT>
</P>

<P><FONT SIZE=2>Lastly, adding a new flag for ENUM *in general* is going to cause some</FONT>
<BR><FONT SIZE=2>problems for application developers like me - ALL of my ENUM clients</FONT>
<BR><FONT SIZE=2>will have to support this, or else these will be non-compliant to any</FONT>
<BR><FONT SIZE=2>3761bis. It seems that your proposal is purely for Carrier/ </FONT>
<BR><FONT SIZE=2>Infrastructure/</FONT>
<BR><FONT SIZE=2>Private ENUM; in this case, changing 3761 has unintended consequences&nbsp; </FONT>
<BR><FONT SIZE=2>for</FONT>
<BR><FONT SIZE=2>Public/User ENUM applications.</FONT>
</P>

<P><FONT SIZE=2>==&gt; I take your point regarding the headaches w/changes to clients.</FONT>
<BR><FONT SIZE=2>==&gt; However, I'm not sure I agree that this is limited to carrier/infra-</FONT>
<BR><FONT SIZE=2>==&gt; ENUM, at least if we think of that in terms of traditional telcos/</FONT>
<BR><FONT SIZE=2>==&gt; cellcos. For example, does this discussion really bear no relevance</FONT>
<BR><FONT SIZE=2>==&gt; to enterprise applications (e.g., I want to call into my company's</FONT>
<BR><FONT SIZE=2>==&gt; IP PBX while I'm on the road?) </FONT>
</P>

<P><FONT SIZE=2>It appears that the proposed 'g' flag is appropriate only for SIP use&nbsp; </FONT>
<BR><FONT SIZE=2>within</FONT>
<BR><FONT SIZE=2>Carrier ENUM, so one could WELL argue that this is an issue for the&nbsp; </FONT>
<BR><FONT SIZE=2>SIP URI</FONT>
<BR><FONT SIZE=2>- I don't see how it can be used for other Enumservices (like&nbsp; </FONT>
<BR><FONT SIZE=2>email:mailto,</FONT>
<BR><FONT SIZE=2>for example). Perhaps adding a SIP parameter (akin to ;user=phone)&nbsp; </FONT>
<BR><FONT SIZE=2>would be</FONT>
<BR><FONT SIZE=2>more appropriate, or adding a new Enumservice to run alongside the&nbsp; </FONT>
<BR><FONT SIZE=2>existing</FONT>
<BR><FONT SIZE=2>SIP one (i.e. to develop a new Enumservice definition RFC to specify&nbsp; </FONT>
<BR><FONT SIZE=2>a SIP</FONT>
<BR><FONT SIZE=2>Gateway service)?</FONT>
</P>

<P><FONT SIZE=2>==&gt; That would have a similar effect to the flag proposal, in the sense</FONT>
<BR><FONT SIZE=2>==&gt; that the contents of the ENUM NAPTR offer guidance on what to do next</FONT>
<BR><FONT SIZE=2>==&gt; (which is really what I'm after)</FONT>
</P>

<P><FONT SIZE=2>==&gt; For the sake of discussion, here's a similar example using the recently-==&gt; standardized Enumservice mms:mailto... an 'm' flag indicating that the ==&gt; NAPTR recipient should now look for an MX Resource Record.</FONT></P>

<P><FONT SIZE=2>all the best,</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; Lawrence</FONT>
</P>
<BR>

<P><FONT SIZE=2>On 4 Feb 2006, at 23:07, Stafford, Matthew wrote:</FONT>
<BR><FONT SIZE=2>&gt; I strongly agree with the following statement from draft-lendl-sip- </FONT>
<BR><FONT SIZE=2>&gt; peering-policy (lifted verbatim from section 6.2):</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; =&gt;&nbsp;&nbsp; RFC 3263 builds on that.&nbsp; Quote:</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; =&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If a SIP proxy, redirect server, or registrar is to be&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; contacted</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; =&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; through the lookup of NAPTR records, there MUST be at least&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; three</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; =&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; records - one with a &quot;SIP+D2T&quot; service field, one with a&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &quot;SIP+D2U&quot;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; =&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; service field, and one with a &quot;SIPS+D2T&quot; service field.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; =&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; =&gt;&nbsp;&nbsp; This &quot;MUST&quot; needs to be reconsidered in this context, as it&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; forces</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; =&gt;&nbsp;&nbsp; VSP to accept calls over unsecured SIP transports.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; In fact, I would go further, as explained below.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; The &quot;u&quot; flag defined in RFC 3761 doesn't say how to interpret the&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; domain name in the returned URI. In the case of a SIP URI, RFC 3263&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; signaling (in particular, an additional layer of dereferencing&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; embodied in a second NAPTR) makes perfect sense to me in a&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; situation where you know nothing about the domain.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; But should RFC 3263 be &quot;universally normative&quot; for SIP URIs? It&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; seems to me that the entity that provisions an ENUM NAPTR will in&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; many cases already know something useful about the target domain.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; As a simple for-instance, suppose &quot;transport=tcp&quot; is included in&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; the sip URI (as allowed by RFC 3261). In this case, there would be&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; an efficiency advantage if the ENUM response could be followed&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; directly by an SRV query.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; So I have argued that there will be circumstances where the second&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; NAPTR doesn't buy you much. Of course there will also be&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; circumstances where RFC 3263 signaling is warranted. I'm cross- </FONT>
<BR><FONT SIZE=2>&gt; posting to the ENUM working group for the following reason: flags&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; could be used to distinguish the two kinds of signaling flows. Say&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; a &quot;g&quot; flag (mnemonic for Gateway) that tells the recipient of the&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; ENUM NAPTR that there is an SRV record (w/domain in the ENUM NAPTR&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; as key) pointing to the gateway.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; I think the example just described is worthwhile. Moreover, I think&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; the Lendl draft suggests that there are additional scenarios that&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; might be facilitated by via new ENUM flags. I'm not clear whether&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; this sort of thing would end up in &quot;3761bis&quot;, so to speak, or in&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; another document. Either way, I'd like to float the idea and see if&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; there's interest.</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Best,</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Matt Stafford</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Vice Chair of Addressing Task Force, GSM North America</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C62C11.73FE4E30--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============0453763937==--




From speermint-bounces@ietf.org Tue Feb 07 13:12:34 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6XKM-0000KI-0w; Tue, 07 Feb 2006 13:12:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6XKE-00009f-Kf; Tue, 07 Feb 2006 13:12:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17286;
	Tue, 7 Feb 2006 13:10:37 -0500 (EST)
Received: from extmail09.cingular.com ([170.35.225.24] helo=cingular.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F6XWX-0001Kw-2Z; Tue, 07 Feb 2006 13:25:10 -0500
Received: from ([10.3.188.52])
	by extmail09.cingular.com with ESMTP  id KP-VYGZ6.56946055;
	Tue, 07 Feb 2006 13:11:47 -0500
Received: by s75202e004001.tdc.cingular.net with Internet Mail Service
	(5.5.2657.72) id <1FCBYSPN>; Tue, 7 Feb 2006 12:15:22 -0600
Message-ID: <DE175C3426C51144B22109E3346CFFA421774083@S75202E004049.sbms.sbc.com>
To: Richard Shockey <richard@shockey.us>
Date: Tue, 7 Feb 2006 12:12:27 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
From: "Stafford, Matthew" <matthew.stafford@cingular.com>
X-Spam-Score: 1.3 (+)
X-Scan-Signature: a38f40f81e96f7c17c0b6f9de20b7099
Cc: enum@ietf.org, speermint@ietf.org
Subject: [Speermint] RE: [Enum] a suggestion re: using flags to distinguish
	post-ENUM signaling f lows
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1859233476=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1859233476==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C62C12.0D407780"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C62C12.0D407780
Content-Type: text/plain

Richard- I'm interested to see what will happen with ENUMservices; thanks
for the info. The only problem I see is that sometimes (e.g., the
recently-standardized E2U+mms:mailto) the subtype is already used to specify
a URI scheme. So, for instance, that would not allow use of the subtype to
indicate that the recipient of the ENUM NAPTR should look for an MX RR as a
next step.

Best,
Matt

-----Original Message-----
From: Richard Shockey [mailto:richard@shockey.us] 
Sent: Sunday, February 05, 2006 10:26 AM
To: lconroy
Cc: Stafford, Matthew; Otmar Lendl; enum@ietf.org; speermint@ietf.org
Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM
signaling f lows

lconroy wrote:
> Hi Matt, Otmar, folks,
>  This is an interesting posting for several reasons.
> The first is the process issue - what group (if any) coordinates
> between the different DDDS applications and their uses; this topic
> covers D2x NAPTRs (natural territory for SIP/SIPPING), E2U NAPTRs
> (natural territory for ENUM), and their use for peering (welcome,
> SPEERMINT). If it's useful to add clarifications for DDDS itself
> then who or what does that?
> 
> To the substance of the post:
> I'm sure Otmar was not suggesting that D2x NAPTRs MUST be available
> for all domains before a SIP exchange can occur. For Service Providers
> it's fine, but...
> There are a number of individuals who do not need or use an intermediary
> provider for their SIP exchanges, so adding D2U NAPTRs is "overkill"
> I, for example, do not have D2x NAPTRs in my zone; there's no target
> domain redirection, so the NAPTRs would not be useful. I only have one
> SIP proxy so one could even argue that SRVs are excessive - it's not
> exactly a load balanced system.
> 
>
> Lastly, adding a new flag for ENUM *in general* is going to cause some
> problems for application developers like me - ALL of my ENUM clients
> will have to support this, or else these will be non-compliant to any
> 3761bis. It seems that your proposal is purely for Carrier/Infrastructure/
> Private ENUM; in this case, changing 3761 has unintended consequences for
> Public/User ENUM applications.
> 
> It appears that the proposed 'g' flag is appropriate only for SIP use 
> within
> Carrier ENUM, so one could WELL argue that this is an issue for the SIP
URI
> - I don't see how it can be used for other Enumservices (like
email:mailto,
> for example). Perhaps adding a SIP parameter (akin to ;user=phone) would
be
> more appropriate, or adding a new Enumservice to run alongside the
existing
> SIP one (i.e. to develop a new Enumservice definition RFC to specify a SIP
> Gateway service)?


Larry I agree with your view.

If there were a general requirement for this form of tag its better done 
as an extension to a Enumservice field.

Those fields are quite extensible you can add as many sub-types as you 
want so long as they are properly defined in a RFC.

E2U+sip:gw

strikes me as the right way to do this.

The purpose of the flag field is not to hint at describe or the nature 
of endpoint after the rewrite but to define how to process the reg exp 
under certain defined conditions. This went to our past issue of how to 
use the replacement field, should someone find a way to use it properly.

BTW we have realized we have a bit of a mess with the Enumservice 
registry in general and we will shortly have a WG draft addressing the 
problem




> 
> all the best,
>   Lawrence
> 
> 
> On 4 Feb 2006, at 23:07, Stafford, Matthew wrote:
>> I strongly agree with the following statement from 
>> draft-lendl-sip-peering-policy (lifted verbatim from section 6.2):
>>
>> =>   RFC 3263 builds on that.  Quote:
>>
>> =>      If a SIP proxy, redirect server, or registrar is to be contacted
>>
>> =>      through the lookup of NAPTR records, there MUST be at least three
>>
>> =>      records - one with a "SIP+D2T" service field, one with a 
>> "SIP+D2U"
>>
>> =>      service field, and one with a "SIPS+D2T" service field.
>>
>> =>
>>
>> =>   This "MUST" needs to be reconsidered in this context, as it forces
>>
>> =>   VSP to accept calls over unsecured SIP transports.
>>
>>  In fact, I would go further, as explained below.
>>
>> The "u" flag defined in RFC 3761 doesn't say how to interpret the 
>> domain name in the returned URI. In the case of a SIP URI, RFC 3263 
>> signaling (in particular, an additional layer of dereferencing 
>> embodied in a second NAPTR) makes perfect sense to me in a situation 
>> where you know nothing about the domain.
>>
>> But should RFC 3263 be "universally normative" for SIP URIs? It seems 
>> to me that the entity that provisions an ENUM NAPTR will in many cases 
>> already know something useful about the target domain. As a simple 
>> for-instance, suppose "transport=tcp" is included in the sip URI (as 
>> allowed by RFC 3261). In this case, there would be an efficiency 
>> advantage if the ENUM response could be followed directly by an SRV 
>> query.
>>
>> So I have argued that there will be circumstances where the second 
>> NAPTR doesn't buy you much. Of course there will also be circumstances 
>> where RFC 3263 signaling is warranted. I'm cross-posting to the ENUM 
>> working group for the following reason: flags could be used to 
>> distinguish the two kinds of signaling flows. Say a "g" flag (mnemonic 
>> for Gateway) that tells the recipient of the ENUM NAPTR that there is 
>> an SRV record (w/domain in the ENUM NAPTR as key) pointing to the 
>> gateway.
>>
>> I think the example just described is worthwhile. Moreover, I think 
>> the Lendl draft suggests that there are additional scenarios that 
>> might be facilitated by via new ENUM flags. I'm not clear whether this 
>> sort of thing would end up in "3761bis", so to speak, or in another 
>> document. Either way, I'd like to float the idea and see if there's 
>> interest.
>>
>> Best,
>>
>> Matt Stafford
>>
>> Vice Chair of Addressing Task Force, GSM North America
> 
> _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
> 


-- 


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

------_=_NextPart_001_01C62C12.0D407780
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: [Enum] a suggestion re: using flags to distinguish post-ENUM =
signaling f lows</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Richard- I'm interested to see what will happen with =
ENUMservices; thanks for the info. The only problem I see is that =
sometimes (e.g., the recently-standardized E2U+mms:mailto) the subtype =
is already used to specify a URI scheme. So, for instance, that would =
not allow use of the subtype to indicate that the recipient of the ENUM =
NAPTR should look for an MX RR as a next step.</FONT></P>

<P><FONT SIZE=3D2>Best,</FONT>
<BR><FONT SIZE=3D2>Matt</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Richard Shockey [<A =
HREF=3D"mailto:richard@shockey.us">mailto:richard@shockey.us</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Sunday, February 05, 2006 10:26 AM</FONT>
<BR><FONT SIZE=3D2>To: lconroy</FONT>
<BR><FONT SIZE=3D2>Cc: Stafford, Matthew; Otmar Lendl; enum@ietf.org; =
speermint@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Enum] a suggestion re: using flags to =
distinguish post-ENUM signaling f lows</FONT>
</P>

<P><FONT SIZE=3D2>lconroy wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; Hi Matt, Otmar, folks,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; This is an interesting posting for =
several reasons.</FONT>
<BR><FONT SIZE=3D2>&gt; The first is the process issue - what group (if =
any) coordinates</FONT>
<BR><FONT SIZE=3D2>&gt; between the different DDDS applications and =
their uses; this topic</FONT>
<BR><FONT SIZE=3D2>&gt; covers D2x NAPTRs (natural territory for =
SIP/SIPPING), E2U NAPTRs</FONT>
<BR><FONT SIZE=3D2>&gt; (natural territory for ENUM), and their use for =
peering (welcome,</FONT>
<BR><FONT SIZE=3D2>&gt; SPEERMINT). If it's useful to add =
clarifications for DDDS itself</FONT>
<BR><FONT SIZE=3D2>&gt; then who or what does that?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; To the substance of the post:</FONT>
<BR><FONT SIZE=3D2>&gt; I'm sure Otmar was not suggesting that D2x =
NAPTRs MUST be available</FONT>
<BR><FONT SIZE=3D2>&gt; for all domains before a SIP exchange can =
occur. For Service Providers</FONT>
<BR><FONT SIZE=3D2>&gt; it's fine, but...</FONT>
<BR><FONT SIZE=3D2>&gt; There are a number of individuals who do not =
need or use an intermediary</FONT>
<BR><FONT SIZE=3D2>&gt; provider for their SIP exchanges, so adding D2U =
NAPTRs is &quot;overkill&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; I, for example, do not have D2x NAPTRs in my =
zone; there's no target</FONT>
<BR><FONT SIZE=3D2>&gt; domain redirection, so the NAPTRs would not be =
useful. I only have one</FONT>
<BR><FONT SIZE=3D2>&gt; SIP proxy so one could even argue that SRVs are =
excessive - it's not</FONT>
<BR><FONT SIZE=3D2>&gt; exactly a load balanced system.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Lastly, adding a new flag for ENUM *in general* =
is going to cause some</FONT>
<BR><FONT SIZE=3D2>&gt; problems for application developers like me - =
ALL of my ENUM clients</FONT>
<BR><FONT SIZE=3D2>&gt; will have to support this, or else these will =
be non-compliant to any</FONT>
<BR><FONT SIZE=3D2>&gt; 3761bis. It seems that your proposal is purely =
for Carrier/Infrastructure/</FONT>
<BR><FONT SIZE=3D2>&gt; Private ENUM; in this case, changing 3761 has =
unintended consequences for</FONT>
<BR><FONT SIZE=3D2>&gt; Public/User ENUM applications.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It appears that the proposed 'g' flag is =
appropriate only for SIP use </FONT>
<BR><FONT SIZE=3D2>&gt; within</FONT>
<BR><FONT SIZE=3D2>&gt; Carrier ENUM, so one could WELL argue that this =
is an issue for the SIP URI</FONT>
<BR><FONT SIZE=3D2>&gt; - I don't see how it can be used for other =
Enumservices (like email:mailto,</FONT>
<BR><FONT SIZE=3D2>&gt; for example). Perhaps adding a SIP parameter =
(akin to ;user=3Dphone) would be</FONT>
<BR><FONT SIZE=3D2>&gt; more appropriate, or adding a new Enumservice =
to run alongside the existing</FONT>
<BR><FONT SIZE=3D2>&gt; SIP one (i.e. to develop a new Enumservice =
definition RFC to specify a SIP</FONT>
<BR><FONT SIZE=3D2>&gt; Gateway service)?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Larry I agree with your view.</FONT>
</P>

<P><FONT SIZE=3D2>If there were a general requirement for this form of =
tag its better done </FONT>
<BR><FONT SIZE=3D2>as an extension to a Enumservice field.</FONT>
</P>

<P><FONT SIZE=3D2>Those fields are quite extensible you can add as many =
sub-types as you </FONT>
<BR><FONT SIZE=3D2>want so long as they are properly defined in a =
RFC.</FONT>
</P>

<P><FONT SIZE=3D2>E2U+sip:gw</FONT>
</P>

<P><FONT SIZE=3D2>strikes me as the right way to do this.</FONT>
</P>

<P><FONT SIZE=3D2>The purpose of the flag field is not to hint at =
describe or the nature </FONT>
<BR><FONT SIZE=3D2>of endpoint after the rewrite but to define how to =
process the reg exp </FONT>
<BR><FONT SIZE=3D2>under certain defined conditions. This went to our =
past issue of how to </FONT>
<BR><FONT SIZE=3D2>use the replacement field, should someone find a way =
to use it properly.</FONT>
</P>

<P><FONT SIZE=3D2>BTW we have realized we have a bit of a mess with the =
Enumservice </FONT>
<BR><FONT SIZE=3D2>registry in general and we will shortly have a WG =
draft addressing the </FONT>
<BR><FONT SIZE=3D2>problem</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; all the best,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; Lawrence</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On 4 Feb 2006, at 23:07, Stafford, Matthew =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I strongly agree with the following =
statement from </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; draft-lendl-sip-peering-policy (lifted =
verbatim from section 6.2):</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; =3D&gt;&nbsp;&nbsp; RFC 3263 builds on =
that.&nbsp; Quote:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; =3D&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If a =
SIP proxy, redirect server, or registrar is to be contacted</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; =3D&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
through the lookup of NAPTR records, there MUST be at least =
three</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; =3D&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
records - one with a &quot;SIP+D2T&quot; service field, one with a =
</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &quot;SIP+D2U&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; =3D&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
service field, and one with a &quot;SIPS+D2T&quot; service =
field.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; =3D&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; =3D&gt;&nbsp;&nbsp; This &quot;MUST&quot; =
needs to be reconsidered in this context, as it forces</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; =3D&gt;&nbsp;&nbsp; VSP to accept calls =
over unsecured SIP transports.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; In fact, I would go further, as =
explained below.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; The &quot;u&quot; flag defined in RFC 3761 =
doesn't say how to interpret the </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; domain name in the returned URI. In the =
case of a SIP URI, RFC 3263 </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; signaling (in particular, an additional =
layer of dereferencing </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; embodied in a second NAPTR) makes perfect =
sense to me in a situation </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; where you know nothing about the =
domain.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; But should RFC 3263 be &quot;universally =
normative&quot; for SIP URIs? It seems </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; to me that the entity that provisions an =
ENUM NAPTR will in many cases </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; already know something useful about the =
target domain. As a simple </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; for-instance, suppose =
&quot;transport=3Dtcp&quot; is included in the sip URI (as </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; allowed by RFC 3261). In this case, there =
would be an efficiency </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; advantage if the ENUM response could be =
followed directly by an SRV </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; query.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; So I have argued that there will be =
circumstances where the second </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; NAPTR doesn't buy you much. Of course there =
will also be circumstances </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; where RFC 3263 signaling is warranted. I'm =
cross-posting to the ENUM </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; working group for the following reason: =
flags could be used to </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; distinguish the two kinds of signaling =
flows. Say a &quot;g&quot; flag (mnemonic </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; for Gateway) that tells the recipient of =
the ENUM NAPTR that there is </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; an SRV record (w/domain in the ENUM NAPTR =
as key) pointing to the </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; gateway.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I think the example just described is =
worthwhile. Moreover, I think </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; the Lendl draft suggests that there are =
additional scenarios that </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; might be facilitated by via new ENUM flags. =
I'm not clear whether this </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; sort of thing would end up in =
&quot;3761bis&quot;, so to speak, or in another </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; document. Either way, I'd like to float the =
idea and see if there's </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; interest.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Best,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Matt Stafford</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Vice Chair of Addressing Task Force, GSM =
North America</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; enum mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; enum@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/enum" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/enum</A></FONT>=

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-- </FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>&nbsp;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&=
gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&=
gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&=
gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>Richard Shockey, Director - Member of Technical =
Staff</FONT>
<BR><FONT SIZE=3D2>NeuStar Inc.</FONT>
<BR><FONT SIZE=3D2>46000 Center Oak Plaza&nbsp; -&nbsp;&nbsp; Sterling, =
VA&nbsp; 20166</FONT>
<BR><FONT SIZE=3D2>sip:rshockey(at)iptel.org&nbsp;&nbsp; =
sip:57141(at)fwd.pulver.com</FONT>
<BR><FONT SIZE=3D2>ENUM +87810-13313-31331</FONT>
<BR><FONT SIZE=3D2>PSTN Office +1 571.434.5651 PSTN Mobile +1 =
703.593.2683</FONT>
<BR><FONT SIZE=3D2>Fax: +1 815.333.1237</FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:richard(at)shockey.us">mailto:richard(at)shockey.us</A>&g=
t; or</FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:richard.shockey(at)neustar.biz">mailto:richard.shockey(at=
)neustar.biz</A>&gt;</FONT>
<BR><FONT SIZE=3D2>&lt;<A HREF=3D"http://www.neustar.biz" =
TARGET=3D"_blank">http://www.neustar.biz</A>&gt; ; &lt;<A =
HREF=3D"http://www.enum.org" =
TARGET=3D"_blank">http://www.enum.org</A>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt=
;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt=
;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt=
;&lt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C62C12.0D407780--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============1859233476==--




From speermint-bounces@ietf.org Tue Feb 07 13:20:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6XSO-0003bJ-Ja; Tue, 07 Feb 2006 13:20:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6XSK-0003Yt-Hg; Tue, 07 Feb 2006 13:20:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17836;
	Tue, 7 Feb 2006 13:18:57 -0500 (EST)
Received: from extmail09.cingular.com ([170.35.225.24] helo=cingular.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F6Xeb-0001at-Aj; Tue, 07 Feb 2006 13:33:30 -0500
Received: from ([10.3.188.52])
	by extmail09.cingular.com with ESMTP  id KP-VYGZ6.56947271;
	Tue, 07 Feb 2006 13:20:13 -0500
Received: by s75202e004001.tdc.cingular.net with Internet Mail Service
	(5.5.2657.72) id <1FCBYTQ2>; Tue, 7 Feb 2006 12:23:48 -0600
Message-ID: <DE175C3426C51144B22109E3346CFFA42177409C@S75202E004049.sbms.sbc.com>
To: Tony Rutkowski <trutkowski@verisign.com>
Date: Tue, 7 Feb 2006 12:20:58 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
From: "Stafford, Matthew" <matthew.stafford@cingular.com>
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc
Cc: enum@ietf.org, speermint@ietf.org
Subject: [Speermint] RE: [Enum] a suggestion re: using flags to distinguish
	post-ENUM signaling f lows
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0318740338=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0318740338==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C62C13.3E107BCA"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C62C13.3E107BCA
Content-Type: text/plain

Tony- The E.164 space is a many-encumbered thing. No argument there.

All the same, I see two benefits of E.164 numbers: although *some* mobile
devices have QWERTY keyboards, many of them still don't. IMO a telephone
number is far and away the easiest thing to punch into a cellphone keypad.
That's the first one. The second one is (essentially) number portability. My
SIP URI can change from sip:mstafford@provider-A.net to
sip:mstafford@provider-B.biz. As long as my phone number stays the same, it
can be used to obtain my current SIP URI.

Best,
Matt

-----Original Message-----
From: Tony Rutkowski [mailto:trutkowski@verisign.com] 
Sent: Sunday, February 05, 2006 10:42 AM
To: lconroy; Stafford, Matthew; Otmar Lendl
Cc: enum@ietf.org; speermint@ietf.org
Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM
signaling f lows

Hi Lawrence,

>The first is the process issue - what group (if any) coordinates
>between the different DDDS applications and their uses; this topic
...
>3761bis. It seems that your proposal is purely for Carrier/ Infrastructure/
>Private ENUM; in this case, changing 3761 has unintended consequences
>for Public/User ENUM applications.

These are great understatements.  The use of
E.164 identifiers, internationally and
domestically, is subject to more statutory,
regulatory, national security, and industry
practice requirements than any identifier
space in existence - not to mention well
established institutional jurisdiction.

The following list is a current tabulation
of E.164 resolver-directory capability
requirements, parsed into three categories,
currently in play in various industry NGN
forums.  The recently enacted EC Data
Retention Directive, and the U.S. Prevent
Cyberstalking law, add further complexity
to the mix. ;-)

best,
--tony

>basic resolver capability
>
>supplementary capability
>         Number Portability
>         Priority Access
>         Roaming
>         Quality of Service
>         Directory Assistance
>         CallerID
>         Disability Assistance
>         Language preference
>         Personal emergency (E112/911)
>         Public emergency alerts
>         Law enforcement assistance
>         DoNotCall
>         Payment Methods
>         Intercarrier Compensation
>         Profile Management
>         Presence
>         Availability
>         Location
>         Push Management
>         Digital Rights Management
>         Device Management
>         Authentication Credentials
>         Information verification level
>
>protocol feature
>         Authentication
>         Auditing
>         Multiple Syntax Support
>         Mutiple Language Support
>         Extensibility and Localisation Mechanisms

------_=_NextPart_001_01C62C13.3E107BCA
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: [Enum] a suggestion re: using flags to distinguish post-ENUM =
signaling f lows</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Tony- The E.164 space is a many-encumbered thing. No =
argument there.</FONT>
</P>

<P><FONT SIZE=3D2>All the same, I see two benefits of E.164 numbers: =
although *some* mobile devices have QWERTY keyboards, many of them =
still don't. IMO a telephone number is far and away the easiest thing =
to punch into a cellphone keypad. That's the first one. The second one =
is (essentially) number portability. My SIP URI can change from =
sip:mstafford@provider-A.net to sip:mstafford@provider-B.biz. As long =
as my phone number stays the same, it can be used to obtain my current =
SIP URI.</FONT></P>

<P><FONT SIZE=3D2>Best,</FONT>
<BR><FONT SIZE=3D2>Matt</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Tony Rutkowski [<A =
HREF=3D"mailto:trutkowski@verisign.com">mailto:trutkowski@verisign.com</=
A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Sunday, February 05, 2006 10:42 AM</FONT>
<BR><FONT SIZE=3D2>To: lconroy; Stafford, Matthew; Otmar Lendl</FONT>
<BR><FONT SIZE=3D2>Cc: enum@ietf.org; speermint@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Enum] a suggestion re: using flags to =
distinguish post-ENUM signaling f lows</FONT>
</P>

<P><FONT SIZE=3D2>Hi Lawrence,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;The first is the process issue - what group (if =
any) coordinates</FONT>
<BR><FONT SIZE=3D2>&gt;between the different DDDS applications and =
their uses; this topic</FONT>
<BR><FONT SIZE=3D2>...</FONT>
<BR><FONT SIZE=3D2>&gt;3761bis. It seems that your proposal is purely =
for Carrier/ Infrastructure/</FONT>
<BR><FONT SIZE=3D2>&gt;Private ENUM; in this case, changing 3761 has =
unintended consequences</FONT>
<BR><FONT SIZE=3D2>&gt;for Public/User ENUM applications.</FONT>
</P>

<P><FONT SIZE=3D2>These are great understatements.&nbsp; The use =
of</FONT>
<BR><FONT SIZE=3D2>E.164 identifiers, internationally and</FONT>
<BR><FONT SIZE=3D2>domestically, is subject to more statutory,</FONT>
<BR><FONT SIZE=3D2>regulatory, national security, and industry</FONT>
<BR><FONT SIZE=3D2>practice requirements than any identifier</FONT>
<BR><FONT SIZE=3D2>space in existence - not to mention well</FONT>
<BR><FONT SIZE=3D2>established institutional jurisdiction.</FONT>
</P>

<P><FONT SIZE=3D2>The following list is a current tabulation</FONT>
<BR><FONT SIZE=3D2>of E.164 resolver-directory capability</FONT>
<BR><FONT SIZE=3D2>requirements, parsed into three categories,</FONT>
<BR><FONT SIZE=3D2>currently in play in various industry NGN</FONT>
<BR><FONT SIZE=3D2>forums.&nbsp; The recently enacted EC Data</FONT>
<BR><FONT SIZE=3D2>Retention Directive, and the U.S. Prevent</FONT>
<BR><FONT SIZE=3D2>Cyberstalking law, add further complexity</FONT>
<BR><FONT SIZE=3D2>to the mix. ;-)</FONT>
</P>

<P><FONT SIZE=3D2>best,</FONT>
<BR><FONT SIZE=3D2>--tony</FONT>
</P>

<P><FONT SIZE=3D2>&gt;basic resolver capability</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;supplementary capability</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Number Portability</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Priority Access</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Roaming</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Quality of Service</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Directory Assistance</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CallerID</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Disability Assistance</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Language preference</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Personal emergency (E112/911)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Public emergency alerts</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Law enforcement assistance</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
DoNotCall</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Payment Methods</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Intercarrier Compensation</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Profile Management</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Presence</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Availability</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Location</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Push Management</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Digital Rights Management</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Device Management</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Authentication Credentials</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Information verification level</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;protocol feature</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Authentication</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Auditing</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Multiple Syntax Support</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Mutiple Language Support</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Extensibility and Localisation Mechanisms</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C62C13.3E107BCA--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============0318740338==--




From speermint-bounces@ietf.org Tue Feb 07 13:37:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6Xi6-0003X3-MT; Tue, 07 Feb 2006 13:37:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6Xi2-0003WX-1l; Tue, 07 Feb 2006 13:37:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18980;
	Tue, 7 Feb 2006 13:35:13 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F6XuL-00028Z-I2; Tue, 07 Feb 2006 13:49:45 -0500
Received: from [10.31.13.183] (neustargw.va.neustar.com [209.173.53.233])
	(authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k17IapLF028802
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 7 Feb 2006 10:36:52 -0800
Message-ID: <43E8E897.3060609@shockey.us>
Date: Tue, 07 Feb 2006 13:36:07 -0500
From: Richard Shockey <richard@shockey.us>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Stafford, Matthew" <matthew.stafford@cingular.com>
References: <DE175C3426C51144B22109E3346CFFA421774074@S75202E004049.sbms.sbc.com>
In-Reply-To: <DE175C3426C51144B22109E3346CFFA421774074@S75202E004049.sbms.sbc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: 0.8 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, speermint@ietf.org, lconroy <lconroy@insensate.co.uk>
Subject: [Speermint] Re: [Enum] a suggestion re: using flags to distinguish
 post-ENUM signaling f lows
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org



> ==> I take your point regarding the headaches w/changes to clients.
> ==> However, I'm not sure I agree that this is limited to carrier/infra-
> ==> ENUM, at least if we think of that in terms of traditional telcos/
> ==> cellcos. For example, does this discussion really bear no relevance
> ==> to enterprise applications (e.g., I want to call into my company's
> ==> IP PBX while I'm on the road?)
> 
> It appears that the proposed 'g' flag is appropriate only for SIP use 
> within Carrier ENUM, so one could WELL argue that this is an issue for the 
> SIP URI - I don't see how it can be used for other Enumservices (like 
> email:mailto, for example). Perhaps adding a SIP parameter (akin to ;user=phone) 
> would be more appropriate, or adding a new Enumservice to run alongside the 
> existing SIP one (i.e. to develop a new Enumservice definition RFC to specify 
> a SIP Gateway service)?

That would be my strong recommendation.

Something like E2U+sip:pstngw


> 
> ==> That would have a similar effect to the flag proposal, in the sense
> ==> that the contents of the ENUM NAPTR offer guidance on what to do next
> ==> (which is really what I'm after)
> 
> ==> For the sake of discussion, here's a similar example using the 
> recently-==> standardized Enumservice mms:mailto... an 'm' flag 
> indicating that the ==> NAPTR recipient should now look for an MX 
> Resource Record.

Lets not even start a discussion over using the flag field ..I do't 
think that will go very far. IMHO a non starter.

URI extentions or Enumservice definitions are the way to go


> 
> all the best,
>    Lawrence
> 
> 
-- 


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 07 13:46:52 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6XrY-00052S-Al; Tue, 07 Feb 2006 13:46:52 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6XrV-00051J-Sl; Tue, 07 Feb 2006 13:46:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19699;
	Tue, 7 Feb 2006 13:44:58 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1F6Y3n-0002Tx-4Q; Tue, 07 Feb 2006 13:59:31 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 7 Feb 2006 19:50:12 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4820@oefeg-s04.oefeg.loc>
Thread-Topic: [Enum] a suggestion re: using flags to distinguish post-ENUM
	signaling f lows
Thread-Index: AcYsFBqynbyURv/vRJ6PPsLklGRjLgAAcEuP
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Stafford, Matthew" <matthew.stafford@cingular.com>
X-Spam-Score: 0.8 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Content-Transfer-Encoding: quoted-printable
Cc: enum@ietf.org, speermint@ietf.org
Subject: [Speermint] Re: [Enum] a suggestion re: using flags to distinguish
	post-ENUM signaling f lows
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

>The second one is (essentially) number portability. My SIP URI can =
change from sip:mstafford@provider-A.net to =
>sip:mstafford@provider-B.biz. As long as my phone number stays the =
same, it can be used to obtain my current SIP URI.

What I want to have is SIP URI portability too, or in other words: I =
want to have my sip URI sip:richard@stastny.com
hosted by one provider and the possibility to port this to another.

Especially if I am a company.
=20
For more information see the ECMA christmas wish-list presented today at =
ETSI TISPAN:
Technical Report TR/91
Enterprise Communication in Next Generation Corporate Networks (NGCN) =
involving Public Next Generation Networks (NGN)
(December 2005)
http://www.ecma-international.org/publications/files/ECMA-TR/TR-091.pdf
=20
and also
Technical Report TR/92
Corporate Telecommunication Networks - Mobility for Enterprise =
Communications
(December 2005)
http://www.ecma-international.org/publications/files/ECMA-TR/TR-092.pdf
=20
The scenarios and requirements described in these two documents will not
be really easy to implement with NGNs ;-)
Of course they want to have best of both sides: peering with each other =
in all variants
AND in addition to be connected to an NGN, just to be on the safe side.
One could also say: the overflow traffic is for the telcos (say max 20%)
=20
Richard


________________________________

Von: enum-bounces@ietf.org im Auftrag von Stafford, Matthew
Gesendet: Di 07.02.2006 19:20
An: Tony Rutkowski
Cc: enum@ietf.org; speermint@ietf.org
Betreff: RE: [Enum] a suggestion re: using flags to distinguish =
post-ENUM signaling f lows



Tony- The E.164 space is a many-encumbered thing. No argument there.=20

All the same, I see two benefits of E.164 numbers: although *some* =
mobile devices have QWERTY keyboards, many of them still don't. IMO a =
telephone number is far and away the easiest thing to punch into a =
cellphone keypad. That's the first one. The second one is (essentially) =
number portability. My SIP URI can change from =
sip:mstafford@provider-A.net to sip:mstafford@provider-B.biz. As long as =
my phone number stays the same, it can be used to obtain my current SIP =
URI.

Best,=20
Matt=20

-----Original Message-----=20
From: Tony Rutkowski [mailto:trutkowski@verisign.com]=20
Sent: Sunday, February 05, 2006 10:42 AM=20
To: lconroy; Stafford, Matthew; Otmar Lendl=20
Cc: enum@ietf.org; speermint@ietf.org=20
Subject: Re: [Enum] a suggestion re: using flags to distinguish =
post-ENUM signaling f lows=20

Hi Lawrence,=20

>The first is the process issue - what group (if any) coordinates=20
>between the different DDDS applications and their uses; this topic=20
...=20
>3761bis. It seems that your proposal is purely for Carrier/ =
Infrastructure/=20
>Private ENUM; in this case, changing 3761 has unintended consequences=20
>for Public/User ENUM applications.=20

These are great understatements.  The use of=20
E.164 identifiers, internationally and=20
domestically, is subject to more statutory,=20
regulatory, national security, and industry=20
practice requirements than any identifier=20
space in existence - not to mention well=20
established institutional jurisdiction.=20

The following list is a current tabulation=20
of E.164 resolver-directory capability=20
requirements, parsed into three categories,=20
currently in play in various industry NGN=20
forums.  The recently enacted EC Data=20
Retention Directive, and the U.S. Prevent=20
Cyberstalking law, add further complexity=20
to the mix. ;-)=20

best,=20
--tony=20

>basic resolver capability=20
>=20
>supplementary capability=20
>         Number Portability=20
>         Priority Access=20
>         Roaming=20
>         Quality of Service=20
>         Directory Assistance=20
>         CallerID=20
>         Disability Assistance=20
>         Language preference=20
>         Personal emergency (E112/911)=20
>         Public emergency alerts=20
>         Law enforcement assistance=20
>         DoNotCall=20
>         Payment Methods=20
>         Intercarrier Compensation=20
>         Profile Management=20
>         Presence=20
>         Availability=20
>         Location=20
>         Push Management=20
>         Digital Rights Management=20
>         Device Management=20
>         Authentication Credentials=20
>         Information verification level=20
>=20
>protocol feature=20
>         Authentication=20
>         Auditing=20
>         Multiple Syntax Support=20
>         Mutiple Language Support=20
>         Extensibility and Localisation Mechanisms=20


_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 07 13:52:45 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6XxF-0006jl-9C; Tue, 07 Feb 2006 13:52:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Xx7-0006iH-Cw
	for speermint@megatron.ietf.org; Tue, 07 Feb 2006 13:52:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20156
	for <speermint@ietf.org>; Tue, 7 Feb 2006 13:50:46 -0500 (EST)
Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]
	helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F6Y9O-0002fq-3k
	for speermint@ietf.org; Tue, 07 Feb 2006 14:05:19 -0500
Received: from ([10.52.116.30])
	by paoakoavas09.cable.comcast.com with ESMTP  id KP-TDCH7.16878133;
	Tue, 07 Feb 2006 13:51:47 -0500
Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by
	PAOAKEXCSMTP01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Tue, 7 Feb 2006 13:51:47 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a borken
	addressingsystem?
Date: Tue, 7 Feb 2006 13:51:46 -0500
Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A167@PACDCEXCMB01.cable.comcast.com>
Thread-Topic: [Enum] RE: [Speermint] and are phone numbers a borken
	addressingsystem?
Thread-Index: AcYrwI7+uWvK8J5uRVuyJ8CBkI74WgAJ7DSQAAKZZWAACOn2kA==
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: <henry@pulver.com>, "Pfautz, Penn L, NEO" <ppfautz@att.com>,
	"Klaus Darilion" <klaus.mailinglists@pernau.at>, "Duane" <duane@e164.org>
X-OriginalArrivalTime: 07 Feb 2006 18:51:47.0574 (UTC)
	FILETIME=[8C437960:01C62C17]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: quoted-printable
Cc: speermint@ietf.org, lconroy <lconroy@insensate.co.uk>,
	Tony Rutkowski <trutkowski@verisign.com>
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org


> Coming to the point:=20
> What about peering for presence and IM?=20

If you read the new speermint charter, I hope you will agree that this
is considered an in-scope item.  A real-time communications session is a
session, no matter the user part of the URI.  However, we tried to be
clear that the priority was first to fix this for VoIP, which is
presumed to be telephone-number-based.  After that, we'll advance to
non-TN-based real-time session peering.  The problems we'll need to
solve from a speermint perspective will largely be the same in either
case - service providers (domains) will all have the same anti-abuse and
trust concerns.  The only variances may be in the bandwidth required for
various types of sessions, but who knows.

>From the charter:
"While voice calls are the primary motivation for this today, other
forms of real-time communications are and will continue to evolve as
natural additions to such peering."

Jason

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 07 13:54:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6XzJ-0008IB-9n; Tue, 07 Feb 2006 13:54:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6XzH-0008DY-HR; Tue, 07 Feb 2006 13:54:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20357;
	Tue, 7 Feb 2006 13:53:10 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1F6YBj-0002l1-1S; Tue, 07 Feb 2006 14:07:43 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 7 Feb 2006 19:54:29 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4821@oefeg-s04.oefeg.loc>
Thread-Topic: [Enum] a suggestion re: using flags to distinguish
	post-ENUMsignaling f lows
Thread-Index: AcYsFtAfom9HqPaQTVmk9jLWhxn19AAARzg1
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Richard Shockey" <richard@shockey.us>,
	"Stafford, Matthew" <matthew.stafford@cingular.com>
X-Spam-Score: 0.8 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Content-Transfer-Encoding: quoted-printable
Cc: enum@ietf.org, speermint@ietf.org, lconroy <lconroy@insensate.co.uk>
Subject: [Speermint] Re: [Enum] a suggestion re: using flags to distinguish
	post-ENUMsignaling f lows
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

>Something like E2U+sip:pstngw
=20
I thought E2U+sip:pstn
is pointing to a gw service already
=20
>URI extentions or Enumservice definitions are the way to go

E2U+mms:mailto:mx ?
or mailto:a@example.com;mx=3Dyes/no ?

E2U+sip:srv=20
or sip:a@example.com;srv=3Dyes/no
=20
Richard


________________________________

Von: enum-bounces@ietf.org im Auftrag von Richard Shockey
Gesendet: Di 07.02.2006 19:36
An: Stafford, Matthew
Cc: enum@ietf.org; speermint@ietf.org; lconroy
Betreff: Re: [Enum] a suggestion re: using flags to distinguish =
post-ENUMsignaling f lows





> =3D=3D> I take your point regarding the headaches w/changes to =
clients.
> =3D=3D> However, I'm not sure I agree that this is limited to =
carrier/infra-
> =3D=3D> ENUM, at least if we think of that in terms of traditional =
telcos/
> =3D=3D> cellcos. For example, does this discussion really bear no =
relevance
> =3D=3D> to enterprise applications (e.g., I want to call into my =
company's
> =3D=3D> IP PBX while I'm on the road?)
>
> It appears that the proposed 'g' flag is appropriate only for SIP use
> within Carrier ENUM, so one could WELL argue that this is an issue for =
the
> SIP URI - I don't see how it can be used for other Enumservices (like
> email:mailto, for example). Perhaps adding a SIP parameter (akin to =
;user=3Dphone)
> would be more appropriate, or adding a new Enumservice to run =
alongside the
> existing SIP one (i.e. to develop a new Enumservice definition RFC to =
specify
> a SIP Gateway service)?

That would be my strong recommendation.

Something like E2U+sip:pstngw


>
> =3D=3D> That would have a similar effect to the flag proposal, in the =
sense
> =3D=3D> that the contents of the ENUM NAPTR offer guidance on what to =
do next
> =3D=3D> (which is really what I'm after)
>
> =3D=3D> For the sake of discussion, here's a similar example using the
> recently-=3D=3D> standardized Enumservice mms:mailto... an 'm' flag
> indicating that the =3D=3D> NAPTR recipient should now look for an MX
> Resource Record.

Lets not even start a discussion over using the flag field ..I do't
think that will go very far. IMHO a non starter.

URI extentions or Enumservice definitions are the way to go


>
> all the best,
>    Lawrence
>
>
--


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum



_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 07 14:05:58 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6YA2-0005Ep-LX; Tue, 07 Feb 2006 14:05:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6Y9z-0005DY-Jj; Tue, 07 Feb 2006 14:05:57 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21412;
	Tue, 7 Feb 2006 14:04:06 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F6YMI-0003DT-2j; Tue, 07 Feb 2006 14:18:39 -0500
Received: from [10.31.13.183] (neustargw.va.neustar.com [209.173.53.233])
	(authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k17J6BrP000542
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 7 Feb 2006 11:06:12 -0800
Message-ID: <43E8EF7B.9000104@shockey.us>
Date: Tue, 07 Feb 2006 14:05:31 -0500
From: Richard Shockey <richard@shockey.us>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Stastny Richard <Richard.Stastny@oefeg.at>
References: <32755D354E6B65498C3BD9FD496C7D462C4820@oefeg-s04.oefeg.loc>
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4820@oefeg-s04.oefeg.loc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, speermint@ietf.org
Subject: [Speermint] Re: [Enum] a suggestion re: using flags to distinguish
 post-ENUM signaling f lows
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Stastny Richard wrote:
>> The second one is (essentially) number portability. My SIP URI can change from sip:mstafford@provider-A.net to >sip:mstafford@provider-B.biz. As long as my phone number stays the same, it can be used to obtain my current SIP URI.
> 
> What I want to have is SIP URI portability too, or in other words: I want to have my sip URI sip:richard@stastny.com
> hosted by one provider and the possibility to port this to another.
> 
> Especially if I am a company.
>  
> For more information see the ECMA christmas wish-list presented today at ETSI TISPAN:
> Technical Report TR/91
> Enterprise Communication in Next Generation Corporate Networks (NGCN) involving Public Next Generation Networks (NGN)
> (December 2005)
> http://www.ecma-international.org/publications/files/ECMA-TR/TR-091.pdf
>  
> and also
> Technical Report TR/92
> Corporate Telecommunication Networks - Mobility for Enterprise Communications
> (December 2005)
> http://www.ecma-international.org/publications/files/ECMA-TR/TR-092.pdf
>  
> The scenarios and requirements described in these two documents will not
> be really easy to implement with NGNs ;-)
> Of course they want to have best of both sides: peering with each other in all variants
> AND in addition to be connected to an NGN, just to be on the safe side.
> One could also say: the overflow traffic is for the telcos (say max 20%)


And ..just to make sure everyone is totally confused and bewildered by 
all of this, the SIP Forum is very close to publishing its Proposed 
Recommendation on IP-PBX to Service Provider interface.

Draft version four of the IP PBX / SP Interoperability specification is 
now available online for your review at the following URL:

The list for this document is taking final comments for the next 30 days.


http://data.memberclicks.com/bbattach/123566/sf-draft-twg-IP_PBX_SP_Interop-sibley-v4.pdf



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 07 14:07:34 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6YBa-0006kd-1H; Tue, 07 Feb 2006 14:07:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6YBY-0006jj-L0; Tue, 07 Feb 2006 14:07:32 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21573;
	Tue, 7 Feb 2006 14:05:43 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F6YNs-0003Hf-Dh; Tue, 07 Feb 2006 14:20:16 -0500
Received: from [10.31.13.183] (neustargw.va.neustar.com [209.173.53.233])
	(authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k17J7jNg000811
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 7 Feb 2006 11:07:47 -0800
Message-ID: <43E8EFDA.7020207@shockey.us>
Date: Tue, 07 Feb 2006 14:07:06 -0500
From: Richard Shockey <richard@shockey.us>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Stastny Richard <Richard.Stastny@oefeg.at>
References: <32755D354E6B65498C3BD9FD496C7D462C4821@oefeg-s04.oefeg.loc>
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4821@oefeg-s04.oefeg.loc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: 0.8 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, speermint@ietf.org, lconroy <lconroy@insensate.co.uk>
Subject: [Speermint] Re: [Enum] a suggestion re: using flags to distinguish
 post-ENUMsignaling f lows
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Stastny Richard wrote:
>> Something like E2U+sip:pstngw
>  
> I thought E2U+sip:pstn
> is pointing to a gw service already
>  

Good point! I forgot about that definition.



-- 


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 07 17:46:31 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6bbT-0003C6-Hc; Tue, 07 Feb 2006 17:46:31 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6bbL-0003B8-0J; Tue, 07 Feb 2006 17:46:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08703;
	Tue, 7 Feb 2006 17:44:28 -0500 (EST)
Received: from extmail09.cingular.com ([170.35.225.24] helo=cingular.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F6bnc-0002ZV-0T; Tue, 07 Feb 2006 17:59:04 -0500
Received: from ([10.3.188.52])
	by extmail09.cingular.com with ESMTP  id KP-VYGZ6.56986858;
	Tue, 07 Feb 2006 17:45:34 -0500
Received: by s75202e004001.tdc.cingular.net with Internet Mail Service
	(5.5.2657.72) id <1FCBZW59>; Tue, 7 Feb 2006 16:49:09 -0600
Message-ID: <DE175C3426C51144B22109E3346CFFA42186EC6B@S75202E004049.sbms.sbc.com>
To: Stastny Richard <Richard.Stastny@oefeg.at>
Date: Tue, 7 Feb 2006 16:46:19 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
From: "Stafford, Matthew" <matthew.stafford@cingular.com>
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86
Cc: enum@ietf.org, speermint@ietf.org
Subject: [Speermint] RE: [Enum] a suggestion re: using flags to distinguish
	post-ENUM signaling f lows
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2076375323=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============2076375323==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C62C38.4F8638E8"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C62C38.4F8638E8
Content-Type: text/plain

Richard- 

===> What I want to have is SIP URI portability too, or in other words: I
===> want to have my sip URI sip:richard@stastny.com
===> hosted by one provider and the possibility to port this to another.

No disagreement there. I guess I view these portability options as
complementary (i.e., both useful depending on individual preferences).

Thanks for the document pointers.

Matt

-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] 
Sent: Tuesday, February 07, 2006 12:50 PM
To: Stafford, Matthew
Cc: enum@ietf.org; speermint@ietf.org
Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM
signaling f lows

>The second one is (essentially) number portability. My SIP URI can change
from sip:mstafford@provider-A.net to >sip:mstafford@provider-B.biz. As long
as my phone number stays the same, it can be used to obtain my current SIP
URI.

What I want to have is SIP URI portability too, or in other words: I want to
have my sip URI sip:richard@stastny.com
hosted by one provider and the possibility to port this to another.

Especially if I am a company.
 
For more information see the ECMA christmas wish-list presented today at
ETSI TISPAN:
Technical Report TR/91
Enterprise Communication in Next Generation Corporate Networks (NGCN)
involving Public Next Generation Networks (NGN)
(December 2005)
http://www.ecma-international.org/publications/files/ECMA-TR/TR-091.pdf
 
and also
Technical Report TR/92
Corporate Telecommunication Networks - Mobility for Enterprise
Communications
(December 2005)
http://www.ecma-international.org/publications/files/ECMA-TR/TR-092.pdf
 
The scenarios and requirements described in these two documents will not
be really easy to implement with NGNs ;-)
Of course they want to have best of both sides: peering with each other in
all variants
AND in addition to be connected to an NGN, just to be on the safe side.
One could also say: the overflow traffic is for the telcos (say max 20%)
 
Richard


________________________________

Von: enum-bounces@ietf.org im Auftrag von Stafford, Matthew
Gesendet: Di 07.02.2006 19:20
An: Tony Rutkowski
Cc: enum@ietf.org; speermint@ietf.org
Betreff: RE: [Enum] a suggestion re: using flags to distinguish post-ENUM
signaling f lows



Tony- The E.164 space is a many-encumbered thing. No argument there. 

All the same, I see two benefits of E.164 numbers: although *some* mobile
devices have QWERTY keyboards, many of them still don't. IMO a telephone
number is far and away the easiest thing to punch into a cellphone keypad.
That's the first one. The second one is (essentially) number portability. My
SIP URI can change from sip:mstafford@provider-A.net to
sip:mstafford@provider-B.biz. As long as my phone number stays the same, it
can be used to obtain my current SIP URI.

Best, 
Matt 

-----Original Message----- 
From: Tony Rutkowski [mailto:trutkowski@verisign.com] 
Sent: Sunday, February 05, 2006 10:42 AM 
To: lconroy; Stafford, Matthew; Otmar Lendl 
Cc: enum@ietf.org; speermint@ietf.org 
Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM
signaling f lows 

Hi Lawrence, 

>The first is the process issue - what group (if any) coordinates 
>between the different DDDS applications and their uses; this topic 
... 
>3761bis. It seems that your proposal is purely for Carrier/ Infrastructure/

>Private ENUM; in this case, changing 3761 has unintended consequences 
>for Public/User ENUM applications. 

These are great understatements.  The use of 
E.164 identifiers, internationally and 
domestically, is subject to more statutory, 
regulatory, national security, and industry 
practice requirements than any identifier 
space in existence - not to mention well 
established institutional jurisdiction. 

The following list is a current tabulation 
of E.164 resolver-directory capability 
requirements, parsed into three categories, 
currently in play in various industry NGN 
forums.  The recently enacted EC Data 
Retention Directive, and the U.S. Prevent 
Cyberstalking law, add further complexity 
to the mix. ;-) 

best, 
--tony 

>basic resolver capability 
> 
>supplementary capability 
>         Number Portability 
>         Priority Access 
>         Roaming 
>         Quality of Service 
>         Directory Assistance 
>         CallerID 
>         Disability Assistance 
>         Language preference 
>         Personal emergency (E112/911) 
>         Public emergency alerts 
>         Law enforcement assistance 
>         DoNotCall 
>         Payment Methods 
>         Intercarrier Compensation 
>         Profile Management 
>         Presence 
>         Availability 
>         Location 
>         Push Management 
>         Digital Rights Management 
>         Device Management 
>         Authentication Credentials 
>         Information verification level 
> 
>protocol feature 
>         Authentication 
>         Auditing 
>         Multiple Syntax Support 
>         Mutiple Language Support 
>         Extensibility and Localisation Mechanisms 

------_=_NextPart_001_01C62C38.4F8638E8
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: [Enum] a suggestion re: using flags to distinguish post-ENUM =
signaling f lows</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Richard- </FONT>
</P>

<P><FONT SIZE=3D2>=3D=3D=3D&gt; What I want to have is SIP URI =
portability too, or in other words: I =3D=3D=3D&gt; want to have my sip =
URI sip:richard@stastny.com</FONT></P>

<P><FONT SIZE=3D2>=3D=3D=3D&gt; hosted by one provider and the =
possibility to port this to another.</FONT>
</P>

<P><FONT SIZE=3D2>No disagreement there. I guess I view these =
portability options as complementary (i.e., both useful depending on =
individual preferences).</FONT></P>

<P><FONT SIZE=3D2>Thanks for the document pointers.</FONT>
</P>

<P><FONT SIZE=3D2>Matt</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stastny Richard [<A =
HREF=3D"mailto:Richard.Stastny@oefeg.at">mailto:Richard.Stastny@oefeg.at=
</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, February 07, 2006 12:50 PM</FONT>
<BR><FONT SIZE=3D2>To: Stafford, Matthew</FONT>
<BR><FONT SIZE=3D2>Cc: enum@ietf.org; speermint@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Enum] a suggestion re: using flags to =
distinguish post-ENUM signaling f lows</FONT>
</P>

<P><FONT SIZE=3D2>&gt;The second one is (essentially) number =
portability. My SIP URI can change from sip:mstafford@provider-A.net to =
&gt;sip:mstafford@provider-B.biz. As long as my phone number stays the =
same, it can be used to obtain my current SIP URI.</FONT></P>

<P><FONT SIZE=3D2>What I want to have is SIP URI portability too, or in =
other words: I want to have my sip URI sip:richard@stastny.com</FONT>
<BR><FONT SIZE=3D2>hosted by one provider and the possibility to port =
this to another.</FONT>
</P>

<P><FONT SIZE=3D2>Especially if I am a company.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>For more information see the ECMA christmas =
wish-list presented today at ETSI TISPAN:</FONT>
<BR><FONT SIZE=3D2>Technical Report TR/91</FONT>
<BR><FONT SIZE=3D2>Enterprise Communication in Next Generation =
Corporate Networks (NGCN) involving Public Next Generation Networks =
(NGN)</FONT>
<BR><FONT SIZE=3D2>(December 2005)</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ecma-international.org/publications/files/ECMA-TR/TR-=
091.pdf" =
TARGET=3D"_blank">http://www.ecma-international.org/publications/files/E=
CMA-TR/TR-091.pdf</A></FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>and also</FONT>
<BR><FONT SIZE=3D2>Technical Report TR/92</FONT>
<BR><FONT SIZE=3D2>Corporate Telecommunication Networks - Mobility for =
Enterprise Communications</FONT>
<BR><FONT SIZE=3D2>(December 2005)</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ecma-international.org/publications/files/ECMA-TR/TR-=
092.pdf" =
TARGET=3D"_blank">http://www.ecma-international.org/publications/files/E=
CMA-TR/TR-092.pdf</A></FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>The scenarios and requirements described in these =
two documents will not</FONT>
<BR><FONT SIZE=3D2>be really easy to implement with NGNs ;-)</FONT>
<BR><FONT SIZE=3D2>Of course they want to have best of both sides: =
peering with each other in all variants</FONT>
<BR><FONT SIZE=3D2>AND in addition to be connected to an NGN, just to =
be on the safe side.</FONT>
<BR><FONT SIZE=3D2>One could also say: the overflow traffic is for the =
telcos (say max 20%)</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Richard</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>________________________________</FONT>
</P>

<P><FONT SIZE=3D2>Von: enum-bounces@ietf.org im Auftrag von Stafford, =
Matthew</FONT>
<BR><FONT SIZE=3D2>Gesendet: Di 07.02.2006 19:20</FONT>
<BR><FONT SIZE=3D2>An: Tony Rutkowski</FONT>
<BR><FONT SIZE=3D2>Cc: enum@ietf.org; speermint@ietf.org</FONT>
<BR><FONT SIZE=3D2>Betreff: RE: [Enum] a suggestion re: using flags to =
distinguish post-ENUM signaling f lows</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Tony- The E.164 space is a many-encumbered thing. No =
argument there. </FONT>
</P>

<P><FONT SIZE=3D2>All the same, I see two benefits of E.164 numbers: =
although *some* mobile devices have QWERTY keyboards, many of them =
still don't. IMO a telephone number is far and away the easiest thing =
to punch into a cellphone keypad. That's the first one. The second one =
is (essentially) number portability. My SIP URI can change from =
sip:mstafford@provider-A.net to sip:mstafford@provider-B.biz. As long =
as my phone number stays the same, it can be used to obtain my current =
SIP URI.</FONT></P>

<P><FONT SIZE=3D2>Best, </FONT>
<BR><FONT SIZE=3D2>Matt </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>From: Tony Rutkowski [<A =
HREF=3D"mailto:trutkowski@verisign.com">mailto:trutkowski@verisign.com</=
A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Sunday, February 05, 2006 10:42 AM </FONT>
<BR><FONT SIZE=3D2>To: lconroy; Stafford, Matthew; Otmar Lendl </FONT>
<BR><FONT SIZE=3D2>Cc: enum@ietf.org; speermint@ietf.org </FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Enum] a suggestion re: using flags to =
distinguish post-ENUM signaling f lows </FONT>
</P>

<P><FONT SIZE=3D2>Hi Lawrence, </FONT>
</P>

<P><FONT SIZE=3D2>&gt;The first is the process issue - what group (if =
any) coordinates </FONT>
<BR><FONT SIZE=3D2>&gt;between the different DDDS applications and =
their uses; this topic </FONT>
<BR><FONT SIZE=3D2>... </FONT>
<BR><FONT SIZE=3D2>&gt;3761bis. It seems that your proposal is purely =
for Carrier/ Infrastructure/ </FONT>
<BR><FONT SIZE=3D2>&gt;Private ENUM; in this case, changing 3761 has =
unintended consequences </FONT>
<BR><FONT SIZE=3D2>&gt;for Public/User ENUM applications. </FONT>
</P>

<P><FONT SIZE=3D2>These are great understatements.&nbsp; The use of =
</FONT>
<BR><FONT SIZE=3D2>E.164 identifiers, internationally and </FONT>
<BR><FONT SIZE=3D2>domestically, is subject to more statutory, </FONT>
<BR><FONT SIZE=3D2>regulatory, national security, and industry </FONT>
<BR><FONT SIZE=3D2>practice requirements than any identifier </FONT>
<BR><FONT SIZE=3D2>space in existence - not to mention well </FONT>
<BR><FONT SIZE=3D2>established institutional jurisdiction. </FONT>
</P>

<P><FONT SIZE=3D2>The following list is a current tabulation </FONT>
<BR><FONT SIZE=3D2>of E.164 resolver-directory capability </FONT>
<BR><FONT SIZE=3D2>requirements, parsed into three categories, </FONT>
<BR><FONT SIZE=3D2>currently in play in various industry NGN </FONT>
<BR><FONT SIZE=3D2>forums.&nbsp; The recently enacted EC Data </FONT>
<BR><FONT SIZE=3D2>Retention Directive, and the U.S. Prevent </FONT>
<BR><FONT SIZE=3D2>Cyberstalking law, add further complexity </FONT>
<BR><FONT SIZE=3D2>to the mix. ;-) </FONT>
</P>

<P><FONT SIZE=3D2>best, </FONT>
<BR><FONT SIZE=3D2>--tony </FONT>
</P>

<P><FONT SIZE=3D2>&gt;basic resolver capability </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;supplementary capability </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Number Portability </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Priority Access </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Roaming </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Quality of Service </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Directory Assistance </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
CallerID </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Disability Assistance </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Language preference </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Personal emergency (E112/911) </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Public emergency alerts </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Law enforcement assistance </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
DoNotCall </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Payment Methods </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Intercarrier Compensation </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Profile Management </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Presence </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Availability </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Location </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Push Management </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Digital Rights Management </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Device Management </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Authentication Credentials </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Information verification level </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;protocol feature </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Authentication </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Auditing </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Multiple Syntax Support </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Mutiple Language Support </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Extensibility and Localisation Mechanisms </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C62C38.4F8638E8--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============2076375323==--




From speermint-bounces@ietf.org Tue Feb 07 18:06:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6bvB-0001TT-C9; Tue, 07 Feb 2006 18:06:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6bv9-0001T2-NX; Tue, 07 Feb 2006 18:06:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09813;
	Tue, 7 Feb 2006 18:05:02 -0500 (EST)
Received: from h139-142-184-176.roothosts.com ([139.142.184.176]
	helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F6c7T-00037z-Ia; Tue, 07 Feb 2006 18:19:36 -0500
Received: from [192.168.1.101] (cpe-24-95-54-117.columbus.res.rr.com
	[24.95.54.117])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified))
	by wodka.aus-biz.com (Postfix) with ESMTP id 24E09260F;
	Tue,  7 Feb 2006 18:06:22 -0500 (EST)
Message-ID: <43E927ED.7080205@e164.org>
Date: Tue, 07 Feb 2006 18:06:21 -0500
From: Duane <duane@e164.org>
User-Agent: Mail/News 1.5 (X11/20060119)
MIME-Version: 1.0
To: "Stafford, Matthew" <matthew.stafford@cingular.com>
Subject: Re: [Speermint] RE: [Enum] a suggestion re: using flags to distinguish
	post-ENUM signaling f lows
References: <DE175C3426C51144B22109E3346CFFA42186EC6B@S75202E004049.sbms.sbc.com>
In-Reply-To: <DE175C3426C51144B22109E3346CFFA42186EC6B@S75202E004049.sbms.sbc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, Stastny Richard <Richard.Stastny@oefeg.at>,
	speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Stafford, Matthew wrote:
> Richard-
> 
> ===> What I want to have is SIP URI portability too, or in other words: 
> I ===> want to have my sip URI sip:richard@stastny.com
> 
> ===> hosted by one provider and the possibility to port this to another.
> 
> No disagreement there. I guess I view these portability options as 
> complementary (i.e., both useful depending on individual preferences).

Wouldn't that be the equivalent to an email provider doing an email 
forward, (or in this case a 3XX redirection) ?

If that's the case, phone number portability would solve that by letting 
the user updates their enum record to point to the new location, or 
having your old provider add a 3XX redirect to their software, a lot of 
ISPs have taken to charging a lot of money for simple email redirects if 
a user moves to another ISP but still wants to collect from their old 
address. Of course owning your own domain would overcome this, just like 
it does with email redirections. Kind of a moot point as far as I can tell.

-- 

Best regards,
  Duane

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 07 18:16:33 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6c4X-0003hz-Jw; Tue, 07 Feb 2006 18:16:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6c4T-0003gw-Gq; Tue, 07 Feb 2006 18:16:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10597;
	Tue, 7 Feb 2006 18:14:36 -0500 (EST)
Received: from extmail09.cingular.com ([170.35.225.24] helo=cingular.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F6cGk-0003T9-Sn; Tue, 07 Feb 2006 18:29:11 -0500
Received: from ([10.3.188.52])
	by extmail09.cingular.com with ESMTP  id KP-VYGZ6.56991565;
	Tue, 07 Feb 2006 18:15:46 -0500
Received: by s75202e004001.tdc.cingular.net with Internet Mail Service
	(5.5.2657.72) id <1FCBZ5AG>; Tue, 7 Feb 2006 17:19:21 -0600
Message-ID: <DE175C3426C51144B22109E3346CFFA42186ED02@S75202E004049.sbms.sbc.com>
To: Stastny Richard <Richard.Stastny@oefeg.at>
Date: Tue, 7 Feb 2006 17:16:26 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
From: "Stafford, Matthew" <matthew.stafford@cingular.com>
X-Spam-Score: 1.3 (+)
X-Scan-Signature: a5d64674af3d12893846a18a44c07b83
Cc: enum@ietf.org, speermint@ietf.org
Subject: [Speermint] RE: [Enum] a suggestion re: using flags to distinguish
	post-ENUMs ignaling f lows
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0867493948=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0867493948==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C62C3C.8517ABBE"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C62C3C.8517ABBE
Content-Type: text/plain

Richard- 

Regarding
==> I thought E2U+sip:pstn
==> is pointing to a gw service already

I consulted draft-ietf-enum-pstn-03. As best I can tell from a brief
reading, the E2U+pstn records are helping you to find a media gateway for
PSTN interconnect. I'm looking specifically at 7.1(d) and 7.2(f) in the call
processing scenarios.

Maybe "g" for gateway was a bad choice in my original message. Since "s" and
"p" are already defined in non-ENUM contexts in the DDDS RFCs, I was looking
for another term (other than server or proxy). Unless I read the PSTN draft
incorrectly (or I'm looking at the wrong document altogether), I believe
that it does *not* address the following question: I've done an ENUM query
and extracted the URI from the ENUM NAPTR; how should I interpret the domain
portion of the URI? 

Also, I'm curious to see the reactions to

==> E2U+mms:mailto:mx ?
==> or mailto:a@example.com;mx=yes/no ?

==> E2U+sip:srv 
==> or sip:a@example.com;srv=yes/no

Appending ";mx=yes/no" (or ";srv=yes/no" in the SIP case) gives information
that can just as easily live outside the ENUM context. Not true of the
Enumservice approach (or, for that matter, the ENUM NAPTR flag)- both of
those are tied directly to the ENUM record.

A random thought: If one wanted to go with mailto:a@example.com;mx=yes/no,
where would the change to the mailto: URI scheme be documented? 

Best,
Matt

-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] 
Sent: Tuesday, February 07, 2006 12:54 PM
To: Richard Shockey; Stafford, Matthew
Cc: enum@ietf.org; speermint@ietf.org; lconroy
Subject: Re: [Enum] a suggestion re: using flags to distinguish
post-ENUMsignaling f lows

>Something like E2U+sip:pstngw
 
I thought E2U+sip:pstn
is pointing to a gw service already
 
>URI extentions or Enumservice definitions are the way to go

E2U+mms:mailto:mx ?
or mailto:a@example.com;mx=yes/no ?

E2U+sip:srv 
or sip:a@example.com;srv=yes/no
 
Richard


________________________________

Von: enum-bounces@ietf.org im Auftrag von Richard Shockey
Gesendet: Di 07.02.2006 19:36
An: Stafford, Matthew
Cc: enum@ietf.org; speermint@ietf.org; lconroy
Betreff: Re: [Enum] a suggestion re: using flags to distinguish
post-ENUMsignaling f lows





> ==> I take your point regarding the headaches w/changes to clients.
> ==> However, I'm not sure I agree that this is limited to carrier/infra-
> ==> ENUM, at least if we think of that in terms of traditional telcos/
> ==> cellcos. For example, does this discussion really bear no relevance
> ==> to enterprise applications (e.g., I want to call into my company's
> ==> IP PBX while I'm on the road?)
>
> It appears that the proposed 'g' flag is appropriate only for SIP use
> within Carrier ENUM, so one could WELL argue that this is an issue for the
> SIP URI - I don't see how it can be used for other Enumservices (like
> email:mailto, for example). Perhaps adding a SIP parameter (akin to
;user=phone)
> would be more appropriate, or adding a new Enumservice to run alongside
the
> existing SIP one (i.e. to develop a new Enumservice definition RFC to
specify
> a SIP Gateway service)?

That would be my strong recommendation.

Something like E2U+sip:pstngw


>
> ==> That would have a similar effect to the flag proposal, in the sense
> ==> that the contents of the ENUM NAPTR offer guidance on what to do next
> ==> (which is really what I'm after)
>
> ==> For the sake of discussion, here's a similar example using the
> recently-==> standardized Enumservice mms:mailto... an 'm' flag
> indicating that the ==> NAPTR recipient should now look for an MX
> Resource Record.

Lets not even start a discussion over using the flag field ..I do't
think that will go very far. IMHO a non starter.

URI extentions or Enumservice definitions are the way to go


>
> all the best,
>    Lawrence
>
>
--


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum


------_=_NextPart_001_01C62C3C.8517ABBE
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: [Enum] a suggestion re: using flags to distinguish =
post-ENUMsignaling f lows</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Richard- </FONT>
</P>

<P><FONT SIZE=3D2>Regarding</FONT>
<BR><FONT SIZE=3D2>=3D=3D&gt; I thought E2U+sip:pstn</FONT>
<BR><FONT SIZE=3D2>=3D=3D&gt; is pointing to a gw service =
already</FONT>
</P>

<P><FONT SIZE=3D2>I consulted draft-ietf-enum-pstn-03. As best I can =
tell from a brief reading, the E2U+pstn records are helping you to find =
a media gateway for PSTN interconnect. I'm looking specifically at =
7.1(d) and 7.2(f) in the call processing scenarios.</FONT></P>

<P><FONT SIZE=3D2>Maybe &quot;g&quot; for gateway was a bad choice in =
my original message. Since &quot;s&quot; and &quot;p&quot; are already =
defined in non-ENUM contexts in the DDDS RFCs, I was looking for =
another term (other than server or proxy). Unless I read the PSTN draft =
incorrectly (or I'm looking at the wrong document altogether), I =
believe that it does *not* address the following question: I've done an =
ENUM query and extracted the URI from the ENUM NAPTR; how should I =
interpret the domain portion of the URI? </FONT></P>

<P><FONT SIZE=3D2>Also, I'm curious to see the reactions to</FONT>
</P>

<P><FONT SIZE=3D2>=3D=3D&gt; E2U+mms:<A =
HREF=3D"mailto:mx">mailto:mx</A> ?</FONT>
<BR><FONT SIZE=3D2>=3D=3D&gt; or <A =
HREF=3D"mailto:a@example.com;mx=3Dyes/no">mailto:a@example.com;mx=3Dyes/=
no</A> ?</FONT>
</P>

<P><FONT SIZE=3D2>=3D=3D&gt; E2U+sip:srv </FONT>
<BR><FONT SIZE=3D2>=3D=3D&gt; or sip:a@example.com;srv=3Dyes/no</FONT>
</P>

<P><FONT SIZE=3D2>Appending &quot;;mx=3Dyes/no&quot; (or =
&quot;;srv=3Dyes/no&quot; in the SIP case) gives information that can =
just as easily live outside the ENUM context. Not true of the =
Enumservice approach (or, for that matter, the ENUM NAPTR flag)- both =
of those are tied directly to the ENUM record.</FONT></P>

<P><FONT SIZE=3D2>A random thought: If one wanted to go with <A =
HREF=3D"mailto:a@example.com;mx=3Dyes/no">mailto:a@example.com;mx=3Dyes/=
no</A>, where would the change to the mailto: URI scheme be documented? =
</FONT></P>

<P><FONT SIZE=3D2>Best,</FONT>
<BR><FONT SIZE=3D2>Matt</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stastny Richard [<A =
HREF=3D"mailto:Richard.Stastny@oefeg.at">mailto:Richard.Stastny@oefeg.at=
</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, February 07, 2006 12:54 PM</FONT>
<BR><FONT SIZE=3D2>To: Richard Shockey; Stafford, Matthew</FONT>
<BR><FONT SIZE=3D2>Cc: enum@ietf.org; speermint@ietf.org; =
lconroy</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Enum] a suggestion re: using flags to =
distinguish post-ENUMsignaling f lows</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Something like E2U+sip:pstngw</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>I thought E2U+sip:pstn</FONT>
<BR><FONT SIZE=3D2>is pointing to a gw service already</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt;URI extentions or Enumservice definitions are =
the way to go</FONT>
</P>

<P><FONT SIZE=3D2>E2U+mms:<A HREF=3D"mailto:mx">mailto:mx</A> ?</FONT>
<BR><FONT SIZE=3D2>or <A =
HREF=3D"mailto:a@example.com;mx=3Dyes/no">mailto:a@example.com;mx=3Dyes/=
no</A> ?</FONT>
</P>

<P><FONT SIZE=3D2>E2U+sip:srv </FONT>
<BR><FONT SIZE=3D2>or sip:a@example.com;srv=3Dyes/no</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Richard</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>________________________________</FONT>
</P>

<P><FONT SIZE=3D2>Von: enum-bounces@ietf.org im Auftrag von Richard =
Shockey</FONT>
<BR><FONT SIZE=3D2>Gesendet: Di 07.02.2006 19:36</FONT>
<BR><FONT SIZE=3D2>An: Stafford, Matthew</FONT>
<BR><FONT SIZE=3D2>Cc: enum@ietf.org; speermint@ietf.org; =
lconroy</FONT>
<BR><FONT SIZE=3D2>Betreff: Re: [Enum] a suggestion re: using flags to =
distinguish post-ENUMsignaling f lows</FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; =3D=3D&gt; I take your point regarding the =
headaches w/changes to clients.</FONT>
<BR><FONT SIZE=3D2>&gt; =3D=3D&gt; However, I'm not sure I agree that =
this is limited to carrier/infra-</FONT>
<BR><FONT SIZE=3D2>&gt; =3D=3D&gt; ENUM, at least if we think of that =
in terms of traditional telcos/</FONT>
<BR><FONT SIZE=3D2>&gt; =3D=3D&gt; cellcos. For example, does this =
discussion really bear no relevance</FONT>
<BR><FONT SIZE=3D2>&gt; =3D=3D&gt; to enterprise applications (e.g., I =
want to call into my company's</FONT>
<BR><FONT SIZE=3D2>&gt; =3D=3D&gt; IP PBX while I'm on the =
road?)</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; It appears that the proposed 'g' flag is =
appropriate only for SIP use</FONT>
<BR><FONT SIZE=3D2>&gt; within Carrier ENUM, so one could WELL argue =
that this is an issue for the</FONT>
<BR><FONT SIZE=3D2>&gt; SIP URI - I don't see how it can be used for =
other Enumservices (like</FONT>
<BR><FONT SIZE=3D2>&gt; email:mailto, for example). Perhaps adding a =
SIP parameter (akin to ;user=3Dphone)</FONT>
<BR><FONT SIZE=3D2>&gt; would be more appropriate, or adding a new =
Enumservice to run alongside the</FONT>
<BR><FONT SIZE=3D2>&gt; existing SIP one (i.e. to develop a new =
Enumservice definition RFC to specify</FONT>
<BR><FONT SIZE=3D2>&gt; a SIP Gateway service)?</FONT>
</P>

<P><FONT SIZE=3D2>That would be my strong recommendation.</FONT>
</P>

<P><FONT SIZE=3D2>Something like E2U+sip:pstngw</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =3D=3D&gt; That would have a similar effect to =
the flag proposal, in the sense</FONT>
<BR><FONT SIZE=3D2>&gt; =3D=3D&gt; that the contents of the ENUM NAPTR =
offer guidance on what to do next</FONT>
<BR><FONT SIZE=3D2>&gt; =3D=3D&gt; (which is really what I'm =
after)</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =3D=3D&gt; For the sake of discussion, here's a =
similar example using the</FONT>
<BR><FONT SIZE=3D2>&gt; recently-=3D=3D&gt; standardized Enumservice =
mms:mailto... an 'm' flag</FONT>
<BR><FONT SIZE=3D2>&gt; indicating that the =3D=3D&gt; NAPTR recipient =
should now look for an MX</FONT>
<BR><FONT SIZE=3D2>&gt; Resource Record.</FONT>
</P>

<P><FONT SIZE=3D2>Lets not even start a discussion over using the flag =
field ..I do't</FONT>
<BR><FONT SIZE=3D2>think that will go very far. IMHO a non =
starter.</FONT>
</P>

<P><FONT SIZE=3D2>URI extentions or Enumservice definitions are the way =
to go</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; all the best,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Lawrence</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>--</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>&nbsp;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&=
gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&=
gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&=
gt;&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>Richard Shockey, Director - Member of Technical =
Staff</FONT>
<BR><FONT SIZE=3D2>NeuStar Inc.</FONT>
<BR><FONT SIZE=3D2>46000 Center Oak Plaza&nbsp; -&nbsp;&nbsp; Sterling, =
VA&nbsp; 20166</FONT>
<BR><FONT SIZE=3D2>sip:rshockey(at)iptel.org&nbsp;&nbsp; =
sip:57141(at)fwd.pulver.com</FONT>
<BR><FONT SIZE=3D2>ENUM +87810-13313-31331</FONT>
<BR><FONT SIZE=3D2>PSTN Office +1 571.434.5651 PSTN Mobile +1 =
703.593.2683</FONT>
<BR><FONT SIZE=3D2>Fax: +1 815.333.1237</FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:richard(at)shockey.us">mailto:richard(at)shockey.us</A>&g=
t; or</FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:richard.shockey(at)neustar.biz">mailto:richard.shockey(at=
)neustar.biz</A>&gt;</FONT>
<BR><FONT SIZE=3D2>&lt;<A HREF=3D"http://www.neustar.biz" =
TARGET=3D"_blank">http://www.neustar.biz</A>&gt; ; &lt;<A =
HREF=3D"http://www.enum.org" =
TARGET=3D"_blank">http://www.enum.org</A>&gt;</FONT>
<BR><FONT =
SIZE=3D2>&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt=
;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt=
;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt=
;&lt;</FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>enum mailing list</FONT>
<BR><FONT SIZE=3D2>enum@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/enum" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/enum</A></FONT>=

</P>

</BODY>
</HTML>
------_=_NextPart_001_01C62C3C.8517ABBE--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============0867493948==--




From speermint-bounces@ietf.org Tue Feb 07 19:17:55 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6d1v-0007GY-BL; Tue, 07 Feb 2006 19:17:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F6d1t-0007GT-Ek
	for speermint@megatron.ietf.org; Tue, 07 Feb 2006 19:17:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13661
	for <speermint@ietf.org>; Tue, 7 Feb 2006 19:16:10 -0500 (EST)
Received: from lennon.multicasttech.com
	([63.105.122.7] helo=multicasttech.com ident=root)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6dEL-00057g-4p
	for speermint@ietf.org; Tue, 07 Feb 2006 19:30:46 -0500
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
	by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
	with ESMTP id 3863343 for speermint@ietf.org;
	Tue, 07 Feb 2006 19:13:19 -0500
Mime-Version: 1.0 (Apple Message framework v746.2)
References: <1139356535.333438.1ae4da5e2bb613d6.f7ba099@persist.google.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <ACB53B81-1A26-4320-8032-D147277E1A37@multicasttech.com>
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks <tme@multicasttech.com>
Date: Tue, 7 Feb 2006 19:17:44 -0500
To: speermint@ietf.org
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Subject: [Speermint] Speermint in the news
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Thought people might be interested.

http://www.newtelephony.com/news/62h7161629.html

Begin forwarded message:

> From: Google Alerts <googlealerts-noreply@google.com>
> Date: February 7, 2006 6:55:35 PM EST
> To: tme@multicasttech.com
> Subject: Google Alert - ietf
>
> Google Alert for: ietf
>
> VoIP Peering: A Mixed Blessing
> New Telephony - Phoenix,AZ,USA
> ... is a relatively new phenomenon in VoIP that has given rise to  
> several new service providers and now a standard-setting effort in  
> the IETF (Internet Engineering ...
>
>
>
>  This once a day Google Alert is brought to you by Google.
> Remove this alert.
> Create another alert.
> Manage your alerts.


_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 07 22:50:08 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6gLI-0005VD-RI; Tue, 07 Feb 2006 22:50:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F6gLG-0005UL-SL
	for speermint@megatron.ietf.org; Tue, 07 Feb 2006 22:50:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09568
	for <speermint@ietf.org>; Tue, 7 Feb 2006 22:48:16 -0500 (EST)
Received: from m106.maoz.com ([205.167.76.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6gXe-0001FJ-3u
	for speermint@ietf.org; Tue, 07 Feb 2006 23:02:55 -0500
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])
	by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k183nlPA016232;
	Tue, 7 Feb 2006 19:49:47 -0800
Received: (from dmm@localhost)
	by m106.maoz.com (8.13.4/8.12.11/Submit) id k183nlN4016231;
	Tue, 7 Feb 2006 19:49:47 -0800
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using
	-f
Date: Tue, 7 Feb 2006 19:49:47 -0800
From: David Meyer <dmm@1-4-5.net>
To: Marshall Eubanks <tme@multicasttech.com>
Subject: Re: [Speermint] Speermint in the news
Message-ID: <20060208034947.GA16207@1-4-5.net>
References: <1139356535.333438.1ae4da5e2bb613d6.f7ba099@persist.google.com>
	<ACB53B81-1A26-4320-8032-D147277E1A37@multicasttech.com>
Mime-Version: 1.0
In-Reply-To: <ACB53B81-1A26-4320-8032-D147277E1A37@multicasttech.com>
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader,
	Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0500362165=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org


--===============0500362165==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4"
Content-Disposition: inline


--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I'm pretty much unhappy at being misquoted. I had forgotten
not to talk to the press. Oh well. Dave

On Tue, Feb 07, 2006 at 07:17:44PM -0500, Marshall Eubanks wrote:
> Thought people might be interested.
>=20
> http://www.newtelephony.com/news/62h7161629.html
>=20
> Begin forwarded message:
>=20
> >From: Google Alerts <googlealerts-noreply@google.com>
> >Date: February 7, 2006 6:55:35 PM EST
> >To: tme@multicasttech.com
> >Subject: Google Alert - ietf
> >
> >Google Alert for: ietf
> >
> >VoIP Peering: A Mixed Blessing
> >New Telephony - Phoenix,AZ,USA
> >... is a relatively new phenomenon in VoIP that has given rise to =20
> >several new service providers and now a standard-setting effort in =20
> >the IETF (Internet Engineering ...
> >
> >
> >
> > This once a day Google Alert is brought to you by Google.
> >Remove this alert.
> >Create another alert.
> >Manage your alerts.
>=20
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint

--YiEDa0DAkWCtVeE4
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFD6WpbORgD1qCZ2KcRAhoYAJ4nAJviZmfx9dZEAguida+vRj22vQCfa40n
XNuQqSuItxX/vuU5ov0VkGc=
=we6p
-----END PGP SIGNATURE-----

--YiEDa0DAkWCtVeE4--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============0500362165==--




From speermint-bounces@ietf.org Wed Feb 08 01:48:09 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6j7Z-0003kC-AK; Wed, 08 Feb 2006 01:48:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6j7Y-0003hc-6q; Wed, 08 Feb 2006 01:48:08 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21076;
	Wed, 8 Feb 2006 01:46:17 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1F6jJu-0006x7-7G; Wed, 08 Feb 2006 02:00:56 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 8 Feb 2006 07:51:38 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4824@oefeg-s04.oefeg.loc>
Thread-Topic: [Enum] a suggestion re: using flags to distinguish
	post-ENUMsignaling f lows
Thread-Index: AcYsPQg6aaaJZPBaRGCTfKjW41t06QAPk35j
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Stafford, Matthew" <matthew.stafford@cingular.com>
X-Spam-Score: 0.8 (/)
X-Scan-Signature: f2984bf50fb52a9e56055f779793d783
Content-Transfer-Encoding: quoted-printable
Cc: enum@ietf.org, speermint@ietf.org
Subject: [Speermint] Re: [Enum] a suggestion re: using flags to distinguish
	post-ENUMsignaling f lows
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

>Also, I'm curious to see the reactions to=20

>=3D=3D> E2U+mms:mailto:mx ?=20
>=3D=3D> or mailto:a@example.com;mx=3Dyes/no ?=20

>=3D=3D> E2U+sip:srv=20
>=3D=3D> or sip:a@example.com;srv=3Dyes/no=20

>Appending ";mx=3Dyes/no" (or ";srv=3Dyes/no" in the SIP case) gives =
information that can just as easily live outside the ENUM >context. Not =
true of the Enumservice approach (or, for that matter, the ENUM NAPTR =
flag)- both of those are tied directly >to the ENUM record.

Exactly,

Peering with SIP URIs must work with or without ENUM, especially in User =
ENUM. The reason
is that the ENUM query may be done by the client and a SIP proxy may =
have no idea if
the SIP URI has been entered by the user direct or by derived from ENUM.

OTOH, since users now do not enter mailto:a@example.com;mx=3Dyes and it =
works, why should
they enter SIP:a@example.com;srv=3Dyes

The SRV s mandatory anyway

regards

Richard


________________________________

Von: Stafford, Matthew [mailto:matthew.stafford@cingular.com]
Gesendet: Mi 08.02.2006 00:16
An: Stastny Richard
Cc: enum@ietf.org; speermint@ietf.org
Betreff: RE: [Enum] a suggestion re: using flags to distinguish =
post-ENUMsignaling f lows



Richard-=20

Regarding=20
=3D=3D> I thought E2U+sip:pstn=20
=3D=3D> is pointing to a gw service already=20

I consulted draft-ietf-enum-pstn-03. As best I can tell from a brief =
reading, the E2U+pstn records are helping you to find a media gateway =
for PSTN interconnect. I'm looking specifically at 7.1(d) and 7.2(f) in =
the call processing scenarios.

Maybe "g" for gateway was a bad choice in my original message. Since "s" =
and "p" are already defined in non-ENUM contexts in the DDDS RFCs, I was =
looking for another term (other than server or proxy). Unless I read the =
PSTN draft incorrectly (or I'm looking at the wrong document =
altogether), I believe that it does *not* address the following =
question: I've done an ENUM query and extracted the URI from the ENUM =
NAPTR; how should I interpret the domain portion of the URI?=20

Also, I'm curious to see the reactions to=20

=3D=3D> E2U+mms:mailto:mx ?=20
=3D=3D> or mailto:a@example.com;mx=3Dyes/no ?=20

=3D=3D> E2U+sip:srv=20
=3D=3D> or sip:a@example.com;srv=3Dyes/no=20

Appending ";mx=3Dyes/no" (or ";srv=3Dyes/no" in the SIP case) gives =
information that can just as easily live outside the ENUM context. Not =
true of the Enumservice approach (or, for that matter, the ENUM NAPTR =
flag)- both of those are tied directly to the ENUM record.

A random thought: If one wanted to go with =
mailto:a@example.com;mx=3Dyes/no, where would the change to the mailto: =
URI scheme be documented?=20

Best,=20
Matt=20

-----Original Message-----=20
From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20
Sent: Tuesday, February 07, 2006 12:54 PM=20
To: Richard Shockey; Stafford, Matthew=20
Cc: enum@ietf.org; speermint@ietf.org; lconroy=20
Subject: Re: [Enum] a suggestion re: using flags to distinguish =
post-ENUMsignaling f lows=20

>Something like E2U+sip:pstngw=20
 =20
I thought E2U+sip:pstn=20
is pointing to a gw service already=20
 =20
>URI extentions or Enumservice definitions are the way to go=20

E2U+mms:mailto:mx ?=20
or mailto:a@example.com;mx=3Dyes/no ?=20

E2U+sip:srv=20
or sip:a@example.com;srv=3Dyes/no=20
 =20
Richard=20


________________________________=20

Von: enum-bounces@ietf.org im Auftrag von Richard Shockey=20
Gesendet: Di 07.02.2006 19:36=20
An: Stafford, Matthew=20
Cc: enum@ietf.org; speermint@ietf.org; lconroy=20
Betreff: Re: [Enum] a suggestion re: using flags to distinguish =
post-ENUMsignaling f lows=20





> =3D=3D> I take your point regarding the headaches w/changes to =
clients.=20
> =3D=3D> However, I'm not sure I agree that this is limited to =
carrier/infra-=20
> =3D=3D> ENUM, at least if we think of that in terms of traditional =
telcos/=20
> =3D=3D> cellcos. For example, does this discussion really bear no =
relevance=20
> =3D=3D> to enterprise applications (e.g., I want to call into my =
company's=20
> =3D=3D> IP PBX while I'm on the road?)=20
>=20
> It appears that the proposed 'g' flag is appropriate only for SIP use=20
> within Carrier ENUM, so one could WELL argue that this is an issue for =
the=20
> SIP URI - I don't see how it can be used for other Enumservices (like=20
> email:mailto, for example). Perhaps adding a SIP parameter (akin to =
;user=3Dphone)=20
> would be more appropriate, or adding a new Enumservice to run =
alongside the=20
> existing SIP one (i.e. to develop a new Enumservice definition RFC to =
specify=20
> a SIP Gateway service)?=20

That would be my strong recommendation.=20

Something like E2U+sip:pstngw=20


>=20
> =3D=3D> That would have a similar effect to the flag proposal, in the =
sense=20
> =3D=3D> that the contents of the ENUM NAPTR offer guidance on what to =
do next=20
> =3D=3D> (which is really what I'm after)=20
>=20
> =3D=3D> For the sake of discussion, here's a similar example using the =

> recently-=3D=3D> standardized Enumservice mms:mailto... an 'm' flag=20
> indicating that the =3D=3D> NAPTR recipient should now look for an MX=20
> Resource Record.=20

Lets not even start a discussion over using the flag field ..I do't=20
think that will go very far. IMHO a non starter.=20

URI extentions or Enumservice definitions are the way to go=20


>=20
> all the best,=20
>    Lawrence=20
>=20
>=20
--=20


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20
Richard Shockey, Director - Member of Technical Staff=20
NeuStar Inc.=20
46000 Center Oak Plaza  -   Sterling, VA  20166=20
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com=20
ENUM +87810-13313-31331=20
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683=20
Fax: +1 815.333.1237=20
<mailto:richard(at)shockey.us> or=20
<mailto:richard.shockey(at)neustar.biz>=20
<http://www.neustar.biz> ; <http://www.enum.org>=20
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<=20

_______________________________________________=20
enum mailing list=20
enum@ietf.org=20
https://www1.ietf.org/mailman/listinfo/enum=20


_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Wed Feb 08 10:44:06 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6rUE-0007n1-Sm; Wed, 08 Feb 2006 10:44:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F6rTl-0007jT-3l
	for speermint@megatron.ietf.org; Wed, 08 Feb 2006 10:44:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02339
	for <speermint@ietf.org>; Wed, 8 Feb 2006 10:41:44 -0500 (EST)
Message-Id: <200602081541.KAA02339@ietf.org>
Received: from mail.pulver.com ([192.246.69.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6rgC-0000nF-Bs
	for speermint@ietf.org; Wed, 08 Feb 2006 10:56:29 -0500
Received: (qmail 15409 invoked by uid 510); 8 Feb 2006 11:08:31 -0500
Received: from henry@pulver.com by mail.pulver.com by uid 508 with
	qmail-scanner-1.22-st-qms 
	(clamdscan: 0.72. spamassassin: 2.63.  Clear:RC:1(67.187.111.112):. 
	Processed in 1.814252 secs); 08 Feb 2006 16:08:31 -0000
X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com
X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(67.187.111.112):. Processed in
	1.814252 secs Process 15404)
Received: from c-67-187-111-112.hsd1.tx.comcast.net (HELO 1AB764895C324D3)
	(henry@pulver.com@67.187.111.112)
	by 192.246.69.184 with SMTP; Wed, 08 Feb 2006 16:08:29 +0000
From: "Henry Sinnreich" <henry@pulver.com>
To: "'Livingood, Jason'" <Jason_Livingood@cable.comcast.com>,
	"'Pfautz, Penn L, NEO'" <ppfautz@att.com>,
	"'Klaus Darilion'" <klaus.mailinglists@pernau.at>,
	"'Duane'" <duane@e164.org>
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a borken
	addressingsystem?
Date: Wed, 8 Feb 2006 09:43:08 -0600
Organization: pulver.com
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcYrwI7+uWvK8J5uRVuyJ8CBkI74WgAJ7DSQAAKZZWAACOn2kAAqf85A
In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7302A3A167@PACDCEXCMB01.cable.comcast.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Antivirus-MYDOMAIN-Message-ID: <113941490983515404@mail.pulver.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Cc: speermint@ietf.org, 'lconroy' <lconroy@insensate.co.uk>,
	'Tony Rutkowski' <trutkowski@verisign.com>
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: henry@pulver.com
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

He charter item is not satisfactory IMHO:

"While voice calls are the primary motivation for this today, other
forms of real-time communications are and will continue to evolve as
natural additions to such peering."

So even if the IM companies (and they carry most of the public VoIP traffic)
would like to interconnect, they would have to wait indefinitely for a
standard from this WG.

I suggest to plan 5 minutes for a hum during the meeting and don't mind if
the outcome will be still "VoIP only". We would have tried at least to make
the WG relevant to the larger IM+VoIP market.

Thanks, Henry

 

-----Original Message-----
From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] 
Sent: Tuesday, February 07, 2006 12:52 PM
To: henry@pulver.com; Pfautz, Penn L, NEO; Klaus Darilion; Duane
Cc: David Meyer; speermint@ietf.org; lconroy; Tony Rutkowski
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a borken
addressingsystem?


> Coming to the point: 
> What about peering for presence and IM? 

If you read the new speermint charter, I hope you will agree that this
is considered an in-scope item.  A real-time communications session is a
session, no matter the user part of the URI.  However, we tried to be
clear that the priority was first to fix this for VoIP, which is
presumed to be telephone-number-based.  After that, we'll advance to
non-TN-based real-time session peering.  The problems we'll need to
solve from a speermint perspective will largely be the same in either
case - service providers (domains) will all have the same anti-abuse and
trust concerns.  The only variances may be in the bandwidth required for
various types of sessions, but who knows.

>From the charter:
"While voice calls are the primary motivation for this today, other
forms of real-time communications are and will continue to evolve as
natural additions to such peering."

Jason




_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Wed Feb 08 10:52:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6rch-000155-Pa; Wed, 08 Feb 2006 10:52:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F6rcg-00014M-Ib
	for speermint@megatron.ietf.org; Wed, 08 Feb 2006 10:52:50 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03010
	for <speermint@ietf.org>; Wed, 8 Feb 2006 10:51:00 -0500 (EST)
Received: from mail121.messagelabs.com ([216.82.241.195])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F6rp8-00015t-5n
	for speermint@ietf.org; Wed, 08 Feb 2006 11:05:45 -0500
X-VirusChecked: Checked
X-Env-Sender: ppfautz@att.com
X-Msg-Ref: server-13.tower-121.messagelabs.com!1139413909!6483726!15
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 29688 invoked from network); 8 Feb 2006 15:52:28 -0000
Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4)
	by server-13.tower-121.messagelabs.com with SMTP;
	8 Feb 2006 15:52:28 -0000
Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by
	attrh2i.attrh.att.com (7.2.052)
	id 43CF03750030E866; Wed, 8 Feb 2006 10:52:26 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a borken
	addressingsystem?
Date: Wed, 8 Feb 2006 10:52:22 -0500
Message-ID: <34DA635B184A644DA4588E260EC0A25A0C1CE4D7@ACCLUST02EVS1.ugd.att.com>
Thread-Topic: [Enum] RE: [Speermint] and are phone numbers a borken
	addressingsystem?
Thread-Index: AcYrwI7+uWvK8J5uRVuyJ8CBkI74WgAJ7DSQAAKZZWAACOn2kAAqf85AAAHNxSA=
From: "Pfautz, Penn L, NEO" <ppfautz@att.com>
To: <henry@pulver.com>, "Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	"Klaus Darilion" <klaus.mailinglists@pernau.at>, "Duane" <duane@e164.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Content-Transfer-Encoding: quoted-printable
Cc: speermint@ietf.org, lconroy <lconroy@insensate.co.uk>,
	Tony Rutkowski <trutkowski@verisign.com>
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Henry:=20

By
So even if the IM companies (and they carry most of the public VoIP
traffic)
would like to interconnect, they would have to wait indefinitely for a
standard from this WG.

Do you refer to IM companies interconnecting for IM for VoIP?

Penn

-----Original Message-----
From: Henry Sinnreich [mailto:henry@pulver.com]=20
Sent: Wednesday, February 08, 2006 10:43 AM
To: 'Livingood, Jason'; Pfautz, Penn L, NEO; 'Klaus Darilion'; 'Duane'
Cc: 'David Meyer'; speermint@ietf.org; 'lconroy'; 'Tony Rutkowski'
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a borken
addressingsystem?

He charter item is not satisfactory IMHO:

"While voice calls are the primary motivation for this today, other
forms of real-time communications are and will continue to evolve as
natural additions to such peering."

So even if the IM companies (and they carry most of the public VoIP
traffic)
would like to interconnect, they would have to wait indefinitely for a
standard from this WG.

I suggest to plan 5 minutes for a hum during the meeting and don't mind
if
the outcome will be still "VoIP only". We would have tried at least to
make
the WG relevant to the larger IM+VoIP market.

Thanks, Henry

=20

-----Original Message-----
From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20
Sent: Tuesday, February 07, 2006 12:52 PM
To: henry@pulver.com; Pfautz, Penn L, NEO; Klaus Darilion; Duane
Cc: David Meyer; speermint@ietf.org; lconroy; Tony Rutkowski
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a borken
addressingsystem?


> Coming to the point:=20
> What about peering for presence and IM?=20

If you read the new speermint charter, I hope you will agree that this
is considered an in-scope item.  A real-time communications session is a
session, no matter the user part of the URI.  However, we tried to be
clear that the priority was first to fix this for VoIP, which is
presumed to be telephone-number-based.  After that, we'll advance to
non-TN-based real-time session peering.  The problems we'll need to
solve from a speermint perspective will largely be the same in either
case - service providers (domains) will all have the same anti-abuse and
trust concerns.  The only variances may be in the bandwidth required for
various types of sessions, but who knows.

>From the charter:
"While voice calls are the primary motivation for this today, other
forms of real-time communications are and will continue to evolve as
natural additions to such peering."

Jason




_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Wed Feb 08 11:35:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6sHm-000271-4h; Wed, 08 Feb 2006 11:35:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F6sHZ-00022J-Oj
	for speermint@megatron.ietf.org; Wed, 08 Feb 2006 11:35:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07435
	for <speermint@ietf.org>; Wed, 8 Feb 2006 11:33:02 -0500 (EST)
Message-Id: <200602081633.LAA07435@ietf.org>
Received: from mail.pulver.com ([192.246.69.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6sTr-000309-9s
	for speermint@ietf.org; Wed, 08 Feb 2006 11:47:48 -0500
Received: (qmail 25709 invoked by uid 510); 8 Feb 2006 11:59:59 -0500
Received: from henry@pulver.com by mail.pulver.com by uid 508 with
	qmail-scanner-1.22-st-qms 
	(clamdscan: 0.72. spamassassin: 2.63.  Clear:RC:1(67.187.111.112):. 
	Processed in 1.836462 secs); 08 Feb 2006 16:59:59 -0000
X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com
X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(67.187.111.112):. Processed in
	1.836462 secs Process 25704)
Received: from c-67-187-111-112.hsd1.wa.comcast.net (HELO 1AB764895C324D3)
	(henry@pulver.com@67.187.111.112)
	by 192.246.69.184 with SMTP; Wed, 08 Feb 2006 16:59:57 +0000
From: "Henry Sinnreich" <henry@pulver.com>
To: "'Pfautz, Penn L, NEO'" <ppfautz@att.com>,
	"'Livingood, Jason'" <Jason_Livingood@cable.comcast.com>,
	"'Klaus Darilion'" <klaus.mailinglists@pernau.at>,
	"'Duane'" <duane@e164.org>
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a borken
	addressingsystem?
Date: Wed, 8 Feb 2006 10:34:36 -0600
Organization: pulver.com
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcYrwI7+uWvK8J5uRVuyJ8CBkI74WgAJ7DSQAAKZZWAACOn2kAAqf85AAAHNxSAAATau0A==
In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0C1CE4D7@ACCLUST02EVS1.ugd.att.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Antivirus-MYDOMAIN-Message-ID: <113941799783525704@mail.pulver.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Content-Transfer-Encoding: 7bit
Cc: speermint@ietf.org, 'lconroy' <lconroy@insensate.co.uk>,
	'Tony Rutkowski' <trutkowski@verisign.com>
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: henry@pulver.com
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Penn,

>Do you refer to IM companies interconnecting for IM for VoIP?

Yes. This is an excellent question.

Users of IM and VoIP would NOT appreciate having to use VoIP from one
provider and IM+presence  from another. Nor would the IT administrator.
Such an assumption is pretty self defeating.

All IM companies provide this together and this may be part of the
explanation why they carry most of the public VoIP minutes. 

IMHO the SPEER WG must include SIMPLE peering to be relevant at all.

Thanks, Henry




 

-----Original Message-----
From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] 
Sent: Wednesday, February 08, 2006 9:52 AM
To: henry@pulver.com; Livingood, Jason; Klaus Darilion; Duane
Cc: David Meyer; speermint@ietf.org; lconroy; Tony Rutkowski
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a borken
addressingsystem?

Henry: 

By
So even if the IM companies (and they carry most of the public VoIP
traffic)
would like to interconnect, they would have to wait indefinitely for a
standard from this WG.

Do you refer to IM companies interconnecting for IM for VoIP?

Penn

-----Original Message-----
From: Henry Sinnreich [mailto:henry@pulver.com] 
Sent: Wednesday, February 08, 2006 10:43 AM
To: 'Livingood, Jason'; Pfautz, Penn L, NEO; 'Klaus Darilion'; 'Duane'
Cc: 'David Meyer'; speermint@ietf.org; 'lconroy'; 'Tony Rutkowski'
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a borken
addressingsystem?

He charter item is not satisfactory IMHO:

"While voice calls are the primary motivation for this today, other
forms of real-time communications are and will continue to evolve as
natural additions to such peering."

So even if the IM companies (and they carry most of the public VoIP
traffic)
would like to interconnect, they would have to wait indefinitely for a
standard from this WG.

I suggest to plan 5 minutes for a hum during the meeting and don't mind
if
the outcome will be still "VoIP only". We would have tried at least to
make
the WG relevant to the larger IM+VoIP market.

Thanks, Henry

 

-----Original Message-----
From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] 
Sent: Tuesday, February 07, 2006 12:52 PM
To: henry@pulver.com; Pfautz, Penn L, NEO; Klaus Darilion; Duane
Cc: David Meyer; speermint@ietf.org; lconroy; Tony Rutkowski
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a borken
addressingsystem?


> Coming to the point: 
> What about peering for presence and IM? 

If you read the new speermint charter, I hope you will agree that this
is considered an in-scope item.  A real-time communications session is a
session, no matter the user part of the URI.  However, we tried to be
clear that the priority was first to fix this for VoIP, which is
presumed to be telephone-number-based.  After that, we'll advance to
non-TN-based real-time session peering.  The problems we'll need to
solve from a speermint perspective will largely be the same in either
case - service providers (domains) will all have the same anti-abuse and
trust concerns.  The only variances may be in the bandwidth required for
various types of sessions, but who knows.

>From the charter:
"While voice calls are the primary motivation for this today, other
forms of real-time communications are and will continue to evolve as
natural additions to such peering."

Jason







_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Wed Feb 08 11:56:57 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6scj-0008Oj-SS; Wed, 08 Feb 2006 11:56:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F6scd-0008HW-JY
	for speermint@megatron.ietf.org; Wed, 08 Feb 2006 11:56:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09370
	for <speermint@ietf.org>; Wed, 8 Feb 2006 11:55:08 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F6spF-0003qH-GG
	for speermint@ietf.org; Wed, 08 Feb 2006 12:09:55 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Enum] RE: [Speermint] and are phone numbers a
	borkenaddressingsystem?
Date: Wed, 8 Feb 2006 17:56:35 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C482D@oefeg-s04.oefeg.loc>
Thread-Topic: [Enum] RE: [Speermint] and are phone numbers a
	borkenaddressingsystem?
Thread-Index: AcYrwI7+uWvK8J5uRVuyJ8CBkI74WgAJ7DSQAAKZZWAACOn2kAAqf85AAAHNxSAAATau0AABECRr
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: <henry@pulver.com>, "Pfautz, Penn L, NEO" <ppfautz@att.com>,
	"Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	"Klaus Darilion" <klaus.mailinglists@pernau.at>, "Duane" <duane@e164.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8
Content-Transfer-Encoding: quoted-printable
Cc: speermint@ietf.org, lconroy <lconroy@insensate.co.uk>,
	Tony Rutkowski <trutkowski@verisign.com>
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Henry
=20
>IMHO the SPEER WG must include SIMPLE peering to be relevant at all.

Maybe it is your English or mine: IMHO

"While voice calls are the primary motivation for this today, other
forms of real-time communications are and will continue to evolve as
natural additions to such peering."

does include IM which is another form, and also a I can remember
the name of the WG was changed from VOIPEER to include other form of
communications.
=20
Richard


________________________________

Von: speermint-bounces@ietf.org im Auftrag von Henry Sinnreich
Gesendet: Mi 08.02.2006 17:34
An: 'Pfautz, Penn L, NEO'; 'Livingood, Jason'; 'Klaus Darilion'; 'Duane'
Cc: speermint@ietf.org; 'lconroy'; 'Tony Rutkowski'
Betreff: RE: [Enum] RE: [Speermint] and are phone numbers a =
borkenaddressingsystem?



Penn,

>Do you refer to IM companies interconnecting for IM for VoIP?

Yes. This is an excellent question.

Users of IM and VoIP would NOT appreciate having to use VoIP from one
provider and IM+presence  from another. Nor would the IT administrator.
Such an assumption is pretty self defeating.

All IM companies provide this together and this may be part of the
explanation why they carry most of the public VoIP minutes.

IMHO the SPEER WG must include SIMPLE peering to be relevant at all.

Thanks, Henry






-----Original Message-----
From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com]
Sent: Wednesday, February 08, 2006 9:52 AM
To: henry@pulver.com; Livingood, Jason; Klaus Darilion; Duane
Cc: David Meyer; speermint@ietf.org; lconroy; Tony Rutkowski
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a borken
addressingsystem?

Henry:

By
So even if the IM companies (and they carry most of the public VoIP
traffic)
would like to interconnect, they would have to wait indefinitely for a
standard from this WG.

Do you refer to IM companies interconnecting for IM for VoIP?

Penn

-----Original Message-----
From: Henry Sinnreich [mailto:henry@pulver.com]
Sent: Wednesday, February 08, 2006 10:43 AM
To: 'Livingood, Jason'; Pfautz, Penn L, NEO; 'Klaus Darilion'; 'Duane'
Cc: 'David Meyer'; speermint@ietf.org; 'lconroy'; 'Tony Rutkowski'
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a borken
addressingsystem?

He charter item is not satisfactory IMHO:

"While voice calls are the primary motivation for this today, other
forms of real-time communications are and will continue to evolve as
natural additions to such peering."

So even if the IM companies (and they carry most of the public VoIP
traffic)
would like to interconnect, they would have to wait indefinitely for a
standard from this WG.

I suggest to plan 5 minutes for a hum during the meeting and don't mind
if
the outcome will be still "VoIP only". We would have tried at least to
make
the WG relevant to the larger IM+VoIP market.

Thanks, Henry



-----Original Message-----
From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
Sent: Tuesday, February 07, 2006 12:52 PM
To: henry@pulver.com; Pfautz, Penn L, NEO; Klaus Darilion; Duane
Cc: David Meyer; speermint@ietf.org; lconroy; Tony Rutkowski
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a borken
addressingsystem?


> Coming to the point:
> What about peering for presence and IM?

If you read the new speermint charter, I hope you will agree that this
is considered an in-scope item.  A real-time communications session is a
session, no matter the user part of the URI.  However, we tried to be
clear that the priority was first to fix this for VoIP, which is
presumed to be telephone-number-based.  After that, we'll advance to
non-TN-based real-time session peering.  The problems we'll need to
solve from a speermint perspective will largely be the same in either
case - service providers (domains) will all have the same anti-abuse and
trust concerns.  The only variances may be in the bandwidth required for
various types of sessions, but who knows.

>From the charter:
"While voice calls are the primary motivation for this today, other
forms of real-time communications are and will continue to evolve as
natural additions to such peering."

Jason







_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Wed Feb 08 13:31:14 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6u5y-0007NX-Co; Wed, 08 Feb 2006 13:31:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F6u5o-00073S-3f
	for speermint@megatron.ietf.org; Wed, 08 Feb 2006 13:31:12 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19243
	for <speermint@ietf.org>; Wed, 8 Feb 2006 13:29:09 -0500 (EST)
Message-Id: <200602081829.NAA19243@ietf.org>
Received: from mail.pulver.com ([192.246.69.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6uIE-00083y-KD
	for speermint@ietf.org; Wed, 08 Feb 2006 13:43:55 -0500
Received: (qmail 13885 invoked by uid 510); 8 Feb 2006 13:56:05 -0500
Received: from henry@pulver.com by mail.pulver.com by uid 508 with
	qmail-scanner-1.22-st-qms 
	(clamdscan: 0.72. spamassassin: 2.63.  Clear:RC:1(67.187.111.112):. 
	Processed in 1.896305 secs); 08 Feb 2006 18:56:05 -0000
X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com
X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(67.187.111.112):. Processed in
	1.896305 secs Process 13880)
Received: from c-67-187-111-112.hsd1.tx.comcast.net (HELO 1AB764895C324D3)
	(henry@pulver.com@67.187.111.112)
	by 192.246.69.184 with SMTP; Wed, 08 Feb 2006 18:56:03 +0000
From: "Henry Sinnreich" <henry@pulver.com>
To: "'Stastny Richard'" <Richard.Stastny@oefeg.at>,
	"'Pfautz, Penn L, NEO'" <ppfautz@att.com>,
	"'Livingood, Jason'" <Jason_Livingood@cable.comcast.com>,
	"'Klaus Darilion'" <klaus.mailinglists@pernau.at>,
	"'Duane'" <duane@e164.org>
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a
	borkenaddressingsystem?
Date: Wed, 8 Feb 2006 12:30:41 -0600
Organization: pulver.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0067_01C62CAB.79C34D30"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcYrwI7+uWvK8J5uRVuyJ8CBkI74WgAJ7DSQAAKZZWAACOn2kAAqf85AAAHNxSAAATau0AABECRrAAMimxA=
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C482D@oefeg-s04.oefeg.loc>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-MS-TNEF-Correlator: 00000000404E398781C19440A31736EC102FE610E47C5F00
X-Antivirus-MYDOMAIN-Message-ID: <113942496383513880@mail.pulver.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d
Cc: speermint@ietf.org, 'lconroy' <lconroy@insensate.co.uk>,
	'Tony Rutkowski' <trutkowski@verisign.com>
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: henry@pulver.com
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0067_01C62CAB.79C34D30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Richard,

If evrything is OK, why not mention SIMPLE for IM and Presence peering in
the WG charter?

If there is a problem mentioning and using SIMPLE, could we be informed what
it is?

Thanks, Henry
  

  _____  

From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] 
Sent: Wednesday, February 08, 2006 10:57 AM
To: henry@pulver.com; Pfautz, Penn L, NEO; Livingood, Jason; Klaus Darilion;
Duane
Cc: speermint@ietf.org; lconroy; Tony Rutkowski
Subject: Re: [Enum] RE: [Speermint] and are phone numbers a
borkenaddressingsystem?

 

Henry

 

>IMHO the SPEER WG must include SIMPLE peering to be relevant at all.

Maybe it is your English or mine: IMHO

"While voice calls are the primary motivation for this today, other
forms of real-time communications are and will continue to evolve as
natural additions to such peering."

does include IM which is another form, and also a I can remember
the name of the WG was changed from VOIPEER to include other form of
communications.

 

Richard

 

  _____  

Von: speermint-bounces@ietf.org im Auftrag von Henry Sinnreich
Gesendet: Mi 08.02.2006 17:34
An: 'Pfautz, Penn L, NEO'; 'Livingood, Jason'; 'Klaus Darilion'; 'Duane'
Cc: speermint@ietf.org; 'lconroy'; 'Tony Rutkowski'
Betreff: RE: [Enum] RE: [Speermint] and are phone numbers a
borkenaddressingsystem?

Penn,

>Do you refer to IM companies interconnecting for IM for VoIP?

Yes. This is an excellent question.

Users of IM and VoIP would NOT appreciate having to use VoIP from one
provider and IM+presence  from another. Nor would the IT administrator.
Such an assumption is pretty self defeating.

All IM companies provide this together and this may be part of the
explanation why they carry most of the public VoIP minutes.

IMHO the SPEER WG must include SIMPLE peering to be relevant at all.

Thanks, Henry






-----Original Message-----
From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com]
Sent: Wednesday, February 08, 2006 9:52 AM
To: henry@pulver.com; Livingood, Jason; Klaus Darilion; Duane
Cc: David Meyer; speermint@ietf.org; lconroy; Tony Rutkowski
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a borken
addressingsystem?

Henry:

By
So even if the IM companies (and they carry most of the public VoIP
traffic)
would like to interconnect, they would have to wait indefinitely for a
standard from this WG.

Do you refer to IM companies interconnecting for IM for VoIP?

Penn

-----Original Message-----
From: Henry Sinnreich [mailto:henry@pulver.com]
Sent: Wednesday, February 08, 2006 10:43 AM
To: 'Livingood, Jason'; Pfautz, Penn L, NEO; 'Klaus Darilion'; 'Duane'
Cc: 'David Meyer'; speermint@ietf.org; 'lconroy'; 'Tony Rutkowski'
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a borken
addressingsystem?

He charter item is not satisfactory IMHO:

"While voice calls are the primary motivation for this today, other
forms of real-time communications are and will continue to evolve as
natural additions to such peering."

So even if the IM companies (and they carry most of the public VoIP
traffic)
would like to interconnect, they would have to wait indefinitely for a
standard from this WG.

I suggest to plan 5 minutes for a hum during the meeting and don't mind
if
the outcome will be still "VoIP only". We would have tried at least to
make
the WG relevant to the larger IM+VoIP market.

Thanks, Henry



-----Original Message-----
From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
Sent: Tuesday, February 07, 2006 12:52 PM
To: henry@pulver.com; Pfautz, Penn L, NEO; Klaus Darilion; Duane
Cc: David Meyer; speermint@ietf.org; lconroy; Tony Rutkowski
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a borken
addressingsystem?


> Coming to the point:
> What about peering for presence and IM?

If you read the new speermint charter, I hope you will agree that this
is considered an in-scope item.  A real-time communications session is a
session, no matter the user part of the URI.  However, we tried to be
clear that the priority was first to fix this for VoIP, which is
presumed to be telephone-number-based.  After that, we'll advance to
non-TN-based real-time session peering.  The problems we'll need to
solve from a speermint perspective will largely be the same in either
case - service providers (domains) will all have the same anti-abuse and
trust concerns.  The only variances may be in the bandwidth required for
various types of sessions, but who knows.

>From the charter:
"While voice calls are the primary motivation for this today, other
forms of real-time communications are and will continue to evolve as
natural additions to such peering."

Jason







_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint


------=_NextPart_000_0067_01C62CAB.79C34D30
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Disposition: attachment;
	filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IikSAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgBcIwAAJAAAAAsAAgABAAAAAwAmAAAAAAALACsAAAAAAAMA
LgAAAAAAHgBwAAEAAABHAAAAW0VudW1dIFJFOiBbU3BlZXJtaW50XSBhbmQgYXJlIHBob25lIG51
bWJlcnMgYSBib3JrZW5hZGRyZXNzaW5nc3lzdGVtPwAAAgFxAAEAAAA+AAAAAcYrwI7+uWvK8J5u
RVuyJ8CBkI74WgAJ7DSQAAKZZWAACOn2kAAqf85AAAHNxSAAATau0AABECRrAAMimxAAAAsAAQ4A
AAAAAgEKDgEAAAAYAAAAAAAAAEBOOYeBwZRAoxc27BAv5hDCgAAAAwAUDgEAAAAeACgOAQAAACoA
AAAwMDAwMDAwOAFoZW5yeUBwdWx2ZXIuY29tAW1haWwucHVsdmVyLmNvbQAAAB4AKQ4BAAAAKgAA
ADAwMDAwMDA4AWhlbnJ5QHB1bHZlci5jb20BbWFpbC5wdWx2ZXIuY29tAAAAAwDeP59OAAADAAJZ
AAAWAAMACVkCAAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAASACCAGAAAAAADA
AAAAAAAARgAAAAAQhQAAAAAAAAsAHIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwAdgAgg
BgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAABAAB+ACCAGAAAAAADAAAAAAAAARgAAAABghQAAAHCa
SjIAAAALACaACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAKoAIIAYAAAAAAMAAAAAAAABG
AAAAABiFAAAAAAAACwBEgAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAAAAAALAB8OAQAAAAIB+A8B
AAAAEAAAAEBOOYeBwZRAoxc27BAv5hACAfoPAQAAABAAAABATjmHgcGUQKMXNuwQL+YQAwD+DwUA
AAACAQkQAQAAAIEfAAB9HwAAIH0AAExaRnUA+S/DAwAKAHJjcGcxMjWCMgNDaHRtbDEDMP8BAwH3
CoACpAPkBxMCgBAD/wBQBFYIVQeyETUOUQMBAgCEY2gKwHNldDIGANsGwxE1MwRGE8cwEj8CAK40
A8UV2RDqNRe/IAdtxRE1NgPGVGFoA3ECgLcRQwjvCfc7Hg8OMDUfL3plDiA4IH8fARFBDGBjZwBQ
CwkBZDM2FmALpTRyIBACKlwOsgGQDhA5ZCA8DrIgeA7QAIA6SHY9IghwbjoE8GhiZQDAcy1tDeAD
YHNqbwGALQWgbScQDtAiXSa1byc/KEkocGYN4GV7K2UpJncpvyrPLLAFsGQHKSUs0A6wdHA6Ly9C
dzBALnczLgWwZwAvVFIvUkVDLeEOsjQwIj4RQyWnFFBnCqMx7zL/ZzMlQCZgZXxhZDHdDvE0TzbP
JeQ2jQ7wPAeAAZAgbmEHgMw9RwnwBJBhdAWxBaArAjAJ8HQs0E0oJiBX6S8RIDEO8CgrkCXwBJAF
CYAgB4BkaXVtKRcxzjgvM9M0OZEhLS0iWwaQICFtKGBdPoEKozxzdHlsZUEkIHZcXDoqAzB7YlJl
E/B2aQWwOghwbCQoIwEBYXUl8CNWqE1MKSHAfQqjb0JfO0NvRHV3RP9GD0R1LnO5E/BwZUffSO9B
Ui9Bmc1AUFsJ8D1wZl1AcD3fEz7vJhE3NyZQdGl0B0HBPz8H8EU6IFtF6m49kF1SVFNKYASQKBC/
AjBS8ABwPGAKwEpwcBzQ/zqAOgA9kEqwFBBUAAqjBuDscmsJ8DXAZCHgBBALgFhnc3lBkC1gP05t
OP41TMFQ708fP6pBlFo/WdRTQFIKoyAvR8BGAiEgPkQBEAuAWJBLAAYxKi/1XXRAAhItS7ArsAqk
AZHHSoFfpSgQbHk6HLVgOIUKsG4oUGUtMToUUMk8gTYgJUAzIFhAJUDbJUAUUDREZl3CU0GiXk/R
XZJwLk0oYE4FsADAYGwsIGxpZwo9cHafZwhgOgDAMMALgDowC4A7YhlqNC0G4AJAKMEuML1scDEF
MGIZX6MAkHorwK8OIGxgbL9hNiIHbSJEZqRhOmfAbmtnoHNiwflnAkh5SmBLUHGxYDodg+46CjJi
GTsweCiQBYM6sP9ewUswTeBys3RhcSZK8ACQXTswZHHvccBeAGwdoHffCYBzH3QvdT92TXBpeyhg
JygAa5Q6wHAtB0B0OtdLwDrAat8tBRBnDrBqnv9+eGv0f09rWEHAAYBqnW2P726fb69wu3fjRQDA
AxBlU99YIH2uQZN/AHKROnKhKGDVOhBsgOBlC1B5hy9hVG8Q5GA4ejQ6EHaNsUSEQO0KsGdKcAZg
Y16yI2NgdvGGczguNQuAPHFsYGq/92pxk7M8cC4OMJVTlUhEZu9oopG/SoGRYjqXdkRmTjH/We8/
8iZBTOVY75pPnP8l471AIi81rzP/oM8lmDUWYDI8BuBkeWewAHBnPbBFTi1VBfBxoj0KMn9CMKUH
oDAlswAhAzCkUjH8MDNj4KZmFmAlaySxoq/rqP8l4zljoDxooTrwC2D9BBA9l3amSQAAp6+qD66v
f6rfaKGtD64fsH+0LyWnNp01cXCyT7NfDhA0OCZQtwISd9CGgT0UUB2DPZCSe4YQYAE9BxO3awvi
AzBj3xNQAzElQLgvJdQ4NXF34vN30EGiPSeGKZOxhwFg+rcKoxDkkDgnt2+981IN4O8T8XewW901
cW+M0KA+DkD/TMHGT6uQx4J34qZJple4rvo1q7EvAhLJf8qDpmYKov/KKAqBpncKsc8Is40BwEzB
/8Zutc/Sn7afw4+4v7nPut//u++8/9bvvx/AL8E/wk/V3wXcYklAsGV2cnl0imhWoSAEACBPS2eg
/HdopDBi4AVAB4ACMF7BwQYASU1QTEWGEQXAv+VQVAKe3NQ1pmfb+VBWYf8J8CuwVIBTgeOTA6Dj
cEpw3FdHOvAT8TzxP8Uvxj//x0/IX8lv3E/Lj++/za/Ov//Pz9Df0e/UT/iv1R/WL9c//9hP2V/a
b9t/3I/dn96v379/4M/77+Lj6iFUYePROfBwvw6AHeAtYOS245JUEnVWkv/lNWege/BD4DxgeUDm
X+dv/wIlSrDp4eWxPVHkMTqw48D9ECFz6w/sH+0v7j/vTwIv//FvFT/zj/Sf9a/2v/fP+i//Hi/6
/wfv/R/+L/8/AE8BX38CbwN/BI8FnwavIW+zcVTr6qBxwHNnoEhWEONQnYz7OXCj4XKmS3aBG38M
/iguKCZuYnfgO6ZZJ2H+MDG4s5wUbxV/Fo8Xnzjf/yM/JEIlPyZKJ18obyl/Kob/eXOOfy0fQE8R
XxJvE383j/87bzmvOr8YzxnfGu9Lzx0P1x9vU4+dmzBHQS+yHEtf/1TvWL+w77H/V/9aX14PWy+P
q9lnFwrwZ8Bnbj3pQN8j4IzwQfZ7g2LDOmMkROx8cWM/+SBLXI9dnzz9M59DhD4SiJ8+rj/hZjU/
//9BD0IfhtNE724PMw8NH1ePv3VPZpxSsA3nT5pgf2iKAXEkJHdpZONwa0CnQDBcJSJivIuRlcBk
ZBA9Oi2s/GaX4GXwZeBqXOMMQYuxfiBff8J/gTFD/09TUS9ff4G/oX8jgkpVhE//TRZV31bvgQ+D
b4pfIB8hIO9hvnFPid9vI2KO65hxj7/jaW89uFRhaGwRPq8/se9M8JJfbt9CLjBDP0RDlSTvKvQM
gGRwDgA6pAAMUHE/5ZckRgngbTpJT0pflu//TH+gH6Evn3ORWqOPk18kFH9quJUvlj+mj5hfmW6a
v2HbnO82JVOMEKzwbiUQxKW3c/8Nv6slW2KARFB0SPAFxKUusRVAb2VmZfRnLhAQXaa9MD8xT7IP
f4yPkR+SL6vfrOucP6//U3/k0Z6fn6+mH6Sfw+/oIFdDD8C40HNkYXnkIEaaZbfQdVEAJRAwOOQg
eSbAMDa5v7MfxJV8ADr0NTcsAE22v7fPuN/Jn/+6/7wPzt++L78/wE8t6Ujw38UPw1/S38V/2Z8g
CTAvIVRAcAxAdumQLgwgbUY76NBEIHV0euQgUF3pIG7Pf8p/2jVM5CBONEVP3kBMXFDjkW9vumTk
IEph4OUQ3kBLYdB5C0AgRFEARFAKkd5ARP/IkM6SzJ/Nr86/z8/Q39Hvn+cv1A/VH9Yv6yZDY9ff
v9jv2f/bD/G/s9A00GUJQKNEQCPgQGllTzAuLKCaZ95AbAwgLyBved5AX9ewsWDnr+A/8mVS3pBr
4G93c2tp5K/lv+bP//e/6O/p//0P7B/tL+4/wVngdWJqZWPCL/EP8h838y8H/zZhUkLwtIBFbuR1
bbaQUkUGXPhfs+ouU/WGtpCswGRisHJlrCBwr1D8wCAMIWL1oElroGEgBDBya97wYZxkZBBAYfDi
YXN5rPD4ZW0/CS8HfwiPod8UX/8Vb0cvSD9O30/vUP9SD1Mf//6fIH+H3xc/if8h/yXPjS//jj+P
T6bfaglq/2wPbR8rD38Cf5lnarNw3yqPGM/+7yYUbmIxkDv7+SdhMP80fxpfEu8T/zjPFh88X06f
fxw/HU8eXx9vJy9FT2CvIEV7oD17oE9XQQvAcKWvAFRkETc3mfAzM7//Qz9G70wPW39KP0tPTa9R
X78oHykvT78rT5QL3hBs9mDkPWJh0GNrLR8uL6pG3GNmLQAvrzC/bmqzMe+/mfVYwwQgWTIzr1zU
SN1S/zrvO/9cnz4fZD9lTzXvOd//QH9Bj0KfQ69Ev1MPcF8i3/9nH1Cfcd91r06PYU9073dP/3r/
U99U73lfVw8sf1nvLp//XF9dbzHPMt9/P4WPN384j/9oj2mfOk9jP3PPgD9mbz+f/2t/bI9tn26v
e697b5rfcu//lI+bT5xfoC94P4k/oL+gf/+lf32Pfp+j34C/WE9ZX4Mv/1t/hP9dn16vX79gz7Bv
iqgWZ7QADeg+tahJTUgYTyB03UDB4FBFReJSx5BHIG3jgIGw/LAZqGB1ZLlBuNBQTEW/DK8Nv7XV
9YLiYbkQbxFgtxBQEECHMHaG0IGwYb8B+GxsLpAPkR+1r5M/wQ//wh+N747/lZ+Wr5e/mM+Z3/+m
380vnQ/D76Rvzq/Sf89//9CP0Z/T/9fPp4u079bvq3/5rI89QePQqT2viv5x28//hi+y37PislPj
s61Q9cBJcA4630O0H9s/IE1heY2+YWm6Ia3weW91soDFDBBn/KBzaCD2YLng//yxC+C40sUvxj+P
P7/fwO//4Y/DD+9fyB/JL8o/y0/MX//Zf/hPom/nP9cv+e/9n6e//6jP+//cj92f3q/fv+DP4d9/
4u+HurPE5R/mLwHfCH8mKHF1b7dqIg5YV2jjDDC6oHZvaa1wAJC/Ue+t8PVguqC5InC94AFgYq27
u/8H2W0QIEiQvyBpBCBf5QGygLkg6OG+MGToYCwv6dC5IfVx1Jox8VFicn0GOVzpkOow9Y8UDhbx
bd2t8G+MEL6QAXAtFmCt0PUEwW258G4SIBaTEqQJsOhkIHcMMGwEwYGg6iBedRLhvkC+wAzgdh7R
c88YTxlfGm8bf31uvyDpMDsBcL9AZEiAHlS+MXN1/mPpwL21v4wPzxDbIN8h738i/yQP1G0q3yvv
LP8uAmT+b63huka40B8gEbAmkejh9wmwF/MW4m0X0B7yAXABEL+/QLjAElEJwL6QrdBt6ID/GD8v
TzBfMW//ULkiJSAdkbcc8bkiucF3AMAAkGgJsCRnZR8QZnKuYCBW/E9JuXO+MbpGNEgc4Taf9zev
OL85z30dzL+M64/sn//tr+6/QY/w30jP8v/0D/Uf//Yv9z/+31G/1K/Vv0+PUz//Vw/6X/tvVk9Y
r1xf/68Av/9avwLfA+8E/wYPBx9hrwk//wpPC18Mbw1/Zy+K34vvxQ//RV9Gb0d/SI9wb0qvdW9M
z/9N307vT/9RD14Pfl9UP3gP/3wvf9+Dr1mPbL+C74VPiP//Xt9f74dfYg9jH2QvZT9mT3+OT2hv
aX9qj2ufjS+Tw1L7M7F7kGRw73H/cw90H3Uv/5O/d0+fn3lven97j3yffa//iq+oj4Dfoj+IP6oP
rd+GL/+ZX60fr3+zL4t/jI+xj46vZ4+3kxCRIyJUHYE0AE7cZXeacB3QlUAikc4UgbxmNZNvlH+V
j5aTMuRy/5kfvX+br25fb2/B/50Pnh//ny/GT6FPyd+jb6R/pY+mnz+nr7Sv0s+wPLY+NTFpZ3xu
PZFAl2A0cb8116B4m5dw1xM613TA/HFjvSn/tTvBH9CfuW7kxLqPu5+8r/+9v77PlhXAn9x/LU/n
DxTav80fyhzQ+xT3zorUz2jXwTuQBB8wZBMA35CW0DAlZiLXDNQQYkkfANhgPTQtMZHMMdox2jBq
XBB1bGRi4gB+IF//9BLz0UETzkPQH9PP9g+07v/DMI9xyUX4n8wGqn+rj/Vff/e//q+1D7YfH2Dk
FRNxZ9ky4C1iKHAXgG3lH+Yv/eL7YpHL88EF392/kBORI/hUYWjgYZHPkyHL4Ah/f+MsALPkH5bf
l+ALRJc0d95l1zAVEJiwmHBkBP8NRPpWj7A6yD/JTw0Py28WH/8XLxVzB3oZjwl+DvQKnwuv/wy/
Dc/j7xAvETkS/yE/6P/3xbAg6SKgZTZwl7CXYQQgQ0OwkUBzQGllziAuDbbgZzLQPQBBdWZ0knLD
ECB2j7AgSNeA8HJ5IFMy4CxQElAzwP8/L0A/QU8nP8PPB28vjyIP9+Q4Ek8l/0cqgCxAPiA2kB8a
PxW/M48arzqvIE1puCAwOCQgBKCSsDAYUOAxNzozNC0vLj8vT/8wXzFvMn9B7zSfNa82v0XofkEU
jznvOv88D0yPPiEnAlCRIHV0eiwgUAssQCLQTFDATkVPJ847Qo8oH01FJ0yw8EGQ0Gdvb2RQwEq2
YCwAq1GQUEBLtlB13/BEz/All8BpVTREdSLAZSf/P49An0GvUe9Dz0TfWX9G/+dID0kfXXhDY0rv
S/9ND79OH2QvKNAplyqnVWFskGC5LMBveVGfUq9TuFQsAAUscFJQkGtvd3Nr/mlXD1gfWS9p71tP
XF9db29ef1+PYJ8mWUIqwCzQZn5mYn9jj2SfZa96vyjQUgBFOiBbRW51bZ5dfmJwX2rfe2VbUymm
m38AIsBk1wAs0CBwJVA1b3AgftFi17Df8GEgiQQgcmssQGFkZCzQE7ZwVIFzeSLwZW0//3vfei97
Pxffhw+IH8M/xy//zc/O38/v0P/SD3FPky/8L/+J7/5PlK+Yf7A/d2+Xv5of/53PAYmbv5zPCd/f
T+BfIEd/4f90ryL/JAR3L6cUUOIs/21fbm9vf3+PlQ2s763/rw9bsB/EomckUMU4PrK4ROhvIHkq
QCB4wfFSt0D8SU0CMARghsEqsKSwKfHn17BpQbJwY3RUgR7QKwDnuCK6AhRgSVCFjLEvsj+/s0+0
X7vPvN+97770WSqA4C4gVGhpuOGD4aiwm9hgHwBsdeAKUXF1KoD7ubAsAC6/X8BvwX/Cj79Pb8bf
x+/I/5+QVTiAg9Fv/yjAuDGCorqy79AqQPOgpMAkT1TXAHBwgvBjaeJh16AgaGFUcrfyVcD7gwDP
c2ZpcCtQg0HKL8s/68xPzV990IBvVHDx0J4we4KiuDAr0IE4gR8AtK9uhmKogLXZXCdhMD2p99JD
qKAEMGjxUMPQAtHPtffcAbgg0EFkKeHEECuhBFAf3DDSz9Pf1O/V/31Tdf8tAMRiAmF+4CRAVkHE
MtCB9wRAbJA4gGwowPHQt8DQ0P9Ugd5P31/gb+F/yg/mX+dv++h/njFBxOC4LNcV3PHEEf0EUGcq
wNwRgpPvk6UwbJD/g7CDEJBACmDO0dwB6b/qz+vr3+zvfcSgcAJQhHDjg9x3aGyQ3AFskGOQQCxh
nG1vqNDxtYMQdWL0IP5jz2Qp4VCQw7HyL/M/9E9/9V/pr/sv/D/9T5+QuDBIAk/c81NQRUVSIDxX
R/DwVcAKYACAY2yKde9hU7gwUExFgxDfKbHRRfFBgvB14HaooApg/9DQg/DE4Pof/38AjwGf/l8/
B/8JDwofnjHD8Kiga3P/UMAsMwtfDG8Nfw6PC08Rf/8SjxOfFK8VvxbPF98Y7xn//xsPHB8dLx4/
H08gXyFvIn9/I48knyWvJr8nzyjfKeUt9S6iT1YQZyxgBsA+QITBfYvQZS6jKl8rbyx/LY99/kbS
UX6QUG9RcH6gp3+EAH5oeMGkUKUwViDeEIxQcOU1A0DQ0HQuuGGlbbjAO3cAi0JmdwAyUKjQe0gC
WQNgUkxJTksg8zfPONV9faYhdwCD0Iuw4FxjZjFcz+CmyTvfvzjjlp+c4UB/e6+NgmGMcP5dME8x
XzJvM3/ikMUBfpDIV2VkRnBzZPEQUMCcRmVFcFbA9/EwOFDAJaZgMIlAOTqNcUFN/0RfRW9Gf0eP
D5CMQNEAEDLyQPjgbHbcIbhhVWBUXv9VYFWcVWBWs0tPTF9Nb05/3n1iUVJh10EvcXm30GkA/2fv
aPFpNWkAbGxTb1R/VY/zVp/ikWJquZF+kH58gd+/gu+D91t/XI9dn16vfYSP/2PvZP9mD2cfKk9q
T2tfbG//n5AQI3kMbm9vf3CPbU9zD/d0H3UvdjRCEG93n3iveb9/4oG4EAYwxQAEIPiEuDsof/B0
95/4rXsPfB99L34/feXd4WY6EGMpg4+En4Wv/Ya/fc/EilBjsLfyuQo1UO+BY8/E0RGNM3c/IAQS
5MHb3aG5IGzxILoCYYhfiW/7in+Lj32o0GIBdlBiINJD/++TA7AG/5IPkx+UL3Z/l6//mL+Zz5rR
tz+4T7lfum+bf/+cj52fml+jj6Sfpa+mujVy/6d/qI+pn6qvp2+tD64fry//Lo8vn7C/sc+y3zPf
EBQEoPu1MBBAZfkg4tA2PzdOT97/OT86Tztdvg89Tz5fwf9Ab/9Bf7jfQ5+2n7evyF9H30jvwUn8
MTA6NDNLH8sv18w/zU9PVidQ/idS8DT/WzYAUvAnUhzW4SdTEyf/0U/SX9Nv1H9Xo9mAWAjW4ftY
z1nRJ1oF2VJanNnv2v//3A/dH1+vYL9hz2Lf4m/jf//kj+WfaC+jH+vf7O/t/7A///Ev8j/zT3Gz
oHAPsPYwn/HnkFGWEJZRbm+CQLWwodD+c9cgocBZsIGQAsJyP/WP//af96/0b/xf/W/+f/+OvNGo
JnF1+hA7AQgiAhjKV5ZAbOlQdm+DEPjh/bVQbOox6UGCk1KQPxCB4/2h0Hb6UdkwohOWM6Agz1N7
+hCAEHL/vwDPAd8C7329oiFtgPCCYelAtVAtodDmbfjhgIBtdaDQgbAJMnsHtOjyd1KgtWBaEaHR
dduNM3+Ab1BR6OBzCt8L78sM/w4PfbVAdHWH4LVgz+8hj7AQ86Ahc3W7wd+C/1EhlqwE3wXrE28U
fxWPFp///68djx6fH69/P4BPgV+Cb/+DfyHfIu8j/4e/Kc8q3yvv/4v/jQ+OH48vkD8uby9/MI//
lH+Vj5afN8843znvIK89b9c+fz+PQJJJGPFntdAoAe2gIXBSICWANSfQElGhQM8mwDaDT8DnsCBk
F+Ch4t8l0hAgWXCh4ujyZNkxKBC9WRFkQN9B70L/RA99JaB/SZ9Kr0u/TM8tkCXhn5B0/6CB6VAR
w+oA32Ch0BHhGd/vGu9QdykSKCBuNlBT/1UP/VB3Ls7hNHsIYM8A6OAoEPsG4NagdFEPQJJPZ8RJ
oCDvTg9PH1AvW/99CIDqoF5//1+PYJ9hr1JDPFCfsQbgCRB/zrCgEiXS2IDgcJ/xJhAr91ajCIHq
oHQ8f2QPZR9mLz9Av2sfbC9tP9Vi+RBua/5z0FC6825/b49wn3Gvbm//dJ91r3a/d89433nvev98
D/99H34vfz+0b7V/gM+B34Lvv7m/usHV7rvvvP/Wk1/V5/ZAB3AowGW+wgdwwMC+z/+/38Dvji+P
P8MPxB+TL5Q//8Y/x0+I78lvhq+Hv4jPza8tzrJUEnDPTjfQVjI6+jWdMFDRP56/n8+g39V0/8Ie
1v/YBNh82WDZk6Sfpa//pr+nz94z3pnfX+Bj4MXZYP/hfKzvrf+vD7Af5q/nv+jP/+nftQ+2H7cv
uD/vL71vvn//v4/An4B/w8/E38Xvxv/ID6/JH8ovA99YEWdYej7NyNwgQyZQR7NoZHAHIKIh/8tv
zH/Nj86fz6/Qv9HHBrD/W0GUcFKRGUY2cwhQhcCq0P8HQbuCJhDCv9Sf1a/Wv8tP393v3v/gD0Ty
4xB5NJAPovMnE7xQZXeyOPj2o6BFIP+8ELJQ5bMRw+Cgu9AH8ltB/zwC4U/iX+Nv5H9N0CbAEhEf
whA10LvQu6ElgW4tc48SEOhB+YIZzyZuYrJAoViJXCdhMNGpQQ+v/xC33CDCAQlRPCE2z+r/7A9v
7R87AfTko6BuJTAIgHQ/M3Elw6vAaQHg8SgXVVLuSfAv8T/yTEi0oCVR59H//7Ba1RKhvJD1n/av
97/4z/x9Y1txCaLpgwgzvRA1gHc0YZfQNnBplfBFo5EweP879DaCKRIAATwQGSHp3wH//wMPBB/h
EdvyukAAhiXAZ9HlvAMtvGQtYhNAWxD8n7v9r/JNZvrU9GAAAifo0v5kaAHcUV5fCk8LXwxv4RHz
+nDvYFROD5TzOfTW2zVfD/8RD/JMcsAGIm+PYW3/JsATtBbQAIMUvxXPFt8X7/07EG+poTukvODm
2LJQlfD/slC5kJgwUvVowzZRDmL8MWeF4POxhWAgZTWA/DByPyAPIR8iLyM/BUAPsSAtffTBcphA
3FEeobGRvKIo90jwl1GSACnopVMxNOQnlvloEWktlHD7UbtyKK8pv38qzyvfUkCjIAdBs5HcUHLf
kgAbbxx/HY9W4yBoANtg/xRCq9D6oCczKBH8Ig+gu5D9UxBk/CBnsVhAByBbEUbh7zF/Mo8znzSv
fToyWkCr0P8GoLJQq9D78fTVcxEw8NsQ+wjQB4Br+nC0sGofPh8/L/9AP+EvRO9F/0cP17/Yz0qo
/4rC/BPnddOPSU9KX0tvTH/fWC9ZOdqAl3C74HbTQNxRf4/QL4C8wbvRBgVpsQawbf9VsJgw9GPb
owfjB3Cio1Ww/yh/UR9SL1M/VELbsR8B+/H/80/0VrvCu4Img7OR9HC6MP8UcigwV5AkcgbgW19c
b11/516PGPD0YHVyhYHBse/g//SDB3EN0AkBGv9VH1YvY+//ZP9mD2cfSD9uD28fcC9xMP+L03Ff
cm9zf3SPcU92/3gP/3kfei97P3xPfV9+b39/gI//gZ+Cr4O/hM+F34bvh/+JD/+KH4svjD+NT45f
j2+Qf5GP+5Kfk6ZfmH+Zj5palC+VP/+WT5dfofDm5y6xnWHSoJ1g/8Jwm2+cf52Pnp+fqLLXoR+v
oi+jP6RPVH88vOBou9AIZj0ip/B0cHM6SC8vd6zgMS6y5i9zoFL6oG4voNKokNuwL72yRyKnyaag
BxAOoGSmogZmsHAu0XR7SFlQwEVSTElOS1ZwrG/zrX+ujX19sCGw4LywqhDAXGNmMVx1aJCo6P+y
D7Mfroyn56fXqWC576le5Dkyp4AvYafAvG+uwa9iAKfJu7+m5jWncS/bsEcwoL8fwC9nMjSrsW/k
OnC9nTI1vULEY6fmv6pyunioyKpjqM+p1je9Ql/EjrsBqo/LX6cEMKuxL/1o0HbB78j/zK/Qf81/
zo/Pz5/R/9XPprg1OL1R2uC8ZHnEnteP2h/Dpje9USun8r2dM9ulfd7wAAAAAwANNP0/BQADAA80
/T8FAAIBFDQBAAAAEAAAAE5JVEH5v7gBAKoAN9luAAACAX8AAQAAADEAAAAwMDAwMDAwMDQwNEUz
OTg3ODFDMTk0NDBBMzE3MzZFQzEwMkZFNjEwRTQ3QzVGMDAAAAAAAwAGEMl+ObwDAAcQ9g4AAAMA
EBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABSSUNIQVJELElGRVZSWVRISU5HSVNPSyxXSFlOT1RN
RU5USU9OU0lNUExFRk9SSU1BTkRQUkVTRU5DRVBFRVJJTkdJTlRIRVdHQ0hBUlRFUj9JRlRIRVJF
SVNBUFJPQkxFTU1FAAAAANm7

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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

------=_NextPart_000_0067_01C62CAB.79C34D30--





From speermint-bounces@ietf.org Wed Feb 08 14:05:22 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6ud0-000720-MW; Wed, 08 Feb 2006 14:05:22 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6ucw-000710-4m; Wed, 08 Feb 2006 14:05:18 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22248;
	Wed, 8 Feb 2006 14:03:36 -0500 (EST)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F6upa-0000uV-EJ; Wed, 08 Feb 2006 14:18:22 -0500
Received: from apache by newodin.ietf.org with local (Exim 4.43)
	id 1F6uct-00054l-7Y; Wed, 08 Feb 2006 14:05:15 -0500
Content-Type: text/plain
Mime-Version: 1.0
To: IETF Announcement list <ietf-announce@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Message-Id: <E1F6uct-00054l-7Y@newodin.ietf.org>
Date: Wed, 08 Feb 2006 14:05:15 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d16ce744298aacf98517bc7c108bd198
Cc: speermint@ietf.org
Subject: [Speermint] WG Action: Session PEERing for Multimedia INTerconnect
	(speermint) 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: iesg-secretary-reply@ietf.org
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

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

+++

Session PEERing for Multimedia INTerconnect (speermint) 
========================================================

Current Status: Acting Working Group

Chair(s):
Dave Meyer <dmm@1-4-5.net>
Jason Livingood <jason_livingood@cable.comcast.com>

Real-time Applications and Infrastruture Area Directors
TBD

Real-time Applications and Infrastructure Area Advisor:
Allison Mankin <mankin@psg.com>

Mailing Lists:
General Discussion: speermint@ietf.org
To Subscribe: speermint-request@ietf.org
In Body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/web/speermint/index.html

Description of Working Group:

The term "VoIP Peering" has historically been used to describe
inter-provider network interconnect and the delivery of voice
calls over interconnection points. While voice calls are the
primary motivation for this today, other forms of real-time
communications are and will continue to evolve as natural
additions to such peering. Therefore, the focus of this working
group is best generalized to describe calls as sessions, and to
note that that such communications are inherently real-time in
nature.

SPEERMINT focuses architectures to identify, signal, and route
delay-sensitive (real-time) communication sessions. These sessions
use the SIP signaling protocol to enable peering between two or more
administrative domains over IP networks. Where these domains peer,
or meet, the establishment of trust, security, and a resistance to
abuse and attack are all important considerations.

Note that the term "peering" is used here to refer to
the interconnection between application layer entities such as
SIP servers, as opposed to interconnection at the IP network
layer. However, in order to achieve real-time Session PEERing,
both signaling and media flows must be taken into
consideration. In addition, the working group recognizes that
there will be use cases that require SPEERMINT to focus on the
interaction between the application layer and lower network
layers, or the dependence of specific application layer use
cases on lower layers, so SPEERMINT will have to be prepared to
solve these problems as they arise.

More specifically, SPEERMINT focuses on real-time session
routing architectures and their associated use cases.
Deliverables here include the specification of the various
types of application flows, such as signaling and media flows, in
such networks, and includes both trunking and peer-to-peer
flows. In addition, SPEERMINT considers and documents requirements
for the feedback of operational conditions (e.g., congestion control)
that enables the application of dynamic policy and recognizes
that various mechanisms for achieving this should be studied as
a potential part of any architecture. In future, as its initial
work completes and the requirements become known, SPEERMINT may seek
rechartering to consider various mechanism to support applying
Quality of Service and/or traffic engineering mechanisms in an
architecturally sound way in support of real-time Session
PEERing. A charter discussion would consider how to work with
with mechanisms developed by other working groups, selecting
and integrating those, but as stated, first the initial milestones
must be completed.

The most focused deliverables of SPEERMINT are best current practices
regarding exchange of real-time sessions among VoIP and other
real-time application service providers and, in particular, how
such calls are routed. SPEERMINT will recognize that some of these
providers also control underlying access networks
(facilities-based), while others do not (not facilities-based),
and this fact may present various additional requirements or
use cases for consideration. The working group will develop
one or more use case documents to record the varieties of
the practices, as well as use this recognition as a guide to
maintaining the greatest possible separation of the application
layer from lower layers.

The SPEERMINT work plan is related to and distinct from the work
plans of the ENUM and SIPPING working groups. While the
the ENUM Working Group is primarily concerned
with the structure and lookup of data for the translation of
E.164 numbers into URIs (RFC3761), SPEERMINT is concerned with
the use of the resulting URI data, as well as non-ENUM-derived
URI data, for use in signaling and routing of real-time
sessions. The SIPPING WG produced the original document in
this area (RFC 3824). The future work in this area will be
produced by SPEERMINT, but RFC 3427, the SIP change process will
be followed as needed.

Issues that are out of scope for SPEERMINT include: 

o Interoperability, and NITS/profiling of existing protocols
such as SIP, RTP, and SRTP,

o SPIT prevention. Note, however, that other working groups
may release relevant specifications that become required or
are referenced by various SPEERMINT uses cases and BCPs,

o Routing of sessions which are not signaled using SIP. In
particular, SPEERMINT is constrained to consider only those
scenarios in which call routing is signaled using the SIP
protocol and addressed by SIP or SIPS URIs. E.164 numbers and
other national or private formats may only be used as defined
within the SIP protocols, and 

o H.323

In the goals and milestones, "submit" means to submit the document to the IESG
for publication.

-----

Goals and Milestones:

Jul 2006 Submit SPEERMINT terminology I-D (Informational).

Sept 2006 Submit I-D defining the SPEERMINT routing architecture
(Informational).

Dec 2006 Submit I-D defining the message flows associated with the
SPEERMINT routing architecture (Informational).

Jan 2007 Submit I-D on the use of DNS SRV and NAPTR records as specified
by RFC 3263 (BCP).

Mar 2007 Submit I-D on the minimum set of requirements for SIP-based
VoIP interconnection (BCP).

July 2007 Submit I-D specifying the use of strong identities in session
peering and supporting the establishment and exchange of trust 
between domains (BCP).

Jul 2007 Submit I-D(s) on use cases (BCP).

Jul 2007 Propose re-chartering for any additional efforts/considerations, 
or propose conclusion of working group (following approval of
last documents)




_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Wed Feb 08 14:26:07 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6ux5-00023m-4c; Wed, 08 Feb 2006 14:26:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ux2-00022q-Gb
	for speermint@megatron.ietf.org; Wed, 08 Feb 2006 14:26:04 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23886
	for <speermint@ietf.org>; Wed, 8 Feb 2006 14:24:14 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F6v9X-0001gE-OV
	for speermint@ietf.org; Wed, 08 Feb 2006 14:39:01 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a
	borkenaddressingsystem?
Date: Wed, 8 Feb 2006 20:29:32 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C482F@oefeg-s04.oefeg.loc>
Thread-Topic: [Enum] RE: [Speermint] and are phone numbers a
	borkenaddressingsystem?
Thread-Index: AcYrwI7+uWvK8J5uRVuyJ8CBkI74WgAJ7DSQAAKZZWAACOn2kAAqf85AAAHNxSAAATau0AABECRrAAMimxAAAea7nQ==
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: <henry@pulver.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Content-Transfer-Encoding: quoted-printable
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Henry,

>If evrything is OK, why not mention SIMPLE for IM and Presence peering =
in the WG charter?

>If there is a problem mentioning and using SIMPLE, could we be informed =
what it is?

I am not the WG chair and also not an AD responsible for the charter, so =
I have no say here
=20
my two cents is only that SPEERMINT is basically SIP peering, and I have =
been educated
some time ago during the discussion in ENUM WG regarding  the SIP =
enumservice that
SIP can be basically used for establishing any type of communication =
session (including
boiling the ocean and saving the whales) so either mentioning SIP is =
sufficient or you have=20
to list all potential and future ways to communicate. Why only =
mentioning SIMPLE.
=20
regards
Richard

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Wed Feb 08 14:43:38 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6vE1-0006MB-W9; Wed, 08 Feb 2006 14:43:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F6vDy-0006KO-ST
	for speermint@megatron.ietf.org; Wed, 08 Feb 2006 14:43:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25534
	for <speermint@ietf.org>; Wed, 8 Feb 2006 14:41:32 -0500 (EST)
Message-Id: <200602081941.OAA25534@ietf.org>
Received: from mail.pulver.com ([192.246.69.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6vQH-0002Os-B5
	for speermint@ietf.org; Wed, 08 Feb 2006 14:56:19 -0500
Received: (qmail 24743 invoked by uid 510); 8 Feb 2006 15:08:28 -0500
Received: from henry@pulver.com by mail.pulver.com by uid 508 with
	qmail-scanner-1.22-st-qms 
	(clamdscan: 0.72. spamassassin: 2.63.  Clear:RC:1(67.187.111.112):. 
	Processed in 3.043274 secs); 08 Feb 2006 20:08:28 -0000
X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com
X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(67.187.111.112):. Processed in
	3.043274 secs Process 24712)
Received: from c-67-187-111-112.hsd1.wa.comcast.net (HELO 1AB764895C324D3)
	(henry@pulver.com@67.187.111.112)
	by 192.246.69.184 with SMTP; Wed, 08 Feb 2006 20:08:25 +0000
From: "Henry Sinnreich" <henry@pulver.com>
To: "'Stastny Richard'" <Richard.Stastny@oefeg.at>
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a
	borkenaddressingsystem?
Date: Wed, 8 Feb 2006 13:43:02 -0600
Organization: pulver.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0090_01C62CB5.95309690"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcYrwI7+uWvK8J5uRVuyJ8CBkI74WgAJ7DSQAAKZZWAACOn2kAAqf85AAAHNxSAAATau0AABECRrAAMimxAAAea7nQAAlcoA
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C482F@oefeg-s04.oefeg.loc>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-MS-TNEF-Correlator: 00000000404E398781C19440A31736EC102FE61024805F00
X-Antivirus-MYDOMAIN-Message-ID: <113942930583524712@mail.pulver.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 225414c974e0d6437992164e91287a51
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: henry@pulver.com
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

This is a multi-part message in MIME format.

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

Richard,

Sure, we both have the same understanding, but people who don't know may be
left confused if the peering protocol is SIMPLE or Jabber/XMPP and it would
help to clarify (Google for example). The IETF has not been too clear by
blessing two IM protocols.

Thanks, Henry

  _____  

From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] 
Sent: Wednesday, February 08, 2006 1:30 PM
To: henry@pulver.com
Cc: speermint@ietf.org
Subject: RE: [Enum] RE: [Speermint] and are phone numbers a
borkenaddressingsystem?

 

Henry,

>If evrything is OK, why not mention SIMPLE for IM and Presence peering in
the WG charter?

>If there is a problem mentioning and using SIMPLE, could we be informed
what it is?

I am not the WG chair and also not an AD responsible for the charter, so I
have no say here

 

my two cents is only that SPEERMINT is basically SIP peering, and I have
been educated
some time ago during the discussion in ENUM WG regarding  the SIP
enumservice that
SIP can be basically used for establishing any type of communication session
(including
boiling the ocean and saving the whales) so either mentioning SIP is
sufficient or you have 
to list all potential and future ways to communicate. Why only mentioning
SIMPLE.

 

regards

Richard


------=_NextPart_000_0090_01C62CB5.95309690
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Disposition: attachment;
	filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IgITAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgBYFAAAJAAAAAsAAgABAAAAAwAmAAAAAAALACsAAAAAAAMA
LgAAAAAAHgBwAAEAAABHAAAAW0VudW1dIFJFOiBbU3BlZXJtaW50XSBhbmQgYXJlIHBob25lIG51
bWJlcnMgYSBib3JrZW5hZGRyZXNzaW5nc3lzdGVtPwAAAgFxAAEAAABIAAAAAcYrwI7+uWvK8J5u
RVuyJ8CBkI74WgAJ7DSQAAKZZWAACOn2kAAqf85AAAHNxSAAATau0AABECRrAAMimxAAAea7nQAA
lcoACwABDgAAAAACAQoOAQAAABgAAAAAAAAAQE45h4HBlECjFzbsEC/mEMKAAAADABQOAQAAAB4A
KA4BAAAAKgAAADAwMDAwMDA4AWhlbnJ5QHB1bHZlci5jb20BbWFpbC5wdWx2ZXIuY29tAAAAHgAp
DgEAAAAqAAAAMDAwMDAwMDgBaGVucnlAcHVsdmVyLmNvbQFtYWlsLnB1bHZlci5jb20AAAADAN4/
n04AAAMAAlkAABYAAwAJWQIAAAALAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMABIAI
IAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAACwAcgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAA
AAADAB2ACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAEAAH4AIIAYAAAAAAMAAAAAAAABGAAAA
AGCFAAAAcJpKMgAAAAsAJoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAqgAggBgAAAAAA
wAAAAAAAAEYAAAAAGIUAAAAAAAALAESACCAGAAAAAADAAAAAAAAARgAAAACChQAAAAAAAAsAHw4B
AAAAAgH4DwEAAAAQAAAAQE45h4HBlECjFzbsEC/mEAIB+g8BAAAAEAAAAEBOOYeBwZRAoxc27BAv
5hADAP4PBQAAAAIBCRABAAAAdhAAAHIQAACQQAAATFpGdVMWxQsDAAoAcmNwZzEyNYIyA0NodG1s
MQMw/wEDAfcKgAKkA+QHEwKAEAP/AFAEVghVB7IRNQ5RAwECAIRjaArAc2V0MgYA2wbDETUzBEYT
xzASPwIAXjQDxRXZB20RNTUDxlRsYWgDcRE1NhBvAfE36Re/IFYEkGQAcBsREUNbCO8J9zsffw4w
NSCfZb0OIDgh7yBxEUEMYGMAUDMLCQFkMzYWYAulNCA5EAIqXA6yAZAOEDkgMjwOsiB4DtAAgDp2
JD0iCHBuOgTwaGUxAMBzLW0N4ANgc2+1AYAtBaBtKIAO0CIoJa5vKK8puSngZg3gZSzVvSqWdysv
LD8uIAWwZCqVAy5ADrB0cDovL3chMbAudzMuBbBnL4BUUi9SRUMtDrLwNDAiPhFDJxcUUAqjMzNf
NG9nMyawJ9BlYb5kM00O8TW/OD8nVDYO8DY8B4ABkCAeYAeAPUfzCfAEkGF0BbEFoAIwCfBKdC5A
TSmWIFcwgSB6MQ7wKC0AJ2AEkAmAIMEHgGRpdW0pMz45n4U1QzQ7ASEtLVsGkEggIW0p0F0+CqM8
IHN0eWxlQpR2XIhcOioDMHtiZRPwFHZpBbA6CHBsKCMJAQFhdSdgI1ZNTOopIzB9CqNvQ89E30Xl
TndGb0d/ReUucxPwcG5lSU9KX0LCL0MJQcBb8wnwPuBmXUHgP09AXyeBxDc3J8B0aXRDMUCvgQfw
RTogW0VuPwD6XVPEU0vQBJApgAIwVGDvAHA90ArAS+BwGuA78DtwPz8ATCAUEFVwCqMG4HJrOwnw
NzBkI1AEEAuAZ3OWeUMALtA/T904NU4x/1JfUI9BGkMEW69bREHCCqP9AhItTSAtIAqkAZFL8V81
cSmAbHk6GsVF5QqjIMovSTBGAiEgRAEQC4CnWgBMcAYxKi9iJEBfPy9gT2FVZPcKsG4pwGUtTDE6
FFA98TYgJrAz3iBZsCawJrAUUDRF1mRPv2VfHhZm32fvaPticlNDEqNi/2JCcC5NKdBOBbDBAMBs
LCBsaXFKPuA+dnFIamoAwDIwC4A6MHcLgGxZdHQtBuACQCoxLnowdrAxBTBsWWnTAJB6Xy0wDiB2
oHb/YMYiB20iSUXWYTpyAG5rceBz820BcUJIeUvQTMB78Wpq3R7zOgoybFk8oHgqAAWD/zwgY3FM
oE9QfPN+oXtmTGC7AJA8oGR8L3wAYrBsHxC+dwmAfV9+b39/gI1wc7tPKdApcHXUPDBwLQdAdK46
TTA8MHUfLQUQZw6w/3TeiLh2NImPdZhDMAGAdN3/d89433nvevuCIy7RAxBDA39ZkGpvYNUQ5JV4
hHQeYHb6eZPrRZTCb5MnoIfuQwO7iUB80Tp84SnQHmBsiyD+ZQtQmIGRj5a/l89pgwqw9mdL4AZg
Y2NiJNOVtpCz+DguNQuAPeF2oHT/dLH7oqM94C4OMKRDpDhF1nLi96CvS/GgUjqmZkXWT6FbX/9B
YiexTlVaX6k/q+8nU0GSXi83HzVvr78nCDUWYDwZBuBkeXHwAHBnPUXYTi1VBfB74j0KMkOgP7P3
ryAnIwAhAzCzQjEw/jNuILVWFmAm2yYhsZ+37/UnUzlt4Dxy4TxgC2AEEP49pma1OQAAtp+4/72f
uc+/cuG7/70Pv2/DHycXNjbhznDBP8JPDhA0OCfAAhL7ghCQwT1uIGoiLkCS7sZb7yaDF4G2fyc1
ODbhgiKCEGlDEj0nkG4nxl/Mo1LfDeAT8YHwXU024W+bwK8u/w5ATjHS37qA1BKCIrU5tUf1x541
uqEvAhLWD9cTtVb/CqLWuAqBtWcKsduYwn0BwP9OMdL+xL/fL8WP0B/Hr8i/f8nPyt/L78z/zg/P
H+KvU/0IcGVx4IOArczgxbVX6El5djFoIExBS+DwYEvgc307kSCGw0MAVYFYEXHgYtuN4FXwZYlg
b8F3GuBy0MMCIOj+JiM4MlIAAoDdtVgn1XDoWAVAa20gB+D/AMCzIEwgcfABce2/7s/ohfk8cWZ1
FCA90EIR8OJU4n9YEVXwA2A8MB7x+qAGQUmwTVBMRUZABcBKAaDpVpEvWPyAUFVzWgBI4E0IYGw9
0C7AbHCFsG8/95/4r/m2C2AGgbMgKEf4b29nb8EPkAXAhdA7kBny0SkuGMDw8UlFVP5G8IFWwG0g
9nBMIAnw/tH/8zC7EK7wVyH3AUMwV/OFsD8wcP8PAB/ohfxw+5dzLv/Rv9LP09/U79X/6J/YHw5v
/9o/20/cX91v3n/g3xdf4a//4r/jz+Tf5e/m/+gP6R/qL8/rPxrdA3AiMGtz0awHP+UgWUhXgHJ5
Cc8K3wvv/wz/Dg8grxAvLT8STxNfFG9fFX8WjxjvNi+s5TApgS//wQwtnzcvOv+/38DvOj88nz9A
Tz1vuslxV1VwcgBnbn49HcBi0FagIlaFw0UDOvNFZCPccWMgWRlrPs8/3/8cnl7kHb8ezx/fIO8h
/yMP/0n/P/0mhlTvJsswbzn8NEt3Jvcx2kK/aJRBHUKxYHccaWTwYE2AtjAwJSLPRPyEEaSwgIB4
PW1gTqxnptBIMEggalz+UWVhfvwgX2ICYcG14IDBMZMzb/9Bv2P/sG8coiyVZo8vVjgf/zkvY09l
r2yfGT8aQEP+U4/7bB9RY2JxK4hhcf9Lr12DeU1DVGHzIJlwTq4w8WbuNXSPUQ9SHzCRKJIad2T+
O5ITg4CLQ/BA/mBTf3lk8kb7sG06K48sn3kvLr//gl+Db4Gzc5qFz3WfXWRM+L93b3h/iM96n3uu
fP9hfy/vjXSgkG5QqrBuAfDRNVY/2ybPjWVbmXIE0DrRNaZQCZNkQG/3YGVnLmGUdF2I/TGEkWJy
tTv/YqFjL1U/cp9zr5t/jm9SRv9+f5I/p/AdAIDfge+IX4bfm6YvJ4BX+oBisHNk9vBp7XBGZZoQ
dTNAAfAw5jjtcIzAMDab/5VfptXIMTozbEBQTZj/mg//mx+r350/nk+xD6BvoX+ij/8kqZcwp0+l
n7UPp7+7z/6BmShhQHD+UPCwci4JcP5trq+vv7DPsd+y77P/wt/Pth+3L7g/xthDY7oPux//vC+9
P82PJ4DIgPsxkSAdAKhAaWUxcC4CoGfAf//Bj8Kfw6/Ev8XP1M/H78j/w8oP7JpiamVjpG/M34/N
787/37+TIVJFOpbA8EVudW2Y0OOB1W+sv/2WZlPRVpjQ/cIzQPsB8yBfYrAEMOPw/TEEIGHwMXJi
ayhQYWRk7VAF03PiefHAZW0/4O/fP+BP/4Qf7B/tLylvKn8xHzIvMz//NE81X9Zf+D9qH+7/bD/5
v//9j29vcH9xj4kfHO9Nn06v/0+/2Y+PD3wBTPNTHwJP8I9R1q8mbmIJUDvTuSf8YTAMP/If6q/r
vxCP7d//FB8w3/P/9Q/2H/cv/u8dDxVC7yBd4D1d4E9XQWhSZXCRQFRGUUmwOPwxNwt/Gv8eryPP
Pb8h//8jDyVvKR//2ycvKD+Jz0Pwa9wA0jA96YB2qwAE40HMcmkBjYykY2Z28Adg7xZQLQ8Iv49e
MZBvTPMwg7o7L4M6L+ILbzLESL+C/iwSrxO/Mo8V3ztfPG8D2OUvhGJEEGNrOCsyAATA/z7fM5+P
Uzd0TPNBQzgfQu//DY8RfxKPOt8+vzz/Pg8X3/8Y7xn/TP8cHypvVL8rP0Yv/1LPLm8vfzCPMZ9Z
D0PfNM/fNd827zf/Xo8O1md8gOWoSj5kyEnUMGV2qvB0TmjqASBw6PBPS6tAd3JoqwBub3aABWAE
QGmDdmCTQElNUExFfOG/iwBqQOei5G/lf2T1UOnB/7+ABQDoINFhaINgQGhg6HDcV0cAoJQB6mBy
6p9Lf/9Mj02fcW9yf0A/QU9CX18v/2AwitNEq0XPZL9H70j/Sg//cK90j3LPc99PX1BvUX+Cv/9T
n1X/in+Lj1ffiI9Z/1sP/1wfXS9eP3mvYF9hb2J/Y4//js9lr2a/Z8RvEegBaMHpEPhwcm93YOpw
aaZoguey/nXp8molq0DAQL/gaz9sT++a9tuA6SCecW5qoQVg59DVaTBhBFBppTFzb/+Bj/+Cn4Ov
px+oL3Zfd294f5U//3qfe6+an33Pft9/76Yvqg//qx+pX4U/hk+HX4hviX+L3/+Ln8EP+s+6v8F/
wo/GX8Nf/8RvxX/H38uvJm+yP8w/zU9/0P8AHwEvz1+rj5DnBONWtecwZJZAYZLPB1E3rm/7lX+W
jzCXo7Bjl/rYdbHf32eV6QCfQGlybxhpsJDns45s1GBpY9wRQUQg6cH+cAQw6fCfEWqSoY+in9p1
v28Sb4WhEOJx4LBvkHZuQPtpcNwwYZIAnkK2P7dP2k//uW/qX+tvtB+1L7vPvN+97/++/8AP0m/2
f8if7T/P//f///vPze/fj/sP/W8BH9M/1E8f/3/Wb5DHrlCSIyJUaQNpsJ6gTmV3IFJv2QTwbiLY
7uUBZuUBBf/n22+WrLBjMTKXot9PC28ZnCRuYgzQnKlcJ2H+MA+/7u/v/7Xf6Z/6L+u//+zPuy/x
3/LvGG/1DwIPIC//+D/5TxgfIa8lfyaP/p8Pn/8nHyrPAt8D7wT/Kj8HH9fv/9j/2g8L/w0P3T/e
Ty9/NSPybZIAdHfigJJAOMCeoB9owWoAmIBvAaUhU1BFQEVSTUlOVGiyYrkuoGljL1A8YWowUOQ/
/+VPNQVuZaEQoBLnxaRAacD5aBBkdT3wb8ChfJeAGdHkYnKtaVxspHDo0TTfvz78LvBpsG8ACNGe
sGfigM9CsG6TbxIpIHNjoFA3kONqAW7hRU5VavDhgW3g/mcd4CkgaJEQXxFvEnpvEk8+Xz9vRYhp
wHVtbgBy/nY94EehpRFDL0Q/RU9Oj/59TiEucDahpEE9uKBQpNH/aqJt8CygsYBowGhzNqA7UR55
bmA8MG0AoTBtbXX/n8BC0WnybgBJU1TvT29UdfYopHAugHVKslHvUv9UD7FbL31ibzkgSIZvkkB/
NqGgEuhgUVBIlaUBlqBz+inngmWlUJ5Bn1pWMmjB0HN1ZmY94GlpwWEv91wPYLVX4XmhQOfUXi9f
P/NgT2effXTigFhh4sE+EP9BAOEQZbIvUKACSw9MHxJ6+GZ1dEhgZGHocJ6gbwHpWahlLkogaJIA
PENlqO9tv2h/bUWgtC4WLxc/bR//GV9633vvFA8VHxu/HM8d3/8e7x//LP+G/yMvfb8qj4h//4xP
KH86H4uPje+Rny3PLt//j/8w/we/CM8J3wrvNa82v/8OH5XfnC9xjxJffy+APxWP/3nfim+W330P
Gt+CH4MvhD//hU+ST5IPsX+Jj6svse+y//+2z47fn9+3X7cfvB+UL5U//7p/l18yPzNPNF+gz51P
N4/vOJ85r8VnSmRzpq+nv8Vf/6nfza/Ov6SPpZ+sP61Prl//r2+wf71/2c+zr9CPuw/bT//fH7j/
yp/eX+C/5G++T79f/+LPwX/Cj8OfxK/pn8bPx9/3yO/J/+kaUj3gUbDygMw//81P7d/Pb/Yv9z/S
n9Ov1L//1c/W39fv2P/l/wJP3C/5D//jjwPPB58EnwWvBr8JHwzvlfqWNerBL2JwZHn7nv8OjxEf
+qbtsAqgd8L7nZjABRK0fRXwAAADAA00/T8FAAMADzT9PwUAAgEUNAEAAAAQAAAATklUQfm/uAEA
qgA32W4AAAIBfwABAAAAMQAAADAwMDAwMDAwNDA0RTM5ODc4MUMxOTQ0MEEzMTczNkVDMTAyRkU2
MTAyNDgwNUYwMAAAAAADAAYQX9ydxQMABxDsAwAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAA
AFJJQ0hBUkQsU1VSRSxXRUJPVEhIQVZFVEhFU0FNRVVOREVSU1RBTkRJTkcsQlVUUEVPUExFV0hP
RE9OVEtOT1dNQVlCRUxFRlRDT05GVVNFRElGVEhFUEVFUklOR1BST1RPQ08AAAAA71M=

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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

------=_NextPart_000_0090_01C62CB5.95309690--





From speermint-bounces@ietf.org Wed Feb 08 14:43:54 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6vEI-0006U2-Nm; Wed, 08 Feb 2006 14:43:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F6vEH-0006T4-1p
	for speermint@megatron.ietf.org; Wed, 08 Feb 2006 14:43:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25582
	for <speermint@ietf.org>; Wed, 8 Feb 2006 14:42:11 -0500 (EST)
Received: from m106.maoz.com ([205.167.76.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6vQu-0002QC-GW
	for speermint@ietf.org; Wed, 08 Feb 2006 14:56:58 -0500
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])
	by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k18JhgFr003034;
	Wed, 8 Feb 2006 11:43:42 -0800
Received: (from dmm@localhost)
	by m106.maoz.com (8.13.4/8.12.11/Submit) id k18Jhg9l003033;
	Wed, 8 Feb 2006 11:43:42 -0800
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using
	-f
Date: Wed, 8 Feb 2006 11:43:42 -0800
From: David Meyer <dmm@1-4-5.net>
To: Stastny Richard <Richard.Stastny@oefeg.at>
Subject: Re: [Enum] RE: [Speermint] and are phone numbers a
	borkenaddressingsystem?
Message-ID: <20060208194342.GA2920@1-4-5.net>
References: <32755D354E6B65498C3BD9FD496C7D462C482F@oefeg-s04.oefeg.loc>
Mime-Version: 1.0
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C482F@oefeg-s04.oefeg.loc>
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader,
	Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0361125862=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org


--===============0361125862==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8"
Content-Disposition: inline


--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 08, 2006 at 08:29:32PM +0100, Stastny Richard wrote:
> Henry,
>=20
> >If evrything is OK, why not mention SIMPLE for IM and Presence peering i=
n the WG charter?
>=20
> >If there is a problem mentioning and using SIMPLE, could we be informed =
what it is?
>=20
> I am not the WG chair and also not an AD responsible for the charter, so =
I have no say here
> =20
> my two cents is only that SPEERMINT is basically SIP peering, and I have =
been educated
> some time ago during the discussion in ENUM WG regarding  the SIP enumser=
vice that
> SIP can be basically used for establishing any type of communication sess=
ion (including
> boiling the ocean and saving the whales) so either mentioning SIP is suff=
icient or you have=20
> to list all potential and future ways to communicate. Why only mentioning=
 SIMPLE.


	The intention of the charter was certainly to admit SIP
	peering independent of the application (or applications)
	being carried. We're working with our ADs to see if we
	can clean up any charter language that might indicate
	otherwise. As you may recall, most of VoIP specific
	language derrives from the fact that we started thinking
	about VoIP peering, and quickly came to the conclusion
	that VoIP was to narrow a scope.

	Dave


=09

--MGYHOYXEY6WxJCY8
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFD6knuORgD1qCZ2KcRAmMwAJ9ChXE6WBVQaKT/VjbwL3/8MRcgfACcCA/j
mXfMNDrgYvp0QsvP0VVmW8k=
=5YV3
-----END PGP SIGNATURE-----

--MGYHOYXEY6WxJCY8--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============0361125862==--




From speermint-bounces@ietf.org Wed Feb 08 18:08:43 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F6yQV-0000T1-Ea; Wed, 08 Feb 2006 18:08:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F6yQN-0000Rc-Ax
	for speermint@megatron.ietf.org; Wed, 08 Feb 2006 18:08:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14973
	for <speermint@ietf.org>; Wed, 8 Feb 2006 18:06:37 -0500 (EST)
Received: from mail1.nextone.com ([209.125.86.104])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6yco-0002Ux-4T
	for speermint@ietf.org; Wed, 08 Feb 2006 18:21:27 -0500
Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with
	Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Feb 2006 18:08:11 -0500
Content-class: urn:content-classes:message
Subject: RE: [Enum] RE: [Speermint] and are phone numbers
	aborkenaddressingsystem?
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 8 Feb 2006 17:45:43 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <F1F8A60D618B704195CE0515A25E4606010333@moe.nextone.local>
Thread-Topic: [Enum] RE: [Speermint] and are phone numbers
	aborkenaddressingsystem?
Thread-Index: AcYrwI7+uWvK8J5uRVuyJ8CBkI74WgAJ7DSQAAKZZWAACOn2kAAqf85AAAHNxSAAATau0AABECRrAAMimxAAAea7nQABnNtA
From: "Medhavi Bhatia" <mbhatia@nextone.com>
To: "Stastny Richard" <Richard.Stastny@oefeg.at>, <henry@pulver.com>
X-OriginalArrivalTime: 08 Feb 2006 23:08:11.0779 (UTC)
	FILETIME=[88609D30:01C62D04]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: quoted-printable
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Quick clarification: When you say SIP w/ ENUM are we talking about
peering of non E.164 name spaces (like full URIs)? I would think the
answer is yes.

> -----Original Message-----
> From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org]
On Behalf Of
> Stastny Richard
> Sent: Wednesday, February 08, 2006 2:30 PM
> To: henry@pulver.com
> Cc: speermint@ietf.org
> Subject: RE: [Enum] RE: [Speermint] and are phone numbers
aborkenaddressingsystem?
>=20
> Henry,
>=20
> >If evrything is OK, why not mention SIMPLE for IM and Presence
peering in the WG
> charter?
>=20
> >If there is a problem mentioning and using SIMPLE, could we be
informed what it is?
>=20
> I am not the WG chair and also not an AD responsible for the charter,
so I have no say here
>=20
> my two cents is only that SPEERMINT is basically SIP peering, and I
have been educated
> some time ago during the discussion in ENUM WG regarding  the SIP
enumservice that
> SIP can be basically used for establishing any type of communication
session (including
> boiling the ocean and saving the whales) so either mentioning SIP is
sufficient or you have
> to list all potential and future ways to communicate. Why only
mentioning SIMPLE.
>=20
> regards
> Richard
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Thu Feb 09 04:52:35 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F78TZ-0005WM-Qg; Thu, 09 Feb 2006 04:52:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F78TI-0005QL-SM; Thu, 09 Feb 2006 04:52:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04247;
	Thu, 9 Feb 2006 04:50:22 -0500 (EST)
Received: from [193.80.224.123] (helo=kahua.nona.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F78fq-00008T-1e; Thu, 09 Feb 2006 05:05:17 -0500
Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3])
	(AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
	by pahula with esmtp; Thu, 09 Feb 2006 10:51:43 +0100
	id 0006C002.43EB10B0.00002B1F
Message-ID: <43EB109F.1030804@enum.at>
Date: Thu, 09 Feb 2006 10:51:27 +0100
From: Alexander Mayrhofer <alexander.mayrhofer@enum.at>
Organization: enum.at GmbH
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Robert.Shaw@itu.int
Subject: Re: [Enum] RE: [Speermint] and are phone numbers a
	borken	addressingsystem?
References: <2ECA12DF5FCB7948A1CD9047C3DAF3DC010DDFA7@MAILBOX1.blue.itu.ch>
In-Reply-To: <2ECA12DF5FCB7948A1CD9047C3DAF3DC010DDFA7@MAILBOX1.blue.itu.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, speermint@ietf.org, trutkowski@verisign.com,
	lconroy@insensate.co.uk
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Robert.Shaw@itu.int wrote:
>> All neat stuff I'm sure. But it lacks the kind of universality and
>> authoritativeness that are ultimately required for a system 
>> that's going to be more than an adjunct, however popular. 
> 
> Indeed. There are about 3.4 billion mobile + fixed subscribers
> out there with most of them now *mobile* and growing fast. At 
> this time, provider-based URI schemes are barely a blip on this 
> radar screen.

And, i think that phone numbers may even enjoy a renaissance as identity 
tokens, with "Identity 2.0" (whatever you interpret into this - 
schizophrenia with 1.0 being me, and 2.0 being ... ??) as one of the new 
internet buzzwords. I hope i'll have my ideas in  a draft by Dallas - stay 
tuned ;)

cheers

alex

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Thu Feb 09 04:54:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F78Uy-0005yg-In; Thu, 09 Feb 2006 04:54:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F78Ur-0005xd-Vy; Thu, 09 Feb 2006 04:53:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04377;
	Thu, 9 Feb 2006 04:52:03 -0500 (EST)
Received: from pb94.dyndns.org ([213.239.207.29])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F78hV-0000Bd-3h; Thu, 09 Feb 2006 05:06:58 -0500
Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3])
	by pb94.dyndns.org (Postfix) with ESMTP id C1E2B721558;
	Thu,  9 Feb 2006 10:53:24 +0100 (CET)
Message-ID: <43EB111C.40500@pernau.at>
Date: Thu, 09 Feb 2006 10:53:32 +0100
From: Klaus Darilion <klaus.mailinglists@pernau.at>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Stafford, Matthew" <matthew.stafford@cingular.com>
Subject: Re: [Speermint] RE: [Enum] a suggestion re: using flags to distinguish
	post-ENUMs ignaling f lows
References: <DE175C3426C51144B22109E3346CFFA42186ED02@S75202E004049.sbms.sbc.com>
In-Reply-To: <DE175C3426C51144B22109E3346CFFA42186ED02@S75202E004049.sbms.sbc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, Stastny Richard <Richard.Stastny@oefeg.at>,
	speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Stafford, Matthew wrote:
> ==> E2U+mms:mailto:mx ?
> ==> or mailto:a@example.com;mx=yes/no ?
> 
> ==> E2U+sip:srv
> ==> or sip:a@example.com;srv=yes/no

I can't follow your discussion: Why do we need a mx=yes/no parameter?

AFAIK standard SMTP applications try MX first with fallback to A. Thus, 
mx=no can be achieved just by not having an MX record for the domain.

regards
klaus

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Thu Feb 09 09:31:18 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F7CpK-0007fY-A5; Thu, 09 Feb 2006 09:31:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F7CpF-0007bn-4P; Thu, 09 Feb 2006 09:31:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26133;
	Thu, 9 Feb 2006 09:29:22 -0500 (EST)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F7D1v-0001aQ-6D; Thu, 09 Feb 2006 09:44:20 -0500
Received: from [10.10.2.124] (sj-natpool-220.cisco.com [128.107.248.220])
	(authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k19EUwI2012326
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 9 Feb 2006 08:31:00 -0600
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4820@oefeg-s04.oefeg.loc>
References: <32755D354E6B65498C3BD9FD496C7D462C4820@oefeg-s04.oefeg.loc>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7D29B289-1104-4FC5-AE49-EAEE963806B9@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Speermint] Re: [Enum] a suggestion re: using flags to
	distinguish post-ENUM signaling f lows
Date: Thu, 9 Feb 2006 08:31:14 -0600
To: Stastny Richard <Richard.Stastny@oefeg.at>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.8 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org


On Feb 7, 2006, at 12:50 PM, Stastny Richard wrote:

>> The second one is (essentially) number portability. My SIP URI can  
>> change from sip:mstafford@provider-A.net to  
>> >sip:mstafford@provider-B.biz. As long as my phone number stays  
>> the same, it can be used to obtain my current SIP URI.
>
> What I want to have is SIP URI portability too, or in other words:  
> I want to have my sip URI sip:richard@stastny.com
> hosted by one provider and the possibility to port this to another.
>
> Especially if I am a company.
>

It's quite easy to move stastny.com from one provider to another --  
you simply change the DNS NS, A, MX,  and SRV records appropriately,  
and you're moved. We don't even need ENUM for this, and it's not a  
peering problem ala speermint.

Having a phone number translate to a different URI requires either a  
DNS record change or an delegation, depending on which portability  
model you're using.

What is HARD to is to move sip:richard@stastny.com without also  
moving sip:alice@stastny.com. That's basically a 302 operation,  
requiring database dips at the original host, and you expect it to be  
painful.

--
dean

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Thu Feb 09 12:09:04 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F7FI0-0002ls-Rb; Thu, 09 Feb 2006 12:09:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F7FHz-0002lj-DT
	for speermint@megatron.ietf.org; Thu, 09 Feb 2006 12:09:03 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09178
	for <speermint@ietf.org>; Thu, 9 Feb 2006 12:07:17 -0500 (EST)
Received: from mail2.nextone.com ([209.125.86.105])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7FUj-0007PZ-Sl
	for speermint@ietf.org; Thu, 09 Feb 2006 12:22:17 -0500
Received: from moe.nextone.local ([192.168.15.38]) by mail2.nextone.com with
	Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Feb 2006 12:08:53 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 9 Feb 2006 12:08:53 -0500
Message-ID: <F1F8A60D618B704195CE0515A25E46060106CB@moe.nextone.local>
Thread-Topic: Some clarifications
Thread-Index: AcYtm4DRH5LB2zl2Sm+p1CwOMlEm8A==
From: "Medhavi Bhatia" <mbhatia@nextone.com>
To: <speermint@ietf.org>
X-OriginalArrivalTime: 09 Feb 2006 17:08:53.0893 (UTC)
	FILETIME=[814A0350:01C62D9B]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250
Subject: [Speermint] Some clarifications
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0820942777=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0820942777==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C62D9B.CBE55CE8"

This is a multi-part message in MIME format.

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

I was going through some web archives for what I have seen so far on
this list and was just trying to put together what is on the table along
with some comments I might have:

=20

In terms of drafts, it seems that the following drafts (even though they
are not WG docs) are under consideration:

=20

http://www.ietf.org/internet-drafts/draft-lendl-sip-peering-policy-00.tx
t

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-meyer-voipeer-te
rminology-01.txt

=20

Am I accurate making this assumption?

=20

Also, seems like the first goal is to tackle real time sessions, like
voice and keep all the other interesting peering like SIMPLE etc which
Henry was talking about on another thread in scope as well. I am
wondering if things like TRIP/TGREP have been considered as well (or
modifications thereof).

=20

-Medhavi.


------_=_NextPart_001_01C62D9B.CBE55CE8
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:schemas-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:"Times New Roman";
	color:windowtext;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.25in 1.25in 1.25in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>I was going through some web archives for what I have seen so =
far on
this list and was just trying to put together what is on the table along =
with
some comments I might have:<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>In terms of drafts, it seems that the following drafts (even =
though
they are not WG docs) are under =
consideration:<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><a
href=3D"http://www.ietf.org/internet-drafts/draft-lendl-sip-peering-polic=
y-00.txt">http://www.ietf.org/internet-drafts/draft-lendl-sip-peering-pol=
icy-00.txt</a><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><a
href=3D"ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-meyer-voi=
peer-terminology-01.txt">ftp://ftp.rfc-editor.org/in-notes/internet-draft=
s/draft-meyer-voipeer-terminology-01.txt</a><o:p></o:p></span></font></p>=


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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Am I accurate making this =
assumption?<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Also, seems like the first goal is to tackle real time sessions, =
like
voice and keep all the other interesting peering like SIMPLE etc which =
Henry
was talking about on another thread in scope as well. I am wondering if =
things
like TRIP/TGREP have been considered as well (or modifications =
thereof).<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>-Medhavi.<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C62D9B.CBE55CE8--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============0820942777==--




From speermint-bounces@ietf.org Thu Feb 09 13:59:00 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F7H0O-0007W2-Ev; Thu, 09 Feb 2006 13:59:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F7H0I-0007SM-4a
	for speermint@megatron.ietf.org; Thu, 09 Feb 2006 13:58:58 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20875
	for <speermint@ietf.org>; Thu, 9 Feb 2006 13:57:04 -0500 (EST)
Received: from m106.maoz.com ([205.167.76.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7HCz-0003JZ-PO
	for speermint@ietf.org; Thu, 09 Feb 2006 14:12:03 -0500
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])
	by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k19IwWh6032262;
	Thu, 9 Feb 2006 10:58:32 -0800
Received: (from dmm@localhost)
	by m106.maoz.com (8.13.4/8.12.11/Submit) id k19IwW8r032261;
	Thu, 9 Feb 2006 10:58:32 -0800
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using
	-f
Date: Thu, 9 Feb 2006 10:58:32 -0800
From: David Meyer <dmm@1-4-5.net>
To: Medhavi Bhatia <mbhatia@nextone.com>
Subject: Re: [Speermint] Some clarifications
Message-ID: <20060209185832.GA32207@1-4-5.net>
References: <F1F8A60D618B704195CE0515A25E46060106CB@moe.nextone.local>
Mime-Version: 1.0
In-Reply-To: <F1F8A60D618B704195CE0515A25E46060106CB@moe.nextone.local>
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader,
	Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2083041214=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org


--===============2083041214==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24"
Content-Disposition: inline


--u3/rZRmxL6MmkK24
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

	Medhavi,

On Thu, Feb 09, 2006 at 12:08:53PM -0500, Medhavi Bhatia wrote:
> I was going through some web archives for what I have seen so far on
> this list and was just trying to put together what is on the table along
> with some comments I might have:
>=20
> =20
>=20
> In terms of drafts, it seems that the following drafts (even though they
> are not WG docs) are under consideration:
>=20
> =20
>=20
> http://www.ietf.org/internet-drafts/draft-lendl-sip-peering-policy-00.tx
> t
>=20
> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-meyer-voipeer-te
> rminology-01.txt
>=20
> =20
>=20
> Am I accurate making this assumption?

	Yes, we will be dicussing these in Dallas. We're hoping
	to have a few more to discuss, but that hasn't firmed up
	yet.=20

> Also, seems like the first goal is to tackle real time sessions, like
> voice and keep all the other interesting peering like SIMPLE etc which
> Henry was talking about on another thread in scope as well.

	Correct.

> I am wondering if things like TRIP/TGREP have been considered
> as well (or modifications thereof).

	While I'm not really sure what you are asking here, it is
	certainly the case that if we wind up with use cases that
	require TRIP, for example, then yes.

	Dave & Jason

--u3/rZRmxL6MmkK24
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFD65DYORgD1qCZ2KcRAmiTAJ9pArloQX5CX3OBXQF8kfrgDdO5sQCeN6a8
6BRHKD2Uh4KXHiUfTR6CO2Q=
=4M/T
-----END PGP SIGNATURE-----

--u3/rZRmxL6MmkK24--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============2083041214==--




From speermint-bounces@ietf.org Thu Feb 09 14:35:21 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F7HZZ-00067s-LW; Thu, 09 Feb 2006 14:35:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F7HZY-00065f-H3
	for speermint@megatron.ietf.org; Thu, 09 Feb 2006 14:35:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23360
	for <speermint@ietf.org>; Thu, 9 Feb 2006 14:33:34 -0500 (EST)
Received: from mail2.nextone.com ([209.125.86.105])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7HmJ-0004X4-GV
	for speermint@ietf.org; Thu, 09 Feb 2006 14:48:34 -0500
Received: from moe.nextone.local ([192.168.15.38]) by mail2.nextone.com with
	Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Feb 2006 14:35:11 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] Some clarifications
Date: Thu, 9 Feb 2006 14:35:11 -0500
Message-ID: <F1F8A60D618B704195CE0515A25E46060107A2@moe.nextone.local>
Thread-Topic: [Speermint] Some clarifications
Thread-Index: AcYtqyWoxkHT8NLqRZ6unvyi2LNUpQABBnmQ
From: "Medhavi Bhatia" <mbhatia@nextone.com>
To: "David Meyer" <dmm@1-4-5.net>
X-OriginalArrivalTime: 09 Feb 2006 19:35:12.0049 (UTC)
	FILETIME=[F17A5210:01C62DAF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: quoted-printable
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

>=20
> > I am wondering if things like TRIP/TGREP have been considered
> > as well (or modifications thereof).
>=20
> 	While I'm not really sure what you are asking here, it is
> 	certainly the case that if we wind up with use cases that
> 	require TRIP, for example, then yes.
>

I think besides peer policy which may be mostly static, there are more
dynamic reasons why calls may be rejected, for example capacity and
bandwidth limitations which change at runtime. Sometimes routes may also
change fast enough that a more realtime solution than DNS may be
desirable. Since the priority#1 is E.164/VoIP peering, TRIP came to my
mind and I want to hear from people on the list as to what they think
about it.

-Medhavi.
=20
> 	Dave & Jason

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Thu Feb 09 15:00:43 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F7Hy7-0008AM-GD; Thu, 09 Feb 2006 15:00:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Hy4-0007xq-TN
	for speermint@megatron.ietf.org; Thu, 09 Feb 2006 15:00:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25221
	for <speermint@ietf.org>; Thu, 9 Feb 2006 14:58:47 -0500 (EST)
Received: from h139-142-184-176.roothosts.com ([139.142.184.176]
	helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F7IAk-0005Og-My
	for speermint@ietf.org; Thu, 09 Feb 2006 15:13:48 -0500
Received: from [192.168.1.101] (cpe-24-95-54-117.columbus.res.rr.com
	[24.95.54.117])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified))
	by wodka.aus-biz.com (Postfix) with ESMTP id C625EF768;
	Thu,  9 Feb 2006 15:00:02 -0500 (EST)
Message-ID: <43EB9F40.1000907@e164.org>
Date: Thu, 09 Feb 2006 15:00:00 -0500
From: Duane <duane@e164.org>
User-Agent: Mail/News 1.5 (X11/20060119)
MIME-Version: 1.0
To: Medhavi Bhatia <mbhatia@nextone.com>
Subject: Re: [Speermint] Some clarifications
References: <F1F8A60D618B704195CE0515A25E46060107A2@moe.nextone.local>
In-Reply-To: <F1F8A60D618B704195CE0515A25E46060107A2@moe.nextone.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Medhavi Bhatia wrote:
>>> I am wondering if things like TRIP/TGREP have been considered
>>> as well (or modifications thereof).
>> 	While I'm not really sure what you are asking here, it is
>> 	certainly the case that if we wind up with use cases that
>> 	require TRIP, for example, then yes.
>>
> 
> I think besides peer policy which may be mostly static, there are more
> dynamic reasons why calls may be rejected, for example capacity and
> bandwidth limitations which change at runtime. Sometimes routes may also
> change fast enough that a more realtime solution than DNS may be
> desirable. Since the priority#1 is E.164/VoIP peering, TRIP came to my
> mind and I want to hear from people on the list as to what they think
> about it.

Aren't such notifications already built-in into existing protocols such 
as SIP?

-- 

Best regards,
  Duane

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Thu Feb 09 15:12:32 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F7I9Y-0004vu-Q8; Thu, 09 Feb 2006 15:12:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F7I9T-0004u5-OW
	for speermint@megatron.ietf.org; Thu, 09 Feb 2006 15:12:31 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25949
	for <speermint@ietf.org>; Thu, 9 Feb 2006 15:10:13 -0500 (EST)
Received: from mail1.nextone.com ([209.125.86.104])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7ILo-0005jU-BQ
	for speermint@ietf.org; Thu, 09 Feb 2006 15:25:13 -0500
Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with
	Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Feb 2006 15:11:50 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] Some clarifications
Date: Thu, 9 Feb 2006 15:11:50 -0500
Message-ID: <F1F8A60D618B704195CE0515A25E46060107E0@moe.nextone.local>
Thread-Topic: [Speermint] Some clarifications
Thread-Index: AcYts7ZhQwbv/R/IQTeZB5XQphoY+AAAIrzg
From: "Medhavi Bhatia" <mbhatia@nextone.com>
To: "Duane" <duane@e164.org>
X-OriginalArrivalTime: 09 Feb 2006 20:11:50.0984 (UTC)
	FILETIME=[10252C80:01C62DB5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Content-Transfer-Encoding: quoted-printable
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Hi Duane,


> Medhavi Bhatia wrote:
> >>> I am wondering if things like TRIP/TGREP have been considered
> >>> as well (or modifications thereof).
> >> 	While I'm not really sure what you are asking here, it is
> >> 	certainly the case that if we wind up with use cases that
> >> 	require TRIP, for example, then yes.
> >>
> >
> > I think besides peer policy which may be mostly static, there are
more
> > dynamic reasons why calls may be rejected, for example capacity and
> > bandwidth limitations which change at runtime. Sometimes routes may
also
> > change fast enough that a more realtime solution than DNS may be
> > desirable. Since the priority#1 is E.164/VoIP peering, TRIP came to
my
> > mind and I want to hear from people on the list as to what they
think
> > about it.
>=20
> Aren't such notifications already built-in into existing protocols
such
> as SIP?

I am not aware of any. There are two use cases:

Routing: TRIP can provide more realtime information on Routing. I think
ENUM has significant advantages as well and maybe a combined approach
can be devised

Bandwidth/Capacity etc: I don't know of any notifications built into SIP
at this point, but I remember TGREP being used to advertise some of this
information to peers. I don't think an ENUM based solution is elegant.

Cheers,
-Medhavi.=20



>=20
> --
>=20
> Best regards,
>   Duane

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Thu Feb 09 15:39:47 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F7IZv-0006k8-S9; Thu, 09 Feb 2006 15:39:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F7IZt-0006iG-3f
	for speermint@megatron.ietf.org; Thu, 09 Feb 2006 15:39:47 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27961
	for <speermint@ietf.org>; Thu, 9 Feb 2006 15:37:44 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F7ImQ-0006as-NV
	for speermint@ietf.org; Thu, 09 Feb 2006 15:52:45 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Speermint] Some clarifications
Date: Thu, 9 Feb 2006 21:43:00 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C483E@oefeg-s04.oefeg.loc>
Thread-Topic: [Speermint] Some clarifications
Thread-Index: AcYtqyWoxkHT8NLqRZ6unvyi2LNUpQABBnmQAAI9LIA=
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Medhavi Bhatia" <mbhatia@nextone.com>, "David Meyer" <dmm@1-4-5.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: quoted-printable
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

>I think besides peer policy which may be mostly static, there are more
>dynamic reasons why calls may be rejected, for example capacity and
>bandwidth limitations which change at runtime. Sometimes routes may =
also
>change fast enough that a more realtime solution than DNS may be
>desirable. Since the priority#1 is E.164/VoIP peering, TRIP came to my
>mind and I want to hear from people on the list as to what they think
>about it.
=20
>From the charter:
"Note that the term "peering" is used here to refer to
the interconnection between application layer entities such as
SIP servers, as opposed to interconnection at the IP network
layer. However, in order to achieve real-time Session PEERing,
both signaling and media flows must be taken into
consideration."
=20
capacity and bandwidth limitations, fast route changes, etc are =
therefore=20
within the scope of SPEERMINT, but I also read this text that first
priority is the signalling on the application layer, and here fast
route changes do not apply.
=20
IMHO SPEERMINT should first concentrate on the basics, enabling
peering at the application layer, and if this is implemented and works,
we may move forward to the issues you mentioned.
=20
regards
Richard
=20

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Thu Feb 09 15:52:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F7Im9-0002af-JI; Thu, 09 Feb 2006 15:52:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Im8-0002aT-OT
	for speermint@megatron.ietf.org; Thu, 09 Feb 2006 15:52:24 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29036
	for <speermint@ietf.org>; Thu, 9 Feb 2006 15:50:41 -0500 (EST)
Received: from mail124.messagelabs.com ([85.158.136.19])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F7Iyw-0007AR-Eh
	for speermint@ietf.org; Thu, 09 Feb 2006 16:05:42 -0500
X-VirusChecked: Checked
X-Env-Sender: ppfautz@att.com
X-Msg-Ref: server-5.tower-124.messagelabs.com!1139518284!7010852!7
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 17633 invoked from network); 9 Feb 2006 20:51:58 -0000
Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4)
	by server-5.tower-124.messagelabs.com with SMTP;
	9 Feb 2006 20:51:58 -0000
Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by
	attrh2i.attrh.att.com (7.2.052)
	id 43CF03750034C6BE; Thu, 9 Feb 2006 15:51:58 -0500
Content-class: urn:content-classes:message
Subject: RE: [Speermint] Some clarifications
Date: Thu, 9 Feb 2006 15:51:57 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Message-ID: <34DA635B184A644DA4588E260EC0A25A0C1FBBFC@ACCLUST02EVS1.ugd.att.com>
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Thread-Topic: [Speermint] Some clarifications
Thread-Index: AcYts7ZhQwbv/R/IQTeZB5XQphoY+AAAIrzgAAECszA=
From: "Pfautz, Penn L, NEO" <ppfautz@att.com>
To: "Medhavi Bhatia" <mbhatia@nextone.com>, "Duane" <duane@e164.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Content-Transfer-Encoding: quoted-printable
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Re
>> I don't think an ENUM based solution is elegant.

I'd beg to differ. TRIP and TGREP are essentially
code(number-prefix)-based solutions. They don't scale well with number
portability unless you keep a separate NP database around (which carrier
ENUM will eventually allow you to dispense with) They don't really
reflect carrier-of-record relationships but just who has a route
(usually a gateway). So long-term, do they really make sense when
delivery to PSTN gateways is not the modal scenario?
 I think of layer 3 peering as generally delivering traffic to the SP
whose customer the traffic is destined for. TRIP isn't really oriented
to that.

So, while TRIP/TGREG have an aesthetically pleasing symmetry with IP
routing protocols I don't think they're the wave of the future.

Penn Pfautz

-----Original Message-----
From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On
Behalf Of Medhavi Bhatia
Sent: Thursday, February 09, 2006 3:12 PM
To: Duane
Cc: speermint@ietf.org
Subject: RE: [Speermint] Some clarifications

Hi Duane,


> Medhavi Bhatia wrote:
> >>> I am wondering if things like TRIP/TGREP have been considered
> >>> as well (or modifications thereof).
> >> 	While I'm not really sure what you are asking here, it is
> >> 	certainly the case that if we wind up with use cases that
> >> 	require TRIP, for example, then yes.
> >>
> >
> > I think besides peer policy which may be mostly static, there are
more
> > dynamic reasons why calls may be rejected, for example capacity and
> > bandwidth limitations which change at runtime. Sometimes routes may
also
> > change fast enough that a more realtime solution than DNS may be
> > desirable. Since the priority#1 is E.164/VoIP peering, TRIP came to
my
> > mind and I want to hear from people on the list as to what they
think
> > about it.
>=20
> Aren't such notifications already built-in into existing protocols
such
> as SIP?

I am not aware of any. There are two use cases:

Routing: TRIP can provide more realtime information on Routing. I think
ENUM has significant advantages as well and maybe a combined approach
can be devised

Bandwidth/Capacity etc: I don't know of any notifications built into SIP
at this point, but I remember TGREP being used to advertise some of this
information to peers.=20

Cheers,
-Medhavi.=20



>=20
> --
>=20
> Best regards,
>   Duane

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Thu Feb 09 16:03:51 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F7IxC-0005JH-PU; Thu, 09 Feb 2006 16:03:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Ix5-0005Ig-U4
	for speermint@megatron.ietf.org; Thu, 09 Feb 2006 16:03:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01052
	for <speermint@ietf.org>; Thu, 9 Feb 2006 16:02:00 -0500 (EST)
Received: from h139-142-184-176.roothosts.com ([139.142.184.176]
	helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F7J9w-0007xW-Nq
	for speermint@ietf.org; Thu, 09 Feb 2006 16:17:02 -0500
Received: from [192.168.1.101] (cpe-24-95-54-117.columbus.res.rr.com
	[24.95.54.117])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified))
	by wodka.aus-biz.com (Postfix) with ESMTP id 8822FF79D;
	Thu,  9 Feb 2006 16:03:27 -0500 (EST)
Message-ID: <43EBAE1E.9040406@e164.org>
Date: Thu, 09 Feb 2006 16:03:26 -0500
From: Duane <duane@e164.org>
User-Agent: Mail/News 1.5 (X11/20060119)
MIME-Version: 1.0
To: Medhavi Bhatia <mbhatia@nextone.com>
Subject: Re: [Speermint] Some clarifications
References: <F1F8A60D618B704195CE0515A25E46060107E0@moe.nextone.local>
In-Reply-To: <F1F8A60D618B704195CE0515A25E46060107E0@moe.nextone.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Medhavi Bhatia wrote:

> I am not aware of any. There are two use cases:
> 
> Routing: TRIP can provide more realtime information on Routing. I think
> ENUM has significant advantages as well and maybe a combined approach
> can be devised
> 
> Bandwidth/Capacity etc: I don't know of any notifications built into SIP
> at this point, but I remember TGREP being used to advertise some of this
> information to peers. I don't think an ENUM based solution is elegant.

Perhaps I'm thinking of discussions over SER or Asterisk where there was 
discussions on modules that check loads and other system resources and 
return temp failures if anything exceeds to force traffic to take other 
routes.

-- 

Best regards,
  Duane

http://www.cacert.org - Free Security Certificates
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://e164.org - Using Enum.164 to interconnect asterisk servers

"In the long run the pessimist may be proved right,
     but the optimist has a better time on the trip."

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Fri Feb 10 10:10:14 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F7ZuY-0006qo-H0; Fri, 10 Feb 2006 10:10:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F7ZuX-0006oc-LA
	for speermint@megatron.ietf.org; Fri, 10 Feb 2006 10:10:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26548
	for <speermint@ietf.org>; Fri, 10 Feb 2006 10:08:30 -0500 (EST)
Received: from m106.maoz.com ([205.167.76.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7a7X-0003tA-Re
	for speermint@ietf.org; Fri, 10 Feb 2006 10:23:41 -0500
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])
	by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k1AFA0H8030812
	for <speermint@ietf.org>; Fri, 10 Feb 2006 07:10:00 -0800
Received: (from dmm@localhost)
	by m106.maoz.com (8.13.4/8.12.11/Submit) id k1AFA03F030811
	for speermint@ietf.org; Fri, 10 Feb 2006 07:10:00 -0800
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using
	-f
Date: Fri, 10 Feb 2006 07:10:00 -0800
From: David Meyer <dmm@1-4-5.net>
To: speermint@ietf.org
Message-ID: <20060210151000.GA30804@1-4-5.net>
Mime-Version: 1.0
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader,
	Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Subject: [Speermint] FYI -- [ietf-secretariat@ietf.org: Internet-Drafts
	Submission Cutoff Dates for the 65th IETF Meeting in Dallas,
	TX, USA]
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1002313941=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org


--===============1002313941==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj"
Content-Disposition: inline


--9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

----- Forwarded message from ietf-secretariat@ietf.org -----

> From: ietf-secretariat@ietf.org
> To: ietf-announce@ietf.org
> Subject: Internet-Drafts Submission Cutoff Dates for the 65th IETF Meeting
>  in Dallas, TX, USA=20
> Date: Fri, 10 Feb 2006 00:00:01 -0500
>=20
>=20
> There are two (2) Internet-Draft cutoff dates for the 65th=20
> IETF Meeting in Dallas, TX, USA:
>=20
> February 27th: Cutoff Date for Initial (i.e., version -00)=20
> Internet-Draft Submissions=20
>=20
> All initial Internet-Drafts (version -00) must be submitted by Monday,=20
> February 27th at 9:00 AM ET. As always, all initial submissions with a=20
> filename beginning with "draft-ietf" must be approved by the=20
> appropriate WG Chair before they can be processed or announced.  The=20
> Secretariat would appreciate receiving WG Chair approval by Monday,=20
> February 20th at 9:00 AM ET.
>=20
> March 6th: Cutoff Date for Revised (i.e., version -01 and higher)=20
> Internet-Draft Submissions=20
>=20
> All revised Internet-Drafts (version -01 and higher) must be submitted=20
> by Monday, March 6th at 9:00 AM ET.
>=20
> Initial and revised Internet-Drafts received after their respective=20
> cutoff dates will not be made available in the Internet-Drafts=20
> directory or announced until on or after Monday, March 20th at 9:00=20
> AM ET, when Internet-Draft posting resumes.  Please do not wait until=20
> the last minute to submit.
>=20
> Thank you for your understanding and cooperation. If you have any=20
> questions or concerns, then please send a message to=20
> internet-drafts@ietf.org.
>=20
> The IETF Secretariat
>=20
> FYI: The Internet-Draft cutoff dates as well as other significant dates
> for the 65th IETF Meeting can be found at http://www.ietf.org/meetings/cu=
toff_dates_65.html.
>=20
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce

----- End forwarded message -----

--9amGYk9869ThD9tj
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFD7KzIORgD1qCZ2KcRAn68AJ40dvQO6q6Sr1f19Oki6g/pio9WBgCgg1Jq
g4tBmwk6FVGtaZk9DgODQIo=
=JLIa
-----END PGP SIGNATURE-----

--9amGYk9869ThD9tj--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============1002313941==--




From speermint-bounces@ietf.org Fri Feb 10 10:33:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F7aH2-00060K-Gl; Fri, 10 Feb 2006 10:33:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F7aH1-0005zJ-Ai
	for speermint@megatron.ietf.org; Fri, 10 Feb 2006 10:33:27 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28318
	for <speermint@ietf.org>; Fri, 10 Feb 2006 10:31:35 -0500 (EST)
Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]
	helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F7aTu-0004cg-3i
	for speermint@ietf.org; Fri, 10 Feb 2006 10:46:47 -0500
Received: from ([10.20.62.13])
	by paoakoavas09.cable.comcast.com with ESMTP  id KP-TDCH7.16966899;
	Fri, 10 Feb 2006 10:32:25 -0500
Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by
	PACDCEXCRLY01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Fri, 10 Feb 2006 10:32:25 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 10 Feb 2006 10:32:24 -0500
Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A1EC@PACDCEXCMB01.cable.comcast.com>
Thread-Topic: wg-business: Call for IETF 65 Agenda Items
Thread-Index: AcYuVzDueBeIXn7ARwKNsvLbjhodcg==
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: <speermint@ietf.org>
X-OriginalArrivalTime: 10 Feb 2006 15:32:25.0598 (UTC)
	FILETIME=[319C09E0:01C62E57]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: [Speermint] wg-business: Call for IETF 65 Agenda Items
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Hello -

We have requested a 2 hour meeting slot at IETF 65.  We are currently
working on a draft agenda to send the list.  If you would like to
propose an item for the agenda, please email Dave and I privately for
consideration by 5pm EST of next Tuesday, 14 February.  We aiming to get
a draft agenda out to the group by Friday of next week.=20
=20
Dave & Jason

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Fri Feb 10 10:52:13 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F7aZB-000712-4E; Fri, 10 Feb 2006 10:52:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F7aZ9-0006z6-IQ
	for speermint@megatron.ietf.org; Fri, 10 Feb 2006 10:52:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00853
	for <speermint@ietf.org>; Fri, 10 Feb 2006 10:50:21 -0500 (EST)
Received: from [193.80.224.123] (helo=kahua.nona.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7am3-0005dV-CV
	for speermint@ietf.org; Fri, 10 Feb 2006 11:05:32 -0500
Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3])
	(AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
	by pahula with esmtp; Fri, 10 Feb 2006 16:51:46 +0100
	id 0006C0B9.43ECB694.000013B5
Message-ID: <43ECB67E.9020900@enum.at>
Date: Fri, 10 Feb 2006 16:51:26 +0100
From: Alexander Mayrhofer <alexander.mayrhofer@enum.at>
Organization: enum.at GmbH
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
Subject: Re: [Speermint] wg-business: Call for IETF 65 Agenda Items
References: <6EEEACD9D7F52940BEE26F5467C02C7302A3A1EC@PACDCEXCMB01.cable.comcast.com>
In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7302A3A1EC@PACDCEXCMB01.cable.comcast.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: speermint@ietf.org, Otmar Lendl <otmar.lendl@enum.at>
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Livingood, Jason wrote:
> Hello -
> 
> We have requested a 2 hour meeting slot at IETF 65.  We are currently
> working on a draft agenda to send the list.  If you would like to
> propose an item for the agenda, please email Dave and I privately for
> consideration by 5pm EST of next Tuesday, 14 February.  We aiming to get
> a draft agenda out to the group by Friday of next week. 

Jason,
David,

I'd like to request a slot of ~20min for the presentation of:

draft-lendl-sip-peering-policy-00

This documents proposes the use of DNS entries to publish a SIP
proxy's policy for accepting incoming calls.  Such published policies
can be used to selectively establish peering relationships between
VoIP service providers.

This draft will most likely be replaced by a set of document before dallas, 
so the agenda should probably mention the upcoming replacement as well:

draft-lendl-domain-policy-ddds-00.txt

A preliminary abstract of this doc is:

This document proposes the use of the DNS to publish a domain's
policy regarding incoming communication. The algorithm used is
defined as a new application of the Dynamic Delegation Discovery
Protocol (DDDS). Such policy announcements can be used to facilitate
selective SIP peering.

We're unsure if 20 minutes will suffice (give us 30, if available), since we 
expect to have a lively discussion about this topic.

I will do proxy for Otmar (hoping that SPEERMINT does not collide with ENUM, 
which would be very bad karma anyways ;) since he can't be in Dallas.

cheers

Alex

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 13 13:24:16 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F8iMy-0000cx-U3; Mon, 13 Feb 2006 13:24:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F8iMx-0000cp-A6
	for speermint@megatron.ietf.org; Mon, 13 Feb 2006 13:24:15 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12897
	for <speermint@ietf.org>; Mon, 13 Feb 2006 13:22:29 -0500 (EST)
Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]
	helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F8iaY-0001Fa-Ed
	for speermint@ietf.org; Mon, 13 Feb 2006 13:38:22 -0500
Received: from ([10.52.116.30])
	by paoakoavas09.cable.comcast.com with ESMTP  id KP-TDCH7.17017696;
	Mon, 13 Feb 2006 13:23:44 -0500
Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by
	PAOAKEXCSMTP01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 13:23:43 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 13 Feb 2006 13:23:43 -0500
Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A232@PACDCEXCMB01.cable.comcast.com>
Thread-Topic: wg hum? SPEERMINT Requirements and Terminology Draft
Thread-Index: AcYwyp6mPCxD+lizQSSNpI4a4XXocg==
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: <speermint@ietf.org>
X-OriginalArrivalTime: 13 Feb 2006 18:23:43.0975 (UTC)
	FILETIME=[9F3D2770:01C630CA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: quoted-printable
Subject: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Last week the I-D editor posted David Meyer's "SPEERMINT Requirements
and Terminology" draft.  This draft has been updated recently and is the
result of the 2 BOFs and much list discussion.  Rather than assume that
we should make this an official working group, I'd like to ask for a
"hum" on the list.  So please post if you agree to make this a WG item.
If the list approves, we'll make this our first official WG I-D and
rename it appropriately (it will remain a -00 draft) in advance of the
Dallas meeting.
=20
http://www.ietf.org/internet-drafts/draft-meyer-speermint-reqs-and-termi
nology-00.txt
                 SPEERMINT Requirements and Terminology
           draft-meyer-speermint-reqs-and-terminology-00.txt

Abstract

   This document outlines the solutions space requirements and defines
   the terminology that is to be used by the Session PEERing for
   Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
   primary objective to focus the working group during its discussions,
   and when writing requirements, gap analysis and other solutions
   oriented documents.

=20
Regards
Jason

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 13 13:52:12 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F8io0-0001B7-ME; Mon, 13 Feb 2006 13:52:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F8inz-0001Az-Ox
	for speermint@megatron.ietf.org; Mon, 13 Feb 2006 13:52:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14777
	for <speermint@ietf.org>; Mon, 13 Feb 2006 13:50:25 -0500 (EST)
Received: from sb7.songbird.com ([208.184.79.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8j1e-00026h-4j
	for speermint@ietf.org; Mon, 13 Feb 2006 14:06:19 -0500
Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net
	[68.165.240.35]) (authenticated bits=0)
	by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1DIqSCa011803
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 13 Feb 2006 10:52:29 -0800
Message-ID: <43F0D54A.6060501@shockey.us>
Date: Mon, 13 Feb 2006 13:51:54 -0500
From: Richard Shockey <richard@shockey.us>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
Subject: Re: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft
References: <6EEEACD9D7F52940BEE26F5467C02C7302A3A232@PACDCEXCMB01.cable.comcast.com>
In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7302A3A232@PACDCEXCMB01.cable.comcast.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Found to be clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Livingood, Jason wrote:
> Last week the I-D editor posted David Meyer's "SPEERMINT Requirements
> and Terminology" draft.  This draft has been updated recently and is the
> result of the 2 BOFs and much list discussion.  Rather than assume that
> we should make this an official working group, I'd like to ask for a
> "hum" on the list.  So please post if you agree to make this a WG item.
> If the list approves, we'll make this our first official WG I-D and
> rename it appropriately (it will remain a -00 draft) in advance of the
> Dallas meeting.


Hummmm.. This should definitely be a WG item now! Per my previous post.


>  
> http://www.ietf.org/internet-drafts/draft-meyer-speermint-reqs-and-termi
> nology-00.txt
>                  SPEERMINT Requirements and Terminology
>            draft-meyer-speermint-reqs-and-terminology-00.txt
> 
> Abstract
> 
>    This document outlines the solutions space requirements and defines
>    the terminology that is to be used by the Session PEERing for
>    Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
>    primary objective to focus the working group during its discussions,
>    and when writing requirements, gap analysis and other solutions
>    oriented documents.
> 
>  
> Regards
> Jason
> 
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
> 


-- 


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 13 16:30:54 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F8lHa-0005b5-Mn; Mon, 13 Feb 2006 16:30:54 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F8lHY-0005XZ-2N
	for speermint@megatron.ietf.org; Mon, 13 Feb 2006 16:30:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24977
	for <speermint@ietf.org>; Mon, 13 Feb 2006 16:29:07 -0500 (EST)
Message-Id: <200602132129.QAA24977@ietf.org>
Received: from mail.pulver.com ([192.246.69.184])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8lVA-0006fD-Rx
	for speermint@ietf.org; Mon, 13 Feb 2006 16:45:01 -0500
Received: (qmail 30820 invoked by uid 510); 13 Feb 2006 16:57:48 -0500
Received: from henry@pulver.com by mail.pulver.com by uid 508 with
	qmail-scanner-1.22-st-qms 
	(clamdscan: 0.72. spamassassin: 2.63.  Clear:RC:1(24.1.142.176):. 
	Processed in 1.859594 secs); 13 Feb 2006 21:57:48 -0000
X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com
X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.142.176):. Processed in
	1.859594 secs Process 30815)
Received: from c-24-1-142-176.hsd1.tx.comcast.net (HELO 1AB764895C324D3)
	(henry@pulver.com@24.1.142.176)
	by 192.246.69.184 with SMTP; Mon, 13 Feb 2006 21:57:46 +0000
From: "Henry Sinnreich" <henry@pulver.com>
To: "'Livingood, Jason'" <Jason_Livingood@cable.comcast.com>,
	<speermint@ietf.org>
Subject: RE: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft
Date: Mon, 13 Feb 2006 15:30:42 -0600
Organization: pulver.com
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcYwyp6mPCxD+lizQSSNpI4a4XXocgAGPUjg
In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7302A3A232@PACDCEXCMB01.cable.comcast.com>
X-Antivirus-MYDOMAIN-Message-ID: <113986786683530815@mail.pulver.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: 7bit
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: henry@pulver.com
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

YES

Thanks, Henry
 

-----Original Message-----
From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On
Behalf Of Livingood, Jason
Sent: Monday, February 13, 2006 12:24 PM
To: speermint@ietf.org
Subject: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft

Last week the I-D editor posted David Meyer's "SPEERMINT Requirements
and Terminology" draft.  This draft has been updated recently and is the
result of the 2 BOFs and much list discussion.  Rather than assume that
we should make this an official working group, I'd like to ask for a
"hum" on the list.  So please post if you agree to make this a WG item.
If the list approves, we'll make this our first official WG I-D and
rename it appropriately (it will remain a -00 draft) in advance of the
Dallas meeting.
 
http://www.ietf.org/internet-drafts/draft-meyer-speermint-reqs-and-termi
nology-00.txt
                 SPEERMINT Requirements and Terminology
           draft-meyer-speermint-reqs-and-terminology-00.txt

Abstract

   This document outlines the solutions space requirements and defines
   the terminology that is to be used by the Session PEERing for
   Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
   primary objective to focus the working group during its discussions,
   and when writing requirements, gap analysis and other solutions
   oriented documents.

 
Regards
Jason

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint




_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 13 16:58:37 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F8liO-00068F-Rn; Mon, 13 Feb 2006 16:58:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F8liM-00065R-Po
	for speermint@megatron.ietf.org; Mon, 13 Feb 2006 16:58:34 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26518
	for <speermint@ietf.org>; Mon, 13 Feb 2006 16:56:49 -0500 (EST)
Received: from paoakoavas10.cable.comcast.com ([208.17.35.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8lw2-0007Kq-Qs
	for speermint@ietf.org; Mon, 13 Feb 2006 17:12:44 -0500
Received: from ([10.20.9.172])
	by paoakoavas10.cable.comcast.com with ESMTP  id KP-TDCH3.16937373;
	Mon, 13 Feb 2006 16:57:51 -0500
Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by
	PACDCEXCSMTP01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 16:57:51 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 13 Feb 2006 16:57:50 -0500
Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A24A@PACDCEXCMB01.cable.comcast.com>
Thread-Topic: wg-business: Secretary Appointed
Thread-Index: AcYw6IifoYUkd95hQiC6cU4Nwspc5A==
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: <speermint@ietf.org>
X-OriginalArrivalTime: 13 Feb 2006 21:57:51.0673 (UTC)
	FILETIME=[89104A90:01C630E8]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: [Speermint] wg-business: Secretary Appointed
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Please welcome Alexander (Axel) Mayrhofer as Secretary of the speermint
working group. Axel has done a fine job in this role with the ENUM WG,
in which he will continue, and we now look forward to having him
contribute to speermint as well.

Regards,
Dave & Jason


_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 13 17:32:40 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F8mFM-000091-G3; Mon, 13 Feb 2006 17:32:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F8mFL-00008t-18
	for speermint@megatron.ietf.org; Mon, 13 Feb 2006 17:32:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28286
	for <speermint@ietf.org>; Mon, 13 Feb 2006 17:30:53 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F8mT1-0008AS-TD
	for speermint@ietf.org; Mon, 13 Feb 2006 17:46:48 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: Re: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 13 Feb 2006 23:36:10 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C484B@oefeg-s04.oefeg.loc>
Thread-Topic: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft
Thread-Index: AcYwyp6mPCxD+lizQSSNpI4a4XXocgAI0TG1
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	<speermint@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Hummm
Agree to make this a WG item
=20
Richard

________________________________

Von: speermint-bounces@ietf.org im Auftrag von Livingood, Jason
Gesendet: Mo 13.02.2006 19:23
An: speermint@ietf.org
Betreff: [Speermint] wg hum? SPEERMINT Requirements and Terminology =
Draft



Last week the I-D editor posted David Meyer's "SPEERMINT Requirements
and Terminology" draft.  This draft has been updated recently and is the
result of the 2 BOFs and much list discussion.  Rather than assume that
we should make this an official working group, I'd like to ask for a
"hum" on the list.  So please post if you agree to make this a WG item.
If the list approves, we'll make this our first official WG I-D and
rename it appropriately (it will remain a -00 draft) in advance of the
Dallas meeting.

http://www.ietf.org/internet-drafts/draft-meyer-speermint-reqs-and-termi
nology-00.txt
                 SPEERMINT Requirements and Terminology
           draft-meyer-speermint-reqs-and-terminology-00.txt

Abstract

   This document outlines the solutions space requirements and defines
   the terminology that is to be used by the Session PEERing for
   Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
   primary objective to focus the working group during its discussions,
   and when writing requirements, gap analysis and other solutions
   oriented documents.


Regards
Jason

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 13 18:29:25 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F8n8H-0002s9-CX; Mon, 13 Feb 2006 18:29:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F8n8F-0002pL-Gc
	for speermint@megatron.ietf.org; Mon, 13 Feb 2006 18:29:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01776
	for <speermint@ietf.org>; Mon, 13 Feb 2006 18:27:37 -0500 (EST)
Received: from smtpout.eastlink.ca ([24.222.0.30])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8nLm-0001Ju-FX
	for speermint@ietf.org; Mon, 13 Feb 2006 18:43:33 -0500
Received: from ip02.eastlink.ca ([24.222.10.10])
	by mta01.eastlink.ca (Sun Java System Messaging Server 6.2-4.03 (built
	Sep 22 2005)) with ESMTP id <0IUN00ADEFWYTHZ1@mta01.eastlink.ca> for
	speermint@ietf.org; Mon, 13 Feb 2006 19:29:22 -0400 (AST)
Received: from blk-222-143-44.eastlink.ca (HELO IBM-7B137D96EC3.ZDSL.com)
	([24.222.143.44]) by ip02.eastlink.ca with ESMTP; Mon,
	13 Feb 2006 19:29:02 -0400
Date: Mon, 13 Feb 2006 18:29:01 -0500
From: Peter Macaulay <peter.macaulay@ZDSL.com>
Subject: Re: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft
In-reply-to: <6EEEACD9D7F52940BEE26F5467C02C7302A3A232@PACDCEXCMB01.cabl
	e.comcast.com>
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>, speermint@ietf.org
Message-id: <7.0.0.16.2.20060213182809.04769240@ZDSL.com>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 (Beta)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAQAAA+k=
References: <6EEEACD9D7F52940BEE26F5467C02C7302A3A232@PACDCEXCMB01.cable.comcast.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7BIT
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Agree.  This should be a WG item.

/PETER MACAULAY

At 01:23 PM 2/13/2006, Livingood, Jason wrote:
>Last week the I-D editor posted David Meyer's "SPEERMINT Requirements
>and Terminology" draft.  This draft has been updated recently and is the
>result of the 2 BOFs and much list discussion.  Rather than assume that
>we should make this an official working group, I'd like to ask for a
>"hum" on the list.  So please post if you agree to make this a WG item.
>If the list approves, we'll make this our first official WG I-D and
>rename it appropriately (it will remain a -00 draft) in advance of the
>Dallas meeting.
>
>http://www.ietf.org/internet-drafts/draft-meyer-speermint-reqs-and-termi
>nology-00.txt
>                  SPEERMINT Requirements and Terminology
>            draft-meyer-speermint-reqs-and-terminology-00.txt
>
>Abstract
>
>    This document outlines the solutions space requirements and defines
>    the terminology that is to be used by the Session PEERing for
>    Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
>    primary objective to focus the working group during its discussions,
>    and when writing requirements, gap analysis and other solutions
>    oriented documents.
>
>
>Regards
>Jason
>
>_______________________________________________
>Speermint mailing list
>Speermint@ietf.org
>https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 14 02:38:40 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F8ulk-0001dq-AD; Tue, 14 Feb 2006 02:38:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F8ulg-0001dk-MU
	for speermint@megatron.ietf.org; Tue, 14 Feb 2006 02:38:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04067
	for <speermint@ietf.org>; Tue, 14 Feb 2006 02:36:50 -0500 (EST)
Received: from co300216-ier2.net.avaya.com ([198.152.13.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8uzO-00086y-Mz
	for speermint@ietf.org; Tue, 14 Feb 2006 02:52:51 -0500
Received: from tierw.net.avaya.com (h198-152-13-100.avaya.com [198.152.13.100])
	by co300216-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP
	id k1E6Z3Qt026953
	for <speermint@ietf.org>; Tue, 14 Feb 2006 01:35:03 -0500
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com
	[135.64.105.51])
	by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id
	k1E7MwYj004180
	for <speermint@ietf.org>; Tue, 14 Feb 2006 02:22:59 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft
Date: Tue, 14 Feb 2006 09:38:28 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A057D6E@is0004avexu1.global.avaya.com>
Thread-Topic: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft
Thread-Index: AcYwyp6mPCxD+lizQSSNpI4a4XXocgAbu3Aw
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	<speermint@ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Huuuuuummmmm indeed :-)

Regards,

Dan


=20
=20

> -----Original Message-----
> From: speermint-bounces@ietf.org=20
> [mailto:speermint-bounces@ietf.org] On Behalf Of Livingood, Jason
> Sent: Monday, February 13, 2006 8:24 PM
> To: speermint@ietf.org
> Subject: [Speermint] wg hum? SPEERMINT Requirements and=20
> Terminology Draft
>=20
> Last week the I-D editor posted David Meyer's "SPEERMINT=20
> Requirements and Terminology" draft.  This draft has been=20
> updated recently and is the result of the 2 BOFs and much=20
> list discussion.  Rather than assume that we should make this=20
> an official working group, I'd like to ask for a "hum" on the=20
> list.  So please post if you agree to make this a WG item.
> If the list approves, we'll make this our first official WG=20
> I-D and rename it appropriately (it will remain a -00 draft)=20
> in advance of the Dallas meeting.
> =20
> http://www.ietf.org/internet-drafts/draft-meyer-speermint-reqs
> -and-termi
> nology-00.txt
>                  SPEERMINT Requirements and Terminology
>            draft-meyer-speermint-reqs-and-terminology-00.txt
>=20
> Abstract
>=20
>    This document outlines the solutions space requirements and defines
>    the terminology that is to be used by the Session PEERing for
>    Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
>    primary objective to focus the working group during its=20
> discussions,
>    and when writing requirements, gap analysis and other solutions
>    oriented documents.
>=20
> =20
> Regards
> Jason
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
>=20

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 14 08:02:28 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F8zp6-0008Tt-AY; Tue, 14 Feb 2006 08:02:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F8zp4-0008TR-RB
	for speermint@megatron.ietf.org; Tue, 14 Feb 2006 08:02:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23146
	for <speermint@ietf.org>; Tue, 14 Feb 2006 08:00:38 -0500 (EST)
Received: from [193.80.224.123] (helo=kahua.nona.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F902Y-0000db-GM
	for speermint@ietf.org; Tue, 14 Feb 2006 08:16:42 -0500
Received: from [10.10.0.63] (nat.labs.nic.at [::ffff:83.136.33.3])
	(AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
	by pahula with esmtp; Tue, 14 Feb 2006 14:02:01 +0100
	id 0006C0B9.43F1D4C9.00006471
Message-ID: <43F1D4B1.8010403@enum.at>
Date: Tue, 14 Feb 2006 14:01:37 +0100
From: Alexander Mayrhofer <alexander.mayrhofer@enum.at>
Organization: enum.at GmbH
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
Subject: Re: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft
References: <6EEEACD9D7F52940BEE26F5467C02C7302A3A232@PACDCEXCMB01.cable.comcast.com>
In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7302A3A232@PACDCEXCMB01.cable.comcast.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7bit
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Livingood, Jason wrote:
> Last week the I-D editor posted David Meyer's "SPEERMINT Requirements
> and Terminology" draft.  This draft has been updated recently and is the
> result of the 2 BOFs and much list discussion.  Rather than assume that
> we should make this an official working group, I'd like to ask for a
> "hum" on the list.  So please post if you agree to make this a WG item.
> If the list approves, we'll make this our first official WG I-D and
> rename it appropriately (it will remain a -00 draft) in advance of the
> Dallas meeting.
>

hum - that should definitely be WG item.

cheers

alex

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 14 09:55:11 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F91aB-0003fH-2e; Tue, 14 Feb 2006 09:55:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F91a9-0003da-Ob
	for speermint@megatron.ietf.org; Tue, 14 Feb 2006 09:55:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02251
	for <speermint@ietf.org>; Tue, 14 Feb 2006 09:53:22 -0500 (EST)
Received: from zcars04f.nortelnetworks.com ([47.129.242.57]
	helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F91nz-0004Xd-AG
	for speermint@ietf.org; Tue, 14 Feb 2006 10:09:27 -0500
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com
	[47.129.230.95])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k1EEsv409974; Tue, 14 Feb 2006 09:54:57 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft
Date: Tue, 14 Feb 2006 09:54:49 -0500
Message-ID: <F1A1D21DA394814E824AC89F5A005BA30951876A@zcarhxm0.corp.nortel.com>
Thread-Topic: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft
Thread-Index: AcYwyp6mPCxD+lizQSSNpI4a4XXocgAowkOQ
From: "James McEachern" <jmce@nortel.com>
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	<speermint@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Agreed.  This should be a WG document.

Jim

-----Original Message-----
From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On =
Behalf Of Livingood, Jason
Sent: Monday, February 13, 2006 1:24 PM
To: speermint@ietf.org
Subject: [Speermint] wg hum? SPEERMINT Requirements and Terminology =
Draft

Last week the I-D editor posted David Meyer's "SPEERMINT Requirements
and Terminology" draft.  This draft has been updated recently and is the
result of the 2 BOFs and much list discussion.  Rather than assume that
we should make this an official working group, I'd like to ask for a
"hum" on the list.  So please post if you agree to make this a WG item.
If the list approves, we'll make this our first official WG I-D and
rename it appropriately (it will remain a -00 draft) in advance of the
Dallas meeting.
=20
http://www.ietf.org/internet-drafts/draft-meyer-speermint-reqs-and-termi
nology-00.txt
                 SPEERMINT Requirements and Terminology
           draft-meyer-speermint-reqs-and-terminology-00.txt

Abstract

   This document outlines the solutions space requirements and defines
   the terminology that is to be used by the Session PEERing for
   Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
   primary objective to focus the working group during its discussions,
   and when writing requirements, gap analysis and other solutions
   oriented documents.

=20
Regards
Jason

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint


_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 14 10:37:46 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F92FO-0003Fq-2f; Tue, 14 Feb 2006 10:37:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F92FM-0003Fl-FT
	for speermint@megatron.ietf.org; Tue, 14 Feb 2006 10:37:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05501
	for <speermint@ietf.org>; Tue, 14 Feb 2006 10:35:59 -0500 (EST)
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F92T8-00061K-Pc
	for speermint@ietf.org; Tue, 14 Feb 2006 10:52:03 -0500
X-IronPort-AV: i="4.02,114,1139202000"; 
	d="scan'208"; a="28238103:sNHT43954464"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft
Date: Tue, 14 Feb 2006 10:38:22 -0500
Message-ID: <330A23D8336C0346B5C1A5BB1966664701D7F508@ATLANTIS.Brooktrout.com>
Thread-Topic: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft
Thread-Index: AcYwyp6mPCxD+lizQSSNpI4a4XXocgAsddGw
From: "Rafferty, James" <jraff@brooktrout.com>
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	<speermint@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org


I agree that this should be a WG document. =20

James=20

-----Original Message-----
From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On
Behalf Of Livingood, Jason
Sent: Monday, February 13, 2006 1:24 PM
To: speermint@ietf.org
Subject: [Speermint] wg hum? SPEERMINT Requirements and Terminology
Draft

Last week the I-D editor posted David Meyer's "SPEERMINT Requirements
and Terminology" draft.  This draft has been updated recently and is the
result of the 2 BOFs and much list discussion.  Rather than assume that
we should make this an official working group, I'd like to ask for a
"hum" on the list.  So please post if you agree to make this a WG item.
If the list approves, we'll make this our first official WG I-D and
rename it appropriately (it will remain a -00 draft) in advance of the
Dallas meeting.
=20
http://www.ietf.org/internet-drafts/draft-meyer-speermint-reqs-and-termi
nology-00.txt
                 SPEERMINT Requirements and Terminology
           draft-meyer-speermint-reqs-and-terminology-00.txt

Abstract

   This document outlines the solutions space requirements and defines
   the terminology that is to be used by the Session PEERing for
   Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
   primary objective to focus the working group during its discussions,
   and when writing requirements, gap analysis and other solutions
   oriented documents.

=20
Regards
Jason

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 14 12:20:02 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F93qM-0006Km-Hm; Tue, 14 Feb 2006 12:20:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F93qL-0006KG-Am
	for speermint@megatron.ietf.org; Tue, 14 Feb 2006 12:20:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13069
	for <speermint@ietf.org>; Tue, 14 Feb 2006 12:18:15 -0500 (EST)
Received: from mail1.nextone.com ([209.125.86.104])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9448-0000tq-75
	for speermint@ietf.org; Tue, 14 Feb 2006 12:34:20 -0500
Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with
	Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Feb 2006 12:19:55 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft
Date: Tue, 14 Feb 2006 12:19:56 -0500
Message-ID: <F1F8A60D618B704195CE0515A25E46061151A0@moe.nextone.local>
Thread-Topic: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft
Thread-Index: AcYwyp6mPCxD+lizQSSNpI4a4XXocgAwCXng
From: "Bob Natale" <bnatale@nextone.com>
To: <speermint@ietf.org>
X-OriginalArrivalTime: 14 Feb 2006 17:19:55.0481 (UTC)
	FILETIME=[DFB11490:01C6318A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: quoted-printable
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Yes.

BobN

-----Original Message-----
From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On
Behalf Of Livingood, Jason
Sent: Monday, February 13, 2006 1:24 PM
To: speermint@ietf.org
Subject: [Speermint] wg hum? SPEERMINT Requirements and Terminology
Draft

Last week the I-D editor posted David Meyer's "SPEERMINT Requirements
and Terminology" draft.  This draft has been updated recently and is the
result of the 2 BOFs and much list discussion.  Rather than assume that
we should make this an official working group, I'd like to ask for a
"hum" on the list.  So please post if you agree to make this a WG item.
If the list approves, we'll make this our first official WG I-D and
rename it appropriately (it will remain a -00 draft) in advance of the
Dallas meeting.
=20
http://www.ietf.org/internet-drafts/draft-meyer-speermint-reqs-and-termi
nology-00.txt
                 SPEERMINT Requirements and Terminology
           draft-meyer-speermint-reqs-and-terminology-00.txt

Abstract

   This document outlines the solutions space requirements and defines
   the terminology that is to be used by the Session PEERing for
   Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
   primary objective to focus the working group during its discussions,
   and when writing requirements, gap analysis and other solutions
   oriented documents.

=20
Regards
Jason

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 14 13:03:57 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F94Wr-0005Ab-H3; Tue, 14 Feb 2006 13:03:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F94Wq-0005AW-CN
	for speermint@megatron.ietf.org; Tue, 14 Feb 2006 13:03:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16500
	for <speermint@ietf.org>; Tue, 14 Feb 2006 13:02:10 -0500 (EST)
Received: from m106.maoz.com ([205.167.76.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F94kg-0002TX-Uj
	for speermint@ietf.org; Tue, 14 Feb 2006 13:18:16 -0500
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])
	by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k1EI3jq3006461;
	Tue, 14 Feb 2006 10:03:45 -0800
Received: (from dmm@localhost)
	by m106.maoz.com (8.13.4/8.12.11/Submit) id k1EI3jX8006460;
	Tue, 14 Feb 2006 10:03:45 -0800
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using
	-f
Date: Tue, 14 Feb 2006 10:03:45 -0800
From: David Meyer <dmm@1-4-5.net>
To: Bob Natale <bnatale@nextone.com>
Subject: Re: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft
Message-ID: <20060214180345.GA6443@1-4-5.net>
References: <F1F8A60D618B704195CE0515A25E46061151A0@moe.nextone.local>
Mime-Version: 1.0
In-Reply-To: <F1F8A60D618B704195CE0515A25E46061151A0@moe.nextone.local>
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader,
	Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0665037307=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org


--===============0665037307==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR"
Content-Disposition: inline


--9jxsPFA5p3P2qPhR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

	Thanks Bob.=20

	BTW, I didn't do the s/VOIPEER/SPEERMINT/g=20

	I'll pick that up in -01.=20

	Thanks,

	Dave

On Tue, Feb 14, 2006 at 12:19:56PM -0500, Bob Natale wrote:
> Yes.
>=20
> BobN
>=20
> -----Original Message-----
> From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On
> Behalf Of Livingood, Jason
> Sent: Monday, February 13, 2006 1:24 PM
> To: speermint@ietf.org
> Subject: [Speermint] wg hum? SPEERMINT Requirements and Terminology
> Draft
>=20
> Last week the I-D editor posted David Meyer's "SPEERMINT Requirements
> and Terminology" draft.  This draft has been updated recently and is the
> result of the 2 BOFs and much list discussion.  Rather than assume that
> we should make this an official working group, I'd like to ask for a
> "hum" on the list.  So please post if you agree to make this a WG item.
> If the list approves, we'll make this our first official WG I-D and
> rename it appropriately (it will remain a -00 draft) in advance of the
> Dallas meeting.
> =20
> http://www.ietf.org/internet-drafts/draft-meyer-speermint-reqs-and-termi
> nology-00.txt
>                  SPEERMINT Requirements and Terminology
>            draft-meyer-speermint-reqs-and-terminology-00.txt
>=20
> Abstract
>=20
>    This document outlines the solutions space requirements and defines
>    the terminology that is to be used by the Session PEERing for
>    Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
>    primary objective to focus the working group during its discussions,
>    and when writing requirements, gap analysis and other solutions
>    oriented documents.
>=20
> =20
> Regards
> Jason
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint

--9jxsPFA5p3P2qPhR
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFD8huBORgD1qCZ2KcRAmJkAJwLk4B4Q6uj14O6jKbQUQM7GIbejgCfaEqp
wn8mH3V3HG8lVmtmNcGUffM=
=enqe
-----END PGP SIGNATURE-----

--9jxsPFA5p3P2qPhR--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============0665037307==--




From speermint-bounces@ietf.org Wed Feb 15 18:50:36 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F9WPs-0002RS-BL; Wed, 15 Feb 2006 18:50:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F9WPV-000268-Se; Wed, 15 Feb 2006 18:50:13 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18899;
	Wed, 15 Feb 2006 18:48:26 -0500 (EST)
Received: from pine.neustar.com ([209.173.57.70])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1F9Wda-0007aT-7D; Wed, 15 Feb 2006 19:04:48 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10])
	by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k1FNo1vP010596
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 15 Feb 2006 23:50:01 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1F9WPJ-0001UY-Eg; Wed, 15 Feb 2006 18:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1F9WPJ-0001UY-Eg@stiedprstage1.ietf.org>
Date: Wed, 15 Feb 2006 18:50:01 -0500
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: speermint@ietf.org
Subject: [Speermint] I-D
	ACTION:draft-ietf-speermint-reqs-and-terminology-00.txt 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

--NextPart

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


	Title		: SPEERMINT Requirements and Terminology

	Author(s)	: D. Meyer
	Filename	: draft-ietf-speermint-reqs-and-terminology-00.txt
	Pages		: 12
	Date		: 2006-2-15
	
   This document outlines the solutions space requirements and defines
   the terminology that is to be used by the Session PEERing for
   Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
   primary objective to focus the working group during its discussions,
   and when writing requirements, gap analysis and other solutions
   oriented documents.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-reqs-and-terminology-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-speermint-reqs-and-terminology-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-speermint-reqs-and-terminology-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-2-15153658.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-speermint-reqs-and-terminology-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-speermint-reqs-and-terminology-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-2-15153658.I-D@ietf.org>


--OtherAccess--

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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--NextPart--




From speermint-bounces@ietf.org Thu Feb 16 14:05:13 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1F9oRF-0003Vr-Cs; Thu, 16 Feb 2006 14:05:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1F9oRD-0003Ub-Q3
	for speermint@megatron.ietf.org; Thu, 16 Feb 2006 14:05:11 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22889
	for <speermint@ietf.org>; Thu, 16 Feb 2006 14:03:24 -0500 (EST)
Received: from paoakoavas10.cable.comcast.com ([208.17.35.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9ofU-0001Mh-9l
	for speermint@ietf.org; Thu, 16 Feb 2006 14:19:57 -0500
Received: from ([10.20.62.13])
	by paoakoavas10.cable.comcast.com with ESMTP  id KP-TDCH3.17024766;
	Thu, 16 Feb 2006 14:04:30 -0500
Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by
	PACDCEXCRLY01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Thu, 16 Feb 2006 14:04:30 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 16 Feb 2006 14:04:22 -0500
Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A2D2@PACDCEXCMB01.cable.comcast.com>
Thread-Topic: wg-business: Draft IETF 65 Agenda
Thread-Index: AcYuVzDueBeIXn7ARwKNsvLbjhodcgE1H20g
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: <speermint@ietf.org>
X-OriginalArrivalTime: 16 Feb 2006 19:04:30.0481 (UTC)
	FILETIME=[D0B59810:01C6332B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Content-Transfer-Encoding: quoted-printable
Cc: 
Subject: [Speermint] wg-business: Draft IETF 65 Agenda
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Here is a draft agenda.  We welcome any feedback.

Regards
Jason

Session PEERing for Multimedia INTerconnect (speermint)

*****DATE NEEDS TO BE UPDATED*****

DAY, Month XX, 2006 XXXX-XXXX (Morning Session I)=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

CHAIRS:	    David Meyer      	<dmm@1-4-5.net>
	    Jason Livingood  	<jason_livingood@cable.comcast.com>

SECRETARY:  Alexander Mayrhofer <alexander.mayrhofer@nic.at>

AGENDA

 o Welcome & Introduction to speermint / Administrivia	  5 minutes
     Dave Meyer

   - Mailing list: speermint-request@ietf.org
     subscribe

   - Scribe (jabber)
  =20
   - Blue Sheets

 o Agenda Bashing                                         	5
minutes
     Dave Meyer

 o Review of Milestones                                   	5
minutes
     Jason Livingood

 o Review and Status of Open Work Items                     =20

   New Drafts
   -------------
    1 - speermint Terminology Draft				15
minutes (TBD)
	  Dave Meyer

    2 - SIP Peering Policy Management
    	draft-lendl-sip-peering-policy-00			20
minutes (requested)
    	draft-lendl-domain-policy-ddds-00.txt
	  Otmar Lendl
	  Axel Mayrhofer

    3 - Media Session Authorization    				15
minutes (TBD)
    	draft-wing-session-auth-00
	  Dan Wing

    4 - I-D on the minimum set of requirements for 		15
minutes (TBD)
    	SIP-based VoIP interconnection (BCP)
    	draft-natale-sip-voip-requirements-00.txt           =20
     	  Bob Natale

    5 - Routing Architectures, Policy, and Message Flows	15
minutes (TBD)
	  Medhavi Bhatia

    6 - Address Resolution Scenarios (not confirmed)		15
minutes (TBD)
	  Matt Stafford

 o Open Discussion                                       	15
minutes


NOTES:=20
Times marked TBD are placeholders. =20
The exact duration of these presentations has not been finalized yet.
Times marked requested are as presenters have requested.
  =20
=20

> -----Original Message-----
> From: speermint-bounces@ietf.org=20
> [mailto:speermint-bounces@ietf.org] On Behalf Of Livingood, Jason
> Sent: Friday, February 10, 2006 10:32 AM
> To: speermint@ietf.org
> Subject: [Speermint] wg-business: Call for IETF 65 Agenda Items
>=20
> Hello -
>=20
> We have requested a 2 hour meeting slot at IETF 65.  We are=20
> currently working on a draft agenda to send the list.  If you=20
> would like to propose an item for the agenda, please email=20
> Dave and I privately for consideration by 5pm EST of next=20
> Tuesday, 14 February.  We aiming to get a draft agenda out to=20
> the group by Friday of next week.=20
> =20
> Dave & Jason
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
>=20

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Fri Feb 17 09:56:57 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1FA72X-0004td-Ru; Fri, 17 Feb 2006 09:56:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6vY-00017g-CQ
	for speermint@megatron.ietf.org; Fri, 17 Feb 2006 09:49:44 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06786
	for <speermint@ietf.org>; Fri, 17 Feb 2006 09:13:36 -0500 (EST)
Received: from paoakoavas10.cable.comcast.com ([208.17.35.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA6bw-00037J-R4
	for speermint@ietf.org; Fri, 17 Feb 2006 09:29:29 -0500
Received: from ([10.20.62.13])
	by paoakoavas10.cable.comcast.com with ESMTP  id KP-TDCH3.17042363;
	Fri, 17 Feb 2006 09:13:59 -0500
Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by
	PACDCEXCRLY01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Fri, 17 Feb 2006 09:13:58 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] wg-business: Draft IETF 65 Agenda
Date: Fri, 17 Feb 2006 09:13:58 -0500
Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A2E2@PACDCEXCMB01.cable.comcast.com>
Thread-Topic: [Speermint] wg-business: Draft IETF 65 Agenda
Thread-Index: AcYuVzDueBeIXn7ARwKNsvLbjhodcgE1H20gACgipbA=
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: <speermint@ietf.org>
X-OriginalArrivalTime: 17 Feb 2006 14:13:58.0977 (UTC)
	FILETIME=[6522EB10:01C633CC]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Content-Transfer-Encoding: quoted-printable
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Here is an official link to the agenda:

 http://www3.ietf.org/proceedings/06mar/agenda/speermint.txt

Jason

> -----Original Message-----
> From: speermint-bounces@ietf.org=20
> [mailto:speermint-bounces@ietf.org] On Behalf Of Livingood, Jason
> Sent: Thursday, February 16, 2006 2:04 PM
> To: speermint@ietf.org
> Subject: [Speermint] wg-business: Draft IETF 65 Agenda
>=20
> Here is a draft agenda.  We welcome any feedback.
>=20
> Regards
> Jason
>=20
> Session PEERing for Multimedia INTerconnect (speermint)
>=20
> *****DATE NEEDS TO BE UPDATED*****
>=20
> DAY, Month XX, 2006 XXXX-XXXX (Morning Session I)=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> CHAIRS:	    David Meyer      	<dmm@1-4-5.net>
> 	    Jason Livingood  	<jason_livingood@cable.comcast.com>
>=20
> SECRETARY:  Alexander Mayrhofer <alexander.mayrhofer@nic.at>
>=20
> AGENDA
>=20
>  o Welcome & Introduction to speermint / Administrivia=09
>   5 minutes
>      Dave Meyer
>=20
>    - Mailing list: speermint-request@ietf.org
>      subscribe
>=20
>    - Scribe (jabber)
>   =20
>    - Blue Sheets
>=20
>  o Agenda Bashing                                         	5
> minutes
>      Dave Meyer
>=20
>  o Review of Milestones                                   	5
> minutes
>      Jason Livingood
>=20
>  o Review and Status of Open Work Items                     =20
>=20
>    New Drafts
>    -------------
>     1 - speermint Terminology Draft				15
> minutes (TBD)
> 	  Dave Meyer
>=20
>     2 - SIP Peering Policy Management
>     	draft-lendl-sip-peering-policy-00			20
> minutes (requested)
>     	draft-lendl-domain-policy-ddds-00.txt
> 	  Otmar Lendl
> 	  Axel Mayrhofer
>=20
>     3 - Media Session Authorization    		=09
> 	15
> minutes (TBD)
>     	draft-wing-session-auth-00
> 	  Dan Wing
>=20
>     4 - I-D on the minimum set of requirements for 		15
> minutes (TBD)
>     	SIP-based VoIP interconnection (BCP)
>     	draft-natale-sip-voip-requirements-00.txt           =20
>      	  Bob Natale
>=20
>     5 - Routing Architectures, Policy, and Message Flows	15
> minutes (TBD)
> 	  Medhavi Bhatia
>=20
>     6 - Address Resolution Scenarios (not confirmed)		15
> minutes (TBD)
> 	  Matt Stafford
>=20
>  o Open Discussion                                       	15
> minutes
>=20
>=20
> NOTES:=20
> Times marked TBD are placeholders. =20
> The exact duration of these presentations has not been finalized yet.
> Times marked requested are as presenters have requested.
>   =20
> =20
>=20
> > -----Original Message-----
> > From: speermint-bounces@ietf.org
> > [mailto:speermint-bounces@ietf.org] On Behalf Of Livingood, Jason
> > Sent: Friday, February 10, 2006 10:32 AM
> > To: speermint@ietf.org
> > Subject: [Speermint] wg-business: Call for IETF 65 Agenda Items
> >=20
> > Hello -
> >=20
> > We have requested a 2 hour meeting slot at IETF 65.  We are=20
> currently=20
> > working on a draft agenda to send the list.  If you would like to=20
> > propose an item for the agenda, please email Dave and I=20
> privately for=20
> > consideration by 5pm EST of next Tuesday, 14 February.  We=20
> aiming to=20
> > get a draft agenda out to the group by Friday of next week.
> > =20
> > Dave & Jason
> >=20
> > _______________________________________________
> > Speermint mailing list
> > Speermint@ietf.org
> > https://www1.ietf.org/mailman/listinfo/speermint
> >=20
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
>=20

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Fri Feb 17 10:08:10 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1FA7BJ-0001cM-PP; Fri, 17 Feb 2006 10:06:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6uw-00017g-67
	for speermint@megatron.ietf.org; Fri, 17 Feb 2006 09:49:06 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08445
	for <speermint@ietf.org>; Fri, 17 Feb 2006 09:18:21 -0500 (EST)
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FA6ge-00058n-8n
	for speermint@ietf.org; Fri, 17 Feb 2006 09:34:22 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 17 Feb 2006 15:23:11 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4D8E@oefeg-s04.oefeg.loc>
Thread-Topic: RE: I-D ACTION:draft-ietf-speermint-reqs-and-terminology-00.txt 
Thread-Index: AcYzza5j3wBE6gMWRCymlsMr1x2R0w==
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: <speermint@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Content-Transfer-Encoding: quoted-printable
Subject: [Speermint] RE: I-D
	ACTION:draft-ietf-speermint-reqs-and-terminology-00.txt 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Thanks to the authors, a good starting point for discussions

I think before we start to discuss the requirements in detail, I would
suggest that the authors align the document with the language used in
the charter. Since the authors have been involved in the discussions
with the A-Ds personally, And know the intentions and arguments, they
are best suited to do this job.

Here I do not mean the already mentioned c/VOIPEER/SPEERMINT/ But the
more subtle changes to generalise terms like Voice Peering, Voice
Service providers etc.=20

Another general remark:
I suggest to move the terminology sections before the reqs e.g. before
or after section 2.

Best regards
Richard


> -----Original Message-----
> From: i-d-announce-bounces@ietf.org=20
> [mailto:i-d-announce-bounces@ietf.org]
> On Behalf Of Internet-Drafts@ietf.org
> Sent: Thursday, February 16, 2006 12:50 AM
> To: i-d-announce@ietf.org
> Cc: speermint@ietf.org
> Subject: I-D ACTION:draft-ietf-speermint-reqs-and-terminology-00.txt
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts=20
> directories.
>=20
>=20
> 	Title		: SPEERMINT Requirements and Terminology
>=20
> 	Author(s)	: D. Meyer
> 	Filename	:
draft-ietf-speermint-reqs-and-terminology-00.txt
> 	Pages		: 12
> 	Date		: 2006-2-15
>=20
>    This document outlines the solutions space requirements and defines
>    the terminology that is to be used by the Session PEERing for
>    Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
>    primary objective to focus the working group during its
discussions,
>    and when writing requirements, gap analysis and other solutions
>    oriented documents.
>=20
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-speermint-reqs-and-
> terminology-00.txt
>=20
> To remove yourself from the I-D Announcement list, send a message to=20
> i-d-announce-request@ietf.org with the word unsubscribe in the body of

> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>=20
>=20
> Internet-Drafts are also available by anonymous FTP. Login with the=20
> username "anonymous" and a password of your e-mail address. After=20
> logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-speermint-reqs-and-terminology-00.txt".
>=20
> A list of Internet-Drafts directories can be found in=20
> http://www.ietf.org/shadow.html or=20
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE
/internet-drafts/draft-ietf-speermint-reqs-and-terminology-
> 00.txt".
>=20
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>=20
>=20
> Below is the data which will enable a MIME compliant mail reader=20
> implementation to automatically retrieve the ASCII version of the=20
> Internet-Draft.

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Fri Feb 17 10:25:53 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1FA7UX-0004yj-Fa; Fri, 17 Feb 2006 10:25:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7Cz-0002yq-PI
	for speermint@megatron.ietf.org; Fri, 17 Feb 2006 10:07:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18785
	for <speermint@ietf.org>; Fri, 17 Feb 2006 10:05:57 -0500 (EST)
Received: from m106.maoz.com ([205.167.76.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA7RQ-0004Qc-Gf
	for speermint@ietf.org; Fri, 17 Feb 2006 10:22:42 -0500
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])
	by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k1HF7VtG013209
	for <speermint@ietf.org>; Fri, 17 Feb 2006 07:07:31 -0800
Received: (from dmm@localhost)
	by m106.maoz.com (8.13.4/8.12.11/Submit) id k1HF7VnD013208
	for speermint@ietf.org; Fri, 17 Feb 2006 07:07:31 -0800
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using
	-f
Date: Fri, 17 Feb 2006 07:07:31 -0800
From: David Meyer <dmm@1-4-5.net>
To: speermint@ietf.org
Message-ID: <20060217150731.GA13195@1-4-5.net>
Mime-Version: 1.0
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader,
	Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Subject: [Speermint] fyi -- [ietf-secretariat@ietf.org: Internet-Drafts
	Submission Cutoff Dates for the 65th IETF Meeting in Dallas,
	TX, USA]
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0644475739=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org


--===============0644475739==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW"
Content-Disposition: inline


--0F1p//8PRICkK4MW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

----- Forwarded message from ietf-secretariat@ietf.org -----

> From: ietf-secretariat@ietf.org
> To: ietf-announce@ietf.org
> Subject: Internet-Drafts Submission Cutoff Dates for the 65th IETF Meeting
>  in Dallas, TX, USA=20
> Date: Fri, 17 Feb 2006 00:00:01 -0500
>=20
>=20
> There are two (2) Internet-Draft cutoff dates for the 65th=20
> IETF Meeting in Dallas, TX, USA:
>=20
> February 27th: Cutoff Date for Initial (i.e., version -00)=20
> Internet-Draft Submissions=20
>=20
> All initial Internet-Drafts (version -00) must be submitted by Monday,=20
> February 27th at 9:00 AM ET. As always, all initial submissions with a=20
> filename beginning with "draft-ietf" must be approved by the=20
> appropriate WG Chair before they can be processed or announced.  The=20
> Secretariat would appreciate receiving WG Chair approval by Monday,=20
> February 20th at 9:00 AM ET.
>=20
> March 6th: Cutoff Date for Revised (i.e., version -01 and higher)=20
> Internet-Draft Submissions=20
>=20
> All revised Internet-Drafts (version -01 and higher) must be submitted=20
> by Monday, March 6th at 9:00 AM ET.
>=20
> Initial and revised Internet-Drafts received after their respective=20
> cutoff dates will not be made available in the Internet-Drafts=20
> directory or announced until on or after Monday, March 20th at 9:00=20
> AM ET, when Internet-Draft posting resumes.  Please do not wait until=20
> the last minute to submit.
>=20
> Thank you for your understanding and cooperation. If you have any=20
> questions or concerns, then please send a message to=20
> internet-drafts@ietf.org.
>=20
> The IETF Secretariat
>=20
> FYI: The Internet-Draft cutoff dates as well as other significant dates
> for the 65th IETF Meeting can be found at http://www.ietf.org/meetings/cu=
toff_dates_65.html.
>=20
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce

----- End forwarded message -----

--0F1p//8PRICkK4MW
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFD9eazORgD1qCZ2KcRAtylAJ9B/DIqH12t/zBOJjpL/pbTHLCuAACgkO4c
TnLC+/Ehf3uccMY/5VLj9ZM=
=OFPB
-----END PGP SIGNATURE-----

--0F1p//8PRICkK4MW--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============0644475739==--




From speermint-bounces@ietf.org Fri Feb 17 10:39:15 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1FA7hT-0002k3-Oo; Fri, 17 Feb 2006 10:39:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7hS-0002jh-PV
	for speermint@megatron.ietf.org; Fri, 17 Feb 2006 10:39:14 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27287
	for <speermint@ietf.org>; Fri, 17 Feb 2006 10:37:26 -0500 (EST)
Received: from m106.maoz.com ([205.167.76.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA7vq-0007w2-1w
	for speermint@ietf.org; Fri, 17 Feb 2006 10:54:11 -0500
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])
	by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k1HFd0pR014961;
	Fri, 17 Feb 2006 07:39:00 -0800
Received: (from dmm@localhost)
	by m106.maoz.com (8.13.4/8.12.11/Submit) id k1HFcx2d014960;
	Fri, 17 Feb 2006 07:38:59 -0800
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using
	-f
Date: Fri, 17 Feb 2006 07:38:59 -0800
From: David Meyer <dmm@1-4-5.net>
To: Stastny Richard <Richard.Stastny@oefeg.at>
Subject: Re: [Speermint] RE: I-D
	ACTION:draft-ietf-speermint-reqs-and-terminology-00.txt
Message-ID: <20060217153859.GA14847@1-4-5.net>
References: <32755D354E6B65498C3BD9FD496C7D463C4D8E@oefeg-s04.oefeg.loc>
Mime-Version: 1.0
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C4D8E@oefeg-s04.oefeg.loc>
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader,
	Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1306422927=="
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org


--===============1306422927==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN"
Content-Disposition: inline


--J/dobhs11T7y2rNN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 17, 2006 at 03:23:11PM +0100, Stastny Richard wrote:
> Thanks to the authors, a good starting point for discussions
>=20
> I think before we start to discuss the requirements in detail, I would
> suggest that the authors align the document with the language used in
> the charter. Since the authors have been involved in the discussions
> with the A-Ds personally, And know the intentions and arguments, they
> are best suited to do this job.

	Good point. I will handle that. Thanks.
>=20
> Here I do not mean the already mentioned c/VOIPEER/SPEERMINT/ But the
> more subtle changes to generalise terms like Voice Peering, Voice
> Service providers etc.=20
>=20
> Another general remark:
> I suggest to move the terminology sections before the reqs e.g. before
> or after section 2.

	I'll take a look at that too.=20

	Thanks for the comments.

	Dave

--J/dobhs11T7y2rNN
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFD9e4TORgD1qCZ2KcRApEcAJ93XBAltIAsUlnIV9HmjPbcB6CAhgCdE9Sl
o/vi+7fRNRxJ8JPawBNhMSM=
=g3lZ
-----END PGP SIGNATURE-----

--J/dobhs11T7y2rNN--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============1306422927==--




From speermint-bounces@ietf.org Fri Feb 17 10:47:32 2006
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1FA7pU-00074h-Cg; Fri, 17 Feb 2006 10:47:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7pS-00074E-Nk
	for speermint@megatron.ietf.org; Fri, 17 Feb 2006 10:47:30 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29593
	for <speermint@ietf.org>; Fri, 17 Feb 2006 10:45:41 -0500 (EST)
Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA83u-0000Nb-F5
	for speermint@ietf.org; Fri, 17 Feb 2006 11:02:27 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] RE:
	I-DACTION:draft-ietf-speermint-reqs-and-terminology-00.txt 
Date: Fri, 17 Feb 2006 10:47:00 -0500
Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A2EE@PACDCEXCMB01.cable.comcast.com>
Thread-Topic: [Speermint] RE:
	I-DACTION:draft-ietf-speermint-reqs-and-terminology-00.txt 
Thread-Index: AcYzza5j3wBE6gMWRCymlsMr1x2R0wACTABQ
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: "Stastny Richard" <Richard.Stastny@oefeg.at>, <speermint@ietf.org>
X-OriginalArrivalTime: 17 Feb 2006 15:47:00.0982 (UTC)
	FILETIME=[64454960:01C633D9]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Sender: speermint-bounces@ietf.org
Errors-To: speermint-bounces@ietf.org

Good feedback.  I think some of these changes may even get reflected in
a -01 rev before Dallas but that may depend more on Dave's schedule than
anything else.

Jason=20

> -----Original Message-----
> From: speermint-bounces@ietf.org=20
> [mailto:speermint-bounces@ietf.org] On Behalf Of Stastny Richard
> Sent: Friday, February 17, 2006 9:23 AM
> To: speermint@ietf.org
> Subject: [Speermint] RE:=20
> I-DACTION:draft-ietf-speermint-reqs-and-terminology-00.txt=20
>=20
> Thanks to the authors, a good starting point for discussions
>=20
> I think before we start to discuss the requirements in=20
> detail, I would suggest that the authors align the document=20
> with the language used in the charter. Since the authors have=20
> been involved in the discussions with the A-Ds personally,=20
> And know the intentions and arguments, they are best suited=20
> to do this job.
>=20
> Here I do not mean the already mentioned c/VOIPEER/SPEERMINT/=20
> But the more subtle changes to generalise terms like Voice=20
> Peering, Voice Service providers etc.=20
>=20
> Another general remark:
> I suggest to move the terminology sections before the reqs=20
> e.g. before or after section 2.
>=20
> Best regards
> Richard
>=20
>=20
> > -----Original Message-----
> > From: i-d-announce-bounces@ietf.org
> > [mailto:i-d-announce-bounces@ietf.org]
> > On Behalf Of Internet-Drafts@ietf.org
> > Sent: Thursday, February 16, 2006 12:50 AM
> > To: i-d-announce@ietf.org
> > Cc: speermint@ietf.org
> > Subject: I-D ACTION:draft-ietf-speermint-reqs-and-terminology-00.txt
> >=20
> > A New Internet-Draft is available from the on-line Internet-Drafts=20
> > directories.
> >=20
> >=20
> > 	Title		: SPEERMINT Requirements and Terminology
> >=20
> > 	Author(s)	: D. Meyer
> > 	Filename	:
> draft-ietf-speermint-reqs-and-terminology-00.txt
> > 	Pages		: 12
> > 	Date		: 2006-2-15
> >=20
> >    This document outlines the solutions space requirements=20
> and defines
> >    the terminology that is to be used by the Session PEERing for
> >    Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
> >    primary objective to focus the working group during its
> discussions,
> >    and when writing requirements, gap analysis and other solutions
> >    oriented documents.
> >=20
> >=20
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-speermint-reqs-and-
> > terminology-00.txt
> >=20
> > To remove yourself from the I-D Announcement list, send a=20
> message to=20
> > i-d-announce-request@ietf.org with the word unsubscribe in=20
> the body of
>=20
> > the message.
> > You can also visit=20
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >=20
> >=20
> > Internet-Drafts are also available by anonymous FTP. Login with the=20
> > username "anonymous" and a password of your e-mail address. After=20
> > logging in, type "cd internet-drafts" and then
> > 	"get draft-ietf-speermint-reqs-and-terminology-00.txt".
> >=20
> > A list of Internet-Drafts directories can be found in=20
> > http://www.ietf.org/shadow.html or=20
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >=20
> >=20
> > Internet-Drafts can also be obtained by e-mail.
> >=20
> > Send a message to:
> > 	mailserv@ietf.org.
> > In the body type:
> > 	"FILE
> /internet-drafts/draft-ietf-speermint-reqs-and-terminology-
> > 00.txt".
> >=20
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> >=20
> >=20
> > Below is the data which will enable a MIME compliant mail reader=20
> > implementation to automatically retrieve the ASCII version of the=20
> > Internet-Draft.
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
>=20

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Sun Feb 19 13:51:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FAteQ-0005q2-Ej; Sun, 19 Feb 2006 13:51:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FAteP-0005px-6E
	for speermint@ietf.org; Sun, 19 Feb 2006 13:51:17 -0500
Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAteN-0001Xa-TP
	for speermint@ietf.org; Sun, 19 Feb 2006 13:51:17 -0500
Received: from [192.168.1.206] (85-124-83-148.dynamic.xdsl-line.inode.at
	[::ffff:85.124.83.148])
	(AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
	by pahula with esmtp; Sun, 19 Feb 2006 19:51:11 +0100
	id 0006C0B9.43F8BE20.000068D9
Message-ID: <43F8BE03.1020500@enum.at>
Date: Sun, 19 Feb 2006 19:50:43 +0100
From: Alexander Mayrhofer <alexander.mayrhofer@enum.at>
Organization: enum.at GmbH
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: speermint@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Subject: [Speermint] fyi - IETF65 speermint session draft schedule
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org


According to the draft Agenda, the speermint session is scheduled for Monday 
afternoon, and collides with the following other sessions:

MONDAY, March 20, 2006
1520-1720 Afternoon Session II - 2 hour
APP	lemonade        Enhancements to Internet
                         email to Support Diverse ServiceEnvironments WG
INT	intarea	Internet Area Meeting
OPS	capwap	Control and Provisioning of Wireless Access Points WG
RAI	spearmint	Session Peering for Multimedia Interconnect WG
SEC	btns	Better-Than-Nothing Security WG
TSV	rmt	Reliable Multicast Transport WG
TSV	tcpm	TCP Maintenance and Minor Extensions WG
RTG	pce	Path Computation Element WG

Same as the ENUM WG: This gives us nearly a full week to clear away the 
discussion debris from the session ;)

cheers

Alex

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 20 08:58:02 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FBBY8-000225-Kz; Mon, 20 Feb 2006 08:58:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FBBY7-00021x-66
	for speermint@ietf.org; Mon, 20 Feb 2006 08:57:59 -0500
Received: from paoakoavas10.cable.comcast.com ([208.17.35.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBBY6-0007y6-SV
	for speermint@ietf.org; Mon, 20 Feb 2006 08:57:59 -0500
Received: from ([10.20.62.13])
	by paoakoavas10.cable.comcast.com with ESMTP  id KP-TDCH3.17085261;
	Mon, 20 Feb 2006 08:57:30 -0500
Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by
	PACDCEXCRLY01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 08:57:30 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] wg-business: Draft IETF 65 Agenda
Date: Mon, 20 Feb 2006 08:57:29 -0500
Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A312@PACDCEXCMB01.cable.comcast.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint] wg-business: Draft IETF 65 Agenda
Thread-Index: AcYuVzDueBeIXn7ARwKNsvLbjhodcgE1H20gACgipbAAlkokMA==
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: <speermint@ietf.org>
X-OriginalArrivalTime: 20 Feb 2006 13:57:30.0221 (UTC)
	FILETIME=[9707F9D0:01C63625]
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org

Our WG has been tentatively schedule on Monday afternoon.  This is not
yet confirmed, as the IETF 65 agenda is still in draft form (see
http://www.ietf.org/meetings/agenda_65.txt).

MONDAY, March 20, 2006
1520-1720 Afternoon Session II

http://www3.ietf.org/proceedings/06mar/agenda/speermint.txt

Regards
Dave & Jason


> -----Original Message-----
> From: speermint-bounces@ietf.org=20
> [mailto:speermint-bounces@ietf.org] On Behalf Of Livingood, Jason
> Sent: Friday, February 17, 2006 9:14 AM
> To: speermint@ietf.org
> Subject: RE: [Speermint] wg-business: Draft IETF 65 Agenda
>=20
> Here is an official link to the agenda:
>=20
>  http://www3.ietf.org/proceedings/06mar/agenda/speermint.txt
>=20
> Jason
>=20
> > -----Original Message-----
> > From: speermint-bounces@ietf.org
> > [mailto:speermint-bounces@ietf.org] On Behalf Of Livingood, Jason
> > Sent: Thursday, February 16, 2006 2:04 PM
> > To: speermint@ietf.org
> > Subject: [Speermint] wg-business: Draft IETF 65 Agenda
> >=20
> > Here is a draft agenda.  We welcome any feedback.
> >=20
> > Regards
> > Jason
> >=20
> > Session PEERing for Multimedia INTerconnect (speermint)
> >=20
> > *****DATE NEEDS TO BE UPDATED*****
> >=20
> > DAY, Month XX, 2006 XXXX-XXXX (Morning Session I)=20
> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >=20
> > CHAIRS:	    David Meyer      	<dmm@1-4-5.net>
> > 	    Jason Livingood  	<jason_livingood@cable.comcast.com>
> >=20
> > SECRETARY:  Alexander Mayrhofer <alexander.mayrhofer@nic.at>
> >=20
> > AGENDA
> >=20
> >  o Welcome & Introduction to speermint / Administrivia=09
> >   5 minutes
> >      Dave Meyer
> >=20
> >    - Mailing list: speermint-request@ietf.org
> >      subscribe
> >=20
> >    - Scribe (jabber)
> >   =20
> >    - Blue Sheets
> >=20
> >  o Agenda Bashing                                         	5
> > minutes
> >      Dave Meyer
> >=20
> >  o Review of Milestones                                   	5
> > minutes
> >      Jason Livingood
> >=20
> >  o Review and Status of Open Work Items                     =20
> >=20
> >    New Drafts
> >    -------------
> >     1 - speermint Terminology Draft				15
> > minutes (TBD)
> > 	  Dave Meyer
> >=20
> >     2 - SIP Peering Policy Management
> >     	draft-lendl-sip-peering-policy-00	=09
> 	20
> > minutes (requested)
> >     	draft-lendl-domain-policy-ddds-00.txt
> > 	  Otmar Lendl
> > 	  Axel Mayrhofer
> >=20
> >     3 - Media Session Authorization    		=09
> > 	15
> > minutes (TBD)
> >     	draft-wing-session-auth-00
> > 	  Dan Wing
> >=20
> >     4 - I-D on the minimum set of requirements for 		15
> > minutes (TBD)
> >     	SIP-based VoIP interconnection (BCP)
> >     	draft-natale-sip-voip-requirements-00.txt           =20
> >      	  Bob Natale
> >=20
> >     5 - Routing Architectures, Policy, and Message Flows	15
> > minutes (TBD)
> > 	  Medhavi Bhatia
> >=20
> >     6 - Address Resolution Scenarios (not confirmed)=09
> 	15
> > minutes (TBD)
> > 	  Matt Stafford
> >=20
> >  o Open Discussion                                       	15
> > minutes
> >=20
> >=20
> > NOTES:=20
> > Times marked TBD are placeholders. =20
> > The exact duration of these presentations has not been=20
> finalized yet.
> > Times marked requested are as presenters have requested.
> >   =20
> > =20
> >=20
> > > -----Original Message-----
> > > From: speermint-bounces@ietf.org
> > > [mailto:speermint-bounces@ietf.org] On Behalf Of Livingood, Jason
> > > Sent: Friday, February 10, 2006 10:32 AM
> > > To: speermint@ietf.org
> > > Subject: [Speermint] wg-business: Call for IETF 65 Agenda Items
> > >=20
> > > Hello -
> > >=20
> > > We have requested a 2 hour meeting slot at IETF 65.  We are
> > currently
> > > working on a draft agenda to send the list.  If you would like to=20
> > > propose an item for the agenda, please email Dave and I
> > privately for
> > > consideration by 5pm EST of next Tuesday, 14 February.  We
> > aiming to
> > > get a draft agenda out to the group by Friday of next week.
> > > =20
> > > Dave & Jason
> > >=20
> > > _______________________________________________
> > > Speermint mailing list
> > > Speermint@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > >=20
> >=20
> > _______________________________________________
> > Speermint mailing list
> > Speermint@ietf.org
> > https://www1.ietf.org/mailman/listinfo/speermint
> >=20
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
>=20

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 20 13:43:41 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FBG0Y-00026N-90; Mon, 20 Feb 2006 13:43:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FBG0X-00026I-05
	for speermint@ietf.org; Mon, 20 Feb 2006 13:43:37 -0500
Received: from mail124.messagelabs.com ([85.158.136.19])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FBG0W-0000k0-H4
	for speermint@ietf.org; Mon, 20 Feb 2006 13:43:36 -0500
X-VirusChecked: Checked
X-Env-Sender: ppfautz@att.com
X-Msg-Ref: server-8.tower-124.messagelabs.com!1140461011!7284742!2
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 26940 invoked from network); 20 Feb 2006 18:43:35 -0000
Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4)
	by server-8.tower-124.messagelabs.com with SMTP;
	20 Feb 2006 18:43:35 -0000
Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.9) by
	attrh2i.attrh.att.com (7.2.052)
	id 43F8A54400021E90 for speermint@ietf.org;
	Mon, 20 Feb 2006 13:43:34 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint]
	I-DACTION:draft-ietf-speermint-reqs-and-terminology-00.txt 
Date: Mon, 20 Feb 2006 13:43:33 -0500
Message-ID: <34DA635B184A644DA4588E260EC0A25A0C3218FD@ACCLUST02EVS1.ugd.att.com>
In-Reply-To: <E1F9WPJ-0001UY-Eg@stiedprstage1.ietf.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint]
	I-DACTION:draft-ietf-speermint-reqs-and-terminology-00.txt 
Thread-Index: AcYyjnNiJxNKTK4TTS6WGKCd7v54XwDvStug
From: "Pfautz, Penn L, NEO" <ppfautz@att.com>
To: <speermint@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org

=20
A couple of comments re this draft:

1. Section 3.3 "No Blocked Calls" indicates that "An originating Voice
Service Provider, or VSP, must be able to
   determine whether a SIP URI is open for direct interconnection
without actually sending a SIP INVITE."
I'd like to clarify that this determination should be respect to
interconnection generally to the domain in question but NOT necessarily
a specific E.164 number where CRD is derived from ENUM.  The reason for
this is to avoid divulging whether a particular number that may be
served by a carrier of record is in service or not. The point is to
avoid making ENUM look-up a data mining opportunity for discovering
unpublished numbers without actually making a call attempt.

2.Section 4.4 defines Network thus "For purposes of this document and
the VOIPEER and ENUM Working
   Groups, a network is defined to be the set of SIP servers and end-
   users (customers) that are controlled by a single administrative
   domain."
I would argue that this document cannot define "network" for the ENUM WG
only for the Speermint WG. Nor it is clear to me that the proposed
definition is appropriate to the ENUM WG which is not just about SIP.
Second, while I understand what is being proposed, I think it would be
less confusing to explicitly qualify network as layer 3 or layer 5 in
each instance or to have a distinguished term, e.g., "VSP network" that
specifically  ties to the definition about rather than trying to bound
the general term in the manner proposed.

Penn


-----Original Message-----
From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On
Behalf Of Internet-Drafts@ietf.org
Sent: Wednesday, February 15, 2006 6:50 PM
To: i-d-announce@ietf.org
Cc: speermint@ietf.org
Subject: [Speermint]
I-DACTION:draft-ietf-speermint-reqs-and-terminology-00.txt=20

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


	Title		: SPEERMINT Requirements and Terminology

	Author(s)	: D. Meyer
	Filename	:
draft-ietf-speermint-reqs-and-terminology-00.txt
	Pages		: 12
	Date		: 2006-2-15
=09
   This document outlines the solutions space requirements and defines
   the terminology that is to be used by the Session PEERing for
   Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
   primary objective to focus the working group during its discussions,
   and when writing requirements, gap analysis and other solutions
   oriented documents.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-reqs-and-termin
ology-00.txt

To remove yourself from the I-D Announcement list, send a message to=20
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-speermint-reqs-and-terminology-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE
/internet-drafts/draft-ietf-speermint-reqs-and-terminology-00.txt".
=09
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 20 13:53:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FBGAB-0002a1-EQ; Mon, 20 Feb 2006 13:53:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FBGAA-0002Zw-5i
	for speermint@ietf.org; Mon, 20 Feb 2006 13:53:34 -0500
Received: from m106.maoz.com ([205.167.76.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBGA8-0000vB-PX
	for speermint@ietf.org; Mon, 20 Feb 2006 13:53:34 -0500
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])
	by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k1KIrQkJ026927;
	Mon, 20 Feb 2006 10:53:26 -0800
Received: (from dmm@localhost)
	by m106.maoz.com (8.13.4/8.12.11/Submit) id k1KIrQrw026926;
	Mon, 20 Feb 2006 10:53:26 -0800
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using
	-f
Date: Mon, 20 Feb 2006 10:53:26 -0800
From: David Meyer <dmm@1-4-5.net>
To: "Pfautz, Penn L, NEO" <ppfautz@att.com>
Subject: Re: [Speermint]
	I-DACTION:draft-ietf-speermint-reqs-and-terminology-00.txt
Message-ID: <20060220185326.GA26898@1-4-5.net>
References: <E1F9WPJ-0001UY-Eg@stiedprstage1.ietf.org>
	<34DA635B184A644DA4588E260EC0A25A0C3218FD@ACCLUST02EVS1.ugd.att.com>
Mime-Version: 1.0
In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0C3218FD@ACCLUST02EVS1.ugd.att.com>
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader,
	Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0118743059=="
Errors-To: speermint-bounces@ietf.org


--===============0118743059==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND"
Content-Disposition: inline


--d6Gm4EdcadzBjdND
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

	Penn,

	First, thanks for the comments.

> A couple of comments re this draft:
>=20
> 1. Section 3.3 "No Blocked Calls" indicates that "An originating Voice
> Service Provider, or VSP, must be able to
>    determine whether a SIP URI is open for direct interconnection
> without actually sending a SIP INVITE."
> I'd like to clarify that this determination should be respect to
> interconnection generally to the domain in question but NOT necessarily
> a specific E.164 number where CRD is derived from ENUM.  The reason for
> this is to avoid divulging whether a particular number that may be
> served by a carrier of record is in service or not. The point is to
> avoid making ENUM look-up a data mining opportunity for discovering
> unpublished numbers without actually making a call attempt.

	Good point. I'll catch that (with appropriate wording) in
	the next rev.

> 2.Section 4.4 defines Network thus "For purposes of this document and
> the VOIPEER and ENUM Working
>    Groups, a network is defined to be the set of SIP servers and end-
>    users (customers) that are controlled by a single administrative
>    domain."
> I would argue that this document cannot define "network" for the ENUM WG
> only for the Speermint WG. Nor it is clear to me that the proposed
> definition is appropriate to the ENUM WG which is not just about SIP.

	Sure, we can revisit that text.


> Second, while I understand what is being proposed, I think it would be
> less confusing to explicitly qualify network as layer 3 or layer 5 in
> each instance or to have a distinguished term, e.g., "VSP network" that
> specifically  ties to the definition about rather than trying to bound
> the general term in the manner proposed.

	Well taken. Let me think about how to do that in an
	economical fashion.

	Thanks,

	Dave

--d6Gm4EdcadzBjdND
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFD+hAmORgD1qCZ2KcRAhXDAJ9dHaYaBBdKCtVZu4/dKO/ry3CdsgCfZVz+
R9y/cyOjlj3w1G3Wb4EASkI=
=IYXk
-----END PGP SIGNATURE-----

--d6Gm4EdcadzBjdND--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============0118743059==--




From speermint-bounces@ietf.org Mon Feb 20 14:04:24 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FBGKd-0002vL-0a; Mon, 20 Feb 2006 14:04:23 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FBGKb-0002vG-NI
	for speermint@ietf.org; Mon, 20 Feb 2006 14:04:21 -0500
Received: from mail2.nextone.com ([209.125.86.105])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBGKb-00014o-Cf
	for speermint@ietf.org; Mon, 20 Feb 2006 14:04:21 -0500
Received: from moe.nextone.local ([192.168.15.38]) by mail2.nextone.com with
	Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 14:04:21 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [Speermint]I-DACTION:draft-ietf-speermint-reqs-and-terminology-00.txt
Date: Mon, 20 Feb 2006 14:04:19 -0500
Message-ID: <8812D8156467224C9E9739E513037EF149CF@moe.nextone.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint]I-DACTION:draft-ietf-speermint-reqs-and-terminology-00.txt
Thread-Index: AcYyjnNiJxNKTK4TTS6WGKCd7v54XwDvStugAACzBeA=
From: "Bob Natale" <bnatale@nextone.com>
To: "Pfautz, Penn L, NEO" <ppfautz@att.com>,
	<speermint@ietf.org>
X-OriginalArrivalTime: 20 Feb 2006 19:04:21.0077 (UTC)
	FILETIME=[74C1A850:01C63650]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org

Hi,

I support the observation Penn makes in #1 and, furthermore, suggest
that requirements of this nature be left for WG refinement as part of
the BCP milestone defining "the minimum set of requirements for
SIP-based VoIP interconnection".

I plan to submit a candidate outline of that document for the Dallas
IETF, mostly structural in nature (not prescriptive), and would expect
substantial WG discussion/editing over the coming months.  And hopefully
we will attract ample input from SIP/VoIP peering organizations as well.

Also, as much as I admire WG Chairs who set realistic achievable
milestone dates, I think we might have to drive ourselves to conclude
this BCP somewhat sooner than March 2007 ... I'm worried that the
marketplace might out-pace us otherwise.

Cheers,
BobN

-----Original Message-----
From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com]=20
Sent: Monday, February 20, 2006 1:44 PM
To: speermint@ietf.org
Subject: RE:
[Speermint]I-DACTION:draft-ietf-speermint-reqs-and-terminology-00.txt=20

=20
A couple of comments re this draft:

1. Section 3.3 "No Blocked Calls" indicates that "An originating Voice
Service Provider, or VSP, must be able to
   determine whether a SIP URI is open for direct interconnection
without actually sending a SIP INVITE."
I'd like to clarify that this determination should be respect to
interconnection generally to the domain in question but NOT necessarily
a specific E.164 number where CRD is derived from ENUM.  The reason for
this is to avoid divulging whether a particular number that may be
served by a carrier of record is in service or not. The point is to
avoid making ENUM look-up a data mining opportunity for discovering
unpublished numbers without actually making a call attempt.

2.Section 4.4 defines Network thus "For purposes of this document and
the VOIPEER and ENUM Working
   Groups, a network is defined to be the set of SIP servers and end-
   users (customers) that are controlled by a single administrative
   domain."
I would argue that this document cannot define "network" for the ENUM WG
only for the Speermint WG. Nor it is clear to me that the proposed
definition is appropriate to the ENUM WG which is not just about SIP.
Second, while I understand what is being proposed, I think it would be
less confusing to explicitly qualify network as layer 3 or layer 5 in
each instance or to have a distinguished term, e.g., "VSP network" that
specifically  ties to the definition about rather than trying to bound
the general term in the manner proposed.

Penn


-----Original Message-----
From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On
Behalf Of Internet-Drafts@ietf.org
Sent: Wednesday, February 15, 2006 6:50 PM
To: i-d-announce@ietf.org
Cc: speermint@ietf.org
Subject: [Speermint]
I-DACTION:draft-ietf-speermint-reqs-and-terminology-00.txt=20

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


	Title		: SPEERMINT Requirements and Terminology

	Author(s)	: D. Meyer
	Filename	:
draft-ietf-speermint-reqs-and-terminology-00.txt
	Pages		: 12
	Date		: 2006-2-15
=09
   This document outlines the solutions space requirements and defines
   the terminology that is to be used by the Session PEERing for
   Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
   primary objective to focus the working group during its discussions,
   and when writing requirements, gap analysis and other solutions
   oriented documents.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-reqs-and-termin
ology-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
	"get draft-ietf-speermint-reqs-and-terminology-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE
/internet-drafts/draft-ietf-speermint-reqs-and-terminology-00.txt".
=09
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 20 14:11:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FBGRT-00039h-LW; Mon, 20 Feb 2006 14:11:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FBGRS-00039c-5M
	for speermint@ietf.org; Mon, 20 Feb 2006 14:11:26 -0500
Received: from m106.maoz.com ([205.167.76.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBGRR-0001O0-QE
	for speermint@ietf.org; Mon, 20 Feb 2006 14:11:26 -0500
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])
	by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k1KJBN8T028188;
	Mon, 20 Feb 2006 11:11:23 -0800
Received: (from dmm@localhost)
	by m106.maoz.com (8.13.4/8.12.11/Submit) id k1KJBNqC028187;
	Mon, 20 Feb 2006 11:11:23 -0800
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using
	-f
Date: Mon, 20 Feb 2006 11:11:23 -0800
From: David Meyer <dmm@1-4-5.net>
To: Bob Natale <bnatale@nextone.com>
Subject: Re: [Speermint]I-DACTION:draft-ietf-speermint-reqs-and-terminology-00.txt
Message-ID: <20060220191123.GA28131@1-4-5.net>
References: <8812D8156467224C9E9739E513037EF149CF@moe.nextone.local>
Mime-Version: 1.0
In-Reply-To: <8812D8156467224C9E9739E513037EF149CF@moe.nextone.local>
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader,
	Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0456162251=="
Errors-To: speermint-bounces@ietf.org


--===============0456162251==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB"
Content-Disposition: inline


--DocE+STaALJfprDB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 20, 2006 at 02:04:19PM -0500, Bob Natale wrote:
> Hi,
>=20
> I support the observation Penn makes in #1 and, furthermore, suggest
> that requirements of this nature be left for WG refinement as part of
> the BCP milestone defining "the minimum set of requirements for
> SIP-based VoIP interconnection".
>
> I plan to submit a candidate outline of that document for the Dallas
> IETF, mostly structural in nature (not prescriptive), and would expect
> substantial WG discussion/editing over the coming months.  And hopefully
> we will attract ample input from SIP/VoIP peering organizations as well.

	All fine. As I mentioned eariler, lets take a look at
	these documents (when we have them in hand) and make=20
	sure we have a reasonable division of topics.=20

> Also, as much as I admire WG Chairs who set realistic achievable
> milestone dates, I think we might have to drive ourselves to conclude
> this BCP somewhat sooner than March 2007 ... I'm worried that the
> marketplace might out-pace us otherwise.

	Sure, we can always get our work done ahead of the
	milestone date; I don't think our ADs would complain
	about that. =20

	Dave

--DocE+STaALJfprDB
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFD+hRbORgD1qCZ2KcRAoSOAJ97R8JnBkNwSeYdrJK/h/MBSqSc+wCfSQOE
teRCHZZA3gA5p0rTuAghW8U=
=PpC2
-----END PGP SIGNATURE-----

--DocE+STaALJfprDB--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============0456162251==--




From speermint-bounces@ietf.org Tue Feb 21 15:50:07 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FBeSU-0003eq-Ah; Tue, 21 Feb 2006 15:50:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FBeSQ-0003ds-L2; Tue, 21 Feb 2006 15:50:02 -0500
Received: from oak.neustar.com ([209.173.53.70])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FBeSQ-0007ow-AO; Tue, 21 Feb 2006 15:50:02 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10])
	by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k1LKo2BX010635
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Feb 2006 20:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FBeSQ-0000HL-5E; Tue, 21 Feb 2006 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1FBeSQ-0000HL-5E@stiedprstage1.ietf.org>
Date: Tue, 21 Feb 2006 15:50:02 -0500
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: speermint@ietf.org
Subject: [Speermint] I-D
	ACTION:draft-ietf-speermint-reqs-and-terminology-01.txt 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF.

	Title		: SPEERMINT Requirements and Terminology
	Author(s)	: D. Meyer
	Filename	: draft-ietf-speermint-reqs-and-terminology-01.txt
	Pages		: 11
	Date		: 2006-2-21
	
This document outlines the solutions space requirements and defines
   the terminology that is to be used by the Session PEERing for
   Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
   primary objective to focus the working group during its discussions,
   and when writing requirements, gap analysis and other solutions
   oriented documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-reqs-and-terminology-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-speermint-reqs-and-terminology-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-speermint-reqs-and-terminology-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-2-21145741.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-speermint-reqs-and-terminology-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-speermint-reqs-and-terminology-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-2-21145741.I-D@ietf.org>


--OtherAccess--

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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--NextPart--





From speermint-bounces@ietf.org Wed Feb 22 09:52:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FBvMF-0008HC-R4; Wed, 22 Feb 2006 09:52:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FBvME-0008H6-IQ
	for speermint@ietf.org; Wed, 22 Feb 2006 09:52:46 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57]
	helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FBvME-0006vV-64
	for speermint@ietf.org; Wed, 22 Feb 2006 09:52:46 -0500
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com
	[47.129.230.95])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k1MEqhv11063
	for <speermint@ietf.org>; Wed, 22 Feb 2006 09:52:43 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint]
	I-DACTION:draft-ietf-speermint-reqs-and-terminology-01.txt 
Date: Wed, 22 Feb 2006 09:52:21 -0500
Message-ID: <F1A1D21DA394814E824AC89F5A005BA30976C18D@zcarhxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint]
	I-DACTION:draft-ietf-speermint-reqs-and-terminology-01.txt 
Thread-Index: AcY3KHFYiQ6389WeSr2P98SlEKjwxgAkds9w
From: "James McEachern" <jmce@nortel.com>
To: <speermint@ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org

Some additional comments on this draft.

Section 4.3 states that "Private ENUM is generally regarded as one or =
more technologies (including DNS and SIP Redirect)..."  Are we really =
suggesting that SIP Redirect is an instance of Private ENUM?

Section 4.4 states that tel URIs are out of scope for Speermint.  =
However, the tel URI phone context can contain a domain name, which =
section 5.2 identifies as the "primary key to any information regarding =
reachability". If a tel URI contains a domain name in the phone context, =
should it still be out of scope for Speermint?  Are we assuming that it =
must first be translated into a SIP URI?

Section 2:  the paragraph after the diagram still seems a bit misleading =
to me.  This paragraph ends by saying that "the CRD can be derived from =
ENUM (i.e., an E.164 DNS entry), or via any other mechanism available to =
the user". This implies that a call initiated with a SIP URI may need to =
use some "other mechanism" to derive the CRD, but section 5.2 makes it =
clear that the domain portion of the SIP URI actually is the CRD.  Would =
it be worth adding one more sentence to the end of section 2 to make =
this clear?  I'm thinking something like this:
"In the case where a SIP URI is used, the domain portion of the SIP URI =
is the CRD."

Section 4.4:  Shouldn't this be changed to Infrastructure ENUM now? =20
In addition this section almost reads as if Infrastructure ENUM does =
everything required to find points of interconnection, while the current =
thinking is that it provides CRD, which then ties in with Speermint to =
find points of interconnection.=20

Section 5.8 says our protocol must be generic enough to encompass other =
protocols.  Do we really view this as a "must", or could it be a =
"should"?

Comment:  I like the restructuring of the draft. I think it improves the =
flow of the document significantly.=20

Thanks
Jim

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20
Sent: Tuesday, February 21, 2006 3:50 PM
To: i-d-announce@ietf.org
Cc: speermint@ietf.org
Subject: [Speermint] =
I-DACTION:draft-ietf-speermint-reqs-and-terminology-01.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
This draft is a work item of the Session PEERing for Multimedia =
INTerconnect Working Group of the IETF.

	Title		: SPEERMINT Requirements and Terminology
	Author(s)	: D. Meyer
	Filename	: draft-ietf-speermint-reqs-and-terminology-01.txt
	Pages		: 11
	Date		: 2006-2-21
=09
This document outlines the solutions space requirements and defines
   the terminology that is to be used by the Session PEERing for
   Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
   primary objective to focus the working group during its discussions,
   and when writing requirements, gap analysis and other solutions
   oriented documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-reqs-and-termino=
logy-01.txt

To remove yourself from the I-D Announcement list, send a message to=20
i-d-announce-request@ietf.org with the word unsubscribe in the body of =
the message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the =
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-speermint-reqs-and-terminology-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE =
/internet-drafts/draft-ietf-speermint-reqs-and-terminology-01.txt".
=09
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Wed Feb 22 10:49:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FBwFJ-0001zv-Cx; Wed, 22 Feb 2006 10:49:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwFH-0001zq-UY
	for speermint@ietf.org; Wed, 22 Feb 2006 10:49:39 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FBwFG-0000wE-Gz
	for speermint@ietf.org; Wed, 22 Feb 2006 10:49:39 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 22 Feb 2006 16:53:33 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4DB3@oefeg-s04.oefeg.loc>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Tel URI phone-context
Thread-Index: AcY3KHFYiQ6389WeSr2P98SlEKjwxgAkds9wAAJgJGAAAQ8pYA==
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "James McEachern" <jmce@nortel.com>,
	<speermint@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: 
Subject: [Speermint] Tel URI phone-context
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org

James McEachern wrote:
>=20
> Section 4.4 states that tel URIs are out of scope for Speermint. =20
> However, the tel URI phone context can contain a domain name, which=20
> section 5.2 identifies as the "primary key to any information
regarding reachability".
> If a tel URI contains a domain name in the phone context, should it=20
> still be out of scope for Speermint?  Are we assuming that it must=20
> first be translated into a SIP URI?

The phone context is used only with local numbers and is defined in RFC
3966:

"Local numbers MUST have a 'phone-context' parameter that identifies
   the scope of their validity.  The parameter MUST be chosen to
   identify the local context within which the number is unique
   unambiguously.  Thus, the combination of the descriptor in the
   'phone-context' parameter and local number is again globally unique.
   The parameter value is defined by the assignee of the local number.
   It does NOT indicate a prefix that turns the local number into a
   global (E.164) number.

   There are two ways to label the context:  via a global number or any
   number of its leading digits (e.g., "+33") and via a domain name,
   e.g., "houston.example.com".  The choice between the two is left to
   the "owner" of the local number and is governed by whether there is a
   global number or domain name that is a valid identifier for a
   particular local number.

   The domain name does not have to resolve to any actual host but MUST
   be under the administrative control of the entity managing the local
   phone context.

The last paragraph clearly states that a domain name is used only to
provide uniqueness and NOT to be used within to query the DNS or to be
used for routing.

Regards

Richard



_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Wed Feb 22 10:51:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FBwH4-00025U-1l; Wed, 22 Feb 2006 10:51:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwH3-00025N-E0
	for speermint@ietf.org; Wed, 22 Feb 2006 10:51:29 -0500
Received: from mail.oefeg.at ([62.47.121.5])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FBwH2-0000zB-W8
	for speermint@ietf.org; Wed, 22 Feb 2006 10:51:29 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 22 Feb 2006 16:55:17 +0100
Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4DB4@oefeg-s04.oefeg.loc>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SPEERMINT Terminology Section 4.4.
Thread-Index: AcY3KHFYiQ6389WeSr2P98SlEKjwxgAkds9wAAKdNwAAAN4n8A==
From: "Stastny Richard" <Richard.Stastny@oefeg.at>
To: "James McEachern" <jmce@nortel.com>,
	<speermint@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: 
Subject: [Speermint] SPEERMINT Terminology Section 4.4.
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org


James McEachern wrote:
>=20
> Section 4.4:  Shouldn't this be changed to Infrastructure ENUM now?

Yes

> In addition this section almost reads as if Infrastructure ENUM does=20
> everything required to find points of interconnection, while the=20
> current thinking is that it provides CRD, which then ties in with=20
> Speermint to find points of interconnection.

This is not my impression, but I think the section needs rewording (I
think the authors simple forgot to update it as requested ;-)

Here a proposal:

"4.4.  Infrastructure ENUM

   Infrastructure ENUM is generally regarded as the use of a separate
branch
   the e164.arpa tree, such as 4.4.i.e164.arpa to permit service
   providers to exchange phone number to URI data in order to find
   points of interconnection.  The current theory of Infratructure ENUM
is
   that only the COR for a particular E.164 number is permitted to
   provision data for that E.164 within that portion of the e164.arpa
   tree.

   The COR may enter CRD (i.e., a SIP URI)
   to allow other VoIP Service Providers to route calls to its network.

   Finally, note that ENUM is not constrained to carry only data (CDR)
   as defined by SPEERMINT.  So the CoR may enter also other data in
   the corresponding domain. In particular, an important class of
   CRD??, the tel URIs [RFC3966] may be carried in ENUM.  Such tel URIs
   are most frequently used to interconnect with the PSTN directly, and
   are out of scope for SPEERMINT.  On the other hand, PSTN endpoints
   served by a COR and reachable via CDR and networks as defined in
   Section 3.1 and Section 3.4 are in scope for SPEERMINT."

The only additional remark is if the second to last sentence
(CRD??) should be called CRD at all, since Tel URIs are not routable on
the Internet.

In 3.1. Call Routing Data are defined as SIP URIs, Tel URIs are not
mentioned there.

I suggest to replace the sentence with:

"In particular, the corresponding domain may also contain tel URIs
[RFC3966]"



regards
Richard



_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Wed Feb 22 10:52:18 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FBwHq-00029a-Gh; Wed, 22 Feb 2006 10:52:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwHo-00029Q-HR
	for speermint@ietf.org; Wed, 22 Feb 2006 10:52:16 -0500
Received: from m106.maoz.com ([205.167.76.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBwHn-0000zm-Ta
	for speermint@ietf.org; Wed, 22 Feb 2006 10:52:16 -0500
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1])
	by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k1MFpiJA016660;
	Wed, 22 Feb 2006 07:51:44 -0800
Received: (from dmm@localhost)
	by m106.maoz.com (8.13.4/8.12.11/Submit) id k1MFpidR016659;
	Wed, 22 Feb 2006 07:51:44 -0800
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using
	-f
Date: Wed, 22 Feb 2006 07:51:44 -0800
From: David Meyer <dmm@1-4-5.net>
To: James McEachern <jmce@nortel.com>
Subject: Re: [Speermint]
	I-DACTION:draft-ietf-speermint-reqs-and-terminology-01.txt
Message-ID: <20060222155144.GA16567@1-4-5.net>
References: <F1A1D21DA394814E824AC89F5A005BA30976C18D@zcarhxm0.corp.nortel.com>
Mime-Version: 1.0
In-Reply-To: <F1A1D21DA394814E824AC89F5A005BA30976C18D@zcarhxm0.corp.nortel.com>
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader,
	Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0065302452=="
Errors-To: speermint-bounces@ietf.org


--===============0065302452==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt"
Content-Disposition: inline


--pf9I7BMVVzbSWLtt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

	Jim,

	Thanks for the comments.=20

On Wed, Feb 22, 2006 at 09:52:21AM -0500, James McEachern wrote:
> Some additional comments on this draft.
>=20
> Section 4.3 states that "Private ENUM is generally regarded as one or mor=
e technologies (including DNS and SIP Redirect)..."  Are we really suggesti=
ng that SIP Redirect is an instance of Private ENUM?

	That should probably be reworded. I'm not sure I remember
	where that text came from (need to check my cvs logs).

> Section 4.4 states that tel URIs are out of scope for Speermint.  However=
, the tel URI phone context can contain a domain name, which section 5.2 id=
entifies as the "primary key to any information regarding reachability". If=
 a tel URI contains a domain name in the phone context, should it still be =
out of scope for Speermint?  Are we assuming that it must first be translat=
ed into a SIP URI?

	See Richard's note on this (with which I agree). Other comments?

> Section 2:  the paragraph after the diagram still seems a bit misleading =
to me.  This paragraph ends by saying that "the CRD can be derived from ENU=
M (i.e., an E.164 DNS entry), or via any other mechanism available to the u=
ser". This implies that a call initiated with a SIP URI may need to use som=
e "other mechanism" to derive the CRD, but section 5.2 makes it clear that =
the domain portion of the SIP URI actually is the CRD.  Would it be worth a=
dding one more sentence to the end of section 2 to make this clear?  I'm th=
inking something like this:
> "In the case where a SIP URI is used, the domain portion of the SIP URI i=
s the CRD."

	That wasn't what I had in mind. I'll clarify that in -02.

> Section 4.4:  Shouldn't this be changed to Infrastructure ENUM now? =20
> In addition this section almost reads as if Infrastructure ENUM does ever=
ything required to find points of interconnection, while the current thinki=
ng is that it provides CRD, which then ties in with Speermint to find point=
s of interconnection.=20
>=20
	Yes, since terminology (and all fronts) is evolving,
	some inconsistency reamins. Another -02 issue.
=20
> Section 5.8 says our protocol must be generic enough to encompass other p=
rotocols.  Do we really view this as a "must", or could it be a "should"?

	First, the use of 2119 in non-standards track documents
	is, well, controversial, so words like should and must as
	used in a document like this are less rigorously
	defined. That being said, I like "should" better. Others?
=20
>=20
> Comment:  I like the restructuring of the draft. I think it improves the =
flow of the document significantly.=20

	Thanks. That was Richard's (Stastny) suggestion.

	Dave

>=20
> Thanks
> Jim
>=20
> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20
> Sent: Tuesday, February 21, 2006 3:50 PM
> To: i-d-announce@ietf.org
> Cc: speermint@ietf.org
> Subject: [Speermint] I-DACTION:draft-ietf-speermint-reqs-and-terminology-=
01.txt=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Session PEERing for Multimedia INTerconn=
ect Working Group of the IETF.
>=20
> 	Title		: SPEERMINT Requirements and Terminology
> 	Author(s)	: D. Meyer
> 	Filename	: draft-ietf-speermint-reqs-and-terminology-01.txt
> 	Pages		: 11
> 	Date		: 2006-2-21
> =09
> This document outlines the solutions space requirements and defines
>    the terminology that is to be used by the Session PEERing for
>    Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
>    primary objective to focus the working group during its discussions,
>    and when writing requirements, gap analysis and other solutions
>    oriented documents.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-speermint-reqs-and-termino=
logy-01.txt
>=20
> To remove yourself from the I-D Announcement list, send a message to=20
> i-d-announce-request@ietf.org with the word unsubscribe in the body of th=
e message. =20
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
> to change your subscription settings.
>=20
>=20
> Internet-Drafts are also available by anonymous FTP. Login with the usern=
ame
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-speermint-reqs-and-terminology-01.txt".
>=20
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html=20
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-speermint-reqs-and-terminology-01.txt".
> =09
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 	=09
> 	=09
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint

--pf9I7BMVVzbSWLtt
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFD/IiQORgD1qCZ2KcRAk2FAJwO+lptnfuvAbgVvZyoeQzwtnl6hwCfdFVo
XUdRj7nvBtALhr6PdMqsSAk=
=m4cw
-----END PGP SIGNATURE-----

--pf9I7BMVVzbSWLtt--


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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--===============0065302452==--




From speermint-bounces@ietf.org Thu Feb 23 18:54:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FCQHv-0002lK-Em; Thu, 23 Feb 2006 18:54:23 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FCQHu-0002l4-Nf
	for speermint@ietf.org; Thu, 23 Feb 2006 18:54:22 -0500
Received: from kremlin.juniper.net ([207.17.137.120])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCQHt-0003H9-Fo
	for speermint@ietf.org; Thu, 23 Feb 2006 18:54:22 -0500
Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37])
	by kremlin.juniper.net with ESMTP; 23 Feb 2006 15:54:20 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.02,142,1139212800"; 
	d="scan'208"; a="529754253:sNHT22306156"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 23 Feb 2006 18:54:19 -0500
Message-ID: <9BD5D7887235424FA97DFC223CAE3C2802DFE4C6@proton.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SIP Call Establishment and media routing over a VoIP peering
	interconnect.
Thread-Index: AcY41HZUnoDhKKFQTHiKDUYTPXqQbA==
From: "Reinaldo Penno" <rpenno@juniper.net>
To: <speermint@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Subject: [Speermint] SIP Call Establishment and media routing over a VoIP
	peering interconnect.
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org

Hello,

I read the proposed agenda of this WG and was wondering about the work
on=20

"In addition, the working group recognizes that
there will be use cases that require SPEERMINT to focus on the
interaction between the application layer and lower network
layers, or the dependence of specific application layer use
cases on lower layers, so SPEERMINT will have to be prepared to
solve these problems as they arise."


Is this WG going to tackle the problem where a DNS/ENUM/whatever lookup
decides the next-hop VoIP media takes on a VoIP peering interconnection?



I'm not talking about end-to-end QoS, reservations or some all
encompassing solution. It is the specific case of VoIP peering
interconnect.=20

For example, if two layer 3/5 devices are connected by many links, the
result of a lookup during SIP Call establishment (between two VoIP
domains), would direct media traffic for a certain call (or group of
calls), over link A instead of B.=20

Thanks,

Reinaldo

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 27 11:31:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FDlHk-00089v-L3; Mon, 27 Feb 2006 11:31:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FDlHj-00089a-GN
	for speermint@ietf.org; Mon, 27 Feb 2006 11:31:43 -0500
Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDlHh-00012W-Hn
	for speermint@ietf.org; Mon, 27 Feb 2006 11:31:43 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] SIP Call Establishment and media routing over a
	VoIPpeering interconnect.
Date: Mon, 27 Feb 2006 11:30:59 -0500
Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A3C7@PACDCEXCMB01.cable.comcast.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint] SIP Call Establishment and media routing over a
	VoIPpeering interconnect.
Thread-Index: AcY41HZUnoDhKKFQTHiKDUYTPXqQbAC5l7yA
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: "Reinaldo Penno" <rpenno@juniper.net>,
	<speermint@ietf.org>
X-OriginalArrivalTime: 27 Feb 2006 16:31:18.0088 (UTC)
	FILETIME=[3C28FC80:01C63BBB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org

> Is this WG going to tackle the problem where a=20
> DNS/ENUM/whatever lookup decides the next-hop VoIP media=20
> takes on a VoIP peering interconnection?
>
> I'm not talking about end-to-end QoS, reservations or some=20
> all encompassing solution. It is the specific case of VoIP=20
> peering interconnect.=20
>=20
> For example, if two layer 3/5 devices are connected by many=20
> links, the result of a lookup during SIP Call establishment=20
> (between two VoIP domains), would direct media traffic for a=20
> certain call (or group of calls), over link A instead of B.=20

I am not sure I completely understand what you are getting at.  However,
if you want to propose something at a high-level we can consider it.

Jason

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Mon Feb 27 13:37:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FDnEx-0004px-LW; Mon, 27 Feb 2006 13:36:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FDnEw-0004pp-AM
	for speermint@ietf.org; Mon, 27 Feb 2006 13:36:58 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDnEw-0005Y4-1D
	for speermint@ietf.org; Mon, 27 Feb 2006 13:36:58 -0500
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-5.cisco.com with ESMTP; 27 Feb 2006 10:36:59 -0800
X-IronPort-AV: i="4.02,150,1139212800"; 
	d="scan'208"; a="258135917:sNHT31645816"
Received: from dwingwxp ([10.32.240.197])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1RIauuh004807;
	Mon, 27 Feb 2006 10:36:56 -0800 (PST)
From: "Dan Wing" <dwing@cisco.com>
To: "'Reinaldo Penno'" <rpenno@juniper.net>, <speermint@ietf.org>
Subject: RE: [Speermint] SIP Call Establishment and media routing over a
	VoIPpeering interconnect.
Date: Mon, 27 Feb 2006 10:36:56 -0800
Message-ID: <043101c63bcc$c9f4f940$c5f0200a@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2802DFE4C6@proton.jnpr.net>
Thread-Index: AcY41HZUnoDhKKFQTHiKDUYTPXqQbAACD6sg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org

draft-wing-session-auth-00.txt can be used to provide that function.
Draft-wing-session-auth-00 currently discusses firewalls which are typically
binary devices that deny flows by default and accept flows by exception.  I
kept that focus because people are familiar with firewalls at the edge of a
network.

However, the same technique introduced by draft-wing-session-auth can be
used for other functions including the function you describe in your email
below.  Afterall, once you have identified and authorized a certain flow you
can then do anything to it you want -- block it, give it different DSCP
values, stick it into a different tunnel or interface, teleport the flow to
the moon, or whatever you like.

Draft-wing-session-auth is on the agenda for the upcoming SPEERMINT working
group meeting in Dallas.

-d

> -----Original Message-----
> From: Reinaldo Penno [mailto:rpenno@juniper.net] 
> Sent: Thursday, February 23, 2006 3:54 PM
> To: speermint@ietf.org
> Subject: [Speermint] SIP Call Establishment and media routing 
> over a VoIPpeering interconnect.
> 
> Hello,
> 
> I read the proposed agenda of this WG and was wondering about the work
> on 
> 
> "In addition, the working group recognizes that
> there will be use cases that require SPEERMINT to focus on the
> interaction between the application layer and lower network
> layers, or the dependence of specific application layer use
> cases on lower layers, so SPEERMINT will have to be prepared to
> solve these problems as they arise."
> 
> 
> Is this WG going to tackle the problem where a 
> DNS/ENUM/whatever lookup
> decides the next-hop VoIP media takes on a VoIP peering 
> interconnection?
> 
> 
> 
> I'm not talking about end-to-end QoS, reservations or some all
> encompassing solution. It is the specific case of VoIP peering
> interconnect. 
> 
> For example, if two layer 3/5 devices are connected by many links, the
> result of a lookup during SIP Call establishment (between two VoIP
> domains), would direct media traffic for a certain call (or group of
> calls), over link A instead of B. 
> 
> Thanks,
> 
> Reinaldo
> 
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint



From speermint-bounces@ietf.org Tue Feb 28 01:21:18 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FDyEP-0008DN-8D; Tue, 28 Feb 2006 01:21:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FDyEO-0008DF-2T
	for speermint@ietf.org; Tue, 28 Feb 2006 01:21:08 -0500
Received: from pahula.nona.net ([193.80.224.123] helo=kahua.nona.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDyED-0007Dk-GA
	for speermint@ietf.org; Tue, 28 Feb 2006 01:21:08 -0500
Received: from [192.168.1.206] (85-124-83-46.dynamic.xdsl-line.inode.at
	[::ffff:85.124.83.46])
	(AUTH: PLAIN axelm, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
	by pahula with esmtp; Tue, 28 Feb 2006 07:20:52 +0100
	id 0006C002.4403EBC4.000010FA
Message-ID: <4403EBB8.3000607@enum.at>
Date: Tue, 28 Feb 2006 07:20:40 +0100
From: Alexander Mayrhofer <alexander.mayrhofer@enum.at>
Organization: enum.at GmbH
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: speermint@ietf.org
Content-Type: multipart/mixed; boundary="------------060403040806030901000007"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 25eb6223a37c19d53ede858176b14339
Subject: [Speermint] [Fwd: I-D ACTION:draft-lendl-domain-policy-ddds-00.txt]
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org

This is a multi-part message in MIME format.
--------------060403040806030901000007
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

fyi,

an I-D about policy announcement via DDDS.

cheers

Alex

--------------060403040806030901000007
Content-Type: message/rfc822;
	name="I-D ACTION:draft-lendl-domain-policy-ddds-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
	filename="I-D ACTION:draft-lendl-domain-policy-ddds-00.txt"

Received: from megatron.ietf.org (odin.ietf.org [::ffff:156.154.16.145])
	(TLS: TLSv1/SSLv3,256bits,AES256-SHA)
	by pahula with esmtp; Tue, 28 Feb 2006 01:20:24 +0100
	id 0006C002.44039748.000066B8
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FDs90-00040x-JY; Mon, 27 Feb 2006 18:51:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FDs7x-00023F-IS
	for i-d-announce@ietf.org; Mon, 27 Feb 2006 18:50:05 -0500
Received: from [156.154.16.129] (helo=cypress.neustar.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDs7u-0007JT-SQ
	for i-d-announce@ietf.org; Mon, 27 Feb 2006 18:50:05 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10])
	by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k1RNo20e016460
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <i-d-announce@ietf.org>; Mon, 27 Feb 2006 23:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FDs7u-0005jM-Dl
	for i-d-announce@ietf.org; Mon, 27 Feb 2006 18:50:02 -0500
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_pahula-26296-1141086024-0001-2"
To: i-d-announce@ietf.org
Cc: 
From: Internet-Drafts@ietf.org
Message-Id: <E1FDs7u-0005jM-Dl@stiedprstage1.ietf.org>
Date: Mon, 27 Feb 2006 18:50:02 -0500
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Subject: I-D ACTION:draft-lendl-domain-policy-ddds-00.txt 
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: internet-drafts@ietf.org
List-Id: i-d-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:i-d-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:i-d-announce@ietf.org>
List-Help: <mailto:i-d-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:i-d-announce-request@ietf.org?subject=subscribe>
Errors-To: i-d-announce-bounces@ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on pahula
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME 
	autolearn=no version=3.0.3

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_pahula-26296-1141086024-0001-2
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

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


	Title		: The Domain Policy DDDS Application
	Author(s)	: O. Lendl
	Filename	: draft-lendl-domain-policy-ddds-00.txt
	Pages		: 13
	Date		: 2006-2-27
	
   This documents proposes the use of the DNS to publish a domain's
   policy regarding incoming communication.  The algorithm used is
   defined as a new application of the Dynamic Delegation Discovery
   System (DDDS).  Such policy announcements can be used to facilitate
   selective SIP peering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lendl-domain-policy-ddds-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-lendl-domain-policy-ddds-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-lendl-domain-policy-ddds-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--=_pahula-26296-1141086024-0001-2
Content-Type: multipart/alternative;
	boundary="=_pahula-26296-1141086024-0001-3"

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_pahula-26296-1141086024-0001-3
Content-Type: message/external-body; access-type=mail-server;
	server="mailserv@ietf.org"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID: <2006-2-27155339.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-lendl-domain-policy-ddds-00.txt

--=_pahula-26296-1141086024-0001-3
Content-Type: message/external-body;
	name="draft-lendl-domain-policy-ddds-00.txt";
	site="ftp.ietf.org"; access-type=anon-ftp;
	directory=internet-drafts
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID: <2006-2-27155339.I-D@ietf.org>


--=_pahula-26296-1141086024-0001-3--

--=_pahula-26296-1141086024-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

--=_pahula-26296-1141086024-0001-2--

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

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

--------------060403040806030901000007--




From speermint-bounces@ietf.org Tue Feb 28 06:00:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FE2am-0005CA-Vp; Tue, 28 Feb 2006 06:00:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FE2al-00059n-0g
	for speermint@ietf.org; Tue, 28 Feb 2006 06:00:31 -0500
Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE2aj-0006r0-NF
	for speermint@ietf.org; Tue, 28 Feb 2006 06:00:30 -0500
Received: by mail.bofh.priv.at (Postfix, from userid 1000)
	id DFA231A3BF; Tue, 28 Feb 2006 12:00:26 +0100 (CET)
Date: Tue, 28 Feb 2006 12:00:26 +0100
From: Otmar Lendl <lendl@nic.at>
To: speermint@ietf.org
Subject: Re: [Speermint] [Fwd: I-D
	ACTION:draft-lendl-domain-policy-ddds-00.txt]
Message-ID: <20060228110026.GA32292@nic.at>
Mail-Followup-To: Otmar Lendl <lendl@nic.at>, speermint@ietf.org
References: <4403EBB8.3000607@enum.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4403EBB8.3000607@enum.at>
User-Agent: Mutt/1.5.6+20040907i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>,
	<mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org

On 2006/02/28 07:02, Alexander Mayrhofer <alexander.mayrhofer@enum.at> wrote:
> fyi,
> 
> an I-D about policy announcement via DDDS.
> 

This is the promised revision of draft-lendl-sip-peering-policy-00 (see
http://www1.ietf.org/mail-archive/web/speermint/current/msg00024.html).

Another I-D is winding its way through the ID-queue and describes
the federation concept.

I've modelled this draft after the ENUM RFC. The experience there
with the enumservice registration procedure has not been a terrible
good one, leading to draft-ietf-enum-enumservices-guide-00.txt.

I'd like to get some feedback whether I should use that ID as a
template to style the registration mechanism for policy-types
within the domain policy DDDS.

Comments anybody?

/ol
-- 
< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint