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 ; 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Software

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 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

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



Availability: Available for INSTANT download!
!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 42 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: 3D"5
(based on 47 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: 3D"5
(based on 32 reviews)

------=_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 ; Fri, 03 Feb 2006 06:18:31 +0300 Date: Thu, 02 Feb 2006 22:20:31 -0500 From: "Ronda Smith" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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: From: "Tiffanie Renee Darwish" 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 List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org wxRpPzn7S7WAeeFrUzF ----SqYAjf3zf517Ftx Content-Type: text/html; Content-Transfer-Encoding: quoted-printable VuTIKNIcDOkC8IIfOI


D

M





A





M



A=
 


ow


ic





do
=  




ac



ut
  
&n= bsp; V

nlo


ros





be
 



rom



ode
 
isi
 <= br> ad
 

oft





Acr
Pho
Cre<= br> Go
Ill

edi



sk 
 =  
= t Ou

Inst


 Win
 Off
 Off
&n= bsp;Ser
 Ser

obat
tosh
ativ
Live
ustr
=
a St
  Dr
  Fl

Auto
  =
r= On

antl
 

dows
ice
ice
ver
ver
 v7.
op C
e Su
 CS2
ator

udi= o
eamw
ash

CAD
 


li

y!


&= nbsp;X
 X
2K
2K
 2

0
S2
it
 1

 M
ea
MX

20
 

<= /td>

ne




P
P
3
3
K

Pr

e
=
1.

X
ve
 P

05
 

=

 <= br> Sto

 

 
Pro
Pro
Pro
Ent=
Pro

o

2

0 CS

2004
r 8
ro
=

 


re

Re
..

















 


 = ;&

t.
..

 $
 $
 $
 = ;$
 $

 $
 $
 $
 $
&nb= sp;$

 $
 $
 $
 
 $
&n= bsp;


 S

 P
..

27
49
59 79
66

44
59
11
39
49

99
39
= 54

37
 


av

ri
..

9.
9=
9.
9.
9.

9.
9.
99
9.
9.

9. 9.
9.

50
 


e

ce
..

= 00
00
00
00
00

00
00
.0
00
00
=
00
00
00

.0
 


Up

 <= br>









0






<= br> 0
 


 t

Ou
..

















 


90

Pr
..
9.
9.
9.
9.
9.

9.
9.
9.
9.
9.
9.
9.
9.

9.
 


= %

ic
..

99
99
99
99
99

99 99
99
99
99

99
99
99

95
 <= /b>


Of

e
.

















 

<= td width=3D18 height=3D231>


<= /b>f!

 Y
 .

 O
 O
 = ;O
 O
 O

 O
 O
 O
&nb= sp;O
 O

 O
 O
 O

Ov
&n= bsp;




ou
..

ve
ve
ve
ve=
ve

ve
ve
vr
ve
ve

ve
ve
ve
er
 

<= font face=3D"Courier New" size=3D2>


 S
..

r r
r
r
r

r
r
 $
r
r

r r
r

 $
 




av
.=

$2
$4
$5
$7
$7

$3
$5
10
$3 $4

$9
$3
$5

36
 



e
.

29
49
29
29
00

79
29 49
49
49

29
49
09

50
 

http://oembariga.com/?AaR6ijWas= 3nQJUaUJd9z4U

----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 ; 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Apologies that spam=20 is still making it onto the list by people cc'ing the list (as=20 non-subscribers).  We have escalated the problem to IETF = Secretariat=20 Services and they are investigating.  We hope this will be worked = out very=20 soon.  Thanks for your continued patience.
 
Regards
Jason=20 Livingood
------_=_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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: "David Meyer" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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 To: Stastny Richard 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

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

 

=3D>   RFC 3263 builds on that.  = Quote:

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

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

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

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

=3D>

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

=3D>   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=3Dtcp" 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-- --===============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: References: 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 Date: Sun, 5 Feb 2006 12:32:25 +0000 To: "Stafford, Matthew" , Otmar Lendl 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: lconroy References: <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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 ; 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 User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: David Meyer 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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 ; 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" To: "Richard Shockey" , "David Meyer" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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 , "Stafford, Matthew" , Otmar Lendl From: Tony Rutkowski In-Reply-To: <82A9B943-EEDE-49F4-B2D0-96FF6E162232@insensate.co.uk> References: <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: "'Tony Rutkowski'" , "'lconroy'" , "'Stafford, Matthew'" , "'Otmar Lendl'" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" To: , "Tony Rutkowski" , "lconroy" , "Stafford, Matthew" , "Otmar Lendl" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 User-Agent: Mail/News 1.5 (X11/20060119) MIME-Version: 1.0 To: "Pfautz, Penn L, NEO" 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 , lconroy X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Duane 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 , Tony Rutkowski X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" To: "Klaus Darilion" , "Duane" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, speermint@ietf.org, lconroy , Tony Rutkowski X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" To: "Klaus Darilion" , "Duane" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, speermint@ietf.org, lconroy , Tony Rutkowski 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 List-Unsubscribe: , List-Post: List-Help: List-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 User-Agent: Mail/News 1.5 (X11/20060119) MIME-Version: 1.0 To: Klaus Darilion 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 , Tony Rutkowski X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: "'Pfautz, Penn L, NEO'" , "'Klaus Darilion'" , "'Duane'" 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' , 'Tony Rutkowski' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: To: lconroy 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 RE: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows

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-- --===============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: To: Richard Shockey 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ------_=_NextPart_001_01C62C12.0D407780 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Enum] a suggestion re: using flags to distinguish post-ENUM = signaling f lows

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


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):
>>
>> =3D>   RFC 3263 builds on = that.  Quote:
>>
>> =3D>      If a = SIP proxy, redirect server, or registrar is to be contacted
>>
>> =3D>      = through the lookup of NAPTR records, there MUST be at least = three
>>
>> =3D>      = records - one with a "SIP+D2T" service field, one with a =
>> "SIP+D2U"
>>
>> =3D>      = service field, and one with a "SIPS+D2T" service = field.
>>
>> =3D>
>>
>> =3D>   This "MUST" = needs to be reconsidered in this context, as it forces
>>
>> =3D>   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=3Dtcp" 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=
>


