From bbl@lowekamp.net Mon Jan 3 13:57:55 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05BB03A6C99 for ; Mon, 3 Jan 2011 13:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJzjbWX0ea8C for ; Mon, 3 Jan 2011 13:57:53 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id A80233A6C98 for ; Mon, 3 Jan 2011 13:57:53 -0800 (PST) Received: by iyi42 with SMTP id 42so13591841iyi.31 for ; Mon, 03 Jan 2011 14:00:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.175.138 with SMTP id ba10mr21510114icb.352.1294092000681; Mon, 03 Jan 2011 14:00:00 -0800 (PST) Received: by 10.42.222.194 with HTTP; Mon, 3 Jan 2011 14:00:00 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Jan 2011 17:00:00 -0500 Message-ID: From: Bruce Lowekamp To: JeffreyHo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Issue about an impact on erroneous judgement of life time for a stored resource after resource migration X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jan 2011 21:57:55 -0000 That timestamp is generated by the storing node, i.e. the one that creates the data in the first place. It's essentially a sequence id that can be used by the overlay to determine which of two objects is newer. It could also have simply been a monotonically increasing counter, but that would require a fetch before store every time. As the section (6) says, if a node needs to store data and finds that a supposedly newer object is stored there due to clock sync problems, the node can just add one to the value stored there. Bruce On Wed, Dec 22, 2010 at 1:13 AM, JeffreyHo wrote: > Dear=C2=A0all, > > I would like to=C2=A0address an issue=C2=A0about erroneous judgement of l= ife time for > a stored resource in Storage Request after resource migration. It might b= e > caused by asynchronized clock among peers. > > In the section of Data Storage Protocol specified in reload=C2=A0base, it= gives > a=C2=A0note that "this does not require synchronized clocks:=C2=A0the rec= eiving peer > uses the storage time in the previous store,=C2=A0not its own clock."=C2= =A0 But it > seems resulting in an impact on life time judgement for checking the > validity period for the stored data=C2=A0after resource migration. If the= clock > is required to be synchronized for all peers on the overlay, the validity > period check can be done dependent on both 'storage_time' and 'lifetime', > even resource migration occurred. But now the 'storage_time' can be used = for > such time operation in the receiving peer, especially for resource migrat= ion > situation. An alternative is that the original responsible peer modify th= e > 'lifetime'=C2=A0in the=C2=A0Store Request before resource migration=C2=A0= for the new > responsible peer so that the new peer can know how much time the migrated > resource will be expired. > > Should we specify the action of modifying the life time for Store Request > when=C2=A0doing resource migration in the reload base specification? Any = response > is welcome. Thanks a lot. > > BR, > Jeffrey > > =E6=9C=AC=E4=BF=A1=E4=BB=B6=E5=8F=AF=E8=83=BD=E5=8C=85=E5=90=AB=E5=B7=A5= =E7=A0=94=E9=99=A2=E6=A9=9F=E5=AF=86=E8=B3=87=E8=A8=8A=EF=BC=8C=E9=9D=9E=E6= =8C=87=E5=AE=9A=E4=B9=8B=E6=94=B6=E4=BB=B6=E8=80=85=EF=BC=8C=E8=AB=8B=E5=8B= =BF=E4=BD=BF=E7=94=A8=E6=88=96=E6=8F=AD=E9=9C=B2=E6=9C=AC=E4=BF=A1=E4=BB=B6= =E5=85=A7=E5=AE=B9=EF=BC=8C=E4=B8=A6=E8=AB=8B=E9=8A=B7=E6=AF=80=E6=AD=A4=E4= =BF=A1=E4=BB=B6=E3=80=82 > This email may contain confidential information. Please do not use or > disclose it in any way and delete it if you are not the intended recipien= t. > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From bbl@lowekamp.net Mon Jan 3 13:58:43 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1D0D3A6C9C for ; Mon, 3 Jan 2011 13:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKAjXl6F4Mr0 for ; Mon, 3 Jan 2011 13:58:41 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id F28ED3A6C9A for ; Mon, 3 Jan 2011 13:58:40 -0800 (PST) Received: by iyi42 with SMTP id 42so13592475iyi.31 for ; Mon, 03 Jan 2011 14:00:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.177.66 with SMTP id bh2mr21552855icb.218.1294092048059; Mon, 03 Jan 2011 14:00:48 -0800 (PST) Received: by 10.42.222.194 with HTTP; Mon, 3 Jan 2011 14:00:47 -0800 (PST) In-Reply-To: References: <026c01cb8952$bf0a06a0$3d1e13e0$%roni@huawei.com> Date: Mon, 3 Jan 2011 17:00:47 -0500 Message-ID: From: Bruce Lowekamp To: "David A. Bryan" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG , Roni Even Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jan 2011 21:58:43 -0000 I support this. Bruce On Wed, Dec 15, 2010 at 4:01 PM, David A. Bryan wrote= : > I think I would be most happy with your suggestion: > >> There's another option where we add a ForwardingOptions flag to the >> base draft that specifies not to keep state about the message, but >> isn't explicitly a DRR flag. =C2=A0There might even be a benefit to doin= g >> that, in that it wouldn't be explicitly tied to the DRR mechanism in >> there now. > > I think this is exactly what I would like to see. > > My concern with the present routing mechanism is it is a bit > underspecified, and also that if we later flesh out a more detailed > one, there will be confusion. I definitely don't want to remove the > routing stuff completely -- we clearly need the flags -- but think the > current attempt at using it for direct routing is a bit > underspecified. I'd rather remove it (leaving the mechanism) so we can > get the next version out with as few changes as possible, and get > RELOAD published so we can move on to other work. > > David (as individual) > > > On Thu, Dec 2, 2010 at 1:53 PM, Bruce Lowekamp wrote: >> The motivation for putting it into the base draft was that if it is >> part of the base spec, then in the future nodes that implement >> whatever is specified in the relay/DRR draft can make use of those >> techniques while on an overlay with nodes that only implement the base >> draft. =C2=A0For example: >> >> - any sort of relay/DRR requires intermediate nodes to not keep any >> state about routed messages. =C2=A0If support for the routing flag that >> allows this is not in the base draft, they will have to simply reject >> the message. >> - knowledge of how to set up a relay node isn't required to make use >> of the relay node. >> >> The intention of the current text was that it could currently only be >> used with no-ice. =C2=A0But it would provide support so that nodes that >> only implement the base draft would be able to forward messages using >> relay/DRR and would also be able to send messages to a relay node in >> the future without knowing the details of how that is set up. =C2=A0As >> currently specified, it definitely needs some text stating explicitly >> that it can currently only be used with no-ice. >> >> There's another option where we add a ForwardingOptions flag to the >> base draft that specifies not to keep state about the message, but >> isn't explicitly a DRR flag. =C2=A0There might even be a benefit to doin= g >> that, in that it wouldn't be explicitly tied to the DRR mechanism in >> there now. >> >> Or , of course, we can remove it completely, at the cost that base >> nodes won't be compatible with whatever is done in the relay/DRR >> draft. >> >> Bruce >> >> >> On Tue, Nov 30, 2010 at 8:03 AM, David A. Bryan wr= ote: >>> I also think the current text is too limiting. The best approach is to >>> make it clear in the draft that other routing techniques are allowed >>> and supported, leave in the flags but remove the very skeletal direct >>> response routing from this draft and we instead do that in the >>> relay/direct response draft. >>> >>> David (as individual) >>> >>> On Sun, Nov 21, 2010 at 3:04 AM, Roni Even wrote= : >>>> >>>>> >>>>> Direct Response Routing and ICE >>>>> =E2=80=A2 Specified in =C2=A75.3.2.4 >>>>> This option can only be used if the direct-return-response-permitted >>>>> flag in the configuration for the overlay is set to TRUE. The >>>>> RESPONSE_COPY flag SHOULD be set to false while the FORWARD_CRITICAL >>>>> and DESTINATION_CRITICAL MUST be set to true. When a node that >>>>> supports this forwarding options receives a request with it, it acts >>>>> as if it had send an Attach request to the the requesting_node and it >>>>> had received the connection_information in the answer. This causes it >>>>> to form a new connection directly to that node. >>>>> =E2=80=A2 This doesn=E2=80=99t work with ICE because the sender of th= e request doesn=E2=80=99t >>>>> have your information >>>>> Proposed Resolution: DRR can only be used with No-ICE >>>>> ***NOTE: This slide generated significant discussion in the meeting. >>>>> There were some comments that this was incomplete, and discussion of >>>>> moving this out of the base draft and into the relay/direct response >>>>> draft. ADDITIONAL DISCUSSION REQUIRED. >>>> >>>> I see the problem and think that we should take this section out from = RELOAD and continue with the individual relay draft (draft-jiang-p2psip-rel= ay-04) for the use case where the node is not behind NAT or a relay can be = used. >>>> In this case we will need to verify that RELOAD allows such extensions= and that there are no issues with supporting it due to some routing assump= tions. >>>> >>>> Roni Even >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> > From bbl@lowekamp.net Mon Jan 3 14:37:29 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26CC83A69EB for ; Mon, 3 Jan 2011 14:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.655 X-Spam-Level: X-Spam-Status: No, score=-0.655 tagged_above=-999 required=5 tests=[AWL=-1.093, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMgBmB-efqEJ for ; Mon, 3 Jan 2011 14:37:27 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 94EE63A69DC for ; Mon, 3 Jan 2011 14:37:27 -0800 (PST) Received: by iyi42 with SMTP id 42so13617529iyi.31 for ; Mon, 03 Jan 2011 14:39:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.167.71 with SMTP id r7mr21588364icy.151.1294094373785; Mon, 03 Jan 2011 14:39:33 -0800 (PST) Received: by 10.42.222.194 with HTTP; Mon, 3 Jan 2011 14:39:33 -0800 (PST) In-Reply-To: References: <33384DCE-ABA1-4D4B-99D1-2916E4C1C04B@orchidseed.org> Date: Mon, 3 Jan 2011 17:39:33 -0500 Message-ID: From: Bruce Lowekamp To: li.lichun1@zte.com.cn Content-Type: multipart/alternative; boundary=90e6ba6e89c2748ea80498f8d31c Cc: P2PSIP WG Subject: Re: [P2PSIP] Where to get configuration file and certificate? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jan 2011 22:37:29 -0000 --90e6ba6e89c2748ea80498f8d31c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think there was a desire to allow an overlay to separate the roles of servers distributing configuration files and handling initial enrollment of new nodes or users. But I agree that the text in 10.2 totally confuses the two. We should clarify that. Thanks. Bruce 2010/12/22 > > Hi, Julian > > I am still confused. > I don't think the user/node certificate is contained in configuration fil= e > because configuration file is redistributed by peers. > The configuration file in Section 10.1 contains the enrollment server's > URL. However, Section 10.2 suggests using DNS to locate enrollment server > and downloading configuration file from enrollment server. > > > > BR > Lichun > > > > *jc * > > 2010-12-17 17:44 > =E6=94=B6=E4=BB=B6=E4=BA=BA > "li.lichun1@zte.com.cn" > =E6=8A=84=E9=80=81 > P2PSIP WG > =E4=B8=BB=E9=A2=98 > Re: [P2PSIP] Where to get configuration file and certificate? > > > > > > > Sent from my iPhone > > On Dec 17, 2010, at 4:08 AM, *li.lichun1@zte.com.cn*wrote: > > > According to Section 3.6, configuration file and certificate are obtained > from configuration server and enrollment server respectively. > But according to Section 10.2, configuration file is obtained from > enrollment server. > > > The enrollment server IS the configuration server. The certificates are > stored in the configuration file on the enrollment server. So this lingo > about "configuration server" should be removed or reworded. > > > BR > Lichun > > > *jc <**julian@orchidseed.org* *>* > > 2010-12-17 16:54 > > =E6=94=B6=E4=BB=B6=E4=BA=BA > "*li.lichun1@zte.com.cn* " <*li.lichun1@zte.com.cn= * > > > =E6=8A=84=E9=80=81 > P2PSIP WG <*p2psip@ietf.org* > > =E4=B8=BB=E9=A2=98 > Re: [P2PSIP] Where to get configuration file and certificate? > > > > > > > What are your questions exactly? > > dns_srv->connect->get->parse_xml is the flow. > > Julian > > On Dec 17, 2010, at 1:51 AM, *li.lichun1@zte.com.cn*wrote: > > > I am confused about the enrollment in RELOAD base draft. > > Section 3.6.1. of RELOAD base draft says: > " The node does a DNS SRV lookup on the > overlay name to get the address of a configuration server. It can > then connect to this server with HTTPS to download a configuration > document which contains the basic overlay configuration parameters as > well as a set of bootstrap nodes which can be used to join the > overlay." > > Section 3.6.2. of RELOAD base draft says: > "In that case, the > configuration document will contain the address of an enrollment > server which can be used to obtain such a certificate." > > Section 10.2. of RELOAD base draft says: > "Once an address and URL for the enrollment server is determined, the > peer forms an HTTPS connection to that IP address. The certificate > MUST match the overlay name as described in [*RFC2818*]. > Then the node > MUST fetch a new copy of the configuration file. To do this, the > peer performs a GET to the URL. " > > BR > Lichun > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy an= d > are not permitted to disclose the contents of this communication to other= s. > This email and any files transmitted with it are confidential and intende= d > solely for the use of the individual or entity to whom they are addressed= . > If you have received this email in error please notify the originator of = the > message. Any views expressed in this message are those of the individual > sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > _______________________________________________ > P2PSIP mailing list* > **P2PSIP@ietf.org* * > **https://www.ietf.org/mailman/listinfo/p2psip* > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy an= d > are not permitted to disclose the contents of this communication to other= s. > This email and any files transmitted with it are confidential and intende= d > solely for the use of the individual or entity to whom they are addressed= . > If you have received this email in error please notify the originator of = the > message. Any views expressed in this message are those of the individual > sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > --90e6ba6e89c2748ea80498f8d31c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think there was a desire to allow an overlay to separate the roles of ser= vers distributing configuration files and handling initial enrollment of ne= w nodes or users. =C2=A0But I agree that the text in 10.2 totally confuses = the two. =C2=A0We should clarify that. =C2=A0Thanks.

Bruce


2010/12/2= 2 <li.lichun= 1@zte.com.cn>

Hi, Julian

I am still confused.
I don't think the user/node ce= rtificate is contained in configuration file because configuration file is redistribu= ted by peers.
The configuration file in Section = 10.1 contains the enrollment server's URL. However, Section 10.2 suggests us= ing DNS to locate enrollment server and downloading configuration file from enrollment server.



BR
Lichun


jc <julian@orchidseed.org&= gt;

2010-12-17 17:44

=E6=94=B6=E4=BB= =B6=E4=BA=BA
"li.lichun1@zte.com.cn" <li.lichun1@zte.com.= cn>
=E6=8A=84=E9=80= =81
P2PSIP WG <p2psip@ietf.org>
=E4=B8=BB=E9=A2= =98
Re: [P2PSIP] Where to get con= figuration file and certificate?







Sent from my iPhone

On Dec 17, 2010, at 4:08 AM, li.lichun1@zte.com.c= n wrote:

According to Section 3.6, configuration file and certificate are obtained from configuration server and enrollment server respectively.
But according to Section 10.2, configuration file is obtained from enrollme= nt server.

The enrollment server IS the configuration server. The certificates are stored in the configuration file on the enrollment server. So this lingo about "configuration server" should be removed or reworded.


BR
Lichun

jc <julian@orchidseed.org>

2010-12-17 16:54


=E6=94=B6=E4=BB= =B6=E4=BA=BA
"li.lichun1@zte.com.cn" <li.lichun1@zte.com.cn= >
=E6=8A=84=E9=80= =81
P2PSIP WG <p2psip@ietf.org>
=E4=B8=BB=E9=A2= =98
Re: [P2PSIP] Where to get con= figuration file and certificate?







What are your questions exactly?

dns_srv->connect->get->parse_xml is the flow.

Julian

On Dec 17, 2010, at 1:51 AM, li.lichun1@zte.com.c= n wrote:


I am confused about the enrollment in RELOAD base draft.

Section 3.6.1. of RELOAD base draft says:
" The node does a DNS SRV lookup on the overlay name to get the address of a configuration server. =C2=A0It can then connect to this server with HTTPS to download a configuration
document which contains the basic overlay configuration parameters as
well as a set of bootstrap nodes which can be used to join the
overlay."

Section 3.6.2. of RELOAD base draft says:
"In that case, the
configuration document will contain the address of an enrollment
server which can be used to obtain such a certificate."

Section 10.2. of RELOAD base draft says:=
"Once an address and URL for the enrollment server is determined, the
peer forms an HTTPS connection to that IP address. =C2=A0The certificate MUST match the overlay name as described in [RFC2818]. =C2=A0Then the node
MUST fetch a new copy of the configuration file. =C2=A0To do this, the
peer performs a GET to the URL. "

BR
Lichun

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communicatio= n is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individua= l sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.=

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman= /listinfo/p2psip

--------------------------------------------------= ------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communicatio= n is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individua= l sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.= 


--------------------------------------------------------
ZTE=C2=A0Information=C2=A0Security=C2=A0Notice:=C2=A0The=C2=A0information=
=C2=A0contained=C2=A0in=C2=A0this=C2=A0mail=C2=A0is=C2=A0solely=C2=A0proper=
ty=C2=A0of=C2=A0the=C2=A0sender's=C2=A0organization.=C2=A0This=C2=A0mai=
l=C2=A0communication=C2=A0is=C2=A0confidential.=C2=A0Recipients=C2=A0named=
=C2=A0above=C2=A0are=C2=A0obligated=C2=A0to=C2=A0maintain=C2=A0secrecy=C2=
=A0and=C2=A0are=C2=A0not=C2=A0permitted=C2=A0to=C2=A0disclose=C2=A0the=C2=
=A0contents=C2=A0of=C2=A0this=C2=A0communication=C2=A0to=C2=A0others.
This=C2=A0email=C2=A0and=C2=A0any=C2=A0files=C2=A0transmitted=C2=A0with=C2=
=A0it=C2=A0are=C2=A0confidential=C2=A0and=C2=A0intended=C2=A0solely=C2=A0fo=
r=C2=A0the=C2=A0use=C2=A0of=C2=A0the=C2=A0individual=C2=A0or=C2=A0entity=C2=
=A0to=C2=A0whom=C2=A0they=C2=A0are=C2=A0addressed.=C2=A0If=C2=A0you=C2=A0ha=
ve=C2=A0received=C2=A0this=C2=A0email=C2=A0in=C2=A0error=C2=A0please=C2=A0n=
otify=C2=A0the=C2=A0originator=C2=A0of=C2=A0the=C2=A0message.=C2=A0Any=C2=
=A0views=C2=A0expressed=C2=A0in=C2=A0this=C2=A0message=C2=A0are=C2=A0those=
=C2=A0of=C2=A0the=C2=A0individual=C2=A0sender.
This=C2=A0message=C2=A0has=C2=A0been=C2=A0scanned=C2=A0for=C2=A0viruses=C2=
=A0and=C2=A0Spam=C2=A0by=C2=A0ZTE=C2=A0Anti-Spam=C2=A0system.

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
= https://www.ietf.org/mailman/listinfo/p2psip


