From nobody Mon Jan 5 03:55:27 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A0E1A3BA0 for ; Mon, 5 Jan 2015 03:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZPhm1F7eS1S for ; Mon, 5 Jan 2015 03:55:24 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 39F321A2130 for ; Mon, 5 Jan 2015 03:55:24 -0800 (PST) Received: from [IPv6:2001:470:40b8:0:70bd:ccd8:860b:4125] (unknown [IPv6:2001:470:40b8:0:70bd:ccd8:860b:4125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 5BC172015D for ; Mon, 5 Jan 2015 12:55:23 +0100 (CET) Message-ID: <54AA7BA8.2090708@acm.org> Date: Mon, 05 Jan 2015 04:55:20 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: p2pSIP Mailing List References: <54535E65.6030408@acm.org> In-Reply-To: <54535E65.6030408@acm.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/p2psip/A8X4a3SoVQIJTBUHGfm2Xo5j2tk Subject: Re: [P2PSIP] Reload Interop event in July 2015 in Prague X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 11:55:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Second and last call for a RELOAD interop event in Europe next summer. So far only two teams are interested in participating in person, which is not enough. Thanks. On 10/31/2014 04:03 AM, Marc Petit-Huguenin wrote: > Hi, > > I would like to get an idea of how many people would be interested in > participating in person in a RELOAD interoperability event before the IETF > meeting in Prague, CZ (July 18 and 19 2015). > > If you are, please send me an email directly. > > Thanks. > > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUqnuoAAoJECnERZXWan7EI4oQAKqg3kZR8TR+dEoTjXEDNtUH MseJ/4tk3QaW8W8AP/2MwR22qMUO9qPkE46mbqQQrJnhFTAnXxIVLRXu2JMLnkNX GYQmk848GEemrjYzpi1YKAkZOSPw50xghTpEMqMxHVQsFS/GOg83I0YCw3d94b6v 9BveuTo+6K3/56CsBEZbq3Tumtgkl5IVIJy+G6NQI2eoYBUYYXoZgjG718kA2hit TAdiO4nJ02XoT0F3LcU3mtLcy0O4UqsfHP7rwg4nBovxC07xn17Y9TKLdo9SWXXX 5tLWJekNLaAV/UGztFdl9YBlJfeqE4vpMWn8yjLR86471thS2KHxvxnBKwtPo/Yj bzzG4escuv+6d6luRqds2XLSyo4Vhy2kyzoBcnpNNJw0vT5KV5Teu7piLczuPNF7 Pbf/Apjyvz/A7k6Ms5B39mp1A4nwsG1G0P9D7zNSADfoj3BQGxLYrBxG1QoVrioq lDlPnfvAX30B1JBMmnLsLUBBRsft31A4rHcASXxNi4Sx1Bg/ySOMeZVMA2oLMKhY oF2TJ5z843kppAiokPLFaD7kxCdH8ACSLRRNrqk01mKb6nB57U9d7fu8/+DnWmQz iP5oRZo4wiRQQImjxs017x2qSOVLsWbsIIgMtsoi4YofWmqjNqDXNPoyCi87707f qsDicRu+7lVuBMMHULma =Xff+ -----END PGP SIGNATURE----- From nobody Thu Jan 8 15:15:39 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238F91A01F0 for ; Thu, 8 Jan 2015 15:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N23fphkXA5dC for ; Thu, 8 Jan 2015 15:15:34 -0800 (PST) Received: from p3plwbeout03-02.prod.phx3.secureserver.net (p3plsmtp03-02-2.prod.phx3.secureserver.net [72.167.218.214]) by ietfa.amsl.com (Postfix) with ESMTP id B4F261A005C for ; Thu, 8 Jan 2015 15:15:34 -0800 (PST) Received: from localhost ([72.167.218.243]) by p3plwbeout03-02.prod.phx3.secureserver.net with bizsmtp id dbFZ1p0025FgiYg01bFZLo; Thu, 08 Jan 2015 16:15:33 -0700 X-SID: dbFZ1p0025FgiYg01 Received: (qmail 7823 invoked by uid 99); 8 Jan 2015 23:15:33 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_1c5d3ee4c490ab5bad3458e0452b6acd" To: "Marc Petit-Huguenin" , "p2pSIP Mailing List" From: "Michael Chen" In-Reply-To: <54AA7BA8.2090708@acm.org> Date: Thu, 08 Jan 2015 16:15:33 -0700 Message-Id: <20150108161533.59ca11a9ba9389561a029f06442e67fa.587481f6dc.mailapi@email03.secureserver.net> X-Originating-IP: 104.35.254.202 User-Agent: MailAPI X-Sender: michaelc@idssoftware.com Archived-At: Subject: Re: [P2PSIP] Reload Interop event in July 2015 in Prague X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 23:15:37 -0000 --=_1c5d3ee4c490ab5bad3458e0452b6acd Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Marc, =20 Do you think it is realistic to do remote inter-op? =20 Thanks =20 --Michael =20 --------- Original Message --------- Subject: Re: [P2PSIP] Reload Interop e= vent in July 2015 in Prague From: "Marc Petit-Huguenin" Date: 1/5/15 3:55 am To: "p2pSIP Mailing List" -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 =20 Second and last call for a RELOAD interop event in Europe next summer. So = far only two teams are interested in participating in person, which is not = enough. =20 Thanks. =20 On 10/31/2014 04:03 AM, Marc Petit-Huguenin wrote: > Hi, >=20 > I would like to get an idea of how many people would be interested in > participating in person in a RELOAD interoperability event before the IE= TF > meeting in Prague, CZ (July 18 and 19 2015). >=20 > If you are, please send me an email directly. >=20 > Thanks. >=20 >=20 =20 - --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 =20 iQIcBAEBCAAGBQJUqnuoAAoJECnERZXWan7EI4oQAKqg3kZR8TR+dEoTjXEDNtUH MseJ/4tk3QaW8W8AP/2MwR22qMUO9qPkE46mbqQQrJnhFTAnXxIVLRXu2JMLnkNX GYQmk848GEemrjYzpi1YKAkZOSPw50xghTpEMqMxHVQsFS/GOg83I0YCw3d94b6v 9BveuTo+6K3/56CsBEZbq3Tumtgkl5IVIJy+G6NQI2eoYBUYYXoZgjG718kA2hit TAdiO4nJ02XoT0F3LcU3mtLcy0O4UqsfHP7rwg4nBovxC07xn17Y9TKLdo9SWXXX 5tLWJekNLaAV/UGztFdl9YBlJfeqE4vpMWn8yjLR86471thS2KHxvxnBKwtPo/Yj bzzG4escuv+6d6luRqds2XLSyo4Vhy2kyzoBcnpNNJw0vT5KV5Teu7piLczuPNF7 Pbf/Apjyvz/A7k6Ms5B39mp1A4nwsG1G0P9D7zNSADfoj3BQGxLYrBxG1QoVrioq lDlPnfvAX30B1JBMmnLsLUBBRsft31A4rHcASXxNi4Sx1Bg/ySOMeZVMA2oLMKhY oF2TJ5z843kppAiokPLFaD7kxCdH8ACSLRRNrqk01mKb6nB57U9d7fu8/+DnWmQz iP5oRZo4wiRQQImjxs017x2qSOVLsWbsIIgMtsoi4YofWmqjNqDXNPoyCi87707f qsDicRu+7lVuBMMHULma =3DXff+ -----END PGP SIGNATURE----- =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip --=_1c5d3ee4c490ab5bad3458e0452b6acd Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Marc,
 
Do you think it is realistic to do remote inter-op?
 
Thanks
 
--Michael
 
--------- Original Message -----= ----
Subject: Re: [P2PSIP] Reload Interop event in July 2015 in Prague
From: "Marc Petit-Huguenin" <petithug@acm.org>
Date: 1/5/15 3:5= 5 am
To: "p2pSIP Mailing List" <p2psip@ietf.org>

----= -BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Second and l= ast call for a RELOAD interop event in Europe next summer. So far only two = teams are interested in participating in person, which is not enough.
=
Thanks.

On 10/31/2014 04:03 AM, Marc Petit-Huguenin wr= ote:
> Hi,
>
> I would like to get an idea of h= ow many people would be interested in
> participating in person in= a RELOAD interoperability event before the IETF
> meeting in Prag= ue, CZ (July 18 and 19 2015).
>
> If you are, please sen= d me an email directly.
>
> Thanks.
>
&g= t;

- --
Marc Petit-Huguenin
Email: marc@petit-hu= guenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: h= ttp://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUqnuoAAoJECnERZXWan7EI4oQAK= qg3kZR8TR+dEoTjXEDNtUH
MseJ/4tk3QaW8W8AP/2MwR22qMUO9qPkE46mbqQQrJnhFT= AnXxIVLRXu2JMLnkNX
GYQmk848GEemrjYzpi1YKAkZOSPw50xghTpEMqMxHVQsFS/GOg= 83I0YCw3d94b6v
9BveuTo+6K3/56CsBEZbq3Tumtgkl5IVIJy+G6NQI2eoYBUYYXoZgj= G718kA2hit
TAdiO4nJ02XoT0F3LcU3mtLcy0O4UqsfHP7rwg4nBovxC07xn17Y9TKLdo= 9SWXXX
5tLWJekNLaAV/UGztFdl9YBlJfeqE4vpMWn8yjLR86471thS2KHxvxnBKwtPo/= Yj
bzzG4escuv+6d6luRqds2XLSyo4Vhy2kyzoBcnpNNJw0vT5KV5Teu7piLczuPNF7 Pbf/Apjyvz/A7k6Ms5B39mp1A4nwsG1G0P9D7zNSADfoj3BQGxLYrBxG1QoVrioq
= lDlPnfvAX30B1JBMmnLsLUBBRsft31A4rHcASXxNi4Sx1Bg/ySOMeZVMA2oLMKhY
oF2= TJ5z843kppAiokPLFaD7kxCdH8ACSLRRNrqk01mKb6nB57U9d7fu8/+DnWmQz
iP5oRZo= 4wiRQQImjxs017x2qSOVLsWbsIIgMtsoi4YofWmqjNqDXNPoyCi87707f
qsDicRu+7lV= uBMMHULma
=3DXff+
-----END PGP SIGNATURE-----

____= ___________________________________________
P2PSIP mailing list
= P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
--=_1c5d3ee4c490ab5bad3458e0452b6acd-- From nobody Fri Jan 9 04:09:21 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606511A8785 for ; Fri, 9 Jan 2015 04:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThH47Lg1gnRI for ; Fri, 9 Jan 2015 04:09:17 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 45F7C1A8782 for ; Fri, 9 Jan 2015 04:09:17 -0800 (PST) Received: from [IPv6:2001:470:40b8:0:18c5:57e3:dd15:4ef7] (unknown [IPv6:2001:470:40b8:0:18c5:57e3:dd15:4ef7]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 4D574204BE; Fri, 9 Jan 2015 13:09:15 +0100 (CET) Message-ID: <54AFC4E7.5030707@acm.org> Date: Fri, 09 Jan 2015 05:09:11 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: Michael Chen , p2pSIP Mailing List References: <20150108161533.59ca11a9ba9389561a029f06442e67fa.587481f6dc.mailapi@email03.secureserver.net> In-Reply-To: <20150108161533.59ca11a9ba9389561a029f06442e67fa.587481f6dc.mailapi@email03.secureserver.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [P2PSIP] Reload Interop event in July 2015 in Prague X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 12:09:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Michael, On 01/08/2015 04:15 PM, Michael Chen wrote: > Marc, > > Do you think it is realistic to do remote inter-op? Learning from the Paris' interop experience, I think that we should not mix in-person and remote interop. Note that you can do remote interop at any time - I am sure that if you send an email to reload@implementers.org you will be able to find other people willing to do remote interop (and I still offer free accounts on my RELOAD configuration & enrollment service for this very purpose). Anyway there will probably be no in-person interop in Prague as so far there is only two participants (I no longer have a working implementation), and that is not worth reserving a meeting room and shipping the hardware required for this. Thanks. > > Thanks > > --Michael > > > --------- Original Message --------- > Subject: Re: [P2PSIP] Reload Interop event in July 2015 in Prague > From: "Marc Petit-Huguenin" > Date: 1/5/15 3:55 am > To: "p2pSIP Mailing List" > > Second and last call for a RELOAD interop event in Europe next summer. So far only two teams are interested in participating in person, which is not enough. > > Thanks. > > On 10/31/2014 04:03 AM, Marc Petit-Huguenin wrote: >> Hi, > >> I would like to get an idea of how many people would be interested in >> participating in person in a RELOAD interoperability event before the IETF >> meeting in Prague, CZ (July 18 and 19 2015). > >> If you are, please send me an email directly. > >> Thanks. > > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUr8TnAAoJECnERZXWan7EGI4P/jN7XvXF8xBmi6O7S5PVHRW+ ljr5fWxvMdLrcIddbf8D+wGyDBUDwCBqy3bLEGCeTuTJ1qacFDb5dmbspoToAfGJ SZ4FZ6P3V9x8i4siHiwG8hE7Y0RBiNQQSmrOK2LUT2JBebzQRzrI1wTuVFzBA/SY LjjJDB4s6x8WCTNlxlMftNHN+fBZmN9sXEUNf2aYwckDmOV1hdWpKoLEIEJPmHk/ cpWXpKZRZHMHXtl6ZKiEm0ozInNMhDPtDBr1nyJ0fPDmWj+4u/11FIthKDGeSje7 5HUAW4RJBgYvCBlYdswDo5QAUdbA+Hp3BKl5kuTx0JbFBfTLo+zFlebSEM8mAgMv Q/Laeh/BcHycfa0t89hrHnLlBUs7LPpX33IN+Wupa42g/E/JNBHDtLovZ8Xr+5Um qgVut9aX8ZKasFkgre8pWzt5YG6hVJl31eFIr32z2MK/A62kmAvdExPUs9pYnpP2 qvimb4RvMyZHiSMW6GcgPHIPCWEpEcjHncwXJ+KgZt1pw6VEzOfAFcMZjg7NEtjE 5nuWqpmK6oMbfQ4FRG6eiAbK9rqTBasXyjklyWCoLL3V8+cuHfNuvCSVBiPJDvCg 7/ZKLlyNrcJsc1ioSkJgya0VJ4fqNPku/Ak9WUl8dE3bUrHBN4XDeX9c+2n820Gj AfIPlhOIkK9ujH/TnIA6 =mMte -----END PGP SIGNATURE----- From nobody Fri Jan 23 00:09:40 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4846A1A904F; Fri, 23 Jan 2015 00:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYt9HEiN4xMw; Fri, 23 Jan 2015 00:09:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A7A1A903A; Fri, 23 Jan 2015 00:09:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150123080935.4605.51843.idtracker@ietfa.amsl.com> Date: Fri, 23 Jan 2015 00:09:35 -0800 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 08:09:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : P2P Overlay Diagnostics Authors : Haibin Song Jiang Xingfeng Roni Even David A. Bryan Yi Sun Filename : draft-ietf-p2psip-diagnostics-16.txt Pages : 29 Date : 2015-01-23 Abstract: This document describes mechanisms for P2P overlay diagnostics. It defines extensions to the RELOAD P2PSIP base protocol to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in P2PSIP overlay networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-diagnostics-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 23 11:25:28 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EA21ACED3 for ; Fri, 23 Jan 2015 11:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7q_5EdnLqbs1 for ; Fri, 23 Jan 2015 11:25:09 -0800 (PST) Received: from upbd19pa11.eemsg.mail.mil (upbd19pa11.eemsg.mail.mil [214.24.27.86]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4BE1ACED0 for ; Fri, 23 Jan 2015 11:25:06 -0800 (PST) X-EEMSG-Attachment-filename: smime.p7s Received: from edge-cols02.mail.mil ([131.64.104.103]) by upbd19pa11.eemsg.mail.mil with ESMTP; 23 Jan 2015 19:25:04 +0000 Received: from UCOLHPMO.easf.csd.disa.mil (131.64.104.43) by edge-cols02.mail.mil (131.64.104.103) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 23 Jan 2015 19:24:38 +0000 Received: from UCOLHPKT.easf.csd.disa.mil ([169.254.2.202]) by ucolhpmo.easf.csd.disa.mil ([131.64.104.43]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 19:24:38 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: "p2psip@ietf.org" Thread-Topic: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt Thread-Index: AQHQNuP00hLTrMrU1EWpqWeJ3iYkxpzOFKlw Date: Fri, 23 Jan 2015 19:24:38 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF724F6F55@ucolhpkt.easf.csd.disa.mil> References: <20150123080935.4605.51843.idtracker@ietfa.amsl.com> In-Reply-To: <20150123080935.4605.51843.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.22.14] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000F_01D03718.4F32DAA0" MIME-Version: 1.0 Archived-At: Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 19:25:11 -0000 ------=_NextPart_000_000F_01D03718.4F32DAA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Song, et al: I have one general question about the draft as follows: 1. Will these diagnostics collection by P2P RELOAD protocol as it is being extended be good enough for P2PSIP management? 2. Does it mean that we do not need any separate P2P Management Protocol (e.g. P2PSNMP aka like P2PSIP) for management P2PSIP network for all of its nodes that use P2PSIP protocol? BR/Radhika -----Original Message----- From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Friday, January 23, 2015 3:10 AM To: i-d-announce@ietf.org Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : P2P Overlay Diagnostics Authors : Haibin Song Jiang Xingfeng Roni Even David A. Bryan Yi Sun Filename : draft-ietf-p2psip-diagnostics-16.txt Pages : 29 Date : 2015-01-23 Abstract: This document describes mechanisms for P2P overlay diagnostics. It defines extensions to the RELOAD P2PSIP base protocol to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in P2PSIP overlay networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-diagnostics-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip ------=_NextPart_000_000F_01D03718.4F32DAA0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISjTCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEuDCCA6CgAwIBAgIDGpBfMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzEwHhcNMTQwOTE1MDAwMDAwWhcN MTcwOTE0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALVT rbd+Bi0u5R+vhGeuVvwE4jy3GZm+RANU3wfqsp9Oq7RJYUFCkOcOf2HSFXyOF9fYMIJYxpwyWyPd MLEQ2zJ9cCHtiWSdwAzfXVzSLZefdcBq44JapSCtNs6NHyB468dPBWCOLbsB5R1fhw/7Kx16eFEI VToykNwboBcl48bAJH/E42GeenZZhfBgJTrfYDIo1arlTw2XCqOxyeNxmHZ9N54F/Ay+vR8qewyI wf4pdYd9Hz4hSQ/cAM2ESzdTkGI5SZOSb5uLxtXn7CzUxDdIn09brcRV3tSnazEwP1hTwJ+BMrDS WLVrj8PaEHvrsMHPjgSO7pOIISUSPSn2kJcCAwEAAaOCAWMwggFfMB8GA1UdIwQYMBaAFIbxW2hv 3TDzlIJo1Ez3RB24ymiBMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMzEuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFPfgWqUBFSj+zRkYK8QdUScKB07UMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMzEu Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAlBgNVHREEHjAcgRpyYWRoaWth LnIucm95LmNpdkBtYWlsLm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMA0GCSqGSIb3 DQEBBQUAA4IBAQCg5mLhdie9Opv9asgcTKjz3wcYnoV72Sd8oYj37iaPVht1UIx+elPJV91q8i5B gq8gGaXlgGX+lTQgbhIKtyg/zeJrPQJI0A5ZN4TzfLqf4eUz5pqPh/hV9B8UbigUCW8wNbopPXYX Fu4fwMCOefKe7jx+kXrIUE+2fQtBRw9XaPzsOG0+XlCo6OdGVtkWkY5qmsNbitS78H8iEWSIhvAN dkJzWMhIOwmQ26F1k5DeWeGz7atyOcASJvobl3Xd6emCopMFKt8IoQtssdCmokDM5p6hqlWCVFRk TPVha4nOZH2u5Sj3Ax6lBtBUtWmGZ3jOpXdEtWj3avViyIDAl3aUMIIFAzCCA+ugAwIBAgIDGpBb MA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQx DDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzEwHhcN MTQwOTE1MDAwMDAwWhcNMTcwOTE0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5T LiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYw JAYDVQQDEx1ST1kuUkFESElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAKPCxD4WPTf6htWggvbIv9Zvq4sjmEBXhlX9wsCV8y94oumGlWiaX7GEFMHg lMWNjj58vz5bUzsL2rUCTxORuRR05b7G2wPFr2Q3ebUGAzLjcsTf3d50IxapuF7HYRzrJBSE7ft5 Rx6eBt1AofYBaS6t01CVi1MQHD3/FxeC0Ipow5A3SDbTNY9NSBVGpnnyX5B9yZ3fuhlgzLCZC+Oa iD278MrGeOhMpfeigL9QYypP1bPKPBbhSl/ZgPlf+0CqRrA4tHy/AHr6F1NYt7QlLgfIAQakKUMY H0B3ypI3+FZ/t08hzSHyloomjs+2oZROMXeaD8yCuehULxvMhYZvkGECAwEAAaOCAa4wggGqMB8G A1UdIwQYMBaAFIbxW2hv3TDzlIJo1Ez3RB24ymiBMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9j cmwuZGlzYS5taWwvY3JsL0RPREVNQUlMQ0FfMzEuY3JsMA4GA1UdDwEB/wQEAwIGwDAjBgNVHSAE HDAaMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGAbUYZkuBh8vML199Hbg7zD qi+eMGgGCCsGAQUFBwEBBFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWdu L0RPREVNQUlMQ0FfMzEuY2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDBFBgNV HREEPjA8gRpyYWRoaWthLnIucm95LmNpdkBtYWlsLm1pbKAeBgorBgEEAYI3FAIDoBAMDjEyOTE5 Mzk4MDFAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwKQYDVR0lBCIwIAYKKwYBBAGC NxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUAA4IBAQC9BhFhcZlxDQy+qExu ucegMi61cE1ux2iVlZxJY1FMQ9GAyUy4m4daGY4afM/MuGOIDAC/Ho+Y7rEGnwNYLUN5bKK7IfrT i/CcKJSKX3H/Nw6w7C4mFToUVP+j9WTZfQLhd/8JS1tq8LKJkjePpx2xNMD+cJFQ5x3E9BlBbgYk LU/8f1lM4EDQw2itc24FskmZwAMaa643iJylvMPQ5c9R1KtmsMSxlvZKFl5ENrxI3vkuHEdnz0QG IGSfuOLRA8g3uy2kiaCmGEYz7764mloTsKuuJkRNJka/As0L2tWR2QuVaGgQv6lTYDBhr1adxV7K G0yNn/jeN/auDAscX+lFMIIFUjCCBDqgAwIBAgICA58wDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQ S0kxFjAUBgNVBAMTDURvRCBSb290IENBIDIwHhcNMTMwMTE2MTQ1MjQzWhcNMTkwMTE2MTQ1MjQz WjBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0Qx DDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMxMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA6K4CLEBMOlLoi3OStHfnOEvA8KpKGFzH9zXDSvDwlnell74n78REIYDq FjS3MNFEOH8qzgTGkWWpblB8yE7+vcC1SxbkOFIV27O391M98rEH25FmXcG38ndmxFGaY5QRSwId DUt8swBHB3kY+nizkx/Udm2ZBMUeNkb8BjQL42hvHnyfLM9huEv/tN8Gn6BflF7rNf8JXTVAB/Kd 7ZYJ2Xbq/m4x/sv0ResweEhobKEpPoZ9k0FK6ucMTOWRUCqlQ2a8IsD8Gyzk8y9iHgTUIb+sHyZ3 NdAdvOK7RsLy6+QUrviza7P6cTiwcSnt0Ysb1wIb3srsfu6h3Eil8T6UqQIDAQABo4ICHDCCAhgw HQYDVR0OBBYEFIbxW2hv3TDzlIJo1Ez3RB24ymiBMB8GA1UdIwQYMBaAFEl0uwxeunr+AlTve6DG lcYJgHCWMBIGA1UdEwEB/wQIMAYBAf8CAQAwDAYDVR0kBAUwA4ABADAOBgNVHQ8BAf8EBAMCAYYw ZgYDVR0gBF8wXTALBglghkgBZQIBCwUwCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELETALBglghkgB ZQIBCxIwCwYJYIZIAWUCAQsTMAwGCmCGSAFlAwIBAxowDAYKYIZIAWUDAgEDGzA3BgNVHR8EMDAu MCygKqAohiZodHRwOi8vY3JsLmRpc2EubWlsL2NybC9ET0RST09UQ0EyLmNybDCCAQEGCCsGAQUF BwEBBIH0MIHxMDoGCCsGAQUFBzAChi5odHRwOi8vY3JsLmRpc2EubWlsL2lzc3VlZHRvL0RPRFJP T1RDQTJfSVQucDdjMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDCBkAYIKwYBBQUH MAKGgYNsZGFwOi8vY3JsLmdkcy5kaXNhLm1pbC9jbiUzZERvRCUyMFJvb3QlMjBDQSUyMDIlMmNv dSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2Nyb3Nz Q2VydGlmaWNhdGVQYWlyO2JpbmFyeTANBgkqhkiG9w0BAQUFAAOCAQEAWTKtqsP435xknHEJNMG9 vGMAHi3b7anICOO5GOSvyq4Uwd27+XODg1eOlMmgqgMHzmecteUXWT8ouBc22rqNw5YRAWpQ1gba aKRK0guFfM2I3/9ed+b1pEiR0E6iZ2r4aO+qF0Xv2JYK3c/wPoe2v4g/01S+PhLOofkLbzLRVL+E WzWg2wdktavpeR7i8qp0cueREvfHu27u5XSQECSLt+fNnIWQR+Tib38gvSy7g5YjTahM2H4uXhUp uCV9VzULLRVUjKnc4OU3nahPIJWDK8USNj2oc+FOiEmlubv6CUooWjO55JJ5W3v4pU/zyTTNmYyw umB+n4Q+5jz6flrr5jGCAv4wggL6AgEBMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0zMQIDGpBbMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE1MDEyMzE5MjQzNFowIwYJKoZIhvcNAQkEMRYEFJFuuwxLO6YMHtVIwDf4 MwpKcH99MCQGCSqGSIb3DQEJDzEXMBUwCgYIKoZIhvcNAwcwBwYFKw4DAhowcwYJKwYBBAGCNxAE MWYwZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNE b0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMxAgMakF8wdQYLKoZIhvcN AQkQAgsxZqBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNV BAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzECAxqQXzANBgkq hkiG9w0BAQEFAASCAQAYXBLCr8MKPZKe8ip6KwZMeAvRqmDkQ3QqtWAJQ2GUT60sqqrfNxY47eRQ x6XIQI5meut96kcminQ17fopbw1nnpciEJwXNDv73qXdx3wBPV14qwX0Ag5c5TJeYP/JwzaZfQaD W0al2QQbdZCsUsXu5LiExdh9iHoBpvUP5I4sluW3vc5GrZjZvs3XSeBekuoKBOg8LdyMDy/MlS0l w0YnPdVguaSBZWf9RjI5GFgHQenrU1bScHHYP5npt165kScYmE0z5PGlh+giUYTdOLmhUEJ0s8JJ VYaqclSvIBZhe/+LRn0aQ9lW3ZKdaAikmVjz2Rhig8FGq6G6LimysyQWAAAAAAAA ------=_NextPart_000_000F_01D03718.4F32DAA0-- From nobody Sun Jan 25 16:38:32 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5211A1AFC for ; Sun, 25 Jan 2015 16:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1xRsJKtPo6i for ; Sun, 25 Jan 2015 16:38:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665441A1AB3 for ; Sun, 25 Jan 2015 16:38:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRS53755; Mon, 26 Jan 2015 00:38:23 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 Jan 2015 00:38:22 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.146]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 26 Jan 2015 08:38:15 +0800 From: "Songhaibin (A)" To: "Roy, Radhika R CIV USARMY (US)" , "p2psip@ietf.org" Thread-Topic: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt Thread-Index: AQHQNuP49RwG5d6TQUagStguaRu7V5zNkJAAgAQBYfA= Date: Mon, 26 Jan 2015 00:38:14 +0000 Message-ID: References: <20150123080935.4605.51843.idtracker@ietfa.amsl.com> <8486C8728176924BAF5BDB2F7D7EEDDF724F6F55@ucolhpkt.easf.csd.disa.mil> In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF724F6F55@ucolhpkt.easf.csd.disa.mil> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 00:38:29 -0000 Hi Roy, > -----Original Message----- > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of Roy, Radhika R > CIV USARMY (US) > Sent: Saturday, January 24, 2015 3:25 AM > To: p2psip@ietf.org > Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt >=20 > Hi, Song, et al: >=20 > I have one general question about the draft as follows: >=20 > 1. Will these diagnostics collection by P2P RELOAD protocol as it is bein= g > extended be good enough for P2PSIP management? It is considered useful for diagnostics at this moment. There can be future= extensions. It is not a full set. > 2. Does it mean that we do not need any separate P2P Management Protocol > (e.g. P2PSNMP aka like P2PSIP) for management P2PSIP network for all of i= ts > nodes that use P2PSIP protocol? IMO P2P network management and diagnostics are two different concepts, and = you can have other protocols/extensions for management. -Haibin > BR/Radhika >=20 > -----Original Message----- > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, January 23, 2015 3:10 AM > To: i-d-announce@ietf.org > Cc: p2psip@ietf.org > Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.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 Peer-to-Peer Session Initiation Protoco= l > Working Group of the IETF. >=20 > Title : P2P Overlay Diagnostics > Authors : Haibin Song > Jiang Xingfeng > Roni Even > David A. Bryan > Yi Sun > Filename : draft-ietf-p2psip-diagnostics-16.txt > Pages : 29 > Date : 2015-01-23 >=20 > Abstract: > This document describes mechanisms for P2P overlay diagnostics. It > defines extensions to the RELOAD P2PSIP base protocol to collect > diagnostic information, and details the protocol specifications for > these extensions. Useful diagnostic information for connection and > node status monitoring is also defined. The document also describes > the usage scenarios and provides examples of how these methods are > used to perform diagnostics in P2PSIP overlay networks. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-16 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-diagnostics-16 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From nobody Mon Jan 26 05:07:38 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8941A8A70 for ; Mon, 26 Jan 2015 05:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHUnNl7fSlxW for ; Mon, 26 Jan 2015 05:07:32 -0800 (PST) Received: from upbd19pa14.eemsg.mail.mil (upbd19pa14.eemsg.mail.mil [214.24.27.89]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8431A1A39 for ; Mon, 26 Jan 2015 05:07:30 -0800 (PST) X-EEMSG-Attachment-filename: smime.p7s Received: from unknown (HELO edge-cols02.mail.mil) ([131.64.104.102]) by upbd19pa14.eemsg.mail.mil with ESMTP; 26 Jan 2015 13:07:25 +0000 Received: from UCOLHPMJ.easf.csd.disa.mil (131.64.104.38) by edge-cols02.mail.mil (131.64.104.102) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 26 Jan 2015 13:07:12 +0000 Received: from UCOLHPKT.easf.csd.disa.mil ([169.254.2.202]) by ucolhpmj.easf.csd.disa.mil ([131.64.104.38]) with mapi id 14.03.0195.001; Mon, 26 Jan 2015 13:07:11 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: "Songhaibin (A)" , "p2psip@ietf.org" Thread-Topic: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt Thread-Index: AQHQNuP00hLTrMrU1EWpqWeJ3iYkxpzOFKlwgAN+SwCAAM9csA== Date: Mon, 26 Jan 2015 13:07:11 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF724F71A6@ucolhpkt.easf.csd.disa.mil> References: <20150123080935.4605.51843.idtracker@ietfa.amsl.com> <8486C8728176924BAF5BDB2F7D7EEDDF724F6F55@ucolhpkt.easf.csd.disa.mil> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.22.14] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0034_01D0393F.1320BD60" MIME-Version: 1.0 Archived-At: Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 13:07:36 -0000 ------=_NextPart_000_0034_01D0393F.1320BD60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Haibin: Great! Yes, I also thought the same. We are looking for full management set for P2PSIP. We saw one proposal P2PSNMP draft some time ago. Why did that draft authors not continue? Or, will people create extensions one after another until the full set for P2PSIP management available? BR/Radhika -----Original Message----- From: Songhaibin (A) [mailto:haibin.song@huawei.com] Sent: Sunday, January 25, 2015 7:38 PM To: Roy, Radhika R CIV USARMY (US); p2psip@ietf.org Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt Hi Roy, > -----Original Message----- > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of Roy, > Radhika R CIV USARMY (US) > Sent: Saturday, January 24, 2015 3:25 AM > To: p2psip@ietf.org > Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > Hi, Song, et al: > > I have one general question about the draft as follows: > > 1. Will these diagnostics collection by P2P RELOAD protocol as it is > being extended be good enough for P2PSIP management? It is considered useful for diagnostics at this moment. There can be future extensions. It is not a full set. > 2. Does it mean that we do not need any separate P2P Management > Protocol (e.g. P2PSNMP aka like P2PSIP) for management P2PSIP network > for all of its nodes that use P2PSIP protocol? IMO P2P network management and diagnostics are two different concepts, and you can have other protocols/extensions for management. -Haibin > BR/Radhika > > -----Original Message----- > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, January 23, 2015 3:10 AM > To: i-d-announce@ietf.org > Cc: p2psip@ietf.org > Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Peer-to-Peer Session Initiation > Protocol Working Group of the IETF. > > Title : P2P Overlay Diagnostics > Authors : Haibin Song > Jiang Xingfeng > Roni Even > David A. Bryan > Yi Sun > Filename : draft-ietf-p2psip-diagnostics-16.txt > Pages : 29 > Date : 2015-01-23 > > Abstract: > This document describes mechanisms for P2P overlay diagnostics. It > defines extensions to the RELOAD P2PSIP base protocol to collect > diagnostic information, and details the protocol specifications for > these extensions. Useful diagnostic information for connection and > node status monitoring is also defined. The document also describes > the usage scenarios and provides examples of how these methods are > used to perform diagnostics in P2PSIP overlay networks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-16 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-diagnostics-16 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip ------=_NextPart_000_0034_01D0393F.1320BD60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISjTCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEuDCCA6CgAwIBAgIDGpBfMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzEwHhcNMTQwOTE1MDAwMDAwWhcN MTcwOTE0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALVT rbd+Bi0u5R+vhGeuVvwE4jy3GZm+RANU3wfqsp9Oq7RJYUFCkOcOf2HSFXyOF9fYMIJYxpwyWyPd MLEQ2zJ9cCHtiWSdwAzfXVzSLZefdcBq44JapSCtNs6NHyB468dPBWCOLbsB5R1fhw/7Kx16eFEI VToykNwboBcl48bAJH/E42GeenZZhfBgJTrfYDIo1arlTw2XCqOxyeNxmHZ9N54F/Ay+vR8qewyI wf4pdYd9Hz4hSQ/cAM2ESzdTkGI5SZOSb5uLxtXn7CzUxDdIn09brcRV3tSnazEwP1hTwJ+BMrDS WLVrj8PaEHvrsMHPjgSO7pOIISUSPSn2kJcCAwEAAaOCAWMwggFfMB8GA1UdIwQYMBaAFIbxW2hv 3TDzlIJo1Ez3RB24ymiBMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMzEuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFPfgWqUBFSj+zRkYK8QdUScKB07UMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMzEu Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAlBgNVHREEHjAcgRpyYWRoaWth LnIucm95LmNpdkBtYWlsLm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMA0GCSqGSIb3 DQEBBQUAA4IBAQCg5mLhdie9Opv9asgcTKjz3wcYnoV72Sd8oYj37iaPVht1UIx+elPJV91q8i5B gq8gGaXlgGX+lTQgbhIKtyg/zeJrPQJI0A5ZN4TzfLqf4eUz5pqPh/hV9B8UbigUCW8wNbopPXYX Fu4fwMCOefKe7jx+kXrIUE+2fQtBRw9XaPzsOG0+XlCo6OdGVtkWkY5qmsNbitS78H8iEWSIhvAN dkJzWMhIOwmQ26F1k5DeWeGz7atyOcASJvobl3Xd6emCopMFKt8IoQtssdCmokDM5p6hqlWCVFRk TPVha4nOZH2u5Sj3Ax6lBtBUtWmGZ3jOpXdEtWj3avViyIDAl3aUMIIFAzCCA+ugAwIBAgIDGpBb MA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQx DDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzEwHhcN MTQwOTE1MDAwMDAwWhcNMTcwOTE0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5T LiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYw JAYDVQQDEx1ST1kuUkFESElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAKPCxD4WPTf6htWggvbIv9Zvq4sjmEBXhlX9wsCV8y94oumGlWiaX7GEFMHg lMWNjj58vz5bUzsL2rUCTxORuRR05b7G2wPFr2Q3ebUGAzLjcsTf3d50IxapuF7HYRzrJBSE7ft5 Rx6eBt1AofYBaS6t01CVi1MQHD3/FxeC0Ipow5A3SDbTNY9NSBVGpnnyX5B9yZ3fuhlgzLCZC+Oa iD278MrGeOhMpfeigL9QYypP1bPKPBbhSl/ZgPlf+0CqRrA4tHy/AHr6F1NYt7QlLgfIAQakKUMY H0B3ypI3+FZ/t08hzSHyloomjs+2oZROMXeaD8yCuehULxvMhYZvkGECAwEAAaOCAa4wggGqMB8G A1UdIwQYMBaAFIbxW2hv3TDzlIJo1Ez3RB24ymiBMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9j cmwuZGlzYS5taWwvY3JsL0RPREVNQUlMQ0FfMzEuY3JsMA4GA1UdDwEB/wQEAwIGwDAjBgNVHSAE HDAaMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGAbUYZkuBh8vML199Hbg7zD qi+eMGgGCCsGAQUFBwEBBFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWdu L0RPREVNQUlMQ0FfMzEuY2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDBFBgNV HREEPjA8gRpyYWRoaWthLnIucm95LmNpdkBtYWlsLm1pbKAeBgorBgEEAYI3FAIDoBAMDjEyOTE5 Mzk4MDFAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwKQYDVR0lBCIwIAYKKwYBBAGC NxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUAA4IBAQC9BhFhcZlxDQy+qExu ucegMi61cE1ux2iVlZxJY1FMQ9GAyUy4m4daGY4afM/MuGOIDAC/Ho+Y7rEGnwNYLUN5bKK7IfrT i/CcKJSKX3H/Nw6w7C4mFToUVP+j9WTZfQLhd/8JS1tq8LKJkjePpx2xNMD+cJFQ5x3E9BlBbgYk LU/8f1lM4EDQw2itc24FskmZwAMaa643iJylvMPQ5c9R1KtmsMSxlvZKFl5ENrxI3vkuHEdnz0QG IGSfuOLRA8g3uy2kiaCmGEYz7764mloTsKuuJkRNJka/As0L2tWR2QuVaGgQv6lTYDBhr1adxV7K G0yNn/jeN/auDAscX+lFMIIFUjCCBDqgAwIBAgICA58wDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQ S0kxFjAUBgNVBAMTDURvRCBSb290IENBIDIwHhcNMTMwMTE2MTQ1MjQzWhcNMTkwMTE2MTQ1MjQz WjBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0Qx DDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMxMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA6K4CLEBMOlLoi3OStHfnOEvA8KpKGFzH9zXDSvDwlnell74n78REIYDq FjS3MNFEOH8qzgTGkWWpblB8yE7+vcC1SxbkOFIV27O391M98rEH25FmXcG38ndmxFGaY5QRSwId DUt8swBHB3kY+nizkx/Udm2ZBMUeNkb8BjQL42hvHnyfLM9huEv/tN8Gn6BflF7rNf8JXTVAB/Kd 7ZYJ2Xbq/m4x/sv0ResweEhobKEpPoZ9k0FK6ucMTOWRUCqlQ2a8IsD8Gyzk8y9iHgTUIb+sHyZ3 NdAdvOK7RsLy6+QUrviza7P6cTiwcSnt0Ysb1wIb3srsfu6h3Eil8T6UqQIDAQABo4ICHDCCAhgw HQYDVR0OBBYEFIbxW2hv3TDzlIJo1Ez3RB24ymiBMB8GA1UdIwQYMBaAFEl0uwxeunr+AlTve6DG lcYJgHCWMBIGA1UdEwEB/wQIMAYBAf8CAQAwDAYDVR0kBAUwA4ABADAOBgNVHQ8BAf8EBAMCAYYw ZgYDVR0gBF8wXTALBglghkgBZQIBCwUwCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELETALBglghkgB ZQIBCxIwCwYJYIZIAWUCAQsTMAwGCmCGSAFlAwIBAxowDAYKYIZIAWUDAgEDGzA3BgNVHR8EMDAu MCygKqAohiZodHRwOi8vY3JsLmRpc2EubWlsL2NybC9ET0RST09UQ0EyLmNybDCCAQEGCCsGAQUF BwEBBIH0MIHxMDoGCCsGAQUFBzAChi5odHRwOi8vY3JsLmRpc2EubWlsL2lzc3VlZHRvL0RPRFJP T1RDQTJfSVQucDdjMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDCBkAYIKwYBBQUH MAKGgYNsZGFwOi8vY3JsLmdkcy5kaXNhLm1pbC9jbiUzZERvRCUyMFJvb3QlMjBDQSUyMDIlMmNv dSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2Nyb3Nz Q2VydGlmaWNhdGVQYWlyO2JpbmFyeTANBgkqhkiG9w0BAQUFAAOCAQEAWTKtqsP435xknHEJNMG9 vGMAHi3b7anICOO5GOSvyq4Uwd27+XODg1eOlMmgqgMHzmecteUXWT8ouBc22rqNw5YRAWpQ1gba aKRK0guFfM2I3/9ed+b1pEiR0E6iZ2r4aO+qF0Xv2JYK3c/wPoe2v4g/01S+PhLOofkLbzLRVL+E WzWg2wdktavpeR7i8qp0cueREvfHu27u5XSQECSLt+fNnIWQR+Tib38gvSy7g5YjTahM2H4uXhUp uCV9VzULLRVUjKnc4OU3nahPIJWDK8USNj2oc+FOiEmlubv6CUooWjO55JJ5W3v4pU/zyTTNmYyw umB+n4Q+5jz6flrr5jGCAv4wggL6AgEBMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0zMQIDGpBbMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE1MDEyNjEzMDcwNlowIwYJKoZIhvcNAQkEMRYEFGpOVC9FknV4agL7phqa jal0ZEw3MCQGCSqGSIb3DQEJDzEXMBUwCgYIKoZIhvcNAwcwBwYFKw4DAhowcwYJKwYBBAGCNxAE MWYwZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNE b0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMxAgMakF8wdQYLKoZIhvcN AQkQAgsxZqBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNV BAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzECAxqQXzANBgkq hkiG9w0BAQEFAASCAQAeeCUHDtnY0OA1gQnhOY5kSouPlO730KtlR5Xo7oIWSzcsVi76TjbeXSzV jlfVdkFPl734Odya2sG3Q6vsblfGKuOIZoSe072tJHj0IWBQ87xh6AFAILEI1bPZTFH1ssDo8iay lhkQW/90LyU1jb8/cg590FYa2+cz7F7vFI2agx/LVy8ZSGzoyIXbHPAT6OKLLlGZFaZNraToIo7+ rLCdzl0PHjD/5EbGyALS3Xgltz/pY2OMOPJvGV8+IYsneZGp6BsvUMVI1Xnto38VfiatQ2XHMXUf 8E2/1VoUwc0ESQYuhxCaEu2i/mBaj44U7+5abyTMJE5n2t2Oivnv5db+AAAAAAAA ------=_NextPart_000_0034_01D0393F.1320BD60-- From nobody Tue Jan 27 10:54:09 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31201A8915 for ; Tue, 27 Jan 2015 10:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9oans9INhdl for ; Tue, 27 Jan 2015 10:54:03 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A231A8924 for ; Tue, 27 Jan 2015 10:53:52 -0800 (PST) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 98D89152783E; Tue, 27 Jan 2015 19:53:48 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 836461525B85; Tue, 27 Jan 2015 19:53:48 +0100 (CET) Message-ID: <1422384828.2887.43.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: p2psip@ietf.org Date: Tue, 27 Jan 2015 19:53:48 +0100 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1018-21288.001 X-TM-AS-Result: No--5.001-7.0-31-1 X-imss-scan-details: No--5.001-7.0-31-1 Archived-At: Cc: p2psip-chairs@tools.ietf.org Subject: [P2PSIP] WGLC for draft-ietf-p2psip-diagnostics-16 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 18:54:07 -0000 Hi, Hereby we are issuing a WGLC for draft-ietf-p2psip-diagnostics-16. The WGLC will be open till the 16th of February. We kindly ask the WG to review the document and provide comments. If you have no comments and think the document is ready to be submitted to IESG, please do send a note stating that to the WG ML. Note that if we don't get some responses to this WGLC showing enough energy & interest to progress this document, we would abandon it. Additional information about the document is below: Title : P2P Overlay Diagnostics Authors : Haibin Song Jiang Xingfeng Roni Even David A. Bryan Yi Sun Filename : draft-ietf-p2psip-diagnostics-16.txt Pages : 29 Date : 2015-01-23 Abstract: This document describes mechanisms for P2P overlay diagnostics. It defines extensions to the RELOAD P2PSIP base protocol to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in P2PSIP overlay networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-16 Thanks -- Brian and Carlos From nobody Tue Jan 27 10:54:16 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40A61A8708 for ; Tue, 27 Jan 2015 10:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tto7h2oWsyf4 for ; Tue, 27 Jan 2015 10:54:09 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524161A88DB for ; Tue, 27 Jan 2015 10:54:09 -0800 (PST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CE500981B04; Tue, 27 Jan 2015 19:54:06 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id C231098182C; Tue, 27 Jan 2015 19:54:06 +0100 (CET) Message-ID: <1422384846.2887.44.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: p2psip@ietf.org Date: Tue, 27 Jan 2015 19:54:06 +0100 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1018-21288.001 X-TM-AS-Result: No--6.712-7.0-31-1 X-imss-scan-details: No--6.712-7.0-31-1 Archived-At: Cc: p2psip-chairs@tools.ietf.org Subject: [P2PSIP] WGLC for draft-ietf-p2psip-share-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 18:54:12 -0000 Hi, Hereby we are issuing a WGLC for draft-ietf-p2psip-share-04. The WGLC will be open till the 16th of February. We kindly ask the WG to review the document and provide comments. We did one last year and we didn't get any comments, which is not acceptable if we want to progress the document. If you have no comments and think the document is ready to be submitted to IESG, please do send a note stating that to the WG ML. Note that if we don't get some responses to this WGLC showing enough energy & interest to progress this document, we would abandon it. Additional information about the document is below: Title : A Usage for Shared Resources in RELOAD (ShaRe) Authors : Alexander Knauf Thomas C. Schmidt Gabriel Hege Matthias Waehlisch Filename : draft-ietf-p2psip-share-04.txt Pages : 20 Date : 2014-08-29 Abstract: This document defines a RELOAD Usage for managing shared write access to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name which is useful whenever peer-independent rendezvous processes are required. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-share-04 Thanks -- Brian and Carlos From nobody Tue Jan 27 10:56:51 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648531A891F for ; Tue, 27 Jan 2015 10:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNRD8FASG6_v for ; Tue, 27 Jan 2015 10:56:43 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ABCE1A88DB for ; Tue, 27 Jan 2015 10:56:43 -0800 (PST) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 64F1B15278F1; Tue, 27 Jan 2015 19:56:41 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 4A1F31527622; Tue, 27 Jan 2015 19:56:41 +0100 (CET) Message-ID: <1422385001.2887.45.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Thomas C. Schmidt" Date: Tue, 27 Jan 2015 19:56:41 +0100 In-Reply-To: <54C6074B.9030405@fu-berlin.de> References: <1406307002.10492.15.camel@acorde.it.uc3m.es> <6a8b56a123154be2a448292dde8aa4d5@HUB02.mailcluster.haw-hamburg.de> <54C6074B.9030405@fu-berlin.de> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1018-21288.001 X-TM-AS-Result: No--21.709-7.0-31-1 X-imss-scan-details: No--21.709-7.0-31-1 Archived-At: Cc: "p2psip-chairs@tools.ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-13 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 18:56:48 -0000 Hi Thomas, Can you please post a revised version of the draft including these changes. Carlos On Mon, 2015-01-26 at 10:22 +0100, Thomas C. Schmidt wrote: > Hi Roland, > > apologies for the very late pick-up of the subject. > > Please see answers inline: > > On 06.09.2014 01:46, Roland Bless wrote: > > > I carefully read the document and didn't find any real show stoppers, > > but IMHO the document would benefit from some clarifications > > as indicated below. > > > > Major: > > - Normally a SIP registration times out after some period > > (usually given in the REGISTER message) > > I guess that the mechanism is replaced in P2PSIP by the > > lifetime parameter in the StoredData. If this is the case > > I'd like to see it mentioned explicitly. > > > > Yes, you are right. We added in Section 3.1: > > "Note that > the registration lifetime known from the regular SIP REGISTER method > is inherited from the lifetime attribute of the basic RELOAD > StoredData structure (see Section 7 in [RFC6940])." > > > - It is unclear how SIP and SIPS should be realized, because > > AppAttach only allows to create DTLS/UDP or TLS/TCP connections > > (cf. OverlayLinkType in IceCandidate). > > "Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted > > SIP messages over the connection as in normal SIP." > > Sending "plain" (I guess non-secured) SIP message is not possible > > if AppAttach doesn't allow for UDP-only connections. > > > > This may be somewhat confusing: Plain SIP sends SIP messages "plainly" > over transport, while SIPS requires the presence of transport layer > security. As the current Reload Link Layer is built on (D)TLS secure > Internet transport, there is actually always some transport layer > security established within the KBR region. However, this should not > prevent users to make "plain SIP" calls using plain SIP URIs, and SIPS > requires end-to-end transport security that include endpoint > certificates and protected links to clients. > > We've added the following clarification: > > "It is noteworthy that according to [RFC6940] all overlay links are > built on (D)TLS secured transport. While hop-wise encrypted paths > does not prevent the use of plain SIP, SIPS requires end-to-end > protection that may include client links and endpoint certificates." > > > > > - I guess that the destination list should contain only > > NodeIDs, or are ResourceIds and OpaqueIDs also permitted? > > If not, then the calling/initiating peer should check > > that condition and some action must be defined if the > > destination list is non-conforming (maybe discard > > this destination list) > > > > - The Draft should clearly specify how to map AORs > > to Resource-IDs as required by RFC6940, sec. 5.2: > > o Define how the Resource Name is used to form the Resource-ID where > > each Kind is stored. > > I guess that the AOR is mapped by using the overlay hash function > > after stripping the scheme (like sip:, sips:) from it. But that > > should be defined explicitly. > > > > Minor: > > Sec. 1: > > - Several different notations like 'Node-ID "1234"', Node-ID 1234 > > or ID 1234 are used in this section. > > > > Sec. 2: > > OLD: include the scheme (e.g sip:) as the AOR needs to match the > > NEW: include the scheme (e.g. sip:) as the AOR needs to match the > > > > Sec. 3.3: > > > > o A Store is permitted only for AORs with domain names that fall > > into the namespaces supported by the RELOAD overlay instance. > > > > and then > > > > Before issuing a Store request to the overlay, any peer SHOULD verify > > that the AOR of the request is a valid Resource Name with respect to > > its domain name and the namespaces defined in the overlay > > configuration document (see Section 3.4). > > > > the first formulation suggests that the latter quotation should use > > rather MUST than SHOULD (the Storing Peer MUST also verify this). > > > > Before a Store is permitted, the storing peer MUST check that: > > > > o The AOR of the request is a valid Resource Name with respect to > > the namespaces defined in the overlay configuration document. > > > > What would be the proper reaction if this condition is not fulfilled? > > I guess a StoreAns with Error_Forbidden, but that could/should also be > > mentioned. > > > > Sec. 5.1: > > > > the responding peer MUST present a certificate with a Node-ID > > matching the terminal entry in the route list. > > > > route list wasn't introduced before and I guess destination list > > would be the right term here. Moreover, what is the reaction if > > there is a certificate mismatch, i.e., the Node-ID doesn't match > > the one in the certificate? Should the connection be torn down? > > > > Sec. 5.2: > > typo > > OLD: that want to assure maintanance of sessions individually need to > > NEW: that want to assure maintenance of sessions individually need to > > > > Sec. 6: > > GRUUs in RELOAD are constructed by embedding a > > base64-encoded destination list in the gr URI parameter of the GRUU. > > > > I guess that the destination list is encoded in the same way as > > described in section 6.3.2.2. of RFC 6940. Simply a list of > > Destination entries without any preceding length field?! > > > > Sec. 7: > > > > > > sip_registration_route > > > > a destination list which can be used to reach the user's peer. > > > > if there are any restrictions like only Node-IDs allowed or the > > last entry must be a Node-ID, no Resource-IDs allowed, that could > > be mentioned here, too. > > > > Sec. 8: > > > > What about destination lists that contain back and forth routes > > like 1234 5678 1234 5678 1234 4444 5678 1234 7777? > > This may be used for traffic amplification as mentioned in > > sec. 13.6.5. of the RELOAD spec. Therefore, an additional > > check at the StoreReq receiving node may be useful, even > > if destination lists are checked by RELOAD. > > > > Regards, > > Roland > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > > From nobody Tue Jan 27 11:01:48 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12F81A82E2 for ; Tue, 27 Jan 2015 11:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpvoiUv6ezYK for ; Tue, 27 Jan 2015 11:01:42 -0800 (PST) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60CC11A70E1 for ; Tue, 27 Jan 2015 11:01:42 -0800 (PST) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1YGBOK-001Ygn-1X>; Tue, 27 Jan 2015 20:01:36 +0100 Received: from e178062006.adsl.alicedsl.de ([85.178.62.6] helo=[192.168.178.49]) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1YGBOJ-002tXt-RS>; Tue, 27 Jan 2015 20:01:36 +0100 Message-ID: <54C7E088.6020102@informatik.haw-hamburg.de> Date: Tue, 27 Jan 2015 20:01:28 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <1406307002.10492.15.camel@acorde.it.uc3m.es> <6a8b56a123154be2a448292dde8aa4d5@HUB02.mailcluster.haw-hamburg.de> <54C6074B.9030405@fu-berlin.de> <1422385001.2887.45.camel@it.uc3m.es> In-Reply-To: <1422385001.2887.45.camel@it.uc3m.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: 85.178.62.6 Archived-At: Cc: "p2psip-chairs@tools.ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-13 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 19:01:46 -0000 Hi Carlos, yes, will be finished tonight. I've just a few steps to complete ... Thomas On 27.01.2015 19:56, Carlos Jesús Bernardos Cano wrote: > Hi Thomas, > > Can you please post a revised version of the draft including these > changes. > > Carlos > > On Mon, 2015-01-26 at 10:22 +0100, Thomas C. Schmidt wrote: >> Hi Roland, >> >> apologies for the very late pick-up of the subject. >> >> Please see answers inline: >> >> On 06.09.2014 01:46, Roland Bless wrote: >> >>> I carefully read the document and didn't find any real show stoppers, >>> but IMHO the document would benefit from some clarifications >>> as indicated below. >>> >>> Major: >>> - Normally a SIP registration times out after some period >>> (usually given in the REGISTER message) >>> I guess that the mechanism is replaced in P2PSIP by the >>> lifetime parameter in the StoredData. If this is the case >>> I'd like to see it mentioned explicitly. >>> >> >> Yes, you are right. We added in Section 3.1: >> >> "Note that >> the registration lifetime known from the regular SIP REGISTER method >> is inherited from the lifetime attribute of the basic RELOAD >> StoredData structure (see Section 7 in [RFC6940])." >> >>> - It is unclear how SIP and SIPS should be realized, because >>> AppAttach only allows to create DTLS/UDP or TLS/TCP connections >>> (cf. OverlayLinkType in IceCandidate). >>> "Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted >>> SIP messages over the connection as in normal SIP." >>> Sending "plain" (I guess non-secured) SIP message is not possible >>> if AppAttach doesn't allow for UDP-only connections. >>> >> >> This may be somewhat confusing: Plain SIP sends SIP messages "plainly" >> over transport, while SIPS requires the presence of transport layer >> security. As the current Reload Link Layer is built on (D)TLS secure >> Internet transport, there is actually always some transport layer >> security established within the KBR region. However, this should not >> prevent users to make "plain SIP" calls using plain SIP URIs, and SIPS >> requires end-to-end transport security that include endpoint >> certificates and protected links to clients. >> >> We've added the following clarification: >> >> "It is noteworthy that according to [RFC6940] all overlay links are >> built on (D)TLS secured transport. While hop-wise encrypted paths >> does not prevent the use of plain SIP, SIPS requires end-to-end >> protection that may include client links and endpoint certificates." >> >> >> >>> - I guess that the destination list should contain only >>> NodeIDs, or are ResourceIds and OpaqueIDs also permitted? >>> If not, then the calling/initiating peer should check >>> that condition and some action must be defined if the >>> destination list is non-conforming (maybe discard >>> this destination list) >>> >>> - The Draft should clearly specify how to map AORs >>> to Resource-IDs as required by RFC6940, sec. 5.2: >>> o Define how the Resource Name is used to form the Resource-ID where >>> each Kind is stored. >>> I guess that the AOR is mapped by using the overlay hash function >>> after stripping the scheme (like sip:, sips:) from it. But that >>> should be defined explicitly. >>> >>> Minor: >>> Sec. 1: >>> - Several different notations like 'Node-ID "1234"', Node-ID 1234 >>> or ID 1234 are used in this section. >>> >>> Sec. 2: >>> OLD: include the scheme (e.g sip:) as the AOR needs to match the >>> NEW: include the scheme (e.g. sip:) as the AOR needs to match the >>> >>> Sec. 3.3: >>> >>> o A Store is permitted only for AORs with domain names that fall >>> into the namespaces supported by the RELOAD overlay instance. >>> >>> and then >>> >>> Before issuing a Store request to the overlay, any peer SHOULD verify >>> that the AOR of the request is a valid Resource Name with respect to >>> its domain name and the namespaces defined in the overlay >>> configuration document (see Section 3.4). >>> >>> the first formulation suggests that the latter quotation should use >>> rather MUST than SHOULD (the Storing Peer MUST also verify this). >>> >>> Before a Store is permitted, the storing peer MUST check that: >>> >>> o The AOR of the request is a valid Resource Name with respect to >>> the namespaces defined in the overlay configuration document. >>> >>> What would be the proper reaction if this condition is not fulfilled? >>> I guess a StoreAns with Error_Forbidden, but that could/should also be >>> mentioned. >>> >>> Sec. 5.1: >>> >>> the responding peer MUST present a certificate with a Node-ID >>> matching the terminal entry in the route list. >>> >>> route list wasn't introduced before and I guess destination list >>> would be the right term here. Moreover, what is the reaction if >>> there is a certificate mismatch, i.e., the Node-ID doesn't match >>> the one in the certificate? Should the connection be torn down? >>> >>> Sec. 5.2: >>> typo >>> OLD: that want to assure maintanance of sessions individually need to >>> NEW: that want to assure maintenance of sessions individually need to >>> >>> Sec. 6: >>> GRUUs in RELOAD are constructed by embedding a >>> base64-encoded destination list in the gr URI parameter of the GRUU. >>> >>> I guess that the destination list is encoded in the same way as >>> described in section 6.3.2.2. of RFC 6940. Simply a list of >>> Destination entries without any preceding length field?! >>> >>> Sec. 7: >>> >>> >>> sip_registration_route >>> >>> a destination list which can be used to reach the user's peer. >>> >>> if there are any restrictions like only Node-IDs allowed or the >>> last entry must be a Node-ID, no Resource-IDs allowed, that could >>> be mentioned here, too. >>> >>> Sec. 8: >>> >>> What about destination lists that contain back and forth routes >>> like 1234 5678 1234 5678 1234 4444 5678 1234 7777? >>> This may be used for traffic amplification as mentioned in >>> sec. 13.6.5. of the RELOAD spec. Therefore, an additional >>> check at the StoreReq receiving node may be useful, even >>> if destination lists are checked by RELOAD. >>> >>> Regards, >>> Roland >>> >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Tue Jan 27 11:09:53 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD941A1B4F for ; Tue, 27 Jan 2015 11:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elaV2sl-v7tf for ; Tue, 27 Jan 2015 11:09:48 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1B31A1BDD for ; Tue, 27 Jan 2015 11:09:48 -0800 (PST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CB721982608; Tue, 27 Jan 2015 20:09:46 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id BDD39982606; Tue, 27 Jan 2015 20:09:46 +0100 (CET) Message-ID: <1422385786.24619.1.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Thomas C. Schmidt" Date: Tue, 27 Jan 2015 20:09:46 +0100 In-Reply-To: <54C7E088.6020102@informatik.haw-hamburg.de> References: <1406307002.10492.15.camel@acorde.it.uc3m.es> <6a8b56a123154be2a448292dde8aa4d5@HUB02.mailcluster.haw-hamburg.de> <54C6074B.9030405@fu-berlin.de> <1422385001.2887.45.camel@it.uc3m.es> <54C7E088.6020102@informatik.haw-hamburg.de> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1018-21288.001 X-TM-AS-Result: No--24.183-7.0-31-1 X-imss-scan-details: No--24.183-7.0-31-1 Archived-At: Cc: "p2psip-chairs@tools.ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-13 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 19:09:52 -0000 Thanks! On Tue, 2015-01-27 at 20:01 +0100, Thomas C. Schmidt wrote: > Hi Carlos, > > yes, will be finished tonight. I've just a few steps to complete ... > > Thomas > > On 27.01.2015 19:56, Carlos Jesús Bernardos Cano wrote: > > Hi Thomas, > > > > Can you please post a revised version of the draft including these > > changes. > > > > Carlos > > > > On Mon, 2015-01-26 at 10:22 +0100, Thomas C. Schmidt wrote: > >> Hi Roland, > >> > >> apologies for the very late pick-up of the subject. > >> > >> Please see answers inline: > >> > >> On 06.09.2014 01:46, Roland Bless wrote: > >> > >>> I carefully read the document and didn't find any real show stoppers, > >>> but IMHO the document would benefit from some clarifications > >>> as indicated below. > >>> > >>> Major: > >>> - Normally a SIP registration times out after some period > >>> (usually given in the REGISTER message) > >>> I guess that the mechanism is replaced in P2PSIP by the > >>> lifetime parameter in the StoredData. If this is the case > >>> I'd like to see it mentioned explicitly. > >>> > >> > >> Yes, you are right. We added in Section 3.1: > >> > >> "Note that > >> the registration lifetime known from the regular SIP REGISTER method > >> is inherited from the lifetime attribute of the basic RELOAD > >> StoredData structure (see Section 7 in [RFC6940])." > >> > >>> - It is unclear how SIP and SIPS should be realized, because > >>> AppAttach only allows to create DTLS/UDP or TLS/TCP connections > >>> (cf. OverlayLinkType in IceCandidate). > >>> "Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted > >>> SIP messages over the connection as in normal SIP." > >>> Sending "plain" (I guess non-secured) SIP message is not possible > >>> if AppAttach doesn't allow for UDP-only connections. > >>> > >> > >> This may be somewhat confusing: Plain SIP sends SIP messages "plainly" > >> over transport, while SIPS requires the presence of transport layer > >> security. As the current Reload Link Layer is built on (D)TLS secure > >> Internet transport, there is actually always some transport layer > >> security established within the KBR region. However, this should not > >> prevent users to make "plain SIP" calls using plain SIP URIs, and SIPS > >> requires end-to-end transport security that include endpoint > >> certificates and protected links to clients. > >> > >> We've added the following clarification: > >> > >> "It is noteworthy that according to [RFC6940] all overlay links are > >> built on (D)TLS secured transport. While hop-wise encrypted paths > >> does not prevent the use of plain SIP, SIPS requires end-to-end > >> protection that may include client links and endpoint certificates." > >> > >> > >> > >>> - I guess that the destination list should contain only > >>> NodeIDs, or are ResourceIds and OpaqueIDs also permitted? > >>> If not, then the calling/initiating peer should check > >>> that condition and some action must be defined if the > >>> destination list is non-conforming (maybe discard > >>> this destination list) > >>> > >>> - The Draft should clearly specify how to map AORs > >>> to Resource-IDs as required by RFC6940, sec. 5.2: > >>> o Define how the Resource Name is used to form the Resource-ID where > >>> each Kind is stored. > >>> I guess that the AOR is mapped by using the overlay hash function > >>> after stripping the scheme (like sip:, sips:) from it. But that > >>> should be defined explicitly. > >>> > >>> Minor: > >>> Sec. 1: > >>> - Several different notations like 'Node-ID "1234"', Node-ID 1234 > >>> or ID 1234 are used in this section. > >>> > >>> Sec. 2: > >>> OLD: include the scheme (e.g sip:) as the AOR needs to match the > >>> NEW: include the scheme (e.g. sip:) as the AOR needs to match the > >>> > >>> Sec. 3.3: > >>> > >>> o A Store is permitted only for AORs with domain names that fall > >>> into the namespaces supported by the RELOAD overlay instance. > >>> > >>> and then > >>> > >>> Before issuing a Store request to the overlay, any peer SHOULD verify > >>> that the AOR of the request is a valid Resource Name with respect to > >>> its domain name and the namespaces defined in the overlay > >>> configuration document (see Section 3.4). > >>> > >>> the first formulation suggests that the latter quotation should use > >>> rather MUST than SHOULD (the Storing Peer MUST also verify this). > >>> > >>> Before a Store is permitted, the storing peer MUST check that: > >>> > >>> o The AOR of the request is a valid Resource Name with respect to > >>> the namespaces defined in the overlay configuration document. > >>> > >>> What would be the proper reaction if this condition is not fulfilled? > >>> I guess a StoreAns with Error_Forbidden, but that could/should also be > >>> mentioned. > >>> > >>> Sec. 5.1: > >>> > >>> the responding peer MUST present a certificate with a Node-ID > >>> matching the terminal entry in the route list. > >>> > >>> route list wasn't introduced before and I guess destination list > >>> would be the right term here. Moreover, what is the reaction if > >>> there is a certificate mismatch, i.e., the Node-ID doesn't match > >>> the one in the certificate? Should the connection be torn down? > >>> > >>> Sec. 5.2: > >>> typo > >>> OLD: that want to assure maintanance of sessions individually need to > >>> NEW: that want to assure maintenance of sessions individually need to > >>> > >>> Sec. 6: > >>> GRUUs in RELOAD are constructed by embedding a > >>> base64-encoded destination list in the gr URI parameter of the GRUU. > >>> > >>> I guess that the destination list is encoded in the same way as > >>> described in section 6.3.2.2. of RFC 6940. Simply a list of > >>> Destination entries without any preceding length field?! > >>> > >>> Sec. 7: > >>> > >>> > >>> sip_registration_route > >>> > >>> a destination list which can be used to reach the user's peer. > >>> > >>> if there are any restrictions like only Node-IDs allowed or the > >>> last entry must be a Node-ID, no Resource-IDs allowed, that could > >>> be mentioned here, too. > >>> > >>> Sec. 8: > >>> > >>> What about destination lists that contain back and forth routes > >>> like 1234 5678 1234 5678 1234 4444 5678 1234 7777? > >>> This may be used for traffic amplification as mentioned in > >>> sec. 13.6.5. of the RELOAD spec. Therefore, an additional > >>> check at the StoreReq receiving node may be useful, even > >>> if destination lists are checked by RELOAD. > >>> > >>> Regards, > >>> Roland > >>> > >>> > >>> _______________________________________________ > >>> P2PSIP mailing list > >>> P2PSIP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/p2psip > >>> > From nobody Tue Jan 27 14:02:19 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409691A9067 for ; Tue, 27 Jan 2015 14:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YsTxjxir0lY for ; Tue, 27 Jan 2015 14:02:12 -0800 (PST) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3941A9051 for ; Tue, 27 Jan 2015 14:02:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,477,1418079600"; d="scan'208";a="24461537" Received: from post.haw-hamburg.de (HELO HUB01.mailcluster.haw-hamburg.de) ([141.22.24.50]) by mail6.is.haw-hamburg.de with ESMTP/TLS/AES128-SHA; 27 Jan 2015 23:02:10 +0100 Received: from CAS01.mailcluster.haw-hamburg.de (2002:8d16:183c::8d16:183c) by HUB01.mailcluster.haw-hamburg.de (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 27 Jan 2015 23:02:10 +0100 Received: from [192.168.178.49] (141.22.200.55) by haw-mailer.haw-hamburg.de (141.22.24.60) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 27 Jan 2015 23:02:09 +0100 Message-ID: <54C80ADA.6070700@haw-hamburg.de> Date: Tue, 27 Jan 2015 23:02:02 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "p2psip@ietf.org" References: <1406307002.10492.15.camel@acorde.it.uc3m.es> <6a8b56a123154be2a448292dde8aa4d5@HUB02.mailcluster.haw-hamburg.de> In-Reply-To: <6a8b56a123154be2a448292dde8aa4d5@HUB02.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-13 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 22:02:14 -0000 Hi Roland, many thanks for your careful reading and apologies for the very late pick-up of the subject. Please see answers inline: On 06.09.2014 01:46, Roland Bless wrote: > I carefully read the document and didn't find any real show stoppers, > but IMHO the document would benefit from some clarifications > as indicated below. > > Major: > - Normally a SIP registration times out after some period > (usually given in the REGISTER message) > I guess that the mechanism is replaced in P2PSIP by the > lifetime parameter in the StoredData. If this is the case > I'd like to see it mentioned explicitly. > Yes, you are right. We added in Section 3.1: "Note that the registration lifetime known from the regular SIP REGISTER method is inherited from the lifetime attribute of the basic RELOAD StoredData structure (see Section 7 in [RFC6940])." > - It is unclear how SIP and SIPS should be realized, because > AppAttach only allows to create DTLS/UDP or TLS/TCP connections > (cf. OverlayLinkType in IceCandidate). > "Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted > SIP messages over the connection as in normal SIP." > Sending "plain" (I guess non-secured) SIP message is not possible > if AppAttach doesn't allow for UDP-only connections. > This may be somewhat confusing: Plain SIP sends SIP messages "plainly" over transport, while SIPS requires the presence of transport layer security. As the current Reload Link Layer is built on (D)TLS secure Internet transport, there is actually always some transport layer security established within the KBR region. However, this should not prevent users to make "plain SIP" calls using plain SIP URIs, and SIPS requires end-to-end transport security that include endpoint certificates and protected links to clients. We've added the following clarification: "It is noteworthy that according to [RFC6940] all overlay links are built on (D)TLS secured transport. While hop-wise encrypted paths do not prevent the use of plain SIP, SIPS requires end-to-end protection that may include client links and endpoint certificates." > - I guess that the destination list should contain only > NodeIDs, or are ResourceIds and OpaqueIDs also permitted? > If not, then the calling/initiating peer should check > that condition and some action must be defined if the > destination list is non-conforming (maybe discard > this destination list) > Maybe I miss the point here - but destination lists are part of the RELOAD routing, and we simply use this mechanism. We want to establish an end-to-end connectivity with the help of the AppAttach messaging procedure and I cannot see a reason to restrict resp. interfere with RELOAD routing here. Did I overlook something? > - The Draft should clearly specify how to map AORs > to Resource-IDs as required by RFC6940, sec. 5.2: > o Define how the Resource Name is used to form the Resource-ID where > each Kind is stored. > I guess that the AOR is mapped by using the overlay hash function > after stripping the scheme (like sip:, sips:) from it. But that > should be defined explicitly. > Yes, agreed. Corresponding adjustments have been made to sections 3.2 and 7. > Minor: > Sec. 1: > - Several different notations like 'Node-ID "1234"', Node-ID 1234 > or ID 1234 are used in this section. > O.K., thanks, fixed. > Sec. 2: > OLD: include the scheme (e.g sip:) as the AOR needs to match the > NEW: include the scheme (e.g. sip:) as the AOR needs to match the > Thanks, fixed. > Sec. 3.3: > > o A Store is permitted only for AORs with domain names that fall > into the namespaces supported by the RELOAD overlay instance. > > and then > > Before issuing a Store request to the overlay, any peer SHOULD verify > that the AOR of the request is a valid Resource Name with respect to > its domain name and the namespaces defined in the overlay > configuration document (see Section 3.4). > > the first formulation suggests that the latter quotation should use > rather MUST than SHOULD (the Storing Peer MUST also verify this). > > Before a Store is permitted, the storing peer MUST check that: > > o The AOR of the request is a valid Resource Name with respect to > the namespaces defined in the overlay configuration document. > > What would be the proper reaction if this condition is not fulfilled? > I guess a StoreAns with Error_Forbidden, but that could/should also be > mentioned. > Just to clarify: The SHOULD applies to the requester and the MUST applies to the storing node. The latter ensures that no improper records enter the overlay. Putting the liberal SHOULD to the requester action was actually on purpose for the following reasons: The responsibility of enforcement clearly is with the storing node, which should be prepared for erroneous request. And there may be situations (which?) where nodes/implementers have reasons to consider it an unsuitable burden to perform the check. However, a SHOULD means that it is meant to be done, anyway. So I'm hesitant to change ... but without strong opinion ;) As for the response code, we added "Error_Forbidden". > Sec. 5.1: > > the responding peer MUST present a certificate with a Node-ID > matching the terminal entry in the route list. > > route list wasn't introduced before and I guess destination list > would be the right term here. Moreover, what is the reaction if > there is a certificate mismatch, i.e., the Node-ID doesn't match > the one in the certificate? Should the connection be torn down? > We added: "Otherwise, the connection MUST NOT be used and closed." Thanks for the "route list": that was an ancient term-typo. > Sec. 5.2: > typo > OLD: that want to assure maintanance of sessions individually need to > NEW: that want to assure maintenance of sessions individually need to > Thanks, fixed. > Sec. 6: > GRUUs in RELOAD are constructed by embedding a > base64-encoded destination list in the gr URI parameter of the GRUU. > > I guess that the destination list is encoded in the same way as > described in section 6.3.2.2. of RFC 6940. Simply a list of > Destination entries without any preceding length field?! > Well yes, we're using the RELOAD destination list (term and definition) here. The above encoding describes the URI-encoding, not the representation of the data structure in the overlay. > Sec. 7: > > > sip_registration_route > > a destination list which can be used to reach the user's peer. > > if there are any restrictions like only Node-IDs allowed or the > last entry must be a Node-ID, no Resource-IDs allowed, that could > be mentioned here, too. > See the discussion above. > Sec. 8: > > What about destination lists that contain back and forth routes > like 1234 5678 1234 5678 1234 4444 5678 1234 7777? > This may be used for traffic amplification as mentioned in > sec. 13.6.5. of the RELOAD spec. Therefore, an additional > check at the StoreReq receiving node may be useful, even > if destination lists are checked by RELOAD. > Mhmm, the issue is discussed and treated in the RELOAD spec. I'm not really convinced that we should redefine RELOAD specifics. Also, from an implementers point of view, I would expect that this checking is already part of handling the destination lists. It appears a bit awkward if an implementation of this specific SIP usage adds generic route protection ... don't you agree? Are you o.k. with these responses or did I miss something? Thanks, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Tue Jan 27 16:20:12 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59FE1AC408; Tue, 27 Jan 2015 16:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ES5PaHmDksin; Tue, 27 Jan 2015 16:20:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A73A1A9235; Tue, 27 Jan 2015 16:20:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150128002001.12729.71336.idtracker@ietfa.amsl.com> Date: Tue, 27 Jan 2015 16:20:01 -0800 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-sip-14.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 00:20:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : A SIP Usage for RELOAD Authors : Cullen Jennings Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Thomas C. Schmidt Filename : draft-ietf-p2psip-sip-14.txt Pages : 20 Date : 2015-01-27 Abstract: This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay. It also defines Globally Routable User Agent Uris (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a peer, the AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-sip-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-sip-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 28 03:03:14 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926CA1A1A1D for ; Wed, 28 Jan 2015 03:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4G8R7nH2XkRI for ; Wed, 28 Jan 2015 03:03:12 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id E263B1A19EF for ; Wed, 28 Jan 2015 03:03:11 -0800 (PST) Received: from [IPv6:2001:470:40b8:0:ac61:89d9:bed7:6f0a] (unknown [IPv6:2001:470:40b8:0:ac61:89d9:bed7:6f0a]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id EA557200DE; Wed, 28 Jan 2015 12:03:08 +0100 (CET) Message-ID: <54C8C1EA.1060809@acm.org> Date: Wed, 28 Jan 2015 04:03:06 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: cjbc@it.uc3m.es, p2psip@ietf.org References: <1422384846.2887.44.camel@it.uc3m.es> In-Reply-To: <1422384846.2887.44.camel@it.uc3m.es> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: p2psip-chairs@tools.ietf.org Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-share-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 11:03:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I reviewed this document multiple times and I believe that it is ready to be submitted to the IESG. Thanks. On 01/27/2015 11:54 AM, Carlos Jesús Bernardos Cano wrote: > Hi, > > Hereby we are issuing a WGLC for draft-ietf-p2psip-share-04. > > The WGLC will be open till the 16th of February. We kindly ask the WG to > review the document and provide comments. We did one last year and we > didn't get any comments, which is not acceptable if we want to progress > the document. If you have no comments and think the document is ready to > be submitted to IESG, please do send a note stating that to the WG ML. > Note that if we don't get some responses to this WGLC showing enough > energy & interest to progress this document, we would abandon it. > > Additional information about the document is below: > > Title : A Usage for Shared Resources in RELOAD (ShaRe) > Authors : Alexander Knauf > Thomas C. Schmidt > Gabriel Hege > Matthias Waehlisch > Filename : draft-ietf-p2psip-share-04.txt > Pages : 20 > Date : 2014-08-29 > > Abstract: > This document defines a RELOAD Usage for managing shared write access > to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic > primitive for enabling various coordination and notification schemes > among distributed peers. Access in ShaRe is controlled by a > hierarchical trust delegation scheme maintained within an access > list. A new USER-CHAIN-ACL access policy allows authorized peers to > write a Shared Resource without owning its corresponding certificate. > This specification also adds mechanisms to store Resources with a > variable name which is useful whenever peer-independent rendezvous > processes are required. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-p2psip-share-04 > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUyMHpAAoJECnERZXWan7E71sP/0QBDCoNwH879T7ryqbU7AeW Xwq3aUpkOgegALis+6Qkpj1RdqfHIhgRaMASaMqxC5yET0B5GZwNyf+Byw1lI0bm NJHOVMmRYcw3uAgFAMenHDt9Dn+ZhatDjvKebEE0VtZpIAsM+/kUwkuybL6NFJSo cdTk9ipyES0jMFlA4v9dVYrunr1Kkt6PYKRbxVS9pS+PNCYaG42Fl1WLvAdX6mL+ rOngo4ZUS/O/waJXm83autJjXcWGSvDo3lnrJe6sYOwhgPAQafDfqWfjRksIpXYT 4saER7SLwX6cODGQyFuva2Bu1Sq26t1SJ+5ddFKGFjUWL9Pe0vp/fJ4Qb1hC0Nns EESawB8LRPXyYnc+2lskQC2Me5xJ438kvpAOTM19+MYfdw7nXfeZ00VGoivLo149 VHleV6QqLKUrfo+gpk1GIfrsWTCfE/kbzIwEkooLsYaft/N20h84zzUE8bwa34F5 xrlErk1iU1QtFxUPs1uDE95qoGIw4Py1OhnT4y3+trfTgElx1erKY5dIUG5hd814 UIIg18wfgnRgX0zKFJsnl5ym/Da7fw3aQ2vpxC1PeLEcHnP+LKfK5VODSbJeqRoI gzkLQfbjkSS9tHkJLJNLYPxruRvXjguCz+VxYgFEoJa72XaTTfj7wUpn2cPEmKgK yotkgA0XCNZ/TBp/0U8m =pLRR -----END PGP SIGNATURE----- From nobody Thu Jan 29 01:29:45 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC9D1A0130 for ; Thu, 29 Jan 2015 01:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAUKZvz80mmh for ; Thu, 29 Jan 2015 01:29:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA62F1A00FB for ; Thu, 29 Jan 2015 01:29:40 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BON96210; Thu, 29 Jan 2015 09:29:39 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Jan 2015 09:29:38 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.146]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 29 Jan 2015 17:29:35 +0800 From: "Songhaibin (A)" To: "Roy, Radhika R CIV USARMY (US)" , "p2psip@ietf.org" Thread-Topic: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt Thread-Index: AQHQNuP49RwG5d6TQUagStguaRu7V5zNkJAAgAQBYfCAAEwogIAE/0gQ Date: Thu, 29 Jan 2015 09:29:34 +0000 Message-ID: References: <20150123080935.4605.51843.idtracker@ietfa.amsl.com> <8486C8728176924BAF5BDB2F7D7EEDDF724F6F55@ucolhpkt.easf.csd.disa.mil> <8486C8728176924BAF5BDB2F7D7EEDDF724F71A6@ucolhpkt.easf.csd.disa.mil> In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF724F71A6@ucolhpkt.easf.csd.disa.mil> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 09:29:44 -0000 Hi Radhika, This is a management issue rather than a technical issue.=20 Best Regards! -Haibin > -----Original Message----- > From: Roy, Radhika R CIV USARMY (US) [mailto:radhika.r.roy.civ@mail.mil] > Sent: Monday, January 26, 2015 9:07 PM > To: Songhaibin (A); p2psip@ietf.org > Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt >=20 > Hi, Haibin: >=20 > Great! >=20 > Yes, I also thought the same. We are looking for full management set for > P2PSIP. >=20 > We saw one proposal P2PSNMP draft some time ago. Why did that draft > authors > not continue? >=20 > Or, will people create extensions one after another until the full set fo= r > P2PSIP management available? >=20 > BR/Radhika >=20 > -----Original Message----- > From: Songhaibin (A) [mailto:haibin.song@huawei.com] > Sent: Sunday, January 25, 2015 7:38 PM > To: Roy, Radhika R CIV USARMY (US); p2psip@ietf.org > Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt >=20 > Hi Roy, >=20 >=20 > > -----Original Message----- > > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of Roy, > > Radhika R CIV USARMY (US) > > Sent: Saturday, January 24, 2015 3:25 AM > > To: p2psip@ietf.org > > Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > > > Hi, Song, et al: > > > > I have one general question about the draft as follows: > > > > 1. Will these diagnostics collection by P2P RELOAD protocol as it is > > being extended be good enough for P2PSIP management? >=20 > It is considered useful for diagnostics at this moment. There can be futu= re > extensions. It is not a full set. >=20 > > 2. Does it mean that we do not need any separate P2P Management > > Protocol (e.g. P2PSNMP aka like P2PSIP) for management P2PSIP network > > for all of its nodes that use P2PSIP protocol? >=20 > IMO P2P network management and diagnostics are two different concepts, > and > you can have other protocols/extensions for management. >=20 > -Haibin >=20 > > BR/Radhika > > > > -----Original Message----- > > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: Friday, January 23, 2015 3:10 AM > > To: i-d-announce@ietf.org > > Cc: p2psip@ietf.org > > Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Peer-to-Peer Session Initiation > > Protocol Working Group of the IETF. > > > > Title : P2P Overlay Diagnostics > > Authors : Haibin Song > > Jiang Xingfeng > > Roni Even > > David A. Bryan > > Yi Sun > > Filename : draft-ietf-p2psip-diagnostics-16.txt > > Pages : 29 > > Date : 2015-01-23 > > > > Abstract: > > This document describes mechanisms for P2P overlay diagnostics. It > > defines extensions to the RELOAD P2PSIP base protocol to collect > > diagnostic information, and details the protocol specifications for > > these extensions. Useful diagnostic information for connection and > > node status monitoring is also defined. The document also describes > > the usage scenarios and provides examples of how these methods are > > used to perform diagnostics in P2PSIP overlay networks. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-16 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-diagnostics-16 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip From nobody Thu Jan 29 01:32:34 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDB01A0126 for ; Thu, 29 Jan 2015 01:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGSbQGDM9LrG for ; Thu, 29 Jan 2015 01:32:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724BA1A0125 for ; Thu, 29 Jan 2015 01:32:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRW19863; Thu, 29 Jan 2015 09:32:28 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 Jan 2015 09:32:27 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.146]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 29 Jan 2015 17:32:19 +0800 From: "Songhaibin (A)" To: "cjbc@it.uc3m.es" , "p2psip@ietf.org" Thread-Topic: [P2PSIP] WGLC for draft-ietf-p2psip-diagnostics-16 Thread-Index: AQHQOmKoRG9EHYDVd0yUyjt0lPZP55zW15vw Date: Thu, 29 Jan 2015 09:32:18 +0000 Message-ID: References: <1422384828.2887.43.camel@it.uc3m.es> In-Reply-To: <1422384828.2887.43.camel@it.uc3m.es> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.49] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "p2psip-chairs@tools.ietf.org" Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-diagnostics-16 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 09:32:32 -0000 As a co-author, I think the document is ready. And we did address a lot of = comments from experts from this WG and other areas. Best Regards! -Haibin > -----Original Message----- > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of Carlos Jes=FAs > Bernardos Cano > Sent: Wednesday, January 28, 2015 2:54 AM > To: p2psip@ietf.org > Cc: p2psip-chairs@tools.ietf.org > Subject: [P2PSIP] WGLC for draft-ietf-p2psip-diagnostics-16 >=20 > Hi, >=20 > Hereby we are issuing a WGLC for draft-ietf-p2psip-diagnostics-16. >=20 > The WGLC will be open till the 16th of February. We kindly ask the WG to = review > the document and provide comments. If you have no comments and think the > document is ready to be submitted to IESG, please do send a note stating = that > to the WG ML. Note that if we don't get some responses to this WGLC showi= ng > enough energy & interest to progress this document, we would abandon it. >=20 > Additional information about the document is below: >=20 > Title : P2P Overlay Diagnostics > Authors : Haibin Song > Jiang Xingfeng > Roni Even > David A. Bryan > Yi Sun > Filename : draft-ietf-p2psip-diagnostics-16.txt > Pages : 29 > Date : 2015-01-23 >=20 > Abstract: > This document describes mechanisms for P2P overlay diagnostics. It > defines extensions to the RELOAD P2PSIP base protocol to collect > diagnostic information, and details the protocol specifications for > these extensions. Useful diagnostic information for connection and > node status monitoring is also defined. The document also describes > the usage scenarios and provides examples of how these methods are > used to perform diagnostics in P2PSIP overlay networks. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-16 >=20 > Thanks >=20 > -- Brian and Carlos >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From nobody Thu Jan 29 04:10:18 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF9E1A0271 for ; Thu, 29 Jan 2015 04:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tj1rTqgzonc9 for ; Thu, 29 Jan 2015 04:10:14 -0800 (PST) Received: from upbd19pa12.eemsg.mail.mil (upbd19pa12.eemsg.mail.mil [214.24.27.87]) by ietfa.amsl.com (Postfix) with ESMTP id 35E161A024C for ; Thu, 29 Jan 2015 04:10:12 -0800 (PST) X-EEMSG-Attachment-filename: smime.p7s Received: from edge-cols02.mail.mil ([131.64.104.102]) by upbd19pa12.eemsg.mail.mil with ESMTP; 29 Jan 2015 12:10:10 +0000 Received: from UCOLHPMH.easf.csd.disa.mil (131.64.104.36) by edge-cols02.mail.mil (131.64.104.102) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 29 Jan 2015 12:10:10 +0000 Received: from UCOLHPKT.easf.csd.disa.mil ([169.254.2.202]) by ucolhpmh.easf.csd.disa.mil ([131.64.104.36]) with mapi id 14.03.0224.002; Thu, 29 Jan 2015 12:10:09 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: "Songhaibin (A)" , "p2psip@ietf.org" Thread-Topic: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt Thread-Index: AQHQNuP00hLTrMrU1EWpqWeJ3iYkxpzOFKlwgAN+SwCAAM9csIAEfBcAgAAqQpA= Date: Thu, 29 Jan 2015 12:10:09 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF724F7794@ucolhpkt.easf.csd.disa.mil> References: <20150123080935.4605.51843.idtracker@ietfa.amsl.com> <8486C8728176924BAF5BDB2F7D7EEDDF724F6F55@ucolhpkt.easf.csd.disa.mil> <8486C8728176924BAF5BDB2F7D7EEDDF724F71A6@ucolhpkt.easf.csd.disa.mil> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.22.15] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01D03B92.9C0A5050" MIME-Version: 1.0 Archived-At: Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 12:10:17 -0000 ------=_NextPart_000_0000_01D03B92.9C0A5050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Haibin and all members of this WG: Right! It is also P2P application issue. For example, MANET WG does the routing protocols for MANETs. However, they also build the RFCs/standards for the management standards for MANETs for each of the routing protocols they have standardized. In the same token, it is the P2PSIP WG shall to do the same. We also expect to produce the RFCs/standards for the P2PSIP management standards/RFCs in this P2PSIP WG. If needed, we can extend our charter. Otherwise, there is be a big gap for actual adaptation of the P2PSIP applications either using RELOAD or any other things that this P2PSIP WG has produced or will be producing. So, we have to proactive in developing the standards for the management of the P2PSIP (as MANET WG does). BR/Radhika -----Original Message----- From: Songhaibin (A) [mailto:haibin.song@huawei.com] Sent: Thursday, January 29, 2015 4:30 AM To: Roy, Radhika R CIV USARMY (US); p2psip@ietf.org Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt Hi Radhika, This is a management issue rather than a technical issue. Best Regards! -Haibin > -----Original Message----- > From: Roy, Radhika R CIV USARMY (US) > [mailto:radhika.r.roy.civ@mail.mil] > Sent: Monday, January 26, 2015 9:07 PM > To: Songhaibin (A); p2psip@ietf.org > Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > Hi, Haibin: > > Great! > > Yes, I also thought the same. We are looking for full management set > for P2PSIP. > > We saw one proposal P2PSNMP draft some time ago. Why did that draft > authors not continue? > > Or, will people create extensions one after another until the full set > for P2PSIP management available? > > BR/Radhika > > -----Original Message----- > From: Songhaibin (A) [mailto:haibin.song@huawei.com] > Sent: Sunday, January 25, 2015 7:38 PM > To: Roy, Radhika R CIV USARMY (US); p2psip@ietf.org > Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > Hi Roy, > > > > -----Original Message----- > > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of Roy, > > Radhika R CIV USARMY (US) > > Sent: Saturday, January 24, 2015 3:25 AM > > To: p2psip@ietf.org > > Subject: Re: [P2PSIP] I-D Action: > > draft-ietf-p2psip-diagnostics-16.txt > > > > Hi, Song, et al: > > > > I have one general question about the draft as follows: > > > > 1. Will these diagnostics collection by P2P RELOAD protocol as it is > > being extended be good enough for P2PSIP management? > > It is considered useful for diagnostics at this moment. There can be > future extensions. It is not a full set. > > > 2. Does it mean that we do not need any separate P2P Management > > Protocol (e.g. P2PSNMP aka like P2PSIP) for management P2PSIP > > network for all of its nodes that use P2PSIP protocol? > > IMO P2P network management and diagnostics are two different concepts, > and you can have other protocols/extensions for management. > > -Haibin > > > BR/Radhika > > > > -----Original Message----- > > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: Friday, January 23, 2015 3:10 AM > > To: i-d-announce@ietf.org > > Cc: p2psip@ietf.org > > Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Peer-to-Peer Session Initiation > > Protocol Working Group of the IETF. > > > > Title : P2P Overlay Diagnostics > > Authors : Haibin Song > > Jiang Xingfeng > > Roni Even > > David A. Bryan > > Yi Sun > > Filename : draft-ietf-p2psip-diagnostics-16.txt > > Pages : 29 > > Date : 2015-01-23 > > > > Abstract: > > This document describes mechanisms for P2P overlay diagnostics. It > > defines extensions to the RELOAD P2PSIP base protocol to collect > > diagnostic information, and details the protocol specifications for > > these extensions. Useful diagnostic information for connection and > > node status monitoring is also defined. The document also describes > > the usage scenarios and provides examples of how these methods are > > used to perform diagnostics in P2PSIP overlay networks. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-16 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-diagnostics-16 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip ------=_NextPart_000_0000_01D03B92.9C0A5050 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISjTCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEuDCCA6CgAwIBAgIDGpBfMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzEwHhcNMTQwOTE1MDAwMDAwWhcN MTcwOTE0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALVT rbd+Bi0u5R+vhGeuVvwE4jy3GZm+RANU3wfqsp9Oq7RJYUFCkOcOf2HSFXyOF9fYMIJYxpwyWyPd MLEQ2zJ9cCHtiWSdwAzfXVzSLZefdcBq44JapSCtNs6NHyB468dPBWCOLbsB5R1fhw/7Kx16eFEI VToykNwboBcl48bAJH/E42GeenZZhfBgJTrfYDIo1arlTw2XCqOxyeNxmHZ9N54F/Ay+vR8qewyI wf4pdYd9Hz4hSQ/cAM2ESzdTkGI5SZOSb5uLxtXn7CzUxDdIn09brcRV3tSnazEwP1hTwJ+BMrDS WLVrj8PaEHvrsMHPjgSO7pOIISUSPSn2kJcCAwEAAaOCAWMwggFfMB8GA1UdIwQYMBaAFIbxW2hv 3TDzlIJo1Ez3RB24ymiBMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMzEuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFPfgWqUBFSj+zRkYK8QdUScKB07UMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMzEu Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAlBgNVHREEHjAcgRpyYWRoaWth LnIucm95LmNpdkBtYWlsLm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMA0GCSqGSIb3 DQEBBQUAA4IBAQCg5mLhdie9Opv9asgcTKjz3wcYnoV72Sd8oYj37iaPVht1UIx+elPJV91q8i5B gq8gGaXlgGX+lTQgbhIKtyg/zeJrPQJI0A5ZN4TzfLqf4eUz5pqPh/hV9B8UbigUCW8wNbopPXYX Fu4fwMCOefKe7jx+kXrIUE+2fQtBRw9XaPzsOG0+XlCo6OdGVtkWkY5qmsNbitS78H8iEWSIhvAN dkJzWMhIOwmQ26F1k5DeWeGz7atyOcASJvobl3Xd6emCopMFKt8IoQtssdCmokDM5p6hqlWCVFRk TPVha4nOZH2u5Sj3Ax6lBtBUtWmGZ3jOpXdEtWj3avViyIDAl3aUMIIFAzCCA+ugAwIBAgIDGpBb MA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQx DDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzEwHhcN MTQwOTE1MDAwMDAwWhcNMTcwOTE0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5T LiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYw JAYDVQQDEx1ST1kuUkFESElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAKPCxD4WPTf6htWggvbIv9Zvq4sjmEBXhlX9wsCV8y94oumGlWiaX7GEFMHg lMWNjj58vz5bUzsL2rUCTxORuRR05b7G2wPFr2Q3ebUGAzLjcsTf3d50IxapuF7HYRzrJBSE7ft5 Rx6eBt1AofYBaS6t01CVi1MQHD3/FxeC0Ipow5A3SDbTNY9NSBVGpnnyX5B9yZ3fuhlgzLCZC+Oa iD278MrGeOhMpfeigL9QYypP1bPKPBbhSl/ZgPlf+0CqRrA4tHy/AHr6F1NYt7QlLgfIAQakKUMY H0B3ypI3+FZ/t08hzSHyloomjs+2oZROMXeaD8yCuehULxvMhYZvkGECAwEAAaOCAa4wggGqMB8G A1UdIwQYMBaAFIbxW2hv3TDzlIJo1Ez3RB24ymiBMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9j cmwuZGlzYS5taWwvY3JsL0RPREVNQUlMQ0FfMzEuY3JsMA4GA1UdDwEB/wQEAwIGwDAjBgNVHSAE HDAaMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGAbUYZkuBh8vML199Hbg7zD qi+eMGgGCCsGAQUFBwEBBFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWdu L0RPREVNQUlMQ0FfMzEuY2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDBFBgNV HREEPjA8gRpyYWRoaWthLnIucm95LmNpdkBtYWlsLm1pbKAeBgorBgEEAYI3FAIDoBAMDjEyOTE5 Mzk4MDFAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwKQYDVR0lBCIwIAYKKwYBBAGC NxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUAA4IBAQC9BhFhcZlxDQy+qExu ucegMi61cE1ux2iVlZxJY1FMQ9GAyUy4m4daGY4afM/MuGOIDAC/Ho+Y7rEGnwNYLUN5bKK7IfrT i/CcKJSKX3H/Nw6w7C4mFToUVP+j9WTZfQLhd/8JS1tq8LKJkjePpx2xNMD+cJFQ5x3E9BlBbgYk LU/8f1lM4EDQw2itc24FskmZwAMaa643iJylvMPQ5c9R1KtmsMSxlvZKFl5ENrxI3vkuHEdnz0QG IGSfuOLRA8g3uy2kiaCmGEYz7764mloTsKuuJkRNJka/As0L2tWR2QuVaGgQv6lTYDBhr1adxV7K G0yNn/jeN/auDAscX+lFMIIFUjCCBDqgAwIBAgICA58wDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQ S0kxFjAUBgNVBAMTDURvRCBSb290IENBIDIwHhcNMTMwMTE2MTQ1MjQzWhcNMTkwMTE2MTQ1MjQz WjBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0Qx DDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMxMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA6K4CLEBMOlLoi3OStHfnOEvA8KpKGFzH9zXDSvDwlnell74n78REIYDq FjS3MNFEOH8qzgTGkWWpblB8yE7+vcC1SxbkOFIV27O391M98rEH25FmXcG38ndmxFGaY5QRSwId DUt8swBHB3kY+nizkx/Udm2ZBMUeNkb8BjQL42hvHnyfLM9huEv/tN8Gn6BflF7rNf8JXTVAB/Kd 7ZYJ2Xbq/m4x/sv0ResweEhobKEpPoZ9k0FK6ucMTOWRUCqlQ2a8IsD8Gyzk8y9iHgTUIb+sHyZ3 NdAdvOK7RsLy6+QUrviza7P6cTiwcSnt0Ysb1wIb3srsfu6h3Eil8T6UqQIDAQABo4ICHDCCAhgw HQYDVR0OBBYEFIbxW2hv3TDzlIJo1Ez3RB24ymiBMB8GA1UdIwQYMBaAFEl0uwxeunr+AlTve6DG lcYJgHCWMBIGA1UdEwEB/wQIMAYBAf8CAQAwDAYDVR0kBAUwA4ABADAOBgNVHQ8BAf8EBAMCAYYw ZgYDVR0gBF8wXTALBglghkgBZQIBCwUwCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELETALBglghkgB ZQIBCxIwCwYJYIZIAWUCAQsTMAwGCmCGSAFlAwIBAxowDAYKYIZIAWUDAgEDGzA3BgNVHR8EMDAu MCygKqAohiZodHRwOi8vY3JsLmRpc2EubWlsL2NybC9ET0RST09UQ0EyLmNybDCCAQEGCCsGAQUF BwEBBIH0MIHxMDoGCCsGAQUFBzAChi5odHRwOi8vY3JsLmRpc2EubWlsL2lzc3VlZHRvL0RPRFJP T1RDQTJfSVQucDdjMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDCBkAYIKwYBBQUH MAKGgYNsZGFwOi8vY3JsLmdkcy5kaXNhLm1pbC9jbiUzZERvRCUyMFJvb3QlMjBDQSUyMDIlMmNv dSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2Nyb3Nz Q2VydGlmaWNhdGVQYWlyO2JpbmFyeTANBgkqhkiG9w0BAQUFAAOCAQEAWTKtqsP435xknHEJNMG9 vGMAHi3b7anICOO5GOSvyq4Uwd27+XODg1eOlMmgqgMHzmecteUXWT8ouBc22rqNw5YRAWpQ1gba aKRK0guFfM2I3/9ed+b1pEiR0E6iZ2r4aO+qF0Xv2JYK3c/wPoe2v4g/01S+PhLOofkLbzLRVL+E WzWg2wdktavpeR7i8qp0cueREvfHu27u5XSQECSLt+fNnIWQR+Tib38gvSy7g5YjTahM2H4uXhUp uCV9VzULLRVUjKnc4OU3nahPIJWDK8USNj2oc+FOiEmlubv6CUooWjO55JJ5W3v4pU/zyTTNmYyw umB+n4Q+5jz6flrr5jGCAv4wggL6AgEBMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0zMQIDGpBbMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE1MDEyOTEyMTAwNlowIwYJKoZIhvcNAQkEMRYEFOKhROdzYSlI690ZFuVX 0Paotgs3MCQGCSqGSIb3DQEJDzEXMBUwCgYIKoZIhvcNAwcwBwYFKw4DAhowcwYJKwYBBAGCNxAE MWYwZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNE b0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMxAgMakF8wdQYLKoZIhvcN AQkQAgsxZqBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNV BAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzECAxqQXzANBgkq hkiG9w0BAQEFAASCAQAC08/G8pJpRmL2ehNqellOSrYuiP0a8sL/Mxh+U/yW+rXk02uHkPKzwtLP nj4XBdyJPN5q7uwlC8yGoVCyDVprdeyrV6OGMfP8c0gYkd7UM9pve+yl3Aodtc8Knu+jlfSqieSV uRJqALOj1lttvgx6GoL/CMMob/Z0BA9XqRVmPm8gVa94hfWCc7hDHbqZxFai7cxOmlXjcnpPq5CB sNWOtMP1Nm4OBjL+DhDYexxHxhHf2//k51+Ya+Tva4DQ+MzVDFAeMyx0MMaIwviuT9/TPJiwi+Ex 2iDS1Pzu5+DPfUi7XvvKjNjX5n7d5Ru8XeEvn7gPZuqUGiTbhJb+wNaGAAAAAAAA ------=_NextPart_000_0000_01D03B92.9C0A5050-- From nobody Thu Jan 29 04:41:24 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABC11A0362 for ; Thu, 29 Jan 2015 04:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKctnH2Ax0PP for ; Thu, 29 Jan 2015 04:41:14 -0800 (PST) Received: from ucol19pa13.eemsg.mail.mil (ucol19pa13.eemsg.mail.mil [214.24.24.86]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF241A014C for ; Thu, 29 Jan 2015 04:41:11 -0800 (PST) X-EEMSG-Attachment-filename: smime.p7s Received: from edge-cols02.mail.mil ([131.64.104.103]) by ucol19pa13.eemsg.mail.mil with ESMTP; 29 Jan 2015 12:41:10 +0000 Received: from UCOLHPM9.easf.csd.disa.mil (131.64.104.34) by edge-cols02.mail.mil (131.64.104.103) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 29 Jan 2015 12:41:10 +0000 Received: from UCOLHPKT.easf.csd.disa.mil ([169.254.2.202]) by UCOLHPM9.easf.csd.disa.mil ([131.64.104.34]) with mapi id 14.03.0224.002; Thu, 29 Jan 2015 12:41:10 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: "Songhaibin (A)" , "p2psip@ietf.org" Thread-Topic: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt Thread-Index: AQHQNuP00hLTrMrU1EWpqWeJ3iYkxpzOFKlwgAN+SwCAAM9csIAEfBcAgAAqQpCAAAhWUA== Date: Thu, 29 Jan 2015 12:41:09 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF724F77EC@ucolhpkt.easf.csd.disa.mil> References: <20150123080935.4605.51843.idtracker@ietfa.amsl.com> <8486C8728176924BAF5BDB2F7D7EEDDF724F6F55@ucolhpkt.easf.csd.disa.mil> <8486C8728176924BAF5BDB2F7D7EEDDF724F71A6@ucolhpkt.easf.csd.disa.mil> <8486C8728176924BAF5BDB2F7D7EEDDF724F7794@ucolhpkt.easf.csd.disa.mil> In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF724F7794@ucolhpkt.easf.csd.disa.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.22.15] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0005_01D03B96.F0BB3C00" MIME-Version: 1.0 Archived-At: Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 12:41:17 -0000 ------=_NextPart_000_0005_01D03B96.F0BB3C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Haibin and all members of this WG: Let me clarify a little more on management works of MANET WG. MANET WG has used the SNMP as the base management protocol and has developed MIBs for all of the MANET physical routing protocols that have standardized. In our P2PWG, we do have the same. That is, for example P2PSNMP protocol that is used as the base protocol for management of P2PSIP protocol. So, if there is no anything like P2P-Management Protocol, what will do for management of the P2PSIP? Under the umbrella of P2PSIP, we can produce P2P-IM, P2PSIP-Conferencing, P2P-Binary Floor Control Protocol, P2P-Media Mixing/Bridging Protocol, P2P-Other protocols that are needed for P2PSIP. In the same token, we can produce P2PSIP-Management Protocol. We will appreciate comments from all members of the P2PSIP WG. BR/Radhika -----Original Message----- From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of Roy, Radhika R CIV USARMY (US) Sent: Thursday, January 29, 2015 7:10 AM To: Songhaibin (A); p2psip@ietf.org Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt Hi, Haibin and all members of this WG: Right! It is also P2P application issue. For example, MANET WG does the routing protocols for MANETs. However, they also build the RFCs/standards for the management standards for MANETs for each of the routing protocols they have standardized. In the same token, it is the P2PSIP WG shall to do the same. We also expect to produce the RFCs/standards for the P2PSIP management standards/RFCs in this P2PSIP WG. If needed, we can extend our charter. Otherwise, there is be a big gap for actual adaptation of the P2PSIP applications either using RELOAD or any other things that this P2PSIP WG has produced or will be producing. So, we have to proactive in developing the standards for the management of the P2PSIP (as MANET WG does). BR/Radhika -----Original Message----- From: Songhaibin (A) [mailto:haibin.song@huawei.com] Sent: Thursday, January 29, 2015 4:30 AM To: Roy, Radhika R CIV USARMY (US); p2psip@ietf.org Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt Hi Radhika, This is a management issue rather than a technical issue. Best Regards! -Haibin > -----Original Message----- > From: Roy, Radhika R CIV USARMY (US) > [mailto:radhika.r.roy.civ@mail.mil] > Sent: Monday, January 26, 2015 9:07 PM > To: Songhaibin (A); p2psip@ietf.org > Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > Hi, Haibin: > > Great! > > Yes, I also thought the same. We are looking for full management set > for P2PSIP. > > We saw one proposal P2PSNMP draft some time ago. Why did that draft > authors not continue? > > Or, will people create extensions one after another until the full set > for P2PSIP management available? > > BR/Radhika > > -----Original Message----- > From: Songhaibin (A) [mailto:haibin.song@huawei.com] > Sent: Sunday, January 25, 2015 7:38 PM > To: Roy, Radhika R CIV USARMY (US); p2psip@ietf.org > Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > Hi Roy, > > > > -----Original Message----- > > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of Roy, > > Radhika R CIV USARMY (US) > > Sent: Saturday, January 24, 2015 3:25 AM > > To: p2psip@ietf.org > > Subject: Re: [P2PSIP] I-D Action: > > draft-ietf-p2psip-diagnostics-16.txt > > > > Hi, Song, et al: > > > > I have one general question about the draft as follows: > > > > 1. Will these diagnostics collection by P2P RELOAD protocol as it is > > being extended be good enough for P2PSIP management? > > It is considered useful for diagnostics at this moment. There can be > future extensions. It is not a full set. > > > 2. Does it mean that we do not need any separate P2P Management > > Protocol (e.g. P2PSNMP aka like P2PSIP) for management P2PSIP > > network for all of its nodes that use P2PSIP protocol? > > IMO P2P network management and diagnostics are two different concepts, > and you can have other protocols/extensions for management. > > -Haibin > > > BR/Radhika > > > > -----Original Message----- > > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: Friday, January 23, 2015 3:10 AM > > To: i-d-announce@ietf.org > > Cc: p2psip@ietf.org > > Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Peer-to-Peer Session Initiation > > Protocol Working Group of the IETF. > > > > Title : P2P Overlay Diagnostics > > Authors : Haibin Song > > Jiang Xingfeng > > Roni Even > > David A. Bryan > > Yi Sun > > Filename : draft-ietf-p2psip-diagnostics-16.txt > > Pages : 29 > > Date : 2015-01-23 > > > > Abstract: > > This document describes mechanisms for P2P overlay diagnostics. It > > defines extensions to the RELOAD P2PSIP base protocol to collect > > diagnostic information, and details the protocol specifications for > > these extensions. Useful diagnostic information for connection and > > node status monitoring is also defined. The document also describes > > the usage scenarios and provides examples of how these methods are > > used to perform diagnostics in P2PSIP overlay networks. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-16 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-diagnostics-16 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip ------=_NextPart_000_0005_01D03B96.F0BB3C00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISjTCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEuDCCA6CgAwIBAgIDGpBfMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzEwHhcNMTQwOTE1MDAwMDAwWhcN MTcwOTE0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALVT rbd+Bi0u5R+vhGeuVvwE4jy3GZm+RANU3wfqsp9Oq7RJYUFCkOcOf2HSFXyOF9fYMIJYxpwyWyPd MLEQ2zJ9cCHtiWSdwAzfXVzSLZefdcBq44JapSCtNs6NHyB468dPBWCOLbsB5R1fhw/7Kx16eFEI VToykNwboBcl48bAJH/E42GeenZZhfBgJTrfYDIo1arlTw2XCqOxyeNxmHZ9N54F/Ay+vR8qewyI wf4pdYd9Hz4hSQ/cAM2ESzdTkGI5SZOSb5uLxtXn7CzUxDdIn09brcRV3tSnazEwP1hTwJ+BMrDS WLVrj8PaEHvrsMHPjgSO7pOIISUSPSn2kJcCAwEAAaOCAWMwggFfMB8GA1UdIwQYMBaAFIbxW2hv 3TDzlIJo1Ez3RB24ymiBMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMzEuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFPfgWqUBFSj+zRkYK8QdUScKB07UMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMzEu Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAlBgNVHREEHjAcgRpyYWRoaWth LnIucm95LmNpdkBtYWlsLm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMA0GCSqGSIb3 DQEBBQUAA4IBAQCg5mLhdie9Opv9asgcTKjz3wcYnoV72Sd8oYj37iaPVht1UIx+elPJV91q8i5B gq8gGaXlgGX+lTQgbhIKtyg/zeJrPQJI0A5ZN4TzfLqf4eUz5pqPh/hV9B8UbigUCW8wNbopPXYX Fu4fwMCOefKe7jx+kXrIUE+2fQtBRw9XaPzsOG0+XlCo6OdGVtkWkY5qmsNbitS78H8iEWSIhvAN dkJzWMhIOwmQ26F1k5DeWeGz7atyOcASJvobl3Xd6emCopMFKt8IoQtssdCmokDM5p6hqlWCVFRk TPVha4nOZH2u5Sj3Ax6lBtBUtWmGZ3jOpXdEtWj3avViyIDAl3aUMIIFAzCCA+ugAwIBAgIDGpBb MA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQx DDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzEwHhcN MTQwOTE1MDAwMDAwWhcNMTcwOTE0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5T LiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYw JAYDVQQDEx1ST1kuUkFESElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAKPCxD4WPTf6htWggvbIv9Zvq4sjmEBXhlX9wsCV8y94oumGlWiaX7GEFMHg lMWNjj58vz5bUzsL2rUCTxORuRR05b7G2wPFr2Q3ebUGAzLjcsTf3d50IxapuF7HYRzrJBSE7ft5 Rx6eBt1AofYBaS6t01CVi1MQHD3/FxeC0Ipow5A3SDbTNY9NSBVGpnnyX5B9yZ3fuhlgzLCZC+Oa iD278MrGeOhMpfeigL9QYypP1bPKPBbhSl/ZgPlf+0CqRrA4tHy/AHr6F1NYt7QlLgfIAQakKUMY H0B3ypI3+FZ/t08hzSHyloomjs+2oZROMXeaD8yCuehULxvMhYZvkGECAwEAAaOCAa4wggGqMB8G A1UdIwQYMBaAFIbxW2hv3TDzlIJo1Ez3RB24ymiBMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9j cmwuZGlzYS5taWwvY3JsL0RPREVNQUlMQ0FfMzEuY3JsMA4GA1UdDwEB/wQEAwIGwDAjBgNVHSAE HDAaMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGAbUYZkuBh8vML199Hbg7zD qi+eMGgGCCsGAQUFBwEBBFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWdu L0RPREVNQUlMQ0FfMzEuY2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDBFBgNV HREEPjA8gRpyYWRoaWthLnIucm95LmNpdkBtYWlsLm1pbKAeBgorBgEEAYI3FAIDoBAMDjEyOTE5 Mzk4MDFAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwKQYDVR0lBCIwIAYKKwYBBAGC NxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUAA4IBAQC9BhFhcZlxDQy+qExu ucegMi61cE1ux2iVlZxJY1FMQ9GAyUy4m4daGY4afM/MuGOIDAC/Ho+Y7rEGnwNYLUN5bKK7IfrT i/CcKJSKX3H/Nw6w7C4mFToUVP+j9WTZfQLhd/8JS1tq8LKJkjePpx2xNMD+cJFQ5x3E9BlBbgYk LU/8f1lM4EDQw2itc24FskmZwAMaa643iJylvMPQ5c9R1KtmsMSxlvZKFl5ENrxI3vkuHEdnz0QG IGSfuOLRA8g3uy2kiaCmGEYz7764mloTsKuuJkRNJka/As0L2tWR2QuVaGgQv6lTYDBhr1adxV7K G0yNn/jeN/auDAscX+lFMIIFUjCCBDqgAwIBAgICA58wDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQ S0kxFjAUBgNVBAMTDURvRCBSb290IENBIDIwHhcNMTMwMTE2MTQ1MjQzWhcNMTkwMTE2MTQ1MjQz WjBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0Qx DDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMxMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA6K4CLEBMOlLoi3OStHfnOEvA8KpKGFzH9zXDSvDwlnell74n78REIYDq FjS3MNFEOH8qzgTGkWWpblB8yE7+vcC1SxbkOFIV27O391M98rEH25FmXcG38ndmxFGaY5QRSwId DUt8swBHB3kY+nizkx/Udm2ZBMUeNkb8BjQL42hvHnyfLM9huEv/tN8Gn6BflF7rNf8JXTVAB/Kd 7ZYJ2Xbq/m4x/sv0ResweEhobKEpPoZ9k0FK6ucMTOWRUCqlQ2a8IsD8Gyzk8y9iHgTUIb+sHyZ3 NdAdvOK7RsLy6+QUrviza7P6cTiwcSnt0Ysb1wIb3srsfu6h3Eil8T6UqQIDAQABo4ICHDCCAhgw HQYDVR0OBBYEFIbxW2hv3TDzlIJo1Ez3RB24ymiBMB8GA1UdIwQYMBaAFEl0uwxeunr+AlTve6DG lcYJgHCWMBIGA1UdEwEB/wQIMAYBAf8CAQAwDAYDVR0kBAUwA4ABADAOBgNVHQ8BAf8EBAMCAYYw ZgYDVR0gBF8wXTALBglghkgBZQIBCwUwCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELETALBglghkgB ZQIBCxIwCwYJYIZIAWUCAQsTMAwGCmCGSAFlAwIBAxowDAYKYIZIAWUDAgEDGzA3BgNVHR8EMDAu MCygKqAohiZodHRwOi8vY3JsLmRpc2EubWlsL2NybC9ET0RST09UQ0EyLmNybDCCAQEGCCsGAQUF BwEBBIH0MIHxMDoGCCsGAQUFBzAChi5odHRwOi8vY3JsLmRpc2EubWlsL2lzc3VlZHRvL0RPRFJP T1RDQTJfSVQucDdjMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDCBkAYIKwYBBQUH MAKGgYNsZGFwOi8vY3JsLmdkcy5kaXNhLm1pbC9jbiUzZERvRCUyMFJvb3QlMjBDQSUyMDIlMmNv dSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2Nyb3Nz Q2VydGlmaWNhdGVQYWlyO2JpbmFyeTANBgkqhkiG9w0BAQUFAAOCAQEAWTKtqsP435xknHEJNMG9 vGMAHi3b7anICOO5GOSvyq4Uwd27+XODg1eOlMmgqgMHzmecteUXWT8ouBc22rqNw5YRAWpQ1gba aKRK0guFfM2I3/9ed+b1pEiR0E6iZ2r4aO+qF0Xv2JYK3c/wPoe2v4g/01S+PhLOofkLbzLRVL+E WzWg2wdktavpeR7i8qp0cueREvfHu27u5XSQECSLt+fNnIWQR+Tib38gvSy7g5YjTahM2H4uXhUp uCV9VzULLRVUjKnc4OU3nahPIJWDK8USNj2oc+FOiEmlubv6CUooWjO55JJ5W3v4pU/zyTTNmYyw umB+n4Q+5jz6flrr5jGCAv4wggL6AgEBMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0zMQIDGpBbMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE1MDEyOTEyNDEwNlowIwYJKoZIhvcNAQkEMRYEFPmG5YfbK8Kua/G7Jj8B 6qrkyXQhMCQGCSqGSIb3DQEJDzEXMBUwCgYIKoZIhvcNAwcwBwYFKw4DAhowcwYJKwYBBAGCNxAE MWYwZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNE b0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMxAgMakF8wdQYLKoZIhvcN AQkQAgsxZqBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNV BAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzECAxqQXzANBgkq hkiG9w0BAQEFAASCAQBKGqbHL3tmVOQdiNhZrbfZPxc04YCt3oVIcAPloUZy6brTs4hAqPD2vnL6 ujlr0HN/qx7L1hhLyBRqcOxUI86JKpZBceqPFAnfbCMwbYfRZwpTNg4/uHUrE4hOJwGbGAt8H9bv E+8Ps7Q0KdbeXhtJO4pBsEi7u4jQOjGqcwjAovBPXA+nwdH2cnNlAcWEGOImc5Q1WmCqlHN+A8zH 6raTyAd5RsGhXoRNg7tasgbjGeEdLUBWlLcTNv+SZL4nVe+SbzaoWUXFbFXS6mWPBaDfKeQ1+Ce2 5VjU7F01RHgffeOajNZKpWm+gv1EX+SBd3XEziq1K1HB5IxB35mgUzBtAAAAAAAA ------=_NextPart_000_0005_01D03B96.F0BB3C00-- From nobody Fri Jan 30 17:23:27 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D07D1A87F0 for ; Fri, 30 Jan 2015 17:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxXydKUWpTnE for ; Fri, 30 Jan 2015 17:23:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46031A1C04 for ; Fri, 30 Jan 2015 17:23:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOP55683; Sat, 31 Jan 2015 01:23:21 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 31 Jan 2015 01:23:20 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.146]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Sat, 31 Jan 2015 09:23:16 +0800 From: "Huangyihong (Rachel)" To: "p2psip@ietf.org" Thread-Topic: Re: [P2PSIP] WGLC for draft-ietf-p2psip-diagnostics-16 Thread-Index: AdA89HzED5DTlkTSR1CWB5zK+JQC6w== Date: Sat, 31 Jan 2015 01:23:16 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB862D14C8@nkgeml501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.144] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB862D14C8nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-diagnostics-16 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 01:23:26 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB862D14C8nkgeml501mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I have read this draft. And I think the current version is in good shape an= d ready for publication. BR, Rachel * * To: p2psip at ietf.org * Subject: [P2PSIP] WGLC for draft-ietf-p2psip-diagnostics-16 * From: Carlos Jes=FAs Bernardos Cano > * Date: Tue, 27 Jan 2015 19:53:48 +0100 * Archived-at: * Cc: p2psip-chairs at tools.ietf.org * Delivered-to: p2psip at ietfa.amsl.com * List-archive: * List-help: * List-id: Peer-to-Peer SIP working group discussion list * List-post: * List-subscribe: , * List-unsubscribe: , * Organization: Universidad Carlos III de Madrid * Reply-to: cjbc at it.uc3m.es ________________________________ Hi, Hereby we are issuing a WGLC for draft-ietf-p2psip-diagnostics-16. The WGLC will be open till the 16th of February. We kindly ask the WG to review the document and provide comments. If you have no comments and think the document is ready to be submitted to IESG, please do send a note stating that to the WG ML. Note that if we don't get some responses to this WGLC showing enough energy & interest to progress this document, we would abandon it. Additional information about the document is below: Title : P2P Overlay Diagnostics Authors : Haibin Song Jiang Xingfeng Roni Even David A. Bryan Yi Sun Filename : draft-ietf-p2psip-diagnostics-16.txt Pages : 29 Date : 2015-01-23 Abstract: This document describes mechanisms for P2P overlay diagnostics. It defines extensions to the RELOAD P2PSIP base protocol to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in P2PSIP overlay networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-16 Thanks -- Brian and Carlos BR, Rachel --_000_51E6A56BD6A85142B9D172C87FC3ABBB862D14C8nkgeml501mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

I have read this draft. And I think the cu= rrent version is in good shape and ready for publication.=

BR,

Rachel

Hi,
 
Hereby we are issuing a WGLC for draft-ietf-p2psi=
p-diagnostics-16.
 
The WGLC will be open till the 16th of February. =
We kindly ask the WG to
review the document and provide comments. If you =
have no comments and
think the document is ready to be submitted to IE=
SG, please do send a
note stating that to the WG ML. Note that if we d=
on't get some responses
to this WGLC showing enough energy & interest=
 to progress this document,
we would abandon it.
 
Additional information about the document is belo=
w:
 
        Title&=
nbsp;          : P2P Overlay D=
iagnostics
        Author=
s         : Haibin Song<=
/span>
        &=
nbsp;           &nbs=
p;     Jiang Xingfeng
        &=
nbsp;           &nbs=
p;     Roni Even
        &=
nbsp;           &nbs=
p;     David A. Bryan
        &=
nbsp;           &nbs=
p;     Yi Sun
        Filena=
me        : draft-ietf-p2psip-diagnostic=
s-16.txt
        Pages&=
nbsp;          : 29=

        Date&n=
bsp;           : 2015-01-=
23
 
Abstract:
   This document describes mechanisms f=
or P2P overlay diagnostics.  It
   defines extensions to the RELOAD P2P=
SIP base protocol to collect
   diagnostic information, and details =
the protocol specifications for
   these extensions.  Useful diagn=
ostic information for connection and
   node status monitoring is also defin=
ed.  The document also describes
   the usage scenarios and provides exa=
mples of how these methods are
   used to perform diagnostics in P2PSI=
P overlay networks.
 
 
The IETF datatracker status page for this draft i=
s:
https://datatracker.ietf.org/doc/draft-ietf-p2ps=
ip-diagnostics/
 
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-p2psip-diagnos=
tics-16
 
Thanks
 
-- Brian and Carlos
 
 

 

 

BR,

Rachel

 

--_000_51E6A56BD6A85142B9D172C87FC3ABBB862D14C8nkgeml501mbschi_-- From nobody Fri Jan 30 21:50:09 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96E41A8876 for ; Fri, 30 Jan 2015 21:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELpE0sWGlMfc for ; Fri, 30 Jan 2015 21:50:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8A361A012D for ; Fri, 30 Jan 2015 21:50:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRX95457; Sat, 31 Jan 2015 05:50:00 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 31 Jan 2015 05:49:59 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.146]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Sat, 31 Jan 2015 13:49:48 +0800 From: "Songhaibin (A)" To: "Roy, Radhika R CIV USARMY (US)" , "p2psip@ietf.org" Thread-Topic: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt Thread-Index: AQHQNuP49RwG5d6TQUagStguaRu7V5zNkJAAgAQBYfCAAEwogIAE/0gQ//+nx4CAAAiqgIADNvnw Date: Sat, 31 Jan 2015 05:49:47 +0000 Message-ID: References: <20150123080935.4605.51843.idtracker@ietfa.amsl.com> <8486C8728176924BAF5BDB2F7D7EEDDF724F6F55@ucolhpkt.easf.csd.disa.mil> <8486C8728176924BAF5BDB2F7D7EEDDF724F71A6@ucolhpkt.easf.csd.disa.mil> <8486C8728176924BAF5BDB2F7D7EEDDF724F7794@ucolhpkt.easf.csd.disa.mil> <8486C8728176924BAF5BDB2F7D7EEDDF724F77EC@ucolhpkt.easf.csd.disa.mil> In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF724F77EC@ucolhpkt.easf.csd.disa.mil> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 05:50:07 -0000 I think in the early discussion in P2PSIP WG. SNMP were not recommended for= the management of p2p networks. Of course, you can extend RELOAD for more = management issues, just like what has been done for the diagnostics. Best Regards! -Haibin > -----Original Message----- > From: Roy, Radhika R CIV USARMY (US) [mailto:radhika.r.roy.civ@mail.mil] > Sent: Thursday, January 29, 2015 8:41 PM > To: Songhaibin (A); p2psip@ietf.org > Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt >=20 > Hi, Haibin and all members of this WG: >=20 > Let me clarify a little more on management works of MANET WG. >=20 > MANET WG has used the SNMP as the base management protocol and has > developed > MIBs for all of the MANET physical routing protocols that have standardiz= ed. >=20 > In our P2PWG, we do have the same. That is, for example P2PSNMP protocol > that is used as the base protocol for management of P2PSIP protocol. >=20 > So, if there is no anything like P2P-Management Protocol, what will do fo= r > management of the P2PSIP? >=20 > Under the umbrella of P2PSIP, we can produce P2P-IM, P2PSIP-Conferencing, > P2P-Binary Floor Control Protocol, P2P-Media Mixing/Bridging Protocol, > P2P-Other protocols that are needed for P2PSIP. >=20 > In the same token, we can produce P2PSIP-Management Protocol. >=20 > We will appreciate comments from all members of the P2PSIP WG. >=20 > BR/Radhika >=20 > -----Original Message----- > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of Roy, Radhika R > CIV USARMY (US) > Sent: Thursday, January 29, 2015 7:10 AM > To: Songhaibin (A); p2psip@ietf.org > Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt >=20 > Hi, Haibin and all members of this WG: >=20 > Right! >=20 > It is also P2P application issue. For example, MANET WG does the routing > protocols for MANETs. However, they also build the RFCs/standards for the > management standards for MANETs for each of the routing protocols they ha= ve > standardized. >=20 > In the same token, it is the P2PSIP WG shall to do the same. We also expe= ct > to produce the RFCs/standards for the P2PSIP management standards/RFCs in > this P2PSIP WG. >=20 > If needed, we can extend our charter. Otherwise, there is be a big gap fo= r > actual adaptation of the P2PSIP applications either using RELOAD or any > other things that this P2PSIP WG has produced or will be producing. >=20 > So, we have to proactive in developing the standards for the management o= f > the P2PSIP (as MANET WG does). >=20 > BR/Radhika >=20 > -----Original Message----- > From: Songhaibin (A) [mailto:haibin.song@huawei.com] > Sent: Thursday, January 29, 2015 4:30 AM > To: Roy, Radhika R CIV USARMY (US); p2psip@ietf.org > Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt >=20 > Hi Radhika, >=20 > This is a management issue rather than a technical issue. >=20 > Best Regards! > -Haibin >=20 >=20 > > -----Original Message----- > > From: Roy, Radhika R CIV USARMY (US) > > [mailto:radhika.r.roy.civ@mail.mil] > > Sent: Monday, January 26, 2015 9:07 PM > > To: Songhaibin (A); p2psip@ietf.org > > Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > > > Hi, Haibin: > > > > Great! > > > > Yes, I also thought the same. We are looking for full management set > > for P2PSIP. > > > > We saw one proposal P2PSNMP draft some time ago. Why did that draft > > authors not continue? > > > > Or, will people create extensions one after another until the full set > > for P2PSIP management available? > > > > BR/Radhika > > > > -----Original Message----- > > From: Songhaibin (A) [mailto:haibin.song@huawei.com] > > Sent: Sunday, January 25, 2015 7:38 PM > > To: Roy, Radhika R CIV USARMY (US); p2psip@ietf.org > > Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > > > Hi Roy, > > > > > > > -----Original Message----- > > > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of Roy, > > > Radhika R CIV USARMY (US) > > > Sent: Saturday, January 24, 2015 3:25 AM > > > To: p2psip@ietf.org > > > Subject: Re: [P2PSIP] I-D Action: > > > draft-ietf-p2psip-diagnostics-16.txt > > > > > > Hi, Song, et al: > > > > > > I have one general question about the draft as follows: > > > > > > 1. Will these diagnostics collection by P2P RELOAD protocol as it is > > > being extended be good enough for P2PSIP management? > > > > It is considered useful for diagnostics at this moment. There can be > > future extensions. It is not a full set. > > > > > 2. Does it mean that we do not need any separate P2P Management > > > Protocol (e.g. P2PSNMP aka like P2PSIP) for management P2PSIP > > > network for all of its nodes that use P2PSIP protocol? > > > > IMO P2P network management and diagnostics are two different concepts, > > and you can have other protocols/extensions for management. > > > > -Haibin > > > > > BR/Radhika > > > > > > -----Original Message----- > > > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of > > > internet-drafts@ietf.org > > > Sent: Friday, January 23, 2015 3:10 AM > > > To: i-d-announce@ietf.org > > > Cc: p2psip@ietf.org > > > Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Peer-to-Peer Session Initiation > > > Protocol Working Group of the IETF. > > > > > > Title : P2P Overlay Diagnostics > > > Authors : Haibin Song > > > Jiang Xingfeng > > > Roni Even > > > David A. Bryan > > > Yi Sun > > > Filename : draft-ietf-p2psip-diagnostics-16.txt > > > Pages : 29 > > > Date : 2015-01-23 > > > > > > Abstract: > > > This document describes mechanisms for P2P overlay diagnostics. I= t > > > defines extensions to the RELOAD P2PSIP base protocol to collect > > > diagnostic information, and details the protocol specifications fo= r > > > these extensions. Useful diagnostic information for connection an= d > > > node status monitoring is also defined. The document also describ= es > > > the usage scenarios and provides examples of how these methods are > > > used to perform diagnostics in P2PSIP overlay networks. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-16 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-diagnostics-16 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www.ietf.org/mailman/listinfo/p2psip From nobody Sat Jan 31 08:21:27 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0F21A1A33 for ; Sat, 31 Jan 2015 08:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En81KHNxTwI8 for ; Sat, 31 Jan 2015 08:21:18 -0800 (PST) Received: from upbd19pa08.eemsg.mail.mil (upbd19pa08.eemsg.mail.mil [214.24.27.83]) by ietfa.amsl.com (Postfix) with ESMTP id 34F6A1A064C for ; Sat, 31 Jan 2015 08:21:15 -0800 (PST) X-EEMSG-Attachment-filename: smime.p7s Received: from edge-cols02.mail.mil ([131.64.104.102]) by upbd19pa08.eemsg.mail.mil with ESMTP; 31 Jan 2015 16:20:58 +0000 Received: from UCOLHPM8.easf.csd.disa.mil (131.64.104.33) by edge-cols02.mail.mil (131.64.104.102) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sat, 31 Jan 2015 16:20:58 +0000 Received: from UCOLHPKT.easf.csd.disa.mil ([169.254.2.202]) by ucolhpm8.easf.csd.disa.mil ([131.64.104.33]) with mapi id 14.03.0224.002; Sat, 31 Jan 2015 16:20:57 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: "Songhaibin (A)" , "p2psip@ietf.org" Thread-Topic: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt Thread-Index: AQHQNuP00hLTrMrU1EWpqWeJ3iYkxpzOFKlwgAN+SwCAAM9csIAEfBcAgAAqQpCAAAhWUIACtKmAgACrnEA= Date: Sat, 31 Jan 2015 16:20:57 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF724F7AFE@ucolhpkt.easf.csd.disa.mil> References: <20150123080935.4605.51843.idtracker@ietfa.amsl.com> <8486C8728176924BAF5BDB2F7D7EEDDF724F6F55@ucolhpkt.easf.csd.disa.mil> <8486C8728176924BAF5BDB2F7D7EEDDF724F71A6@ucolhpkt.easf.csd.disa.mil> <8486C8728176924BAF5BDB2F7D7EEDDF724F7794@ucolhpkt.easf.csd.disa.mil> <8486C8728176924BAF5BDB2F7D7EEDDF724F77EC@ucolhpkt.easf.csd.disa.mil> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.22.13] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01D03D47.F62FE250" MIME-Version: 1.0 Archived-At: Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 16:21:21 -0000 ------=_NextPart_000_0000_01D03D47.F62FE250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Haibin: OK, it provides a direction how we can proceed with RELOAD extensions for all other remaining functions that P2PSIP needs. My guess is that RELOAD provides routing, security, and other infrastructures that all the things that are needed no matter what additional capabilities are needed. Per your suggestion, I think we can proceed as follows: 1. Let us extend RELOAD like diagnostics for additional capabilities for management of the P2PSIP application signaling application protocol. 2. We may have to develop P2P-BFCP for conference floor control and see how RELOAD that provide the basic infrastructure as stated above can be used for this. 3. We may have to develop P2P-Media Channel Protocol for media bridging/mixing and see how RELOAD can be used for this as stated in item 2. 4. Similarly, for others ... Is this direction for the group? BR/Radhika -----Original Message----- From: Songhaibin (A) [mailto:haibin.song@huawei.com] Sent: Saturday, January 31, 2015 12:50 AM To: Roy, Radhika R CIV USARMY (US); p2psip@ietf.org Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt I think in the early discussion in P2PSIP WG. SNMP were not recommended for the management of p2p networks. Of course, you can extend RELOAD for more management issues, just like what has been done for the diagnostics. Best Regards! -Haibin > -----Original Message----- > From: Roy, Radhika R CIV USARMY (US) [mailto:radhika.r.roy.civ@mail.mil] > Sent: Thursday, January 29, 2015 8:41 PM > To: Songhaibin (A); p2psip@ietf.org > Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > Hi, Haibin and all members of this WG: > > Let me clarify a little more on management works of MANET WG. > > MANET WG has used the SNMP as the base management protocol and has > developed > MIBs for all of the MANET physical routing protocols that have standardized. > > In our P2PWG, we do have the same. That is, for example P2PSNMP protocol > that is used as the base protocol for management of P2PSIP protocol. > > So, if there is no anything like P2P-Management Protocol, what will do for > management of the P2PSIP? > > Under the umbrella of P2PSIP, we can produce P2P-IM, P2PSIP-Conferencing, > P2P-Binary Floor Control Protocol, P2P-Media Mixing/Bridging Protocol, > P2P-Other protocols that are needed for P2PSIP. > > In the same token, we can produce P2PSIP-Management Protocol. > > We will appreciate comments from all members of the P2PSIP WG. > > BR/Radhika > > -----Original Message----- > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of Roy, Radhika R > CIV USARMY (US) > Sent: Thursday, January 29, 2015 7:10 AM > To: Songhaibin (A); p2psip@ietf.org > Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > Hi, Haibin and all members of this WG: > > Right! > > It is also P2P application issue. For example, MANET WG does the routing > protocols for MANETs. However, they also build the RFCs/standards for the > management standards for MANETs for each of the routing protocols they have > standardized. > > In the same token, it is the P2PSIP WG shall to do the same. We also expect > to produce the RFCs/standards for the P2PSIP management standards/RFCs in > this P2PSIP WG. > > If needed, we can extend our charter. Otherwise, there is be a big gap for > actual adaptation of the P2PSIP applications either using RELOAD or any > other things that this P2PSIP WG has produced or will be producing. > > So, we have to proactive in developing the standards for the management of > the P2PSIP (as MANET WG does). > > BR/Radhika > > -----Original Message----- > From: Songhaibin (A) [mailto:haibin.song@huawei.com] > Sent: Thursday, January 29, 2015 4:30 AM > To: Roy, Radhika R CIV USARMY (US); p2psip@ietf.org > Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > Hi Radhika, > > This is a management issue rather than a technical issue. > > Best Regards! > -Haibin > > > > -----Original Message----- > > From: Roy, Radhika R CIV USARMY (US) > > [mailto:radhika.r.roy.civ@mail.mil] > > Sent: Monday, January 26, 2015 9:07 PM > > To: Songhaibin (A); p2psip@ietf.org > > Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > > > Hi, Haibin: > > > > Great! > > > > Yes, I also thought the same. We are looking for full management set > > for P2PSIP. > > > > We saw one proposal P2PSNMP draft some time ago. Why did that draft > > authors not continue? > > > > Or, will people create extensions one after another until the full set > > for P2PSIP management available? > > > > BR/Radhika > > > > -----Original Message----- > > From: Songhaibin (A) [mailto:haibin.song@huawei.com] > > Sent: Sunday, January 25, 2015 7:38 PM > > To: Roy, Radhika R CIV USARMY (US); p2psip@ietf.org > > Subject: RE: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > > > Hi Roy, > > > > > > > -----Original Message----- > > > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of Roy, > > > Radhika R CIV USARMY (US) > > > Sent: Saturday, January 24, 2015 3:25 AM > > > To: p2psip@ietf.org > > > Subject: Re: [P2PSIP] I-D Action: > > > draft-ietf-p2psip-diagnostics-16.txt > > > > > > Hi, Song, et al: > > > > > > I have one general question about the draft as follows: > > > > > > 1. Will these diagnostics collection by P2P RELOAD protocol as it is > > > being extended be good enough for P2PSIP management? > > > > It is considered useful for diagnostics at this moment. There can be > > future extensions. It is not a full set. > > > > > 2. Does it mean that we do not need any separate P2P Management > > > Protocol (e.g. P2PSNMP aka like P2PSIP) for management P2PSIP > > > network for all of its nodes that use P2PSIP protocol? > > > > IMO P2P network management and diagnostics are two different concepts, > > and you can have other protocols/extensions for management. > > > > -Haibin > > > > > BR/Radhika > > > > > > -----Original Message----- > > > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of > > > internet-drafts@ietf.org > > > Sent: Friday, January 23, 2015 3:10 AM > > > To: i-d-announce@ietf.org > > > Cc: p2psip@ietf.org > > > Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-16.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Peer-to-Peer Session Initiation > > > Protocol Working Group of the IETF. > > > > > > Title : P2P Overlay Diagnostics > > > Authors : Haibin Song > > > Jiang Xingfeng > > > Roni Even > > > David A. Bryan > > > Yi Sun > > > Filename : draft-ietf-p2psip-diagnostics-16.txt > > > Pages : 29 > > > Date : 2015-01-23 > > > > > > Abstract: > > > This document describes mechanisms for P2P overlay diagnostics. It > > > defines extensions to the RELOAD P2PSIP base protocol to collect > > > diagnostic information, and details the protocol specifications for > > > these extensions. Useful diagnostic information for connection and > > > node status monitoring is also defined. The document also describes > > > the usage scenarios and provides examples of how these methods are > > > used to perform diagnostics in P2PSIP overlay networks. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/ > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-16 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-diagnostics-16 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www.ietf.org/mailman/listinfo/p2psip ------=_NextPart_000_0000_01D03D47.F62FE250 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISjTCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEuDCCA6CgAwIBAgIDGpBfMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzEwHhcNMTQwOTE1MDAwMDAwWhcN MTcwOTE0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALVT rbd+Bi0u5R+vhGeuVvwE4jy3GZm+RANU3wfqsp9Oq7RJYUFCkOcOf2HSFXyOF9fYMIJYxpwyWyPd MLEQ2zJ9cCHtiWSdwAzfXVzSLZefdcBq44JapSCtNs6NHyB468dPBWCOLbsB5R1fhw/7Kx16eFEI VToykNwboBcl48bAJH/E42GeenZZhfBgJTrfYDIo1arlTw2XCqOxyeNxmHZ9N54F/Ay+vR8qewyI wf4pdYd9Hz4hSQ/cAM2ESzdTkGI5SZOSb5uLxtXn7CzUxDdIn09brcRV3tSnazEwP1hTwJ+BMrDS WLVrj8PaEHvrsMHPjgSO7pOIISUSPSn2kJcCAwEAAaOCAWMwggFfMB8GA1UdIwQYMBaAFIbxW2hv 3TDzlIJo1Ez3RB24ymiBMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMzEuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFPfgWqUBFSj+zRkYK8QdUScKB07UMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMzEu Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAlBgNVHREEHjAcgRpyYWRoaWth LnIucm95LmNpdkBtYWlsLm1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMA0GCSqGSIb3 DQEBBQUAA4IBAQCg5mLhdie9Opv9asgcTKjz3wcYnoV72Sd8oYj37iaPVht1UIx+elPJV91q8i5B gq8gGaXlgGX+lTQgbhIKtyg/zeJrPQJI0A5ZN4TzfLqf4eUz5pqPh/hV9B8UbigUCW8wNbopPXYX Fu4fwMCOefKe7jx+kXrIUE+2fQtBRw9XaPzsOG0+XlCo6OdGVtkWkY5qmsNbitS78H8iEWSIhvAN dkJzWMhIOwmQ26F1k5DeWeGz7atyOcASJvobl3Xd6emCopMFKt8IoQtssdCmokDM5p6hqlWCVFRk TPVha4nOZH2u5Sj3Ax6lBtBUtWmGZ3jOpXdEtWj3avViyIDAl3aUMIIFAzCCA+ugAwIBAgIDGpBb MA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQx DDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzEwHhcN MTQwOTE1MDAwMDAwWhcNMTcwOTE0MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5T LiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYw JAYDVQQDEx1ST1kuUkFESElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAKPCxD4WPTf6htWggvbIv9Zvq4sjmEBXhlX9wsCV8y94oumGlWiaX7GEFMHg lMWNjj58vz5bUzsL2rUCTxORuRR05b7G2wPFr2Q3ebUGAzLjcsTf3d50IxapuF7HYRzrJBSE7ft5 Rx6eBt1AofYBaS6t01CVi1MQHD3/FxeC0Ipow5A3SDbTNY9NSBVGpnnyX5B9yZ3fuhlgzLCZC+Oa iD278MrGeOhMpfeigL9QYypP1bPKPBbhSl/ZgPlf+0CqRrA4tHy/AHr6F1NYt7QlLgfIAQakKUMY H0B3ypI3+FZ/t08hzSHyloomjs+2oZROMXeaD8yCuehULxvMhYZvkGECAwEAAaOCAa4wggGqMB8G A1UdIwQYMBaAFIbxW2hv3TDzlIJo1Ez3RB24ymiBMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9j cmwuZGlzYS5taWwvY3JsL0RPREVNQUlMQ0FfMzEuY3JsMA4GA1UdDwEB/wQEAwIGwDAjBgNVHSAE HDAaMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGAbUYZkuBh8vML199Hbg7zD qi+eMGgGCCsGAQUFBwEBBFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWdu L0RPREVNQUlMQ0FfMzEuY2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDBFBgNV HREEPjA8gRpyYWRoaWthLnIucm95LmNpdkBtYWlsLm1pbKAeBgorBgEEAYI3FAIDoBAMDjEyOTE5 Mzk4MDFAbWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwKQYDVR0lBCIwIAYKKwYBBAGC NxQCAgYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUAA4IBAQC9BhFhcZlxDQy+qExu ucegMi61cE1ux2iVlZxJY1FMQ9GAyUy4m4daGY4afM/MuGOIDAC/Ho+Y7rEGnwNYLUN5bKK7IfrT i/CcKJSKX3H/Nw6w7C4mFToUVP+j9WTZfQLhd/8JS1tq8LKJkjePpx2xNMD+cJFQ5x3E9BlBbgYk LU/8f1lM4EDQw2itc24FskmZwAMaa643iJylvMPQ5c9R1KtmsMSxlvZKFl5ENrxI3vkuHEdnz0QG IGSfuOLRA8g3uy2kiaCmGEYz7764mloTsKuuJkRNJka/As0L2tWR2QuVaGgQv6lTYDBhr1adxV7K G0yNn/jeN/auDAscX+lFMIIFUjCCBDqgAwIBAgICA58wDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UE BhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQ S0kxFjAUBgNVBAMTDURvRCBSb290IENBIDIwHhcNMTMwMTE2MTQ1MjQzWhcNMTkwMTE2MTQ1MjQz WjBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0Qx DDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMxMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA6K4CLEBMOlLoi3OStHfnOEvA8KpKGFzH9zXDSvDwlnell74n78REIYDq FjS3MNFEOH8qzgTGkWWpblB8yE7+vcC1SxbkOFIV27O391M98rEH25FmXcG38ndmxFGaY5QRSwId DUt8swBHB3kY+nizkx/Udm2ZBMUeNkb8BjQL42hvHnyfLM9huEv/tN8Gn6BflF7rNf8JXTVAB/Kd 7ZYJ2Xbq/m4x/sv0ResweEhobKEpPoZ9k0FK6ucMTOWRUCqlQ2a8IsD8Gyzk8y9iHgTUIb+sHyZ3 NdAdvOK7RsLy6+QUrviza7P6cTiwcSnt0Ysb1wIb3srsfu6h3Eil8T6UqQIDAQABo4ICHDCCAhgw HQYDVR0OBBYEFIbxW2hv3TDzlIJo1Ez3RB24ymiBMB8GA1UdIwQYMBaAFEl0uwxeunr+AlTve6DG lcYJgHCWMBIGA1UdEwEB/wQIMAYBAf8CAQAwDAYDVR0kBAUwA4ABADAOBgNVHQ8BAf8EBAMCAYYw ZgYDVR0gBF8wXTALBglghkgBZQIBCwUwCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELETALBglghkgB ZQIBCxIwCwYJYIZIAWUCAQsTMAwGCmCGSAFlAwIBAxowDAYKYIZIAWUDAgEDGzA3BgNVHR8EMDAu MCygKqAohiZodHRwOi8vY3JsLmRpc2EubWlsL2NybC9ET0RST09UQ0EyLmNybDCCAQEGCCsGAQUF BwEBBIH0MIHxMDoGCCsGAQUFBzAChi5odHRwOi8vY3JsLmRpc2EubWlsL2lzc3VlZHRvL0RPRFJP T1RDQTJfSVQucDdjMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDCBkAYIKwYBBQUH MAKGgYNsZGFwOi8vY3JsLmdkcy5kaXNhLm1pbC9jbiUzZERvRCUyMFJvb3QlMjBDQSUyMDIlMmNv dSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2Nyb3Nz Q2VydGlmaWNhdGVQYWlyO2JpbmFyeTANBgkqhkiG9w0BAQUFAAOCAQEAWTKtqsP435xknHEJNMG9 vGMAHi3b7anICOO5GOSvyq4Uwd27+XODg1eOlMmgqgMHzmecteUXWT8ouBc22rqNw5YRAWpQ1gba aKRK0guFfM2I3/9ed+b1pEiR0E6iZ2r4aO+qF0Xv2JYK3c/wPoe2v4g/01S+PhLOofkLbzLRVL+E WzWg2wdktavpeR7i8qp0cueREvfHu27u5XSQECSLt+fNnIWQR+Tib38gvSy7g5YjTahM2H4uXhUp uCV9VzULLRVUjKnc4OU3nahPIJWDK8USNj2oc+FOiEmlubv6CUooWjO55JJ5W3v4pU/zyTTNmYyw umB+n4Q+5jz6flrr5jGCAv4wggL6AgEBMGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJ TCBDQS0zMQIDGpBbMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE1MDEzMTE2MjA0N1owIwYJKoZIhvcNAQkEMRYEFEz6n1Cg12zz8bxajamH JZF4ayPWMCQGCSqGSIb3DQEJDzEXMBUwCgYIKoZIhvcNAwcwBwYFKw4DAhowcwYJKwYBBAGCNxAE MWYwZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNE b0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTMxAgMakF8wdQYLKoZIhvcN AQkQAgsxZqBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNV BAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMzECAxqQXzANBgkq hkiG9w0BAQEFAASCAQBh4vhSgAK/uwzpofIX6thLVf04wNqExHd2+0mKuO9y0KinJNbxk7l41Qb9 jAtUb6VxDcAFTxXjmGJE66X6or2CcTSRwa79a15DKIRHX6mmEoHd3Q8eVRsviyA8YiUvbkmGMd9A q6N5faQwVSJrrk+cOJnL9tRMGnzQwJ+SMn6p6lJMbiUH08ISfMlWFCuxxuP2z2Uzjxeh0OhY0J8j cDQRUShoDm6cZRQ35n9jSsKTSzA3+ZawrlTdbsneDtOdLIIB1wDp7Vu1y1ZvH3FA4KmeMApegKJ1 lbHpFPPJfEq5BZgkMsAiKT6yzca97yvC0wbBe9BcA4zbiRVMjHjnT5IfAAAAAAAA ------=_NextPart_000_0000_01D03D47.F62FE250--