From roland.bless@kit.edu Wed Dec 21 09:32:41 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F3B1F0C55 for ; Wed, 21 Dec 2011 09:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-MhTUfd4r0A for ; Wed, 21 Dec 2011 09:32:38 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA9F1F0C51 for ; Wed, 21 Dec 2011 09:32:31 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1RdQ1g-0000ur-Uw for ; Wed, 21 Dec 2011 18:32:30 +0100 Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 for id 1RdQ1g-0007Hj-Q2; Wed, 21 Dec 2011 18:32:24 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 9BD5AA80549 for ; Wed, 21 Dec 2011 18:32:24 +0100 (CET) Message-ID: <4EF21828.8060602@kit.edu> Date: Wed, 21 Dec 2011 18:32:24 +0100 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: P2PSIP@ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1324488750.254099000 Subject: [P2PSIP] draft-ietf-p2psip-base-19: fragment bits issue X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 21 Dec 2011 17:32:41 -0000 Hi, a student (Andr=E9 Becker) at our institute discovered some inconsistencies with the proposed fragmentation while implementing RELOAD, which he has started to work on recently. Issue: 5.3.2 and 5.7 are inconsistent and confusing with respect to the fragment bit definition. Sec. 5.3.2: fragment: This field is used to handle fragmentation. The high order two bits are used to indicate the fragmentation status: If the high bit (0x80000000) is set, it indicates that the message is a fragment. If the next bit (0x40000000) is set, it indicates that this is the last fragment. The next six bits (0x20000000 to 0x01000000) are reserved and SHOULD be set to zero. The remainder of the field is used to indicate the fragment offset; see Section 5.7 I read this as: - if the message is a fragment then the high bit is set. - if the message is the last fragment, then the next bit is set. (BTW: It is not clear to me why there is only a "SHOULD be set to zero" for the Reserved bits instead of a MUST.) And Section 5.7 states: If the message is not fragmented, then both the first and last fragment bits are set to 1 and the offset is 0 resulting in a fragment value of 0xC0000000. Note that this means that the first fragment bit is always 1, so isn't actually that useful. Issues: - there are no official names defined in 5.3.2 that are called "first fragment" and "last fragment" bits. The high bit of 5.3.2 indicates that the message is a fragment, not only the first fragment. - according to 5.3.2, it is perfectly ok to set both bits for the last fragment, since the high bit should be set because it's a fragment and the next bit should be set to indicate that it is the last fragment. - the last sentence is a somewhat weird statement Proposal: - change 5.3.2 to a clearer definition of the bits - fix the description in 5.7 as follows: sec 5.3.2: fragment: This field is used to handle fragmentation. The high order two bits are used to indicate the fragmentation status: If the message is a fragment the high bit ("fragment bit") (0x80000000) MUST be set, as it indicates that the message is a fragment. If the message is the last fragment the next bit ("last fragment") (0x40000000) MUST be set in addition to the high bit, otherwise it MUST be set to zero. The next six bits (0x20000000 to 0x01000000) are reserved and MUST be set to zero, their contents MUST be ignored on reception. The remaining 24 bits of the field are used to indicate the fragment offset; see Section 5.7 So if the message is a fragment, the high bit will always be set, and the last bit will be additionally set to indicate "last fragment". The combination high bit zero and last fragment is not allowed (protocol error). Is there a need to report an error message back in this case? Proposed changed text for Section 5.7: Old: The first fragment therefore has an offset of 0. The first and last bit indicators MUST be appropriately set. If the message is not fragmented, then both the first and last fragment bits are set to 1 and the offset is 0 resulting in a fragment value of 0xC0000000. Note that this means that the first fragment bit is always 1, so isn't actually that useful. New: The first fragment therefore has an offset of zero. The fragment and last fragment bit indicators MUST be appropriately set. If the message is not fragmented, then both the first and last fragment bits are set to zero and the offset MUST be set to zero. Regards, Roland From petithug@acm.org Wed Dec 21 09:54:12 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488B211E80AD for ; Wed, 21 Dec 2011 09:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.15 X-Spam-Level: X-Spam-Status: No, score=-102.15 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKK+RCQv5OBp for ; Wed, 21 Dec 2011 09:54:11 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE1211E8073 for ; Wed, 21 Dec 2011 09:54:11 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 77E2720198; Wed, 21 Dec 2011 17:42:07 +0000 (UTC) Message-ID: <4EF21D3E.1000309@acm.org> Date: Wed, 21 Dec 2011 09:54:06 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16 MIME-Version: 1.0 To: Roland Bless References: <4EF21828.8060602@kit.edu> In-Reply-To: <4EF21828.8060602@kit.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: P2PSIP@ietf.org Subject: Re: [P2PSIP] draft-ietf-p2psip-base-19: fragment bits issue X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 21 Dec 2011 17:54:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Roland, You may consider subscribing to the RELOAD implementers mailing-list: http://implementers.org/mailman/listinfo/reload One comment below. On 12/21/2011 09:32 AM, Roland Bless wrote: > Hi, > > a student (André Becker) at our institute discovered > some inconsistencies with the proposed fragmentation > while implementing RELOAD, which he has started to work > on recently. > > Issue: 5.3.2 and 5.7 are inconsistent and confusing > with respect to the fragment bit definition. > > Sec. 5.3.2: > fragment: This field is used to handle fragmentation. The high > order two bits are used to indicate the fragmentation status: If > the high bit (0x80000000) is set, it indicates that the message is > a fragment. If the next bit (0x40000000) is set, it indicates > that this is the last fragment. The next six bits (0x20000000 to > 0x01000000) are reserved and SHOULD be set to zero. The remainder > of the field is used to indicate the fragment offset; see > Section 5.7 > > I read this as: > - if the message is a fragment then the high bit is set. > - if the message is the last fragment, then the next bit is set. > > (BTW: It is not clear to me why there is only a "SHOULD be set to zero" > for the Reserved bits instead of a MUST.) > > And Section 5.7 states: > If the message is not fragmented, then both the > first and last fragment bits are set to 1 and the offset is 0 > resulting in a fragment value of 0xC0000000. Note that this means > that the first fragment bit is always 1, so isn't actually that > useful. > > Issues: > - there are no official names defined in 5.3.2 that are called > "first fragment" and "last fragment" bits. The high bit of > 5.3.2 indicates that the message is a fragment, not only the first > fragment. > - according to 5.3.2, it is perfectly ok to set both bits > for the last fragment, since the high bit should be set because > it's a fragment and the next bit should be set to indicate that > it is the last fragment. > - the last sentence is a somewhat weird statement For reference, here's the email exchange for this text (search for "A.20"): http://www.ietf.org/mail-archive/web/p2psip/current/msg05801.html > > Proposal: > - change 5.3.2 to a clearer definition of the bits > - fix the description in 5.7 > as follows: > > sec 5.3.2: > fragment: This field is used to handle fragmentation. The high > order two bits are used to indicate the fragmentation status: > If the message is a fragment the high bit ("fragment bit") > (0x80000000) MUST be set, as it indicates that the message is a > fragment. If the message is the last fragment the next bit ("last > fragment") (0x40000000) MUST be set in addition to the high bit, > otherwise it MUST be set to zero. The next six bits (0x20000000 to > 0x01000000) are reserved and MUST be set to zero, their contents > MUST be ignored on reception. The remaining 24 bits of the field > are used to indicate the fragment offset; see Section 5.7 > > So if the message is a fragment, the high bit will always be set, > and the last bit will be additionally set to indicate "last fragment". > The combination high bit zero and last fragment is not allowed > (protocol error). Is there a need to report an error message back in > this case? > > Proposed changed text for Section 5.7: > Old: > The first fragment therefore has > an offset of 0. The first and last bit indicators MUST be > appropriately set. If the message is not fragmented, then both the > first and last fragment bits are set to 1 and the offset is 0 > resulting in a fragment value of 0xC0000000. Note that this means > that the first fragment bit is always 1, so isn't actually that > useful. > > > New: > The first fragment therefore has an offset of zero. > The fragment and last fragment bit indicators MUST be appropriately > set. If the message is not fragmented, then both the first and last > fragment bits are set to zero and the offset MUST be set to zero. - -- 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.11 (GNU/Linux) iQIcBAEBCAAGBQJO8h05AAoJECnERZXWan7EpTUQAImGv5w+TW/7eO7RMipW2k85 qDEJ8svDs/ASDjR/ITTHIW/oIjWRDZpCo66yaqaQs/5iYe/O90dN2fgmqtB3Yjrv ug3orfwuvrHrgy8W6+cCw+7X5bKyEb49qqRW1x6lkGwzc06+D/K4tkM6Jne/qU9B BqJiDJHDy2K1LPGVO+VB+Lqig83CJWejlaT+iHGiSlVBjc72zwu374ZSvJK7PHDy Rmiu0Ph0UYD3jnk/MouCqAUTdpi8orV8pNwmxynDG4TxwjkvKTDlLhJTKE42LHH6 d7y4sF5hlsdU7R8L2zLY48263lE0FMp839ynmj7oQnaTJKMnkZaM1Uo49QW3Ml25 knGUnUQ/tj9r2NgIYtme1bWoDanPT6F09bYsppF9hcIofZ4tK+9hY2H+b8pU39dm GRFMFmrFaWf5eeya/GRghpHCFcjOnflPqCv5ECquFLGCodvznNdgXv84Z2EV97WJ L9wxgOJlGCBaF3OmX/Z3RT/GRRF5+CRGIx5NwT4EsyBa1vJy8l5W9dl8nZQ63mOK bALklfNdnMwP8w1OmkENWfX0q4biF6scjxFxpB/77ngYivpyIDx1ZqvWpL+Tfw6B WHAvgXSlDrGKgJ+YDJy4jC7wZNVq9Oep58lfKhV17TWbwBg4mLsSZKmMTFWi8LMI RlDIk095nus1JyMFnlCK =qQxC -----END PGP SIGNATURE----- From roland.bless@kit.edu Wed Dec 21 13:20:53 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62AA1F0C52 for ; Wed, 21 Dec 2011 13:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKwjzteozJJD for ; Wed, 21 Dec 2011 13:20:53 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id D2BA41F0C4D for ; Wed, 21 Dec 2011 13:20:51 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1RdTae-0000QZ-EP; Wed, 21 Dec 2011 22:20:50 +0100 Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 id 1RdTae-0004EQ-AG; Wed, 21 Dec 2011 22:20:44 +0100 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 02583A80552; Wed, 21 Dec 2011 22:20:43 +0100 (CET) Message-ID: <4EF24DAB.8010703@kit.edu> Date: Wed, 21 Dec 2011 22:20:43 +0100 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <4EF21828.8060602@kit.edu> <4EF21D3E.1000309@acm.org> In-Reply-To: <4EF21D3E.1000309@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1324502450.460448000 Cc: P2PSIP@ietf.org Subject: Re: [P2PSIP] draft-ietf-p2psip-base-19: fragment bits issue X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 21 Dec 2011 21:20:53 -0000 On 21.12.2011 18:54, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi Roland, > > You may consider subscribing to the RELOAD implementers mailing-list: > > http://implementers.org/mailman/listinfo/reload > > One comment below. >> And Section 5.7 states: >> If the message is not fragmented, then both the >> first and last fragment bits are set to 1 and the offset is 0 >> resulting in a fragment value of 0xC0000000. Note that this means >> that the first fragment bit is always 1, so isn't actually that >> useful. >> - the last sentence is a somewhat weird statement > > For reference, here's the email exchange for this text (search for "A.20"): > > http://www.ietf.org/mail-archive/web/p2psip/current/msg05801.html Thanks for the pointer, but its doesn't make it more reasonable. IMHO it just provides a hint that something is broken: if it is always set to 1, it doesn't provide any useful information, so you could simply leave it out. Not sure how it was actually meant to be used, but if it was indicating "first fragment" then it is set for the first fragment and for non-fragmented packets together with the last fragment bit. For all intermediate fragments it probably had to be set to zero, so then it would have changed. I think that my proposed definition is less confusing to implementers and protocol debugging people. Regards, Roland From petithug@acm.org Wed Dec 21 13:45:36 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB1B21F8B08 for ; Wed, 21 Dec 2011 13:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.24 X-Spam-Level: X-Spam-Status: No, score=-102.24 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InMt3spPsktP for ; Wed, 21 Dec 2011 13:45:35 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 95BE421F8B06 for ; Wed, 21 Dec 2011 13:45:35 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id D3A7820198; Wed, 21 Dec 2011 21:33:31 +0000 (UTC) Message-ID: <4EF2537B.8060503@acm.org> Date: Wed, 21 Dec 2011 13:45:31 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16 MIME-Version: 1.0 To: Roland Bless References: <4EF21828.8060602@kit.edu> <4EF21D3E.1000309@acm.org> <4EF24DAB.8010703@kit.edu> In-Reply-To: <4EF24DAB.8010703@kit.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP@ietf.org Subject: Re: [P2PSIP] draft-ietf-p2psip-base-19: fragment bits issue X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 21 Dec 2011 21:45:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/21/2011 01:20 PM, Roland Bless wrote: > On 21.12.2011 18:54, Marc Petit-Huguenin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Hi Roland, >> >> You may consider subscribing to the RELOAD implementers mailing-list: >> >> http://implementers.org/mailman/listinfo/reload >> >> One comment below. > >>> And Section 5.7 states: >>> If the message is not fragmented, then both the >>> first and last fragment bits are set to 1 and the offset is 0 >>> resulting in a fragment value of 0xC0000000. Note that this means >>> that the first fragment bit is always 1, so isn't actually that >>> useful. >>> - the last sentence is a somewhat weird statement >> >> For reference, here's the email exchange for this text (search for "A.20"): >> >> http://www.ietf.org/mail-archive/web/p2psip/current/msg05801.html > > Thanks for the pointer, but its doesn't make it more reasonable. > IMHO it just provides a hint that something is broken: if it is > always set to 1, it doesn't provide any useful information, so > you could simply leave it out. Not sure how it was actually meant > to be used, but if it was indicating "first fragment" then it is > set for the first fragment and for non-fragmented packets together > with the last fragment bit. For all intermediate fragments it > probably had to be set to zero, so then it would have changed. > I think that my proposed definition is less confusing to > implementers and protocol debugging people. Well, I agree with you, but for all intent and purpose, the protocol is currently frozen. The authors rejected all suggestions of modifications that change the wire protocol for the last year or so. They seems to not realize that the longer they wait to publish it, the more likely it will be that people will find things to fix in it and so will delay the publication even further. The last WG meeting in Taipei was very disappointing - to say the least - with very little progress made and I expect that it will be the same in Paris. - -- 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.11 (GNU/Linux) iQIcBAEBCAAGBQJO8lNtAAoJECnERZXWan7E5KQP/iOAjTGpH82Zee6zkIzvvBMc 8UfBOlre3ELVnCZwdXxMO10FYIugZa7wDCwQERiRtKoYzc79dmC6/J6ivnmX9M7U C9fkjSpTJAZnBMWL4vGgXnnklF2FWScXQRzl09rHx6OnljSkuhybmMbU/OjkaIdG MBJ8F1kd7hBTfVffG0dMAsJC+nkVeTG3QVcYypiVMzSlHXi+oPu1xz3MLdZG+9Ur bGcfgZjVzP54VvPtMibFk9/VyuY9XiibSqJvwwl59SJN7sl03cCkWUL5yneH22rI DgQgI6qsbQEwwXUUxJcey1DHsEVlKLxcTlj85uEt5LQBBOOadIDLVye8T4F400DZ 8Y79AvpRowQpUPcT1LYTXs5hXN+XsiY0kKzJk6m8scSovE+ZB3C+0ZO+pok7M8yQ bMag+2Pyb3ksXbMU7ePkYpZO8iTvILQgWYlJ9ScMV9r3FW1rmi3HoW5jFkYINAVv Ud50eu1izUt7H4O11oboU/8E20mqet+Zjj78LD/3abCz6TTFM9XQrKxU8rSpwbSg +SYOoP+meFyQdyDxAY9q47qztUsfI0O/FJB/hy+BsEp7UYixwhTgmYx0aVLtSOP4 8ejXmriWaETDjxjY2f49bpONwDg93BhKIFwd9c3hRynmKSbqXfv6Q0jBWbD5kPfR HrfvCPlXNyDlljX0U5If =WtNI -----END PGP SIGNATURE----- From michaelc@IDSSOFTWARE.COM Thu Dec 22 16:33:28 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F41A21F84BB for ; Thu, 22 Dec 2011 16:33:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKqyltufLpC0 for ; Thu, 22 Dec 2011 16:33:27 -0800 (PST) Received: from smtpoutwbe07.prod.mesa1.secureserver.net (smtpoutwbe07.prod.mesa1.secureserver.net [208.109.78.209]) by ietfa.amsl.com (Postfix) with SMTP id B845C21F84B9 for ; Thu, 22 Dec 2011 16:33:27 -0800 (PST) Received: (qmail 9195 invoked from network); 23 Dec 2011 00:33:27 -0000 Received: from unknown (HELO localhost) (72.167.218.135) by smtpoutwbe07.prod.mesa1.secureserver.net with SMTP; 23 Dec 2011 00:33:25 -0000 Received: (qmail 6890 invoked by uid 99); 23 Dec 2011 00:33:25 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 218.19.229.226 User-Agent: Web-Based Email 5.6.09 Message-Id: <20111222173324.61e8c06078a3b23a733c71e914c0b9df.2fe5e9d808.wbe@email03.secureserver.net> From: "Michael Chen" To: "Roland Bless" Date: Thu, 22 Dec 2011 17:33:24 -0700 Mime-Version: 1.0 Cc: P2PSIP@ietf.org Subject: Re: [P2PSIP] draft-ietf-p2psip-base-19: fragment bits issue X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 00:33:29 -0000 Roland,=0A=0AI believe the fragment bits design is fine as it is, but the l= anguage=0Acould be clarified or further restricted. Having the high bit 0x8= 0000000=0Aconsistently set for all fragments (first, middle, last) makes mo= re=0Asense than any other alternatives.=0A=0AThere are certainly some overl= apped definitions here, for example,=0A0xC0000000 and 0x00000000 can both i= ndicate a non-fragmented message.=0AHowever, if you only adhere to the defi= nitions of 0x80000000, 0x40000000=0Aand the low 24 bits, it works just fine= . Consider these 3 definitions=0Asupersede all other combinations and speci= al cases.=0A=0AThanks=0A=0A--Michael=0A=0A> -------- Original Message -----= ---=0A> Subject: Re: [P2PSIP] draft-ietf-p2psip-base-19: fragment bits issu= e=0A> From: Roland Bless =0A> Date: Wed, December 21,= 2011 1:20 pm=0A> To: Marc Petit-Huguenin =0A> Cc: P2PSIP= @ietf.org=0A> =0A> =0A> On 21.12.2011 18:54, Marc Petit-Huguenin wrote:=0A>= > -----BEGIN PGP SIGNED MESSAGE-----=0A> > Hash: SHA256=0A> >=0A> > Hi Rol= and,=0A> >=0A> > You may consider subscribing to the RELOAD implementers ma= iling-list:=0A> >=0A> > http://implementers.org/mailman/listinfo/reload=0A>= >=0A> > One comment below.=0A> =0A> >> And Section 5.7 states:=0A> >> = If the message is not fragmented, then both the=0A> >> first and last f= ragment bits are set to 1 and the offset is 0=0A> >> resulting in a fra= gment value of 0xC0000000. Note that this means=0A> >> that the first = fragment bit is always 1, so isn't actually that=0A> >> useful.=0A> >> = - the last sentence is a somewhat weird statement=0A> >=0A> > For reference= , here's the email exchange for this text (search for "A.20"):=0A> >=0A> > = http://www.ietf.org/mail-archive/web/p2psip/current/msg05801.html=0A> =0A> = Thanks for the pointer, but its doesn't make it more reasonable.=0A> IMHO i= t just provides a hint that something is broken: if it is=0A> always set to= 1, it doesn't provide any useful information, so=0A> you could simply leav= e it out. Not sure how it was actually meant=0A> to be used, but if it was = indicating "first fragment" then it is=0A> set for the first fragment and f= or non-fragmented packets together=0A> with the last fragment bit. For all = intermediate fragments it=0A> probably had to be set to zero, so then it wo= uld have changed.=0A> I think that my proposed definition is less confusing= to=0A> implementers and protocol debugging people.=0A> =0A> Regards,=0A> = Roland=0A> =0A> _______________________________________________=0A> P2PSIP= mailing list=0A> P2PSIP@ietf.org=0A> https://www.ietf.org/mailman/listinfo= /p2psip=0A From internet-drafts@ietf.org Wed Dec 28 01:41:54 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B21A21F8AD8; Wed, 28 Dec 2011 01:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIfX40ctt1lt; Wed, 28 Dec 2011 01:41:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AAE21F8ABC; Wed, 28 Dec 2011 01:41:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111228094153.22080.42489.idtracker@ietfa.amsl.com> Date: Wed, 28 Dec 2011 01:41:53 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-07.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 09:41:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Proto= col Working Group of the IETF. Title : P2PSIP Overlay Diagnostics Author(s) : Song Haibin Jiang Xingfeng Roni Even David A. Bryan Filename : draft-ietf-p2psip-diagnostics-07.txt Pages : 30 Date : 2011-12-28 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-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-diagnostics-07.txt From haibin.song@huawei.com Wed Dec 28 01:47:03 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C4321F849B for ; Wed, 28 Dec 2011 01:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAY7UX4Av6qA for ; Wed, 28 Dec 2011 01:47:03 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6D76821F8AF3 for ; Wed, 28 Dec 2011 01:47:02 -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 <0LWW00674R3DRE@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 28 Dec 2011 17:45:14 +0800 (CST) Received: from szxrg02-dlp.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 <0LWW006M1R2912@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 28 Dec 2011 17:45:13 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFZ37145; Wed, 28 Dec 2011 17:45:13 +0800 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Dec 2011 17:45:08 +0800 Received: from SZXEML534-MBS.china.huawei.com ([169.254.6.210]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Wed, 28 Dec 2011 17:45:09 +0800 Date: Wed, 28 Dec 2011 09:45:09 +0000 From: Songhaibin X-Originating-IP: [10.138.41.129] To: P2PSIP Mailing List Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: New Version Notification for draft-ietf-p2psip-diagnostics-07.txt Thread-index: AQHMxUT3mZ9DpEctOkG5EujCM6xb+5Xw/6Dg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [P2PSIP] FW: New Version Notification for draft-ietf-p2psip-diagnostics-07.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 09:47:03 -0000 Hi all, The diagnostics draft has been updated. The major comments from Marc was solved. Any comments are welcome. BR, -Haibin > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, December 28, 2011 5:42 PM > To: Songhaibin > Cc: dbryan@ethernot.org; Songhaibin; Johnson Jiang(Xingfeng); Roni even > Subject: New Version Notification for draft-ietf-p2psip-diagnostics-07.txt > > A new version of I-D, draft-ietf-p2psip-diagnostics-07.txt has been successfully > submitted by Haibin Song and posted to the IETF repository. > > Filename: draft-ietf-p2psip-diagnostics > Revision: 07 > Title: P2PSIP Overlay Diagnostics > Creation date: 2011-12-28 > WG ID: p2psip > Number of pages: 30 > > Abstract: > 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. > > > > > The IETF Secretariat From petithug@acm.org Wed Dec 28 08:33:44 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DA521F893C for ; Wed, 28 Dec 2011 08:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKk79-oxIIMC for ; Wed, 28 Dec 2011 08:33:44 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id C645A21F849B for ; Wed, 28 Dec 2011 08:33:43 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 8B14C20198; Wed, 28 Dec 2011 16:21:13 +0000 (UTC) Message-ID: <4EFB44E3.2030905@acm.org> Date: Wed, 28 Dec 2011 08:33:39 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16 MIME-Version: 1.0 To: Songhaibin References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] FW: New Version Notification for draft-ietf-p2psip-diagnostics-07.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 16:33:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Thanks for the new version. I updated the Wireshark dissector accordingly, please see my post in the RELOAD implementers mailing-list: http://implementers.org/archives/reload/2011-December/000019.html Note that there is still some of my previous comments that are not addressed in this new version: 1. } DiagnosticExtension ";" is missing at the end 2. DescriptionExtension The definition of DiagnosticExtension is still not compatible with the data description language ("<>" and "case > 0"). One definition that is bit compatible is this: struct { uint64 expiration; uint64 timestamp_initiated; uint32 length; uint64 dMFlags; DiagnosticExtension diagnostic_extensions[length]; } DiagnosticsRequest; Another definition that is simpler but not bit-compatible: struct { uint64 expiration; uint64 timestamp_initiated; uint64 dMFlags; DiagnosticExtension diagnostic_extensions<0..2^32-1>; } DiagnosticsRequest; Nits (old and new): - ---- - - Section 1 s/compliment/complement/ - - Section 3 s/from the overlay ./from the overlay./ - - Section 4.1 s/the RELOAD ping/the RELOAD Ping/ - - Section 4.3 s/-- one/- one/ - - Section 5.1 s/are defined. DiagnosticRequest/are defined, DiagnosticRequest/ - - Section 5.1.1 s/inSection 9.6/in Section 9.6/ - - Section 5.1.2 s/Section 5.1.1Paragraph 5/Section 5.1.1 Paragraph 5/ - - Section 5.1.3 s/ox00/0x00/ s/ox0F/0x0F/ - - Section 5.3 s/New Reqeust/New Request/ - - Section 5.5.1, first paragraph s/Ping message or with/Ping message with/ On 12/28/2011 01:45 AM, Songhaibin wrote: > Hi all, > > The diagnostics draft has been updated. The major comments from Marc was solved. Any comments are welcome. > > BR, > -Haibin > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, December 28, 2011 5:42 PM >> To: Songhaibin >> Cc: dbryan@ethernot.org; Songhaibin; Johnson Jiang(Xingfeng); Roni even >> Subject: New Version Notification for draft-ietf-p2psip-diagnostics-07.txt >> >> A new version of I-D, draft-ietf-p2psip-diagnostics-07.txt has been successfully >> submitted by Haibin Song and posted to the IETF repository. >> >> Filename: draft-ietf-p2psip-diagnostics >> Revision: 07 >> Title: P2PSIP Overlay Diagnostics >> Creation date: 2011-12-28 >> WG ID: p2psip >> Number of pages: 30 >> >> Abstract: >> 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. >> - -- 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.11 (GNU/Linux) iQIcBAEBCAAGBQJO+0TfAAoJECnERZXWan7EaWgQAJ0Rtdwr/s8Bst8l55/wlegh lXjky7sn5WNKMQqNqzQBfdFo7culD1FelzAvRFELTe+HSpdW0i8sHW22GKvH6x7s 7i4NVNyTK9gZPqIsZPsM1GclPt+Wr+L3XvyLbsmbF40ZmVdldpPA4l9qmnYJaIJX wEJYG9uQi3q3Avn1B7ZZxLQEcJJGVx/Y5zrzy3+H4jexK247zUEbLJF8gTsk7OKd v9ni06C5OXD25Wmb/Jbd/EEcpXgkWBoHAgXlQD+TqXoTIIkJW/1xLdIASVrkbSsf FRH/aGWLbAhQqdahkQhydPUvytaq4wZ/F8z5z0tPYyH1wjsoAAxcsxCsd4Z8dmeg W9L5GUwYr/Jc4b27mIw5RSnXa7yndfGhCH+Aav28che8bMJoaTuAbVB1ZrPMGoRM XHtFpYuKxVDvYo+XL2WFlssXluQ9j6vxE6ac3wNVvVg2JbZ4ZLkznA+8Si72JUiC plkMbc1GK1lw8KfZ6cEtISPT4ef3xaKPy9zuq8MGOhlMg6YoTG5jOF0AM1WN1zAj WRQy2O8RC13c8eoVdnFXawNyJjoWWuvi41sXNs5tDJO1FFdrlB0a9EqWZTog6X9j 1WZGsFC2fCOn+tUkq1ovCWrG1NlqJC7WJCaxYT0op8UVgUkgrcTHDNkQ7wu67Mid hfKYxtysHObkokc4vHdN =cg0Z -----END PGP SIGNATURE----- From internet-drafts@ietf.org Wed Dec 28 17:53:38 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C51D21F84AC; Wed, 28 Dec 2011 17:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XcFnyjooaLZ; Wed, 28 Dec 2011 17:53:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3973221F845A; Wed, 28 Dec 2011 17:53:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111229015338.1253.35894.idtracker@ietfa.amsl.com> Date: Wed, 28 Dec 2011 17:53:38 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-08.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 01:53:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Proto= col Working Group of the IETF. Title : P2PSIP Overlay Diagnostics Author(s) : Song Haibin Jiang Xingfeng Roni Even David A. Bryan Filename : draft-ietf-p2psip-diagnostics-08.txt Pages : 29 Date : 2011-12-28 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-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-diagnostics-08.txt From haibin.song@huawei.com Wed Dec 28 17:57:37 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD47021F84B5 for ; Wed, 28 Dec 2011 17:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZOiMhciMje5 for ; Wed, 28 Dec 2011 17:57:37 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id C867921F8492 for ; Wed, 28 Dec 2011 17:57:36 -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 <0LWY00F3403Y6G@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 29 Dec 2011 09:57:34 +0800 (CST) Received: from szxrg01-dlp.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 <0LWY00B9103YKL@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 29 Dec 2011 09:57:34 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGB86112; Thu, 29 Dec 2011 09:57:34 +0800 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Dec 2011 09:57:28 +0800 Received: from SZXEML534-MBS.china.huawei.com ([169.254.6.210]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Thu, 29 Dec 2011 09:57:30 +0800 Date: Thu, 29 Dec 2011 01:57:30 +0000 From: Songhaibin In-reply-to: <20111229015338.1253.35894.idtracker@ietfa.amsl.com> X-Originating-IP: [10.138.41.129] To: "p2psip@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-08.txt Thread-index: AQHMxczbwcGO6SnuF0m3cvFx40pOkZXyDivg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20111229015338.1253.35894.idtracker@ietfa.amsl.com> Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-08.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 01:57:37 -0000 The draft has been updated. Any comments are welcome. BR, -Haibin > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Thursday, December 29, 2011 9:54 AM > To: i-d-announce@ietf.org > Cc: p2psip@ietf.org > Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-08.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working > Group of the IETF. > > Title : P2PSIP Overlay Diagnostics > Author(s) : Song Haibin > Jiang Xingfeng > Roni Even > David A. Bryan > Filename : draft-ietf-p2psip-diagnostics-08.txt > Pages : 29 > Date : 2011-12-28 > > 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-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-diagnostics-08.txt > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Thu Dec 29 07:18:55 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C94521F87FA for ; Thu, 29 Dec 2011 07:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.343 X-Spam-Level: X-Spam-Status: No, score=-102.343 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-N9gyC-0mE0 for ; Thu, 29 Dec 2011 07:18:54 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA6B21F8545 for ; Thu, 29 Dec 2011 07:18:53 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 1EAEA202D2; Thu, 29 Dec 2011 15:06:19 +0000 (UTC) Message-ID: <4EFC84D9.5020109@acm.org> Date: Thu, 29 Dec 2011 07:18:49 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16 MIME-Version: 1.0 To: Songhaibin References: <20111229015338.1253.35894.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-08.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 15:18:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, This version takes care of all my comments, but you accidentally removed the dMFlags field from DiagnosticsRequest. Thanks. On 12/28/2011 05:57 PM, Songhaibin wrote: > The draft has been updated. Any comments are welcome. > > BR, > -Haibin > >> -----Original Message----- >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Thursday, December 29, 2011 9:54 AM >> To: i-d-announce@ietf.org >> Cc: p2psip@ietf.org >> Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-08.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working >> Group of the IETF. >> >> Title : P2PSIP Overlay Diagnostics >> Author(s) : Song Haibin >> Jiang Xingfeng >> Roni Even >> David A. Bryan >> Filename : draft-ietf-p2psip-diagnostics-08.txt >> Pages : 29 >> Date : 2011-12-28 >> >> 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-08.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-diagnostics-08.txt >> - -- 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.11 (GNU/Linux) iQIcBAEBCAAGBQJO/ITXAAoJECnERZXWan7EyQ4P/RR1nDKGVV6PwNQ3Z9K7HNXb maTDdMo8lyR6epxjCeud1mwZ5Sw1WSFGlm+x2fV+6cu1yZORGg2JCNu98z0Im7wC Swiq874vah517wXTJ5CKJwHHZMNdE9F2X78kBp74fOGbpZfkDIAOyYhffanAouTy KmNawLusoLBd1cYap8yh9PuKgWYEG47oMOvn8sgFrzkCK89S1b/S5TVuiVwJl8AX tUxrkS35NMLdeh8kB0deLJw3RS7A28kR31nh2TrRjGE0s+u+4XCEdkmpQHC54k5C ck+KJ7oT9saEVlCw+fn7sotlnqd5tNLzq21jwlPv/sdoZy/Oup4PQDw3uH6AGpEq 5t6wpiSCjJQgMKP8nPu8aY7Nyb6zjwfAJIdrYVw8b8VfgbahOnrAfkA9ysBhwQPC xkwT3n6V9mAc+0fTnhoVcs4ChA0ni6VtQCaC/CUTV8lTWvYXXa3BUFfpEQqEEAEK ohiMzGlKPXkMz93Iz4DylUgO14U8nNjdGVMVJyGu5mVewAUYmLyIJGQox2xExKmJ ZhOp6WbAOYnG25R4cuRKrPft7TgNDjuVBYOd6/TynooPIpBAisB80S1KSO10tf7i hqPeWj/xrNu7zSDLvPxr6/b6gw9ryhjXM6iF2kESVVUt09el2WjnjIG3uy2RmlRw uV05PsuZelKpTxW0EPJw =b27Z -----END PGP SIGNATURE----- From haibin.song@huawei.com Thu Dec 29 17:08:12 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84E721F8BEC for ; Thu, 29 Dec 2011 17:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMWE6dmazgUY for ; Thu, 29 Dec 2011 17:08:12 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id DE34221F8BDE for ; Thu, 29 Dec 2011 17:08:11 -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 <0LWZ00EECSHC0U@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 30 Dec 2011 09:08:00 +0800 (CST) Received: from szxrg02-dlp.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 <0LWZ005J3SHBKA@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 30 Dec 2011 09:07:59 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGA15230; Fri, 30 Dec 2011 09:07:47 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Dec 2011 09:07:40 +0800 Received: from SZXEML534-MBS.china.huawei.com ([169.254.6.210]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Fri, 30 Dec 2011 09:07:46 +0800 Date: Fri, 30 Dec 2011 01:07:45 +0000 From: Songhaibin In-reply-to: <4EFC84D9.5020109@acm.org> X-Originating-IP: [10.138.41.129] To: Marc Petit-Huguenin Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-08.txt Thread-index: AQHMxczbwcGO6SnuF0m3cvFx40pOkZXyDivggABac4CAASo38A== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20111229015338.1253.35894.idtracker@ietfa.amsl.com> <4EFC84D9.5020109@acm.org> Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-08.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 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, 30 Dec 2011 01:08:13 -0000 Hi Marc, Thanks for pointing out:) It will be addressed in the next version. BR, -Haibin > -----Original Message----- > From: Marc Petit-Huguenin [mailto:petithug@acm.org] > Sent: Thursday, December 29, 2011 11:19 PM > To: Songhaibin > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-08.txt > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > This version takes care of all my comments, but you accidentally removed the > dMFlags field from DiagnosticsRequest. > > Thanks. > > On 12/28/2011 05:57 PM, Songhaibin wrote: > > The draft has been updated. Any comments are welcome. > > > > BR, > > -Haibin > > > >> -----Original Message----- > >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf > Of > >> internet-drafts@ietf.org > >> Sent: Thursday, December 29, 2011 9:54 AM > >> To: i-d-announce@ietf.org > >> Cc: p2psip@ietf.org > >> Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-08.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. > >> This draft is a work item of the Peer-to-Peer Session Initiation Protocol > Working > >> Group of the IETF. > >> > >> Title : P2PSIP Overlay Diagnostics > >> Author(s) : Song Haibin > >> Jiang Xingfeng > >> Roni Even > >> David A. Bryan > >> Filename : draft-ietf-p2psip-diagnostics-08.txt > >> Pages : 29 > >> Date : 2011-12-28 > >> > >> 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-08.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> This Internet-Draft can be retrieved at: > >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-diagnostics-08.txt > >> > > > - -- > 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.11 (GNU/Linux) > > iQIcBAEBCAAGBQJO/ITXAAoJECnERZXWan7EyQ4P/RR1nDKGVV6PwNQ3Z9K7HNX > b > maTDdMo8lyR6epxjCeud1mwZ5Sw1WSFGlm+x2fV+6cu1yZORGg2JCNu98z0Im7 > wC > Swiq874vah517wXTJ5CKJwHHZMNdE9F2X78kBp74fOGbpZfkDIAOyYhffanAouTy > KmNawLusoLBd1cYap8yh9PuKgWYEG47oMOvn8sgFrzkCK89S1b/S5TVuiVwJl8AX > tUxrkS35NMLdeh8kB0deLJw3RS7A28kR31nh2TrRjGE0s+u+4XCEdkmpQHC54k5C > ck+KJ7oT9saEVlCw+fn7sotlnqd5tNLzq21jwlPv/sdoZy/Oup4PQDw3uH6AGpEq > 5t6wpiSCjJQgMKP8nPu8aY7Nyb6zjwfAJIdrYVw8b8VfgbahOnrAfkA9ysBhwQPC > xkwT3n6V9mAc+0fTnhoVcs4ChA0ni6VtQCaC/CUTV8lTWvYXXa3BUFfpEQqEEAEK > ohiMzGlKPXkMz93Iz4DylUgO14U8nNjdGVMVJyGu5mVewAUYmLyIJGQox2xExK > mJ > ZhOp6WbAOYnG25R4cuRKrPft7TgNDjuVBYOd6/TynooPIpBAisB80S1KSO10tf7i > hqPeWj/xrNu7zSDLvPxr6/b6gw9ryhjXM6iF2kESVVUt09el2WjnjIG3uy2RmlRw > uV05PsuZelKpTxW0EPJw > =b27Z > -----END PGP SIGNATURE-----