--90e6ba6e89c2748ea80498f8d31c-- From hocs@itri.org.tw Mon Jan 3 22:18:12 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CA813A6B2B for ; Mon, 3 Jan 2011 22:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.95 X-Spam-Level: X-Spam-Status: No, score=-98.95 tagged_above=-999 required=5 tests=[AWL=2.314, BAYES_00=-2.599, HELO_EQ_TW=1.335, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iyyrf2z1+-lU for ; Mon, 3 Jan 2011 22:18:11 -0800 (PST) Received: from maillog1.itri.org.tw (maillog.itri.org.tw [61.61.254.185]) by core3.amsl.com (Postfix) with ESMTP id 392B63A67A5 for ; Mon, 3 Jan 2011 22:18:11 -0800 (PST) Received: from msx.itri.org.tw ([140.96.151.58]) by maillog1.itri.org.tw with ESMTP id p046KFJQ052598; Tue, 4 Jan 2011 14:20:15 +0800 (CST) (envelope-from hocs@itri.org.tw) Received: from 52092035393 (140.96.150.239) by smtpx.itri.org.tw (140.96.151.58) with Microsoft SMTP Server id 8.3.137.0; Tue, 4 Jan 2011 14:20:15 +0800 From: JeffreyHo To: "'Bruce Lowekamp'" Date: Tue, 4 Jan 2011 14:20:20 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcurkZXbFxhd0/4lSXOh1RN7fcmYpQAIuDRwAAGIAyA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-MAIL: maillog1.itri.org.tw p046KFJQ052598 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Issue about an impact on erroneous judgement of life time for a stored resource after resource migration X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jan 2011 06:18:12 -0000 Thank Bruce's comment. But I am sorry that I didn't express my question clearly so that it might m= ake Bruce misunderstand this issue.=20 In a word, my question is that how the stored peer determinates whether a r= esource has been expired based on 'lifetime' value after resource migration= . I address a scenario below. 1. Peer-1 stores a resource A with 'lifetime' of 1 hour to Peer-2. 2. After 30 mins, Peer-3 joins to between Peer-1 and Peer-2. 3. Peer-2 occurs resource migration, so Peer-2 stores the resource A to Pee= r-3. Please note the value of 'lifetime' is still 1 hour. 4. After 30 mins, Peer-3 can't detect the resource A to be expired because = the 'lifetime' is 1 hour not 30 mins. One solution is that Peer-3 detects whether the resource A has been expired= according to compare the current time with 'storage_time' + 'lifetime'. Bu= t this will fail if Peer-3 and Peer-1 are not clock sync. The other solution is that in step 3 above, Peer-2 decreases the 'lifetime'= first, then migrate the resource A to Peer-3. But this needs to add the sp= ecification in reload base. Hope I address my question more clear this time. Looking forward to receivi= ng your further comment.=20 Thanks a lot. Jeffrey=20 -----Original Message----- From: Bruce Lowekamp [mailto:bbl@lowekamp.net] Sent: Tuesday, January 04, 2011 6:00 AM To: =E4=BD=95=E5=93=B2=E5=8B=B3 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Issue about an impact on erroneous judgement of life = time for a stored resource after resource migration That timestamp is generated by the storing node, i.e. the one that creates = the data in the first place. It's essentially a sequence id that can be us= ed by the overlay to determine which of two objects is newer. It could als= o have simply been a monotonically increasing counter, but that would requi= re a fetch before store every time. As the section (6) says, if a node nee= ds to store data and finds that a supposedly newer object is stored there d= ue to clock sync problems, the node can just add one to the value stored th= ere. Bruce On Wed, Dec 22, 2010 at 1:13 AM, JeffreyHo wrote: > Dear all, > > I would like to address an issue about erroneous judgement of life=20 > time for a stored resource in Storage Request after resource=20 > migration. It might be caused by asynchronized clock among peers. > > In the section of Data Storage Protocol specified in reload base, it=20 > gives a note that "this does not require synchronized clocks: the=20 > receiving peer uses the storage time in the previous store, not its=20 > own clock." But it seems resulting in an impact on life time=20 > judgement for checking the validity period for the stored data after=20 > resource migration. If the clock is required to be synchronized for=20 > all peers on the overlay, the validity period check can be done=20 > dependent on both 'storage_time' and 'lifetime', even resource=20 > migration occurred. But now the 'storage_time' can be used for such=20 > time operation in the receiving peer, especially for resource=20 > migration situation. An alternative is that the original responsible=20 > peer modify the 'lifetime' in the Store Request before resource=20 > migration for the new responsible peer so that the new peer can know how = much time the migrated resource will be expired. > > Should we specify the action of modifying the life time for Store=20 > Request when doing resource migration in the reload base=20 > specification? Any response is welcome. Thanks a lot. > > BR, > Jeffrey > > =E6=9C=AC=E4=BF=A1=E4=BB=B6=E5=8F=AF=E8=83=BD=E5=8C=85=E5=90=AB=E5=B7=A5= =E7=A0=94=E9=99=A2=E6=A9=9F=E5=AF=86=E8=B3=87=E8=A8=8A=EF=BC=8C=E9=9D=9E=E6= =8C=87=E5=AE=9A=E4=B9=8B=E6=94=B6=E4=BB=B6=E8=80=85=EF=BC=8C=E8=AB=8B=E5=8B= =BF=E4=BD=BF=E7=94=A8=E6=88=96=E6=8F=AD=E9=9C=B2=E6=9C=AC=E4=BF=A1=E4=BB=B6= =E5=85=A7=E5=AE=B9=EF=BC=8C=E4=B8=A6=E8=AB=8B=E9=8A=B7=E6=AF=80=E6=AD=A4=E4= =BF=A1=E4=BB=B6=E3=80=82 > This email may contain confidential information. Please do not use or=20 > disclose it in any way and delete it if you are not the intended recipien= t. > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =E6=9C=AC=E4=BF=A1=E4=BB=B6=E5=8F=AF=E8=83=BD=E5=8C=85=E5=90=AB=E5=B7=A5=E7= =A0=94=E9=99=A2=E6=A9=9F=E5=AF=86=E8=B3=87=E8=A8=8A=EF=BC=8C=E9=9D=9E=E6=8C= =87=E5=AE=9A=E4=B9=8B=E6=94=B6=E4=BB=B6=E8=80=85=EF=BC=8C=E8=AB=8B=E5=8B=BF= =E4=BD=BF=E7=94=A8=E6=88=96=E6=8F=AD=E9=9C=B2=E6=9C=AC=E4=BF=A1=E4=BB=B6=E5= =85=A7=E5=AE=B9=EF=BC=8C=E4=B8=A6=E8=AB=8B=E9=8A=B7=E6=AF=80=E6=AD=A4=E4=BF= =A1=E4=BB=B6=E3=80=82=20 This email may contain confidential information. Please do not use or discl= ose it in any way and delete it if you are not the intended recipient. From Even.roni@huawei.com Thu Jan 6 06:09:30 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738103A6F19 for ; Thu, 6 Jan 2011 06:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ANsJHWZLQ72 for ; Thu, 6 Jan 2011 06:09:29 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 324E33A6E28 for ; Thu, 6 Jan 2011 06:09:29 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEL000DUU314V@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 06 Jan 2011 22:11:25 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEL00J0HU31HE@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 06 Jan 2011 22:11:25 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-17-26.red.bezeqint.net [79.178.17.26]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEL006WJU2WHT@szxml02-in.huawei.com>; Thu, 06 Jan 2011 22:11:25 +0800 (CST) Date: Thu, 06 Jan 2011 16:07:56 +0200 From: Roni Even In-reply-to: To: 'Bruce Lowekamp' , "'David A. Bryan'" Message-id: <021a01cbadab$21b4eff0$651ecfd0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcuSUk73aebZ9cERSDOhJESTNyblvwbWIXSw References: <026c01cb8952$bf0a06a0$3d1e13e0$%roni@huawei.com> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 06 Jan 2011 14:09:30 -0000 Hi Bruce, I think that the flag for not keeping state may be useful but there is = also another mechanism which is the time out that tells intermediate = nodes to discard any state after a timeout. Roni > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf Of Bruce Lowekamp > Sent: Thursday, December 02, 2010 8:54 PM > To: David A. Bryan > Cc: P2PSIP WG; Roni Even > Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft = from > meeting - DRR >=20 > The motivation for putting it into the base draft was that if it is > part of the base spec, then in the future nodes that implement > whatever is specified in the relay/DRR draft can make use of those > techniques while on an overlay with nodes that only implement the base > draft. For example: >=20 > - any sort of relay/DRR requires intermediate nodes to not keep any > state about routed messages. If support for the routing flag that > allows this is not in the base draft, they will have to simply reject > the message. > - knowledge of how to set up a relay node isn't required to make use > of the relay node. >=20 > The intention of the current text was that it could currently only be > used with no-ice. But it would provide support so that nodes that > only implement the base draft would be able to forward messages using > relay/DRR and would also be able to send messages to a relay node in > the future without knowing the details of how that is set up. As > currently specified, it definitely needs some text stating explicitly > that it can currently only be used with no-ice. >=20 > There's another option where we add a ForwardingOptions flag to the > base draft that specifies not to keep state about the message, but > isn't explicitly a DRR flag. There might even be a benefit to doing > that, in that it wouldn't be explicitly tied to the DRR mechanism in > there now. >=20 > Or , of course, we can remove it completely, at the cost that base > nodes won't be compatible with whatever is done in the relay/DRR > draft. >=20 > Bruce >=20 >=20 > On Tue, Nov 30, 2010 at 8:03 AM, David A. Bryan > wrote: > > I also think the current text is too limiting. The best approach is > to > > make it clear in the draft that other routing techniques are allowed > > and supported, leave in the flags but remove the very skeletal = direct > > response routing from this draft and we instead do that in the > > relay/direct response draft. > > > > David (as individual) > > > > On Sun, Nov 21, 2010 at 3:04 AM, Roni Even > wrote: > >> > >>> > >>> Direct Response Routing and ICE > >>> =E2=80=A2 Specified in =C2=A75.3.2.4 > >>> This option can only be used if the direct-return-response- > permitted > >>> flag in the configuration for the overlay is set to TRUE. The > >>> RESPONSE_COPY flag SHOULD be set to false while the > FORWARD_CRITICAL > >>> and DESTINATION_CRITICAL MUST be set to true. When a node that > >>> supports this forwarding options receives a request with it, it > acts > >>> as if it had send an Attach request to the the requesting_node and > it > >>> had received the connection_information in the answer. This causes > it > >>> to form a new connection directly to that node. > >>> =E2=80=A2 This doesn=E2=80=99t work with ICE because the sender of = the request > doesn=E2=80=99t > >>> have your information > >>> Proposed Resolution: DRR can only be used with No-ICE > >>> ***NOTE: This slide generated significant discussion in the > meeting. > >>> There were some comments that this was incomplete, and discussion > of > >>> moving this out of the base draft and into the relay/direct > response > >>> draft. ADDITIONAL DISCUSSION REQUIRED. > >> > >> I see the problem and think that we should take this section out > from RELOAD and continue with the individual relay draft (draft-jiang- > p2psip-relay-04) for the use case where the node is not behind NAT or = a > relay can be used. > >> In this case we will need to verify that RELOAD allows such > extensions and that there are no issues with supporting it due to some > routing assumptions. > >> > >> Roni Even > >> > >> > >> > >> > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Thu Jan 6 15:37:39 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8467C3A6E3F for ; Thu, 6 Jan 2011 15:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.535 X-Spam-Level: X-Spam-Status: No, score=-101.535 tagged_above=-999 required=5 tests=[AWL=0.730, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qF0HejQPngvQ for ; Thu, 6 Jan 2011 15:37:38 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 884DF3A6D23 for ; Thu, 6 Jan 2011 15:37:38 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 8E929DFC4010; Thu, 6 Jan 2011 23:39:44 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 132B2DFC400E for ; Thu, 6 Jan 2011 23:39:44 +0000 (UTC) Message-ID: <4D2652BE.9030601@acm.org> Date: Thu, 06 Jan 2011 15:39:42 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: 'P2PSIP WG' X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] draft-ietf-p2psip-base-12 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 06 Jan 2011 23:37:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Any chance to receive some kind of answer to my questions? http://www.ietf.org/mail-archive/web/p2psip/current/msg05751.html http://www.ietf.org/mail-archive/web/p2psip/current/msg05756.html http://www.ietf.org/mail-archive/web/p2psip/current/msg05766.html - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk0mUrwACgkQ9RoMZyVa61cYTwCgpHuuO0tiPE65T4sRWvgOlE4S mYIAmwc0+azr1jgiOhggj0uuw1ws7M+q =Jbc8 -----END PGP SIGNATURE----- From Internet-Drafts@ietf.org Fri Jan 7 08:00:04 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D000E3A6922; Fri, 7 Jan 2011 08:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKowoWCXpPK9; Fri, 7 Jan 2011 08:00:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB94D3A691A; Fri, 7 Jan 2011 08:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110107160002.6107.70095.idtracker@localhost> Date: Fri, 07 Jan 2011 08:00:02 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-self-tuning-03.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2011 16:00:04 -0000 --NextPart 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 Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD) Author(s) : J. Maenpaa, et al. Filename : draft-ietf-p2psip-self-tuning-03.txt Pages : 20 Date : 2011-01-07 REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay, and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-self-tuning-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-p2psip-self-tuning-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-07075607.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Fri Jan 7 08:00:05 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B4D63A6921; Fri, 7 Jan 2011 08:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwqdeLZeNHLe; Fri, 7 Jan 2011 08:00:04 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 951CF3A6920; Fri, 7 Jan 2011 08:00:03 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110107160003.6107.50304.idtracker@localhost> Date: Fri, 07 Jan 2011 08:00:03 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-service-discovery-02.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2011 16:00:05 -0000 --NextPart 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 : Service Discovery Usage for REsource LOcation And Discovery (RELOAD) Author(s) : J. Maenpaa, G. Camarillo Filename : draft-ietf-p2psip-service-discovery-02.txt Pages : 14 Date : 2011-01-07 REsource LOcation and Discovery (RELOAD) does not define a generic service discovery mechanism as part of the base protocol. This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism used in OpenDHT can be applied to RELOAD overlays to provide a generic service discovery mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-service-discovery-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-p2psip-service-discovery-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-07075944.I-D@ietf.org> --NextPart-- From bbl@lowekamp.net Fri Jan 7 14:22:46 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7736E28C124 for ; Fri, 7 Jan 2011 14:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJt43kC6iHHK for ; Fri, 7 Jan 2011 14:22:45 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id B3F8A28C0D0 for ; Fri, 7 Jan 2011 14:22:20 -0800 (PST) Received: by iwn40 with SMTP id 40so18730541iwn.31 for ; Fri, 07 Jan 2011 14:24:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.166.198 with SMTP id p6mr1397425icy.345.1294439065642; Fri, 07 Jan 2011 14:24:25 -0800 (PST) Received: by 10.42.217.136 with HTTP; Fri, 7 Jan 2011 14:24:25 -0800 (PST) In-Reply-To: <4CEAC54A.2030503@acm.org> References: <4CEAC54A.2030503@acm.org> Date: Fri, 7 Jan 2011 17:24:25 -0500 Message-ID: From: Bruce Lowekamp To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (2) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2011 22:22:46 -0000 inline On Mon, Nov 22, 2010 at 2:32 PM, Marc Petit-Huguenin wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > More questions, comments and nits: > > - - A.9. In section 5.1.2, 5th paragraph: "As an example of the second st= rategy, > if node D receives a message from node C with transaction X and via list = (A, B), > it could store (X, C) in its state database and forward the message with = the via > list unchanged. =C2=A0When D receives the response, it consults its state= database > for transaction id X, determines that the request came from C, and forwar= ds the > response to C." > > If I understand correctly this whole paragraph, when a message is forward= ed it > keeps the same transaction_id, because if the response received by D was = using a > different transaction_id, say Y, it could not retrieve (X, C) from the st= ate > database. =C2=A0Is this analysis correct? A message should always keep the same transaction ID. The paragraph is really just trying to point out that you can keep a map of tid -> return node for your routing state. > > - - A.10. It seems that this version of RELOAD lacks the support of virtu= al > servers (see draft-harjula-p2psip-loadbalancing-survey), more precisely a= way to > share connections between two virtual servers on the same physical server= (see > Frank Dabek, M. Frans Kaashoek, David Karger, Robert Morris, Ion Stoica, > Wide-area cooperative storage with CFS: "Use of virtual servers could > potentially increase the number of hops in a Chord lookup. =C2=A0CFS avoi= ds this > expense by allowing virtual servers on the same physical server to examin= e each > others' tables: the fact that these virtual servers can take short-cuts t= hrough > each others' routing table exactly compensates for the increases number o= f > servers."). =C2=A0Because the certificates contains a list of Node-IDs, i= t is not > possible to know on a hop by hop basis what are the source and destinatio= n > NodeIds of a specific message. =C2=A0Section 3 of > draft-rosenberg-dispatch-vipr-reload-usage seems to acknowledge that by a= dding a > PeerID Shim to exchange the source and destination peerIDs (aka Node-IDs)= . > > Because of this, it is probably a good idea to add in p2psip-base the > possibility to know the source Node-ID and destination Node-ID of a messa= ge. > One way to do that would have be to have the sender of a message add its = own > Node-ID in the via_list, and the Node-ID of the destination in the > destination_list before sending a message (similar to what SIP is doing),= but I > guess that it is too late for such a modification. > I totally agree that vnodes should share routing state. But it's not clear to me what benefit would be obtained by making that sort of a protocol change. * on request routing, a message should normally have exactly one destination node-id. The only reason to have more would be that the request sender has some particular reason to want to source-route the request. * on response sending, with recursive response you simply want to reverse the initial request routing. If there was an advantage to "short-cutting" between v-nodes, it would have been done on the request routing. If you're not doing recursive response routing, then this case is the same as request routing. > - - A.11. Looking at the examples in section 3.3, it seems that the via_l= ist is > updated only when the message forwarded is a request but not for response= s, but > I cannot find this anywhere in the text. =C2=A0So are all messages proces= sed the same > way when forwarded (and via updated on all types of messages) or specific= ally on > requests? (by testing the last bit of message_code). > I think it's implied in 5.1 that the via list is only added to on request routing and not response, but I believe it should be made more clear. Bruce > - - A.12. Section 10.3 states that "[t]he SubjectAltName field in the cer= tificate > contains the following values: One or more Node-IDs...", but nowhere it i= s said > how to request multiple Node-IDs. =C2=A0Is it an URL parameter of the POS= T request? > An attribute in the Certification Request object? > > > Nits > =3D=3D=3D=3D > > - - Section 5.3, in the list "Security Block:" > > s/""Message Contents"/"Message Contents"/ > > - - Section 5.3.2.1 > > s/destination_value/destination_data/ > > - - Section 5.3.4 "overlay + transaction_id + MessageContents + SignerIde= ntity" > > The "+" should probably be replaced with "||". > > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAkzqxUgACgkQ9RoMZyVa61fLpQCglb3AQGXUnEmD6athMaIGFBAx > vLkAn2r+Gy54Z/sJHMNv/j0i4Ic4y2ZZ > =3DbP6t > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From bbl@lowekamp.net Fri Jan 7 14:27:31 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B792728C160 for ; Fri, 7 Jan 2011 14:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtzAPqUizcH2 for ; Fri, 7 Jan 2011 14:27:30 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 44E1D28C138 for ; Fri, 7 Jan 2011 14:27:27 -0800 (PST) Received: by iwn40 with SMTP id 40so18733505iwn.31 for ; Fri, 07 Jan 2011 14:29:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.165.199 with SMTP id l7mr1391446icy.412.1294439374159; Fri, 07 Jan 2011 14:29:34 -0800 (PST) Received: by 10.42.217.136 with HTTP; Fri, 7 Jan 2011 14:29:34 -0800 (PST) In-Reply-To: <021a01cbadab$21b4eff0$651ecfd0$%roni@huawei.com> References: <026c01cb8952$bf0a06a0$3d1e13e0$%roni@huawei.com> <021a01cbadab$21b4eff0$651ecfd0$%roni@huawei.com> Date: Fri, 7 Jan 2011 17:29:34 -0500 Message-ID: From: Bruce Lowekamp To: Roni Even Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2011 22:27:31 -0000 I think requiring the state timeout mechanism to be used for every message would be a bit much to put on the peers. I would rather provide the explicit flag. Bruce On Thu, Jan 6, 2011 at 9:07 AM, Roni Even wrote: > Hi Bruce, > I think that the flag for not keeping state may be useful but there is al= so another mechanism which is the time out that tells intermediate nodes to= discard any state after a timeout. > Roni > >> -----Original Message----- >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >> Behalf Of Bruce Lowekamp >> Sent: Thursday, December 02, 2010 8:54 PM >> To: David A. Bryan >> Cc: P2PSIP WG; Roni Even >> Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from >> meeting - DRR >> >> The motivation for putting it into the base draft was that if it is >> part of the base spec, then in the future nodes that implement >> whatever is specified in the relay/DRR draft can make use of those >> techniques while on an overlay with nodes that only implement the base >> draft. =C2=A0For example: >> >> - any sort of relay/DRR requires intermediate nodes to not keep any >> state about routed messages. =C2=A0If support for the routing flag that >> allows this is not in the base draft, they will have to simply reject >> the message. >> - knowledge of how to set up a relay node isn't required to make use >> of the relay node. >> >> The intention of the current text was that it could currently only be >> used with no-ice. =C2=A0But it would provide support so that nodes that >> only implement the base draft would be able to forward messages using >> relay/DRR and would also be able to send messages to a relay node in >> the future without knowing the details of how that is set up. =C2=A0As >> currently specified, it definitely needs some text stating explicitly >> that it can currently only be used with no-ice. >> >> There's another option where we add a ForwardingOptions flag to the >> base draft that specifies not to keep state about the message, but >> isn't explicitly a DRR flag. =C2=A0There might even be a benefit to doin= g >> that, in that it wouldn't be explicitly tied to the DRR mechanism in >> there now. >> >> Or , of course, we can remove it completely, at the cost that base >> nodes won't be compatible with whatever is done in the relay/DRR >> draft. >> >> Bruce >> >> >> On Tue, Nov 30, 2010 at 8:03 AM, David A. Bryan >> wrote: >> > I also think the current text is too limiting. The best approach is >> to >> > make it clear in the draft that other routing techniques are allowed >> > and supported, leave in the flags but remove the very skeletal direct >> > response routing from this draft and we instead do that in the >> > relay/direct response draft. >> > >> > David (as individual) >> > >> > On Sun, Nov 21, 2010 at 3:04 AM, Roni Even >> wrote: >> >> >> >>> >> >>> Direct Response Routing and ICE >> >>> =E2=80=A2 Specified in =C2=A75.3.2.4 >> >>> This option can only be used if the direct-return-response- >> permitted >> >>> flag in the configuration for the overlay is set to TRUE. The >> >>> RESPONSE_COPY flag SHOULD be set to false while the >> FORWARD_CRITICAL >> >>> and DESTINATION_CRITICAL MUST be set to true. When a node that >> >>> supports this forwarding options receives a request with it, it >> acts >> >>> as if it had send an Attach request to the the requesting_node and >> it >> >>> had received the connection_information in the answer. This causes >> it >> >>> to form a new connection directly to that node. >> >>> =E2=80=A2 This doesn=E2=80=99t work with ICE because the sender of t= he request >> doesn=E2=80=99t >> >>> have your information >> >>> Proposed Resolution: DRR can only be used with No-ICE >> >>> ***NOTE: This slide generated significant discussion in the >> meeting. >> >>> There were some comments that this was incomplete, and discussion >> of >> >>> moving this out of the base draft and into the relay/direct >> response >> >>> draft. ADDITIONAL DISCUSSION REQUIRED. >> >> >> >> I see the problem and think that we should take this section out >> from RELOAD and continue with the individual relay draft (draft-jiang- >> p2psip-relay-04) for the use case where the node is not behind NAT or a >> relay can be used. >> >> In this case we will need to verify that RELOAD allows such >> extensions and that there are no issues with supporting it due to some >> routing assumptions. >> >> >> >> Roni Even >> >> >> >> >> >> >> >> >> > _______________________________________________ >> > P2PSIP mailing list >> > P2PSIP@ietf.org >> > https://www.ietf.org/mailman/listinfo/p2psip >> > >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > From bbl@lowekamp.net Fri Jan 7 15:37:04 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF5CF28B797 for ; Fri, 7 Jan 2011 15:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H43-QqSEUpc for ; Fri, 7 Jan 2011 15:37:03 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2BAA83A69B0 for ; Fri, 7 Jan 2011 15:37:03 -0800 (PST) Received: by iwn40 with SMTP id 40so18771707iwn.31 for ; Fri, 07 Jan 2011 15:39:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.229.7 with SMTP id jg7mr1465845icb.211.1294443549925; Fri, 07 Jan 2011 15:39:09 -0800 (PST) Received: by 10.42.217.136 with HTTP; Fri, 7 Jan 2011 15:39:09 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Jan 2011 18:39:09 -0500 Message-ID: From: Bruce Lowekamp To: JeffreyHo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Issue about an impact on erroneous judgement of life time for a stored resource after resource migration X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 07 Jan 2011 23:37:05 -0000 The idea is that lifetime is time in seconds for which the data is valid. e.g. if the data is valid for one hour, it would be set to 3600 on the initial store. Somewhere, there should be an instruction that any time a data object is transferred across the wire, this field is adjusted, but I can't find it anywhere, only: When a peer stores data previously stored by another node (e.g., for replicas or topology shifts) it MUST adjust the lifetime value downward to reflect the amount of time the value was stored at the peer. which doesn't specify a mechanism for accomplishing this. Also, there's some material in 12.5.3 which I think is really unclear as it mixes storage time and lifetime. We will try to update the text to clarify these issues. Bruce On Tue, Jan 4, 2011 at 1:20 AM, JeffreyHo wrote: > Thank Bruce's comment. > But I am sorry that I didn't express my question clearly so that it might= make Bruce misunderstand this issue. > In a word, my question is that how the stored peer determinates whether a= resource has been expired based on 'lifetime' value after resource migrati= on. I address a scenario below. > 1. Peer-1 stores a resource A with 'lifetime' of 1 hour to Peer-2. > 2. After 30 mins, Peer-3 joins to between Peer-1 and Peer-2. > 3. Peer-2 occurs resource migration, so Peer-2 stores the resource A to P= eer-3. Please note the value of 'lifetime' is still 1 hour. > 4. After 30 mins, Peer-3 can't detect the resource A to be expired becaus= e the 'lifetime' is 1 hour not 30 mins. > > One solution is that Peer-3 detects whether the resource A has been expir= ed according to compare the current time with 'storage_time' + 'lifetime'. = But this will fail if Peer-3 and Peer-1 are not clock sync. > The other solution is that in step 3 above, Peer-2 decreases the 'lifetim= e' first, then migrate the resource A to Peer-3. But this needs to add the = specification in reload base. > > Hope I address my question more clear this time. Looking forward to recei= ving your further comment. > Thanks a lot. > > Jeffrey > > -----Original Message----- > From: Bruce Lowekamp [mailto:bbl@lowekamp.net] > Sent: Tuesday, January 04, 2011 6:00 AM > To: =E4=BD=95=E5=93=B2=E5=8B=B3 > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] Issue about an impact on erroneous judgement of lif= e time for a stored resource after resource migration > > That timestamp is generated by the storing node, i.e. the one that create= s the data in the first place. =C2=A0It's essentially a sequence id that ca= n be used by the overlay to determine which of two objects is newer. =C2=A0= It could also have simply been a monotonically increasing counter, but that= would require a fetch before store every time. =C2=A0As the section (6) sa= ys, if a node needs to store data and finds that a supposedly newer object = is stored there due to clock sync problems, the node can just add one to th= e value stored there. > > Bruce > > > On Wed, Dec 22, 2010 at 1:13 AM, JeffreyHo wrote: >> Dear all, >> >> I would like to address an issue about erroneous judgement of life >> time for a stored resource in Storage Request after resource >> migration. It might be caused by asynchronized clock among peers. >> >> In the section of Data Storage Protocol specified in reload base, it >> gives a note that "this does not require synchronized clocks: the >> receiving peer uses the storage time in the previous store, not its >> own clock." =C2=A0But it seems resulting in an impact on life time >> judgement for checking the validity period for the stored data after >> resource migration. If the clock is required to be synchronized for >> all peers on the overlay, the validity period check can be done >> dependent on both 'storage_time' and 'lifetime', even resource >> migration occurred. But now the 'storage_time' can be used for such >> time operation in the receiving peer, especially for resource >> migration situation. An alternative is that the original responsible >> peer modify the 'lifetime' in the Store Request before resource >> migration for the new responsible peer so that the new peer can know how= much time the migrated resource will be expired. >> >> Should we specify the action of modifying the life time for Store >> Request when doing resource migration in the reload base >> specification? Any response is welcome. Thanks a lot. >> >> BR, >> Jeffrey >> >> =E6=9C=AC=E4=BF=A1=E4=BB=B6=E5=8F=AF=E8=83=BD=E5=8C=85=E5=90=AB=E5=B7=A5= =E7=A0=94=E9=99=A2=E6=A9=9F=E5=AF=86=E8=B3=87=E8=A8=8A=EF=BC=8C=E9=9D=9E=E6= =8C=87=E5=AE=9A=E4=B9=8B=E6=94=B6=E4=BB=B6=E8=80=85=EF=BC=8C=E8=AB=8B=E5=8B= =BF=E4=BD=BF=E7=94=A8=E6=88=96=E6=8F=AD=E9=9C=B2=E6=9C=AC=E4=BF=A1=E4=BB=B6= =E5=85=A7=E5=AE=B9=EF=BC=8C=E4=B8=A6=E8=AB=8B=E9=8A=B7=E6=AF=80=E6=AD=A4=E4= =BF=A1=E4=BB=B6=E3=80=82 >> This email may contain confidential information. Please do not use or >> disclose it in any way and delete it if you are not the intended recipie= nt. >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> >> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =E6=9C=AC=E4=BF=A1=E4=BB=B6=E5=8F=AF=E8=83=BD=E5=8C=85=E5=90=AB=E5=B7=A5= =E7=A0=94=E9=99=A2=E6=A9=9F=E5=AF=86=E8=B3=87=E8=A8=8A=EF=BC=8C=E9=9D=9E=E6= =8C=87=E5=AE=9A=E4=B9=8B=E6=94=B6=E4=BB=B6=E8=80=85=EF=BC=8C=E8=AB=8B=E5=8B= =BF=E4=BD=BF=E7=94=A8=E6=88=96=E6=8F=AD=E9=9C=B2=E6=9C=AC=E4=BF=A1=E4=BB=B6= =E5=85=A7=E5=AE=B9=EF=BC=8C=E4=B8=A6=E8=AB=8B=E9=8A=B7=E6=AF=80=E6=AD=A4=E4= =BF=A1=E4=BB=B6=E3=80=82 > This email may contain confidential information. Please do not use or dis= close it in any way and delete it if you are not the intended recipient. > > > From petithug@acm.org Mon Jan 10 14:44:50 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D97128C106 for ; Mon, 10 Jan 2011 14:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.801 X-Spam-Level: X-Spam-Status: No, score=-101.801 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeMkJ4vtV+aD for ; Mon, 10 Jan 2011 14:44:49 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id EACCA3A67ED for ; Mon, 10 Jan 2011 14:42:00 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id EF97511BC401E; Mon, 10 Jan 2011 22:44:15 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 3D79111BC401C; Mon, 10 Jan 2011 22:44:15 +0000 (UTC) Message-ID: <4D2B8BBE.3050303@acm.org> Date: Mon, 10 Jan 2011 14:44:14 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Bruce Lowekamp References: <4CEAC54A.2030503@acm.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (2) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jan 2011 22:44:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for your responses. see below for more comments. On 01/07/2011 02:24 PM, Bruce Lowekamp wrote: > inline > > On Mon, Nov 22, 2010 at 2:32 PM, Marc Petit-Huguenin wrote: > More questions, comments and nits: > [...] > > - A.10. It seems that this version of RELOAD lacks the support of virtual > servers (see draft-harjula-p2psip-loadbalancing-survey), more precisely a way to > share connections between two virtual servers on the same physical server (see > Frank Dabek, M. Frans Kaashoek, David Karger, Robert Morris, Ion Stoica, > Wide-area cooperative storage with CFS: "Use of virtual servers could > potentially increase the number of hops in a Chord lookup. CFS avoids this > expense by allowing virtual servers on the same physical server to examine each > others' tables: the fact that these virtual servers can take short-cuts through > each others' routing table exactly compensates for the increases number of > servers."). Because the certificates contains a list of Node-IDs, it is not > possible to know on a hop by hop basis what are the source and destination > NodeIds of a specific message. Section 3 of > draft-rosenberg-dispatch-vipr-reload-usage seems to acknowledge that by adding a > PeerID Shim to exchange the source and destination peerIDs (aka Node-IDs). > > Because of this, it is probably a good idea to add in p2psip-base the > possibility to know the source Node-ID and destination Node-ID of a message. > One way to do that would have be to have the sender of a message add its own > Node-ID in the via_list, and the Node-ID of the destination in the > destination_list before sending a message (similar to what SIP is doing), but I > guess that it is too late for such a modification. > > >> I totally agree that vnodes should share routing state. But it's not >> clear to me what benefit would be obtained by making that sort of a >> protocol change. > >> * on request routing, a message should normally have exactly one >> destination node-id. The only reason to have more would be that the >> request sender has some particular reason to want to source-route the >> request. >> * on response sending, with recursive response you simply want to >> reverse the initial request routing. If there was an advantage to >> "short-cutting" between v-nodes, it would have been done on the >> request routing. If you're not doing recursive response routing, >> then this case is the same as request routing. Let's forget for now the solution I proposed. Do you agree that Section 3 of draft-rosenberg-dispatch-vipr-reload-usage exposes a problem that would be worth been solved in p2psip-base? Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk0ri7wACgkQ9RoMZyVa61edGQCggzZ04xzB0pc2jQZrDTeAFQdP 1bYAniaPm1eH+YU3FHSv9txq7DV3IEwI =oZBv -----END PGP SIGNATURE----- From petithug@acm.org Mon Jan 10 16:15:17 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2301D3A6819 for ; Mon, 10 Jan 2011 16:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.839 X-Spam-Level: X-Spam-Status: No, score=-101.839 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glZ90AVR1h74 for ; Mon, 10 Jan 2011 16:15:16 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 344203A6837 for ; Mon, 10 Jan 2011 16:15:16 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 514A7FBC413A; Tue, 11 Jan 2011 00:17:31 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id D0D98FBC4130 for ; Tue, 11 Jan 2011 00:17:30 +0000 (UTC) Message-ID: <4D2BA199.5080105@acm.org> Date: Mon, 10 Jan 2011 16:17:29 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] draft-ietf-p2psip-base-12 (4) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 11 Jan 2011 00:15:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 More comments: A.30. Section 5.5.4.1 "opaque config_data<0..2^24-1>" If a configuration document contains multiple configuration elements (and I guess multiple matching signature elements), then should not config_data been in fact structured the same way than kinds?, i.e. an XML fragment containing only the configuration element and the signature element for this overlay, extracted from the multiple configuration elements document? See also A.31 below. A.31. Section 1.1 'The file can contain multiple "configuration" elements..." This contradicts the RELAX NG grammar in section 10.1.1. In addition, should not configuration elements be structured as kind elements are, i.e. something like this: ... ... ... ... In this case, config_data would contain a XML configuration-block production (see A.31 above). A.32. Section 10.1 "root-cert: [...] there can be more than one root-cert element" This contradicts the RELAX NG grammar in section 10.1.1. A.33. Section 10.1 "enrollment-server: [...] there can be more than one enrollment-server element" This contradicts the RELAX NG grammar in section 10.1.1. A.34. Section 10.1 'multicast-bootstrap: [...] it has an attribute called "address" [...] and an attribute called "port"' This contradicts the RELAX NG grammar in section 10.1.1 (hostPort). A.35. Section 10.1.1 "parameter &= element required-kinds { kind-block* }" Because the text in section 10.1. says that "[i]nside each overlay element, the required-kinds element can also occur", I think it should be this instead: parameter &= element required-kinds { kind-block+ }? - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk0roZgACgkQ9RoMZyVa61fN/wCcCZk9KcSDiVZz2u4E+KVfl2Es w3oAoIYvjgqZv3Lwwt73VSRA03uSlFrg =/1lC -----END PGP SIGNATURE----- From Internet-Drafts@ietf.org Tue Jan 11 01:15:03 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A07028C11B; Tue, 11 Jan 2011 01:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPhBKQObxYTn; Tue, 11 Jan 2011 01:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D893228C104; Tue, 11 Jan 2011 01:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110111091501.29930.54340.idtracker@localhost> Date: Tue, 11 Jan 2011 01:15:01 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-diagnostics-05.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 11 Jan 2011 09:15:03 -0000 --NextPart 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 : P2PSIP Overlay Diagnostics Author(s) : H. Song, et al. Filename : draft-ietf-p2psip-diagnostics-05.txt Pages : 29 Date : 2011-01-11 This document describes mechanisms for P2PSIP diagnostics. It defines extensions to the RELOAD P2PSIP base protocol RELOAD [I-D.ietf-p2psip-base] 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 a P2PSIP overlay networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-diagnostics-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-p2psip-diagnostics-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-11011436.I-D@ietf.org> --NextPart-- From ekr@rtfm.com Thu Jan 13 09:30:57 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 412EF28C10E for ; Thu, 13 Jan 2011 09:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.678 X-Spam-Level: X-Spam-Status: No, score=-102.678 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+raOH-Y5NQj for ; Thu, 13 Jan 2011 09:30:56 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 2F92028C0F7 for ; Thu, 13 Jan 2011 09:30:56 -0800 (PST) Received: by yxt33 with SMTP id 33so880204yxt.31 for ; Thu, 13 Jan 2011 09:33:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.26.24 with SMTP id d24mr3496657agj.160.1294939998724; Thu, 13 Jan 2011 09:33:18 -0800 (PST) Received: by 10.90.154.19 with HTTP; Thu, 13 Jan 2011 09:33:18 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Jan 2011 17:33:18 +0000 Message-ID: From: Eric Rescorla To: li.lichun1@zte.com.cn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Typo in base draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 13 Jan 2011 17:30:57 -0000 Sorry, so what's the typo here. I'm sure I'm just missing it.... -Ekr On Fri, Dec 17, 2010 at 6:54 AM, wrote: > > 5.4.2.2 > "LeaveReq contains only the Node-ID of the leaving peer. =A0Overlay > =A0 algorithms MAY specify other data to appear in this request. > =A0 Receivers of the JoinReq MUST verify that the joining_peer_id field > =A0 matches the Node-ID used to sign the message and if not MUST reject > =A0 the message with an Error_Forbidden error." > > BR > Lichun > > -------------------------------------------------------- > ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained=A0= in=A0this=A0mail=A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organizat= ion.=A0This=A0mail=A0communication=A0is=A0confidential.=A0Recipients=A0name= d=A0above=A0are=A0obligated=A0to=A0maintain=A0secrecy=A0and=A0are=A0not=A0p= ermitted=A0to=A0disclose=A0the=A0contents=A0of=A0this=A0communication=A0to= =A0others. > This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0confid= ential=A0and=A0intended=A0solely=A0for=A0the=A0use=A0of=A0the=A0individual= =A0or=A0entity=A0to=A0whom=A0they=A0are=A0addressed.=A0If=A0you=A0have=A0re= ceived=A0this=A0email=A0in=A0error=A0please=A0notify=A0the=A0originator=A0o= f=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0message=A0are=A0= those=A0of=A0the=A0individual=A0sender. > This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0by= =A0ZTE=A0Anti-Spam=A0system. > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From li.lichun1@zte.com.cn Thu Jan 13 16:39:08 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE0C428C0DC for ; Thu, 13 Jan 2011 16:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.686 X-Spam-Level: X-Spam-Status: No, score=-98.686 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgPwwdTO5Quu for ; Thu, 13 Jan 2011 16:39:07 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 224A828B23E for ; Thu, 13 Jan 2011 16:39:06 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35102075036648; Fri, 14 Jan 2011 08:39:34 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 81846.2296983992; Fri, 14 Jan 2011 08:34:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p0E0fKvQ040827; Fri, 14 Jan 2011 08:41:20 +0800 (GMT-8) (envelope-from li.lichun1@zte.com.cn) In-Reply-To: To: Eric Rescorla MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: li.lichun1@zte.com.cn Date: Fri, 14 Jan 2011 08:41:07 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-14 08:41:20, Serialize complete at 2011-01-14 08:41:20 Content-Type: multipart/alternative; boundary="=_alternative 0004157048257818_=" X-MAIL: mse01.zte.com.cn p0E0fKvQ040827 Cc: P2PSIP WG Subject: Re: [P2PSIP] Typo in base draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 14 Jan 2011 00:39:08 -0000 This is a multipart message in MIME format. --=_alternative 0004157048257818_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSB0aGluayAiSm9pblJlcSIgYW5kICJqb2luaW5nX3BlZXJfaWQiIHNob3VsZCBiZSAiTGVhdmVS ZXEiIGFuZCAiDQpsZWF2aW5nX3BlZXJfaWQiIGhlcmUuDQoNCg0KDQoNCkVyaWMgUmVzY29ybGEg PGVrckBydGZtLmNvbT4gDQoyMDExLTAxLTE0IDAxOjMzDQoNCsrVvP7Iyw0KbGkubGljaHVuMUB6 dGUuY29tLmNuDQqzrcvNDQpQMlBTSVAgV0cgPHAycHNpcEBpZXRmLm9yZz4NCtb3zOINClJlOiBb UDJQU0lQXSBUeXBvIGluIGJhc2UgZHJhZnQNCg0KDQoNCg0KDQoNClNvcnJ5LCBzbyB3aGF0J3Mg dGhlIHR5cG8gaGVyZS4gSSdtIHN1cmUgSSdtIGp1c3QgbWlzc2luZyBpdC4uLi4NCg0KLUVrcg0K DQoNCk9uIEZyaSwgRGVjIDE3LCAyMDEwIGF0IDY6NTQgQU0sICA8bGkubGljaHVuMUB6dGUuY29t LmNuPiB3cm90ZToNCj4NCj4gNS40LjIuMg0KPiAiTGVhdmVSZXEgY29udGFpbnMgb25seSB0aGUg Tm9kZS1JRCBvZiB0aGUgbGVhdmluZyBwZWVyLiAgT3ZlcmxheQ0KPiAgIGFsZ29yaXRobXMgTUFZ IHNwZWNpZnkgb3RoZXIgZGF0YSB0byBhcHBlYXIgaW4gdGhpcyByZXF1ZXN0Lg0KPiAgIFJlY2Vp dmVycyBvZiB0aGUgSm9pblJlcSBNVVNUIHZlcmlmeSB0aGF0IHRoZSBqb2luaW5nX3BlZXJfaWQg ZmllbGQNCj4gICBtYXRjaGVzIHRoZSBOb2RlLUlEIHVzZWQgdG8gc2lnbiB0aGUgbWVzc2FnZSBh bmQgaWYgbm90IE1VU1QgcmVqZWN0DQo+ICAgdGhlIG1lc3NhZ2Ugd2l0aCBhbiBFcnJvcl9Gb3Ji aWRkZW4gZXJyb3IuIg0KPg0KPiBCUg0KPiBMaWNodW4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQpaVEUgSW5mb3JtYXRp b24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFp bCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBt YWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3Zl IGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQg dG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMu DQo+IA0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNv bmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9m IHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhv c2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KPiANClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBz Y2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0KPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBQMlBT SVAgbWFpbGluZyBsaXN0DQo+IFAyUFNJUEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0KPg0KPg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRp b24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFp bCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBt YWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3Zl IGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQg dG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMu DQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlk ZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg b3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhl IG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBv ZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBm b3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0004157048257818_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgdGhpbmsgJnF1b3Q7Sm9pblJl cSZxdW90OyBhbmQgJnF1b3Q7PC9mb250Pjx0dD48Zm9udCBzaXplPTM+am9pbmluZ19wZWVyX2lk PC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90Ow0Kc2hvdWxk IGJlICZxdW90O0xlYXZlUmVxJnF1b3Q7IGFuZCAmcXVvdDs8L2ZvbnQ+PHR0Pjxmb250IHNpemU9 Mz5sZWF2aW5nX3BlZXJfaWQ8L2ZvbnQ+PC90dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+JnF1b3Q7DQpoZXJlLjxicj4NCjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj48Yj5FcmljIFJlc2NvcmxhICZsdDtla3JAcnRmbS5jb20mZ3Q7PC9i Pg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDEtMTQg MDE6MzM8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+bGkubGljaHVuMUB6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5QMlBTSVAgV0cg Jmx0O3AycHNpcEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+ PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbUDJQU0lQXSBU eXBvIGluIGJhc2UgZHJhZnQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPlNvcnJ5LCBzbyB3aGF0J3MgdGhlIHR5cG8gaGVyZS4gSSdtIHN1 cmUgSSdtIGp1c3QNCm1pc3NpbmcgaXQuLi4uPGJyPg0KPGJyPg0KLUVrcjxicj4NCjxicj4NCjxi cj4NCk9uIEZyaSwgRGVjIDE3LCAyMDEwIGF0IDY6NTQgQU0sICZuYnNwOyZsdDtsaS5saWNodW4x QHp0ZS5jb20uY24mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IDUuNC4yLjI8YnI+DQom Z3Q7ICZxdW90O0xlYXZlUmVxIGNvbnRhaW5zIG9ubHkgdGhlIE5vZGUtSUQgb2YgdGhlIGxlYXZp bmcgcGVlci4gJm5ic3A7T3ZlcmxheTxicj4NCiZndDsgJm5ic3A7IGFsZ29yaXRobXMgTUFZIHNw ZWNpZnkgb3RoZXIgZGF0YSB0byBhcHBlYXIgaW4gdGhpcyByZXF1ZXN0Ljxicj4NCiZndDsgJm5i c3A7IFJlY2VpdmVycyBvZiB0aGUgSm9pblJlcSBNVVNUIHZlcmlmeSB0aGF0IHRoZSBqb2luaW5n X3BlZXJfaWQNCmZpZWxkPGJyPg0KJmd0OyAmbmJzcDsgbWF0Y2hlcyB0aGUgTm9kZS1JRCB1c2Vk IHRvIHNpZ24gdGhlIG1lc3NhZ2UgYW5kIGlmIG5vdCBNVVNUDQpyZWplY3Q8YnI+DQomZ3Q7ICZu YnNwOyB0aGUgbWVzc2FnZSB3aXRoIGFuIEVycm9yX0ZvcmJpZGRlbiBlcnJvci4mcXVvdDs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBCUjxicj4NCiZndDsgTGljaHVuPGJyPg0KJmd0Ozxicj4NCiZndDsg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 YnI+DQomZ3Q7IFpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6 Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3Ro aXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5i c3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21h aWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVj aXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJz cDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25v dCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250 ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290 aGVycy48YnI+DQomZ3Q7IFRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2Zp bGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25m aWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNw O3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5i c3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJl c3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMm bmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJz cDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNw O0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVz c2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFs Jm5ic3A7c2VuZGVyLjxicj4NCiZndDsgVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDti ZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFt Jm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uPGJyPg0KJmd0Ozxi cj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7IFAyUFNJUCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IFAyUFNJUEBpZXRmLm9yZzxi cj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXA8YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtU aGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNw O21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNw O2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRz Jm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5i c3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7 cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5i c3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0K VGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21p dHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2Fu ZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0 byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5i c3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7 aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdp bmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3Mm bmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5i c3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpU aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9y Jm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0Fu dGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0004157048257818_=-- From petithug@acm.org Sun Jan 16 07:16:19 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7287C3A6D21 for ; Sun, 16 Jan 2011 07:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.996 X-Spam-Level: X-Spam-Status: No, score=-101.996 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABTzRviHtexh for ; Sun, 16 Jan 2011 07:16:18 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 9B0293A6BD7 for ; Sun, 16 Jan 2011 07:16:18 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id EABB011BC4022; Sun, 16 Jan 2011 15:18:49 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 416DE11BC4020 for ; Sun, 16 Jan 2011 15:18:49 +0000 (UTC) Message-ID: <4D330C58.2020107@acm.org> Date: Sun, 16 Jan 2011 07:18:48 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] RELOAD Interop tests X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 16 Jan 2011 15:16:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would be interested in doing interoperability testing with other RELOAD implementations (-12 and higher) at IETF 80 (we can meet in the terminal room, like we did for TURN few years ago). I am also interested to hear if there will be RELOAD implementations in SIPit 28, so I can plan my travels accordingly. We (Stonyfish) will also release soon a new version of the Wireshark dissector for RELOAD, and we will also release a plugin for Linux 32 and 64 bit at the same time, so it will be easier to use. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk0zDFYACgkQ9RoMZyVa61dwKgCghXJLb1kAR+GJLHnZrasNBNer zdAAn0y7ScrgxZpuMmj8MdBCrmNrCio/ =+RWV -----END PGP SIGNATURE----- From Jan.Seedorf@neclab.eu Tue Jan 18 02:28:51 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1D963A6FBE; Tue, 18 Jan 2011 02:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.056 X-Spam-Level: X-Spam-Status: No, score=-101.056 tagged_above=-999 required=5 tests=[AWL=-1.221, BAYES_40=-0.185, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRLMP12JBzmv; Tue, 18 Jan 2011 02:28:50 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id A27213A6FB8; Tue, 18 Jan 2011 02:28:49 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 08619280001AA; Tue, 18 Jan 2011 11:32:34 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl6g+p7O7lTV; Tue, 18 Jan 2011 11:32:33 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id D773D2800017C; Tue, 18 Jan 2011 11:32:08 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.59]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Tue, 18 Jan 2011 11:31:00 +0100 From: Jan Seedorf To: "p2prg@irtf.org" , P2PSIP WG , "ppsp@ietf.org" , 'alto' , "decade@ietf.org" Thread-Topic: Live streaming of NAPA-WINE P2P-TV workshop with P2P software Thread-Index: Acu2+sxB9abvF+YITYupvh0rusVDHQ== Date: Tue, 18 Jan 2011 10:30:59 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE7E96AF@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.226] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [P2PSIP] Live streaming of NAPA-WINE P2P-TV workshop with P2P software X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2011 10:28:51 -0000 P2P folks at IETF, To help people interested in the P2P-TV workshop we are hosting, the NAPA-WINE project's final workshop will be *broadcasted live* with the P2P Live Streaming Software developed by the NAPA-WINE project. The workshop opens on Thursday 20th January at 2.30PM CET and closes on Friday 21th January afternoon at 6.00PM CET. Recordings of the workshop will be made available from the project web site few days after the event too. For people interested in following the workshop/talks live via P2P video stream, we have prepared a page with Quick-Start instructions on how to download, install, and use the software to follow the event live. If you are interested, please go to http://www.napa-wine.eu/cgi-bin/twiki/view/Public/NapaWineWorkshopLive If you have any questions regarding the use of the software or following the final workshop live with it, please use the mailing list (napalive@tlc.= polito.it). A demo activity of the software is scheduled at 5.30PM (and yes! you will be part of the demo if you join the channel!)=20 *Workshop Program*=20 The final NAPA-WINE workshop is intended as an informal forum for lively discussions on current and future trends in peer-to-peer live streaming. Th= e program comprises four talks presenting the main NAPA-WINE achievements (an= d a demo of NAPA-WINE's network-aware P2P live streaming system) as well as nin= e talks from external highly qualified researchers from both academia and industry, providing a broad and articulated perspective on the main challen= ges and solutions on the topic. There will be external presentations provided b= y (see http://www.napa-wine.eu/workshop/program.html for agenda details): - Presentations from other on-going European projects on P2P-TV/CDN: * Future Media Networks (FMN) cluster and ENVISION (David Griffin, UCL, G= B) * COAST/SEA (Emanuele Quacchio, ST Microelectronics, IT) * P2P-NEXT (Raul Jimenez, KTH, SE) - Presentations from the industrial world (the operator/content provider vi= sion): * Nikolaos Laoutaris, Telefonica Research, ES * Enrico Marocco, Chair of IETF ALTO, Telecom Italia, IT - Presentations from academia (technical challenges) * Ernst Biersack, Eurecom, FR * Phuoc Tran-Gia, Tobias Hossfeld, University of Wuerzburg, DE * Yong Liu, Polytechnic Institute of NYU, US * Victoria Fodor, Gyorgy Dan, KTH, SE For further workshop program details, please see http://www.napa-wine.eu/wo= rkshop/ - Jan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jan Seedorf Senior Researcher NEC Europe Ltd., NEC Laboratories Europe, Network Division=A0=A0=A0=A0=A0 Kurfuerstenanlage 36, D-69115 Heidelberg Tel.=A0=A0=A0=A0 +49 (0)6221 4342-221 Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 e-mail:=A0 jan.seedorf@neclab.eu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014=20 From ekr@skype.net Tue Jan 18 07:32:53 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4840A28C15A for ; Tue, 18 Jan 2011 07:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLkt2e2qqzwX for ; Tue, 18 Jan 2011 07:32:51 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 563AD28C102 for ; Tue, 18 Jan 2011 07:32:51 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 3DD4C1700; Tue, 18 Jan 2011 16:35:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mx; bh=nm I4jkCfTMbdFuvQ3GmHfbp4/4s=; b=Ar/VhgA/fcgN1LFXPfQluEIPcICbbmu2EN sfowycS3wsdVPEmRURiz9dxNejMhlLC/m5pLQSpB2snqB1ML++qlI5NXw5GsrKlh La5cOWZm8Ask6A7aHR7PcO5Owry8V38eacvReWaJNCdgaPQR11oH7cM68483RXI5 l12refgOM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=mx; b=cEqTQGcl+6j3gYLG3YyaTL Qybc1cbEIsEUEqRuY/K6T2X24JFNc0h1CqPw530wurwhPtxaE7Mug7nhXPZnGbC6 13oMLL4Owf5DQ9uAioPClCN+N/lz9m1iE5dEhRQIBZGg7logoNlOMalEyFAODq4L uTHuqCbHKTjRcXtFimoZs= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 3C54616FC; Tue, 18 Jan 2011 16:35:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 10B023507CA7; Tue, 18 Jan 2011 16:35:27 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvCqzYPS4Iwk; Tue, 18 Jan 2011 16:35:25 +0100 (CET) Received: from [192.168.8.196] (161.26.235.80.sta.estpak.ee [80.235.26.161]) by zimbra.skype.net (Postfix) with ESMTPSA id 6F3D23506EBA; Tue, 18 Jan 2011 16:35:25 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=utf-8 From: Eric Rescorla In-Reply-To: <4CE5B4EC.3050904@idssoftware.com> Date: Tue, 18 Jan 2011 04:38:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <03AD3FF9-10AA-4F81-82DF-BF554CEC537E@skype.net> References: <4CE5B4EC.3050904@idssoftware.com> To: Michael Chen X-Mailer: Apple Mail (2.1082) Cc: P2PSIP WG Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2011 15:32:53 -0000 Done. -Ekr On Nov 18, 2010, at 3:21 PM, Michael Chen wrote: > Bruce and Eric, >=20 > I am submitting some proposed changes to the base-12 draft based on > the Attach Race Condition discussion as follows (leading "-" is > deletion, "+" is addition): >=20 > 5.4.2.3. Update > ... > the state change. In general, peers send Update messages to all > their adjacencies whenever they detect a topology shift. > + > + When a peer receives an Attach request with the send_update flag > + set to "true" (see 5.5.1.1), it MUST send an Update message back > + to the sender of the Attach request after the completion of the > + corresponding ICE check and TLS connection. Note that the sender > + of a such Attach request may not have joint the overlay yet. >=20 >=20 > 5.5.1.2. Response Definition > - > - If a peer receives an Attach request, it MUST process the request = and > - SHOULD generate its own response with a AttachReqAns. A peer which > - is overloaded or detects some other kind of error may of course > - generate an error instead of an AttachReqAns. It should then begin > - ICE checks. When a peer receives an Attach response, it SHOULD = parse > - the response and begin its own ICE checks. > + > + If a peer receives an Attach request, it MUST determine how to = process > + the request as follows: > + > + o If it has not initiated an Attach request to the originating = peer > + of this Attach request, it MUST process this request and SHOULD > + generate its own response with an AttachReqAns. It should then > + begin ICE check. > + > + o If it has already sent an Attach request to and received the > + response from the originating peer of this Attach request, and > + as a as a result, an ICE check and TLS connection is in = progress, > + then it SHOULD generate an error instead of an AttachReqAns. > + [[I suggest adding a new error number for this condition.]] > + > + o If it has already sent an Attach request to but not yet received > + the response from the originating peer of this Attach request, > + it SHOULD apply the tie-breaker heuristic to determine how to > + handle this Attach request and the incomplete Attach request it > + has sent out. > + > + The tie-breaker heuristic is to compare the Node-IDs of both > + peers as unsigned integers, and > + > + * If the peer's own Node-ID is smaller, it MUST cancel its > + own incomplete Attach request. It MUST then process this > + Attach request, generate an AttachReqAns response, and > + proceed with the corresponding ICE check. > + > + * If the peer's own Node-ID is larger, it MUST generate an > + error to this Attach request, then proceed to wait for > + and complete the Attach and the corresponding ICE check > + it has originated. > + > + o If the peer is overloaded or detects some other kind of error, = it > + may generate an error instead of an AttachReqAns. > + > + When a peer receives an Attach response, it SHOULD parse > + the response and begin its own ICE checks. >=20 >=20 > Feel free to change and discuss further. >=20 > Thanks >=20 > --Michael >=20 >=20 > On 11/16/2010 11:53 AM, David A. Bryan wrote: >> At the meeting, the following issues were presented related to the >> RELOAD base draft. As planned, I have cut and pasted the proposals >> from Ekr's slides here to take the discussion to list. >>=20 >> Except as noted, there was no discussion on the issue in the meeting, >> and unless there is list discussion, the proposals mentioned for the >> open issues without discussion will be deemed as consensus (for the >> TODOs noted, we assume they will be completed). >>=20 >> As the draft is very close to going to the editor, if you have = issues, >> speak up quickly! >>=20 >> David (as chair) >>=20 >>=20 >> SLIDES/ISSUES WITH DISCUSSION/OPEN ISSUES RAISED FOR MAILING LIS > ... >> Join race condition I (Michael Chen) >> =E2=80=A2 =C2=A79.4: =E2=80=93 Step 7: routing table from AP =E2=86=92 = JP =E2=80=93 Step 8: routing table >> from AP =E2=86=92 NP >> =E2=80=A2 In some cases (e.g., Chord predecessors) this may cause = simultaneous >> connects between JP and it=E2=80=99s new neighbors >> Proposed Resolution: Tiebreaker when multiple connections are >> established between a pair of nodes. Terminate the connection >> originating from the smaller Node-Id seems like a natural choice. >> ***NOTE: There was significant list discussion ongoing at the time >> this slide was presented. Need to reach consensus on list for this >> item. > ... >> ______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From ekr@skype.net Tue Jan 18 07:33:09 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14923A7028 for ; Tue, 18 Jan 2011 07:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zueiT01MMgOk for ; Tue, 18 Jan 2011 07:33:08 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id CA4FE3A7005 for ; Tue, 18 Jan 2011 07:33:07 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id D0ACA1707; Tue, 18 Jan 2011 16:35:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=mx; bh=HtvkUGYOKzPAp2E/H1N20zwZ9p4=; b=FWzDbzg oGyPBPUGwhLZOrS9e8bsbgD/SuB+/CZ6qUtjtU+IGMYoxLZgfEBMFrG80ZkkvKjj uL795llBeU+Obtq1aMtUa/dsQeJQcMa8th9UkIdjq1CbRYnRgFOrPsvL78ZYfGOU 9MDQWVmZOkb7UNlmsnX9xf2JcokA25DPp1eA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to; q=dns; s=mx; b=iqQb5l7uG+KIH0SXNXteQ4DyaBOe1Pne3MLYYBKfnj1ZCD5D cKfAUNxXQAt+UzscRzqsxmK6zzNEqIaUs4yqNpP69zKNSKeekOScsKicmXC3QMo8 a1loh/m1DMivma8BpJDn2+byUJApWrmrF7By91CH5H0rtXhVf73APupnuV8= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id CF24616FC; Tue, 18 Jan 2011 16:35:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 74FD43507CA5; Tue, 18 Jan 2011 16:35:44 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMddLNhSCH8t; Tue, 18 Jan 2011 16:35:42 +0100 (CET) Received: from [192.168.8.196] (161.26.235.80.sta.estpak.ee [80.235.26.161]) by zimbra.skype.net (Postfix) with ESMTPSA id 8B25B3506F43; Tue, 18 Jan 2011 16:35:42 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-4--777903026 From: Eric Rescorla In-Reply-To: <4CFD5FCD.7060205@acm.org> Date: Tue, 18 Jan 2011 05:21:16 -0800 Message-Id: <29353BE9-83FE-40C3-817F-6649AE09DF0C@skype.net> References: <4CFD5FCD.7060205@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1082) Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (3) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2011 15:33:09 -0000 --Apple-Mail-4--777903026 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 6, 2010, at 2:12 PM, Marc Petit-Huguenin wrote: > bytes, or 2032 bits. >=20 > A.14. Section 5.3.2 "uint32 length;" >=20 > I can assume that this length covers the Header, MessageContents and = Signature, > but I would guess that this was useful when Message was sent without > FramingHeader over TCP (same than for the relo_token used to = disambiguate STUN > packets). Now that this is useless, can't this length been only = Header and > MessageContents, so it is possible to find the boundary between = MessageContents > and Signature without having to parse MessageContents at all? >=20 I think it's a mistake to assume we'll never want messages to be = self-contained/unframed. Is there a real advantage to this breaking change? > A.15. Section 5.3.4 "HashAlgorithm hash_alg;" >=20 > What are the algorithms that should be supported? > Is the hash only used to identify the certificate in = SecurityBlock.certificates? > Also the text says that "[t]he certificate_hash contains the hash of = the > certificate object." Are we talking about the hash of the DER encoded > certificate, as stored in GenericCertificate.certificate? Yes. Clarified. > A.16. Section 5.5.1.1. "IceCandidate candidates<0..2^16-1>;" >=20 > Because there must be at least one candidate, should this be: >=20 > IceCandidate candidates<1..2^16-1>; It's actually quite a but longer than that, because IceCandidate is = fairly long. However, I think it's harmless to leave it as-is and actually putting=20 12..2^16-1 or whatever is just confusing. > A.17. "config_data (type=3D=3Dconfig)" >=20 > The definition of this field is "[t]he contents of the configuration = document", > but 10.1 says that a file "...can contain multiple 'configuration' = elements...". > So should not this field be in fact defined as "One XML configuration > production. This MUST be encoded with UTF-8 and assume a default = namespace of > ...", like for the kinds value? And in this case what about the = signature > element in the XML fragment? >=20 Hmm.... I'm going to defer to Cullen on this one.. He did all the XML :) > A.18. Section 5.6.2 "...not all aspects of the header apply to both = types of > transports." >=20 > It would be great if this could be explained a little bit more. For = example I > assume that on a reliable link, the receiver still need to send the = Ack for each > frame received (to calculate the RTO), but what about the content of = the > ack_sequence and received fields? >=20 In retrospect, I think this sentence is stupid. Removed. > A.19. Section 5.6.3.1.1, last paragraph >=20 > This paragraph described a lockstep algorithm, but if it is the case = then there > is no need for the received field, as we would always know that the = previous > messages have been received. >=20 Sorry, I'm not sure I understand the question. The received field is = there to=20 permit the sender to unilaterally use more sophisticated algorithms. > A.20. Section 5.7, "If the message is not fragmented, then both the = first and > last fragment are set to 1..." >=20 > If the first fragment bit is set to 1 when the message is fragmented = and is also > set to one when the message is not fragmented, then it is always set = to 1, so > what is the point of having it in the first place? Good point. OTOH, does this do any damage? If not, I'm tempted to write = it down as a misfeature and leave as-is. > A.21. Section 10.1. "..." >=20 > Why do we need to repeat the data-model and access-control that were = already in > the IANA registry? Or is it a way to override the IANA definitions as = the > example would suggest? (as the registration for SIP-REGISTRATION is = using > DICTIONARY and USER-NODE-MATCH). >=20 No, it's just to preserve uniform syntax for IANA-defined and = user-defined kinds. > A.22. Section 10.1. "sequence: a monotonically increasing sequence = number > between 1 and 2^32" >=20 > According to section 5.3.2 and 5.3.2.1, it should be between 0 and = 2^16-2 (65534). >=20 Fixed. > A.23. Section 10.1. "root-cert This element..." >=20 > I guess that the encoding to use is base64, but it is said nowhere. >=20 Yes, the text here says "PEM" but that's stupid. Changed to = base64--unless someone objects. > A.24. Section 10.1.1. "| attribute id { xsd:int })," >=20 > Does not match 13.6, that is saying that this is an unsigned integer. = Should > probably use xsd:unsignedInt instead. >=20 > Note that there is other places in the RELAX NG document where the = type can be > improved (initial-ttl, etc...) I'll leave this to Cullen. > A.25. Section 10.1.1. 'access-control-type |=3D = "user-match-with-anon-create"' >=20 > This control type is never defined in the document. >=20 Removed. > A.26. Section 10.1.1. 'kind-names |=3D "sip-registration"' >=20 > the sip-registration kind is not defined in this document. OTOH, > certificate-by-node and certificate-by-name are defined, but not = listed here. A cullen problem. > A.27. Section 10.1.1. 'self-signed-digest-type |=3D "sha1"' >=20 > Section 10.1. says that '[v]alid values for this parameter are "SHA-1" = and > "SHA-256"'. Adjusted the text. > A.28. Section 10.1.1 last paragraph "such an XML configuration file = sent over > email." >=20 > Because the signatures on the XML document are done on exact byte = string and > because emails servers are known to mess with end of lines, we will = see > configuration documents that cannot be verified after been sent by = email (what > was wrong with using XML-sig anyway?). >=20 It's ridiculously overcomplicated for this application (and arguably for = any application). > A.29. Section 13.15 "destination: a hex-encoded Destination List = object" >=20 > A Destination List object is never formally defined in the whole = document, so is > it just Destination objects packed together, or is it in fact a = "Destination > destination_list<0..2^16-1>" ? In other words, does it start with a = length field? Added something. -Ekr --Apple-Mail-4--777903026 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
bytes, or 2032 = bits.

A.14. Section 5.3.2  "uint32 length;"

I can = assume that this length covers the Header, MessageContents and = Signature,
but I would guess that this was useful when Message was = sent without
FramingHeader over TCP (same than for the relo_token = used to disambiguate STUN
packets).  Now that this is useless, = can't this length been only Header and
MessageContents, so it is = possible to find the boundary between MessageContents
and Signature = without having to parse MessageContents at = all?


I think it's a mistake to = assume we'll never want messages to be = self-contained/unframed.
Is there a real advantage to this =  breaking = change?


A.15. Section 5.3.4 "HashAlgorithm = hash_alg;"

What are the algorithms that should be = supported?
Is the hash only used to identify the certificate in = SecurityBlock.certificates?
Also the text says that "[t]he = certificate_hash contains the hash of the
certificate object." =  Are we talking about the hash of the DER encoded
certificate, = as stored in = GenericCertificate.certificate?

Yes. = Clarified.


A.16. Section 5.5.1.1. "IceCandidate = candidates<0..2^16-1>;"

Because there must be at least one = candidate, should this be:

IceCandidate = candidates<1..2^16-1>;

It's = actually quite a but longer than that, because IceCandidate is fairly = long.
However, I think it's harmless to leave it as-is and = actually putting 
12..2^16-1 or whatever is just = confusing.


A.17. "config_data (type=3D=3Dconfig)"

The = definition of this field is "[t]he contents of the configuration = document",
but 10.1 says that a file "...can contain multiple = 'configuration' elements...".
So should not this field be in fact = defined as "One XML configuration
production.  This MUST be = encoded with UTF-8 and assume a default namespace of
...", like for = the kinds value?  And in this case what about the = signature
element in the XML = fragment?


Hmm.... I'm going to = defer to Cullen on this one.. He did all the XML = :)


A.18. = Section 5.6.2 "...not all aspects of the header apply to both types = of
transports."

It would be great if this could be explained a = little bit more.  For example I
assume that on a reliable link, = the receiver still need to send the Ack for each
frame received (to = calculate the RTO), but what about the content of the
ack_sequence = and received fields?


In = retrospect, I think this sentence is stupid. = Removed.


A.19.= Section 5.6.3.1.1, last paragraph

This paragraph described a = lockstep algorithm, but if it is the case then there
is no need for = the received field, as we would always know that the = previous
messages have been = received.


Sorry, I'm not sure I = understand the question. The received field is there = to 
permit the sender to unilaterally use more = sophisticated algorithms.


A.20. Section 5.7, "If the message is not fragmented, = then both the first and
last fragment are set to 1..."

If the = first fragment bit is set to 1 when the message is fragmented and is = also
set to one when the message is not fragmented, then it is always = set to 1, so
what is the point of having it in the first place?


Good point. OTOH, does this do any damage? If not, I'm = tempted to write it
down as a misfeature and leave = as-is.



A.21. Section 10.1. "<kind = name=3D'sip-registration'><data-model>..."

Why do we = need to repeat the data-model and access-control that were already = in
the IANA registry?  Or is it a way to override the IANA = definitions as the
example would suggest? (as the registration for = SIP-REGISTRATION is using
DICTIONARY and = USER-NODE-MATCH).


No, it's just = to preserve uniform syntax for IANA-defined and user-defined = kinds.



A.22. Section 10.1. "sequence: a monotonically = increasing sequence number
between 1 and 2^32"

According to = section 5.3.2 and 5.3.2.1, it should be between 0 and 2^16-2 = (65534).


Fixed.


A.23. Section 10.1. = "root-cert  This element..."

I guess that the encoding to = use is base64, but it is said = nowhere.


Yes, the text here = says "PEM" but that's stupid. Changed to base64--unless someone = objects.



A.24. Section 10.1.1. "| attribute id { xsd:int = }),"

Does not match 13.6, that is saying that this is an unsigned = integer.  Should
probably use xsd:unsignedInt = instead.

Note that there is other places in the RELAX NG document = where the type can be
improved (initial-ttl, = etc...)

I'll leave this to = Cullen.


A.25. = Section 10.1.1. 'access-control-type |=3D = "user-match-with-anon-create"'

This control type is never defined = in the = document.


Removed.

=

A.26. Section 10.1.1. = 'kind-names |=3D "sip-registration"'

the sip-registration kind is = not defined in this document.  OTOH,
certificate-by-node and = certificate-by-name are defined, but not listed = here.

A cullen = problem.


A.27.= Section 10.1.1. 'self-signed-digest-type |=3D "sha1"'

Section = 10.1. says that '[v]alid values for this parameter are "SHA-1" = and
"SHA-256"'.

Adjusted the = text.


A.28. = Section 10.1.1 last paragraph "such an XML configuration file sent = over
email."

Because the signatures on the XML document are = done on exact byte string and
because emails servers are known to = mess with end of lines, we will see
configuration documents that = cannot be verified after been sent by email (what
was wrong with = using XML-sig anyway?).


It's= ridiculously overcomplicated for this application (and arguably for any = application).


A.29. Section 13.15 "destination: a hex-encoded = Destination List object"

A Destination List object is never = formally defined in the whole document, so is
it just Destination = objects packed together, or is it in fact a = "Destination
destination_list<0..2^16-1>" ?  In other = words, does it start with a length = field?

Added = something.

-Ekr


= --Apple-Mail-4--777903026-- From ekr@skype.net Tue Jan 18 07:33:12 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3E5828C1A7 for ; Tue, 18 Jan 2011 07:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaJZrEOpVtlo for ; Tue, 18 Jan 2011 07:33:11 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 016633A7005 for ; Tue, 18 Jan 2011 07:33:11 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 0B1E71708; Tue, 18 Jan 2011 16:35:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=mx; bh=a/GxYiRL5NOJBu4KIVXkVVwgoIk=; b=tzXKlbZ JWDnvvXl3M5qvJmoqFubn5j+O7/Fu068igZ4xLUbLf93xIOUKQyRV1iy5Xb3+AZJ c95eLLm3aGO84ZjVIJOBtzGdMI4mD7FSTw0fgCC+3vpOVz/ZySYHllunVeGFxh8E 4EWqdRzRNJK/k67sgR5/eE0DKsD1UmSb+J7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to; q=dns; s=mx; b=l8USWOkw6j5U+EaXFxizQ/xLkwWInUj5ZGvbb9t+uWCfHkTW VxcoSCWzQneOCNOxqHD6nmasIR3OO76ITxQx2BR43YzaqksDjS4jinTUR+8QA3jN e6RQRO+HApBwGfDCgLNLLzGpOCYMj60H4poWqIw3dtM0pmjxJse6aYwup2g= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 09C4516FC; Tue, 18 Jan 2011 16:35:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id D6ACB35077F2; Tue, 18 Jan 2011 16:35:47 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQXjqn342A2e; Tue, 18 Jan 2011 16:35:46 +0100 (CET) Received: from [192.168.8.196] (161.26.235.80.sta.estpak.ee [80.235.26.161]) by zimbra.skype.net (Postfix) with ESMTPSA id C7BFA3507CA5; Tue, 18 Jan 2011 16:35:45 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-5--776600160 From: Eric Rescorla In-Reply-To: <4CEAC54A.2030503@acm.org> Date: Tue, 18 Jan 2011 15:42:59 +0200 Message-Id: <1D7ECC00-15E7-4E46-9C3B-B942E0856815@skype.net> References: <4CEAC54A.2030503@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1082) Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (2) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2011 15:33:12 -0000 --Apple-Mail-5--776600160 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 22, 2010, at 11:32 AM, Marc Petit-Huguenin wrote: > ] > Because of this, it is probably a good idea to add in p2psip-base the > possibility to know the source Node-ID and destination Node-ID of a = message. > One way to do that would have be to have the sender of a message add = its own > Node-ID in the via_list, and the Node-ID of the destination in the > destination_list before sending a message (similar to what SIP is = doing), but I > guess that it is too late for such a modification. I don't think I understand your point about destination node-ids. They = will be in the destination list, no? I agree about source. We would also need to add text about populating the routing table with "accidental" adjacencies. I.e., if you connect to node 1234 and it gives = you a cert for 1234 and 5678 you need to automatically add that as a routing adjacency. > - - A.11. Looking at the examples in section 3.3, it seems that the = via_list is > updated only when the message forwarded is a request but not for = responses, but > I cannot find this anywhere in the text. So are all messages = processed the same > way when forwarded (and via updated on all types of messages) or = specifically on > requests? (by testing the last bit of message_code). >=20 > - - A.12. Section 10.3 states that "[t]he SubjectAltName field in the = certificate > contains the following values: One or more Node-IDs...", but nowhere = it is said > how to request multiple Node-IDs. Is it an URL parameter of the POST = request? > An attribute in the Certification Request object? >=20 Good question. This is an issue that's simply not addressed in the = draft., but presumably we'll need to do something like this, yeah. My taste would be for it to = be a URL in the POSt. >=20 > Nits > =3D=3D=3D=3D >=20 > - - Section 5.3, in the list "Security Block:" >=20 > s/""Message Contents"/"Message Contents"/ >=20 > - - Section 5.3.2.1 >=20 > s/destination_value/destination_data/ >=20 > - - Section 5.3.4 "overlay + transaction_id + MessageContents + = SignerIdentity" >=20 > The "+" should probably be replaced with "||". >=20 Done. -Ekr > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) >=20 > iEYEARECAAYFAkzqxUgACgkQ9RoMZyVa61fLpQCglb3AQGXUnEmD6athMaIGFBAx > vLkAn2r+Gy54Z/sJHMNv/j0i4Ic4y2ZZ > =3DbP6t > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip >=20 --Apple-Mail-5--776600160 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
]
Because of = this, it is probably a good idea to add in p2psip-base = the
possibility to know the source Node-ID and destination Node-ID of = a message.
One way to do that would have be to have the sender of a = message add its own
Node-ID in the via_list, and the Node-ID of the = destination in the
destination_list before sending a message (similar = to what SIP is doing), but I
guess that it is too late for such a = modification.