--


 >>>>>>>>>>>>>>&= gt;>>>>>>>>>>>>>>>>>&= gt;>>>>>>>>>>>>>>>>>&= gt;>>
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&g= t; or
<mailto:richard.shockey(at= )neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<= ;<<<<<<<<<<<<<<<<<<= ;<<<<<<<<<<<<<<<<<<= ;<

------_=_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: To: Tony Rutkowski 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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_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 User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Stafford, Matthew" References: In-Reply-To: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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" To: "Stafford, Matthew" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: , "Pfautz, Penn L, NEO" , "Klaus Darilion" , "Duane" 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 , Tony Rutkowski X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" To: "Richard Shockey" , "Stafford, Matthew" X-Spam-Score: 0.8 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, speermint@ietf.org, lconroy 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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 User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stastny Richard 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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 User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stastny Richard 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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: To: Stastny Richard 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 RE: [Enum] a suggestion re: using flags to distinguish post-ENUM = signaling f lows

Richard-

=3D=3D=3D> What I want to have is SIP URI = portability too, or in other words: I =3D=3D=3D> want to have my sip = URI sip:richard@stastny.com

=3D=3D=3D> 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/E= CMA-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/E= CMA-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-- --===============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 User-Agent: Mail/News 1.5 (X11/20060119) MIME-Version: 1.0 To: "Stafford, Matthew" Subject: Re: [Speermint] RE: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows References: In-Reply-To: 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 , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: To: Stastny Richard 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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 RE: [Enum] a suggestion re: using flags to distinguish = post-ENUMsignaling f lows

Richard-

Regarding
=3D=3D> I thought E2U+sip:pstn
=3D=3D> 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

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

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

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

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=3Dyes/= no ?

E2U+sip:srv
or sip:a@example.com;srv=3Dyes/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





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


 >>>>>>>>>>>>>>&= gt;>>>>>>>>>>>>>>>>>&= gt;>>>>>>>>>>>>>>>>>&= gt;>>
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&g= t; 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-- --===============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 ; 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: Content-Transfer-Encoding: 7bit From: Marshall Eubanks 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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 ; 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 To: Marshall Eubanks Subject: Re: [Speermint] Speermint in the news Message-ID: <20060208034947.GA16207@1-4-5.net> References: <1139356535.333438.1ae4da5e2bb613d6.f7ba099@persist.google.com> Mime-Version: 1.0 In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > >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" To: "Stafford, Matthew" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 or=20 =20 ; =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 ; 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" To: "'Livingood, Jason'" , "'Pfautz, Penn L, NEO'" , "'Klaus Darilion'" , "'Duane'" 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' , 'Tony Rutkowski' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: , "Livingood, Jason" , "Klaus Darilion" , "Duane" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: speermint@ietf.org, lconroy , Tony Rutkowski X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: "'Pfautz, Penn L, NEO'" , "'Livingood, Jason'" , "'Klaus Darilion'" , "'Duane'" 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' , 'Tony Rutkowski' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: , "Pfautz, Penn L, NEO" , "Livingood, Jason" , "Klaus Darilion" , "Duane" X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable Cc: speermint@ietf.org, lconroy , Tony Rutkowski X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: "'Stastny Richard'" , "'Pfautz, Penn L, NEO'" , "'Livingood, Jason'" , "'Klaus Darilion'" , "'Duane'" 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' , 'Tony Rutkowski' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From: IESG Secretary Message-Id: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Jason Livingood Real-time Applications and Infrastruture Area Directors TBD Real-time Applications and Infrastructure Area Advisor: Allison Mankin 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 ; 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: "'Stastny Richard'" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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 To: Stastny Richard 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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: Thread-Topic: [Enum] RE: [Speermint] and are phone numbers aborkenaddressingsystem? Thread-Index: AcYrwI7+uWvK8J5uRVuyJ8CBkI74WgAJ7DSQAAKZZWAACOn2kAAqf85AAAHNxSAAATau0AABECRrAAMimxAAAea7nQABnNtA From: "Medhavi Bhatia" To: "Stastny Richard" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Stafford, Matthew" Subject: Re: [Speermint] RE: [Enum] a suggestion re: using flags to distinguish post-ENUMs ignaling f lows References: In-Reply-To: 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 , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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: Thread-Topic: Some clarifications Thread-Index: AcYtm4DRH5LB2zl2Sm+p1CwOMlEm8A== From: "Medhavi Bhatia" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

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:

 