I don't think I = understand your point about destination node-ids. They will
be = in the destination list, no? I agree about = source.


We would also need to add = text about populating the routing table with
"accidental" = adjacencies. I.e., if you connect to node 1234 and it gives = you
a cert for 1234 and 5678 you need to automatically add = that as a = routing
adjacency.


<= blockquote type=3D"cite">
- - A.11. Looking at the examples in = section 3.3, it seems that the via_list is
updated only when the = message forwarded is a request but not for responses, but
I cannot = find this anywhere in the text.  So are all messages processed the = same
way when forwarded (and via updated on all types of messages) or = specifically on
requests? (by testing the last bit of = message_code).

- - A.12. Section 10.3 states that "[t]he = SubjectAltName field in the certificate
contains the following = values: One or more Node-IDs...", but nowhere it is said
how to = request multiple Node-IDs.  Is it an URL parameter of the POST = request?
An attribute in the Certification Request = object?


Good question. This is = an issue that's simply not addressed in the draft., but = presumably
we'll need to do something like this, yeah. My = taste would be for it to be a URL in the = POSt.



Nits
=3D=3D=3D=3D

- - Section 5.3, in = the list "Security Block:"

s/""Message Contents"/"Message = Contents"/

- - Section = 5.3.2.1

s/destination_value/destination_data/

- - Section = 5.3.4 "overlay + transaction_id + MessageContents + = SignerIdentity"

The "+" should probably be replaced with = "||".


Done.

<= div>-Ekr

- --
Marc = Petit-Huguenin
Personal email: marc@petit-huguenin.org
Pro= fessional email: petithug@acm.org
Blog: http://blog.marc.petit-huguen= in.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 = (GNU/Linux)

iEYEARECAAYFAkzqxUgACgkQ9RoMZyVa61fLpQCglb3AQGXUnEmD6at= hMaIGFBAx
vLkAn2r+Gy54Z/sJHMNv/j0i4Ic4y2ZZ
=3DbP6t
-----END PGP = SIGNATURE-----
_______________________________________________
P2PSI= P mailing list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip


= --Apple-Mail-5--776600160-- From ekr@skype.net Tue Jan 18 07:33:13 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6568028C1A7 for ; Tue, 18 Jan 2011 07:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjLnQk147kWH for ; Tue, 18 Jan 2011 07:33:12 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 6241628C192 for ; Tue, 18 Jan 2011 07:33:12 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 6F2D71707; Tue, 18 Jan 2011 16:35:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mx; bh=IK V2wud/9mdhUqhlx29+qHv3v9s=; b=UWu50jxskv/V+T4M7c/ajKX+rI0BrNwr6M xI1ozAi1lQkS7W7tArQ9ciNMvFxpP32lsdgJqCa6vQ83xrjtLQ8Q/mnwl/2Cj/t4 6/GfKWcFUZUcHm42IFg6EBpM/QcKnVmJnBRLJw8xen0OE1CbvMiSpTxuoQZGvcBO wFgIN0j3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=mx; b=SYzqQyVZrmEOub+7k5R0t2 uI8kZ9WJrEPWMTSKETEnFiyUPvQD0HNmdkyt4tNKWjsOKXSjKrH9YPKql+lsYA+h zaPSm57C/2ueH2HWiOuq0gH9OjNCvZ+Anq5iK/enlFI9vm4dopwprdThpElas659 Tm2mUqHu8//gEVDs+8Vd0= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 6DE5D16FC; Tue, 18 Jan 2011 16:35:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 506D435077F2; Tue, 18 Jan 2011 16:35:49 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLPoNCE6uiuI; Tue, 18 Jan 2011 16:35:45 +0100 (CET) Received: from [192.168.8.196] (161.26.235.80.sta.estpak.ee [80.235.26.161]) by zimbra.skype.net (Postfix) with ESMTPSA id 1A94B3507792; Tue, 18 Jan 2011 16:35:45 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Eric Rescorla In-Reply-To: <4CE42CDF.4060804@acm.org> Date: Tue, 18 Jan 2011 05:32:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CE42CDF.4060804@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1082) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2011 15:33:13 -0000 On Nov 17, 2010, at 11:28 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Few more nits: >=20 > - - Section 5.5.4.1 "typedef uint16 KindId;" >=20 > This contradicts section 13.6 that states that KindId are 32-bit = integers. >=20 > (Reported by St=E9phane Bryant) >=20 I'm tempted to change the bits on the wire here--bigger seems better. = Obviously this is a breaking change. Comments? > - - Section 5.5.4.2 "} ConfigUpdateRsp" >=20 > Should be ConfigUpdateAns to match the other answer definitions. >=20 Fixed. > - - Section 9.1 last paragraph >=20 > s/peer id/Node-ID/ >=20 > - - Section 11 2nd paragraph >=20 > This paragraph is a duplicate of the first sentence of the previous = paragraph. Fixed. > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) >=20 > iEYEARECAAYFAkzkLN0ACgkQ9RoMZyVa61cKdgCeI0GK4nzV/JdzCf5Or7jre9fL > 3OgAnA+j+zp6wOQ2N1Ryxl45cDH+jZUg > =3DvIN0 > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From ekr@skype.net Tue Jan 18 02:25:12 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA823A6FBB for ; Tue, 18 Jan 2011 02:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.266 X-Spam-Level: ** X-Spam-Status: No, score=2.266 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIFqL5fjsEKn for ; Tue, 18 Jan 2011 02:25:11 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id CB2823A6E74 for ; Tue, 18 Jan 2011 02:25:10 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 669FC1700; Tue, 18 Jan 2011 11:27:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=mx; bh=uin/E9o8AvkEgZSNjBpAp47gs4k=; b=Okz+U2F u8gj78bTrpxKZEWmLbjs4LIX3zjv9MmYzYZ3O097ZXF8ACKkdIfIYtuKiNbMtcbz C3kv3SoxeAx7uRjDSjW3Kej4URQbbTjcL6ts+V7FQN2jB5krU5dwATJxrAhfULjh rF+KqKSaKuiLE5T+csaH5DaYr2q+OTcLxAFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to; q=dns; s=mx; b=f+VeMcnG7WbxBS+Arl05D5Oa+83AJh9LOUWnGTREJqCdzryx J0Wzk5IQ1MzAJuvyl7Jhiy48G5TH/PHvS2ZqcNybPRJMCyUJsF4YulLqLCOiX9zd 50T1y7vSLk8sl/Q2UiOEIhBn9N8Q14mEgICki2anPlDqeRdCN+DkL0iZ3gU= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 651D97FD; Tue, 18 Jan 2011 11:27:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 41B4335074C0; Tue, 18 Jan 2011 11:27:46 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bW633s0DoSid; Tue, 18 Jan 2011 11:27:44 +0100 (CET) Received: from [172.30.29.190] (unknown [80.187.150.40]) by zimbra.skype.net (Postfix) with ESMTPSA id A7B1A3507502; Tue, 18 Jan 2011 11:27:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-2--788288283 From: Eric Rescorla In-Reply-To: Date: Tue, 18 Jan 2011 02:28:11 -0800 Message-Id: <734385D7-A7AB-4D52-A817-735DDB4F7DAC@skype.net> References: To: li.lichun1@zte.com.cn X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Tue, 18 Jan 2011 08:05:41 -0800 Cc: P2PSIP WG Subject: Re: [P2PSIP] Typo in base draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2011 10:25:12 -0000 --Apple-Mail-2--788288283 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Got it. Thanks. -Ekr On Jan 13, 2011, at 4:41 PM, li.lichun1@zte.com.cn wrote: >=20 > I think "JoinReq" and "joining_peer_id" should be "LeaveReq" and = "leaving_peer_id" here. >=20 >=20 >=20 > Eric Rescorla > 2011-01-14 01:33 >=20 > =CA=D5=BC=FE=C8=CB > li.lichun1@zte.com.cn > =B3=AD=CB=CD > P2PSIP WG > =D6=F7=CC=E2 > Re: [P2PSIP] Typo in base draft >=20 >=20 >=20 >=20 >=20 > Sorry, so what's the typo here. I'm sure I'm just missing it.... >=20 > -Ekr >=20 >=20 > On Fri, Dec 17, 2010 at 6:54 AM, wrote: > > > > 5.4.2.2 > > "LeaveReq contains only the Node-ID of the leaving peer. Overlay > > algorithms MAY specify other data to appear in this request. > > Receivers of the JoinReq MUST verify that the joining_peer_id = field > > matches the Node-ID used to sign the message and if not MUST = reject > > the message with an Error_Forbidden error." > > > > BR > > Lichun > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. > > This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > > > > >=20 >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. > This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail-2--788288283 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 Got = it. Thanks.