In terms of drafts, it seems that the following drafts (even = though they are not WG docs) are under = consideration:

 

http://www.ietf.org/internet-drafts/draft-lendl-sip-peering-pol= icy-00.txt

ftp://ftp.rfc-editor.org/in-notes/internet-draft= s/draft-meyer-voipeer-terminology-01.txt

=

 

Am I accurate making this = assumption?

 

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

 

-Medhavi.

------_=_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 ; 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 To: Medhavi Bhatia Subject: Re: [Speermint] Some clarifications Message-ID: <20060209185832.GA32207@1-4-5.net> References: Mime-Version: 1.0 In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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: Thread-Topic: [Speermint] Some clarifications Thread-Index: AcYtqyWoxkHT8NLqRZ6unvyi2LNUpQABBnmQ From: "Medhavi Bhatia" To: "David Meyer" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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 User-Agent: Mail/News 1.5 (X11/20060119) MIME-Version: 1.0 To: Medhavi Bhatia Subject: Re: [Speermint] Some clarifications References: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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: Thread-Topic: [Speermint] Some clarifications Thread-Index: AcYts7ZhQwbv/R/IQTeZB5XQphoY+AAAIrzg From: "Medhavi Bhatia" To: "Duane" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: "Medhavi Bhatia" , "David Meyer" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: "Medhavi Bhatia" , "Duane" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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 User-Agent: Mail/News 1.5 (X11/20060119) MIME-Version: 1.0 To: Medhavi Bhatia Subject: Re: [Speermint] Some clarifications References: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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 Organization: enum.at GmbH User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Livingood, Jason" 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 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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 User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Livingood, Jason" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ 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 ; 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" To: "'Livingood, Jason'" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: "Livingood, Jason" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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 Subject: Re: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft In-reply-to: <6EEEACD9D7F52940BEE26F5467C02C7302A3A232@PACDCEXCMB01.cabl e.comcast.com> To: "Livingood, Jason" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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 ; 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 ; 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: Thread-Topic: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft Thread-Index: AcYwyp6mPCxD+lizQSSNpI4a4XXocgAbu3Aw From: "Romascanu, Dan \(Dan\)" To: "Livingood, Jason" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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 Organization: enum.at GmbH User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Livingood, Jason" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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: Thread-Topic: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft Thread-Index: AcYwyp6mPCxD+lizQSSNpI4a4XXocgAowkOQ From: "James McEachern" To: "Livingood, Jason" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: "Livingood, Jason" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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: Thread-Topic: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft Thread-Index: AcYwyp6mPCxD+lizQSSNpI4a4XXocgAwCXng From: "Bob Natale" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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 To: Bob Natale Subject: Re: [Speermint] wg hum? SPEERMINT Requirements and Terminology Draft Message-ID: <20060214180345.GA6443@1-4-5.net> References: Mime-Version: 1.0 In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Jason Livingood SECRETARY: Alexander Mayrhofer 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 ; 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > Jason Livingood >=20 > SECRETARY: Alexander Mayrhofer >=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 ; 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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 To: Stastny Richard 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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" To: "Stastny Richard" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > > Jason Livingood > >=20 > > SECRETARY: Alexander Mayrhofer > >=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: 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 To: "Pfautz, Penn L, NEO" Subject: Re: [Speermint] I-DACTION:draft-ietf-speermint-reqs-and-terminology-00.txt Message-ID: <20060220185326.GA26898@1-4-5.net> References: <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" To: "Pfautz, Penn L, NEO" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 To: Bob Natale 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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: 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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" To: "James McEachern" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" To: "James McEachern" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 To: James McEachern Subject: Re: [Speermint] I-DACTION:draft-ietf-speermint-reqs-and-terminology-01.txt Message-ID: <20060222155144.GA16567@1-4-5.net> References: Mime-Version: 1.0 In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" To: "Reinaldo Penno" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" To: "'Reinaldo Penno'" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ; 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: 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: , List-Post: List-Help: List-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 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 , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2006/02/28 07:02, Alexander Mayrhofer 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