-Ekr

On Jan 13, = 2011, at 4:41 PM, li.lichun1@zte.com.cn = wrote:


I think "JoinReq" and = "joining_peer_id" should be "LeaveReq" and "leaving_peer_id" here.


Eric Rescorla = <ekr@rtfm.com>

2011-01-14 01:33

=CA=D5=BC=FE=C8=CB
li.lichun1@zte.com.cn
=B3=AD=CB=CD
P2PSIP WG <p2psip@ietf.org>
=D6=F7=CC=E2
Re: [P2PSIP] Typo in base = draft





Sorry, so what's the typo here. I'm sure I'm = just missing it....

-Ekr


On Fri, Dec 17, 2010 at 6:54 AM,  <li.lichun1@zte.com.cn> = wrote:
>
> 5.4.2.2
> "LeaveReq contains only the Node-ID of the leaving peer. =  Overlay
>   algorithms MAY specify other data to appear in this = request.
>   Receivers of the JoinReq MUST verify that the = joining_peer_id field
>   matches the Node-ID used to sign the message and if not MUST reject
>   the message with an Error_Forbidden error."
>
> BR
> Lichun
>
> --------------------------------------------------------
> = ZTE Information Security Notice: The information&= nbsp;contained in this mail is solely proper= ty of the sender's organization. This mail&n= bsp;communication is confidential. Recipients named&nb= sp;above are obligated to maintain secrecy a= nd are not permitted to disclose the co= ntents of this communication to others.
> = This email and any files transmitted with&nb= sp;it are confidential and intended solely f= or the use of the individual or entity&= nbsp;to whom they are addressed. If you = ;have received this email in error please&nb= sp;notify the originator of the message. Any=  views expressed in this message are th= ose of the individual sender.
> = This message has been scanned for viruses&nb= sp;and Spam by ZTE Anti-Spam system.
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www.ietf.org= /mailman/listinfo/p2psip
>
>

 

--------------------------------------------------------
=
ZTE Information Security Notice: The information&=
nbsp;contained in this mail is solely proper=
ty of the sender's organization. This mail&n=
bsp;communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy a=
nd are not permitted to disclose the co=
ntents of this communication to others.
=
This email and any files transmitted with&nb=
sp;it are confidential and intended solely f=
or the use of the individual or entity&=
nbsp;to whom they are addressed. If you =
;have received this email in error please&nb=
sp;notify the originator of the message. Any=
 views expressed in this message are th=
ose of the individual sender.
=
This message has been scanned for viruses&nb=
sp;and Spam by ZTE Anti-Spam system.
_______________________________________________
P2PSIP mailing = list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip

= --Apple-Mail-2--788288283-- From ekr@skype.net Tue Jan 18 02:37:22 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A02C83A6FCD for ; Tue, 18 Jan 2011 02:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.167 X-Spam-Level: X-Spam-Status: No, score=-0.167 tagged_above=-999 required=5 tests=[AWL=2.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72E77XcpD95r for ; Tue, 18 Jan 2011 02:37:21 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 5BF9D3A6F6E for ; Tue, 18 Jan 2011 02:37:21 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id C883F16FF; Tue, 18 Jan 2011 11:39:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mx; bh=Ok xKOV3AjN/RYtvZVP6LqZABPew=; b=XKonKfymKOmV2CLuYvShbQJC1tIM8En/sC ql5+Pg4ehI+9yTThagyW/vM5YhT+fIQbf/nJ8KnT2fbOVBBJeaML65pFncu/azFJ ge3eZbRYu1raLlZVEYxA+6+RKeCxbT5D19TuKhI55NTq3OLy3DLy1A8w8wOgiltN bevw8Hm7E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=mx; b=wlHf+PJzUTcmllJWPTD+lO 51dJMie63zWkTn7LxUyttho3HWyx8pnXBZazYjCl6HQw2JovULYdjkTIcQ8VeDsf q1xsfphzfB7+F0rB11fZlAavdmS/R2YAoZ1tFoADbgNYWq1ZCPYSmGX+pJSd6fmj J5VhQ0cbW3maFrRa3tE/Y= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id C6E347FD; Tue, 18 Jan 2011 11:39:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id A76C23507C8D; Tue, 18 Jan 2011 11:39:57 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6k6RDqG2ML7; Tue, 18 Jan 2011 11:39:56 +0100 (CET) Received: from [172.30.29.190] (unknown [80.187.150.40]) by zimbra.skype.net (Postfix) with ESMTPSA id C9E6135077A3; Tue, 18 Jan 2011 11:39:55 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Eric Rescorla In-Reply-To: Date: Tue, 18 Jan 2011 02:40:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <908474C7-827B-4A10-94CF-955033086C23@skype.net> References: <026c01cb8952$bf0a06a0$3d1e13e0$%roni@huawei.com> <021a01cbadab$21b4eff0$651ecfd0$%roni@huawei.com> To: Bruce Lowekamp X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Tue, 18 Jan 2011 08:05:41 -0800 Cc: P2PSIP WG , Roni Even Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2011 10:37:22 -0000 I've made this change. -Ekr On Jan 7, 2011, at 2:29 PM, Bruce Lowekamp wrote: > I think requiring the state timeout mechanism to be used for every > message would be a bit much to put on the peers. I would rather > provide the explicit flag. >=20 > Bruce >=20 > On Thu, Jan 6, 2011 at 9:07 AM, Roni Even = wrote: >> Hi Bruce, >> I think that the flag for not keeping state may be useful but there = is also another mechanism which is the time out that tells intermediate = nodes to discard any state after a timeout. >> Roni >>=20 >>> -----Original Message----- >>> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >>> Behalf Of Bruce Lowekamp >>> Sent: Thursday, December 02, 2010 8:54 PM >>> To: David A. Bryan >>> Cc: P2PSIP WG; Roni Even >>> Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft = from >>> meeting - DRR >>>=20 >>> The motivation for putting it into the base draft was that if it is >>> part of the base spec, then in the future nodes that implement >>> whatever is specified in the relay/DRR draft can make use of those >>> techniques while on an overlay with nodes that only implement the = base >>> draft. For example: >>>=20 >>> - any sort of relay/DRR requires intermediate nodes to not keep any >>> state about routed messages. If support for the routing flag that >>> allows this is not in the base draft, they will have to simply = reject >>> the message. >>> - knowledge of how to set up a relay node isn't required to make use >>> of the relay node. >>>=20 >>> The intention of the current text was that it could currently only = be >>> used with no-ice. But it would provide support so that nodes that >>> only implement the base draft would be able to forward messages = using >>> relay/DRR and would also be able to send messages to a relay node in >>> the future without knowing the details of how that is set up. As >>> currently specified, it definitely needs some text stating = explicitly >>> that it can currently only be used with no-ice. >>>=20 >>> There's another option where we add a ForwardingOptions flag to the >>> base draft that specifies not to keep state about the message, but >>> isn't explicitly a DRR flag. There might even be a benefit to doing >>> that, in that it wouldn't be explicitly tied to the DRR mechanism in >>> there now. >>>=20 >>> Or , of course, we can remove it completely, at the cost that base >>> nodes won't be compatible with whatever is done in the relay/DRR >>> draft. >>>=20 >>> Bruce >>>=20 >>>=20 >>> On Tue, Nov 30, 2010 at 8:03 AM, David A. Bryan = >>> wrote: >>>> I also think the current text is too limiting. The best approach is >>> to >>>> make it clear in the draft that other routing techniques are = allowed >>>> and supported, leave in the flags but remove the very skeletal = direct >>>> response routing from this draft and we instead do that in the >>>> relay/direct response draft. >>>>=20 >>>> David (as individual) >>>>=20 >>>> On Sun, Nov 21, 2010 at 3:04 AM, Roni Even >>> wrote: >>>>>=20 >>>>>>=20 >>>>>> Direct Response Routing and ICE >>>>>> =95 Specified in =A75.3.2.4 >>>>>> This option can only be used if the direct-return-response- >>> permitted >>>>>> flag in the configuration for the overlay is set to TRUE. The >>>>>> RESPONSE_COPY flag SHOULD be set to false while the >>> FORWARD_CRITICAL >>>>>> and DESTINATION_CRITICAL MUST be set to true. When a node that >>>>>> supports this forwarding options receives a request with it, it >>> acts >>>>>> as if it had send an Attach request to the the requesting_node = and >>> it >>>>>> had received the connection_information in the answer. This = causes >>> it >>>>>> to form a new connection directly to that node. >>>>>> =95 This doesn=92t work with ICE because the sender of the = request >>> doesn=92t >>>>>> have your information >>>>>> Proposed Resolution: DRR can only be used with No-ICE >>>>>> ***NOTE: This slide generated significant discussion in the >>> meeting. >>>>>> There were some comments that this was incomplete, and discussion >>> of >>>>>> moving this out of the base draft and into the relay/direct >>> response >>>>>> draft. ADDITIONAL DISCUSSION REQUIRED. >>>>>=20 >>>>> I see the problem and think that we should take this section out >>> from RELOAD and continue with the individual relay draft = (draft-jiang- >>> p2psip-relay-04) for the use case where the node is not behind NAT = or a >>> relay can be used. >>>>> In this case we will need to verify that RELOAD allows such >>> extensions and that there are no issues with supporting it due to = some >>> routing assumptions. >>>>>=20 >>>>> Roni Even >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>>=20 >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>=20 >>=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Tue Jan 18 09:50:26 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2B373A6FBA for ; Tue, 18 Jan 2011 09:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.022 X-Spam-Level: X-Spam-Status: No, score=-102.022 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqIL1Kg7vtwy for ; Tue, 18 Jan 2011 09:50:26 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 0A2EF3A6E78 for ; Tue, 18 Jan 2011 09:50:25 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 5ACBEDFC4010; Tue, 18 Jan 2011 17:53:03 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id E4370DFC400E for ; Tue, 18 Jan 2011 17:53:02 +0000 (UTC) Message-ID: <4D35D37E.9040409@acm.org> Date: Tue, 18 Jan 2011 09:53:02 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] draft-ietf-p2psip-base-12 (4) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2011 17:50:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Three nits that I hope will make it in -13: - - Section 6.4.1.1: In the text description of StoreKindData: s/generation/generation_counter/ - - Section 6.4.1.2: In the text description of StoreKindData: s/generation/generation_counter/ Section 10.1: s/It has an attributed called "address"/It has an attribute called "address"/ - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk0103wACgkQ9RoMZyVa61ccSQCgiU0ZosVYTb/AmCLyuKF6nhX7 8U8An0omFdpD60fUmBqc8/zcuG2QRyG7 =kfgg -----END PGP SIGNATURE----- From henry.sinnreich@gmail.com Tue Jan 18 09:22:03 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0641D28C21E; Tue, 18 Jan 2011 09:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsrDTm765kcj; Tue, 18 Jan 2011 09:22:01 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 3D00E28C0F1; Tue, 18 Jan 2011 09:22:01 -0800 (PST) Received: by gwj17 with SMTP id 17so2684081gwj.31 for ; Tue, 18 Jan 2011 09:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=tPAeerIR9mRtJIio14cxeZyREDxSaVBRN51soh7VdUw=; b=hKaVMQxtGDm7kDl+0Qvt8OwyEt2h7zqHs0IKvXbK2Xi1oEcsBiSFK4hx1Jc2Ifwrl4 XyBU31SPN3aMn51FO6jTPPDIradZhsYkBkTrQ6jsR6b8RK2KIFv+FWqX0rMlSBA4QH0h T6lqx91JW8Lp1X+vfIdWhrJNo6b6O69cI1D6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=n1vAXLuWFm310RkOZcNAqbOpp32metpPEOGoAIJLdgacoIJX64FzfpiW8essKyJwfm IqrQk/OcNfER2qfkJxpn6hdmV6m3RYD156CC4/lGu5JPgMF5waq0uvCptwQqX6vKYtuE arQ5YJcIJ9f2pkqT0qyBbiooyHCZS/NzoZpAs= Received: by 10.100.137.3 with SMTP id k3mr955644and.112.1295371477613; Tue, 18 Jan 2011 09:24:37 -0800 (PST) Received: from [10.0.1.5] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id c30sm7224115anc.0.2011.01.18.09.24.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 09:24:28 -0800 (PST) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 18 Jan 2011 11:24:23 -0600 From: Henry Sinnreich To: Jan Seedorf , "p2prg@irtf.org" , P2PSIP WG , "ppsp@ietf.org" , 'alto' , "decade@ietf.org" Message-ID: Thread-Topic: [decade] Live streaming of NAPA-WINE P2P-TV workshop with P2P software Thread-Index: Acu2+sxB9abvF+YITYupvh0rusVDHQAOcAJn In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE7E96AF@PALLENE.office.hd> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Mailman-Approved-At: Tue, 18 Jan 2011 10:07:12 -0800 Subject: Re: [P2PSIP] [decade] Live streaming of NAPA-WINE P2P-TV workshop with P2P software X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2011 17:22:03 -0000 This spam is highly unwelcome. Also quite surprising, since your spam has already been called out on another list. Thanks, Henry On 1/18/11 4:30 AM, "Jan Seedorf" wrote: > P2P folks at IETF, >=20 > To help people interested in the P2P-TV workshop we are hosting, > the NAPA-WINE project's final workshop will be *broadcasted live* > with the P2P Live Streaming Software developed by the NAPA-WINE project. >=20 > The workshop opens on Thursday 20th January at 2.30PM CET and closes > on Friday 21th January afternoon at 6.00PM CET. > Recordings of the workshop will be made available from the project web si= te > few days after the event too. >=20 > For people interested in following the workshop/talks live > via P2P video stream, we have prepared a page with Quick-Start > instructions on how to download, install, and use the software > to follow the event live. If you are interested, please go to >=20 > http://www.napa-wine.eu/cgi-bin/twiki/view/Public/NapaWineWorkshopLive >=20 > If you have any questions regarding the use of the software or following > the final workshop live with it, please use the mailing list > (napalive@tlc.polito.it). >=20 > A demo activity of the software is scheduled at 5.30PM (and yes! you > will be part of the demo if you join the channel!) >=20 > *Workshop Program* > The final NAPA-WINE workshop is intended as an informal forum for lively > discussions on current and future trends in peer-to-peer live streaming. = The > program comprises four talks presenting the main NAPA-WINE achievements (= and a > demo of NAPA-WINE's network-aware P2P live streaming system) as well as n= ine > talks from external highly qualified researchers from both academia and > industry, providing a broad and articulated perspective on the main chall= enges > and solutions on the topic. There will be external presentations provided= by > (see http://www.napa-wine.eu/workshop/program.html for agenda details): >=20 > - Presentations from other on-going European projects on P2P-TV/CDN: > * Future Media Networks (FMN) cluster and ENVISION (David Griffin, UCL,= GB) > * COAST/SEA (Emanuele Quacchio, ST Microelectronics, IT) > * P2P-NEXT (Raul Jimenez, KTH, SE) > - Presentations from the industrial world (the operator/content provider > vision): > * Nikolaos Laoutaris, Telefonica Research, ES > * Enrico Marocco, Chair of IETF ALTO, Telecom Italia, IT > - Presentations from academia (technical challenges) > * Ernst Biersack, Eurecom, FR > * Phuoc Tran-Gia, Tobias Hossfeld, University of Wuerzburg, DE > * Yong Liu, Polytechnic Institute of NYU, US > * Victoria Fodor, Gyorgy Dan, KTH, SE >=20 > For further workshop program details, please see > http://www.napa-wine.eu/workshop/ >=20 > - Jan >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Jan Seedorf > Senior Researcher > NEC Europe Ltd., NEC Laboratories Europe, Network Division=A0=A0=A0=A0=A0 > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel.=A0=A0=A0=A0 +49 (0)6221 4342-221 > Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 > e-mail:=A0 jan.seedorf@neclab.eu > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC Europe Limited Registered Office: NEC House, > 1 Victoria Road, London W3 6BL Registered in England 2832014 >=20 >=20 > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From petithug@acm.org Tue Jan 18 10:19:46 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E113A7059 for ; Tue, 18 Jan 2011 10:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.033 X-Spam-Level: X-Spam-Status: No, score=-102.033 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yBiDtr7nVDt for ; Tue, 18 Jan 2011 10:19:45 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 306E73A7050 for ; Tue, 18 Jan 2011 10:19:45 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id ECF8EDFC4010; Tue, 18 Jan 2011 18:22:22 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 29A92DFC400E; Tue, 18 Jan 2011 18:22:22 +0000 (UTC) Message-ID: <4D35DA5D.7000804@acm.org> Date: Tue, 18 Jan 2011 10:22:21 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Eric Rescorla References: <4CFD5FCD.7060205@acm.org> <29353BE9-83FE-40C3-817F-6649AE09DF0C@skype.net> In-Reply-To: <29353BE9-83FE-40C3-817F-6649AE09DF0C@skype.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (3) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2011 18:19:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Inline. On 01/18/2011 05:21 AM, Eric Rescorla wrote: > > On Dec 6, 2010, at 2:12 PM, Marc Petit-Huguenin wrote: >> bytes, or 2032 bits. >> >> A.14. Section 5.3.2 "uint32 length;" >> >> I can assume that this length covers the Header, MessageContents and >> Signature, >> but I would guess that this was useful when Message was sent without >> FramingHeader over TCP (same than for the relo_token used to >> disambiguate STUN >> packets). Now that this is useless, can't this length been only >> Header and >> MessageContents, so it is possible to find the boundary between >> MessageContents >> and Signature without having to parse MessageContents at all? >> > > I think it's a mistake to assume we'll never want messages to be > self-contained/unframed. > Is there a real advantage to this breaking change? A little easier to parse the message, but you are right that a message can be unframed. [...] >> A.16. Section 5.5.1.1. "IceCandidate candidates<0..2^16-1>;" >> >> Because there must be at least one candidate, should this be: >> >> IceCandidate candidates<1..2^16-1>; > > It's actually quite a but longer than that, because IceCandidate is > fairly long. > However, I think it's harmless to leave it as-is and actually putting > 12..2^16-1 or whatever is just confusing. OK >> A.19. Section 5.6.3.1.1, last paragraph >> >> This paragraph described a lockstep algorithm, but if it is the case >> then there >> is no need for the received field, as we would always know that the >> previous >> messages have been received. >> > > Sorry, I'm not sure I understand the question. The received field is > there to > permit the sender to unilaterally use more sophisticated algorithms. > Here's what the last paragraph says: "Once an ACK has been received for a message, the next message can be sent, but the peer SHOULD ensure that there is at least 10 ms between sending any two messages. The only time a value less than 10 ms can be used is when it is known that all nodes are on a network that can support retransmissions faster than 10 ms with no congestion issues." What I understand from this text is that a message cannot be sent until the previous one has been acknowledged. If other algorithms can be used (e.g. one that use the received field), then the text should say that the algorithm above is the basic algorithm that must at least been implemented. > >> A.20. Section 5.7, "If the message is not fragmented, then both the >> first and >> last fragment are set to 1..." >> >> If the first fragment bit is set to 1 when the message is fragmented >> and is also >> set to one when the message is not fragmented, then it is always set >> to 1, so >> what is the point of having it in the first place? > > > Good point. OTOH, does this do any damage? If not, I'm tempted to write it > down as a misfeature and leave as-is. OK. Perhaps a note somewhere about this would be useful for future developers. >> A.21. Section 10.1. "..." >> >> Why do we need to repeat the data-model and access-control that were >> already in >> the IANA registry? Or is it a way to override the IANA definitions as the >> example would suggest? (as the registration for SIP-REGISTRATION is using >> DICTIONARY and USER-NODE-MATCH). >> > > No, it's just to preserve uniform syntax for IANA-defined and > user-defined kinds. OK, but what happen if the values in the XML are different from what is in the RFC describing the Kind (like it is currently in the example). My suggestion would be to simply say that the values in the XML files are ignored for IANA-defined kinds. [...] >> A.28. Section 10.1.1 last paragraph "such an XML configuration file >> sent over >> email." >> >> Because the signatures on the XML document are done on exact byte >> string and >> because emails servers are known to mess with end of lines, we will see >> configuration documents that cannot be verified after been sent by >> email (what >> was wrong with using XML-sig anyway?). >> > > It's ridiculously overcomplicated for this application (and arguably for > any application). OK. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk012lwACgkQ9RoMZyVa61dEfACaAwKwiLT0CpVaxDFjmF24Htfv ZxgAoIbFGmodRm3Q4Q30RiacwmMkjLZO =rh5C -----END PGP SIGNATURE----- From petithug@acm.org Tue Jan 18 10:27:20 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55363A7059 for ; Tue, 18 Jan 2011 10:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.043 X-Spam-Level: X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28AiS1RRvqXR for ; Tue, 18 Jan 2011 10:27:19 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 9AAE13A6FE2 for ; Tue, 18 Jan 2011 10:27:19 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 9CF79DFC4010; Tue, 18 Jan 2011 18:29:57 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 2E07CDFC400E; Tue, 18 Jan 2011 18:29:57 +0000 (UTC) Message-ID: <4D35DC24.6030808@acm.org> Date: Tue, 18 Jan 2011 10:29:56 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Eric Rescorla References: <4CE42CDF.4060804@acm.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jan 2011 18:27:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/18/2011 05:32 AM, Eric Rescorla wrote: > > On Nov 17, 2010, at 11:28 AM, Marc Petit-Huguenin wrote: > > Few more nits: > > - Section 5.5.4.1 "typedef uint16 KindId;" > > This contradicts section 13.6 that states that KindId are 32-bit integers. > > (Reported by Stéphane Bryant) > > >> I'm tempted to change the bits on the wire here--bigger seems better. Obviously >> this is a breaking change. Comments? I am personally all for breaking compatibility between different versions of an I-D. You can make it easy for implementers by incrementing the minor version in the Forwarding header (i.e. 0x01-->0x02, and it will still be changed to 0x0a when published as an RFC). - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk013B8ACgkQ9RoMZyVa61fOvQCcCo/Cf4iZpVjRb/2zg1sWvmtL qDAAoIN+o+pu7/4WSyjYyc/kuWsxtXXT =bKtP -----END PGP SIGNATURE----- From ekr@skype.net Tue Jan 18 22:54:12 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB183A6EF5 for ; Tue, 18 Jan 2011 22:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGNLp4TfFa2A for ; Tue, 18 Jan 2011 22:54:09 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id E6AB53A6E7E for ; Tue, 18 Jan 2011 22:54:08 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 11B98170F; Wed, 19 Jan 2011 07:56:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mx; bh=qD RIKM3MIHK/ZCzrLqlhyQtg6mQ=; b=bULD1m9H9Lk4+VxGwdoD+g4th7OWOXXUku xSXLorpLRKd6DCs7g/YA2b6reMNdWOgihvTYHDOiV02ChGZyjXxX8cz6zNJZ4koU ez3RP5VuMLqzrv7aU8JDEGroAfwQPEq42uSOnERrioAy1NUwsc0cQpJxjsYpESOG WdqBuD+r0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=mx; b=CCy+5xjgHGpWiR+aoWn0ku qx3MSsJeNBoUeJAdc/9ps1x0HFVLz5kTjzEKkSI5ddhj7u0H2HXs19Ml9OZtfrGe CDS5qQarpJetbBQHHWpkWnwaMrRChE5siw3NunJBOl/XI5E05UwR2gRzXO25k3p2 xNGzOxpUNuFwZaGWrpJEA= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 1031516FC; Wed, 19 Jan 2011 07:56:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id E49E23506EFB; Wed, 19 Jan 2011 07:56:46 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQBlvDfonivL; Wed, 19 Jan 2011 07:56:46 +0100 (CET) Received: from [172.16.27.138] (unknown [194.126.108.2]) by zimbra.skype.net (Postfix) with ESMTPSA id C9FB13506E1F; Wed, 19 Jan 2011 07:56:45 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Eric Rescorla In-Reply-To: <4D35DA5D.7000804@acm.org> Date: Wed, 19 Jan 2011 08:57:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6314438E-52EE-4F6C-B4B9-BA9D9C83D9CF@skype.net> References: <4CFD5FCD.7060205@acm.org> <29353BE9-83FE-40C3-817F-6649AE09DF0C@skype.net> <4D35DA5D.7000804@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1082) Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (3) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 19 Jan 2011 06:54:12 -0000 On Jan 18, 2011, at 8:22 PM, Marc Petit-Huguenin wrote: >=20 > On 01/18/2011 05:21 AM, Eric Rescorla wrote: >>=20 >> On Dec 6, 2010, at 2:12 PM, Marc Petit-Huguenin wrote: >>> bytes, or 2032 bits. >>>=20 >>> A.14. Section 5.3.2 "uint32 length;" >>>=20 >>> I can assume that this length covers the Header, MessageContents and >>> Signature, >>> but I would guess that this was useful when Message was sent without >>> FramingHeader over TCP (same than for the relo_token used to >>> disambiguate STUN >>> packets). Now that this is useless, can't this length been only >>> Header and >>> MessageContents, so it is possible to find the boundary between >>> MessageContents >>> and Signature without having to parse MessageContents at all? >>>=20 >>=20 >> I think it's a mistake to assume we'll never want messages to be >> self-contained/unframed. >> Is there a real advantage to this breaking change? >=20 > A little easier to parse the message, but you are right that a message = can be > unframed. >=20 > [...] >=20 >>> A.16. Section 5.5.1.1. "IceCandidate candidates<0..2^16-1>;" >>>=20 >>> Because there must be at least one candidate, should this be: >>>=20 >>> IceCandidate candidates<1..2^16-1>; >>=20 >> It's actually quite a but longer than that, because IceCandidate is >> fairly long. >> However, I think it's harmless to leave it as-is and actually putting=20= >> 12..2^16-1 or whatever is just confusing. >=20 > OK >=20 >>> A.19. Section 5.6.3.1.1, last paragraph >>>=20 >>> This paragraph described a lockstep algorithm, but if it is the case >>> then there >>> is no need for the received field, as we would always know that the >>> previous >>> messages have been received. >>>=20 >>=20 >> Sorry, I'm not sure I understand the question. The received field is >> there to=20 >> permit the sender to unilaterally use more sophisticated algorithms. >>=20 >=20 > Here's what the last paragraph says: >=20 > "Once an ACK has been received for a message, the next message can be > sent, but the peer SHOULD ensure that there is at least 10 ms between > sending any two messages. The only time a value less than 10 ms can > be used is when it is known that all nodes are on a network that can > support retransmissions faster than 10 ms with no congestion issues." >=20 > What I understand from this text is that a message cannot be sent = until the > previous one has been acknowledged. If other algorithms can be used = (e.g. one > that use the received field), then the text should say that the = algorithm above > is the basic algorithm that must at least been implemented. >=20 Sounds good. Willdo. >>=20 >> Good point. OTOH, does this do any damage? If not, I'm tempted to = write it >> down as a misfeature and leave as-is. Done. > OK. Perhaps a note somewhere about this would be useful for future = developers. >=20 >>> A.21. Section 10.1. "..." >>>=20 >>> Why do we need to repeat the data-model and access-control that were >>> already in >>> the IANA registry? Or is it a way to override the IANA definitions = as the >>> example would suggest? (as the registration for SIP-REGISTRATION is = using >>> DICTIONARY and USER-NODE-MATCH). >>>=20 >>=20 >> No, it's just to preserve uniform syntax for IANA-defined and >> user-defined kinds. >=20 > OK, but what happen if the values in the XML are different from what = is in the > RFC describing the Kind (like it is currently in the example). My = suggestion > would be to simply say that the values in the XML files are ignored = for > IANA-defined kinds. >=20 I've made this change, but I'd like to have other people weigh in if = they don't like it. -Ekr From Jan.Seedorf@neclab.eu Wed Jan 19 06:30:24 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C052D3A7146; Wed, 19 Jan 2011 06:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZovOkvjMYj2v; Wed, 19 Jan 2011 06:30:23 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 39EC53A7145; Wed, 19 Jan 2011 06:30:23 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3DA712C000349; Wed, 19 Jan 2011 15:33:23 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qC4v+gEIa0XP; Wed, 19 Jan 2011 15:33:23 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 1EFA22C0001AF; Wed, 19 Jan 2011 15:32:53 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.59]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Wed, 19 Jan 2011 15:32:32 +0100 From: Jan Seedorf To: Henry Sinnreich , "p2prg@irtf.org" , P2PSIP WG , "ppsp@ietf.org" , 'alto' , "decade@ietf.org" Thread-Topic: [decade] Live streaming of NAPA-WINE P2P-TV workshop with P2P software Thread-Index: Acu2+sxB9abvF+YITYupvh0rusVDHQAOcAJnACv7d1A= Date: Wed, 19 Jan 2011 14:32:31 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE7E9ECC@PALLENE.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE7E96AF@PALLENE.office.hd> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.199] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [P2PSIP] [decade] Live streaming of NAPA-WINE P2P-TV workshop with P2P software X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 19 Jan 2011 14:30:24 -0000 Dear Henry, all, I apologize for abusing the mailing lists. Many IETF people had told me individually that they are highly interested i= n our workshop but cannot attend in person. I had received many emails with= questions on how to access workshop material after the event. Thus, I thou= ght it is of interest to this community that we are streaming the workshop = live with P2P software and everybody can join the P2P swarm to watch the ta= lks. Sorry if my mail was perceived as spam, - Jan > -----Original Message----- > From: Henry Sinnreich [mailto:henry.sinnreich@gmail.com] > Sent: Dienstag, 18. Januar 2011 18:24 > To: Jan Seedorf; p2prg@irtf.org; P2PSIP WG; ppsp@ietf.org; 'alto'; > decade@ietf.org > Subject: Re: [decade] Live streaming of NAPA-WINE P2P-TV workshop with P2= P > software >=20 > This spam is highly unwelcome. > Also quite surprising, since your spam has already been called out on > another list. >=20 > Thanks, Henry >=20 >=20 > On 1/18/11 4:30 AM, "Jan Seedorf" wrote: >=20 > > P2P folks at IETF, > > > > To help people interested in the P2P-TV workshop we are hosting, > > the NAPA-WINE project's final workshop will be *broadcasted live* > > with the P2P Live Streaming Software developed by the NAPA-WINE project= . > > > > The workshop opens on Thursday 20th January at 2.30PM CET and closes > > on Friday 21th January afternoon at 6.00PM CET. > > Recordings of the workshop will be made available from the project web = site > > few days after the event too. > > > > For people interested in following the workshop/talks live > > via P2P video stream, we have prepared a page with Quick-Start > > instructions on how to download, install, and use the software > > to follow the event live. If you are interested, please go to > > > > http://www.napa-wine.eu/cgi-bin/twiki/view/Public/NapaWineWorkshopLive > > > > If you have any questions regarding the use of the software or followin= g > > the final workshop live with it, please use the mailing list > > (napalive@tlc.polito.it). > > > > A demo activity of the software is scheduled at 5.30PM (and yes! you > > will be part of the demo if you join the channel!) > > > > *Workshop Program* > > The final NAPA-WINE workshop is intended as an informal forum for livel= y > > discussions on current and future trends in peer-to-peer live streaming= . The > > program comprises four talks presenting the main NAPA-WINE achievements= (and > a > > demo of NAPA-WINE's network-aware P2P live streaming system) as well as= nine > > talks from external highly qualified researchers from both academia and > > industry, providing a broad and articulated perspective on the main > challenges > > and solutions on the topic. There will be external presentations provid= ed by > > (see http://www.napa-wine.eu/workshop/program.html for agenda details): > > > > - Presentations from other on-going European projects on P2P-TV/CDN: > > * Future Media Networks (FMN) cluster and ENVISION (David Griffin, UC= L, > GB) > > * COAST/SEA (Emanuele Quacchio, ST Microelectronics, IT) > > * P2P-NEXT (Raul Jimenez, KTH, SE) > > - Presentations from the industrial world (the operator/content provide= r > > vision): > > * Nikolaos Laoutaris, Telefonica Research, ES > > * Enrico Marocco, Chair of IETF ALTO, Telecom Italia, IT > > - Presentations from academia (technical challenges) > > * Ernst Biersack, Eurecom, FR > > * Phuoc Tran-Gia, Tobias Hossfeld, University of Wuerzburg, DE > > * Yong Liu, Polytechnic Institute of NYU, US > > * Victoria Fodor, Gyorgy Dan, KTH, SE > > > > For further workshop program details, please see > > http://www.napa-wine.eu/workshop/ > > > > - Jan > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Jan Seedorf > > Senior Researcher > > NEC Europe Ltd., NEC Laboratories Europe, Network Division > > Kurfuerstenanlage 36, D-69115 Heidelberg > > Tel.=A0=A0=A0=A0 +49 (0)6221 4342-221 > > Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 > > e-mail:=A0 jan.seedorf@neclab.eu > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > NEC Europe Limited Registered Office: NEC House, > > 1 Victoria Road, London W3 6BL Registered in England 2832014 > > > > > > _______________________________________________ > > decade mailing list > > decade@ietf.org > > https://www.ietf.org/mailman/listinfo/decade >=20 From petithug@acm.org Fri Jan 21 10:13:38 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585F428C133 for ; Fri, 21 Jan 2011 10:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.052 X-Spam-Level: X-Spam-Status: No, score=-102.052 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHZq4mYXeq-J for ; Fri, 21 Jan 2011 10:13:37 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 7764228C132 for ; Fri, 21 Jan 2011 10:13:37 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 65E98DDC4092; Fri, 21 Jan 2011 18:16:23 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 12391DDC4090; Fri, 21 Jan 2011 18:16:20 +0000 (UTC) Message-ID: <4D39CD70.5040706@acm.org> Date: Fri, 21 Jan 2011 10:16:16 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Bruce Lowekamp References: <4CEAC54A.2030503@acm.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (2) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 21 Jan 2011 18:13:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/07/2011 02:24 PM, Bruce Lowekamp wrote: > inline > > On Mon, Nov 22, 2010 at 2:32 PM, Marc Petit-Huguenin wrote: > More questions, comments and nits: > > - A.9. In section 5.1.2, 5th paragraph: "As an example of the second strategy, > if node D receives a message from node C with transaction X and via list (A, B), > it could store (X, C) in its state database and forward the message with the via > list unchanged. When D receives the response, it consults its state database > for transaction id X, determines that the request came from C, and forwards the > response to C." > > If I understand correctly this whole paragraph, when a message is forwarded it > keeps the same transaction_id, because if the response received by D was using a > different transaction_id, say Y, it could not retrieve (X, C) from the state > database. Is this analysis correct? > >> A message should always keep the same transaction ID. The paragraph >> is really just trying to point out that you can keep a map of tid -> >> return node for your routing state. In fact this is implied by the fact that the Signature in the SecurityBlock covers transaction_id. Sorry for that. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk05zWUACgkQ9RoMZyVa61eYjwCdFlFuviv2Sd0S0HYyb+rQjtTn d7EAn3M4s+2BrQZ4UYPBewXL3h8Yby54 =eGya -----END PGP SIGNATURE----- From stephane@glycon.org Wed Jan 26 09:29:25 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1703A68D7 for ; Wed, 26 Jan 2011 09:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[AWL=-2.057, BAYES_05=-1.11, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpCREMlkx7PQ for ; Wed, 26 Jan 2011 09:29:24 -0800 (PST) Received: from server.glycon.org (unknown [IPv6:2604:3400:dc1:41:216:3eff:fed5:96f3]) by core3.amsl.com (Postfix) with ESMTP id 72C263A6821 for ; Wed, 26 Jan 2011 09:29:24 -0800 (PST) Received: from [192.168.88.100] (gar13-9-83-156-136-174.fbx.proxad.net [83.156.136.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Stephane Bryant", Issuer "StonyFish Inc." (verified OK)) by server.glycon.org (Postfix) with ESMTPS id 8C17D6515 for ; Wed, 26 Jan 2011 11:32:23 -0600 (CST) Message-ID: <4D405AA5.5060001@glycon.org> Date: Wed, 26 Jan 2011 18:32:21 +0100 From: =?ISO-8859-1?Q?st=E9phane_bryant?= Organization: StonyFish, Inc User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: p2psip@ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] wireshark RELOAD dissector X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jan 2011 17:29:25 -0000 Hello, We submitted a serie of bug fixes and improvements to the wireshark RELOAD dissector in trunk (as bug 5620), which we tested against an implementation developped independantly. We will also soon have a RELOAD plugin available for wireshark's stable version. regards, Stephane Bryant, StonyFish, Inc From Even.roni@huawei.com Sun Jan 30 22:55:40 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 292AF3A6B98 for ; Sun, 30 Jan 2011 22:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.621 X-Spam-Level: X-Spam-Status: No, score=-103.621 tagged_above=-999 required=5 tests=[AWL=0.874, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbYNHNGCDe3F for ; Sun, 30 Jan 2011 22:55:38 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B46703A6B97 for ; Sun, 30 Jan 2011 22:55:37 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFV00GJFKPSFU@szxga03-in.huawei.com> for p2psip@ietf.org; Mon, 31 Jan 2011 14:58:41 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFV006GZKPS0Z@szxga03-in.huawei.com> for p2psip@ietf.org; Mon, 31 Jan 2011 14:58:40 +0800 (CST) Received: from windows8d787f9 ([109.64.31.233]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFV00BBJKPMRX@szxml01-in.huawei.com>; Mon, 31 Jan 2011 14:58:40 +0800 (CST) Date: Mon, 31 Jan 2011 08:54:16 +0200 From: Roni Even In-reply-to: To: 'Bruce Lowekamp' Message-id: <09ea01cbc113$b125e060$1371a120$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=UTF-8 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: Acuuul0kVwV/GEWxTUejY0ABtJ3zogSWQulA References: <026c01cb8952$bf0a06a0$3d1e13e0$%roni@huawei.com> <021a01cbadab$21b4eff0$651ecfd0$%roni@huawei.com> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting - DRR X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 31 Jan 2011 06:55:40 -0000 Hi Bruce, I do not think it is required for every message, just for the case when = the intermediary node keeps state of the message (it is per such a = message). This may be needed due to failures on the route and not only = for DRR support Roni > -----Original Message----- > From: Bruce Lowekamp [mailto:bbl@lowekamp.net] > Sent: Saturday, January 08, 2011 12:30 AM > To: Roni Even > Cc: David A. Bryan; P2PSIP WG > Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft = from > meeting - DRR >=20 > I think requiring the state timeout mechanism to be used for every > message would be a bit much to put on the peers. I would rather > provide the explicit flag. >=20 > Bruce >=20 > On Thu, Jan 6, 2011 at 9:07 AM, Roni Even = wrote: > > Hi Bruce, > > I think that the flag for not keeping state may be useful but there > is also another mechanism which is the time out that tells = intermediate > nodes to discard any state after a timeout. > > Roni > > > >> -----Original Message----- > >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > >> Behalf Of Bruce Lowekamp > >> Sent: Thursday, December 02, 2010 8:54 PM > >> To: David A. Bryan > >> Cc: P2PSIP WG; Roni Even > >> Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft > from > >> meeting - DRR > >> > >> The motivation for putting it into the base draft was that if it is > >> part of the base spec, then in the future nodes that implement > >> whatever is specified in the relay/DRR draft can make use of those > >> techniques while on an overlay with nodes that only implement the > base > >> draft. For example: > >> > >> - any sort of relay/DRR requires intermediate nodes to not keep any > >> state about routed messages. If support for the routing flag that > >> allows this is not in the base draft, they will have to simply > reject > >> the message. > >> - knowledge of how to set up a relay node isn't required to make = use > >> of the relay node. > >> > >> The intention of the current text was that it could currently only > be > >> used with no-ice. But it would provide support so that nodes that > >> only implement the base draft would be able to forward messages > using > >> relay/DRR and would also be able to send messages to a relay node = in > >> the future without knowing the details of how that is set up. As > >> currently specified, it definitely needs some text stating > explicitly > >> that it can currently only be used with no-ice. > >> > >> There's another option where we add a ForwardingOptions flag to the > >> base draft that specifies not to keep state about the message, but > >> isn't explicitly a DRR flag. There might even be a benefit to = doing > >> that, in that it wouldn't be explicitly tied to the DRR mechanism = in > >> there now. > >> > >> Or , of course, we can remove it completely, at the cost that base > >> nodes won't be compatible with whatever is done in the relay/DRR > >> draft. > >> > >> Bruce > >> > >> > >> On Tue, Nov 30, 2010 at 8:03 AM, David A. Bryan > > >> wrote: > >> > I also think the current text is too limiting. The best approach > is > >> to > >> > make it clear in the draft that other routing techniques are > allowed > >> > and supported, leave in the flags but remove the very skeletal > direct > >> > response routing from this draft and we instead do that in the > >> > relay/direct response draft. > >> > > >> > David (as individual) > >> > > >> > On Sun, Nov 21, 2010 at 3:04 AM, Roni Even > >> wrote: > >> >> > >> >>> > >> >>> Direct Response Routing and ICE > >> >>> =E2=80=A2 Specified in =C2=A75.3.2.4 > >> >>> This option can only be used if the direct-return-response- > >> permitted > >> >>> flag in the configuration for the overlay is set to TRUE. The > >> >>> RESPONSE_COPY flag SHOULD be set to false while the > >> FORWARD_CRITICAL > >> >>> and DESTINATION_CRITICAL MUST be set to true. When a node that > >> >>> supports this forwarding options receives a request with it, it > >> acts > >> >>> as if it had send an Attach request to the the requesting_node > and > >> it > >> >>> had received the connection_information in the answer. This > causes > >> it > >> >>> to form a new connection directly to that node. > >> >>> =E2=80=A2 This doesn=E2=80=99t work with ICE because the sender = of the request > >> doesn=E2=80=99t > >> >>> have your information > >> >>> Proposed Resolution: DRR can only be used with No-ICE > >> >>> ***NOTE: This slide generated significant discussion in the > >> meeting. > >> >>> There were some comments that this was incomplete, and > discussion > >> of > >> >>> moving this out of the base draft and into the relay/direct > >> response > >> >>> draft. ADDITIONAL DISCUSSION REQUIRED. > >> >> > >> >> I see the problem and think that we should take this section out > >> from RELOAD and continue with the individual relay draft (draft- > jiang- > >> p2psip-relay-04) for the use case where the node is not behind NAT > or a > >> relay can be used. > >> >> In this case we will need to verify that RELOAD allows such > >> extensions and that there are no issues with supporting it due to > some > >> routing assumptions. > >> >> > >> >> Roni Even > >> >> > >> >> > >> >> > >> >> > >> > _______________________________________________ > >> > P2PSIP mailing list > >> > P2PSIP@ietf.org > >> > https://www.ietf.org/mailman/listinfo/p2psip > >> > > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www.ietf.org/mailman/listinfo/p2psip > > > > From petithug@acm.org Mon Jan 31 07:35:47 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87EF93A6A93 for ; Mon, 31 Jan 2011 07:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.331 X-Spam-Level: X-Spam-Status: No, score=-101.331 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+Jx1EW7ueQz for ; Mon, 31 Jan 2011 07:35:46 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 8F3CD3A6A7F for ; Mon, 31 Jan 2011 07:35:46 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 5636ADFC4010; Mon, 31 Jan 2011 15:39:00 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 28364DFC400E; Mon, 31 Jan 2011 15:38:59 +0000 (UTC) Message-ID: <4D46D792.1020901@acm.org> Date: Mon, 31 Jan 2011 07:38:58 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: p2psip@ietf.org References: <4D405AA5.5060001@glycon.org> In-Reply-To: <4D405AA5.5060001@glycon.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: =?UTF-8?B?c3TDqXBoYW5lIGJyeWFudA==?= Subject: Re: [P2PSIP] wireshark RELOAD dissector X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 31 Jan 2011 15:35:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/26/2011 09:32 AM, stéphane bryant wrote: > Hello, > > We submitted a serie of bug fixes and improvements to the > wireshark RELOAD dissector in trunk (as bug 5620), which > we tested against an implementation developped independantly. > We will also soon have a RELOAD plugin available for wireshark's > stable version. As promised, we released a Debian/Ubuntu package for the RELOAD Wireshark plugin. This plugin can be used in current versions of Wireshark starting with 1.2.7, and we hope that this will make this dissector - and RELOAD development - more accessible: http://stonyfish.com/foss/2011/1/30/wireshark-dissector-for-reload.html The source code is available at the same place and we will be happy to see people releasing builds for Windows and MacOS. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1G148ACgkQ9RoMZyVa61eZDgCgkvn2Xedd1g+w5w7BXb+7OClW daoAoJ8pVn8av1Og02f63A9sgmItlyQ3 =0WEr -----END PGP SIGNATURE-----